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.
Dieses Dokument enthält eine Beschreibung der Funktion des BGP-Best-Path-Algorithmus (Border Gateway Protocol).
BGP-Router erhalten in der Regel mehrere Pfade zum gleichen Ziel. Der BGP-Algorithmus für den besten Pfad entscheidet, welcher Pfad am besten in der IP-Routing-Tabelle installiert und für die Datenweiterleitung verwendet wird.
Angenommen, alle Pfade, die ein Router für ein bestimmtes Präfix empfängt, sind in einer Liste angeordnet. Die Liste ähnelt der Ausgabe von show ip bgp longer-prefixes
aus. In diesem Fall werden einige Pfade nicht als Kandidaten für den besten Pfad betrachtet. Solche Pfade enthalten in der Regel nicht das gültige Flag in der Ausgabe des show ip bgp longer-prefixes
aus. Router ignorieren Pfade unter folgenden Umständen:
Pfade, die als nicht synchronisiert gekennzeichnet sind im show ip bgp longer-prefixes
Ausgabe.
Wenn die BGP-Synchronisierung aktiviert ist, muss das Präfix in der IP-Routing-Tabelle übereinstimmen, damit ein interner BGP-Pfad (iBGP) als gültiger Pfad angesehen wird. Die BGP-Synchronisierung ist in der Cisco IOS®-Software standardmäßig aktiviert. Wenn die übereinstimmende Route von einem OSPF-Nachbarn (Open Shortest Path First) bezogen wird, muss ihre OSPF-Router-ID mit der BGP-Router-ID des iBGP-Nachbarn übereinstimmen. Die meisten Benutzer ziehen es vor, die Synchronisierung mithilfe des no synchronization
BGP-Unterbefehl.
Hinweis: Die Synchronisierung ist in Version 12.2(8)T der Cisco IOS® Software standardmäßig deaktiviert.
Pfade, auf die NEXT_HOP nicht zugreifen kann.
Stellen Sie sicher, dass eine Interior Gateway Protocol (IGP)-Route zu NEXT_HOP vorhanden ist, die dem Pfad zugeordnet ist.
Pfade von einem externen BGP (eBGP)-Nachbarn, wenn das lokale autonome System (AS) in AS_PATH angezeigt wird.
Solche Pfade werden beim Eindringen in den Router abgelehnt und nicht einmal in der BGP Routing Information Base (RIB) installiert. Das Gleiche gilt für alle Pfade, die durch eine Routingrichtlinie abgelehnt werden, die über den Zugriff, das Präfix, AS_PATH oder Community-Listen implementiert wird, es sei denn, Sie haben neighbor soft-reconfiguration inbound
für den Nachbarn.
Wenn Sie bgp enforce-first-as
und UPDATE enthält nicht das AS des Nachbarn als erste AS-Nummer in AS_SEQUENCE.
In diesem Fall sendet der Router eine Benachrichtigung und beendet die Sitzung.
Pfade, die in der als (nur empfangen) markiert sind show ip bgp longer-prefixes
Ausgabe
Die Richtlinie hat diese Pfade abgelehnt. Der Router hat die Pfade jedoch gespeichert, da Sie soft-reconfiguration inbound
für den Nachbarn, der den Pfad sendet.
BGP weist den ersten gültigen Pfad als aktuellen besten Pfad zu. BGP vergleicht dann den besten Pfad mit dem nächsten Pfad in der Liste, bis BGP das Ende der Liste gültiger Pfade erreicht. Diese Liste enthält die Regeln, die zur Bestimmung des besten Pfads verwendet werden:
Bevorzugung des Pfads mit dem höchsten GEWICHT.
Hinweis: WEIGHT ist ein Cisco-spezifischer Parameter. Er befindet sich lokal auf dem Router, auf dem er konfiguriert ist.
Bevorzugung des Pfads mit dem höchsten LOCAL_PREF.
Hinweis: Bei einem Pfad ohne LOCAL_PREF wurde der Wert mit dem bgp default local-preference
oder standardmäßig auf 100 gesetzt werden.
bevorzugen den Pfad, der lokal über eine network
Oder aggregate
BGP-Unterbefehl oder durch Neuverteilung von einem IGP.
Lokale Pfade, die vom network
Oder redistribute
Befehle werden lokalen Aggregaten vorgezogen, die von den aggregate-address
aus.
Hinweis: Beachten Sie Folgendes:
- Wenn AIGP konfiguriert ist UND die bgp bestpath aigp ignore
nicht konfiguriert ist, berücksichtigt der Entscheidungsprozess die AIGP-Metrik. Weitere Informationen finden Sie unter Configure the AIGP Metric Attribute for BGP.
Bevorzugung des Pfads mit dem kürzesten AS_PATH.
Hinweis: Beachten Sie folgende Punkte:
- Dieser Schritt wird übersprungen, wenn Sie die bgp bestpath as-path ignore
aus.
- Ein AS_SET zählt als 1, unabhängig davon, wie viele ASs in der Gruppe enthalten sind.
- AS_CONFED_SEQUENCE und AS_CONFED_SET sind nicht in der Länge von AS_PATH enthalten.
Bevorzugung des Pfads mit dem niedrigsten Ursprungstyp.
Hinweis: IGP ist niedriger als Exterior Gateway Protocol (EGP) und EGP ist niedriger als INCOMPLETE.
Bevorzugung des Pfads mit dem niedrigsten Multi-Exit Discriminator (MED).
Hinweis: Beachten Sie folgende Punkte:
- Dieser Vergleich findet nur statt, wenn die erste (benachbarte) AS in beiden Pfaden gleich ist. Alle untergeordneten AS der Confederation werden ignoriert.
Mit anderen Worten: MEDs werden nur verglichen, wenn das erste AS in AS_SEQUENCE für mehrere Pfade identisch ist. Alle vorherigen AS_CONFED_SEQUENCE-Elemente werden ignoriert.
- Wenn bgp always-compare-med
aktiviert ist, werden MEDs für alle Pfade verglichen.
Sie müssen diese Option für das gesamte AS deaktivieren. Andernfalls können Routing-Schleifen auftreten.
- Wenn bgp bestpath med-confed
ist aktiviert, werden MEDs für alle Pfade verglichen, die nur aus AS_CONFED_SEQUENCE bestehen.
Diese Pfade stammen aus der lokalen Confederation.
- Der MED von Pfaden, die von einem Nachbarn mit einem MED von 4.294.967.295 empfangen werden, wird vor dem Einfügen in die BGP-Tabelle geändert. Die MED ändert sich auf 4 294 967 294.
- Der MED von Pfaden, die von einem Nachbarn mit einem MED von 4.294.967.295 empfangen werden, gilt als gültig und wird in die BGP-Tabelle eingetragen. Dies wirkt sich auf Codes aus, die aufgrund von Cisco Bug-ID CSCef34800 korrigiert wurden.
- Pfaden, die ohne MED empfangen werden, wird eine MED von 0 zugewiesen, es sei denn, Sie haben diese Option aktiviert bgp bestpath med missing-as-worst
.
Wenn Sie Folgendes aktiviert haben bgp bestpath med missing-as-worst
wird den Pfaden eine MED von 4,294,967,294 zugewiesen.
Wenn Sie Folgendes aktiviert haben bgp bestpath med missing-as-worst
wird den Pfaden eine MED von 4.294.967.295 zugewiesen, die sich auf Codes bezieht, die für die Cisco Bug-ID CSCef34800 behoben wurden.
-Die Fehlermeldung bgp deterministic-med
kann diesen Schritt ebenfalls beeinflussen.
Eine Demonstration finden Sie unter Verwendung des Multi-Exit Discriminator durch BGP-Router für die Auswahl des besten Pfads.
Bevorzugung von eBGP gegenüber iBGP-Pfaden.
Wenn bestpath ausgewählt ist, fahren Sie mit Schritt 9 (Multipath) fort.
Hinweis: Pfade, die AS_CONFED_SEQUENCE und AS_CONFED_SET enthalten, sind für den Verbund lokal. Daher werden diese Pfade als interne Pfade behandelt. Es gibt keine Unterscheidung zwischen Confederation External und Confederation Internal.
Bevorzugung des Pfads mit der niedrigsten IGP-Metrik gegenüber dem nächsten BGP-Hop.
Wird fortgesetzt, auch wenn bestpath bereits ausgewählt ist.
Bestimmung in der Routing-Tabelle für BGP Multipath, ob mehrere Pfade installiert werden müssen.
Wird fortgesetzt, wenn bestpath noch nicht ausgewählt wurde.
Wenn beide Pfade extern sind, wird der zuerst empfangene Pfad (der älteste) bevorzugt.
Dieser Schritt minimiert Routen-Flaps, da ein neuerer Pfad keinen älteren ersetzt, selbst wenn der neuere Pfad basierend auf den nächsten Entscheidungskriterien (Schritte 11, 12 und 13) die bevorzugte Route wäre.
Überspringen Sie diesen Schritt, wenn eines der folgenden Szenarien zutrifft:
Sie haben die bgp best path compare-routerid
aus.
Hinweis: Dieser Befehl wurde mit den Cisco IOS® Software-Versionen 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T und 12.1.3.E eingeführt.
Die Router-ID ist für mehrere Pfade identisch, da die Routen von demselben Router empfangen wurden.
Es gibt aktuell besten Pfad.
Der aktuell beste Pfad kann verloren gehen, wenn beispielsweise der Nachbar, der den Pfad anbietet, ausfällt.
Bevorzugung der Route, die vom BGP-Router mit der niedrigsten Router-ID stammt.
Die Router-ID ist die höchste IP-Adresse auf dem Router, wobei Loopback-Adressen bevorzugt werden. Darüber hinaus können Sie die bgp router-id
, um die Router-ID manuell festzulegen.
Hinweis: Wenn ein Pfad RR-Attribute (Route Reflector) enthält, wird bei der Pfadauswahl die Router-ID durch die Ursprungs-ID ersetzt.
Wenn die Absender- oder Router-ID für mehrere Pfade identisch ist, wird der Pfad mit der kürzesten Clusterliste bevorzugt.
Dies ist nur in BGP-RR-Umgebungen der Fall. Es ermöglicht Clients das Peering mit RRs oder Clients in anderen Clustern. In diesem Szenario muss der Client das RR-spezifische BGP-Attribut kennen.
Bevorzugung des Pfads, der von der niedrigsten Nachbaradresse stammt.
Diese Adresse ist die IP-Adresse, die im BGP verwendet wird. neighbor
konfiguration. Die Adresse entspricht dem Remote-Peer, der in der TCP-Verbindung mit dem lokalen Router verwendet wird.
In diesem Beispiel sind 9 Pfade für das Netzwerk 10.30.116.0/23 verfügbar. Die Fehlermeldung show ip bgp network
zeigt die Einträge in der BGP-Routing-Tabelle für das jeweilige Netzwerk an.
Router R1#show ip bgp vpnv4 rd 1100:1001 10.30.116.0/23 BGP routing table entry for 1100:1001:10.30.116.0/23, version 26765275 Paths: (9 available, best #6, no table) Advertised to update-groups: 1 2 3 (65001 64955 65003) 65089, (Received from a RR-client) 172.16.254.226 (metric 20645) from 172.16.224.236 (172.16.224.236) Origin IGP, metric 0, localpref 100, valid, confed-internal Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (65008 64955 65003) 65089 172.16.254.226 (metric 20645) from 10.131.123.71 (10.131.123.71) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (65001 64955 65003) 65089 172.16.254.226 (metric 20645) from 172.16.216.253 (172.16.216.253) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (65001 64955 65003) 65089 172.16.254.226 (metric 20645) from 172.16.216.252 (172.16.216.252) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (64955 65003) 65089 172.16.254.226 (metric 20645) from 10.77.255.57 (10.77.255.57) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (64955 65003) 65089 172.16.254.226 (metric 20645) from 10.57.255.11 (10.57.255.11) Origin IGP, metric 0, localpref 100, valid, confed-external, best Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 !--- BGP selects this as the Best Path on comparing
!--- with all the other routes and selected based on lower router ID. (64955 65003) 65089 172.16.254.226 (metric 20645) from 172.16.224.253 (172.16.224.253) Origin IGP, metric 0, localpref 100, valid, confed-internal Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 (65003) 65089 172.16.254.226 (metric 20645) from 172.16.254.234 (172.16.254.234) Origin IGP, metric 0, localpref 100, valid, confed-external Extended Community: RT:1100:1001 mpls labels in/out nolabel/362 65089, (Received from a RR-client) 172.16.228.226 (metric 20645) from 172.16.228.226 (172.16.228.226) Origin IGP, metric 0, localpref 100, valid, confed-internal Extended Community: RT:1100:1001 mpls labels in/out nolabel/278
BGP wählt den besten Pfad aus diesen neun Pfaden unter Berücksichtigung der verschiedenen Attribute aus, die in diesem Dokument erläutert werden. In der hier gezeigten Ausgabe vergleicht BGP die verfügbaren Pfade und wählt Pfad 6 basierend auf seiner niedrigeren Router-ID als besten Pfad aus.
Comparing path 1 with path 2: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP The paths have different neighbor AS's so ignoring MED Both paths are internal (no distinction is made between confed-internal and confed-external) Both paths have an IGP metric to the NEXT_HOP of 20645 Path 2 is better than path 1 because it has a lower Router-ID. Comparing path 2 with path 3: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 2 is better than path 3 because it has a lower Router-ID. Comparing path 2 with path 4: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 2 is better than path 4 because it has a lower Router-ID. Comparing path 2 with path 5: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 5 is better than path 2 because it has a lower Router-ID. Comparing path 5 with path 6: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 6 is better than path 5 because it has a lower Router-ID. Comparing path 6 with path 7: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are internal (no distinction is made between confed-internal and confed-external) Both paths have an IGP metric to the NEXT_HOP of 20645 Path 6 is better than path 7 because it has a lower Router-ID. Comparing path 6 with path 8: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP Both paths have the same neighbor AS, 65089, so comparing MED. Both paths have a MED of 0 Both paths are confed-external Both paths have an IGP metric to the NEXT_HOP of 20645 Path 6 is better than path 8 because it has a lower Router-ID. Comparing path 6 with path 9: Both paths have reachable next hops Both paths have a WEIGHT of 0 Both paths have a LOCAL_PREF of 100 Both paths are learned Both paths have AS_PATH length 1 Both paths are of origin IGP The paths have different neighbor AS's so ignoring MED Both paths are internal (no distinction is made between confed-internal and confed-external) Both paths have an IGP metric to the NEXT_HOP of 20645 Path 6 is better than path 9 because it has a lower Router-ID. The best path is #6
Das erweiterte Community-Attribut, das als BGP Cost Community bezeichnet wird, bietet eine Möglichkeit, den Vorgang der Auswahl des besten Pfads anzupassen. Ein zusätzlicher Schritt, in dem Cost Communitys verglichen werden, wird dem Algorithmus hinzugefügt, der im Abschnitt Funktionsweise des Bester-Pfad-Algorithmus beschrieben wird. Dieser Schritt folgt auf den erforderlichen Schritt (Einfügepunkt) im Algorithmus. Der Pfad mit dem niedrigsten Cost-Wert wird bevorzugt.
Hinweis: Beachten Sie folgende Punkte:
- Dieser Schritt wird übersprungen, wenn Sie die bgp bestpath cost-community ignore
aus.
- Die cost community set-Klausel ist mit einer Cost-Community-ID-Nummer (0 bis 255) und einem Cost-Nummernwert (0 bis 4.294.967.295) konfiguriert. Der Wert der Cost-Nummer bestimmt die Präferenz für den Pfad. Der Pfad mit dem niedrigsten Cost-Wert wird bevorzugt. Pfaden, die nicht speziell mit dem Cost-Nummernwert konfiguriert sind, wird ein Standard-Cost-Nummernwert von 2.147.483.647 zugewiesen. Dieser Wert ist der Mittelpunkt zwischen 0 und 4.294.967.295. Diese Pfade werden dann vom Prozess für die Auswahl des besten Pfads entsprechend bewertet. Wenn zwei Pfade mit demselben Cost-Nummernwert konfiguriert sind, bevorzugt der Pfadauswahlprozess den Pfad mit der niedrigsten Community-ID. Wenn die Pfade ungleiche Pre-Bestpath Cost Communitys haben, wird der Pfad mit der niedrigeren Pre-Bestpath Cost Community als bester Pfad ausgewählt.
- Der ABSOLUTE_VALUE wird als erster Schritt betrachtet, um den Präferenzgrad eines Pfades zu bestimmen. Wenn EIGRP beispielsweise an BGP VPNv4 umverteilt wird, wird der Typ ABSOLUTE_VALUE für die Cost Community verwendet. IGB_Cost wird berücksichtigt, nachdem die interne Distanz (IGP) zum nächsten Hop verglichen wurde. Dies bedeutet, dass Cost Communitys mit dem Einfügepunkt IGP_COST nach Schritt 8 des Algorithmus in Funktionsweise des Bester-Pfad-Algorithmus berücksichtigt werden.
BGP Multipath ermöglicht die Installation mehrerer BGP-Pfade zum gleichen Ziel in der IP-Routing-Tabelle. Diese Pfade werden zusammen mit dem besten Pfad für die Lastverteilung in der Tabelle installiert. BGP Multipath hat keine Auswirkungen auf die Auswahl des besten Pfads. Ein Router weist beispielsweise einen der Pfade weiterhin gemäß dem Algorithmus als besten Pfad zu und kündigt diesen besten Pfad seinen Nachbarn an.
BGP-Multipath hat folgende Funktionen:
eBGP-Multipath: maximum-paths n
iBGP Multipath: maximum-paths ibgp n
eiBGP-Multipath - maximum-paths eibgp
Um als Multipath-Kandidat in Frage zu kommen, müssen Pfade zum gleichen Ziel folgende Eigenschaften aufweisen, die den Eigenschaften des besten Pfades entsprechen:
Gewicht
Lokale Präferenz
AS-PATH-Länge
Ursprung
MED
Eines der Folgenden:
Nachbar-AS oder Sub-AS (vor dem Hinzufügen der eiBGP-Multipath-Funktion)
AS-PATH (nach Hinzufügen der eiBGP-Multipath-Funktion)
Einige BGP-Multipath-Funktionen stellen zusätzliche Anforderungen an Multipath-Kandidaten.
Folgende zusätzlichen Anforderungen gelten für eBGP-Multipath:
Der Pfad muss von einem externen oder konföderationsexternen Nachbarn (eBGP) abgeleitet werden.
Die IGP-Metrik für den BGP Next Hop muss der IGP-Metrik mit dem besten Pfad entsprechen.
Folgende zusätzlichen Anforderungen gelten für iBGP-Multipath:
Der Pfad muss von einem internen Nachbarn (iBGP) bezogen werden.
Die IGP-Metrik für den nächsten BGP-Hop muss der IGP-Metrik mit dem besten Pfad entsprechen, es sei denn, der Router ist für iBGP-Multipath mit ungleichen Kosten konfiguriert.
BGP fügt bis zu n zuletzt empfangene Pfade von Multipath-Kandidaten in die IP-Routing-Tabelle ein. Der Höchstwert für n ist derzeit 6. Der Standardwert, wenn Multipath deaktiviert ist, ist 1.
Für den Unequal-Cost-Lastenausgleich können Sie auch BGP-Link-Bandbreite verwenden.
Hinweis: Der entsprechende Next-Hop-Self wird auf dem besten Pfad durchgeführt, der unter den eBGP-Multipfaden ausgewählt ist, bevor er an interne Peers weitergeleitet wird.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
4.0 |
11-Jul-2023 |
Aktualisierter Titel, Einführung und Formatierung.
Hintergrundinformationen hinzugefügt. |
3.0 |
22-Jun-2022 |
Auf Maschinenübersetzungsrichtlinien aktualisiert. |
1.0 |
10-Dec-2001 |
Erstveröffentlichung |