Einleitung
In diesem Dokument wird die Bedeutung des Border Gateway Protocol (BGP)-Gewichtspfadattributs in Netzwerk-Failover-Szenarien beschrieben.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
- Border Gateway Protocol (BGP)
- Neuverteilung von Routing-Protokollen
- Cisco Router mit Cisco IOS®
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf einem Cisco Router mit Cisco IOS® Version 15.6(2)
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
BGP wird in der Regel verwendet, um Netzwerkpräfixe an das WAN (WAN) weiterzuleiten, sobald diese über ein Interior Gateway Protocol (IGP) vom LAN (LAN) empfangen wurden und umgekehrt. Ohne die richtige Konfiguration kann das BGP den ursprünglichen Routing-Pfad über das WAN nach einem Verbindungsausfall nicht wiederherstellen.
Bei Routern, die in Failover-Szenarien bereitgestellt werden, können Routen blockiert sein, was eine Umleitung des Datenverkehrs über den Backup-Pfad nach einem Ausfall und einer Wiederherstellung des Netzwerks zur Folge haben kann. Dies kann aufgrund der Art des BGP-Gewichtspfadattributs geschehen.
Nach einem Netzwerkausfall (in der Regel über die WAN-Verbindung) kann das Netzwerk konvergiert werden und den verfügbaren Backup-Pfad nutzen, der über das IGP empfangen wird.
Nach der Wiederherstellung des primären Pfads kann der Router jedoch weiterhin den Backup-Pfad verwenden und nicht die ursprüngliche Route über die WAN-Verbindung wiederherstellen.
Es sind Folgen wie asymmetrische und suboptimale Routing-Pfade erkennbar.
In Redundanzszenarien mit zwei WAN-Routern können diese BGP ausführen, um Netzwerkpräfixe mit dem WAN auszutauschen. Ein IGP wie Enhanced Interior Gateway Routing Protocol (EIGRP) kann zum Austausch von Netzwerkpräfixen mit den LAN-Netzwerkgeräten verwendet werden. Eine gegenseitige Neuverteilung zwischen diesen Protokollen ist in der Regel erforderlich, um eine vollständige Netzwerkanbindung zu erreichen.
Hinweis: In diesem Dokument werden die Begriffe "Präfix" und "Route" synonym verwendet.
Das übergeordnete Design ist in der nächsten Topologie zu sehen:
BGP-Gewichtspfadattribut in lokal erzeugten Routen festgelegt
Im nächsten Szenario wird das Verhalten des BGP-Gewichtspfadattributs bei Failover-Fällen beschrieben.
Schritt 1: Die Route wird über das BGP empfangen.
Wie im Bild gezeigt, empfängt der Router mit dem Namen WAN RTR das Netzwerk 192.168.1.0/24 über BGP.
Bei einer administrativen Distanz (AD) von 20 wird die Route in der Routing-Tabelle installiert.
BGP-Tabelle:
WAN_RTR |
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.2.2 0 0 2 i
|
Die Routing-Tabelle zeigt die vom BGP installierte Route:
WAN_RTR |
WAN_RTR#show ip route
<snip>
B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42
|
Schritt 2: Die Route wird über EIGRP empfangen.
Die BGP-Sitzung fällt aufgrund eines Verbindungsfehlers aus. Durch Netzwerkkonvergenz wird nun die gleiche Route wie 192.168.1.0/24 über EIGRP empfangen.
Der springende Punkt hierbei ist, dass das BGP EIGRP-Routen ankündigen oder neu verteilen kann (mithilfe der nächsten Routerkonfiguration). In diesem Fall wird die EIGRP-Route der BGP-Tabelle hinzugefügt.
Hinweis: Das BGP-Gewichtspfadattribut ist standardmäßig auf 32768 festgelegt, wenn der Router lokal Netzwerkpräfixe generiert.
BGP-Konfiguration:
WAN_RTR |
WAN_RTR#show running-config | begin router bgp
<snip> router bgp 1
redistribute eigrp 1
neighbor 10.1.2.2 remote-as 2
! |
Hinweis: Die Maske 255.255.255.255.0 des BGP-Befehls network 192.168.1.0 kann die gleichen Ergebnisse anzeigen.
BGP-Tabelle:
WAN_RTR |
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.3.3 156160 32768 ?
|
Die Routing-Tabelle zeigt die vom EIGRP installierte Route:
WAN_RTR |
WAN_RTR#show ip route
<snip>
D 192.168.1.0/24 [90/156160] via 10.1.3.3, 00:00:02, FastEthernet0/1
WAN_RTR# |
Schritt 3: Route über BGP erneut empfangen
Da die EIGRP-Route jetzt in das BGP umverteilt wird und nachdem die ursprüngliche Route erneut über das BGP empfangen wurde, befinden sich jetzt 2 Einträge für das Netzwerk 192.168.1.0/24 in der BGP-Tabelle.
BGP-Tabelle:
WAN_RTR |
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.1.2.2 0 0 2 i
*> 10.1.3.3 156160 32768 ?
|
In der BGP-Tabelle:
- Der in Schritt 2 durch die Umverteilung der EIGRP-Route zum BGP erstellte Eintrag wird weiterhin angezeigt.
- Die ursprüngliche Route wird mithilfe der wiederhergestellten BGP-Sitzung wieder hinzugefügt.
Hinsichtlich der Auswahl des besten BGP-Pfads:
- Der Wert des Gewichtungspfadattributs der EIGRP-Route, die in das BGP umverteilt wird, wird auf 32768 festgelegt, da sie vom BGP-Standpunkt aus lokal vom Router stammt.
- Der Wert des Gewichtungspfadattributs der ursprünglichen Route, die über die BGP-Sitzung mit dem WAN empfangen wurde, ist 0.
- Die erste Route hat das höchste Gewicht und wird daher in der BGP-Tabelle als beste Route ausgewählt.
- Dies führt dazu, dass die Routing-Tabelle nicht wieder in den ursprünglichen Zustand konvergiert und der EIGRP-Routeneintrag beibehalten wird.
Hinweis: Das BGP Weight Path-Attribut ist das erste Pfadattribut, das BGP bei der Auswahl des besten Pfads in der BGP-Tabelle für Cisco IOS-Router prüft. BGP bevorzugt den Pfad für den Eintrag mit der höchsten Gewichtung. Das Gewicht ist ein Cisco spezifischer Parameter und nur auf dem Router, für den es konfiguriert wurde, lokal von Bedeutung. Weitere Informationen finden Sie über den BGP Best Path Selection Algorithm.
Routingtabelle:
WAN_RTR |
WAN_RTR#show ip route
<snip>
D 192.168.1.0/24 [90/156160] via 10.1.3.3, 00:08:55, FastEthernet0/1
|
Ändern des BGP-Gewichtspfadattributs
Der Standardwert des BGP Weight-Pfadattributs kann in der Konfiguration pro BGP-Peer mithilfe des Befehls weight oder einer Routing-Map geändert werden.
Mit den nächsten Befehlen wird das Weight path-Attribut für alle vom BGP-Peer empfangenen Routen auf 40000 festgelegt.
Beispiel 1
Verwendung des Befehls weight |
router bgp 1
neighbor 10.1.2.2 weight 40000 |
Beispiel 2
Verwenden des Befehls route-map zum Festlegen des Attributs "Weigh Path" |
route-map FROM-WAN permit 10
set weight 40000
!
router bgp 1
neighbor 10.1.2.2 route-map FROM-WAN in
!
clear ip bgp * soft in |
Beispiel 3
Verwenden des Befehls route-map, um das Weigh Path-Attribut für bestimmte Routen festzulegen |
ip prefix-list NETWORKS permit 192.168.1.0/24
!
route-map FROM-WAN permit 10
match ip address prefix NETWORKS
set weight 40000
route-map FROM-WAN permit 100
!
router bgp 1
neighbor 10.1.2.2 route-map FROM-WAN in
!
clear ip bgp * soft in |
Mit zunehmendem Wert des Weight-Pfadattributs haben die über BGP empfangenen ursprünglichen Routen Vorrang, wie im nächsten Fall gezeigt:
Schritt 1: Die Route wird über das BGP empfangen.
Die BGP-Tabelle zeigt, dass Routen, die über BGP empfangen werden, nun einen Gewichtungswert von 40000 anstatt von 0 aufweisen.
BGP-Tabelle:
WAN_RTR |
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.2.2 0 40000 2 i
WAN_RTR# |
Routingtabelle:
WAN_RTR |
WAN_RTR#show ip route
<snip>
B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:09:53
|
Schritt 2: Die Route wird über EIGRP empfangen.
Die BGP-Tabelle enthält weiterhin Routen vom lokalen Ursprung mit dem Wert 32768.
BGP-Tabelle:
WAN_RTR |
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.3.3 156160 32768 ?
|
Routingtabelle:
WAN_RTR |
WAN_RTR#show ip route
<snip>
D 192.168.1.0/24 [90/156160] via 10.1.3.3, 00:01:41, FastEthernet0/1
|
Schritt 3: Route über BGP erneut empfangen
Mit Weight 40000 werden die über BGP empfangenen Routen von nun an von den lokalen Routen vorgezogen. Dadurch wird das Netzwerk wieder in seinen ursprünglichen Zustand zurückversetzt.
BGP-Tabelle:
WAN_RTR |
WAN_RTR#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
*> 192.168.1.0 10.1.2.2 0 40000 2 i
|
Routingtabelle:
WAN_RTR |
WAN_RTR#show ip route
<snip>
B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:25
|
Fallbeispiel
Nehmen wir als Beispiel das nächste Szenario:
Schritt 1: Ursprünglicher Netzwerkstatus.
Der Layer-3-Core-Switch empfängt die Route 192.168.1.0/24 über EIGRP von WAN RTR A und WAN RTR B. Der Pfad über WAN RTR A wird ausgewählt.
Die nächste Ausgabe zeigt, wie der CORE-Switch eine EIGRP-Adjacency mit beiden WAN-Routern aufrechterhält und dass WAN RTR A so ausgewählt ist, dass es das Netzwerk 192.168.1.0/24 erreicht.
KERN |
CORE#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.2.2 (WAN_RTR_A) Fa0/0 10 00:05:15 79 1066 0 10
1 10.1.3.3 (WAN_RTR_B) Fa0/1 12 00:06:22 76 456 0 5
CORE#show ip route
<snip>
D EX 192.168.1.0/24 [170/28416] via 10.1.2.2, 00:00:32, FastEthernet0/0
CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.2.2 (28416/2816), FastEthernet0/0
via 10.1.3.3 (281856/2816), FastEthernet0/1 |
Schritt 2: Ausfall der primären WAN-Verbindung.
Bei einem Verbindungsausfall installiert der CORE-Switch nun die Route über den zweitbesten EIGRP-Pfad, nämlich WAN RTR B.
KERN |
CORE#show ip route
<snip>
D EX 192.168.1.0/24 [170/281856] via 10.1.3.3, 00:00:05, FastEthernet0/1
CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.3.3 (281856/2816), FastEthernet0/1 |
Schritt 3: Wiederherstellung der primären WAN-Verbindung.
Die primäre WAN-Verbindung wurde wiederhergestellt. Der CORE-Switch routet jedoch weiterhin über den Backup-Pfad, wie an der nächsten Ausgabe erkennbar:
KERN |
CORE#show ip route
<snip>
D EX 192.168.1.0/24 [170/281856] via 10.1.3.3, 00:06:09, FastEthernet0/1
CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
via 10.1.3.3 (281856/2816), FastEthernet0/1 |
Der Grund für dieses Verhalten liegt, wie bereits erwähnt, im BGP-Gewichtspfadattribut.
Im aktuellen Zustand zeigt WAN RTR A die Route in der Routing-Tabelle über EIGRP und in der BGP-Tabelle, die vom EIGRP umverteilt wurde, weil der höchste Wert des Gewichtungspfadattributs den Gewichtungswert der Route übertrifft, die vom neu eingerichteten WAN-Link über das BGP empfangen wurde.
WAN_RTR_A |
WAN_RTR_A#show ip bgp
<snip>
Network Next Hop Metric LocPrf Weight Path
* 192.168.1.0 10.2.4.4 0 0 4 i
*> 10.1.2.1 284416 32768 ?
WAN_RTR_A#show ip bgp summary
BGP router identifier 10.20.20.20, local AS number 2
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.2.4.4 4 4 12 12 16 0 0 00:03:54 (UP) 4
WAN_RTR_A#show ip route
<snip>
D EX 192.168.1.0/24 [170/284416] via 10.1.2.1, 00:08:22, FastEthernet0/0
|
Das in diesem Dokument behandelte Verhalten ist in diesem Bereich weithin bekannt. Netzwerktopologien und erste Symptome können sich von den beschriebenen Beispielen unterscheiden. Die Ursache kann jedoch in vielen Fällen wie in diesem Dokument beschrieben sein. Es ist wichtig zu überprüfen, ob die Konfigurationen und das Szenario die Variablen erfüllen, damit diese Bedingung in Ihrer Netzwerkbereitstellung auftritt.