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 die bgp deterministic-med
und erklärt, wie es die Pfadauswahl auf Basis von Multi-Exit Discriminator (MED) beeinflusst.
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 Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Weitere Informationen zu Dokumentkonventionen finden Sie in den technischen Tipps von Cisco zu Konventionen.
MED ist ein optionales nichttransitives Attribut. MED ist ein Hinweis an externe Nachbarn auf den bevorzugten Pfad zu einem autonomen System (AS), das mehrere Eintrittspunkte hat. Die MED wird auch als externe Metrik einer Route bezeichnet. Ein niedrigerer MED-Wert wird gegenüber einem höheren Wert bevorzugt.
In diesem Abschnitt wird ein Beispiel dafür beschrieben, wie Sie mit MED die Routing-Entscheidung eines benachbarten AS beeinflussen.
In diesem Szenario ist AS 65502 ein Benutzer des ISP mit AS 65501. R4 ist aus Redundanzgründen mit zwei verschiedenen Routern auf der ISP-Seite verbunden und kündigt dem ISP zwei Netzwerke an: 10.4.0.0/16 und 10.5.0.0/16. In diesem Abschnitt werden einige der relevanten Konfigurationen beschrieben.
R4 |
---|
! version 12.3 ! hostname r4 ! ip cef ! ! interface Loopback10 ip address 10.4.0.1 255.255.0.0 ! interface Loopback11 ip address 10.5.0.1 255.255.0.0 ! interface Serial0/0 ip address 192.168.20.4 255.255.255.0 ! interface Serial1/0 ip address 192.168.30.4 255.255.255.0 ! router bgp 65502 no synchronization bgp log-neighbor-changes network 10.4.0.0 mask 255.255.0.0 network 10.5.0.0 mask 255.255.0.0 neighbor 192.168.20.2 remote-as 65501 neighbor 192.168.30.3 remote-as 65501 no auto-summary ! ip classless ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 exec-timeout 0 0 login ! ! end |
R2 |
---|
! version 12.3 ! hostname r2 ! ip cef ! ! interface Loopback0 ip address 10.2.2.2 255.255.255.255 ! interface Ethernet0/0 ip address 172.16.0.2 255.255.255.0 ! interface Serial1/0 ip address 192.168.1.2 255.255.255.0 serial restart-delay 0 ! interface Serial2/0 ip address 192.168.20.2 255.255.255.0 serial restart-delay 0 ! router ospf 1 log-adjacency-changes redistribute connected passive-interface Serial2/0 network 10.2.2.2 0.0.0.0 area 0 network 172.16.0.2 0.0.0.0 area 0 network 192.168.1.2 0.0.0.0 area 0 network 192.168.20.2 0.0.0.0 area 0 ! router bgp 65501 no synchronization bgp log-neighbor-changes neighbor 10.1.1.1 remote-as 65501 neighbor 10.1.1.1 update-source Loopback0 neighbor 10.3.3.3 remote-as 65501 neighbor 10.3.3.3 update-source Loopback0 neighbor 192.168.20.4 remote-as 65502 no auto-summary ! ip classless ! ! line con 0 exec-timeout 0 0 transport preferred all transport output all line aux 0 transport preferred all transport output all line vty 0 4 exec-timeout 0 0 login transport preferred all transport input all transport output all ! end |
Die Konfigurationen von R1 und R3 ähneln denen von R2. R3 hat ein eBGP, das Peers mit R4 bildet, und ein iBGP, das Peers mit R1 bildet.
R1 hat ein iBGP, das als Peer für R2 und einer für R3 fungiert. Achten Sie darauf, was die BGP-Tabellen R1, R2 und R3 für die beiden von R4 angegebenen Netzwerke anzeigen:
r2# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 7 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.1.1.1 10.3.3.3 65502 192.168.20.4 from 192.168.20.4 (10.4.4.4) Origin IGP, metric 0, localpref 100, valid, external, best 65502 192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal r2# show ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 6 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.1.1.1 10.3.3.3 65502 192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal 65502 192.168.20.4 from 192.168.20.4 (10.4.4.4) Origin IGP, metric 0, localpref 100, valid, external, best r3# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 8 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.1.1.1 10.2.2.2 65502 192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal 65502 192.168.30.4 from 192.168.30.4 (10.4.4.4) Origin IGP, metric 0, localpref 100, valid, external, best r3# show ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 10 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.1.1.1 10.2.2.2 65502 192.168.30.4 from 192.168.30.4 (10.4.4.4) Origin IGP, metric 0, localpref 100, valid, external, best 65502 192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal r1# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 11 Paths: (2 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 65502 192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best 65502 192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal r1# show ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 10 Paths: (2 available, best #2, table Default-IP-Routing-Table) Not advertised to any peer 65502 192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal 65502 192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best
Sowohl R2 als auch R3 wählen als besten Pfad die externe Route von R4 aus, die basierend auf dem BGP-Algorithmus zur Auswahl des besten Pfads erwartet wird. Weitere Informationen finden Sie unter BGP Best Path Selection Algorithm.
Entsprechend wählt R1 R2 für den Zugriff auf die beiden Netzwerke aus. Dies entspricht der BGP-Regel für den besten Pfad: Wählen Sie den Pfad mit der niedrigsten Router-ID aus. Da die R2-Router-ID 10.2.2.2 und die R3-Router-ID 10.3.3.3 lautet, wird R2 ausgewählt. In dieser Basiskonfiguration verläuft der gesamte Datenverkehr zu den beiden Netzwerken in AS 65502 standardmäßig von R1 über R2 nach R4. Angenommen, R4 möchte den Lastenausgleich für den Datenverkehr vornehmen, der von AS 65501 empfangen wird. Um dies ohne Änderungen am R4-ISP zu tun, konfigurieren Sie R4 so, dass er MED verwendet, um den Datenverkehr für ein Netzwerk auf einem Pfad und den Datenverkehr für das andere Netzwerk auf dem anderen Pfad zu erzwingen.
Dies ist die Konfiguration von R4, nachdem Sie die erforderliche Konfiguration angewendet haben:
R4 |
---|
! version 12.3 ! hostname r4 ! ip cef ! ! ! interface Loopback10 ip address 10.4.0.1 255.255.0.0 ! interface Loopback11 ip address 10.5.0.1 255.255.0.0 ! interface Serial0/0 ip address 192.168.20.4 255.255.255.0 ! interface Serial1/0 ip address 192.168.30.4 255.255.255.0 ! router bgp 65502 no synchronization bgp log-neighbor-changes network 10.4.0.0 mask 255.255.0.0 network 10.5.0.0 mask 255.255.0.0 neighbor 192.168.20.2 remote-as 65501 neighbor 192.168.20.2 route-map setMED-R2 out neighbor 192.168.30.3 remote-as 65501 neighbor 192.168.30.3 route-map setMED-R3 out no auto-summary ! ip classless no ip http server ! ! access-list 1 permit 10.4.0.0 0.0.255.255 access-list 2 permit 10.5.0.0 0.0.255.255 ! route-map setMED-R3 permit 10 match ip address 1 set metric 200 ! route-map setMED-R3 permit 20 match ip address 2 set metric 100 !--- The route-map MED-R3 is applying a MED of 200 to the 10.4.0.0/16 |
Hinweis: Sie müssen die BGP-Sitzung mit dem clear ip bgp * soft out
, damit diese Konfigurationen aktiv werden.
R1 betrachtet die Route über R2 nun als besten Pfad für das Netzwerk 10.4.0.0/16, da das von R2 empfangene Update eine MED von 100 im Vergleich zu einer MED von 200 hat, was R3 ankündigt. Ebenso verwendet R1 R3 und den Link R3 - R4, um auf 10.5.0.0/16 zuzugreifen:
r1# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 14 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x800 Not advertised to any peer 65502 192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2) Origin IGP, metric 100, localpref 100, valid, internal, best r1#sh ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 13 Paths: (1 available, best #1, table Default-IP-Routing-Table) Flag: 0x800 Not advertised to any peer 65502 192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3) Origin IGP, metric 100, localpref 100, valid, internal, best
Schauen Sie auf das R2-Display:
r2# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 10 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 10.1.1.1 10.3.3.3 65502 192.168.20.4 from 192.168.20.4 (10.4.4.4) Origin IGP, metric 100, localpref 100, valid, external, best r2# show ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 11 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.20.4 65502 192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3) Origin IGP, metric 100, localpref 100, valid, internal, best 65502 192.168.20.4 from 192.168.20.4 (10.4.4.4) Origin IGP, metric 200, localpref 100, valid, external
Der Grund, warum R2 nur einen Pfad für 10.4.0.0/16 anzeigt, liegt darin, dass R3 das Update für 10.4.0.0/16 zurückzieht (ein Update mit einer nicht erreichbaren Metrik sendet), sobald es bemerkt, dass R3 R2 verwendet, um auf 10.4.0.0/16 zuzugreifen (nachdem Sie BGP BestPath auf allen verfügbaren Pfaden ausgeführt haben):
r3# show ip bgp 10.4.0.0 BGP routing table entry for 10.4.0.0/16, version 20 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.30.4 65502 192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2) Origin IGP, metric 100, localpref 100, valid, internal, best 65502 192.168.30.4 from 192.168.30.4 (10.4.4.4) Origin IGP, metric 200, localpref 100, valid, external
Dadurch kann R2 etwas Speicher speichern, da es diese nutzlosen Informationen nicht speichern muss. Falls die BGP-Sitzung zwischen R2 und R4 fehlschlägt, sendet R2 ein unerreichbares Update für 10.4.0.0/16 an R3. Dieses Update würde R3 veranlassen, ein Update mit der R3-Route für 10.4.0.0/16 über R4 an R2 zu senden. R2 könnte beginnen, über R3 zu routen.
Wenn Sie die bgp deterministic-med
-Befehls entfernt es jede zeitliche Abhängigkeit von MED-basierten Best Path-Entscheidungen. Es stellt sicher, dass ein genauer MED-Vergleich über alle von demselben autonomen System (AS) empfangenen Routen hinweg durchgeführt wird.
Wenn Sie bgp deterministic-med
kann die Reihenfolge, in der Routen empfangen werden, MED-basierte Entscheidungen über den besten Pfad beeinflussen. Dies kann auftreten, wenn dieselbe Route von mehreren ASs oder Confederation Sub-ASs mit genau derselben Pfadlänge aber unterschiedlichen MEDs empfangen wird.
Betrachten Sie beispielsweise die folgenden Routen:
entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10 entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5 entry3: ASPATH 1, MED 200, external
Die Reihenfolge, in der die BGP-Routen empfangen wurden, ist entry3, entry2 und entry1 (entry3 ist der älteste Eintrag in der BGP-Tabelle und entry1 der neueste).
Ein BGP-Router mit bgp deterministic-med
disabled (Deaktiviert) wählt entry2 gegenüber entry1 aus, da eine niedrigere IGP-Metrik den NEXT_HOP erreicht (MED wurde in dieser Entscheidung nicht verwendet, da entry1 und entry2 von zwei verschiedenen ASs stammen). Es bevorzugt dann entry3 gegenüber entry2, da es extern ist. Eintrag3 hat jedoch eine höhere MED als Eintrag1. Weitere Informationen zu den BGP-Pfadauswahlkriterien finden Sie unter BGP Best Path Selection Algorithm .
In diesem Fall werden Routen vom gleichen AS gruppiert, und die besten Einträge jeder Gruppe werden verglichen. Im vorliegenden Beispiel gibt es zwei AS, AS 1 und AS 2.
Group 1: entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10 entry3: ASPATH 1, MED 200, external Group 2: entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5
In Gruppe 1 ist der beste Pfad entry1, da der untere MED-Wert verwendet wird (MED wird in dieser Entscheidung verwendet, da die Pfade vom gleichen AS stammen). In Gruppe 2 gibt es nur einen Eintrag (Eintrag2). Der beste Pfad wird dann mit einem Vergleich der Gewinner jeder Gruppe ermittelt (MED wird in diesem Vergleich standardmäßig nicht verwendet, da die Gewinner jeder Gruppe aus verschiedenen ASs stammen. Wenn Sie bgp always-compare-med
Dadurch wird dieses Standardverhalten geändert). Wenn Sie jetzt Eintrag1 (Gewinner aus Gruppe 1) und Eintrag2 (Gewinner aus Gruppe 2) vergleichen, kann Eintrag2 der Gewinner sein, da er die bessere IGP-Metrik für den nächsten Hop aufweist.
Wenn bgp always-compare-med
wurde auch aktiviert, wenn Sie Eintrag 1 (der Gewinner aus Gruppe 1) und Eintrag 2 (der Gewinner aus Gruppe 2) vergleichen, kann Eintrag 1 aufgrund der niedrigeren MED der Gewinner sein.
Cisco empfiehlt die Aktivierung bgp always-compare-med
in allen neuen Netzwerkbereitstellungen. Wenn darüber hinaus bgp always-compare-med
ist aktiviert, sind BGP MED-Entscheidungen immer deterministisch.
Weitere Informationen über die bgp deterministic-med
und bgp always-compare-med
-Befehlen, siehe Wie sich der Befehl bgp deterministic-med vom Befehl bgp always-compare-med unterscheidet.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
26-Jan-2024 |
SEO und Formatierung aktualisiert. |
1.0 |
10-Dec-2001 |
Erstveröffentlichung |