Accueil / Notes techniques / Dépannage de l'overlay VXLAN

Pannes de l'overlay VXLAN : migration de VM, état du tunnel et traçage du trafic

Un tunnel VXLAN affichant Up ne signifie pas que le trafic qui vous intéresse le traverse réellement. Voici l'ordre de diagnostic qui sépare les quatre choses qui tombent réellement en panne sur un fabric VXLAN basé sur EVPN — l'état du tunnel, une migration de VM qui perd des paquets pendant 20 secondes, des comptages de trafic au niveau paquet des deux côtés du tunnel, et si le trafic d'un utilisateur donné a même atteint l'overlay.

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 l'overlay masque la panne

Le tunnel est une abstraction. Chacune de ces pannes finit par se loger dans l'underlay, le plan de contrôle, ou une simple adresse MAC mal interprétée en dessous.

Le rôle entier de VXLAN est de faire disparaître un réseau underlay et de le remplacer par un overlay d'apparence plate. C'est précisément ce qui rend les pannes ici déroutantes : display vxlan tunnel peut afficher Up alors que le vrai trafic métier va ailleurs, ou le tunnel peut être parfaitement sain pendant qu'une tempête de routes EVPN totalement sans rapport bloque une migration de VM pendant vingt secondes. La façon la plus rapide de s'en sortir reste la même discipline que toujours — confirmer l'état réel du tunnel, puis faire correspondre le symptôme au cas précis qu'il évoque, plutôt que de deviner d'abord la configuration BGP EVPN.

Voici la suite : une topologie VXLAN Spine-Leaf pour situer la panne, l'ordre pour vérifier l'état du tunnel avant de toucher à quoi que ce soit d'autre, un cas réel de perte de paquets lors d'une migration de VM remonté à une tempête de routes EVPN sur le Route Reflector, des statistiques de trafic au niveau paquet côté accès et à l'intérieur du tunnel, comment confirmer que le trafic d'un utilisateur a réellement atteint l'overlay, cinq causes racines récurrentes, et des réponses de FAQ éprouvées sur le terrain.

Lisez le fabric avant de lire le moindre compteur

Border Leaf, Spine faisant office de route reflector, paires de Server Leaf en double rattachement M-LAG des hôtes — les tunnels VXLAN circulent de leaf à leaf sur un plan de contrôle BGP EVPN qui n'apparaît jamais dans la topologie physique.

Chaque cas ci-dessous suppose cette forme : des VTEP sur les paires de Server Leaf construisant des tunnels VXLAN dynamiques via BGP EVPN, le Spine ne faisant office que de route reflector — il réfléchit les routes EVPN, il n'origine pas lui-même de VTEP.

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

C'est le plan de contrôle EVPN qui rend ce fabric différent à dépanner d'un réseau commuté classique : une route qui n'est jamais reflétée, ou un mappage VNI-vers-bridge-domain erroné sur un leaf, produit exactement le même trou noir qu'un câble sectionné — sans aucun symptôme physique.

Vérifier l'état du tunnel, puis traiter le cas précis

Quatre investigations différentes, quatre jeux de commandes différents — et la discipline de vérifier d'abord l'état du tunnel avant de présumer laquelle s'applique.

Confirmer l'état du tunnel avant de présumer une panne VXLAN

display vxlan troubleshooting exécute le diagnostic automatique propre à Huawei et indique la raison en clair — à lire avant d'ouvrir un dossier sur autre chose.

Vérifiez d'abord display vxlan tunnel. Si State est Down, c'est votre point de départ, pas la table de routes EVPN.
Exécutez display vxlan troubleshooting pour obtenir directement une Event Description — par exemple, tunnel down parce que la route vers l'adresse source ou destination est inaccessible, ou parce qu'aucune route hôte 32 bits n'existe.
Confirmez avec display bgp evpn peer que le voisin EVPN ayant construit ce tunnel est réellement Established, pas seulement que l'objet tunnel existe.
Confirmez avec display ip routing-table que la table de routage IP de l'underlay possède bien une route vers l'adresse loopback source ou destination du pair.

<HUAWEI> display vxlan tunnel
Number of vxlan tunnel : 1
Tunnel ID    Source                Destination           State
40000001     10.1.1.1              10.1.1.2              down
// state is down -- this is where to start, not the EVPN route table

<HUAWEI> display vxlan troubleshooting
Vxlan Tunnel Troubleshooting Information:
 Tunnel ID       : 40000001
 Event Description : The tunnel is Down because the route to the destination
                      is unreachable, or no 32-bit host route exists for it.

<HUAWEI> display bgp evpn peer
 Peer            V    AS  MsgRcvd  MsgSent  OutQ  Up/Down   State  PrefRcv
 10.1.1.2        4  65001      120      118     0  00:12:40  Established     6

<HUAWEI> display ip routing-table
Destination/Mask    Proto  Pre  Cost      Flags NextHop     Interface
10.1.1.2/32          O_ASE 150  1         D     10.0.0.2    GE1/0/1
// a /32 route to the destination loopback must exist, not just a summary route

Cas : migration de VM perdant des paquets pendant plus de 20 secondes

Ici, le tunnel n'est pas le problème — c'est la file d'attente d'envoi sortante du route reflector.

Symptôme : la migration de VM sur ce fabric perd des paquets pendant plus de 20 secondes, bien au-delà de ce que prévoit la conception.
Cause racine : des mises à jour de routes EVPN fréquentes (généralement pilotées par MAC/ARP) congestionnent la file d'attente d'envoi du route reflector plus vite qu'il ne peut vider les routes vers chaque pair, si bien que la nouvelle position de la VM n'est pas annoncée à temps.
Vérifiez display bgp evpn update-peer-group pour trouver le Group ID gérant les pairs concernés.
Dans la vue diagnose, vérifiez display bgp evpn update-peer-group index <id> verbose — un compteur UptPeerGrp PktBuffer non nul signifie que le route reflector n'a pas fini d'envoyer les mises à jour à ce groupe.
Correctif : augmentez le temps de vieillissement des MAC dynamiques sur Server Leaf et Border Leaf, du défaut de 300 secondes à environ 1800 secondes, réduisant le taux de churn de routes piloté par les MAC ; puis confirmez que le compteur UptPeerGrp PktBuffer revient à 0.

<HUAWEI> display bgp evpn update-peer-group
 Group ID   PeerNumber  Description
 3          24          EVPN-RR-Group

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display bgp evpn update-peer-group index 3 verbose
 UptPeerGrp PktBuffer   : 214
// non-zero -- the RR has not finished flushing updates to this peer group

[HUAWEI] mac-address aging-time 1800
// default is 300s; raising it reduces MAC-driven EVPN route churn

[HUAWEI-diagnose] display bgp evpn update-peer-group index 3 verbose
 UptPeerGrp PktBuffer   : 0
// confirms the send queue has cleared after the change

Statistiques de trafic au niveau paquet — côté accès et à l'intérieur du tunnel

L'interface côté accès voit le paquet d'origine ; l'interface côté tunnel le voit encapsulé dans un en-tête VXLAN — c'est pourquoi les deux côtés nécessitent des méthodes de correspondance différentes.

Côté accès, construisez une ACL simple correspondant à l'IP source/destination du trafic à comptabiliser, puis liez-la à une politique de trafic sur l'interface d'accès.
Côté tunnel, le paquet porte désormais un en-tête VXLAN, donc le classificateur de trafic doit référencer explicitement le paquet interne avec if-match vxlan transit acl.
Appliquez la politique côté tunnel à l'interface de tunnel VXLAN (ou à l'interface orientée NVE) dans le sens sortant ou entrant selon besoin, puis relevez les compteurs avec display traffic-policy statistics.

[HUAWEI] acl 3000
[HUAWEI-acl-adv-3000] rule 5 permit ip source 10.10.1.0 0.0.0.255 destination 10.10.2.0 0.0.0.255

[HUAWEI] traffic classifier c_access
[HUAWEI-classifier-c_access] if-match acl 3000
[HUAWEI] traffic behavior b_access
[HUAWEI-behavior-b_access] statistic enable
[HUAWEI] traffic policy p_access
[HUAWEI-trafficpolicy-p_access] classifier c_access behavior b_access
[HUAWEI] interface GigabitEthernet1/0/1
[HUAWEI-GigabitEthernet1/0/1] traffic-policy p_access inbound

// tunnel side -- match the inner packet through the VXLAN header
[HUAWEI] traffic classifier c_tunnel
[HUAWEI-classifier-c_tunnel] if-match vxlan transit acl 3000
[HUAWEI] traffic policy p_tunnel
[HUAWEI-trafficpolicy-p_tunnel] classifier c_tunnel behavior b_access

<HUAWEI> display traffic-policy statistics interface GigabitEthernet1/0/1 inbound
 Classifier: c_access
   Matched     : 128664 packets / 96 Mbytes

Comment confirmer que le trafic d'un utilisateur a bien atteint le réseau VXLAN

Un VNI correspond 1:1 à un bridge domain ; une fois que l'on sait comment le VTEP décide à quel bridge domain appartient une trame, juger si un utilisateur est dedans ou dehors devient une vérification en trois étapes.

Vérifiez si l'adresse MAC de l'utilisateur a été apprise dans le bridge domain attendu avec display mac-address bridge-domain. Si oui, la trame est dans l'overlay ; sinon, passez à l'étape suivante.
Vérifiez l'interface d'accès et sa configuration de sous-interface pour déterminer si l'utilisateur est censé arriver via un accès basé VLAN ou via une sous-interface avec terminaison 802.1Q.
Vérifiez les VLAN ou sous-interfaces liés au bridge domain avec display bridge-domain <id> — si le VLAN ou la sous-interface de l'utilisateur n'y figure pas, le trafic ne peut pas atteindre l'overlay, aussi correct que semble être le reste.

<HUAWEI> display mac-address bridge-domain 10
MAC Address    VLAN/VSI/BD  Learned-From        Type
5489-98aa-1122 -/-/10       Eth-Trunk1.10        dynamic
// user's MAC is learned into BD 10 -- the frame is in the overlay

<HUAWEI> display this
interface Eth-Trunk1.10
 encapsulation dot1q vid 10
 bridge-domain 10
// confirms this is sub-interface access with 802.1Q termination into BD 10

<HUAWEI> display bridge-domain 10
 Bridge-domain 10 information:
  Binding interface : Eth-Trunk1.10, Eth-Trunk2.10
// if the user's own VLAN/sub-interface is not bound here, it never reaches the overlay

5 causes racines qui reviennent sans cesse

Une fois que les vérifications ci-dessus vous ont indiqué laquelle des quatre investigations s'applique, ces cinq causes expliquent l'essentiel des problèmes réels.

1. Le churn de routes EVPN inonde la file d'attente d'envoi du route reflector

SYMPTÔMELa migration de VM entraîne une perte de paquets de plus de 20 secondes — bien au-delà de ce que prévoit la conception.

CAUSEDes mises à jour de routes EVPN fréquentes dépassent la capacité du route reflector à vider sa file d'attente d'envoi vers tous les pairs ; la nouvelle position de la VM n'est pas annoncée à temps, donc le trafic continue d'aller vers l'ancien leaf pendant l'intervalle.

CORRECTIFAugmentez le temps de vieillissement des MAC dynamiques sur Server Leaf et Border Leaf par rapport au défaut de 300 secondes pour réduire le taux de churn, puis confirmez que le compteur UptPeerGrp PktBuffer est revenu à 0.

[HUAWEI] mac-address aging-time 1800

2. Alarme de flapping MAC due à une collision entre la VM et la passerelle

SYMPTÔMEL'équipement signale une alarme de flapping MAC et le trafic de la VM devient intermittent.

CAUSEL'adresse MAC d'une VM entre en collision avec la propre MAC de la passerelle L3 VXLAN — par exemple sur une interface VBDIF — donc chaque trame vue par le réseau semble provenir de deux endroits à la fois.

CORRECTIFVérifiez display mac-address flapping-record pour la MAC en flapping, croisez-la avec display interface vbdif <id>, puis changez la MAC de la VM ou de la passerelle, ou supprimez purement et simplement une interface VBDIF inutilisée.

<HUAWEI> display mac-address flapping-record
 MAC Address      VLAN/BD   Times    Last-Time
 5489-98aa-3344   10        16        2026-07-18 09:14:02

<HUAWEI> display interface vbdif 10
Vbdif10 current state : UP
 Hardware address is 5489-98aa-3344
// same MAC as the flapping VM -- collision with the gateway's own address

3. Tunnel down car la route vers la source ou la destination est inaccessible

SYMPTÔMEdisplay vxlan tunnel affiche l'état du tunnel comme down ; les VM derrière ne peuvent pas se joindre entre datacenters.

CAUSEAucune route — ni route hôte 32 bits — n'existe vers l'adresse loopback source ou destination du tunnel ; display vxlan troubleshooting le nomme directement dans son Event Description.

CORRECTIFConfirmez que le voisin EVPN est Established, puis vérifiez la table de routage IP de l'underlay pour une route vers l'adresse manquante ; corrigez le protocole de routage sous-jacent, pas la configuration VXLAN elle-même.

4. La table de réplication head-end n'est jamais construite

SYMPTÔMEdisplay vxlan peer affiche zéro pair pour un VNI qui devrait avoir la réplication head-end configurée ; les VM entre datacenters ne peuvent pas se joindre.

CAUSEGénéralement une mauvaise configuration de l'interface NVE — mauvaise adresse source, ou mauvais protocole de peer-list head-end — ou un voisin EVPN qui n'est jamais monté du tout.

CORRECTIFVérifiez la configuration de l'interface NVE par rapport à la conception de référence, puis confirmez l'état du voisin EVPN avec display bgp evpn peer.

<HUAWEI> display vxlan peer vni 10010
Total 0 peer.
// expected head-end replication peers, but none learned

<HUAWEI> display this
interface Nve1
 source 10.1.1.1
 vni 10010 head-end peer-list protocol bgp
// confirm source address and protocol match the reference config on every leaf

5. Route EVPN jamais apprise car un VPN-Target ne correspond pas, ou l'ARP distant n'a jamais été converti

SYMPTÔMEdisplay ip routing-table vpn-instance n'affiche rien du tout pour une VM de destination censée être joignable — pas de route, pas une route erronée.

CAUSETrois suspects habituels : le leaf distant n'a jamais appris l'entrée ARP de la VM de destination ; une route-policy sur l'un des leaf filtre la route EVPN ; ou les attributs de communauté étendue VPN-target des deux leaf ne se croisent pas, si bien que la route est générée localement mais rejetée à la réception.

CORRECTIFConfirmez d'abord que la table ARP du leaf distant contient bien la destination avec display arp network <ip> ; vérifiez si la route locale a été générée avec le bon route-target via display bgp instance evpn all routing-table mac-route ; si rien n'est filtré et que les route-targets correspondent, cherchez une route-policy appliquée au pair BGP.

<HUAWEI> display arp network 10.10.2.20
// empty -- the local leaf never learned this VM's ARP entry, so no route was ever generated

<HUAWEI> display bgp instance vpn1 evpn all routing-table mac-route
 Route Distinguisher: 10.1.1.1:1
 VPN-Target       : 65001:10010 export, 65001:10010 import
// compare export community on the originating leaf against import on the receiving leaf

Cinq questions auxquelles il vaut mieux avoir une réponse prête

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

Faire tourner VXLAN nécessite-t-il une License distincte ?

VXLAN est soumis à une License (CE-LIC-VXLAN), mais sur les commutateurs CloudEngine, elle est préinstallée et préactivée en usine — il n'y a rien à activer manuellement.

L'encapsulation VXLAN a poussé la longueur de mes paquets au-delà de ce qu'autorisent les commutateurs underlay — et maintenant ?

VXLAN ajoute 54 octets de surcharge à chaque paquet d'origine, ce qui suffit à dépasser le MTU d'un commutateur underlay classique et à être silencieusement rejeté. Choisissez la combinaison que le matériel underlay prend en charge : augmentez la longueur de trame Jumbo que l'underlay laisse passer au-delà de la longueur du paquet VXLAN, augmentez plutôt le MTU de l'interface underlay au-delà, ou placez la passerelle VXLAN elle-même sur du matériel capable de fragmenter et réassembler, afin que l'underlay n'ait jamais à traiter de trame surdimensionnée.

VXLAN prend-il en charge IPv6 ?

Oui des deux côtés — le réseau overlay transporté à l'intérieur du tunnel et le réseau underlay sur lequel le tunnel lui-même circule peuvent chacun être indépendamment en IPv6.

J'ai activé les statistiques de trafic du tunnel VXLAN et l'équipement a commencé à signaler une alarme d'instabilité du chip LANSWITCH — ai-je cassé quelque chose ?

Vous avez atteint une limite de ressources de comptage matériel, pas une véritable panne. Lorsque l'interface sortante du tunnel est un port membre VLAN et que vous empilez les statistiques de port entrant, les statistiques de tunnel, les statistiques tunnel+VNI, les statistiques de bridge domain et les propres statistiques du VLAN sortant les unes sur les autres, vous dépassez la capacité de compteurs par flux du moteur de transfert — les statistiques VLAN cessent silencieusement de fonctionner et le chip déclenche l'alarme d'instabilité. Désactivez l'une quelconque des fonctionnalités de statistiques empilées et les deux problèmes disparaissent.

display vxlan tunnel indique que le tunnel est up mais les VM derrière ne se parlent toujours pas — par où commencer ?

Deux vérifications, dans l'ordre. D'abord, display bgp evpn peer — confirmez que le voisin EVPN ayant construit ce tunnel est réellement Established, pas seulement que l'objet tunnel existe ; une session qui a flappé et s'est rétablie discrètement peut laisser le tunnel up alors que les routes n'ont pas encore été réapprises. Ensuite, display mac-address bridge-domain — confirmez que la MAC de destination a bien été apprise dans le bridge domain attendu. Un tunnel qui affiche Up tout en protégeant le mauvais bridge domain, ou un autre assis derrière une session EVPN périmée, se ressemblent tous deux exactement à « tunnel up, rien ne fonctionne » vu de l'extérieur.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'appuie sur le modèle VXLAN basé sur BGP EVPN du manuel de maintenance V300 des séries Huawei CloudEngine 16800/9800/8800/6800 — display vxlan tunnel / vxlan troubleshooting / vxlan peer / bgp evpn peer, ainsi que sur les cas de terrain qui les sous-tendent. Si votre fabric utilise un VXLAN basé sur le multicast sans EVPN, ou une passerelle overlay d'un autre fournisseur, les commandes exactes changent, mais l'ordre de diagnostic — état du tunnel, voisin du plan de contrôle, route underlay, puis le trafic lui-même — s'applique directement. Elle ne couvre pas en profondeur les cas particuliers du multi-homing EVPN (ESI) ni les spécificités de l'overlay VXLAN IPv6.

Bloqué sur un tunnel VXLAN en particulier ?

Dites-nous ce qu'affichent display vxlan troubleshooting et display bgp evpn peer, ainsi que laquelle de ces quatre formes ça correspond, et nous vous aiderons à l'interpréter.

WhatsApp avec un ingénieur →