Un tunnel VXLAN qui ne monte jamais du tout est une panne différente de celui qui est actif mais oscille, ou actif mais auquel il manque une route. Voici l'ordre couche par couche qui la trouve — le voisin BGP EVPN, la route qui construit réellement le tunnel, et le croisement VPN Target qui décide si cette route est acceptée.
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
Un tunnel qui ne s'établit jamais échoue exactement à l'une de trois couches, et la couche dépend qu'il s'agisse d'un tunnel L2 ou L3.
Dans un fabric à passerelle distribuée BGP EVPN VXLAN, le tunnel entre deux VTEP n'est pas configuré directement — il est construit dynamiquement une fois la bonne route reçue. Un tunnel L2 est construit à partir d'une route Inclusive Multicast de type 3 ; un tunnel L3 est construit à partir d'une route IP Prefix de type 5 (aussi appelée route IRB). L'une ou l'autre route n'est acceptée que si la liste d'import VPN Target locale chevauche ce que le côté distant a exporté. Un tunnel qui ne s'établit pas du tout échoue alors à l'une de ces trois couches exactement : le voisin BGP EVPN lui-même, la route qui construit ce type de tunnel précis, ou le croisement VPN Target qui décide si la route est admise.
C'est différent d'un tunnel qui monte puis tombe plus tard, ou d'un tunnel qui existe mais dont une route précise à l'intérieur manque — ce sont des pannes qui leur sont propres, référencées en croisement à la fin de cette note. Voici la répartition en trois couches, les vérifications display bgp evpn pour les tunnels L2 et L3 côte à côte, les causes derrière chaque couche, et des réponses éprouvées sur le terrain.
Les échecs d'établissement de tunnel VXLAN se répartissent d'abord par type de tunnel — L2 ou L3 — puis par les mêmes trois couches sous-jacentes aux deux.
Un tunnel L2 et un tunnel L3 partagent la couche 1 (le voisin BGP EVPN) mais divergent à la couche 2, car ils sont construits à partir de deux types de routes EVPN différents, avec deux commandes de configuration différentes à vérifier.
Les légendes du schéma restent en anglais pour la clarté technique.
La couche 1 est partagée — corrigez le voisin une fois et les deux types de tunnel en bénéficient. Les couches 2 et 3 sont propres au type de tunnel que vous traquez, et les commandes diffèrent réellement entre elles.
Une couche partagée, puis deux couches propres à chaque tunnel avec leur propre type de route et leur propre commande VPN Target.
Aucun des deux types de tunnel ne peut rien construire avant que cette couche soit solide — vérifiez-la d'abord, que vous traquiez une panne L2 ou L3.
<VTEP2> display bgp evpn peer
BGP local router ID : 10.3.3.3
Local AS number : 100
Total number of peers : 2 Peers in established state : 2
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
10.1.1.1 4 100 4010 4016 0 0066h46m Established 1
10.2.2.2 4 100 4009 4010 0 0066h40m Established 4
<VTEP2> ping -a 10.2.2.2 10.3.3.3
Reply from 10.3.3.3: bytes=32 time=1ms TTL=126
Ping statistics for 10.3.3.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
// loopback-to-loopback reachable -> if peer still isn't Established, check TCP session state next
<VTEP2> display tcp status
TCPCB Tid/Soid Local Add:port Foreign Add:port VPNID State
49f3370c 262/8 10.2.2.2:53342 10.3.3.3:179 0 Established
49f339f4 262/7 10.2.2.2:55160 10.1.1.1:179 0 Established
// clean Established state here -> the neighbor layer is not the problemUn tunnel L2 entre deux VTEP est construit entièrement à partir de ce seul type de route — s'il n'est pas là, le tunnel non plus.
<VTEP2> display current-configuration interface nve 1
interface Nve1
source 10.2.2.2
vni 10 head-end peer-list protocol bgp
<VTEP2> display bgp evpn all routing-table inclusive-route 0:32:10.2.2.2
Total routes of Route Distinguisher(1:10): 1
BGP routing table entry information of 0:32:10.2.2.2:
Imported route.
From: 0.0.0.0 (0.0.0.0)
Ext-Community: RT <1 : 100>, RT <10 : 1>, Tunnel Type <VxLan(8)>
Route Type: 3 (Inclusive Multicast Route)
Advertised to such 2 peers:
10.3.3.3
10.1.1.1
// From: 0.0.0.0 = generated locally; check the same prefix for the remote VTEP's source address nextUn tunnel L3 est construit à partir de la route IP Prefix de la passerelle — même idée, type de route et commande différents.
<VTEP2> display current-configuration interface vbdif 10
interface Vbdif10
ip binding vpn-instance vpn1
ip address 192.168.10.1 255.255.255.0
<VTEP2> display bgp evpn all routing-table prefix-route 0:24:192.168.20.0
Total routes of Route Distinguisher(3:100): 1
BGP routing table entry information of 0:192.168.20.0:24:
Ext-Community: RT <1 : 100>, Tunnel Type <VxLan(8)>
Route Type: 5 (Ip Prefix Route)
VPN-Instance vpn1, Router ID 10.2.2.2:
BGP routing table entry information of 192.168.20.0/24:
Relay Tunnel Out-Interface: VXLAN
// showing up under VPN-Instance vpn1, not just the EVPN address family, is what confirms the L3 tunnel can actually use itLa route est arrivée ; le côté local doit encore la laisser entrer — et la commande qui contrôle cela diffère entre tunnels L2 et L3.
// L2 -- EVPN instance, no "evpn" keyword
<VTEP2> display current-configuration configuration evpn-instance evpn10
evpn vpn-instance evpn10 bd-mode
vpn-target 1:100 10:1 export-extcommunity
vpn-target 10:1 import-extcommunity
// L3 -- VPN instance, "evpn" keyword required
<VTEP2> display current-configuration configuration vpn-instance vpn1
ip vpn-instance vpn1
ipv4-family
vpn-target 1:100 export-extcommunity evpn
vpn-target 1:100 import-extcommunity evpn
vxlan vni 100Une fois que les trois couches ci-dessus ont indiqué où se situe le problème, ces cinq causes expliquent l'essentiel de ce qui ne va vraiment pas.
SYMPTÔMEdisplay bgp evpn peer montre un pair bloqué indéfiniment dans un état non-Established, et rien en aval — ni route Inclusive, ni route IP Prefix — n'a de quoi se construire.
CAUSELes routes de construction des tunnels L2 et L3 circulent toutes deux sur la même session BGP EVPN, et cette session est sourcée depuis une Loopback sur chaque VTEP. Si l'IGP entre les deux VTEP ne porte pas réellement de route vers la Loopback du pair, la session TCP derrière BGP ne peut absolument pas se former, et cela ressemble à un problème EVPN alors que c'est réellement un problème IGP.
SOLUTIONFaites un Ping depuis l'adresse source Loopback locale directement vers la distante (ping -a <local> <distant>) avant de toucher à toute configuration EVPN ou VPN-target — si cela échoue, corrigez d'abord la route IGP.
SYMPTÔMELes deux Loopbacks se ping mutuellement sans problème, mais display bgp evpn peer n'atteint toujours pas Established.
CAUSELa joignabilité entre les deux loopbacks confirme que le routage va bien, mais ne confirme pas que la session TCP BGP elle-même survit au chemin — une ACL de défense CPU, une limite de débit CPCAR, ou un middlebox quelque part entre les deux peut abandonner discrètement le trafic du port TCP 179 tandis que l'ICMP passe encore proprement.
SOLUTIONVérifiez display tcp status pour l'état réel de la session entre les deux Router ID ; si elle n'est pas proprement Established, cherchez des limites CPCAR ou des ACL sur le chemin qui affectent spécifiquement le port TCP 179, pas seulement la joignabilité générale.
SYMPTÔMEdisplay bgp evpn all routing-table inclusive-route sur le VTEP d'origine montre la route avec From: 0.0.0.0 et la liste comme annoncée au pair distant — mais la recherche du VTEP distant lui-même pour le même préfixe ne remonte rien.
CAUSELa route Inclusive Multicast du tunnel L2 n'est acceptée côté distant que si l'import-extcommunity de l'instance EVPN de ce VTEP partage une valeur avec le RT avec lequel la route a été exportée — sans chevauchement, la route est abandonnée silencieusement à l'arrivée, sans erreur d'un côté ni de l'autre.
SOLUTIONComparez l'import-extcommunity de l'instance evpn du VTEP distant directement aux valeurs Ext-Community RT affichées sur la route annoncée du côté d'origine, pas à ce que vous supposez avoir été configuré.
SYMPTÔMELa route IP Prefix semble correctement générée et apparaît même dans la famille d'adresses EVPN sur le VTEP récepteur, mais le tunnel vers cette passerelle ne se construit toujours pas et le sous-réseau reste injoignable.
CAUSEUn tunnel L3 a besoin que son VPN Target soit configuré sous l'ipv4-family de l'instance VPN avec le mot-clé evpn final (vpn-target ... export-extcommunity evpn / import-extcommunity evpn) — le configurer comme un simple vpn-target sans ce mot-clé, ou le configurer sous l'instance EVPN à la place (là où appartient la forme L2), laisse la route visible au niveau EVPN mais jamais résolue dans la table de routage propre de l'instance VPN.
SOLUTIONConfirmez avec display current-configuration configuration vpn-instance <nom> que les lignes export/import-extcommunity portent bien toutes deux le mot-clé evpn, et que la route apparaît spécifiquement sous l'entrée VPN-Instance dans la sortie de la table de routage, pas seulement dans la section famille d'adresses EVPN au-dessus.
SYMPTÔMEAprès avoir résolu un problème d'établissement de tunnel L2 entre deux VTEP, le tunnel L3 entre les deux mêmes équipements ne monte toujours pas, et cela donne l'impression que la correction précédente n'a pas fonctionné.
CAUSELes deux types de tunnel ne partagent que la couche voisin BGP EVPN — tout ce qui est au-dessus (le type de route, le niveau de configuration VPN Target, la commande import/export spécifique) est indépendant entre L2 et L3. Corriger une incompatibilité RT au niveau de l'instance EVPN ne fait rien pour une incompatibilité RT au niveau de l'instance VPN sur le même boîtier.
SOLUTIONTraitez une correction L2 et une correction L3 comme deux tickets distincts sur la même paire de voisins, et relancez les vérifications de couche 2 et couche 3 pour chaque type de tunnel séparément, même après que l'autre a été confirmé fonctionnel.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Established confirme seulement que la session de plan de contrôle BGP EVPN entre les deux VTEP est active. Le tunnel lui-même a encore besoin que son type de route — Inclusive Multicast pour L2, IP Prefix pour L3 — soit généré, annoncé, reçu, et accepté via le croisement VPN Target. Un voisin sain avec une route manquante ou rejetée ne produit toujours aucun tunnel.
Inclusive Multicast (type de route 3) construit un tunnel VXLAN L2 — elle est liée à l'adresse source NVE du VTEP et ne porte aucune information d'hôte, juste « ce VTEP existe et est joignable pour ce VNI ». IP Prefix (type de route 5) construit un tunnel L3 — elle est liée à un sous-réseau de passerelle (Vbdif) spécifique et c'est ce qu'une passerelle IRB annonce pour que d'autres VTEP puissent router vers ce sous-réseau à travers elle.
Vérifiez à quel niveau de commande vous l'avez réellement configuré. Pour un tunnel L2, le VPN Target se trouve sous l'instance EVPN (evpn vpn-instance ... vpn-target ... export/import-extcommunity, pas de mot-clé final) ; pour un tunnel L3, il se trouve sous l'ipv4-family de l'instance VPN avec le mot-clé evpn (vpn-target ... export/import-extcommunity evpn). Des numéros RT identiques en apparence configurés au mauvais niveau, ou l'oubli du mot-clé evpn côté L3, produisent exactement ce symptôme.
Cette note suppose que le tunnel n'a littéralement jamais monté — aucun état Established BGP EVPN, ou aucune route Inclusive/IP Prefix jamais acceptée. Si le tunnel s'est établi puis tombe, oscille, ou monte bien mais qu'une migration de VM ou un flux de trafic spécifique se comporte étrangement, ce sont des vérifications différentes — voir la note Pannes d'overlay VXLAN, qui reprend à partir d'un tunnel qui existe déjà.
Si chaque vérification de route de cette note revient propre — voisin Established, route Inclusive ou IP Prefix générée et reçue, VPN Target qui se chevauche — et que le tunnel ne transfère toujours pas de trafic, la panne a dépassé l'établissement du tunnel pour entrer dans une autre catégorie : vérifiez si c'est la route EVPN d'un hôte précis qui manque plutôt que le tunnel lui-même, traité dans la note Route EVPN non apprise.
Oui — chaque commande de cette note est en lecture seule, sauf le ping loopback-à-loopback utilisé pour tester la joignabilité, qui ne touche pas au plan de données du fabric. Aucune n'exige de changement de configuration juste pour diagnostiquer, donc il n'y a aucune raison d'attendre une fenêtre de maintenance avant d'exécuter ces vérifications.
Cette note s'appuie sur le fabric à passerelle distribuée BGP EVPN de type Huawei CloudEngine et ses commandes display bgp evpn peer / display bgp evpn all routing-table inclusive-route / prefix-route / display current-configuration configuration evpn-instance / vpn-instance, ainsi que sur les cas de terrain qui les sous-tendent. Elle suppose une conception EVPN VXLAN standard à deux niveaux (L2 + L3) et ne couvre pas le provisionnement automatique underlay/overlay orchestré par contrôleur (fabric SDN), où ces mêmes symptômes peuvent remonter au contrôleur plutôt qu'à la configuration d'équipement montrée ici.
Dites-nous à quelle couche ça bloque — voisin, route, ou VPN Target — plus s'il s'agit d'un tunnel L2 ou L3, et la sortie display bgp evpn pertinente, et nous vous aiderons à l'interpréter.