MultiExit-Diskriminator zur Beeinflussung der Auswahl des besten BGP-Pfads verwenden

Einleitung

Dieses Dokument beschreibt den Befehl bgp deterministic-med und wie er die Pfadauswahl auf Basis des Multiexit-Diskriminators (MED) beeinflusst.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Einfaches IP-Routing
• Border Gateway Protocol (BGP)

Verwendete Komponenten

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.

Konventionen

Weitere Informationen zu Dokumentationskonventionen von Cisco finden Sie unter Cisco Technical Tips Conventions.

Das MED-Attribut

MED ist ein optionales, nicht transitives BGP-Attribut, das externen Nachbarn einen Hinweis auf den bevorzugten Pfad zu einem autonomen System (AS) mit mehreren Einstiegspunkten gibt. MED wird auch als externe Metrik einer Route bezeichnet und ein niedrigerer MED-Wert wird gegenüber einem höheren Wert bevorzugt. Standardmäßig vergleicht BGP MED-Werte nur zwischen Pfaden, die von demselben benachbarten AS empfangen wurden.

Anmerkung: Standardmäßig vergleicht BGP MED-Werte nur für Pfade, die von demselben benachbarten AS empfangen werden, es sei denn, bgp always-compare-med ist konfiguriert. Weitere Informationen finden Sie unter Unterschiede zwischen dem Befehl bgp deterministic-med und dem Befehl bgp always-compare-med.

Netzwerktopologie 

Netzwerktopologie

Beispiel

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. Einige der relevanten Konfigurationen werden in diesem Abschnitt dargestellt.

!
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

!
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 relevanten R1- und R3-Konfigurationen verwenden dasselbe Design wie R2. R1, R2 und R3 sind über Loopback-Schnittstellen iBGP-erreichbar, und das IGP bietet Erreichbarkeit für BGP Next Hops. R3 hat eine eBGP-Sitzung mit R4 und iBGP-Sitzungen mit R1 und R2.

R1 hat ein iBGP, das mit R2 und einem mit R3 gleicht. Schauen Sie sich an, was die BGP-Tabellen für R1, R2 und R3 für die beiden von R4 angekündigten 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 den besten Pfad als externe Route aus R4 aus, was basierend auf dem BGP-Algorithmus zur Auswahl des besten Pfads erwartet wird. Weitere Informationen finden Sie unter BGP Best Path Selection Algorithm.

Ebenso wählt R1 R2 für den Zugriff auf die beiden Netzwerke, da die früheren BGP-Attribute für den besten Pfad übereinstimmen und die niedrigste BGP-Router-ID als Timer verwendet wird. R2 hat die Router-ID 10.2.2.2, und R3 hat die Router-ID 10.3.3.3.Da die R2s Router-ID 10.2.2.2 und die R3s Router-ID 10.3.3.3 ist, 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.

Anmerkung: Bitte beachten Sie, dass das beschriebene MED-Konfigurationsbeispiel ein Datenverkehr-Engineering nach Präfix und nicht einen echten Lastenausgleich bei gleichen Kosten beinhaltet.

Dies ist die Konfiguration von R4, nachdem Sie die erforderliche Konfiguration angewendet haben:

!
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 setMED-R3 is applying a MED of 200 to the 10.4.0.0/16 
!--- network and a MED of 100 to the 10.5.0.0/16 network. 
!--- The route-map is being applied outbound towards R3. 

! 
route-map setMED-R2 
permit 10 match ip address 1 
set metric 100 
! 
route-map setMED-R2 permit 20 
match ip address 2 
set metric 200 

!--- The route-map setMED-R2 is applying a MED of 100 to the 10.4.0.0/16 
!--- network and a MED of 200 to the 10.5.0.0/16 network. 
!--- The route-map is being applied outbound towards R2.  
! 
! 
! 
line con 0 
exec-timeout 0 0 
line aux 0 
line vty 0 4 
exec-timeout 0 0 
login 
! 
! 
end

Hinweis: In diesem Beispiel werden nur 10.4.0.0/16 und 10.5.0.0/16 angekündigt. Wenn demselben Nachbarn zusätzliche Präfixe angekündigt werden, fügen Sie sie der entsprechenden Zugriffsliste oder Routing-Map-Sequenz hinzu. Fügen Sie eine abschließende Genehmigungssequenz hinzu, wenn nicht übereinstimmende Präfixe angekündigt werden müssen, ohne durch die Outbound-Routenübersicht gefiltert zu werden.

Anmerkung: Nachdem die ausgehende Routenübersicht angewendet wurde, aktualisieren Sie die ausgehenden BGP-Updates, indem Sie den Befehl clear ip bgp * soft out ausführen. Verwenden Sie in der Produktion, wenn möglich, einen nachbarspezifischen weichen ausgehenden Datenverkehr, z. B. einen klaren IP BGP 192.168.20.2 weichen Ausgang und einen klaren IP BGP 192.168.30.3 weichen Ausgang.

Nach Anwendung von MED wählt R2 den Pfad/Link von R2 nach R4 als besten für 10.4.0.0/16 und R3 den Pfad/Link von R3 nach R4 als besten für 10.5.0.0/16. Im gezeigten konvergenten Zustand erhält R1 die zulässige beste iBGP-Anzeige für jedes Präfix und verwendet R2 für 10.4.0.0/16 und R3 für 10.5.0.0/16:

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#show 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

Siehe nächstes Beispiel für 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

R2 zeigt einen Pfad für 10.4.0.0/16 an, da R3 seinen R4-bezogenen Pfad nicht mehr ankündigt, nachdem R3 den iBGP-bezogenen Pfad durch R2 als am besten ausgewählt hat. R3 zieht das Update für 10.4.0.0/16 zurück (sendet eine BGP-Routenentziehung, dieses Update enthält eine nicht erreichbare Metrik), sobald festgestellt wird, dass R3 R2 für den Zugriff auf 10.4.0.0/16 verwendet. Die Standardregeln für iBGP-Werbung verhindern, dass R3 den vom iBGP ermittelten Pfad an einen anderen iBGP-Peer in dieser Topologie zurückgibt:

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 diese nutzlosen Informationen nicht gespeichert werden müssen. Falls die BGP-Sitzung zwischen R2 und R4 fehlschlägt, sendet R2 ein unerreichbares Update an R3 für 10.4.0.0/16. Dieses Update löst R3 aus, ein Update mit der R3-Route für 10.4.0.0/16 über R4 an R2 zu senden. R2 kann mit der Route über R3 beginnen.

Der Befehl MED

Um den deterministischen MED-Vergleich zu aktivieren, konfigurieren Sie den Befehl bgp deterministic-med im Konfigurationsmodus des BGP-Routers. Wenn bgp deterministic-med aktiviert ist, entfernt es die zeitliche Abhängigkeit von MED-basierten Best-Path-Entscheidungen, indem Pfade aus demselben AS gruppiert werden, bevor der Vergleich durchgeführt wird. Dadurch wird ein genauer MED-Vergleich über alle vom gleichen autonomen System (AS) empfangenen Routen hinweg sichergestellt.

Wenn Sie bgp deterministic-med deaktivieren, können sich die empfangenen Routen auf die MED-basierten Entscheidungen zum besten Pfad auswirken. Dies kann auftreten, wenn dieselbe Route von mehreren ASs oder Confederation Sub-ASs mit genau derselben Pfadlänge aber unterschiedlichen MEDs empfangen wird.

Beispiele

Betrachten Sie beispielsweise die folgenden Routen:

Ein BGP-Router mit deaktivierter MED

Beispiel für Ankunftsauftrag 1

Die Reihenfolge, in der die BGP-Routen empfangen wurden, ist (Eintrag1 ist der älteste Eintrag in der BGP-Tabelle und Eintrag3 der neueste):

1. Eintrag1
2. Eintrag2
3. Eintrag3

Anfangs existiert nur eine Route, sodass entry1 der beste Pfad wird. Wenn entry2 von AS65002 mit entry1 von AS65001 verglichen wird, wird MED ignoriert, da die Routen von verschiedenen benachbarten ASs stammen. Da alle verbleibenden Attribute gleich sind, behält der Router den aktuell besten Pfad, entry1, bei.

Wenn der Eintrag3 von AS65001 mit MED 20 mit dem Eintrag1 von AS65001 mit MED 100 verglichen wird, wird MED ausgewertet, da beide Routen von demselben benachbarten AS stammen. Da 20 kleiner als 100 ist, wird entry3 zum besten Pfad.

Beispiel für Ankunftsauftrag 2

Nehmen wir nun an, dieselben Routen kommen in einer anderen Reihenfolge an:

1. Eintrag2
2. Eintrag3
3. Eintrag1

Zunächst wird entry2 als bester Pfad ausgewählt. Wenn Eintrag 3 von AS65001 mit Eintrag 2 von AS65002 verglichen wird, wird MED nicht ausgewertet, da die Routen von verschiedenen benachbarten ASs stammen. Da alle verbleibenden Attribute gleich sind, behält der Router den aktuell besten Pfad, entry2, bei.

Wenn entry1 von AS65001 mit entry2 von AS65002 verglichen wird, wird MED erneut ignoriert, da die Routen von verschiedenen benachbarten ASs stammen. Daher behält der Router entry2 als den besten Pfad bei.

Bei deaktivierter MED beeinflusst die Route-Ankunftsreihenfolge die Vergleichsreihenfolge. Beachten Sie, dass der empfangene Router genau die gleichen drei Routen ist, aber er hat verschiedene beste Pfade ausgewählt, da die Routen in einer anderen Reihenfolge angekommen sind. Dies ist die zeitliche Abhängigkeit, die bgp deterministic-med eliminieren soll.

Anmerkung: Weitere Informationen zu den BGP-Pfadauswahlkriterien finden Sie unter BGP Best Path Selection Algorithm.

Ein BGP-Router mit aktivierter MED

Bei aktivierter MED-Funktion gruppiert der Router zunächst Routen nach benachbarten AS, bevor er MED-basierte Entscheidungen trifft. 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 65001 und AS 65002.

In Gruppe 1 ist der beste Pfad entry3 aufgrund der niedrigeren MED (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 bestimmt, MED wird in diesem Vergleich standardmäßig nicht verwendet, da die Gewinner jeder Gruppe aus verschiedenen ASs stammen.

Zu diesem Zeitpunkt wird MED nicht mehr berücksichtigt, da die verbleibenden Routen von verschiedenen benachbarten ASs stammen. Der BGP-Algorithmus für den besten Pfad wird mit den folgenden Attributen fortgesetzt (z. B. eBGP im Vergleich zu iBGP, IGP-Metrik für den nächsten Hop, ältester Pfad, Router-ID usw., je nachdem, welche Attribute sich unterscheiden).

Der Hauptvorteil besteht darin, dass dieser Prozess unabhängig von den empfangenen Routen ist. Legt fest, ob der Router die Routen wie folgt lernt:

• Eintrag1 → Eintrag2 → Eintrag3
• Eintrag2 → Eintrag3 → Eintrag1
• Eintrag3 → Eintrag1 → Eintrag2

Aus diesem Grund liefern Ankunftsaufträge das gleiche Ergebnis, da die Entscheidung auf den Routenattributen und nicht auf der Reihenfolge basiert, in der die Aktualisierungen empfangen wurden.

Anmerkung: Wenn bgp always-compare-med auch beim Vergleich von Eintrag 3 (Gewinner aus Gruppe 1) und Eintrag 2 (Gewinner aus Gruppe 2) aktiviert wurde; Der 3. Platz gewinnt aufgrund der unteren MED.

Anmerkung: Durch Aktivieren des Befehls bgp deterministic-med wird sichergestellt, dass die MED-Variable verglichen wird, wenn Routen ausgewählt werden, die von verschiedenen Peers im selben AS angekündigt werden. Durch Aktivieren des Befehls bgp always-compare-med wird der Vergleich der MED für Pfade von Nachbarn in verschiedenen AS sichergestellt.

In diesem Beispiel wird davon ausgegangen, dass alle BGP-Attribute mit höherer Priorität (z. B. Weight, Local Preference, AS Path length, Origin usw.) identisch sind. Der Zweck besteht darin, die Wirkung von MED zu isolieren und zu veranschaulichen, warum die Deaktivierung von bgp deterministic-med sicherstellen kann, dass die Entscheidung für den besten Pfad von der Route-Ankunftsreihenfolge abhängt.

Cisco empfiehlt die Aktivierung von bgp always-compare-med in allen neuen Netzwerkbereitstellungen. Wenn bgp always-compare-med aktiviert ist, sind BGP-MED-Entscheidungen deterministisch.

Weitere Informationen zu den Befehlen bgp deterministic-med und bgp always-compare-med finden Sie unter Unterschiede zwischen dem Befehl bgp deterministic-med und dem Befehl bgp always-compare-med.

Zugehörige Informationen

• Beispielkonfiguration für BGP mit zwei verschiedenen Service Providern (Multihoming)
• IP/BGP-Unterstützung
• BGP-Anwenderberichte
• Technischer Support und Downloads von Cisco