Inleiding
Dit document beschrijft het belang van BGP-weegpadattributen (Border Gateway Protocol) in scenario's voor netwerkfailover.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan:
- BGP-protocol (border gateway protocol)
- Herdistributie van routingprotocollen
- 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 algemeen gebruikt om de netwerkprefixes te adverteren naar het WAN Area Network (WAN) wanneer deze eenmaal zijn ontvangen via een Interior Gateway Protocol (IGP) van het LAN Area Network (LAN) en vice versa. Zonder de juiste configuratie op zijn plaats, kan BGP er niet in slagen om de originele routeringspad over WAN te herstellen nadat het netwerk van een verbindingsmislukking terugkrijgt.
Routers die in failover-scenario's worden ingezet kunnen nog steeds routes hebben die ervoor kunnen zorgen dat het verkeer over de back-uppad wordt omgeleid na een storing en herstel netwerkgebeurtenis. Dit kan gebeuren vanwege de aard van het BGP-kenmerk van het snijpad.
Na een netwerkfout (meestal met de WAN-link) kan het netwerk samenkomen en de beschikbare back-uppad gebruiken die via de IGP wordt ontvangen.
Bij herstel van het primaire pad kan de router echter nog steeds het back-uppad gebruiken en de oorspronkelijke route niet via de WAN-link herstellen.
De gevolgen zoals asymmetrische en sub-optimale het verpletteren wegen kunnen worden gezien.
In redundantiescenario's met twee WAN-routers kunnen deze BGP uitvoeren om netwerkprefixes met WAN uit te wisselen. Een IGP zoals Enhanced Interior Gateway Routing Protocol (EIGRP) kan worden gebruikt om netwerkprefixes uit te wisselen met de LAN-netwerkapparaten. Wederzijdse herverdeling tussen deze protocollen is doorgaans nodig om de volledige netwerkconnectiviteit te realiseren.
Opmerking: in dit document worden de termen prefix en route door elkaar gebruikt.
Het hoogstaande ontwerp van dit kan in de volgende topologie worden gezien:
BGP-kenmerk van snijpad ingesteld op lokaal uitgaande routers
In het volgende scenario wordt beschreven hoe het BGP-kenmerk Weight Path tijdens een foutenprocedure werkt.
Stap 1. De route wordt ontvangen via BGP.
Zoals in de afbeelding wordt getoond, 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 Routing Table.
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
|
Routing Table toont de route die geïnstalleerd is door BGP:
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 ontvangen via EIGRP.
De BGP-sessie gaat omlaag vanwege koppelingsfout. Door netwerkconvergentie, wordt de zelfde route 192.168.1.0/24 nu ontvangen via EIGRP.
Het belangrijkste punt is dat BGP EIGRP-routes kan adverteren of herverdelen (met behulp van de volgende routerconfiguratie). Als dat het geval is, wordt de EIGRP-route nu toegevoegd aan de BGP-tabel.
Opmerking: het BGP-kenmerk Gewichtspad is standaard ingesteld op 32768 wanneer de router lokaal netwerkprefixes genereert.
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-opdrachtnetwerk 192.168.1.0 masker 255.255.255.0 kan dezelfde resultaten laten zien.
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 ?
|
Routing Table toont de route die door EIGRP geïnstalleerd is:
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. Opnieuw ontvangen route via BGP.
Met de route EIGRP nu opnieuw verdeeld in BGP en nadat de originele route opnieuw via BGP wordt ontvangen, zijn er nu 2 ingangen voor het 192.168.1.0/24 netwerk in de BGP lijst.
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 die in stap 2 wordt gemaakt door de EIGRP-route die in BGP is herverdeeld, kan nog steeds worden gezien.
- De oorspronkelijke route wordt weer toegevoegd door middel van de BGP-sessie opnieuw ingesteld.
Vanuit het BGP-oogpunt van beste padselectie:
- De waarde van het attribuut van de Weg van de route EIGRP die in BGP wordt herverdeeld wordt geplaatst aan 32768 aangezien het plaatselijk in de router van het standpunt BGP voortgekomen is.
- De waarde van het attribuut van het Gewicht van de originele die route via de zitting BGP met WAN wordt ontvangen is 0.
- De eerste route heeft het hoogste gewicht en wordt daarom gekozen als beste in de BGP-tabel.
- Dit veroorzaakt de Routing Table niet om terug naar de originele staat te convergeren en de EIGRP routeingang te houden.
Opmerking: het BGP-kenmerk Gewichtspad is het eerste padkenmerk BGP-controles bij de selectie van het beste pad in de BGP-tabel op Cisco IOS-routers. BGP geeft de voorkeur aan het pad voor de vermelding met het hoogste gewicht. Gewicht is een Cisco-specifieke parameter en is alleen lokaal belangrijk in de router waarin deze is geconfigureerd. Meer informatie via het BGP-algoritme voor de beste padselectie.
Routing-tabel:
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
|
De BGP-kenmerken van het snijpad wijzigen
De standaardwaarde van het BGP-gewichtspadkenmerk kan worden gewijzigd in de ingestelde waarde per BGP-peer met behulp van de opdracht Gewicht of een routekaart.
Met de volgende opdrachten wordt het kenmerk Gewichtspad ingesteld op 40000 voor alle routes die van de BGP-peer worden ontvangen.
Voorbeeld 1
Gebruik van de opdracht gewicht |
router bgp 1
neighbor 10.1.2.2 weight 40000 |
Voorbeeld 2
Gebruik van routekaart-opdracht om de eigenschap Weg Path 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 routekaart-opdracht om de eigenschap Weg Pad 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 de attributen van het Gewicht verhoogd, nemen de originele die routes via BGP worden ontvangen voorrang zoals die in het volgende geval wordt gezien:
Stap 1. De route wordt ontvangen via BGP.
BGP-tabel toont aan dat via BGP ontvangen routes nu een gewichtswaarde van 40000 hebben in plaats van nul.
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# |
Routing-tabel:
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 ontvangen via EIGRP.
Lokaal geïnitieerde 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 ?
|
Routing-tabel:
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. Opnieuw ontvangen route via BGP.
Met Weight 40000 worden de routes die via BGP worden ontvangen nu gekozen over de lokaal gecreëerde routes. Hierdoor komt het netwerk weer goed samen in 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
|
Routing-tabel:
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 via WAN RTR A wordt geselecteerd.
De volgende output toont hoe de Switch van de KERN een nabijheid EIGRP met zowel WAN Routers handhaaft als dat WAN RTR A wordt verkozen om het netwerk te bereiken 192.168.1.0/24.
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-koppelingsfout.
In het geval van een koppelingsfout installeert de CORE Switch nu de route via de op een na beste EIGRP-pad dat WAN RTR B is.
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-link.
De primaire WAN-link 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 de BGP Gewichtspad attributen zoals is besproken.
In de huidige staat, WAN RTR A toont de route in de Draaiende Lijst via EIGRP en in de BGP lijst die van EIGRP wegens de hoogste waarde van de attributen van de Weg opnieuw wordt verdeeld wint over de waarde van het Gewicht van de route die via BGP van de opnieuw gevestigde verbinding van WAN wordt ontvangen.
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 alom zichtbaar. Netwerktopologieën en eerste symptomen kunnen verschillen van het gedekte voorbeeld. De basisoorzaak kan echter zijn en is vaak zoals beschreven in dit document. Het is belangrijk om te verifiëren of de configuraties en het scenario voldoen aan de variabelen voor deze voorwaarde om in uw netwerkplaatsing te voorkomen.