Verständnis der Bedeutung des BGP-Gewichtspfadattributs

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

router bgp 1
 neighbor 10.1.2.2 weight 40000

Beispiel 2

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

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#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#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#show ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.3.3            156160         32768 ?

Routingtabelle:

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

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.

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:

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