Accueil / Notes techniques / Dépannage voisin BGP et instabilité de routes

Le voisin BGP ne s'établit pas et les routes s'instabilisent : une checklist complète

Un voisin bloqué en Idle ou OpenSent, ou une session qui rebondit sans cesse en entraînant une route avec elle, est l'une des escalades les plus courantes en bordure de réseau étendu. Voici l'ordre de diagnostic qui distingue les quelques causes racines derrière la plupart de ces tickets — les commandes display exactes, les codes d'erreur, et où l'itération de route casse silencieusement une session qui semble par ailleurs normale.

Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026

Pourquoi la colonne d'état en dit plus que le symptôme

Je ne commence pas par fixer la configuration — je commence par déterminer dans lequel des six états le voisin est réellement bloqué.

Une session BGP traverse une séquence fixe — Idle, Connect, Active, OpenSent, OpenConfirm, Established — et presque chaque ticket « le voisin ne monte pas » revient en réalité à savoir dans lequel de ces états il est bloqué, pas à un mystère à résoudre en changeant les réglages des deux côtés à la fois. Une session qui atteint Established puis tombe, rebondit, ou envoie silencieusement le trafic sur un seul de plusieurs chemins à coût égal est un problème différent, avec son propre ordre de diagnostic, même s'il est signalé de la même façon : « BGP est down ».

Voici l'arbre de panne sur lequel ce texte s'appuie, les vérifications pour chaque branche avec les commandes exactes à exécuter, les causes qui reviennent sans cesse une fois passées les premières vérifications, et quelques réponses de FAQ tirées de cas de terrain réels.

Lisez l'arbre de panne avant de toucher à la configuration

Les pannes BGP se répartissent en exactement deux formes : le voisin n'atteint jamais Established, ou il l'atteint et quelque chose ne va toujours pas.

Placer d'abord le symptôme sur cet arbre évite beaucoup d'allers-retours par la suite — cela indique laquelle des sections ci-dessous s'applique réellement à ce que vous observez.

Les légendes du schéma restent en anglais pour la clarté technique.

Une fois que vous savez quelle branche s'applique, presque chaque vérification ci-dessous n'est qu'à une seule commande display d'une cause confirmée — le piège consiste à traiter une session déjà Established qui flappe avec la même checklist qu'une session qui n'a jamais démarré.La même discipline, appliquée à un autre protocole, se retrouve dans Le voisin OSPF est bloqué ou les routes s'instabilisent ? Lire la machine à états pour trouver la panne, sa note sœur pour les adjacences OSPF.

Parcourir chaque état

Six états, une seule commande exacte pour savoir dans lequel vous êtes bloqué — et les journaux de flap s'expliquent d'eux-mêmes une fois le code d'erreur compris.

Étape 0 — Confirmer que le transport se connecte réellement

Si le voisin ne quitte jamais Idle ou Active, ne touchez pas encore à la configuration BGP — confirmez d'abord que les deux extrémités peuvent réellement se joindre sur TCP 179.

Faites un ping entre les deux adresses de voisin avec une commande qui porte une adresse source et une taille de paquet réelle — ping -a source-ip-address -s packetsize host — car une adresse source confirme aussi que le chemin de retour est valide, et une taille de paquet plus grande confirme qu'une grosse Update BGP ne sera pas silencieusement perdue en chemin.
Si le ping échoue, c'est un problème de routage/liaison à traiter séparément, pas un problème BGP.
Si le ping réussit mais que la session ne progresse toujours pas, vérifiez sur les deux extrémités une ACL qui filtrerait le port TCP 179 — souvent un reliquat d'une politique de sécurité ou de QoS sans rapport.

<HUAWEI> display acl all
Basic ACL 3001, 2 rules
ACL's step is 5
ACL's match-order is config
  rule 5 deny tcp source-port eq bgp
  rule 10 deny tcp destination-port eq bgp
// undo rule 5 destination-port / undo rule 10 source-port removes the block

Étape 1 — Correspondance du Router ID, du numéro d'AS et de la famille d'adresses

Le transport va bien, mais le voisin ne quitte toujours pas OpenSent ou affiche « No Neg » — c'est presque toujours un paramètre précis qui semble correct isolément mais ne correspond pas réellement à l'autre extrémité.

Vérifiez display bgp peer sur les deux extrémités pour le Router ID local. Deux voisins partageant le même Router ID — fréquent après une configuration clonée — bloquent l'établissement pur et simple ; corrigez avec router id en vue BGP, généralement réglé sur l'adresse Loopback.
Comparez le numéro d'AS configuré à ce que l'autre extrémité est réellement, pas à ce que vous pensez qu'il devrait être.
Si la session est spécifique à une famille d'adresses (VPNv4, IPv6, VPNv6), confirmez que peer enable est configuré sous cette famille d'adresses des deux côtés — une configuration unilatérale s'affiche en « No Neg » plutôt qu'en échec net.

<HUAWEI> display bgp peer
BGP local router ID : 1.1.1.1
 Local AS number : 41976
 Total number of peers : 12                Peers in established state : 4
  Peer            V          AS  MsgRcvd  MsgSent  OutQ  Up/Down       State PrefRcv
  10.9.0.8        4         100     1601     1443     0 23:21:56 Established   10000
  10.10.0.10      4         200     1565     1799     0 23:15:30 Established    9999
// Router ID and AS both compared directly against the peer's own values

Étape 2 — Paramètres de voisinage par Loopback

Si l'une des extrémités source la session depuis une interface Loopback, quatre paramètres supplémentaires doivent être correctement configurés, et un cinquième — le Device ID — doit simplement ne pas être nul.

Confirmez que peer connect-interface pointe vers le Loopback utilisé pour sourcer la session — sans cela, l'appareil source par défaut depuis l'interface physique de sortie.
Pour une session EBGP construite sur un Loopback (ou tout EBGP multi-sauts), confirmez que peer ebgp-max-hop est configuré avec un nombre de sauts qui couvre réellement le chemin.
Si le GTSM est en jeu, confirmez que peer valid-ttl-hops est configuré symétriquement des deux côtés — il doit être activé des deux côtés ensemble, pas d'un seul.
Lors du peering avec un appareil d'un autre fournisseur, si la session refuse de se rétablir après un redémarrage alors que la poignée de main TCP se termine proprement, vérifiez si cet appareil a réellement un Device ID BGP utilisable — si chaque interface adressée en IP est liée à l'intérieur d'une instance VPN et qu'il n'y a pas de Loopback autonome, le Device ID se résout en 0.0.0.0, que la plupart des implémentations rejettent d'emblée.

<Huawei> display bgp vpnv4 vpn-instance VPN1 peer
BGP local Device ID : 0.0.0.0        // invalid -- session will not originate or accept
...
// after adding a Loopback interface outside any VPN instance:
BGP local Device ID : 192.168.1.2
VPN-Instance VPN1, Device ID 192.168.1.2:
Total number of peers : 1  Peers in established state : 1
Peer         V AS     MsgRcvd  MsgSent  OutQ  Up/Down     State       PrefRcv
10.83.255.2  4 39651  10       22       0     02:59:49    Established 1

Étape 3 — Établie, puis chute : lisez le code d'erreur, ne devinez pas

Une session qui allait bien puis a chuté, ou qui rebondit sans cesse, laisse une raison exacte derrière elle — vous n'avez pas besoin d'être en train de regarder quand cela se produit.

Exécutez display bgp peer <ip> log-info pour extraire l'historique Up/Down avec un Error Code et un Error Subcode pour chaque transition — Cease/Administrative Shutdown signifie que quelqu'un a exécuté shutdown ou peer ignore ; Hold Timer Expired signifie que les keepalives ont simplement cessé d'arriver à temps ; un sous-code de changement de configuration signifie qu'une commande affectant le voisin a été modifiée.
En vue diagnostic, pads diagnose neighbor bgp affiche une raison en clair sur une ligne par voisin, sans que vous ayez à la reconstituer à partir de la configuration.
Si la raison n'est pas une action d'administration, vérifiez le chemin physique/IGP en dessous — une route vers le Loopback du voisin qui récursive via une route statique peut silencieusement rediriger le trafic de la session BGP elle-même vers un trou noir Null0 dès qu'une liaison montante physique tombe, même si un simple ping (qui hache différemment) réussit toujours.

<HUAWEI> display bgp peer 10.8.200.26 log-info
 Date/Time     : 2021-02-06 18:34:31+00:00
 State         : Down
 Error Code    : 4(Hold Timer Expired)
 Error Subcode : 0(UnSpecific)
 Notification  : Send Notification

[~HUAWEI-diagnose] pads diagnose neighbor establish-abnormal bgp history-record
NBR-Peer-IP    Last-Detect-Time State       Reason
1.1.1.1        01-27 20:23:49   OpenConfirm The shutdown command is run in the BGP view.
2.2.2.2        01-27 20:23:49   Idle        The peer ignore command is configured for the BGP peer.

Étape 4 — Trafic déséquilibré ou route agrégée instable

La session est stable — le « défaut » réside dans la façon dont les routes qu'elle transporte sont utilisées ou réannoncées.

Si deux chemins EBGP à coût égal ou plus existent entre la même paire de routeurs mais que presque tout le trafic emprunte l'un d'eux, confirmez que maximum load-balancing est configuré avec une valeur de 2 ou plus sur chaque routeur qui voit les routes à coût égal.
Si une route résumée/agrégée flappe continuellement sans changement de politique et sans qu'aucune route ne soit réellement ajoutée ou retirée, comparez la préférence du protocole BGP à celle de la route statique ou IGP qui alimente aussi cet agrégat — celle qui l'emporte actuellement décide si l'agrégat est « up », et un blip de session ou de protocole du côté perdant le fait basculer.

[Device] bgp 65001
[Device-bgp] maximum load-balancing 4
// configure identically on every router in the cross-connected mesh

[Device-bgp] preference 65
// set BGP's preference lower (worse) than the static route feeding the same aggregate (default static preference 60)

6 causes qui reviennent sans cesse

Une fois que les états ci-dessus vous ont indiqué où se situe le problème, ces six causes expliquent l'essentiel de ce qui ne va pas.

1. Une collision de Router ID bloque silencieusement la session

SYMPTÔMELe voisin n'atteint jamais Established alors que le ping de transport réussit proprement — il reste simplement en OpenSent ou cycle.

CAUSEDeux voisins se retrouvent avec le même Router ID — souvent après une configuration clonée ou basée sur un modèle où l'adresse Loopback, ou la sélection par défaut du Router ID, n'a pas été changée sur la copie.

SOLUTIONDéfinissez un Router ID explicite et unique sur chaque appareil, généralement en utilisant sa propre adresse Loopback.

[Device] bgp 65001
[Device-bgp] router id 2.2.2.2

2. Une ACL oubliée bloque le port TCP 179

SYMPTÔMELe ping de couche transport entre les deux adresses de voisin fonctionne bien, mais la session ne quitte jamais Idle ou Active.

CAUSEUne ACL configurée pour un autre but — filtrage de sécurité, classification QoS — se trouve refuser le port source ou destination TCP bgp sur le chemin entre les deux voisins.

SOLUTIONVérifiez display acl all sur les deux extrémités et supprimez ou restreignez la règle qui correspond au port TCP 179.

<HUAWEI> display acl all
Basic ACL 3001, 2 rules
  rule 5 deny tcp source-port eq bgp
  rule 10 deny tcp destination-port eq bgp
[HUAWEI] acl 3001
[HUAWEI-acl-basic-3001] undo rule 5 destination-port
[HUAWEI-acl-basic-3001] undo rule 10 source-port

3. Voisinage par Loopback sans connect-interface / ebgp-max-hop, ou un Device ID à 0.0.0.0

SYMPTÔMEUne session vers le routeur d'un autre fournisseur refuse de se reconnecter après un redémarrage de l'appareil, alors que la connexion TCP sous-jacente se termine proprement.

CAUSESi chaque interface adressée en IP de l'appareil est liée à l'intérieur d'une instance VPN et qu'il n'y a pas de Loopback autonome, le Device ID BGP se résout en 0.0.0.0 — une valeur que la plupart des implémentations considèrent invalide, donc l'appareil ne lancera ni n'acceptera de session à cet ID, peu importe la santé du transport. Par ailleurs, les sessions sourcées depuis un Loopback nécessitent peer connect-interface, et les sessions EBGP sourcées depuis un Loopback ou autrement multi-sauts nécessitent peer ebgp-max-hop — sans l'un ou l'autre, la session reste non établie sans erreur évidente.

SOLUTIONAjoutez une interface Loopback en dehors de toute instance VPN (ou définissez explicitement router id) pour que le Device ID ne soit jamais 0.0.0.0, et configurez connect-interface et ebgp-max-hop partout où la session n'est pas un simple voisin EBGP directement connecté.

[Device] interface loopback 1
[Device-LoopBack1] ip address 192.168.1.2 32
[Device] bgp 64512
[Device-bgp] peer 10.83.255.2 ebgp-max-hop 2
[Device-bgp] peer 10.83.255.2 connect-interface LoopBack1

4. L'itération de route redirige silencieusement la session vers un trou noir Null0

SYMPTÔMEUne session BGP à double liaison montante qui allait bien retombe en OpenSent dès qu'une liaison montante physique tombe — même si vous pouvez toujours pinguer l'adresse Loopback du voisin depuis cet appareil.

CAUSELes routes statiques vers le Loopback du voisin sont récursives via une autre route statique plutôt que de pointer vers une interface et un tronçon suivant explicites. Quand une liaison physique tombe, le tronçon suivant de la route survivante à coût égal itère vers une route Null0 configurée pour un usage de trou noir sans rapport. Un ping non sourcé se hache sur le chemin encore fonctionnel et réussit, mais la session BGP — sourcée depuis le Loopback — se hache sur le chemin qui itère désormais vers Null0, et tombe.

SOLUTIONFaites pointer chaque route statique vers une interface de sortie et un tronçon suivant explicites au lieu de la laisser récursive via une autre entrée statique.

[Device] undo ip route-static 10.0.0.1 255.255.255.255 192.168.0.1
[Device] ip route-static 10.0.0.1 255.255.255.255 10GE0/0/2 192.168.0.1
<Device> display bgp peer
// the peer at 10.0.0.1 returns to Established once the recursive path is removed

5. Des chemins à coût égal existent, mais l'équilibrage de charge n'a jamais été activé

SYMPTÔMEDeux liaisons EBGP à coût égal ou plus connectent la même paire de routeurs, mais presque tout le trafic emprunte l'une d'elles pendant que l'autre reste quasiment inactive.

CAUSEPar défaut, BGP n'installe et n'utilise qu'un seul meilleur chemin par préfixe — quel que soit le nombre de routes à coût égal réellement présentes — à moins que l'équilibrage de charge ne soit explicitement activé. Sans cela, la sélection de chemin BGP ordinaire (le Router ID le plus bas parmi des routes identiques, par exemple) retombe toujours sur le même chemin unique.

SOLUTIONActivez maximum load-balancing avec un compte de 2 ou plus sur chaque routeur du maillage entrecroisé, dimensionné pour la croissance future, et confirmez le compte que la plateforme du fournisseur distant prend en charge si elle n'est pas la même que celle-ci.

[Device] bgp 65001
[Device-bgp] maximum load-balancing 4

6. Un bras de fer de priorité statique vs dynamique fait flapper une route agrégée

SYMPTÔMEUne route résumée annoncée vers le backbone flappe continuellement — les voisins en aval la voient apparaître et disparaître même si personne n'a touché à aucune politique ni ajouté ou retiré de route.

CAUSEL'agrégat est alimenté à la fois par une route statique (souvent un trou noir) et une route apprise dynamiquement en IBGP ou IGP avec une préférence meilleure que l'entrée statique. Chaque fois que la session sous-jacente de la route dynamique vacille — même brièvement — la source préférée pour l'agrégat bascule entre les deux, et l'agrégat est retiré puis réannoncé alors que rien n'a changé sur le réseau réel.

SOLUTIONRéglez la préférence du protocole dynamique moins bonne (numériquement plus élevée) que celle de la route statique, afin que l'entrée statique reste la source stable et permanente de l'agrégat.

[Device] bgp 65001
[Device-bgp] preference 65
// static route default preference is 60 -- keep it better than BGP/IGP for this aggregate's source

Cinq questions qui reviennent sans cesse

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse toute prête.

Mon voisin ne quitte jamais Idle ou Active — quel est le moyen le plus rapide de savoir dans quel état il est réellement bloqué ?

display bgp peer affiche directement la colonne State actuelle (Idle / Connect / Active / OpenSent / OpenConfirm / Established). Si la raison pour laquelle il ne progresse pas au-delà de cet état n'est pas évidente, la commande en vue diagnostic pads diagnose neighbor establish-abnormal bgp history-record affiche une raison en clair sur une ligne par voisin — « the shutdown command is run in the BGP view », « the peer ignore command is configured » — sans que vous ayez à la reconstituer depuis la configuration active.

La session était Established depuis des semaines puis a chuté une fois — comment savoir pourquoi après coup ?

display bgp peer <ip> log-info conserve un historique des transitions Up/Down avec la paire exacte Error Code / Error Subcode pour chacune. Le code 6 sous-code 2 (Administrative Shutdown) signifie que quelqu'un a exécuté shutdown ou configuré peer ignore ; le code 4 (Hold Timer Expired) signifie que les keepalives ont simplement cessé d'arriver à temps — vérifiez la liaison et la charge CPU ; le code 6 sous-code 6 signifie qu'une commande affectant le voisin, comme ebgp-max-hop, a été modifiée. Recoupez l'horodatage avec le journal des opérations pour ce même instant.

Deux liaisons EBGP relient la même paire de routeurs avec un coût identique, mais presque tout le trafic emprunte l'une d'elles — pourquoi ?

BGP n'installe qu'un seul meilleur chemin par préfixe par défaut. Sans maximum load-balancing configuré à une valeur de 2 ou plus sur les routeurs qui voient les chemins à coût égal, un seul chemin est jamais utilisé, quel que soit le nombre de routes à coût égal réellement présentes. Configurez-le sur chaque routeur de la paire entrecroisée, et vérifiez le compte que la plateforme du fournisseur distant prend en charge si elle n'est pas la même que celle-ci.

Une route résumée que nous annonçons en amont flappe sans cesse même si personne n'a changé de politique ni de route — qu'est-ce qui bouge réellement ?

C'est plus souvent un problème de priorité qu'un problème de protocole. Si l'agrégat est alimenté à la fois par une route statique et une route apprise dynamiquement en IBGP ou IGP, celle qui a actuellement la meilleure préférence décide si l'agrégat est « up ». Quand la session derrière la route dynamique vacille, même brièvement, la source gagnante bascule et l'agrégat est retiré puis réannoncé — rien n'a changé dans le réseau réel. Réglez la préférence du protocole dynamique moins bonne que celle de la route statique pour que l'entrée statique reste la source stable.

La configuration semble identique des deux côtés, mais une session avec le routeur d'un autre fournisseur ne monte toujours pas après un redémarrage — que me manque-t-il ?

Vérifiez si cet appareil a réellement un Device ID BGP utilisable. Si chaque interface adressée en IP est liée à l'intérieur d'une instance VPN et qu'il n'y a pas de Loopback autonome, le Device ID se résout en 0.0.0.0, que la plupart des implémentations rejettent d'emblée — l'appareil ne lancera ni n'acceptera de session à cet ID même si la connexion TCP elle-même se termine proprement. Ajoutez une interface Loopback en dehors de toute instance VPN, ou définissez explicitement router id, avant de changer quoi que ce soit d'autre.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'articule autour du modèle de classification des pannes BGP du routeur Huawei série AR et de ses commandes display bgp peer / display bgp peer log-info / pads diagnose neighbor bgp, ainsi que des cas de terrain qui les sous-tendent. Si votre routeur est d'un autre fournisseur, les commandes exactes changent, mais la logique sous-jacente — correspondance Router ID et AS, ACL de couche transport, paramètres de voisinage par Loopback, itération de route, équilibrage de charge manquant, flap dû à la priorité — se transpose directement. Elle ne couvre pas en profondeur BGP FlowSpec, la validation d'origine RPKI, ni les scénarios BGP intégrés à SR-TE.

Voisin bloqué ou instable en ce moment ?

Indiquez-nous la colonne State exacte de display bgp peer, ou l'Error Code de display bgp peer log-info, et nous vous aiderons à l'interpréter.

WhatsApp avec un ingénieur →