Dépannage de la session eBGP bloquée dans l'état actif

Introduction

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

Contribution de William Xu, ingénieur du centre d'assistance technique Cisco.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• BGP 
• TCP
• LPTS pour IOS XR

Composants utilisés

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 comprendre l'impact potentiel de toute commande.

Problème

Lorsque vous configurez eBGP, la session peut rester active indéfiniment si :

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

Ces symptômes se manifestent lorsque ce problème se produit :

• Les adresses IP sont accessibles
• Les deux homologues BGP restent bloqués dans l'état actif
• La capture de paquets indique 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 principale 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 stable après les modifications de la topologie.

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

Remarque : iBGP (Internal Border Gateway Protocol) n'atteint normalement pas ce problème puisque update-source est toujours utilisé.

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

Vous pouvez créer des sessions eBGP à sauts multiples entre ASR9K-1 et ASR9K-3. Les adresses IP homologues sont 172.123.1.1 et 172.123.2.2 au niveau des interfaces physiques. Aucune commande update-source n'est configurée. Avec la topologie actuelle, la session reste à l'état actif. Cela 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 à sauts multiples, ce qui permet d'envoyer une requête ping. Les adresses IP source correspondent aux deux extrémités, mais la session BGP est toujours dans un état actif.

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 rubriques pertinentes du STPGV sont disponibles. Il permet au voisin BGP de connecter le port 179 avec l'adresse IP locale 172.123.3.1. Puisqu'il tente d'initier une session TCP à partir du port local 26036, vous pouvez voir une autre entrée pour lui.

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

Ce résultat 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 entrantes vers 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 modification de l'adresse source de mise à jour

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. Conformément au 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 au niveau des 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 point.

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 à jamais dans un état actif.

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, ce qui peut empêcher ce problème.

Amélioration de la version XR

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

CSCuz5103 - Session BGP bloquée en cours

Cette amélioration a été introduite à partir de XR version 6.1.1. 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 toujours attendre que la session soit ouverte de temps en temps.

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 n'essaie pas de rétablir la session, l'adresse IP locale n'est pas vérifiée. Les entrées LPTS ne sont donc pas mises à jour.

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

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

Informations connexes

• ASR9000/XR : CoPP LPTS (Local Packet Transport Services) (Control Plane Policing)
• Guide de configuration : Implémentation de LPTS
• Guide de configuration : Implémentation de BGP

---