Verständnis der Bedeutung des BGP-Gewichtungsattributs

Einleitung

In diesem Dokument wird die Bedeutung des Border Gateway Protocol (BGP) Weight-Attributs für 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 IOS-Befehlszeilenschnittstelle (CLI)

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 Wide Area Network (WAN) weiterzuleiten, sobald diese über ein Interior Gateway Protocol (IGP) vom Local Area Network (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 Fehler 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-ähnliches Enhanced Interior Gateway Routing Protocol (EIGRP) kann für den Austausch von Netzwerkpräfixen mit LAN-Netzwerkgeräten verwendet werden. In der hier beschriebenen Topologie werden BGP-Routen in EIGRP umverteilt, und eine EIGRP-Route wird auf dem WAN-Router in BGP umverteilt, um eine vollständige Netzwerkkonnektivität zu erreichen. In diesen Szenarien ist eine geeignete Routenfilterung oder ein Tagging erforderlich, um zu verhindern, dass Routen zwischen den Protokollen zurückgespeist werden.

Anmerkung: In diesem Dokument werden die Begriffe "Präfix" und "Route" synonym verwendet.

Das übergeordnete Design ist in der nächsten Topologie zu sehen:

BGP-Gewichtungsattribut in lokal erzeugten Routen festgelegt

Im nächsten Szenario wird das Verhalten des BGP Weight-Attributs bei einem Failover beschrieben.

1. Route wird über 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 Administrative Distance (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

Diese 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

2. Route wird über EIGRP empfangen

Die BGP-Sitzung ist aufgrund eines Verbindungsfehlers nicht mehr verfügbar. Durch Netzwerkkonvergenz wird nun die gleiche Route wie 192.168.1.0/24 über EIGRP empfangen.

Der Befehl redistribute eigrp generiert zulässige EIGRP-Routen im BGP. Daher wird die EIGRP-Route in der lokalen BGP-Tabelle angezeigt.

Anmerkung: Das BGP-Gewicht ist standardmäßig auf 32768 festgelegt, wenn der Router lokal von Netzwerkpräfixen stammt.

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
!

Anmerkung: Das BGP-Befehlsnetzwerk 192.168.1.0 kann dieses Präfix auch mit der Maske 255.255.255.0 generieren, während in der IP-Routing-Tabelle eine exakt übereinstimmende Route vorhanden ist.

 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 ?

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

3. Route über BGP empfangen (wieder)

Da die EIGRP-Route jetzt in das BGP umverteilt wird und nachdem die ursprüngliche Route erneut über das BGP empfangen wurde, enthält die BGP-Tabelle nun 2 Einträge für das Netzwerk 192.168.1.0/24.

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 erstellte Eintrag, der von der in das BGP umverteilten EIGRP-Route stammt, wird weiterhin angezeigt.
• Die ursprüngliche Route wird nach der Wiederherstellung der BGP-Sitzung wieder hinzugefügt.

Hinsichtlich der Auswahl des besten BGP-Pfads:

• Der Wert für das BGP-Gewicht der in das BGP umverteilten EIGRP-Route wird auf 32768 festgelegt, da es vom BGP-Standpunkt aus lokal im Router stammt.
• Der Wert für das BGP-Gewicht der ursprünglichen Route, die über die BGP-Sitzung mit dem WAN empfangen wurde, ist 0.
• Die EIGRP-Route, die zum BGP umverteilt wird, hat eine höhere Gewichtung und wird als bester Pfad in der BGP-Tabelle ausgewählt.
• Da das BGP den lokal erzeugten Pfad als besten Pfad auswählt, ersetzt der wiederhergestellte, vom WAN bezogene Pfad die EIGRP-Route in der Routing-Tabelle nicht.

Anmerkung: Das lokale BGP-Gewichtungsattribut ist der erste BGP-Parameter, der bei der Auswahl des besten Pfads in der BGP-Tabelle für Cisco IOS® Router geprüft wird. 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, auf dem es konfiguriert wurde, lokal von Bedeutung. Weitere Informationen finden Sie im Dokument 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-Gewichts kann mithilfe des Befehls weight oder route-map pro BGP-Peer 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

Anmerkung: Die endgültige Genehmigungssequenz in der Route-Map FROM-WAN akzeptiert andere Routen vom Peer, ohne ihnen die Gewichtung 40000 zuzuweisen.

Anmerkung: Der Platzhalter in clear ip bgp * soft in aktualisiert eingehende Routen von allen BGP-Peers. Führen Sie den Befehl clear ip bgp <ip-address> soft in aus, um nur den in diesen Beispielen verwendeten Peer zu aktualisieren.

Mit zunehmendem Wert des Weight-Pfadattributs haben die über BGP empfangenen ursprünglichen Routen Vorrang, wie im nächsten Fall gezeigt:

Schritt 1: Route wird über BGP empfangen

Die nächste BGP-Tabelle zeigt, dass Routen, die über das 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: 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 empfangen (erneut)

Bei einem Gewicht von 40000 wird die über BGP empfangene Route über die lokal erstellte Route ausgewählt. Nachdem die WAN-Route die EIGRP-Route in der Routing-Tabelle ersetzt hat, wird das Netzwerk wieder in seinen ursprünglichen Zustand versetzt.

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

Failover-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 WAN-Routern aufrechterhält und WAN RTR A so ausgewählt wird, dass er 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: Primärer WAN-Verbindungsausfall

Bei einem Verbindungsausfall installiert der CORE-Switch 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 in der nächsten Ausgabe zu sehen ist:

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 ist, wie bereits erwähnt, das BGP Weight-Attribut.

Im aktuellen Zustand installiert WAN RTR A die EIGRP-Route in der Routing-Tabelle. In der BGP-Tabelle hat die vom EIGRP neu verteilte Route eine höhere Gewichtung als die über die wiederhergestellte WAN-Verbindung empfangene Route und bleibt der beste Pfad.

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

Dieses Verhalten kann auftreten, wenn ein WAN-Router eine IGP-Backup-Route über das BGP verteilt und die Route, die lokal gestartet wurde, eine höhere Gewichtung hat als die wiederhergestellte, vom WAN übernommene Route. Netzwerktopologien und erste Symptome können von diesem Beispiel abweichen. Überprüfen Sie die Neuverteilungskonfiguration, die BGP-Gewichtungen und die ausgewählten Routen, bevor Sie persistentes Backup-Pfad-Routing auf diese Bedingung zurückführen.