Pannes PE-CE MPLS L3VPN : incohérences RT, fuites de routes et convergence lente
Une route VPN qui ne traverse pas jusqu'au PE distant, deux VPN qui fuient l'un dans l'autre, ou un réseau qui met deux minutes à reconverger après un redémarrage de PE — la plupart des tickets L3VPN se répartissent en quelques formes répétitives une fois la session BGP PE-PE elle-même confirmée saine. Voici l'ordre de diagnostic qui trouve la panne le plus vite, les commandes display exactes pour chaque étape, et les causes qui expliquent la plupart de ces cas.
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 cela commence par une session BGP fonctionnelle, pas par la configuration VPN
La moitié de ce qui ressemble à une panne L3VPN est en réalité une panne BGP ou LDP déguisée en VPN.
Si l'IBGP PE-PE lui-même n'atteint pas Established, c'est un problème de l'arbre de panne BGP avant d'être un problème L3VPN — consultez d'abord Le voisin BGP ne s'établit pas et les routes s'instabilisent : une checklist complète en premier. Une fois cette session confirmée saine, les pannes L3VPN se répartissent en quelques formes répétitives : une route qui ne traverse jamais jusqu'au PE distant (incohérences locales de VPN Target, collisions d'IP entre instances VPN, étiquettes manquantes, problèmes de relais inter-domaines, ou un réflecteur de route qui la filtre silencieusement), et une route qui traverse bien mais où quelque chose ne va toujours pas (instabilité de couche physique sous un VPN par ailleurs correct, ou convergence qui prend des minutes au lieu de secondes après une panne de PE).
Voici l'arbre de panne sur lequel ce texte s'appuie, les vérifications pour chaque étape 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 L3VPN se répartissent en exactement deux formes : la route ne traverse jamais jusqu'au PE distant, ou elle traverse 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 à dépanner la couche VPN alors que la panne réelle se situe une couche plus bas, dans l'IGP, le LDP ou la liaison physique sous-jacente.
Parcourir chaque étape
Quatre étapes, quatre ensembles différents de choses à examiner — et la commande qui vous dit exactement où une route cesse d'être visible.
Étape 0 — Confirmer que la route a bien quitté le CE
Avant de toucher à la configuration RT ou des étiquettes, confirmez que la route est même présente dans la table de routage VPN locale du PE proche.
- Faites d'abord un ping de CE à CE. S'il réussit, le chemin CE à CE va bien et la panne se situe entre l'hôte de l'utilisateur VPN et le CE — vérifiez cette route séparément.
- Si cela échoue, exécutez display ip routing-table sur les deux CE pour voir si l'un d'eux a même une route vers l'autre.
- Sur le PE, exécutez display ip routing-table vpn-instance vpn-instance-name pour confirmer que la route du CE est bien arrivée dans la table de routage VPN du PE — si elle n'y est pas, la panne se situe réellement dans la session CE-PE ou sa politique de route, pas en aval.
<PE> display ip routing-table vpn-instance vpna
// confirm the CE-advertised prefix is present before looking at RT, labels, or the far PE at allÉtape 1 — Correspondance RT / VPN Target et croisement local
La route est dans la table VPN locale, la session BGP PE-PE est Established, mais le PE distant ne l'a toujours pas — vérifiez la correspondance RT elle-même, et un point local moins évident.
- Exécutez display ip vpn-instance verbose sur les deux PE et confirmez que l'Export VPN Target de ce PE correspond à l'Import VPN Target du PE distant, et vice versa.
- Si deux VPN partagent délibérément le même RT pour une joignabilité inter-VPN contrôlée, confirmez aussi que les deux instances VPN ne sont pas liées à des adresses IP locales identiques sur le même PE — le croisement de routes local préfère silencieusement la route locale directe à la route BGP importée quand l'adressage entre en collision, et le VPN croisé ne fonctionne alors que dans un sens.
<PE> display ip vpn-instance verbose
VPN-Instance Name and ID : vpn1, 1
Route Distinguisher : 100:1
Export VPN Targets : 100:1
Import VPN Targets : 1:1
// Export/Import Targets compared directly against the far PE's own values
<PE1> display ip interface brief
Interface IP Address/Mask Physical Protocol VPN
10GE0/0/1 10.1.1.2/30 up up VPN-A
10GE0/0/2 10.1.1.2/30 up up VPN-B
// same IP bound to two different VPN instances -- local crossing picks the wrong routeÉtape 2 — Route présente mais pas valide/meilleure, ou ne peut atteindre un tunnel
La route apparaît dans la table BGP VPNv4 du PE distant, mais elle n'est jamais installée — la raison est presque toujours le tronçon suivant, le tunnel, ou une étiquette manquante.
- Exécutez display bgp vpnv4 vpn-instance vpn-instance-name routing-table <prefix> et confirmez que la route s'affiche valide et meilleure — sinon, vérifiez si la table de routage IP a même une route vers le tronçon suivant BGP (Original nexthop).
- Exécutez display bgp vpnv4 all routing-table <prefix> et cherchez un champ Relay Tunnel Out-Interface (confirme que la route peut réellement itérer vers un LSP) et un champ Label information (confirme qu'une étiquette privée a été allouée) — une route peut être valide et meilleure et pourtant ne jamais être utilisée si l'un des deux manque.
- Pour une conception Option-B inter-domaines en particulier, vérifiez le masque du Loopback de chaque ASBR intermédiaire sur le chemin — LDP n'alloue par défaut des étiquettes que pour des routes hôtes /32, donc un Loopback configuré avec tout autre masque casse silencieusement l'allocation d'étiquette pour ce FEC, et le LSP vers celui-ci ne se termine jamais même si BGP lui-même montre la route comme présente.
<HUAWEI> display bgp vpnv4 vpn-instance vpna routing-table 1.1.1.1
Relay IP Nexthop : 10.1.1.2
Original nexthop : 3.3.3.3
..., valid, internal, best, select, active, pre 255
<HUAWEI> display bgp vpnv4 all routing-table 10.2.1.2
Label information (Received/Applied): 13316/NULL
Relay IP Out-Interface: 10GE0/0/1
Relay Tunnel Out-Interface: 10GE0/0/1
// both fields present -- route can reach a real LSP with a real label
// cross-domain Option-B fix: ASBR Loopback was 1.1.1.2 255.255.255.252 (/30)
[ASBR1] interface loopback 0
[ASBR1-LoopBack0] ip address 1.1.1.2 32
[ASBR1] reset mpls ldpÉtape 3 — Un réflecteur de route la rejette silencieusement
La configuration des deux PE semble correcte isolément — le filtrage se produit sur le RR situé entre eux.
- Sur le RR, vérifiez display current-configuration configuration bgp sous ipv4-family vpnv4 pour policy vpn-target — cela active le filtrage VPN-Target sur le RR lui-même, et si le RR n'a pas d'instance VPN locale configurée pour ce RT, il rejette silencieusement toute route le portant.
- Vérifiez display ip extcommunity-filter pour une règle deny correspondant au RT de cette route, référencée par rr-filter sous la vue BGP-VPNv4 du RR — souvent un reliquat d'une politique de réflexion antérieure plus restrictive.
<RR> display ip extcommunity-filter
Extended Community filter Number 1
index: 10 deny rt : 100:1
index: 20 permit rt : 200:1
// RT 100:1 is being denied -- this PE's Export VPN Target never gets reflected
[RR] ip extcommunity-filter 1 permit rt 100:1
[RR] bgp 100
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] undo rr-filter
[RR-bgp-af-vpnv4] rr-filter 1Qualité : routes instables et convergence lente
La configuration VPN est correcte — la panne est une couche plus bas, ou dans la façon dont le basculement se produit réellement.
- Si un préfixe VPN spécifique flappe continuellement alors que la configuration VPN, RT et BGP est propre, descendez à partir du type de route : confirmez que le voisin IGP est stable, puis vérifiez display mpls lsp include <prefix>/32 pour un LSP LDP à durée de vie courte à côté d'un LSP RSVP/TE stable depuis longtemps — cette discordance pointe vers la session LDP, pas le VPN.
- Vérifiez display interface sur la liaison que la session LDP instable emprunte réellement — une interface physique qui bascule up/down est la couche où ce type de panne se situe généralement vraiment.
- Si la convergence après un redémarrage de PE prend de l'ordre de minutes plutôt que de secondes, vérifiez si les PE redondants annonçant le même préfixe CE partagent un Route Distinguisher identique — si oui, leurs routes VPNv4 sont traitées comme un seul chemin BGP plutôt que deux chemins à coût égal indépendants, et le basculement doit attendre que le RR confirme que la session de l'ancien PE a réellement disparu via une convergence IGP complète.
<DeviceA> display mpls lsp include 1.1.1.1 32
LSP Information: RSVP LSP ... TimeStamp: 1825411sec // stable for a long time
LSP Information: LDP LSP ... TimeStamp: 10sec // this one keeps resetting
[PE3] ip vpn-instance vpn-access
[PE3-vpn-instance-vpn-access] route-distinguisher 22:1
// distinct RD per PE turns the equal-cost VPNv4 paths into two independently comparable routes6 causes qui reviennent sans cesse
Une fois que les étapes ci-dessus vous ont indiqué où se situe le problème, ces six causes expliquent l'essentiel de ce qui ne va pas.
1. Deux VPN partagent un RT intentionnellement, mais aussi une adresse IP par accident
SYMPTÔMEUn VPN à RT partagé délibérément, conçu pour que deux instances VPN puissent se joindre, ne fonctionne que dans un sens.
CAUSELe croisement local sélectionne la mauvaise route quand deux instances VPN sur le même PE se retrouvent à lier leurs interfaces à des adresses IP identiques. Le PE préfère la route locale directe à la route BGP importée lors du croisement de routes local, donc le VPN croisé ne se résout jamais réellement dans ce sens, même si les RT correspondent correctement.
SOLUTIONDonnez à chaque instance VPN un adressage IP local distinct, puis reconstruisez le voisin BGP affecté une fois l'adressage changé.
<PE1> display ip interface brief
10GE0/0/1 10.1.1.2/30 up up VPN-A
10GE0/0/2 10.1.1.2/30 up up VPN-B // duplicate -- rebind to a distinct subnet2. RR configuré avec policy vpn-target mais sans instance VPN locale correspondante
SYMPTÔMEDeux PE derrière une paire redondante de réflecteurs de route ne voient pas du tout les routes VPNv4 l'un de l'autre, sans rien de manifestement anormal sur l'un ou l'autre PE.
CAUSEpolicy vpn-target sous ipv4-family vpnv4 indique au RR d'appliquer un filtrage VPN-Target à ce qu'il accepte. Si le RR lui-même n'a pas d'instance VPN configurée pour ce RT, il n'accepte silencieusement rien portant cet Import Target — une fonctionnalité de filtrage qui n'a de sens que sur un PE, appliquée à tort et discrètement à un rôle de pur réflecteur de route.
SOLUTIONSoit supprimez policy vpn-target sur le RR pour qu'il accepte et réfléchisse tout (l'approche courante pour un RR pur), soit ajoutez une instance VPN correspondante sur le RR uniquement pour lui donner le RT auquel se comparer.
[RR] bgp 100
[RR-bgp] ipv4-family vpnv4
[RR-bgp-af-vpnv4] undo policy vpn-target3. Option-B inter-domaines : un Loopback ASBR qui n'est pas un /32
SYMPTÔMEUne route VPNv4 Option-B fonctionne dans un sens à travers la frontière de domaine mais pas dans l'autre.
CAUSELDP n'alloue par défaut des étiquettes que pour des routes hôtes /32. Si le Loopback d'un ASBR intermédiaire est configuré avec un masque plus court, LDP ne peut pas construire d'étiquette pour ce FEC, le LSP vers celui-ci ne se termine jamais, et la route VPNv4 par ailleurs présente du PE distant n'est jamais installée — parce que son LSP sous-jacent n'est pas valide, pas parce que quelque chose ne va dans la configuration VPN.
SOLUTIONCorrigez le masque du Loopback à /32 sur l'ASBR affecté et exécutez reset mpls ldp pour forcer la resignalisation.
[ASBR1] interface loopback 0
[ASBR1-LoopBack0] ip address 1.1.1.2 32
[ASBR1] reset mpls ldp4. Un extcommunity-filter oublié bloque sélectivement la réflexion d'un RT
SYMPTÔMELe réflecteur de route accepte une route VPNv4 d'un PE, mais seuls certains des autres clients du RR l'apprennent jamais.
CAUSEUn ip extcommunity-filter référencé par rr-filter sous la vue BGP-VPNv4 du RR refuse ce RT spécifique — souvent un reliquat d'une politique de réflexion antérieure plus restrictive jamais reconsidérée lors de l'ajout de nouvelles instances VPN au réseau.
SOLUTIONAjoutez une entrée permit pour le RT (ou supprimez entièrement la référence du filtre) et réappliquez rr-filter.
<RR> display ip extcommunity-filter
index: 10 deny rt : 100:1
[RR] ip extcommunity-filter 1 permit rt 100:1
[RR-bgp-af-vpnv4] undo rr-filter
[RR-bgp-af-vpnv4] rr-filter 15. Une route instable qui est en réalité une liaison physique sous la couche LDP/IGP
SYMPTÔMEUn préfixe VPN spécifique flappe continuellement alors que la configuration VPN, le RT et la session BGP s'avèrent tous propres.
CAUSELa route privée emprunte un LSP dont le voisin IGP et le tunnel TE sont stables, mais la session LDP en dessous rebondit parce que l'interface physique sur laquelle elle repose flappe continuellement up/down — quelque chose qu'aucun dépannage de couche VPN ne fera jamais ressortir.
SOLUTIONDescendez à partir du type de route — BGP, puis IGP, puis LDP/RSVP, puis l'interface physique — plutôt que de supposer que la panne se situe dans la couche où le symptôme est visible ; une fois trouvée, traitez-la comme une panne physique ou optique, pas comme une panne VPN.
<DeviceA> display mpls ldp session
// LDP session itself shows as bouncing
<DeviceA> display interface 10GE0/0/0
Last physical up time : 2010-05-20 21:33:42
Last physical down time : 2010-05-20 21:31:58
// physical layer is where the flap actually originates6. Des chemins VPNv4 à coût égal partagent le même RD, donc le basculement attend l'IGP
SYMPTÔMEAprès un redémarrage de PE, les PE en aval mettent environ deux minutes à réapprendre le sous-réseau métier d'un CE via le PE survivant, au lieu de basculer immédiatement.
CAUSEQuand des PE redondants annonçant le même préfixe CE utilisent tous un Route Distinguisher identique, leurs routes VPNv4 sont traitées comme le même chemin BGP plutôt que comme deux chemins à coût égal indépendants. Les réflecteurs de route ne transfèrent un nouveau chemin qu'une fois qu'ils ont confirmé que la session IGP/BGP de l'ancien PE a réellement disparu, donc la convergence MPLS VPN suit derrière la convergence IGP complète.
SOLUTIONAttribuez à chaque PE un RD distinct pour l'instance VPN afin que les deux routes existent comme des chemins indépendants et comparables — l'un actif, l'autre immédiatement disponible — ou déployez VPN FRR.
[PE3] ip vpn-instance vpn-access
[PE3-vpn-instance-vpn-access] route-distinguisher 22:1
// PE4 keeps its own distinct RD -- PE5/PE6 now hold two independent, comparable pathsConceptions de solutions associées
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.
BGP semble Established et LDP va bien, mais un préfixe VPN spécifique ne traverse toujours pas jusqu'au PE distant — quel est le moyen le plus rapide de trouver où il est réellement bloqué ?
Parcourez la chaîne dans l'ordre plutôt que de deviner : la route est-elle valide et meilleure dans display bgp vpnv4 vpn-instance routing-table (sinon, le tronçon suivant BGP n'est probablement pas joignable) ; si valide mais non affichée comme envoyée, vérifiez la politique sortante côté expéditeur et la politique entrante côté récepteur ; si elle a été envoyée et reçue, vérifiez si elle itère vers un vrai tunnel (Relay Tunnel Out-Interface) et a réellement obtenu une étiquette privée (Label information) ; si tout cela est propre, la correspondance Export/Import du RT est l'endroit suivant, et le plus courant, où elle meurt silencieusement.
La route traverse bien PE1→PE2 mais pas PE2→PE1 — comment une panne peut-elle être unidirectionnelle ?
Cela signifie presque toujours que les deux sens utilisent en réalité des mécanismes sous-jacents différents qui se trouvent avoir l'air symétriques dans la configuration — un chemin Option-B inter-domaines où seul le Loopback d'un ASBR a le mauvais masque, ou une session IBGP où seul un côté manque de peer connect-interface loopback pour l'interface source de la session. Vérifiez le chemin de chaque sens indépendamment plutôt que de supposer une cause racine partagée.
L'Export et l'Import VPN Target semblent corrects sur les deux PE, mais les routes ne traversent toujours pas — que me manque-t-il ?
Confirmez que la correspondance RT n'est pas filtrée quelque part entre les deux PE plutôt qu'à l'un ou l'autre PE lui-même — le plus souvent un réflecteur de route avec policy vpn-target activé mais sans instance VPN locale pour ce RT, ou un extcommunity-filter oublié lié à rr-filter qui précède le VPN actuel. Les deux rejettent silencieusement la route sans rien de visible sur l'un ou l'autre PE.
Une route VPN flappe continuellement alors que personne n'a touché à la configuration VPN — où dois-je vraiment regarder ?
En dessous de la couche VPN. Confirmez que le voisin IGP et le tunnel (LDP ou RSVP-TE) portant cette route sont eux-mêmes stables avant de supposer que quelque chose ne va avec BGP ou l'instance VPN — un LSP à durée de vie courte remonte presque toujours à une interface physique instable ou un problème d'optique une couche plus bas.
La convergence après une panne de PE prend des minutes au lieu de secondes — est-ce normal pour MPLS VPN ?
Pas si les PE redondants sont censés offrir deux chemins à coût égal indépendants. Vérifiez s'ils utilisent le même Route Distinguisher pour l'instance VPN — si oui, leurs routes VPNv4 sont indiscernables en tant que chemin BGP unique, et le basculement doit attendre la convergence IGP complète avant même qu'un nouveau chemin soit visible. Des RD distincts par PE, ou VPN FRR, transforment cela en un basculement quasi instantané.
Limites honnêtes de cette note
Cette note s'articule autour du modèle de classification des pannes BGP/MPLS L3VPN du routeur Huawei série AR et de ses commandes display bgp vpnv4 / display ip vpn-instance / display mpls lsp, ainsi que des cas de terrain qui les sous-tendent. Si votre PE est d'un autre fournisseur, les commandes exactes changent, mais la logique sous-jacente — correspondance Export/Import du RT, itération de tunnel, filtrage par réflecteur de route, convergence pilotée par RD — se transpose directement. Elle ne couvre pas en profondeur les superpositions VPN basées sur EVPN, les variantes inter-AS Option-A/Option-C, ni les spécificités du VPN IPv6 (L3VPNv6) au-delà de ce qui est noté en ligne.
Route ne traversant pas, ou convergence trop lente ?
Indiquez-nous de quel PE la route est absente, ou combien de temps le basculement prend réellement, et nous vous aiderons à interpréter la sortie de display bgp vpnv4.