Un switch Leaf incapable de trouver la route vers une VM de destination est l'un des tickets les plus courants dans un fabric VXLAN BGP EVPN. Voici l'ordre de vérification qui trouve la panne le plus vite — confirmer que l'ARP est bien là, confirmer que la route est bien générée, confirmer qu'elle est bien apprise, et confirmer que le VPN Target la laisse bien passer.
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
La route manque pour l'une de ces quatre raisons exactement, et elles suivent un ordre strict — vérifiez-les dans cet ordre et vous arrêtez de deviner.
Sur un switch Leaf d'un fabric VXLAN BGP EVPN, « la route vers cette VM n'existe pas » ne signifie presque jamais que le fabric est cassé de bout en bout. Cela signifie qu'un maillon précis d'une chaîne à quatre maillons ne s'est pas achevé : le Leaf de destination n'a jamais appris l'ARP de la VM, ce Leaf n'a jamais transformé l'ARP en route EVPN, ce Leaf-ci n'a jamais appris la route annoncée par l'autre côté, ou la route est arrivée mais la communauté VPN Target ne l'a jamais laissée entrer dans la table de routage locale.
Voici la répartition des pannes sur laquelle ce texte s'appuie, les commandes display bgp evpn à exécuter à chaque étape, les causes qui reviennent sans cesse une fois passée la première vérification, et des réponses éprouvées sur le terrain aux questions qui reviennent autour de cette panne précise.
Les pannes de route EVPN manquante se répartissent en deux moitiés : le problème est encore sur le Leaf distant, ou le Leaf distant a fait son travail et le problème est dans ce qui est revenu vers celui-ci.
Placer d'abord le symptôme dans cette répartition indique s'il faut continuer à travailler sur le Leaf distant ou revenir travailler sur le local — ce qui évite un aller-retour vers le mauvais équipement.
Les légendes du schéma restent en anglais pour la clarté technique.
Les vérifications 1 et 2 ci-dessous se situent entièrement sur le Leaf distant ; les vérifications 3 et 4 se situent entièrement sur ce Leaf-ci. Rien concernant la joignabilité IP, la configuration VLAN ailleurs dans le fabric, ou le lien physique n'appartient à cet arbre — ce sont des pannes distinctes avec leurs propres vérifications.
Quatre vérifications, une commande chacune, et chacune indique s'il faut continuer ou aller corriger quelque chose de précis.
Si l'ARP n'est pas là, rien au-delà de ce point n'a encore d'importance — la route EVPN ne peut pas exister avant l'ARP.
<Leaf3> display arp network 192.168.1.11
ARP Entry Types: D - Dynamic, S - Static, I - Interface, O - OpenFlow, RD - Redirect
EXP: Expire-time VLAN:VLAN or Bridge Domain
IP ADDRESS MAC ADDRESS EXP(M) TYPE/VLAN INTERFACE VPN-INSTANCE
----------------------------------------------------------------------------------------
192.168.1.11 0019-9400-000b 1164 D/BD1012254 Eth-Trunk1.4 ABC
----------------------------------------------------------------------------------------
Total:1 Dynamic:1 Static:0 Interface:0 OpenFlow:0
Redirect:0
// ARP present -> move to check 2. Nothing here -> this is an ARP fault, not an EVPN fault.Une entrée ARP existant localement ne signifie pas qu'elle a été transformée en une route visible par le reste du fabric.
<Leaf3> display bgp instance overlay evpn all routing-table | include 192.168.1.11
Local AS number : 64888
BGP Local router ID is 172.31.58.20
Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
EVPN address family:
Number of Mac Routes: 82864
*> 0:48:0019-9400-000b:32:192.168.1.11 0.0.0.0
// 0.0.0.0 next-hop = this route was generated locally, on this LeafLe Leaf distant peut avoir annoncé une route parfaitement correcte et ce Leaf-ci peut quand même ne pas l'avoir — c'est un problème côté réception, pas côté génération.
<Leaf3> display bgp instance overlay evpn all routing-table mac-route 0:48:0019-9400-000b:32:192.168.1.11
BGP local router ID : 172.31.58.20
Local AS number : 64888
Total routes of Route Distinguisher(2101:1012254): 1
BGP routing table entry information of 0:48:0019-9400-000b:32:192.168.1.11:
Imported route.
Label information (Received/Applied): NULL/1012254 1010000
From: 0.0.0.0 (0.0.0.0)
Route Duration: 0d07h52m39s
Original nexthop: 172.31.58.138
Ext-Community: RT <0 : 1010000>, RT <0 : 1012254>, Tunnel Type <VxLan>, Router's MAC <0000-5e00-02c9>
Route Type: 2 (MAC Advertisement Route)
Advertised to such 1 peers:
10.124.138.251
// this is the remote Leaf's own advertised copy -- confirm it looks like this before checking the local sideC'est là que finissent presque tous les cas restants : la route est arrivée, et le VPN Target local ne la laisse toujours pas entrer dans la table de routage.
<Leaf1> display current-configuration configuration evpn-instance evpn10
evpn vpn-instance evpn10 bd-mode
route-distinguisher 1:10
vpn-target 1:100 10:1 export-extcommunity
vpn-target 10:1 import-extcommunity
// import-extcommunity must share at least one value with the Ext-Community RT the remote Leaf advertisedUne fois que les quatre vérifications 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 arp network <IP-VM> sur le Leaf distant ne remonte rien, et rien plus loin dans la chaîne EVPN n'a encore de quoi travailler.
CAUSELa route EVPN pour l'IP d'une VM est générée directement à partir de la table ARP/route hôte locale sur le Leaf auquel elle est rattachée — si l'ARP n'a jamais été appris (hôte éteint, mauvais VLAN, mauvaise interface d'accès, suppression ARP de la passerelle mal configurée), il n'existe tout simplement aucune donnée source à partir de laquelle construire une route EVPN.
SOLUTIONTraitez-la d'abord comme une panne d'apprentissage ARP sur le Leaf distant — vérifiez l'interface côté accès, l'appartenance VLAN/BD et la configuration de la passerelle — avant de toucher à quoi que ce soit lié à l'EVPN.
SYMPTÔMEL'ARP est confirmée présente sur le Leaf distant, mais display bgp instance overlay evpn all routing-table | include <IP-VM> ne remonte rien.
CAUSELa route MAC/IP n'est générée que si l'interface Vbdif du BD de cette VM est correctement liée à la bonne instance VPN et que l'instance EVPN correspondante est réellement configurée — une passerelle active mais liée à la mauvaise vpn-instance, ou une instance EVPN totalement absente pour ce BD, produit un Leaf qui a l'ARP et ne la transforme tout simplement jamais en route.
SOLUTIONConfirmez que display current-configuration interface vbdif <ID-BD> affiche le bon ip binding vpn-instance, et qu'une evpn vpn-instance existe et est liée à ce BD.
SYMPTÔMELa table EVPN propre du Leaf distant montre la route générée et annoncée, mais la table du Leaf local ne montre rien pour le même préfixe.
CAUSEUne route-policy BGP appliquée sur l'un ou l'autre Leaf, ou sur un réflecteur de route Spine entre les deux, peut filtrer une route EVPN de l'annonce sans produire aucune erreur ni entrée de journal — la route ne traverse tout simplement jamais vers l'autre côté.
SOLUTIONVérifiez la présence d'une route-policy configurée sous le pair BGP EVPN ou la famille d'adresses sur chaque équipement du chemin d'annonce, pas seulement les deux extrémités, et confirmez qu'elle ne correspond pas à ce préfixe ou RT précis.
SYMPTÔMELa route est confirmée présente dans la table EVPN du Leaf local (display bgp instance overlay evpn all routing-table mac-route <préfixe> la montre) mais elle n'atteint jamais la table de transfert/routage réelle.
CAUSEBGP EVPN n'accepte une route dans la table de routage que si au moins une des valeurs Ext-Community RT de la route correspond à l'une des valeurs import-extcommunity de l'instance EVPN locale — si les ensembles RT d'export et d'import ne se chevauchent pas du tout, la route est abandonnée silencieusement, sans rien dans les journaux.
SOLUTIONComparez l'import-extcommunity de display current-configuration configuration evpn-instance <nom> aux valeurs Ext-Community RT réellement annoncées par le côté distant (pas celles que vous supposez qu'il annonce), et ajustez la liste d'import locale pour inclure une valeur correspondante.
SYMPTÔMELa table EVPN locale montre deux entrées pour exactement le même préfixe, reçues de deux Router ID différents, l'une marquée not preferred for peer address, et cela est signalé comme « la route semble incorrecte ».
CAUSEDans tout fabric avec plus d'un Spine agissant comme réflecteur de route, la même route EVPN arrive légitimement deux fois — une fois reflétée par chaque Spine — et la sélection du meilleur chemin propre à BGP en choisit une comme active et marque l'autre comme non préférée. C'est un comportement normal de chemin redondant, pas la preuve d'une panne.
SOLUTIONConfirmez que les deux copies portent les mêmes Label information et valeurs Ext-Community RT ; si c'est le cas, ce n'est pas la cause du ticket de route manquante — continuez plutôt à vérifier le croisement VPN Target.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Le type de route 2 est une MAC Advertisement Route — le type de route EVPN qui porte l'adresse MAC d'un hôte et, quand l'IP de l'hôte est connue, son IP également. C'est ce que poursuit toute cette séquence de vérification. Le type 3 (Inclusive Multicast Route) construit le tunnel L2 lui-même, et le type 5 (IP Prefix Route) est ce qu'une passerelle IRB annonce pour tout un sous-réseau — une panne différente, traitée dans la note VXLAN Tunnel Won't Establish.
Vérifiez d'abord l'ARP. La route MAC/IP EVPN d'un hôte est générée à partir de l'entrée ARP apprise localement pour cet hôte — il n'y a aucune route à trouver dans la table EVPN si l'ARP n'a jamais été appris sur le Leaf auquel l'hôte est rattaché, donc commencer par la table EVPN sur un Leaf sans ARP ne fait que gaspiller une étape.
Oui, pour l'entrée ARP dynamique d'un seul hôte — cela ne fait qu'effacer et redéclencher l'apprentissage pour cette IP-là, pas toute la table ARP. C'est raisonnable à essayer une fois la configuration déjà confirmée correcte, mais c'est un contournement du symptôme, pas une correction ; si la route ne revient pas après une réinitialisation, la cause sous-jacente (RT incompatible, route-policy, instance EVPN manquante) est toujours là et doit être corrigée.
Confirmez que vous comparez la bonne paire : l'export-extcommunity du côté distant (ce qu'il a réellement mis sur le fil, visible dans le champ Ext-Community de la route reçue) par rapport à l'import-extcommunity de ce Leaf (pas sa propre valeur d'export, qu'il est facile de comparer par erreur). Une route n'a besoin de partager qu'une seule valeur RT entre ces deux champs précis, pas de correspondre à chaque RT configuré sur les deux Leaf.
Cette note suppose que le voisin BGP EVPN est Established et que le tunnel entre les deux VTEP existe déjà — le fabric fonctionne, mais la route d'un hôte précis manque. Si le pair BGP EVPN lui-même n'atteint jamais Established, ou si la route Inclusive Multicast / IP Prefix qui construit le tunnel ne se croise jamais du tout, c'est une panne différente traitée dans la note VXLAN Tunnel Won't Establish, qui commence une couche plus bas.
Quand c'est chaque hôte d'un Leaf plutôt qu'un seul hôte, montez les vérifications d'un niveau : confirmez que le pair BGP EVPN de ce Leaf est toujours Established (pas seulement l'était), et que sa configuration d'instance EVPN et de RT n'a pas été touchée lors d'un changement récent — une mauvaise configuration au niveau instance affecte tous les hôtes derrière elle à la fois, tandis qu'un seul ARP manquant n'affecte que cet hôte-là.
Cette note s'appuie sur le fabric à passerelle distribuée BGP EVPN de type Huawei CloudEngine et ses commandes display bgp instance overlay evpn / display arp network / display current-configuration configuration evpn-instance, ainsi que sur les cas de terrain qui les sous-tendent. Elle suppose que la relation de voisinage BGP EVPN et le tunnel VXLAN sous-jacent existent déjà — pour les pannes d'établissement de tunnel elles-mêmes, voir la note VXLAN Tunnel Won't Establish. Elle ne couvre pas le provisionnement automatique de routes orchestré par contrôleur (fabric SDN), où les mêmes symptômes peuvent remonter au contrôleur plutôt qu'à la configuration de l'équipement.
Dites-nous à laquelle des quatre vérifications ça échoue — ARP, génération de route, réception de route, ou VPN Target — avec la sortie display bgp evpn / display arp pertinente, et nous vous aiderons à l'interpréter.