Probleemoplossing voor eBGP-sessie die vaststaat in actieve staat

Inleiding

Dit document beschrijft hoe u problemen kunt oplossen met eBGP (External Border Gateway Protocol) wanneer de sessie in actieve status is vastgelopen als gevolg van onjuiste LPTS-vermeldingen (Local Packet Transport Services).

Bijgedragen door William Xu, Cisco TAC Engineer.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• BGP
• TCP
• LPTS voor IOS XR

Gebruikte componenten

De informatie in dit document is gebaseerd op ASR 9000 (Aggregation Services Router)-platforms.

De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, zorg er dan voor dat u de mogelijke impact van opdrachten begrijpt.

Probleem

Wanneer u eBGP configureert, kan de sessie voor onbepaalde tijd actief blijven als:

• Er is geen update-source opdracht geconfigureerd
• Er is een topologieverandering die verkeer veroorzaakt om een verschillende weg te nemen

Deze symptomen treden op als dit probleem zich voordoet:

• IP-adressen zijn bereikbaar
• Beide BGP-peers blijven actief
• Packet Capture toont aan dat de routers veel TCP-resets verzenden
• toon TCP-overtrek fout geeft deze fout aan voor BGP-sessies.

Feb 18 09:32:15.393 tcp/error 0/RSP0/CPU0 t9  Lpts set the drop flag for 179 -> 5368, drop packet (pak 0xb1cf80f3) and send a RST

Samengevat is de oorzaak van het probleem dat LPTS-vermeldingen niet worden bijgewerkt door de wijziging van routing en doorsturen. Het betekent dat ze in een stabiele toestand blijven nadat de topologie verandert.

Er zijn een aantal verbeteringen voor BGP uitgevoerd. In deze twee scenario's wordt nader op deze kwestie ingegaan.

Opmerking: iBGP (Internal Border Gateway Protocol) raakt dit probleem normaal gesproken niet, omdat updatebron altijd wordt gebruikt.

Scenario 1 - Multihop EBGP met verandering van topologie

U kunt een multihop eBGP-sessies tussen ASR9K-1 en ASR9K-3 bouwen. De peer IP-adressen zijn 172.123.1.1 en 172.123.2.2 op de fysieke interfaces. Er is geen update-source commando geconfigureerd. Met de huidige topologie blijft de sessie in de actieve staat. Dit wordt verwacht omdat beide routers de interface in subnetnummer 172.123.3.0/24 als uitgaande interface zullen gebruiken.

U kunt de directe link tussen ASR9K-1 en ASR9K-3 afsluiten. Dan, zijn de peer adressen bereikbaar via ASR9K-2 die de multihop link is, dus ping is succesvol. De IP-adressen van de bron komen aan beide uiteinden overeen, maar de BGP-sessie is nog actief.

Wanneer de BGP-buren zijn geconfigureerd, worden LPTS-vermeldingen gemaakt volgens de CEF-tabel (Cisco Express Forwarding). Voor ASR9K-1 is IP-adres 172.123.2.2 bereikbaar via 172.123.3.0/24 subnetwerkkaart. Daarom zijn de desbetreffende vermeldingen in het LPTS beschikbaar. Hiermee kan BGP-buur poort 179 verbinden met lokaal IP-adres 172.123.3.1. Aangezien het probeert om een TCP sessie te starten vanaf een lokale 26036, kunt u er een andere ingang voor zien.

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.2.2
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,26036 172.123.2.2,179

Deze output is hetzelfde in de ASR9K-3.

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,11126 172.123.1.1,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.1.1

Wanneer de koppeling tussen ASR9K-1 en ASR9K-3 vervalt, zijn de peers bereikbaar via ASR9K-2 pad met een nieuw lokaal IP-bronadres. Maar de topologieverandering leidt niet tot de LPTS-update. De originele vermelding met poort 179 blijft bij het oorspronkelijke lokale IP-adres. Dit verhindert de router om toegang TCP verzoeken aan het nieuwe lokale IP adres toe te staan. Daarom blijft de BGP-sessie aan beide uiteinden in een actieve staat steken.

Scenario 2 - eBGP met wijziging van updatebronadres

U kunt een eBGP-sessie tussen ASR9K-1 en ASR9K-3 implementeren. De IP-adressen zijn 172.123.3.1 en 172.123.3.2. In het nieuwe plan hebt u de IP-adressen gewijzigd in 172.123.3.111 en 172.123.3.222. Als u eerst eBGP configureert en vervolgens de IP-adressen op de interfaces bijwerkt, zit de EBGP-sessie in een actieve staat.

De oorzaak is hetzelfde als scenario 1. Zodra u de eBGP-sessie configureert, worden de LPTS-vermeldingen op dat punt gegenereerd volgens de lokale uitgangsinterface.

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.3.222
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,24067 172.123.3.222,179

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,45091 172.123.3.111,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.3.111

Hoewel de lokale IP-adressen later zijn gewijzigd, worden de LPTS-vermeldingen niet bijgewerkt. Het TCP-verzoek is geblokkeerd en de sessie blijft voor altijd vastzitten in een actieve status.

Oplossing

Om dit probleem op te lossen, moet u een update naar LPTS activeren. U kunt deze opties gebruiken om het probleem op te lossen:

• Sluit/nee sluit de BGP-buren
• Herconfiguratie van de BGP-buren
• BGP-proces opnieuw starten
• Configureer update-bron aan beide uiteinden die dit probleem kunnen voorkomen.

Verbetering in XR release

Er zijn enkele verbeteringen in recente IOS XR releases.

CSCuz51103 - BGP-sessie vastgezet in actief

Deze verbetering is geïntroduceerd met XR release 6.1.1. In deze release, wanneer BGP probeert de sessie opnieuw te starten, werkt LPTS zijn vermeldingen bij met het nieuwe lokale IP-adres . De updatetijd hangt van de configuratie van de greeptijd op beide einden af. Je kunt nog steeds wachten tot de sessie voorbij is.

Zelfs met deze verbetering kan een BGP-sessie nog steeds in een actieve status worden vastgezet als u passieve modus hebt geconfigureerd. De reden ligt voor de hand. Als BGP niet probeert de sessie te herstellen, wordt het lokale IP-adres niet geselecteerd. Daarom worden de LPTS-vermeldingen niet bijgewerkt.

Er is nog een verbetering voor deze situatie van XR release 6.2.1.

CSCvb15128-BGP sessie ingesloten in actief terwijl router passieve BGP-modus geconfigureerd heeft

Gerelateerde informatie

• ASR 9000/XR: LPTS-CoPP (Control Plane Policing) voor lokaal pakkettransport
• Configuratiehandleiding: LPTS implementeren
• Configuratiehandleiding: BGP implementeren

---