Einleitung
In diesem Dokument wird die Verwendung von BGP Community Values zur Steuerung der Routing-Richtlinie in Upstream-Anbieternetzwerken beschrieben.
Voraussetzungen
Anforderungen
In diesem Dokument werden Kenntnisse über das Border Gateway Protocol (BGP)-Routing-Protokoll und dessen Funktionsweise benötigt.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt. Die Informationen in diesem Dokument basieren jedoch auf der folgenden Softwareversion:
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Auch wenn die Communitys selbst den Prozess für den BGP-besten Pfad nicht verändern, können sie als Markierungen für bestimmte Routen verwendet werden. Upstream-Service-Provider-Router können diese Flags verwenden, um innerhalb ihres Netzwerks bestimmte Routing-Richtlinien (z. B. die lokale Präferenz) anzuwenden.
Provider ordnen Ihre konfigurierbaren Community-Werte den entsprechenden lokalen Voreinstellungen innerhalb des Anbieternetzwerks zu. Sie können spezifische Richtlinien festlegen, für die LOCAL_PREF im Anbieternetzwerksatz und die entsprechenden Community-Werte in den Routing-Updates geändert werden müssen.
Eine Community ist eine Gruppe von Präfixen, die gemeinsame Eigenschaften haben und mit dem BGP-Community-Attribut konfiguriert werden können. Das BGP-Community-Attribut ist ein optionales transitives Attribut variabler Länge. Das Attribut besteht aus einem Satz von vier Oktetten, die eine Community angeben. Die Community-Attributwerte werden mit einer AS-Nummer (Autonomous System) in den ersten beiden Oktetten codiert, während die beiden anderen Oktetten vom AS definiert werden. Ein Präfix kann mehr als ein Community-Attribut aufweisen. Ein BGP-Sprecher, der mehrere Community-Attribute in einem Präfix erkennt, kann auf der Grundlage eines, einiger oder aller Attribute agieren. Ein Router hat die Möglichkeit, ein Community-Attribut hinzuzufügen oder zu ändern, bevor der Router das Attribut an andere Peers weitergibt. Weitere Informationen zum Community-Attribut finden Sie in den BGP-Anwenderberichten.
Das Attribut "local preference" gibt dem AS an, welcher Pfad bevorzugt wird, um ein bestimmtes Netzwerk zu erreichen. Wenn mehrere Pfade zum gleichen Ziel vorhanden sind, wird der Pfad mit der höheren Einstellung ausgewählt (der Standardwert des lokalen Einstellungsattributs ist 100). Weitere Informationen finden Sie unter Fallstudien.
Konventionen
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Konfigurieren und Steuern der Routing-Richtlinie
Hinweis: Weitere Informationen zu den in diesem Dokument verwendeten Befehlen erhalten Sie mit dem Befehlsnachschlachtungstool.
Zur Vereinfachung wird davon ausgegangen, dass die Zuordnung von Community-Attributen und lokalen Voreinstellungsattributen zwischen dem Upstream-Service-Provider (AS 100) und Ihrem Gerät (AS 30) eingerichtet wird.
Lokale Präferenz |
Gemeinschaftswerte |
130 |
100:300 |
125 |
100:250 |
Wenn die Präfixe mit einem Community-Attribut von 100:300 angekündigt werden, setzt der Upstream-Service Provider die lokale Präferenz für diese Routen auf 130 und 125, wenn das Community-Attribut 100:250 entspricht.
Dadurch haben Sie die Kontrolle über die Routing-Richtlinie im Service-Provider-Netzwerk, wenn Sie die Community-Werte der dem Service Provider angekündigten Präfixe ändern.
Im Netzwerkdiagramm möchte AS 30 diese Routing-Richtlinie mit den Community-Attributen verwenden.
-
Der von AS 100 an das Netzwerk 10.0.10.0/24 eingehende Datenverkehr wird über die R1-R3-Verbindung geleitet. Wenn die R1-R3-Verbindung ausfällt, wird der gesamte Datenverkehr über R2-R3 geleitet.
-
Der von AS 100 an das Netzwerk 10.1.0.0/24 eingehende Datenverkehr wird über die R2-R3-Verbindung geleitet. Wenn die R2-R3-Verbindung ausfällt, wird der gesamte Datenverkehr über R1-R3 geleitet.
Um diese Routing-Richtlinie zu erreichen, kündigt R3 seine Präfixe wie folgt an:
Zu R1:
- 10.0.10.0/24 mit Community-Attribut 100:300
- 10.1.0.0/24 mit Community-Attribut 100:250
Zu R2:
Wenn die BGP-Nachbarn R1 und R2 die Präfixe von R3 empfangen haben, wenden R1 und R2 die konfigurierte Richtlinie basierend auf der Zuordnung zwischen den Attributen für die Community und die lokalen Einstellungen an (siehe vorige Tabelle), um die von Ihnen (AS 30) diktierte Routing-Richtlinie zu erreichen. R1 installiert die Präfixe in der BGP-Tabelle.
R2 installiert das Präfix in seiner BGP-Tabelle:
Da bei den BGP-Pfadauswahlkriterien eine höhere lokale Präferenz bevorzugt wird, wird der Pfad mit einer lokalen Präferenz von 130 (130 ist größer als 125) als bester Pfad innerhalb von AS 100 ausgewählt und in der IP-Routing-Tabelle von R1 und R2 installiert. Weitere Informationen zu den BGP-Pfadauswahlkriterien finden Sie unter BGP Best Path Selection Algorithm.
Netzwerkdiagramm
BGP-Netzwerk
Konfigurationen
In diesem Dokument werden folgende Konfigurationen verwendet:
R3
hostname R3
!
interface Loopback0
ip address 10.0.10.0 255.255.255.0
!
interface Ethernet0/0
ip address 10.1.0.0 255.255.255.1
!
interface Serial8/0
ip address 10.10.13.3 255.255.255.0
!--- Interface connected to R1
!
interface Serial9/0
ip address 10.10.23.3 255.255.255.0
!--- Interface connected to R2
!
router bgp 30
network 10.0.10.0 mask 255.255.255.0
network 10.1.0.0 mask 255.255.255.1
!--- Network commands announce prefix 10.0.10.0/24 and 10.1.0.0/24.
neighbor 10.10.13.1 remote-as 100
!--- Establishes peering with R1
neighbor 10.10.13.1 send-community
!--- Without this command, the community attributes are not sent to the neighbor
neighbor 10.10.13.1 route-map Peer-R1 out
!--- Configures outbound policy as defined by route-map "Peer-R1" when peering with R1
neighbor 10.10.23.2 remote-as 100
!--- Establishes peering with R2
neighbor 10.10.23.2 send-community
!--- Configures to send community attribute to R2
neighbor 10.10.23.2 route-map Peer-R2 out
!--- Configures outbound policy as defined by
!--- route-map "Peer-R2" when peering with R2.
no auto-summary
!
ip classless
ip bgp-community new-format
!--- Allows you to configure the BGP community
!--- attribute in AA:NN format.
!
access-list 101 permit ip host 10.0.10.0 host 255.255.255.0
access-list 102 permit ip host 10.1.0.0 host 255.255.255.1
!
!
route-map Peer-R1 permit 10
match ip address 101
set community 100:300
!--- Sets community 100:300 for routes matching access-list 101
!
route-map Peer-R1 permit 20
match ip address 102
set community 100:250
!--- Sets community 100:250 for routes matching access-list 102
!
route-map Peer-R2 permit 10
match ip address 101
set community 100:250
!--- Sets community 100:250 for routes matching access-list 101
!
route-map Peer-R2 permit 20
match ip address 102
set community 100:300
!--- Sets community 100:300 for routes matching access-list 102
!
end
R1
hostname R1
!
interface Loopback0
ip address 10.200.10.1 255.255.255.0
!
interface Serial8/0
ip address 10.10.13.1 255.255.255.1
!--- Connected to R3
!
interface Serial10/0
ip address 10.10.12.1 255.255.255.0
!--- Connected to R2
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.10.12.2 remote-as 100
!--- Establishes peering with R2
neighbor 10.10.12.2 next-hop-self
neighbor 10.10.13.3 remote-as 30
!--- Establishes peering with R3
neighbor 10.10.13.3 route-map Peer-R3 in
!--- Configures the inbound policy as defined by route-map "Peer-R3" when peering with R3.
no auto-summary
!
ip bgp-community new-format
!--- Allows you to configure the BGP community attribute in AA:NN format.
ip community-list 1 permit 100:300
ip community-list 2 permit 100:250
!--- Defines community list 1 and 2.
!
route-map Peer-R3 permit 10
match community 1
set local-preference 130
!--- Sets local preference 130 for all routes matching community list 1.
!
route-map Peer-R3 permit 20
match community 2
set local-preference 125
!--- Sets local preference 125 for all routes matching community list 2.
!
route-map Peer-R3 permit 30
!--- Without this permit 30 statement, updates that do not match the permit 10 or permit 20 statements are dropped.
!
end
R2
hostname R2
!
interface Loopback0
ip address 10.0.10.0 255.255.255.0
!
interface Serial9/0
ip address 10.10.23.2 255.255.255.1
!--- Connected to R3
!
interface Serial10/0
ip address 10.10.12.2 255.255.255.0
!--- Connected to R1
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 10.10.12.1 remote-as 100
!--- Establishes iBGP peering with R1
neighbor 10.10.12.1 next-hop-self
neighbor 10.10.23.3 remote-as 30
!--- Establishes peering with R3
neighbor 10.10.23.3 route-map Peer-R3 in
!--- Configures inbound policy as defined by route-map "Peer-R3" when peering with R3.
no auto-summary
!
ip bgp-community new-format
!--- Allows you to configure the BGP community attribute in AA:NN format.
!
ip community-list 1 permit 100:300
ip community-list 2 permit 100:250
!--- Defines community list 1 and 2.
!
route-map Peer-R3 permit 10
match community 1
set local-preference 130
!--- Sets local preference 130 for all routes matching community list 1.
!
route-map Peer-R3 permit 20
match community 2
set local-preference 125
!--- Sets local preference 125 for all routes matching community list 2.
!
route-map Peer-R3 permit 30
!--- Without this permit 30 statement, updates that do not match the permit 10 or permit 20 statements are dropped.
!
end
Verifizierung
R1 empfängt die Präfixe 10.0.10.0/24 und 10.1.0.0/24 mit den Communities 100:300 und 100:250, wie im nächsten show ip bgp Befehlsausgabeergebnis gezeigt.
Hinweis: Wenn diese Routen gemäß der konfigurierten Richtlinie in der BGP-Tabelle installiert wurden, wird den Präfixen mit der Community 100:300 die lokale Präferenz 130 und den Präfixen mit der Community 100:250 die lokale Präferenz 125 zugewiesen.
R1#show ip bgp 10.0.10.0 BGP routing table entry for 10.0.10.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.10.12.2 30 10.10.13.3 from 10.10.13.3 (10.0.10.0) Origin IGP, metric 0, localpref 130, valid, external, best Community: 100:300 !--- Prefix 10.0.10.0/24 with community 100:300 received from 10.10.13.3 (R3) is assigned local preference 130.
R1#show ip bgp 10.1.0.0 BGP routing table entry for 10.1.0.0/24, version 4 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.10.13.3 30 10.10.12.2 from 10.10.12.2 (10.1.0.0) Origin IGP, metric 0, localpref 130, valid, internal, best
!--- Received prefix 10.1.0.0/24 over iBGP from 10.10.12.2 (R2) with local preference 130
30 10.10.13.3 from 10.10.13.3 (198.51.100.1) Origin IGP, metric 0, localpref 125, valid, external Community: 100:250 !--- Prefix 10.1.0.0/24 with community 100:250 received from 10.10.13.3 (R3) is assigned local preference 125.
R1#show ip bgp BGP table version is 4, local router ID is 10.200.10.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 10.0.10.0/24 10.10.13.3 0 130 0 30 i *>i 10.1.0.0/24 10.10.12.2 0 130 0 30 i * 10.10.13.3 0 125 0 30 i
Der show ip bgp Befehl auf R1 bestätigt, dass der beste auf R1 ausgewählte Pfad mit der lokalen Präferenz (LoclPrf) = 130 lautet. Ebenso empfängt R2 die Präfixe 10.0.10.0/24 und 10.1.0.0/24 mit den Communities 100:250 und 100:300, wie in dieser show ip bgp Befehlsausgabe fett dargestellt:
Hinweis: Wenn diese Routen gemäß der konfigurierten Richtlinie in der BGP-Tabelle installiert wurden, wird den Präfixen mit der Community 100:300 die lokale Präferenz 130 und den Präfixen mit der Community 100:250 die lokale Präferenz 125 zugewiesen.
R2#show ip bgp 10.0.10.0 BGP routing table entry for 10.0.10.0/24, version 2 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.10.23.3 30 10.10.23.3 from 10.10.23.3 (10.0.10.0) Origin IGP, metric 0, localpref 125, valid, external Community: 100:250 !--- Prefix 10.0.10.0/24 with community 100:250 received from 10.10.23.3 (R3) is assigned local preference 125
30 10.10.12.1 from 10.10.12.1 (10.200.10.1) Origin IGP, metric 0, localpref 130, valid, internal, best !--- Received prefix 10.0.10.0/24 over iBGP from 10.10.12.1 (R1) with local preference 130
R2#show ip bgp 10.1.0.0 BGP routing table entry for 10.1.0.0/24, version 3 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.10.12.1 30 10.10.23.3 from 10.10.23.3 (10.1.0.0) Origin IGP, metric 0, localpref 130, valid, external, best Community: 100:300 !--- Prefix 10.1.0.0/24 with community 100:300 received from 10.10.23.3 (R3) is assigned local preference 130.
R2#show ip bgp BGP table version is 3, local router ID is 192.168.50.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 10.0.10.0/24 10.10.23.3 0 125 0 30 i *>i 10.10.12.1 0 130 0 30 i *> 10.1.0.0/24 10.10.23.3 0 130 0 30 i
Mit dieser show ip bgp Befehlsausgabe auf R2 wird bestätigt, dass der beste Pfad auf R2 mit der lokalen Präferenz (loclPrf) = 130 ausgewählt wurde. Die IP-Route zum Präfix 10.0.10.0/24 bevorzugt die R1-R3-Verbindung zum Beenden von AS 100 zu AS 30. Der show ip route Befehl auf R1 und R2 bestätigt diese Einstellung.
R1#show ip route 10.0.10.0 Routing entry for 10.0.10.0/24 Known via "bgp 100", distance 20, metric 0 Tag 30, type external Last update from 10.10.13.3 3d21h ago Routing Descriptor Blocks: * 10.10.13.3, from 10.10.13.3, 3d21h ago Route metric is 0, traffic share count is 1 AS Hops 1 !--- On R1, the IP route to prefix 10.0.10.0/24 points to next hop 10.10.13.3 which is R3 serial 8/0 interface on the R1-R3 link.
R2#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 200, metric 0 Tag 30, type internal Last update from 10.10.12.1 3d21h ago Routing Descriptor Blocks: * 10.10.12.1, from 10.10.12.1, 3d21h ago Route metric is 0, traffic share count is 1 AS Hops 1 !--- On R2, IP route to prefix 10.1.0.0/24 points to next hop R1 (10.10.12.1) on its iBGP link !--- Thus traffic to network 10.1.0.0/24 from R2 exits through R2-R1 and then R1-R3 link from AS 100 towards AS 30
Die IP-Route zum Präfix 10.1.0.0/24 bevorzugt eine R2-R3-Verbindung zum Beenden von AS 100 zu AS 30. Der show ip route Befehl auf R1 und R2 bestätigt diese Einstellung.
R2#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 20, metric 0 Tag 30, type external Last update from 10.10.23.3 3d22h ago Routing Descriptor Blocks: * 10.10.23.3, from 10.10.23.3, 3d22h ago Route metric is 0, traffic share count is 1 AS Hops 1 !--- On R2, IP route to prefix 10.1.0.0/24 points to next hop 10.10.23.3 which is R3 serial 9/0 interface on R2-R3 link.
R1#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 200, metric 0 Tag 30, type internal Last update from 10.10.12.2 3d22h ago Routing Descriptor Blocks: * 10.10.12.2, from 10.10.12.2, 3d22h ago Route metric is 0, traffic share count is 1 AS Hops 1 !--- On R1, IP route to prefix 10.1.0.0/24 points to next hop R2 (10.10.12.2) on its iBGP link. !--- Thus traffic to network 10.1.0.0/24 from R1 exits through R1-R2 and then R2-R3 link from AS 100 towards AS 30.
Wenn eine Verbindung ausfällt, z. B. die R1-R3-Verbindung, muss der gesamte Datenverkehr die R2-R3-Verbindung verfolgen. Sie können diesen Datenverkehr simulieren, wenn Sie die Verbindung zwischen R1 und R3 beenden.
R1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. R1(config)#interface serial8/0 R1(config-if)#shut R1(config-if)# 3d22h: %BGP-5-ADJCHANGE: neighbor 10.10.13.3 Down Interface flap 3d22h: %LINK-5-CHANGED: Interface Serial8/0, changed state to administratively down 3d22h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0, changed state to down
Beachten Sie die IP-Routing-Tabelle für das Präfix 10.0.10.0/24 und 10.1.0.0/24 auf R1 und R2. Verwenden Sie die R2-R3-Verbindung, um den AS 100 zu verlassen.
R1#show ip route 10.0.10.0 Routing entry for 10.0.10.0/24 Known via "bgp 100", distance 200, metric 0 Tag 30, type internal Last update from 10.10.12.2 00:01:47 ago Routing Descriptor Blocks: * 10.10.12.2, from 10.10.12.2, 00:01:47 ago Route metric is 0, traffic share count is 1 AS Hops 1
R1#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 200, metric 0 Tag 30, type internal Last update from 10.10.12.2 3d22h ago Routing Descriptor Blocks: * 10.10.12.2, from 10.10.12.2, 3d22h ago Route metric is 0, traffic share count is 1 AS Hops 1
Diese show Befehlsausgabe zeigt, dass die Route zu den Präfixen 10.0.10.0/24 und 10.1.0.0/24 auf den erwarteten nächsten Hop 10.10.12.2 (R2) verweist. Sehen Sie sich nun die IP-Routing-Tabelle auf R2 an, um den Next-Hop des Präfix 10.0.10.0/24 und 10.1.0.0/24 zu überprüfen. Der nächste Hop muss R3 sein, damit die konfigurierte Richtlinie erfolgreich funktioniert.
R2#show ip route 10.0.10.0 Routing entry for 10.0.10.0/24 Known via "bgp 100", distance 20, metric 0 Tag 30, type external Last update from 10.10.23.3 00:04:10 ago Routing Descriptor Blocks: * 10.10.23.3, from 10.10.23.3, 00:04:10 ago Route metric is 0, traffic share count is 1 AS Hops 1
R2#show ip route 10.1.0.0 Routing entry for 10.1.0.0/24 Known via "bgp 100", distance 20, metric 0 Tag 30, type external Last update from 10.10.23.3 3d22h ago Routing Descriptor Blocks: * 10.10.23.3, from 10.10.23.3, 3d22h ago Route metric is 0, traffic share count is 1 AS Hops 1
Der nächste Hop 10.10.23.3 ist die serielle R3 9/0-Schnittstelle auf der R2-R3-Verbindung. Dadurch wird bestätigt, dass die konfigurierte Richtlinie wie erwartet funktioniert.
Zugehörige Informationen