Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Achtergrondinformatie

BGP-kenmerk van snijpad ingesteld op lokaal uitgaande routers

De BGP-kenmerken van het snijpad wijzigen

Real Case Scenario

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 viceversa. 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 overkoepelende ontwerp hiervan is te zien in de volgende topologie:

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 route die via de BGP zitting 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 ontstane 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 over 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 van dit gedrag ligt op de BGP-gewichtswegattributen 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 gedocumenteerde wordt besproken, is in het veld alom zichtbaar. Netwerktopologieën en eerste symptomen kunnen verschillen van het gedekte voorbeeld. De basisoorzaak kan echter zijn en wordt vaak 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.