Fehlerbehebung bei eBGP-Sitzung im aktiven Zustand

Einleitung

In diesem Dokument wird die Fehlerbehebung für eBGP (External Border Gateway Protocol) beschrieben, wenn die Sitzung aufgrund falscher LPTS-Einträge (Local Packet Transport Services) im aktiven Zustand verbleibt.

Unterstützt von William Xu, Cisco TAC Engineer.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• BGP
• TCP
• LPTS für IOS XR

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf ASR9000-Plattformen (Aggregation Services Router).

Die Informationen in diesem Dokument stammen von Geräten in einer bestimmten Laborumgebung. 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 potenziellen Auswirkungen von Befehlen verstehen.

Problem

Wenn Sie eBGP konfigurieren, kann die Sitzung unbegrenzt aktiv bleiben, wenn:

• Es ist kein Update-Source-Befehl konfiguriert.
• Es gibt eine Topologieänderung, die dazu führt, dass der Datenverkehr einen anderen Pfad einnimmt.

Diese Symptome treten auf, wenn dieses Problem auftritt:

• IP-Adressen sind erreichbar
• Beide BGP-Peers bleiben aktiv
• Die Paketerfassung zeigt, dass die Router viele TCP-Resets senden.
• show tcp trace error gibt diesen Fehler für BGP-Sitzungen an.

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

Zusammenfassend lässt sich sagen, dass die Ursache des Problems darin besteht, dass LPTS-Einträge durch die Routing- und Weiterleitungsänderung nicht aktualisiert werden. Das bedeutet, dass sie nach der Topologieänderung in einem veralteten Zustand bleiben.

Für BGP wurden einige Verbesserungen vorgenommen. Diese beiden Szenarien behandeln dieses Problem detaillierter.

Hinweis: iBGP (Internal Border Gateway Protocol) tritt dieses Problem normalerweise nicht auf, da update-source immer verwendet wird.

Szenario 1 - Multihop-EBGP mit Topologieänderung

Sie können eine eBGP-Multihop-Sitzung zwischen ASR9K-1 und ASR9K-3 erstellen. Die Peer-IP-Adressen sind 172.123.1.1 und 172.123.2.2 an den physischen Schnittstellen. Es ist kein Update-Source-Befehl konfiguriert. Bei der aktuellen Topologie bleibt die Sitzung im aktiven Zustand. Dies wird erwartet, da beide Router die Schnittstelle im Subnetz 172.123.3.0/24 als Ausgangsschnittstelle verwenden.

Sie können die direkte Verbindung zwischen ASR9K-1 und ASR9K-3 beenden. Anschließend sind die Peer-Adressen über den ASR9K-2 erreichbar, der die Multihop-Verbindung darstellt. Der Ping-Test ist somit erfolgreich. Die Quell-IP-Adressen stimmen auf beiden Seiten überein, aber die BGP-Sitzung ist noch aktiv.

Wenn die BGP-Nachbarn konfiguriert sind, werden LPTS-Einträge entsprechend der CEF-Tabelle (Cisco Express Forwarding) erstellt. Für ASR9K-1 ist die IP-Adresse 172.123.2.2 über das Subnetz 172.123.3.0/24 erreichbar. Daher sind die entsprechenden Einträge im LPTS verfügbar. Es ermöglicht dem BGP-Nachbarn, Port 179 mit der lokalen IP-Adresse 172.123.3.1 zu verbinden. Da versucht wird, eine TCP-Sitzung vom lokalen Port 26036 aus zu initiieren, wird ein anderer Eintrag angezeigt.

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

Diese Ausgabe ist für den ASR9K-3 identisch.

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

Wenn die Verbindung zwischen ASR9K-1 und ASR9K-3 ausfällt, sind die Peers über einen ASR9K-2-Pfad mit einer neuen lokalen IP-Quelladresse erreichbar. Die Topologieänderung löst jedoch nicht das LPTS-Update aus. Der ursprüngliche Eintrag mit Port 179 bleibt bei der ursprünglichen lokalen IP-Adresse. Dadurch wird verhindert, dass der Router eingehende TCP-Anfragen an die neue lokale IP-Adresse zulässt. Daher bleibt die BGP-Sitzung an beiden Enden im aktiven Zustand.

Szenario 2 - eBGP mit Änderung der Quelladresse aktualisieren

Sie können eine eBGP-Sitzung zwischen ASR9K-1 und ASR9K-3 bereitstellen. Die IP-Adressen sind 172.123.3.1 und 172.123.3.2. Gemäß dem neuen Plan haben Sie die IP-Adressen in 172.123.3.111 und 172.123.3.222 geändert. Wenn Sie eBGP zuerst konfigurieren und dann die IP-Adressen an den Schnittstellen aktualisieren, bleibt die EBGP-Sitzung in einem aktiven Zustand.

Die Ursache ist dieselbe wie in Szenario 1. Nach der Konfiguration der eBGP-Sitzung werden die LPTS-Einträge entsprechend der lokalen Ausgangsschnittstelle zu diesem Zeitpunkt generiert.

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

Obwohl die lokalen IP-Adressen später geändert wurden, werden die LPTS-Einträge nicht aktualisiert. Die TCP-Anfrage wird blockiert, und die Sitzung bleibt für immer im aktiven Status.

Lösung

Um dieses Problem zu beheben, müssen Sie ein Update auf LPTS auslösen. Sie können diese Optionen verwenden, um das Problem zu beheben:

• BGP-Nachbarn schließen/nicht schließen
• Neukonfiguration der BGP-Nachbarn
• Prozess-BGP neu starten
• Konfigurieren Sie update-source auf beiden Seiten, um dieses Problem zu vermeiden.

Verbesserungen in XR-Version

Die neuesten IOS XR-Versionen bieten einige Verbesserungen.

CSCuz51103 - BGP-Sitzung bleibt aktiv

Diese Erweiterung wurde in XR 6.1.1 eingeführt. Wenn BGP in dieser Version versucht, die Sitzung wiederherzustellen, aktualisiert das LPTS seine Einträge mit der neuen lokalen IP-Adresse . Die Aktualisierungszeit hängt von der Konfiguration der Haltezeit an beiden Enden ab. Sie können immer noch warten, bis die Sitzung manchmal aktiv ist.

Selbst bei dieser Erweiterung kann eine BGP-Sitzung im aktiven Status verbleiben, wenn Sie den passiven Modus konfiguriert haben. Der Grund liegt auf der Hand. Wenn das BGP nicht versucht, die Sitzung wiederherzustellen, wird die lokale IP-Adresse nicht überprüft. Daher werden die LPTS-Einträge nicht aktualisiert.

Es gibt eine weitere Verbesserung für diese Situation von XR Version 6.2.1.

CSCvb15128 - BGP-Sitzung bleibt aktiv, während der passive BGP-Modus des Routers konfiguriert ist

Zugehörige Informationen

• ASR9000/XR: Local Packet Transport Services (LPTS) CoPP (Control Plane Policing)
• Konfigurationsanleitung: Implementieren von LPTS
• Konfigurationsanleitung: Implementieren von BGP

---