Dépannez la session d'eBGP coincée dans l'état active

Introduction

Ce document décrit comment dépanner l'eBGP (External Border Gateway Protocol) quand la session est coincée dans l'état active dû aux entrées incorrectes LPTS (services de transport locaux de paquet).

Contribué par William Xu, ingénieur TAC 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 dans ce document sont basées sur (l'agrégation entretient le routeur) les Plateformes ASR9000.

Les informations contenues dans ce document ont été créées à partir des périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est vivant, assurez-vous que vous comprenez l'impact potentiel de toutes les commandes.

Problème

Quand vous configurez l'eBGP, la session peut être coincée en active indéfiniment si :

• Il n'y a aucune commande d'update-source configurée
• Il y a une modification de topologie qui fait prendre le trafic un différent chemin

Ces symptômes actuels où cette question se produit :

• Les IP address sont accessibles
• Les deux pairs BGP restent collés en active
• La capture de paquet prouve que les Routeurs envoient beaucoup de remises de TCP
• l'erreur de suivi de show tcp indique cette erreur pour des 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 de la question est que des entrées LPTS ne sont pas mises à jour par la modification de routage et d'expédition. Il signifie qu'ils restent dans un état éventé après que la topologie change.

Il y a quelques améliorations faites pour le BGP. Ces deux scénarios couvrent plus de détail au sujet de cette question.

Note: l'iBGP (Internal Border Gateway Protocol) normalement ne frappe pas cette question puisque l'update-source est toujours utilisé.

Scénario 1 - EBGP de multi-alimentation avec la modification de topologie

Vous pouvez établir des sessions d'un eBGP de connexion multiple entre deux noeuds entre ASR9K-1 et ASR9K-3. Les adresses IP de pair sont 172.123.1.1 et 172.123.2.2 aux interfaces physiques. Il n'y a aucune commande d'update-source configurée. Avec la topologie en cours, la session reste dans l'état active. Ceci est prévu parce que les deux Routeurs utiliseront l'interface dans le sous-réseau 172.123.3.0/24 comme interface de sortie.

Vous pouvez arrêter le lien direct entre ASR9K-1 et ASR9K-3. Puis, les adresses de pair sont accessibles par l'intermédiaire d'ASR9K-2 qui est le lien de multi-alimentation, ainsi le ping est réussi. Les adresses IP de source s'assortissent aux deux extrémités, mais la session BGP est toujours dans un état active.

Quand les voisins BGP sont configurés, des entrées LPTS sont créées selon la table de CEF (Cisco Express Forwarding). Pour ASR9K-1, l'adresse IP 172.123.2.2 est accessible par l'intermédiaire du sous-réseau 172.123.3.0/24. Par conséquent, les entrées appropriées dans LPTS sont disponibles. Il permet au voisin BGP pour connecter le port 179 à l'adresse IP locale 172.123.3.1. Puisqu'il essaye d'initier une session TCP 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 même 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

Quand le lien entre ASR9K-1 et ASR9K-3 descend, les pairs sont accessibles par l'intermédiaire du 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. Ceci empêche le routeur pour permettre des demandes de TCP d'entrée à la nouvelle adresse IP locale. Par conséquent, la session BGP aux deux extrémités demeure collée dans un état active.

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

Vous pouvez déployer une session d'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 changé les adresses IP à 172.123.3.111 et à 172.123.3.222. Si vous configurez l'eBGP d'abord et mettez à jour ensuite les adresses IP aux interfaces, la session EBGP est coincée dans un état active.

La cause correspond le scénario 1. Une fois que vous configurez la session d'eBGP, les entrées LPTS sont générées selon l'interface de sortie locale à ce moment là.

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é changées plus tard, les entrées LPTS ne sont pas mises à jour. La demande de TCP est bloquée et la session demeure collée dans un état active pour toujours.

Solution

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

• Shut/No a fermé les voisins BGP
• Reconfiguration des voisins BGP
• BGP de processus de reprise
• Configurez l'update-source aux deux extrémités qui peuvent empêcher cette question.

Amélioration dans la release XR

Il y a quelques améliorations dans des releases récentes IOS XR.

CSCuz51103 - Session BGP coincée en active

Cette amélioration introduite de la version 6.1.1 XR. Dans cette release, quand les essais BGP pour rétablir la session, LPTS met à jour ses entrées avec la nouvelle adresse IP locale. Le minuteur de mise à jour dépend de la configuration de durée d'attente aux deux extrémités. Vous pouvez encore attendre parfois pour voir la session.

Même avec cette amélioration, une session BGP peut encore être coincée dans un état active si vous avez configuré le mode passif. La raison est évidente. Si le BGP n'essaye 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 de la version 6.2.1 XR.

CSCvb15128- la session BGP a collé en active tandis que le routeur fait configurer le mode passif BGP

Informations connexes

• ASR9000/XR : Services de transport locaux de paquet (LPTS) CoPP (Réglementation du plan de commande)
• Guide de configuration : Mise en oeuvre de LPTS
• Guide de configuration : Mise en oeuvre du BGP

---