L'alarme hwNvo3VxlanTnlDown se déclenche, et un tunnel qui allait bien une minute plus tôt a disparu. Voici l'ordre qui permet de le rétablir en toute sécurité — quoi confirmer en premier, quoi rassembler avant de toucher à quoi que ce soit, les deux causes profondes qui expliquent la plupart de ces alarmes, et comment prouver que la correction a réellement fonctionné avant de clore le ticket.
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
Le réflexe lorsqu'une alarme se déclenche est de corriger la première chose qui semble anormale. Sur une alarme de tunnel VXLAN, ce réflexe cause plus de coupures qu'il n'en évite.
hwNvo3VxlanTnlDown signifie exactement une chose : un tunnel VXLAN qui était up est tombé. Cela ne dit pas pourquoi, et réagir au seul texte de l'alarme — redémarrer un processus, faire un bounce d'interface, pousser un changement de configuration — est la façon dont une alarme sur un seul tunnel se transforme en coupure plus large. Ce guide suit un ordre fixe : confirmer ce qui s'est réellement passé et jusqu'où cela s'étend, rassembler les preuves qui distinguent la cause profonde du bruit, traiter les deux causes qui expliquent la plupart de ces tickets, et vérifier que ce tunnel précis a récupéré avant de considérer le travail terminé.
Voici cet ordre avec les commandes exactes, la commande qui met le plus souvent fin à l'incident — un shutdown d'interface ciblé — et pourquoi il doit s'agir de la bonne interface, pas simplement d'une interface qui paraît instable.
Quatre étapes, un point de bifurcation — mieux vaut avoir ce schéma sous les yeux avant de toucher quoi que ce soit.
Le point de bifurcation est simple : la route vers le VTEP distant a-t-elle complètement disparu, ou est-elle présente mais instable ? Les deux réponses mènent à deux corrections totalement différentes, et appliquer la mauvaise gaspille les minutes qui comptent le plus lors d'une coupure en cours.
Les légendes du schéma restent en anglais pour la clarté technique.
Tout ce qui précède le point de bifurcation relève de la confirmation et de la collecte de preuves, pas de la remédiation — résistez à l'envie de corriger quoi que ce soit tant que vous ne savez pas de quel côté de la bifurcation vous êtes.
Quatre étapes : confirmer et délimiter, rassembler les preuves, appliquer la correction correspondante, vérifier ce tunnel précis — pas le réseau en général.
Avant de toucher à la moindre configuration, sachez ce qui est réellement cassé et jusqu'où cela s'étend.
%%01NVO3/4/hwNvo3VxlanTnlDown_active: The VXLAN tunnel changed from Up to Down.
(SourceAddress=4.4.4.100, DestinationAddress=3.3.3.100, TunnelId=4026531844)
// the alarm names the affected device and the tunnel's Source/Destination -> log in to that device, not a neighbor
<HUAWEI> display device
// rule out main control board / interface board faults before assuming this is a routing problemDeux commandes indiquent laquelle des deux causes profondes vous rencontrez — exécutez les deux avant de décider d'une correction.
<HUAWEI> display ip routing-table 3.3.3.100
<HUAWEI>
// no route to the peer VTEP -> the underlay route is genuinely gone, go to Stage 3a
<HUAWEI> display ospf peer brief
Peer Address Interface State
10.0.12.2 GE1/0/1 Full
// run this again a few seconds later, and again --
// a neighbor that comes and goes between runs is flapping, not just slow to reconvergeIl s'agit d'une véritable perte de chemin vers le pair, pas d'un symptôme d'instabilité — traitez-le comme une panne de routage/EVPN, pas une panne de tunnel.
C'est la correction qui résout réellement la plupart de ces alarmes — une coupure petite, délibérée, temporaire, pas un bounce d'interface au hasard.
[~HUAWEI] interface 10ge 1/0/1 // example only -- use the interface you identified as flapping
[~HUAWEI-10GE1/0/1] shutdown
[*HUAWEI-10GE1/0/1] commitUn ping fonctionnel ailleurs sur le fabric ne confirme pas que ce tunnel a récupéré — vérifiez le tunnel lui-même, par sa paire Source/Destination.
<HUAWEI> display vxlan tunnel
Tunnel ID Source Destination State Type Uptime
4026531844 4.4.4.100 3.3.3.100 up dynamic 00:00:42
// confirm State is up for this exact Source/Destination pair before closing the incidentUne fois que les quatre étapes ci-dessus ont indiqué où se situe l'incident, ces cinq points expliquent l'essentiel de ce qui surprend encore les gens.
SYMPTÔMEhwNvo3VxlanTnlDown ressemble à un problème VXLAN, donc le réflexe est d'aller d'abord regarder la configuration VXLAN ou NVE.
CAUSELe tunnel est un passager, pas la cause — il tombe parce que l'Underlay a cessé de pouvoir atteindre le VTEP distant. Toute correction réelle dans ce guide se situe dans le routage (route manquante ou voisin instable), jamais dans la configuration VXLAN/NVE elle-même.
SOLUTIONCommencez la collecte de preuves par la table de routage, pas par la configuration VXLAN — display ip routing-table vers le VTEP distant est la première commande qui compte réellement.
SYMPTÔMELe tunnel revient brièvement après un shutdown d'interface, puis l'incident empire — plus de trafic affecté, pas moins.
CAUSELe shutdown d'interface est une action ciblée et délibérée contre une adjacence instable précise identifiée à partir de sorties répétées de display ospf peer brief — pas un geste général « couper tout ce qui paraît instable ». Faire un shutdown de la mauvaise interface peut supprimer un chemin fonctionnel au lieu de celui qui est instable.
SOLUTIONConfirmez le voisin instable via plusieurs exécutions répétées de la commande avant de faire un shutdown quelconque, et ne faites un shutdown que de cette interface.
SYMPTÔMELa route vers le VTEP distant paraît correcte, OSPF n'est pas instable, et pourtant le tunnel reste down ou continue de se réactiver.
CAUSEUne carte de contrôle principale ou une carte d'interface défaillante peut produire exactement cette signature — des échecs de transfert intermittents qui ressemblent à un problème de routage depuis la CLI, alors que la panne réelle est matérielle. C'est pourquoi l'étape 1 vérifie l'état des cartes et les alarmes de gestion réseau avant même que l'étape 2 ne commence.
SOLUTIONSi les preuves de l'étape 2 ne pointent pas clairement vers une route manquante ou instable, revenez en arrière et écartez une panne de carte via la gestion réseau avant de passer plus de temps sur le routage.
SYMPTÔMEdisplay vxlan tunnel montre un State up quelques minutes après la correction, puis le tunnel retombe.
CAUSEUn tunnel qui revient à State up confirme seulement que le symptôme immédiat a disparu — cela ne confirme pas que le voisin instable identifié à l'étape 3b était bien le bon, ni que sa cause sous-jacente (une mauvaise optique, un lien défaillant, un équipement en amont instable) a été traitée. Un shutdown d'interface est explicitement une mesure provisoire dans ce guide, pas une correction de clôture.
SOLUTIONConsidérez la vérification de l'étape 4 comme confirmant que l'incident est stable, pas résolu — planifiez l'investigation de suivi sur la raison de l'instabilité de cette interface avant de clore complètement le ticket.
SYMPTÔMEUn tunnel n'est jamais monté du tout — display vxlan tunnel montre Down dès le départ, sans transition Up-vers-Down à alarmer.
CAUSEhwNvo3VxlanTnlDown signifie spécifiquement qu'un tunnel précédemment up est tombé — c'est une réponse d'urgence pour un tunnel actif et fonctionnel qui s'est cassé. Un tunnel qui ne s'est jamais établi du tout est un type de panne différent, dû à la mise en place initiale plutôt qu'à quelque chose qui casse un état fonctionnel.
SOLUTIONPour un tunnel qui n'est jamais monté, utilisez le chemin d'établissement de tunnel de notre note dédiée de dépannage du tunnel VXLAN plutôt que ce guide d'urgence — les causes et les corrections sont différentes.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Oui — c'est pourquoi l'étape 3b n'y recourt qu'après que l'étape 2 a déjà confirmé, via plusieurs vérifications répétées, exactement quel voisin est instable. C'est une action ciblée, fondée sur des preuves, sur une interface identifiée, pas une étape de dépannage à l'aveugle, et c'est explicitement la deuxième chose que ce guide essaie, pas la première.
La présence de la route confirme que le chemin Underlay existe, pas que VXLAN lui-même est sain — à ce stade, cela cesse d'être un incident de routage et devient une question d'établissement VXLAN/EVPN. Notre note de dépannage du tunnel VXLAN reprend exactement à partir de ce point.
À côté, pour un moment différent. Ce guide est destiné à l'urgence spécifique d'une alarme se déclenchant sur un tunnel qui fonctionnait un instant plus tôt — triage rapide, preuves, correction provisoire, vérification. La note de dépannage complète est destinée au travail de cause profonde plus poussé — problèmes de route EVPN, discordances de VPN-Target, échecs d'établissement de tunnel — vers lesquels les étapes de collecte de preuves de ce guide vous orientent.
Exécutez display ospf peer brief plusieurs fois de suite, à quelques secondes d'intervalle. Un voisin qui se remet d'un événement réel se stabilise et le reste ; un voisin instable continue d'apparaître et de disparaître au fil de vos exécutions répétées. Si vous n'exécutez la commande qu'une seule fois, vous ne pouvez pas faire la différence — c'est exactement pourquoi l'étape 2 demande des vérifications répétées, pas un seul coup d'œil.
L'interface que vous avez arrêtée à l'étape 3b est toujours down, et elle portait exactement la condition d'instabilité — une optique défaillante, un lien marginal, un voisin en amont instable. C'est un travail de suivi, pas un travail d'incident : planifiez l'investigation physique/optique et ne remettez pas l'interface en service tant que vous ne savez pas pourquoi elle était instable au départ.
Ce guide repose sur l'alarme hwNvo3VxlanTnlDown et les deux causes profondes — perte de route et instabilité de route — qui expliquent la plupart de ces tickets d'urgence. Il suppose que le tunnel était auparavant up et stable ; un tunnel qui ne s'est jamais établi du tout est une panne différente, traitée dans notre note de dépannage du tunnel VXLAN, pas ici. Il ne remplace pas non plus une investigation matérielle au niveau carte, que l'étape 1 vous demande d'écarter en premier sans la détailler, et il ne couvre pas la récupération orchestrée par contrôleur sur les fabrics SDN, où la même logique Underlay s'applique mais où les commandes diffèrent.
Dites-nous ce que montrent display ip routing-table et display ospf peer brief pour le tunnel affecté, et nous vous aiderons à trouver rapidement le point de bifurcation.