In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie das metrische Attribut des Accumulated Interior Gateway Protocol (AIGP) konfiguriert wird, das vom Border Gateway Protocol (BGP) in Cisco IOS® übernommen wird.
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
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 Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.
Dieser Abschnitt bietet einen Überblick über das metrische Attribut "AIGP" und einige wichtige Überlegungen zu seiner Verwendung.
Unternehmen möchten möglicherweise ein Netzwerkdesign implementieren, bei dem das Netzwerk aus mehreren Interior Gateway Protocols (IGPs) besteht, von denen jedes über ein autonomes BGP-System verfügt. Dies wird aus Gründen der Skalierbarkeit verwendet, wenn das Netzwerk für ein IGP zu groß wird. Das BGP ist skalierbar, wenn es einige Routen überträgt, die sonst vom IGP übertragen würden. Die Lösung, die AIGP verwendet, ist für Netzwerke mit unterschiedlichen autonomen BGP-Systemen unter einer zentralen Verwaltungskontrolle vorgesehen.
Hier ein Beispiel:
Der End-to-End-Service ist Multi-Protocol Label Switching (MPLS) VPN. Wenn im Netzwerk eine große Anzahl von Provider Edge (PE)-Routern vorhanden ist, muss das IGP zu viele Routen übertragen. Die Lösung besteht darin, dass BGP die Loopback-Schnittstellen der PE-Router überträgt. Die Lösung, die verwendet wird, um sicherzustellen, dass der MPLS Label Switched Path (LSP) nicht durchgängig unterbrochen wird, ist die Verwendung des BGP IPv4 +-Labels. Dies bedeutet, dass RFC 3107 zwischen den PE-Routern und den Grenzroutern verwendet wird, die die verschiedenen IGP-Domänen miteinander verbinden.
Das Problem bei dieser Lösung besteht darin, dass die Grenzrouter oder die PE-Router keine Entscheidung mehr für den besten Pfad auf Basis des kürzesten metrischen End-to-End-Verfahrens treffen können, da es kein IGP mehr gibt, das im gesamten Netzwerk ausgeführt wird. Die Lösung für dieses Problem ist das neue BGP-Attribut, das Accumulated IGP Metric Attribute oder AIGP Metric Attribute genannt wird. Dieses nicht-transitive BGP-Attribut enthält die kumulierte Metrik für die Pfade, sodass die BGP-Sprecher die End-to-End-Metrik für diese Pfade kennen lernen.
Die BGP-Router müssen die Route zur Next-Hop-Metrik zum aktuellen Wert im metrischen Attribut des AIGP hinzufügen, bevor die Route weitergeleitet wird.
Hinweis: Der Vergleich der Pfade für eine Route erfolgt unmittelbar nach dem Vergleich der lokalen Präferenz. Weitere Informationen zum BGP Best Path Selection Algorithm finden Sie im Dokument BGP Best Path Selection Algorithm von Cisco.
Diese Lösung ähnelt der Lösung, bei der der Multi-Exit-Diskriminator (MED) auf die IGP-Metrik festgelegt ist. In diesem Fall entscheidet jedoch Schritt 6 (der niedrigste MED) über den besten Pfad. Dieser Schritt erfolgt nach Schritt 4, bei dem der kürzeste Pfad den besten Pfad bestimmt. Der beste Pfad wird häufig bereits gefunden, bevor Schritt 6 erreicht wird. Bei der AIGP-Lösung wird die normale BGP-Entscheidung so geändert, dass das AIGP nach Schritt 3 überprüft wird, um festzustellen, ob die Route lokal angekündigt wurde. Wenn verschiedene benachbarte ASs (Autonomous Systems) mit dem BGP-Sprecher Peers arbeiten, bedeutet dies, dass der stets vergleiche mittlere Wert aktiviert werden muss.
Das metrische Attribut AIGP wird in RFC 7311 festgelegt, dem kumulierten metrischen IGP-Attribut für BGP. Um den AIGP-Metrik-Wert in der Kostengemeinschaft zu tragen, werden die in der Draft-retana-idr-aigp-cost-community festgelegten Verfahren (Verwendung der Cost Community zur Übertragung des kumulierten IGP-Metrik) verwendet.
Hinweis: Die BGP AIGP-Metrik bietet ein optimales Routing in Netzwerken, in denen verschiedene Routing-Domänen über das BGP verbunden sind.
Bei Verwendung von AIGP werden folgende Änderungen am BGP Best Path Selection Algorithm vorgenommen:
Wenn es sich bei den IGPs im Netzwerk um unterschiedliche Typen handelt (Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), Enhanced Interior Gateway Routing Protocol (EIGRP)), ist es unwahrscheinlich, dass die Kennzahl, die sich aus der Verwendung des AIGP-Attributs ergibt, zu konsistenten oder vernünftigen Ergebnissen führt. Wenn in den verschiedenen Domänen dasselbe IGP verwendet wird, müssen dieselben Metrikeinstellungen verwendet werden, um konsistente Ergebnisse zu gewährleisten.
Damit die Grenzrouter oder PE-Router zwischen mehreren Pfaden (basierend auf der von AIGP abgeleiteten Metrik) entscheiden können, müssen sie zunächst mehrere Pfade empfangen. Aus diesem Grund müssen Sie möglicherweise den zusätzlichen Pfad (ADD-Pfad) aktivieren oder die beste externe BGP-Funktion bewerben.
Die für AIGP aktivierten BGP-Peers und die Peers, die nicht in separate Aktualisierungsgruppen unterteilt sind. Darüber hinaus werden die in der Kostengemeinschaft für AIGP aktivierten BGP-Peers in separate Aktualisierungsgruppen unterteilt.
Wenn im Netzwerk Router vorhanden sind, die kein AIGP (Legacy-Router) unterstützen, gibt es zwei mögliche Lösungen:
In diesem Abschnitt wird beschrieben, wie das metrische Attribut AIGP konfiguriert wird.
Das AIGP muss explizit für interne BGP (iBGP)- und externe BGP (eBGP)-Sitzungen mit dem neighbor ip-address aigp
aus.
So überprüfen Sie, ob das AIGP für den BGP-Peer aktiviert ist:
P3#show bgp ipv4 unicast neighbors 10.1.9.2 | in AIGP
For address family: IPv4 Unicast
AIGP is enabled
Das AIGP kann auf die IGP-Metrik oder einen Wert festgelegt werden. Das AIGP kann auch für bestimmte Routen nur für IGPs über eine route-map
. Wenn der Urheber des AIGP eine Änderung der IGP-Metrik erkennt, sollte er ein neues BGP-Update mit den neuen AIGP-Werten für die betroffenen Routen senden.
Die AIGP-Metrik kann automatisch auf die IGP-Metrik oder einen beliebigen 32-Bit-Wert festgelegt werden:
P1(config-route-map)#set aigp-metric ?
<0-4294967295> manual value
igp-metric metric value from rib
Dieses Beispiel zeigt, wie die AIGP-Metrik auf die Metrik der IGP-Route festgelegt wird:
ip prefix-list loopback seq 5 permit 10.100.1.1/32
!
route-map redistribute-loopback permit 10
match ip address prefix-list loopback
set aigp-metric igp-metric
Wenn dieser Knopf aktiviert ist, verwendet das BGP keinen AIGP-Timer, es sei denn, beide Pfade haben das metrische Attribut AIGP. Das bedeutet, dass das AIGP-Attribut nicht beim besten Pfadauswahlprozess zwischen zwei Pfaden ausgewertet wird, wenn ein Pfad nicht über das AIGP-Attribut verfügt.
Hier ein Beispiel:
router bgp 65000
bgp bestpath aigp ignore
Wenn der Router PE2 keine Software besitzt, die das metrische Attribut AIGP unterstützt (es handelt sich um einen Legacy-Router), können Sie zwei Lösungen verwenden.
Konfigurieren Sie die Router P3 und P4, um die IGP-Kosten in eine Kostengemeinschaft umzuwandeln, die der Router einem älteren Router ankündigen kann:
P3#show run | beg router bgp
router bgp 65000
address-family ipv4
neighbor 10.1.9.2 activate
neighbor 10.1.9.2 send-community both
neighbor 10.1.9.2 aigp send cost-community 100 poi igp-cost transitive
P4#show run | beg router bgp
router bgp 65000
address-family ipv4
neighbor 10.1.10.2 activate
neighbor 10.1.10.2 send-community both
neighbor 10.1.10.2 aigp send cost-community 100 poi igp-cost transitive
Sie müssen dem Router, der sendet, erlauben, erweiterte Communitys zu senden. Das bedeutet, Sie müssen send-community extended
Oder send-community both
Attribute (neighbor x.x.x.x send-community
) für den BGP-Peer.
Hier ein Beispiel:
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 6
Paths: (2 available, best #1, table default)
Advertised to update-groups:
6
Refresh Epoch 2
65000 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, localpref 100, valid, external, best
Extended Community: Cost(transitive):igp:100:6
mpls labels in/out 17/16
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 15
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, localpref 100, valid, external
Extended Community: Cost(transitive):igp:100:11
mpls labels in/out 17/30
rx pathid: 0, tx pathid: 0
Wie gezeigt, wählte der Router PE2 den Pfad mit den niedrigsten Kosten (100:6 gegenüber 100:11) als besten Pfad.
Konfigurieren Sie die Router P3 und P4, um die IGP-Kosten in das MED zu übersetzen, das der Router einem älteren Router mitteilen kann.
Die Konfiguration auf dem Router P3 sieht wie folgt aus:
router bgp 65000
address-family ipv4
neighbor 10.1.9.2 activate
neighbor 10.1.9.2 send-community both
neighbor 10.1.9.2 aigp send med
Die Konfiguration auf dem Router P4 ist wie folgt:
router bgp 65000
address-family ipv4
neighbor 10.1.10.2 activate
neighbor 10.1.10.2 send-community both
neighbor 10.1.10.2 aigp send med
Die Ausgabe der debug bgp ipv4 unicast updates in
zeigt die Verwendung des metrischen AIGP-Attributs:
PE2#
BGP(0): 10.1.9.4 rcvd UPDATE w/ attr: nexthop 10.1.9.4, origin ?, aigp-metric 22,
merged path 65000 65001, AS_PATH
Wenn Sie das im Abschnitt dieses Dokuments bereitgestellte Bild betrachten, sehen Sie, dass alle Verbindungen im Netzwerk AS 6500 OSPF-Kosten von 10 haben, die Verbindungen zwischen den Routern P1 und P4 sowie zwischen P2 und P3 OSPF-Kosten von 100 haben und die Verbindung zwischen den Routern P3 und P1 5.
Dies ist die Route für 10.100.1.1/32 (siehe Router P3:
P3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (2 available, best #1, table default)
Additional-path-install
Path advertised to update-groups:
5
Refresh Epoch 5
65001
10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.3, Cluster list: 10.100.1.7
mpls labels in/out 29/16
rx pathid: 0x0, tx pathid: 0x0
Path not advertised to any peer
Refresh Epoch 5
65001
10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)
Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all
Originator: 10.100.1.5, Cluster list: 10.100.1.7
mpls labels in/out 29/16
rx pathid: 0x1, tx pathid: 0x1
Dies ist die Route für 10.100.1.1/32, wie auf dem Router P4 gezeigt:
P4#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 9
Paths: (2 available, best #2, table default)
Additional-path-install
Path not advertised to any peer
Refresh Epoch 5
65001
10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)
Origin incomplete, metric 0, localpref 100, valid, internal, backup/repair, all
Originator: 10.100.1.3, Cluster list: 10.100.1.7
mpls labels in/out 29/16
rx pathid: 0x0, tx pathid: 0x1
Path advertised to update-groups:
35
Refresh Epoch 5
65001
10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.5, Cluster list: 10.100.1.7
mpls labels in/out 29/16
rx pathid: 0x1, tx pathid: 0x0
Dies ist die Route für 10.100.1.1/32, wie auf dem Router PE2 zu sehen:
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 4
Paths: (2 available, best #2, table default)
Advertised to update-groups:
5
Refresh Epoch 1
65000 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, localpref 100, valid, external
mpls labels in/out 18/17
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, localpref 100, valid, external, best
mpls labels in/out 18/30
rx pathid: 0, tx pathid: 0x0
Der beste Pfad auf dem Router P3 ist der Pfad mit der IGP-Metrik 6, wobei der Router P1 der nächste Hop ist. Der beste Pfad auf dem Router P4 ist der Pfad mit der IGP-Metrik 11, wobei der Router P2 der nächste Hop ist. Die Router P3 und P4 senden ihren besten Pfad zum Router PE2. Der Router PE2 wählt den Pfad vom Router P4 als besten aus. Dieser wurde entschieden, da beide BGP-Pfade auf dem Router PE2 sehr ähnlich sind und Schritt 10 der Zeitbegrenzer war: der älteste externe Pfad hat gewonnen. Das bedeutet, dass der Datenverkehr vom Router PE2 zum Router PE1 den Pfad PE2-P4-P2-PE1 nutzt. Bei Berücksichtigung der IGP-Kosten ist jedoch der kürzeste Gesamtpfad PE2-P3-P1-PE1.
Verwenden Sie die folgenden Informationen, um das metrische Attribut für AIGP auf den Routern P3 und P4 zum Router PE2 zu überprüfen (10.100.1.7):
Die Ausgabe für den Router P3 sieht wie folgt aus:
router bgp 65000
address-family ipv4
bgp additional-paths select all
bgp additional-paths receive
bgp additional-paths install
neighbor 10.1.9.2 activate
neighbor 10.1.9.2 aigp
neighbor 10.1.9.2 send-label
neighbor 10.100.1.7 activate
neighbor 10.100.1.7 aigp
neighbor 10.100.1.7 next-hop-self
neighbor 10.100.1.7 send-label
Die Ausgabe für den Router P4 ist wie folgt:
router bgp 65000
address-family ipv4
bgp additional-paths select all
bgp additional-paths receive
bgp additional-paths install
neighbor 10.1.10.2 activate
neighbor 10.1.10.2 aigp
neighbor 10.1.10.2 send-label
neighbor 10.100.1.7 activate
neighbor 10.100.1.7 aigp
neighbor 10.100.1.7 next-hop-self
neighbor 10.100.1.7 send-label
Sie können sehen, dass der Router P3 jetzt über Folgendes verfügt:
P3#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 30
Paths: (2 available, best #2, table default)
Additional-path-install
Path not advertised to any peer
Refresh Epoch 11
65001
10.100.1.5 (metric 21) from 10.100.1.7 (10.100.1.7)
Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,
backup/repair, all
Originator: 10.100.1.5, Cluster list: 10.100.1.7
mpls labels in/out 28/31
rx pathid: 0x1, tx pathid: 0x1
Path advertised to update-groups:
5
Refresh Epoch 11
65001
10.100.1.3 (metric 6) from 10.100.1.7 (10.100.1.7)
Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.3, Cluster list: 10.100.1.7
mpls labels in/out 28/30
rx pathid: 0x0, tx pathid: 0x0
Der Router P4 verfügt jetzt über:
P4#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 30
Paths: (2 available, best #1, table default)
Additional-path-install
Path advertised to update-groups:
35
Refresh Epoch 11
65001
10.100.1.5 (metric 11) from 10.100.1.7 (10.100.1.7)
Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal, best
Originator: 10.100.1.5, Cluster list: 10.100.1.7
mpls labels in/out 16/31
rx pathid: 0x1, tx pathid: 0x0
Path not advertised to any peer
Refresh Epoch 11
65001
10.100.1.3 (metric 16) from 10.100.1.7 (10.100.1.7)
Origin incomplete, aigp-metric 0, metric 0, localpref 100, valid, internal,
backup/repair, all
Originator: 10.100.1.3, Cluster list: 10.100.1.7
mpls labels in/out 16/30
rx pathid: 0x0, tx pathid: 0x1
Die IGP-Metrik für die Pfade auf den Routern P3 und P4 hat sich nicht geändert, aber der Router PE2 empfängt jetzt die Routen mit dem AIGP-Attribut von den Routern P3 und P4.
Der Router PE2 sieht die beiden Pfade. Jeder Pfad hat das AIGP-Attribut, und der Pfad mit dem niedrigsten metrischen Attribut des AIGP gewinnt:
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 6
Paths: (2 available, best #1, table default)
Advertised to update-groups:
5
Refresh Epoch 1
65000 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
mpls labels in/out 18/17
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, aigp-metric 11, localpref 100, valid, external
mpls labels in/out 18/30
rx pathid: 0, tx pathid: 0
Wenn der vom Router P3 empfangene Pfad länger ist als der Pfad, der vom Router P4 auf dem Router PE2 empfangen wird, wählt der Router PE2 den Pfad vom Router P3 immer noch als den besten aus. Sie können den Pfad, den der Router P3 ankündigt, um eins über eine route-map
und as-prepending
.
router bgp 65000
address-family ipv4
neighbor 10.1.9.2 route-map as_path out
route-map as_path permit 10
set as-path prepend last-as 1
Der Router PE2 hat jetzt die Route vom Router P3 mit einem zusätzlichen AS im AS-Pfad:
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 7
Paths: (2 available, best #1, table default)
Advertised to update-groups:
5
Refresh Epoch 1
65000 65001 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
mpls labels in/out 18/nolabel
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, aigp-metric 11, localpref 100, valid, external
mpls labels in/out 18/30
rx pathid: 0, tx pathid: 0
Aufgrund des metrischen Attributs "AIGP" wählt der Router PE2 den Pfad vom Router P3 immer noch als den besten aus. Die AIGP-Prüfung wird durchgeführt, bevor die AS-Pfadlänge überprüft wird.
Wenn Sie die Möglichkeit entziehen, das AIGP auf dem Router P4 an den Router PE2 zu senden, empfängt der Router-PE2 den Pfad ohne das metrische Attribut AIGP vom Router P4. Der Router PE2 hat jedoch weiterhin den Pfad vom Router P3 mit AIGP. Der Router PE2 bevorzugt den Pfad mit AIGP einem Pfad ohne AIGP und wählt den Pfad vom Router P3 als den besten aus:
PE2#show bgp ipv4 unicast 10.100.1.1
BGP routing table entry for 10.100.1.1/32, version 2
Paths: (2 available, best #2, table default)
Advertised to update-groups:
6
Refresh Epoch 1
65000 65001
10.1.10.6 from 10.1.10.6 (10.100.1.6)
Origin incomplete, localpref 100, valid, external
mpls labels in/out 17/30
rx pathid: 0, tx pathid: 0
Refresh Epoch 1
65000 65001 65001
10.1.9.4 from 10.1.9.4 (10.100.1.4)
Origin incomplete, aigp-metric 6, localpref 100, valid, external, best
mpls labels in/out 17/nolabel
rx pathid: 0, tx pathid: 0x0
Hinweis: Wenn der Router PE2 das AIGP während des Prozesses zur Auswahl des besten BGP-Pfads ignorieren soll, konfigurieren Sie den bgp bestpath aigp ignore
aus.
Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
18-May-2021 |
Erstveröffentlichung |