hwNvo3VxlanTnlDown fires and a tunnel that was fine a minute ago is gone. This is the order that gets it back safely — what to confirm first, what to gather before you change anything, the two root causes that account for most of these alarms, and how to prove the fix actually worked before you close the ticket.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The instinct when an alarm fires is to fix the first thing that looks wrong. On a VXLAN tunnel alarm, that instinct causes more outages than it prevents.
hwNvo3VxlanTnlDown means exactly one thing: a VXLAN tunnel that was up has gone down. It doesn't tell you why, and reacting to the alarm text alone — restarting a process, bouncing an interface, pushing a configuration change — is how a single-tunnel alarm turns into a wider outage. This runbook follows a fixed order: confirm what actually happened and how far it reaches, gather the evidence that tells root cause apart from noise, work the two causes that account for most of these tickets, and verify the specific tunnel recovered before calling it done.
What follows is that order with the exact commands, the one command that most often ends the incident — a targeted interface shutdown — and why it has to be the right interface, not just any interface that looks unstable.
Four steps, one branch point — worth having the picture in front of you before you touch anything.
The branch point is simple: is the route to the peer VTEP missing entirely, or is it there but flapping? The two answers lead to two completely different fixes, and running the wrong one wastes the minutes that matter most in an active outage.
Diagram labels are kept in English for engineering clarity.
Everything above the branch point is confirmation and evidence-gathering, not remediation — resist fixing anything until you know which side of the branch you're on.
Four stages: confirm and scope, gather evidence, apply the matching fix, verify the specific tunnel — not the network in general.
Before touching any configuration, know what's actually broken and how far it reaches.
%%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 problemTwo commands tell you which of the two root causes you're dealing with — run both before deciding on a fix.
<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 reconvergeThis is a genuine loss of path to the peer, not a flapping symptom — treat it as a routing/EVPN fault, not a tunnel fault.
This is the fix that actually resolves most of these alarms — a small, deliberate, temporary cut, not a random interface bounce.
[~HUAWEI] interface 10ge 1/0/1 // example only -- use the interface you identified as flapping
[~HUAWEI-10GE1/0/1] shutdown
[*HUAWEI-10GE1/0/1] commitA working ping elsewhere on the fabric doesn't confirm this tunnel recovered — check the tunnel itself, by its Source/Destination pair.
<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 incidentOnce the four stages above have told you where the incident sits, these five explain most of what still catches people out.
SYMPTOMhwNvo3VxlanTnlDown looks like a VXLAN problem, so the instinct is to go looking at VXLAN or NVE configuration first.
CAUSEThe tunnel is a passenger, not the cause — it goes down because the underlay stopped being able to reach the peer VTEP. Every real fix in this runbook happens in routing (a missing route or a flapping neighbor), never in the VXLAN/NVE configuration itself.
FIXStart evidence-gathering at the routing table, not the VXLAN configuration — display ip routing-table toward the peer VTEP is the first command that actually matters.
SYMPTOMThe tunnel comes back briefly after an interface shutdown, then the incident gets worse — more traffic affected, not less.
CAUSEInterface shutdown is a targeted, deliberate action against one specific flapping adjacency identified from repeated display ospf peer brief output — not a general “shut down anything that looks unstable” move. Shutting down the wrong interface can remove a working path instead of the flapping one.
FIXConfirm the flapping neighbor across multiple repeated command runs before shutting anything down, and shut down only that interface.
SYMPTOMThe route to the peer VTEP looks fine, OSPF isn't flapping, and yet the tunnel stays down or keeps re-flapping.
CAUSEA failing main control board or interface board can produce exactly this signature — intermittent forwarding failures that look like a routing problem from the CLI, when the actual fault is hardware. This is why Stage 1 checks board status and network-management alarms before Stage 2 even starts.
FIXIf Stage 2's evidence doesn't cleanly point to a missing or flapping route, go back and rule out a board fault via network management before spending more time on routing.
SYMPTOMdisplay vxlan tunnel shows State up minutes after the fix, then the tunnel drops again.
CAUSEA tunnel recovering State up only confirms the immediate symptom cleared — it doesn't confirm the flapping neighbor identified in Stage 3b was actually the right one, or that its underlying cause (a bad optic, a failing link, an unstable upstream device) has been addressed. An interface shutdown is explicitly a stopgap in this runbook, not a close-out fix.
FIXTreat Stage 4's verification as confirming the incident is stable, not resolved — schedule the follow-up investigation into why that interface was flapping before the ticket is fully closed.
SYMPTOMA tunnel never came up in the first place — display vxlan tunnel shows Down from the start, with no Up-to-Down transition to alarm on.
CAUSEhwNvo3VxlanTnlDown specifically means a previously-up tunnel went down — it's an emergency response for a live, working tunnel that broke. A tunnel that never established at all is a different kind of fault, driven by the initial setup rather than something breaking a working state.
FIXFor a tunnel that never came up, use the dedicated VXLAN tunnel troubleshooting note's tunnel-establishment path instead of this emergency runbook — the causes and the fixes are different.
Pulled straight from the field — the ones worth having an answer ready for.
Yes — which is why Stage 3b only reaches for it after Stage 2 has already confirmed, across multiple repeated checks, exactly which neighbor is flapping. It's a targeted, evidence-based action on one identified interface, not a blind troubleshooting step, and it's explicitly the second thing this runbook tries, not the first.
Route presence confirms the underlay path exists, not that VXLAN itself is healthy — at that point this stops being a routing incident and becomes a VXLAN/EVPN establishment question. Our VXLAN tunnel troubleshooting note picks up from exactly this point.
Alongside it, for a different moment. This runbook is for the specific emergency of an alarm firing on a tunnel that was working a moment ago — fast triage, evidence, a stopgap fix, verification. The full troubleshooting note is for the deeper root-cause work — EVPN route problems, VPN-Target mismatches, tunnel-establishment failures — that this runbook's evidence-gathering steps point you toward.
Run display ospf peer brief several times in a row, a few seconds apart. A neighbor recovering from a real event settles into a stable state and stays there; a flapping neighbor keeps appearing and disappearing across your repeated runs. If you only run the command once, you can't tell the difference — that's exactly why Stage 2 calls for repeated checks, not a single look.
The interface you shut down in Stage 3b is still down, and it was carrying whatever the flapping condition actually was — a failing optic, a marginal link, an unstable upstream neighbor. That's follow-up work, not incident work: schedule the physical/optical investigation and don't bring the interface back up until you know why it was flapping in the first place.
This runbook is built around the hwNvo3VxlanTnlDown alarm and the two root causes — route loss and route flapping — that account for most of these emergency tickets. It assumes the tunnel was previously up and stable; a tunnel that never established at all is a different fault, covered in our VXLAN tunnel troubleshooting note, not here. It also doesn't replace a board-level hardware investigation, which Stage 1 tells you to rule out first but doesn't walk through in detail, and it doesn't cover controller-orchestrated recovery on SDN fabrics, where the same underlay logic applies but the commands differ.
Tell us what display ip routing-table and display ospf peer brief show for the affected tunnel, and we'll help you find the branch point fast.