Dépannage du blocage de session eBGP en état actif

Introduction

Ce document décrit comment dépanner eBGP (External Border Gateway Protocol) lorsque la session est bloquée en état actif en raison d'entrées LPTS incorrectes (Local Packet Transport Services).

Contribué par William Xu, ingénieur TAC Cisco.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• BGP 
• TCP
• LPTS pour IOS XR

Components Used

Les informations de ce document sont basées sur les plates-formes ASR9000 (Aggregation Services Router).

Les informations contenues dans ce document ont été créées à partir des périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est actif, assurez-vous de bien comprendre l'impact potentiel de toutes les commandes.

Problème

Lorsque vous configurez eBGP, la session peut être bloquée indéfiniment si :

• Aucune commande update-source configurée
• Il y a une modification de topologie qui fait que le trafic emprunte un chemin différent

Ces symptômes se présentent lorsque ce problème survient :

• Les adresses IP sont accessibles
• Les deux homologues BGP restent bloqués en activité
• La capture de paquets montre que les routeurs envoient de nombreuses réinitialisations TCP
• show tcp trace error indique cette erreur pour les sessions BGP.

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

En résumé, la cause première du problème est que les entrées LPTS ne sont pas mises à jour par la modification de routage et de transfert. Cela signifie qu'ils restent dans un état de stagnation après les modifications de la topologie.

Certaines améliorations ont été apportées au protocole BGP. Ces deux scénarios couvrent plus en détail ce problème.

Note: iBGP (Internal Border Gateway Protocol) ne touche généralement pas ce problème, car update-source est toujours utilisé.

Scénario 1 - EBGP à sauts multiples avec changement de topologie

Vous pouvez créer des sessions eBGP à plusieurs sauts entre ASR9K-1 et ASR9K-3. Les adresses IP des homologues sont 172.123.1.1 et 172.123.2.2 au niveau des interfaces physiques. Aucune commande update-source configurée. Avec la topologie actuelle, la session reste à l'état actif. Ceci est attendu car les deux routeurs utiliseront l’interface du sous-réseau 172.123.3.0/24 comme interface de sortie.

Vous pouvez arrêter la liaison directe entre ASR9K-1 et ASR9K-3. Ensuite, les adresses homologues sont accessibles via ASR9K-2, qui est la liaison multisaut, et la requête ping réussit. Les adresses IP source correspondent aux deux extrémités, mais la session BGP est toujours active.

Lorsque les voisins BGP sont configurés, les entrées LPTS sont créées conformément à la table CEF (Cisco Express Forwarding). Pour ASR9K-1, l'adresse IP 172.123.2.2 est accessible via le sous-réseau 172.123.3.0/24. Par conséquent, les entrées pertinentes dans LPTS sont disponibles. Il permet au voisin BGP de connecter le port 179 avec l'adresse IP locale 172.123.3.1. Comme il tente d'initier une session TCP à partir du port local 26036, vous pouvez voir une autre entrée pour elle.

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

Cette sortie est identique dans l'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

Lorsque la liaison entre ASR9K-1 et ASR9K-3 est interrompue, les homologues sont accessibles via le chemin ASR9K-2 avec une nouvelle adresse IP source locale. Mais la modification de topologie ne déclenche pas la mise à jour LPTS. L'entrée d'origine avec le port 179 reste avec l'adresse IP locale d'origine. Cela empêche le routeur d'autoriser les requêtes TCP d'entrée à la nouvelle adresse IP locale. Par conséquent, la session BGP aux deux extrémités reste bloquée dans un état actif.

Scénario 2 - eBGP avec mise à jour de la modification de l'adresse source

Vous pouvez déployer une session eBGP entre ASR9K-1 et ASR9K-3. Les adresses IP sont 172.123.3.1 et 172.123.3.2. Selon le nouveau plan, vous avez modifié les adresses IP en 172.123.3.111 et 172.123.3.222. Si vous configurez d'abord eBGP, puis mettez à jour les adresses IP sur les interfaces, la session EBGP est bloquée dans un état actif.

La cause est identique au scénario 1. Une fois que vous avez configuré la session eBGP, les entrées LPTS sont générées en fonction de l'interface de sortie locale à ce stade.

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

Bien que les adresses IP locales aient été modifiées ultérieurement, les entrées LPTS ne sont pas mises à jour. La requête TCP est bloquée et la session reste bloquée à tout jamais.

Solution

Pour résoudre ce problème, vous devez déclencher une mise à jour vers LPTS. Vous pouvez utiliser ces options pour résoudre le problème :

• Arrêter/Non fermer les voisins BGP
• Reconfiguration des voisins BGP
• Redémarrer le processus bgp
• Configurez update-source aux deux extrémités pour éviter ce problème.

Amélioration de la version XR

Certaines améliorations ont été apportées aux versions récentes d'IOS XR.

CSCuz51103 - Session BGP bloquée en cours

Cette amélioration est née de la version 6.1.1 de XR. Dans cette version, lorsque BGP tente de rétablir la session, LPTS met à jour ses entrées avec la nouvelle adresse IP locale . Le temps de mise à jour dépend de la configuration du temps d'attente aux deux extrémités. Vous pouvez encore attendre que parfois la session s'ouvre.

Même avec cette amélioration, une session BGP peut toujours être bloquée dans un état actif si vous avez configuré le mode passif. La raison en est évidente. Si BGP ne tente pas de rétablir la session, l'adresse IP locale n'est pas vérifiée. Par conséquent, les entrées LPTS ne sont pas mises à jour.

Il y a une autre amélioration pour cette situation à partir de XR version 6.2.1.

CSCvb15128 - Session BGP bloquée en cours alors que le mode BGP passif du routeur est configuré

Informations connexes

• ASR9000/XR : Services de transport de paquets locaux (LPTS) CoPP(Contrôle du plan de contrôle)
• Guide de configuration : Mise en oeuvre de LPTS
• Guide de configuration : Implémentation de BGP

---