Dépannage des problèmes de base du protocole BGP
Table des matières
Introduction
Ce document décrit comment dépanner les problèmes les plus courants avec le Border Gateway Protocol (BGP) et fournit des solutions et des directives de base.
Conditions préalables
Exigences
Il n'existe aucune condition préalable spécifique pour ce document. La connaissance de base du protocole BGP est utile, vous pouvez vous référer au Guide de configuration BGP pour plus d'informations.
Composants utilisés
Ce document n'est pas limité à des versions logicielles et matérielles spécifiques, mais les commandes sont applicables à Cisco IOS® et Cisco IOS® XE.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Ce document décrit un guide de base pour dépanner les problèmes les plus courants dans le protocole BGP (Border Gateway Protocol), fournit des actions correctives, des commandes/débogages utiles pour détecter la cause racine des problèmes et les meilleures pratiques pour éviter les problèmes potentiels. Gardez à l'esprit que toutes les variables et tous les scénarios possibles ne peuvent pas être pris en compte et qu'une analyse plus approfondie peut être requise par le TAC Cisco.
Topologie
Utilisez ce schéma de topologie comme référence pour les résultats fournis dans ce document.
Scénarios et problèmes
Contiguïté descendante
Si une session BGP est hors ligne, exécutez la commande show ip bgp all summary command. Ceci fournit l'état actuel de la session :
- Si l'état de la session n'est pas up, il peut varier entre IDLE et ACTIVE (cela dépend du processus Finite State Machine).
- Si la session est en ligne, vous pouvez voir le nombre de préfixes reçus.
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
Aucune connectivité
La première condition étant la connectivité entre les deux homologues, la session TCP sur le port 179 est établie. Ils sont connectés directement ou non) et vous pouvez utiliser une requête ping. Si l'appairage est établi entre les interfaces de bouclage, une requête ping de bouclage à bouclage doit être exécutée. Si un test ping est effectué sans bouclage spécifique comme interface source, l'adresse IP de l'interface physique sortante est utilisée comme adresse IP source du paquet au lieu de l'adresse IP de bouclage du routeur.
Si la requête ping échoue, tenez compte des raisons suivantes :
- Aucun homologue de route connecté ou aucune route du tout ; exécutez la commande show ip route peer_IP_address.
- Problème de couche 1 : Une interface physique, un SFP (connecteur), un câble ou un problème externe (transport et fournisseur, le cas échéant) doivent être pris en compte.
- Vérifiez tout pare-feu ou toute liste d'accès pouvant bloquer votre connexion.
Si la requête ping aboutit :
Problèmes liés à la configuration
- Adresse IP ou système autonome incorrect configuré : Si l'adresse IP est incorrecte, aucun message de ce type n'est affiché. Assurez-vous toutefois que la configuration est correcte. Pour un AS incorrect, vous devez voir un message similaire à la commande show logging.
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
Vérifiez la configuration BGP aux deux extrémités pour corriger les numéros de système autonome ou l'adresse IP homologue.
- Identificateur de routeur en double:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
Vérifiez l'identificateur BGP aux deux extrémités en exécutant la commande show ip bgp all summary et corrigez le problème dupliqué. Cela peut être réalisé manuellement avec la commande globale bgp router-id X.X.X.X sous la configuration du routeur bgp. Il est recommandé de définir manuellement l'ID de routeur sur un numéro unique.
- Source BGP et durée de vie :
La plupart des sessions iBGP sont configurées sur des interfaces de bouclage, qui sont accessibles via un IGP. Cette interface de bouclage doit être explicitement définie en tant que source. Pour ce faire, exécutez la commande neighbor ip-address update-source interface-id.
Pour les interfaces d'homologue eBGP directement connectées, la plupart sont utilisées pour l'homologue. Cisco IOS/Cisco IOS XE est vérifié pour remplir cette fonction, ou il n'essaie pas d'établir une session. Si eBGP est tenté de bouclage à bouclage sur des routeurs connectés directement, cette vérification peut être désactivée pour un voisin spécifique aux deux extrémités en exécutant la commande neighbor ip-address disable-connected-check.
Cependant, s'il y a plusieurs sauts entre les homologues eBGP, un nombre de sauts correct est requis, assurez-vous que l'adresse IP de voisin ebgp-multihop [hop-count]est configurée avec le nombre de sauts correct afin que chaque session puisse être établie. Si le nombre de sauts n'est pas spécifié, la valeur TTL par défaut pour les sessions iBGP est 255, tandis que la valeur TTL par défaut pour les sessions eBGP est 1.
Problèmes de session TCP
Une action utile pour tester le port 179 est une connexion Telnet manuelle d’un homologue à l’autre :
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
Une connexion ouverte/fermée ou refusée par l'hôte distant indique que les paquets ont atteint l'extrémité distante. Assurez-vous ensuite qu'il n'y a aucun problème avec le plan de contrôle à l'extrémité. Sinon, s'il y a un message Destination Unreachable (Destination inaccessible), vérifiez tout pare-feu ou toute liste d'accès qui peut bloquer le port TCP 179, les paquets BGP ou s'il y a une perte de paquets sur le chemin.
Si l'authentification est le problème, les messages suivants s'affichent :
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
Vérifiez les méthodes d'authentification, le mot de passe et les configurations associées, et pour un dépannage plus approfondi, référez-vous au guide Exemple de configuration d'authentification MD5 entre homologues BGP.
Si la session TCP n'est pas en ligne, utilisez les commandes suivantes pour l'isolation :
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
Rebonds de contiguïté
Si la session est intermittente, recherchez le journal show et vous pouvez trouver quelques scénarios.
Volet D'Interface
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
La raison de cette défaillance est due à un « Flap d'interface hors service ». Recherchez tout problème physique sur le port/SFP, le câble ou les déconnexions.
Expiration du minuteur de conservation
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
C'est fréquent et le routeur n'a pas reçu/traité de message de test d'activité ni mis à jour le message avant l'expiration du minuteur de mise en attente. Le périphérique envoie un message de notification et ferme la session. Les raisons les plus communes de ce problème sont :
- Problèmes d'interface : Recherchez les erreurs d'entrée, les abandons de file d'attente d'entrée ou les problèmes physiques sur les deux interfaces connectées par l'homologue ; l'exécution de la commande show interface peut être utilisée à cette fin.
- Perte de paquets en transit : Parfois, des paquets Hello peuvent être abandonnés pendant le transit, pour s'assurer qu'il s'agit d'une capture de paquets au niveau de l'interface :
- Utiliser la capture de paquets intégrée sur les périphériques Cisco IOS et Cisco IOS XE.
- Si des paquets sont vus au niveau de l'interface, assurez-vous qu'ils atteignent le plan de contrôle, EPC sur le plan de contrôle ou exécutez la commande debug bgp [vrf name] ipv4 unicast keepalives.
- CPU élevé : une condition CPU élevée peut provoquer des chutes sur le plan de contrôle, la commande show processes cpu [sorted|history] peut aider à identifier ces problèmes. En fonction de la plate-forme, vous pouvez trouver les étapes suivantes de dépannage en vous reportant au guide CPU Reference.
- Questions de politique CoPP : La méthodologie de dépannage varie pour chaque plate-forme et sort du cadre de ce document.
- Incompatibilité MTU : Si le chemin présente des différences de MTU et si des messages ICMP sont bloqués sur le chemin entre la source et la destination, PMTUD ne fonctionne pas correctement et peut entraîner un battement de session. Les mises à jour sont envoyées avec la valeur MSS négociée et un bit DF défini. Si un périphérique sur le chemin ou la destination ne peut pas accepter les paquets avec un MTU supérieur, il renvoie un message d'erreur ICMP au haut-parleur BGP. Le routeur de destination attend le keepalive BGP ou BGP met à jour le paquet vers son minuteur de mise hors service.
Vous pouvez vérifier le MSS négocié en exécutant la commande show ip bgp neighbors ip_address.
Un test ping vers un voisin spécifique avec le df set peut vous montrer si le MTU est valide le long du chemin :
ping 198.51.100.2 size max_seg_size df
Si des problèmes de MTU sont détectés, un examen précis de la configuration doit être effectué pour s'assurer que les valeurs de MTU sont cohérentes sur l'ensemble du réseau.
Questions relatives à AFI/SAFI
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
L'identificateur de famille d'adresses (AFI) est une extension de capacité ajoutée par le protocole BGP multiprotocole (MP-BGP). Il est mis en corrélation avec un protocole réseau spécifique, tel que IPv4, IPv6, etc. Précision supplémentaire grâce à un identificateur de famille d'adresses (SAFI) ultérieur, tel que monodiffusion et multidiffusion. MBGP réalise cette séparation avec les attributs de chemin BGP MP_REACH_NLRI et MP_UNREACH_NLRI. Ces attributs sont transportés à l'intérieur des messages de mise à jour BGP et sont utilisés pour transporter des informations d'accessibilité du réseau pour différentes familles d'adresses.
Le message vous fournit les numéros de l'AFI/SAFI enregistrée par l'IANA :
- Numéros de famille d'adresses IANA
- Paramètres des identificateurs de famille d'adresses suivants (SAFI)
- Vérifiez la configuration BGP pour les familles d'adresses prévues des deux côtés pour corriger les familles d'adresses indésirables.
- Exécutez la commande neighbor ip-address dont-capability-negotiation aux deux extrémités. Pour plus d'informations, référez-vous au guide Unsupported Capabilities Cause BGP Peer Malfunction.
Installation et sélection du chemin
Pour plus d'informations sur BGP et la sélection du meilleur chemin, référez-vous à Algorithme de sélection du meilleur chemin BGP.
Saut suivant
Pour qu'une route soit installée dans la table de routage, le saut suivant doit être accessible, sinon, même si le préfixe est sur la table BGP Loc-RIB, il ne se déplace pas dans RIB. En tant que règle d'évitement de boucle, sur Cisco IOS/Cisco IOS XE, iBGP ne modifie pas l'attribut de saut suivant car il laisse AS_PATH seul tandis qu'eBGP réécrit le saut suivant et ajoute son AS_PATH.
Vous pouvez vérifier le saut suivant en exécutant la commande show ip bgp [prefix] car elle fournit le saut suivant et le mot inaccessible. Dans cet exemple, il s'agit d'un préfixe annoncé par R1 via eBGP à R2 et appris par R3 via une connexion iBGP à partir de R2 :
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CST
Dans le résultat, le tronçon suivant est l'interface sortante de R1, qui n'est pas connue par R3. Pour corriger cette situation, vous pouvez annoncer le tronçon suivant via IGP, la route statique ou exécuter la commande neighbor ip-address next-hop-self sur l'homologue iBGP pour modifier l'adresse IP du tronçon suivant (qui est directement connectée). Dans l'exemple de schéma, cette configuration doit être sur R2 ; le voisin vers R3 (voisin 10.0.23.3 next-hop-self.)
Par conséquent, le saut suivant passe (après un clear ip bgp 10.0.23.2 soft) à l'interface connectée directement (accessible) et le préfixe est installé :
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CST
Défaillance RIB
Cela se produit lorsqu’une route ne peut pas être installée dans le RIB global, ce qui entraîne une défaillance du RIB. Les raisons courantes sont lorsque le même préfixe est déjà sur RIB pour un autre protocole de routage avec une distance administrative inférieure, mais la raison exacte d'une défaillance RIB est visible avec la commande show ip bgp rib-failure.
Condition De Course
Le problème le plus fréquent est quand IGP est préféré à eBGP sur un scénario de redistribution mutuelle. Lorsqu'une route IGP est redistribuée dans BGP, elle est considérée comme générée localement par BGP et reçoit un poids de 32 768 par défaut. Tous les préfixes reçus d'un homologue BGP reçoivent un poids local de 0 par défaut. Par conséquent, si le même préfixe doit être comparé, le préfixe ayant le poids le plus élevé est installé dans la table de routage en fonction du processus de sélection du meilleur chemin BGP, ce qui explique pourquoi la route IGP est installée sur RIB.
La solution à ce problème est de définir un poids plus élevé pour toutes les routes reçues de l'homologue BGP dans la configuration bgp du routeur :
neighbor ip-address weight 40000
Autres questions
Homologue lent BGP
Il s'agit d'un homologue qui ne peut pas suivre le taux auquel un expéditeur génère des messages de mise à jour. Il y a de nombreuses raisons pour qu'un pair présente ce problème ; CPU élevé dans l'un des homologues, trafic excessif, perte de trafic sur une liaison, ressource de bande passante, entre autres.
Problèmes de mémoire
Le protocole BGP utilise la mémoire affectée au processus Cisco IOS pour gérer les préfixes réseau, les meilleurs chemins, les stratégies et toutes les configurations associées afin de fonctionner correctement. Les processus globaux sont visibles en exécutant la commande show processes memory sorted :
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
Le pool de processeurs est la mémoire utilisée ; environ 2,1 Go dans l'exemple. Ensuite, vous devez examiner la colonne Holding pour identifier le sous-processus qui en détient la plus grande partie. Ensuite, vous devez vérifier les sessions BGP que vous avez, combien de routes sont reçues et quelle configuration est utilisée.
Étapes courantes pour réduire le stockage de mémoire par BGP :
- Filtrage BGP : s'il n'est pas nécessaire de recevoir une table BGP complète, utilisez des stratégies pour filtrer les routes et installer uniquement les préfixes dont vous avez besoin.
- Reconfiguration logicielle : Recherchez neighbor ip_address soft-reconfiguration inbound sous configuration BGP ; Cette commande vous permet d'afficher tous les préfixes reçus avant toute stratégie entrante (Adj-RIB-in). Cependant, cette table a besoin d'environ la moitié de la table RIB locale BGP actuelle pour stocker ces informations afin que vous puissiez éviter cette configuration sauf si elle est obligatoire, ou si vos préfixes actuels sont peu nombreux.
CPU élevé
Les routeurs utilisent des processus différents pour le fonctionnement du protocole BGP. Pour vérifier que le processus BGP est la cause d'une utilisation élevée du CPU, exécutez la commande show process cpu sorted.
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
Voici les processus courants, les causes et les étapes générales pour surmonter l'utilisation élevée du CPU due au BGP :
- Routeur BGP : S'exécute une fois par seconde pour garantir une convergence plus rapide (il s'agit d'un thread important). Il lit les messages de mise à jour bgp, valide les préfixes/réseaux et attributs, met à jour la table de réseau/préfixe et la table d'attributs AFI/SAFI, effectue le calcul du meilleur chemin, entre autres tâches.
Un grand désordre de route est un scénario très courant qui conduit à cette situation. - Analyseur BGP : Processus de faible priorité qui s'exécute toutes les 60 secondes par défaut. Ce processus vérifie l'intégralité de la table BGP pour vérifier l'accessibilité du tronçon suivant et met à jour la table BGP en conséquence. Il est exécuté via la base d'informations de routage (RIB) à des fins de redistribution. Vérifiez l'évolutivité de la plate-forme, car plus de préfixes et de routes sont installés et TCAM utilisé, plus de ressources sont nécessaires.
- E/S BGP : S'exécute lorsque des paquets de contrôle BGP sont reçus et gère la mise en file d'attente et le traitement des paquets BGP. S'il y a un nombre excessif de paquets reçus dans la file d'attente BGP pendant une longue période, ou s'il y a un problème avec TCP, le routeur montre des symptômes de CPU élevé dû au processus d'E/S BGP. Généralement, le routeur BGP est également élevé dans cette situation. Examinez le nombre de messages pour identifier l'homologue et capturez les paquets pour identifier la source de ces messages.
- BGP ouvert : Processus utilisé pour l'établissement de la session; Il ne s'agit pas d'un problème fréquent de CPU élevé, sauf si une session est bloquée dans un état Ouvert.
- Événement BGP : est responsable du traitement du tronçon suivant. Recherchez les sauts suivants sur les préfixes reçus.
Informations connexes
- Assistance et documentation techniques - Cisco Systems
- Guide de configuration BGP
- Exemple de configuration d'authentification MD5 entre homologues BGP
- Capture de paquets intégrée
- Volets de voisinage BGP avec dépannage MTU
-
Paramètres des identificateurs de famille d'adresses suivants (SAFI)
- Des fonctionnalités non prises en charge provoquent un dysfonctionnement des homologues BGP
- Algorithme de sélection du meilleur chemin BGP
- Comprendre RIB-failure BGP et la commande bgp suppress-inactive
- Comprendre l’importance de l’attribut de chemin poids du BGP dans les scénarios de basculement réseau
- Utiliser la fonctionnalité « Slow Peer » du protocole BGP pour résoudre les problèmes d'homologue lent
- Configuration des routeurs BGP pour des performances optimales et une consommation de mémoire réduite
- Dépannage d’un CPU élevé causé par l’analyseur BGP ou le processus du routeur
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
5.0 |
02-Sep-2026
|
La recertification a mis à jour l'orthographe et la grammaire, inséré des lignes horizontales pour séparer les sections afin de faciliter la lecture et corrigé les erreurs dans CCW. |
4.0 |
19-Feb-2025
|
Recertification |
3.0 |
25-Sep-2023
|
Mise à jour d'IOS XE (tiret supprimé) et ajout de marque, SEO et formatage. |
2.0 |
21-Feb-2023
|
Recertification. |
1.0 |
04-Aug-2022
|
Première publication |
Commentaires