Inleiding
In dit document wordt het belang beschreven van het BGP-weegpad (Border Gateway Protocol) in scenario's voor failover van het netwerk.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- Border Gateway Protocol (BGP)
- herverdeling van routeringsprotocollen
- Cisco Router waarop Cisco IOS® wordt uitgevoerd
Gebruikte componenten
De informatie in dit document is gebaseerd op een Cisco Router met Cisco IOS® versie 15.6(2)
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Achtergrondinformatie
BGP wordt vaak gebruikt om de netwerkvoorvoegsels te adverteren voor het Wan Area Network (WAN) eenmaal ontvangen via een Interior Gateway-protocol (IGP) van het LAN Area Network (LAN) en vice versa. Zonder de juiste configuratie kan BGP het oorspronkelijke routeringspad via het WAN niet herstellen nadat het netwerk is hersteld van een verbindingsfout.
Routers die in failover-scenario's worden geïmplementeerd, kunnen routes vastlopen die een omleiding van het verkeer over het back-uppad na een storing en een herstelnetwerkgebeurtenis kunnen veroorzaken. Dit kan gebeuren vanwege de aard van het BGP Weight path-attribuut.
Nadat een netwerkstoring optreedt (meestal met de WAN-koppeling) kan het netwerk converteren en het beschikbare back-uppad gebruiken dat via de IGP is ontvangen.
Na herstel van het primaire pad kan de router echter nog steeds het back-uppad gebruiken en de oorspronkelijke route via de WAN-koppeling niet herstellen.
Gevolgen zoals asymmetrische en suboptimale routeringspaden zijn te zien.
In redundantiescenario's met twee WAN-routers kunnen deze BGP uitvoeren om netwerkvoorvoegsels uit te wisselen met het WAN. Een IGP zoals Enhanced Interior Gateway Routing Protocol (EIGRP) kan worden gebruikt om netwerkvoorvoegsels uit te wisselen met de LAN-netwerkapparaten. Wederzijdse herverdeling tussen deze protocollen is meestal nodig om volledige netwerkconnectiviteit te bereiken.
Opmerking: In dit document worden de termen prefix en route door elkaar gebruikt.
Het ontwerp op hoog niveau hiervan is te zien in de volgende topologie:

Eigenschap BGP-gewichtspad ingesteld in Lokaal geïnitieerde routes
Het volgende scenario beschrijft het gedrag van het BGP Weight Path attribuut in gevallen van fail-over.
Stap 1. De route wordt via BGP aangeboden.
Zoals te zien is in de afbeelding, ontvangt de router met de naam WAN RTR het 192.168.1.0/24-netwerk via BGP.
Met een administratieve afstand (AD) van 20 wordt de route geïnstalleerd in de routeringstabel.

BGP-tabel:
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
|
Routeringstabel toont de route die door BGP is geïnstalleerd:
WAN_RTR |
WAN_RTR#show ip route
<snip>
B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42
|
Stap 2. De route wordt via EIGRP ontvangen.
De BGP-sessie wordt afgebroken vanwege een storing in de link. Door netwerkconvergentie wordt dezelfde route 192.168.1.0/24 nu via EIGRP ontvangen.

Het belangrijkste punt is dat BGP kan adverteren of herdistribueren EIGRP routes (met behulp van de volgende Router configuratie). Als dat het geval is, wordt de EIGRP-route nu toegevoegd aan de BGP-tabel.
Opmerking: Het BGP-attribuut voor het gewichtspad is standaard ingesteld op 32768 wanneer de router lokaal netwerkvoorvoegsels initieert.
BGP-configuratie:
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
!
|
Opmerking: Het BGP command network 192.168.1.0 mask 255.255.255.0 kan dezelfde resultaten weergeven.
BGP-tabel:
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 ?
|
Routeringstabel toont de route die door EIGRP is geïnstalleerd:
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#
|
Stap 3. Weer een route via BGP.
Nu het EIGRP-tracé is herverdeeld in BGP en nadat het oorspronkelijke tracé opnieuw via de BGP is ontvangen, staan er nu 2 vermeldingen voor het 192.168.1.0/24-netwerk in de BGP-tabel.

BGP-tabel:
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 de BGP-tabel:
- De vermelding gecreëerd in stap 2 door de EIGRP route herverdeeld in BGP kan nog steeds worden gezien.
- De oorspronkelijke route wordt weer toegevoegd door middel van de BGP sessie opnieuw ingesteld.
Vanuit het oogpunt van de BGP beste pad selectie:
- De waarde van het attribuut Gewichtspad van de EIGRP-route die wordt herverdeeld in BGP is ingesteld op 32768, omdat deze lokaal is ontstaan in de router vanuit het oogpunt van BGP.
- De waarde van het attribuut Gewichtspad van de oorspronkelijke route die via de BGP-sessie met het WAN is ontvangen, is 0.
- De eerste route heeft het hoogste Gewicht en wordt daarom als beste gekozen in de BGP tabel.
- Hierdoor convergeert de routeringstabel niet terug naar de oorspronkelijke staat en blijft de EIGRP-routevermelding behouden.
Opmerking: Het BGP Weight Path-attribuut is het eerste pad-attribuut dat BGP controleert bij de selectie van het beste pad in de BGP-tabel op Cisco IOS Routers. BGP geeft de voorkeur aan het pad voor de intocht met het hoogste gewicht. Gewicht is een Cisco-specifieke parameter en het is alleen lokaal significant in de router waar het is geconfigureerd. Meer informatie via het BGP Best Path Selection Algorithm.
Routingtabel:
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
|
Het kenmerk BGP-gewichtspad wijzigen
De standaardwaarde van het BGP Weight path attribuut kan worden gewijzigd in de geconfigureerde per BGP peer met behulp van de opdracht gewicht of een routekaart.
Met de volgende opdrachten wordt het kenmerk Weegpad ingesteld op 40000 voor alle routes die van de BGP-peer worden ontvangen.
Voorbeeld 1
Gebruik van opdracht Gewicht |
router bgp 1
neighbor 10.1.2.2 weight 40000
|
Voorbeeld 2
Gebruik van de opdracht routekaart om het kenmerk Weegpad in te stellen |
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
|
Voorbeeld 3
Gebruik van de opdracht routekaart om het kenmerk Weegpad voor bepaalde routes in te stellen |
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
|
Met de waarde van het kenmerk Gewichtspad verhoogd, krijgen de oorspronkelijke routes die via BGP worden ontvangen voorrang, zoals te zien is in het volgende geval:
Stap 1. De route wordt via BGP aangeboden.
Uit de BGP-tabel blijkt dat routes die via BGP worden ontvangen, nu een waarde van 40000 in plaats van nul hebben.
BGP-tabel:
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#
|
Routingtabel:
WAN_RTR |
WAN_RTR#show ip route
<snip>
B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:09:53
|
Stap 2. De route wordt via EIGRP ontvangen.
Lokaal ontstane routes hebben nog steeds een waarde van 32768 in de BGP-tabel.
BGP-tabel:
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 ?
|
Routingtabel:
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
|
Stap 3. Weer een route via BGP.
Met Gewicht 40000 worden de routes die via BGP worden ontvangen, nu verkozen boven de lokaal geproduceerde routes. Dit zorgt ervoor dat het netwerk op de juiste manier terugkeert naar de oorspronkelijke staat.
BGP-tabel:
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
|
Routingtabel:
WAN_RTR |
WAN_RTR#show ip route
<snip>
B 192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:25
|
Real Case Scenario
Neem als voorbeeld het volgende scenario:
Stap 1. Oorspronkelijke netwerkstatus.

De CORE Layer 3-Switch ontvangt de 192.168.1.0/24-route via EIGRP van WAN RTR A en WAN RTR B. Het pad over WAN RTR A is geselecteerd.
De volgende uitvoer laat zien hoe de CORE-Switch een EIGRP-nabijheid behoudt met beide WAN-routers en dat WAN RTR A is gekozen om het 192.168.1.0/24-netwerk te bereiken.
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
|
Stap 2. Primaire WAN-verbindingsfout.

In het geval van een verbindingsfout installeert de CORE-Switch de route nu via het op één na beste EIGRP-pad, namelijk 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
|
Stap 3. Herstel van de primaire WAN-verbinding.

De primaire WAN-verbinding is hersteld. De CORE-Switch routeert echter nog steeds over het back-uppad, zoals te zien is op de volgende uitvoer:
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
|
De reden voor dit gedrag ligt op het BGP Weight path attribuut zoals besproken.
In de huidige toestand geeft WAN RTR A de route weer in de Roting Table via EIGRP en in de BGP-tabel die is herverdeeld vanuit EIGRP vanwege de hoogste waarde van het attribuut Weight Path wint van de waarde Weight van de route die via BGP is ontvangen van de opnieuw ingestelde WAN-link.
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
|
Het gedrag dat in dit document aan de orde komt, is in het veld breed waargenomen. Netwerktopologieën en initiële symptomen kunnen verschillen van het voorbeeld dat wordt behandeld. De onderliggende oorzaak kan echter zijn en is vaak zoals beschreven in dit document. Het is belangrijk om te controleren of de configuraties en het scenario voldoen aan de variabelen voor deze voorwaarde die zich voordoet in uw netwerkimplementatie.