Deux VM sur le même fabric VXLAN matériel n'arrivent pas à se joindre, ou le trafic entre elles se coupe par intermittence, et le chemin passe par un Spine qu'on ne peut pas simplement observer. Voici la méthode traditionnelle en deux étapes pour trouver l'équipement qui perd réellement les paquets — confirmer d'abord la base Underlay/Overlay, puis configurer des statistiques de flux pour localiser la perte.
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 méthode traditionnelle pour localiser une perte de paquets sur un fabric Spine-Leaf VXLAN matériel n'est pas une liste de quarante points à vérifier d'un coup — ce sont deux étapes, la seconde ne démarrant que lorsque la première revient propre.
Lorsque deux VM sur le même fabric n'arrivent pas à se joindre, ou que le trafic entre elles se coupe par intermittence, le réflexe est de récupérer d'un coup la configuration de chaque équipement sur le chemin. La méthode traditionnelle en deux étapes utilisée sur les fabrics Spine-Leaf VXLAN distribués matériels fait l'inverse : confirmer d'abord que la base Underlay et Overlay est réellement saine de bout en bout, et seulement ensuite — si cette base est vraiment confirmée — activer les statistiques de flux pour trouver le seul équipement du chemin qui perd réellement des paquets.
Voici les deux étapes avec les commandes display exactes, la configuration des statistiques de flux à cinq éléments qui identifie précisément le saut fautif, et les pièges qui surprennent même quand on applique correctement la méthode.
Les statistiques de flux de l'étape 2 sont mises en correspondance différemment à chaque saut de ce chemin — mieux vaut avoir ce schéma sous les yeux avant de configurer quoi que ce soit.
Voici le schéma d'accès le plus courant dans un fabric VXLAN distribué matériel : Server Leaf source, traversée du fabric via un Spine, passage par un Service/Border Leaf si la destination se trouve derrière l'un d'eux, retour par un Spine, puis arrivée au Server Leaf de destination. L'étape 2 n'a de sens que si le symptôme peut être situé sur ce chemin.
Les légendes du schéma restent en anglais pour la clarté technique.
Si l'étape 1 révèle une rupture — route manquante, tunnel Down, ARP ou route hôte manquante — corrigez-la directement ; il s'agit d'une simple erreur de configuration de routage, VXLAN ou EVPN, pas d'un mystère de perte de paquets, et notre note de dépannage du tunnel VXLAN traite ces causes en détail. Les statistiques de flux de l'étape 2 ne valent la peine d'être configurées que lorsque la base est réellement propre de bout en bout.
Cinq vérifications à l'étape 1, puis une configuration de statistiques de flux à cinq éléments à l'étape 2 — dans cet ordre, pas l'inverse.
Prenons l'exemple de VM1 (10.120.120.5, passerelle vBDIF111 sur le Server Leaf source) qui n'arrive pas à joindre VM2 (10.141.141.3, passerelle vBDIF222 sur le Server Leaf de destination) — cinq vérifications, chacune sur le Server Leaf source et sur celui de destination.
<SourceLeaf> display ip routing-table 3.3.3.100
Routing Table : Public
Destination/Mask Proto Pre Cost NextHop Interface
3.3.3.100/32 OSPF 10 2 10.0.12.2 GE1/0/1
// route to the peer NVE (Dest. Server Leaf) source address exists -> Underlay is reachable this direction
<SourceLeaf> display vxlan tunnel
Tunnel ID Source Destination State Type Uptime
4026531844 4.4.4.100 3.3.3.100 up dynamic 9:14:02
// State up, Type dynamic -> tunnel itself is fine, not the problem here
<SourceLeaf> display arp interface vbdif 111
IP ADDRESS MAC ADDRESS EXP(M) TYPE VLAN/CEVLAN INTERFACE
10.141.141.3 0019-9400-000b 18 dynamic BD1012254 Eth-Trunk1.4
// destination VM's ARP is learned
<SourceLeaf> display ip routing-table vpn-instance ABC 10.141.141.3
Destination/Mask Proto Pre Cost Flags NextHop Interface
10.141.141.3/32 IBGP 255 0 RD 3.3.3.100 VXLAN
// EVPN host route to VM2 is present -> repeat steps 4-5 on Dest. Server Leaf for VM1's ARP/host routeOn n'y arrive que lorsque l'étape 1 est entièrement propre des deux côtés. Les statistiques de trafic fonctionnent sur le cinq-uplet, mais ne prennent en charge que le sens entrant — et le format du paquet diffère à chaque saut.
// example flow: source 192.168.20.2, destination 192.168.10.2, VNI 5001
// match rule differs by hop on the reference path:
// Source Server Leaf : if-match acl xxx (original packet, pre-VXLAN)
// Spine (transit) : if-match vxlan transit tag-format none
// Service/Border Leaf : if-match vxlan tag-format none
// Dest. Server Leaf : if-match vxlan tag-format none
[SourceLeaf] acl number 3001
[SourceLeaf-acl-adv-3001] rule 5 permit ip source 192.168.20.2 0 destination 192.168.10.2 0
[SourceLeaf] traffic classifier c_flow
[SourceLeaf-classifier-c_flow] if-match acl 3001
[SourceLeaf] traffic behavior b_count
[SourceLeaf-behavior-b_count] statistic enable
[SourceLeaf] traffic policy p_count
[SourceLeaf-trafficpolicy-p_count] classifier c_flow behavior b_count
[SourceLeaf] interface vbdif 111
[SourceLeaf-Vbdif111] traffic-policy p_count inbound
// repeat the equivalent classifier + policy, matched to that hop's packet format, on Spine / Service Leaf / Dest. Server Leaf
<SourceLeaf> display traffic-policy statistic interface Vbdif111 inbound verbose
// compare this counter against the same query on the next hop down the path ->
// the first hop where the count doesn't carry through is the dropping deviceUne fois que les deux étapes ci-dessus ont indiqué où se situe le problème, ces cinq causes expliquent l'essentiel de ce qui ne va vraiment pas — y compris quelques façons de se tromper soi-même tout en appliquant correctement la méthode.
SYMPTÔMEdisplay ip routing-table vers l'adresse du NVE distant revient vide sur un Server Leaf mais semble correct sur l'autre — l'étape 1 a semblé réussir simplement parce qu'un seul sens a été vérifié.
CAUSELa convergence IGP/BGP vers les adresses loopback n'est pas toujours symétrique — un changement de coût IGP, une politique de routage ou un filtre sur un seul équipement peut laisser le chemin retour sans route vers le VTEP distant alors que le chemin aller paraît parfaitement normal.
SOLUTIONEffectuez la vérification de la table de routage sur le Server Leaf source et sur celui de destination, chacun vers l'adresse source NVE de l'autre, avant de conclure que l'étape 1 est réussie.
SYMPTÔMEdisplay vxlan tunnel montre un State à down pour le tunnel du chemin de référence, alors que les autres tunnels du même équipement sont up.
CAUSEUn tunnel VXLAN ne monte que lorsqu'il existe une route vers le VTEP distant ; si cet état Down échappe à un coup d'œil rapide à l'étape 1, tout ce qui suit — ARP, routes hôtes, statistiques de flux — finit par être vérifié sur un chemin qui n'allait de toute façon jamais transporter de trafic.
SOLUTIONTraitez un tunnel Down comme une panne à part entière, pas comme un symptôme de perte de paquets — travaillez d'abord notre note de dépannage du tunnel VXLAN, puis revenez à cette méthode une fois le tunnel confirmé up.
SYMPTÔMEL'étape 4 (ARP) réussit sur les deux Server Leaf, mais l'étape 5 (la route hôte EVPN) est absente d'un côté.
CAUSELe Server Leaf distant a bien converti l'entrée ARP en route EVPN et l'a annoncée — mais une discordance de VPN-Target, un filtre de politique de routage, ou une collision de Router-ID sur le réflecteur de route ont empêché l'autre côté de jamais l'accepter dans sa table de routage.
SOLUTIONIl s'agit d'une erreur de configuration routage/EVPN, pas d'une panne matérielle du fabric — l'analyse approfondie des discordances de VPN-Target et du filtrage par le réflecteur de route se trouve dans notre note de dépannage du tunnel VXLAN ; corrigez cela avant de passer à l'étape 2.
SYMPTÔMELes statistiques de flux affichent des compteurs propres à chaque saut, pourtant le ping entre VM continue de perdre des paquets.
CAUSELes statistiques de trafic ne prennent en charge que le sens entrant, et le format du paquet change à chaque saut : le premier équipement NVE voit le paquet original, avant VXLAN, et a besoin d'un classificateur basé sur une ACL, tandis que chaque équipement en aval voit un paquet encapsulé VXLAN et a besoin d'un classificateur vxlan tag-format. Réutilisez la mauvaise règle if-match sur le mauvais saut et le compteur de cet équipement n'augmente tout simplement jamais — sans rien vous dire sur l'endroit où se situe réellement la perte.
SOLUTIONFaites correspondre le classificateur au saut : if-match acl sur le Server Leaf source, if-match vxlan transit tag-format none sur les Spine de transit, if-match vxlan tag-format none sur les Leaf qui terminent le tunnel.
SYMPTÔMELe symptôme semble intermittent — certains pings passent, d'autres non — et relancer le même test ne le reproduit pas de manière constante.
CAUSEL'ECMP sur plusieurs Spine hache selon le cinq-uplet ; un simple ping réutilise toujours le même uplet et retombera toujours sur le même chemin, ce qui peut masquer une panne sur un Spine qu'un autre flux aurait atteint, ou faire paraître intermittent un Spine réellement défaillant si certains flux l'évitent complètement.
SOLUTIONFaites varier délibérément le cinq-uplet lors des tests — différents ports source, pas seulement des pings répétés — ou fiez-vous aux compteurs de statistiques de flux de l'étape 2 plutôt qu'au seul ping pour décider si un segment de chemin donné est réellement propre.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Parce que la convergence Underlay et EVPN n'est pas garantie symétrique. Une route, une entrée ARP ou une route hôte peut être présente dans un sens et absente dans l'autre, et ne vérifier que le Leaf source vous raconte la mauvaise moitié de l'histoire précisément quand cela compte le plus.
Vous pouvez, mais cela gaspille une passe de configuration. Chacune des cinq vérifications de l'étape 1 s'exécute plus vite que la mise en place de classificateurs, comportements et politiques à chaque saut, et un simple problème de routage, d'état de tunnel, d'ARP ou de route hôte apparaît immédiatement à l'étape 1 sans besoin de statistiques du tout.
Cette méthode lit des compteurs et des tables que vous configurez à la main, saut par saut — elle fonctionne sur n'importe quel fabric VXLAN distribué matériel et ne nécessite rien de plus qu'un accès CLI. Une plateforme d'analyse basée sur un contrôleur automatise la même idée — enregistrements de perte de paquets, traçage de flux, vérifications de chemin conscientes de la topologie — et vous mène plus vite à la réponse si elle est déployée, mais la logique sous-jacente est identique : confirmer la base, puis localiser la perte.
Oui, et c'est la raison pour laquelle le classificateur à chaque saut doit correspondre à ce que cet équipement précis reçoit réellement — le paquet original au premier saut NVE, un paquet encapsulé VXLAN partout ensuite. Configurer le compteur du mauvais côté d'un saut, ou faire correspondre le mauvais format de paquet, est la façon la plus courante d'obtenir une lecture faussement « propre » avec cette méthode.
À ce stade, le fabric lui-même a effectivement été mis hors de cause. Vérifiez si un changement de configuration manuel a été apporté à un équipement du chemin autour du moment où la panne a commencé, et si les compteurs restent réellement propres sur tout le chemin de référence, traitez cela comme un problème côté nœud de calcul ou application, et coordonnez-vous avec l'équipe IT/serveurs plutôt que de continuer à chercher dans le réseau.
Cette note repose sur la méthode traditionnelle en deux étapes, pilotée par la CLI, pour les fabrics Spine-Leaf VXLAN distribués matériels — d'abord la base Underlay/Overlay, puis les statistiques de flux à cinq éléments. Elle suppose une panne déjà placée sur le chemin VM-à-VM montré ci-dessus ; un tunnel Down, ou une route EVPN qui n'a jamais traversé, sont des pannes à part entière traitées en détail dans notre note de dépannage du tunnel VXLAN, non répétées ici. Elle ne couvre pas non plus les plateformes d'analyse basées sur un contrôleur qui automatisent la même logique de localisation — là où l'une est déployée, elle vous mènera généralement plus vite à la réponse que la méthode manuelle décrite ici. Pour le même arbre de décision à trois sources (optique, couche physique/CRC, rejets) appliqué à un seul lien plutôt qu'à un chemin de fabric multi-sauts, voir notre note sur la perte de paquets en campus.
Dites-nous à quelle étape vous êtes bloqué — la base Underlay/Overlay ou les statistiques de flux — ainsi que la sortie display, et nous vous aiderons à l'interpréter.