A VXLAN tunnel showing Up doesn't mean the traffic you care about is actually crossing it. This is the diagnostic order that separates the four things that actually go wrong on an EVPN-based VXLAN fabric — tunnel state, a VM migration that drops packets for 20 seconds, packet-level traffic counts on both sides of the tunnel, and whether a specific user's traffic ever reached the overlay at all.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The tunnel is an abstraction. Every one of these faults turns out to live in the underlay, the control plane, or a single misread MAC address underneath it.
VXLAN's whole job is to make an underlay network disappear and leave a flat-looking overlay in its place. That is exactly why faults here are confusing: display vxlan tunnel can say Up while the real business traffic is going somewhere else entirely, or the tunnel can be perfectly healthy while a completely unrelated EVPN route storm is stalling a VM migration for twenty seconds. The fastest way through any of it is the same discipline as always — confirm the state the tunnel is actually in, then match the symptom to the specific case it resembles, rather than guessing at the BGP EVPN configuration first.
What follows is a Spine-Leaf VXLAN topology to place the fault on, the order to verify tunnel state before touching anything else, a real case of VM migration packet loss traced to an EVPN route storm at the Route Reflector, packet-based traffic statistics for both the access side and inside the tunnel, how to confirm a user's traffic actually reached the overlay, five recurring root causes, and field-tested FAQ answers.
Border Leaf, Spine acting as route reflector, Server Leaf pairs dual-homing hosts over M-LAG — the VXLAN tunnels run leaf-to-leaf across a BGP EVPN control plane that never appears in the physical topology.
Every case below assumes this shape: VTEPs on the Server Leaf pairs building dynamic VXLAN tunnels via BGP EVPN, with the Spine acting purely as a route reflector — it reflects EVPN routes, it doesn't originate a VTEP itself.
Diagram labels are kept in English for engineering clarity.
The EVPN control plane is what makes this fabric different to troubleshoot from a plain switched network: a route that never gets reflected, or a VNI-to-bridge-domain mapping that's wrong on one leaf, produces exactly the same black hole as a severed cable — with none of the physical symptoms.
Four different investigations, four different sets of commands — and the discipline of checking tunnel state first before assuming any one of them applies.
display vxlan troubleshooting runs Huawei's own automatic diagnosis and reports the reason in plain text — read that before opening a case on anything else.
<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 routeThe tunnel isn't the problem here — the route reflector's outbound send queue is.
<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 changeThe access-side interface sees the original packet; the tunnel-side interface sees it wrapped in a VXLAN header — that's why the two sides need different match methods.
[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 MbytesA VNI maps 1:1 to a bridge domain; once you know how the VTEP is deciding which bridge domain a frame belongs to, judging whether a user is in or out becomes a three-step check.
<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 overlayOnce the checks above have told you which of the four investigations applies, these five account for most of what's actually wrong.
SYMPTOMVM migration causes packet loss lasting more than 20 seconds — well past what the design expects.
CAUSEFrequent EVPN route updates outpace the route reflector's ability to flush its send queue to all peers; the VM's new location isn't advertised in time, so traffic keeps going to the old leaf during the gap.
FIXRaise the dynamic MAC aging time on Server Leaf and Border Leaf from the 300-second default to cut the churn rate, then confirm the UptPeerGrp PktBuffer count is back to 0.
[HUAWEI] mac-address aging-time 1800SYMPTOMThe device reports a MAC flapping alarm and VM traffic becomes intermittent.
CAUSEA VM's MAC address collides with the VXLAN L3 gateway's own MAC — for example, on a VBDIF interface — so every frame the network sees looks like it's coming from two places at once.
FIXCheck display mac-address flapping-record for the flapping MAC, cross-reference it against display interface vbdif <id>, then change the VM's MAC or the gateway's, or remove an unused VBDIF interface entirely.
<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 addressSYMPTOMdisplay vxlan tunnel shows the tunnel State as down; VMs behind it can't reach each other across data centers.
CAUSENo route — or no 32-bit host route — exists to the tunnel's source or destination loopback address; display vxlan troubleshooting names this directly in its Event Description.
FIXConfirm the EVPN neighbor is Established, then check the underlay IP routing table for a route to the missing address; fix the underlying routing protocol, not the VXLAN configuration itself.
SYMPTOMdisplay vxlan peer shows zero peers for a VNI that should have head-end replication configured; VMs across data centers can't reach each other.
CAUSEUsually an NVE interface misconfiguration — a wrong source address, or a wrong head-end peer-list protocol — or an EVPN neighbor that never came up in the first place.
FIXCheck the NVE interface configuration against the reference design, then confirm the EVPN neighbor state with 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 leafSYMPTOMdisplay ip routing-table vpn-instance shows nothing at all for a destination VM that should be reachable — no route, not a wrong one.
CAUSEThree usual suspects: the remote leaf never learned the destination VM's ARP entry in the first place; a route-policy on either leaf is filtering the EVPN route; or the two leafs' VPN-target extended-community attributes don't intersect, so the route is generated locally but discarded on receipt.
FIXConfirm the remote leaf's ARP table has the destination first with display arp network <ip>; check whether the local route was generated with the right route-target via display bgp instance evpn all routing-table mac-route; if nothing is filtered and the route-targets match, check for a route-policy applied to the BGP peer.
<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 leafPulled straight from the field — the ones worth having an answer ready for.
VXLAN is gated by a License (CE-LIC-VXLAN), but on CloudEngine switches it ships pre-installed and pre-activated from the factory — there's nothing to activate by hand.
VXLAN adds 54 bytes of overhead to every original packet, and that's enough to exceed a plain underlay switch's MTU and get silently dropped. Pick whichever combination the underlay hardware supports: raise the Jumbo frame length the underlay allows through past the VXLAN packet length, raise the underlay interface MTU past it instead, or put the VXLAN gateway itself on hardware that can fragment and reassemble, so the underlay never has to deal with an oversized frame at all.
Yes on both sides — the overlay network carried inside the tunnel and the underlay network the tunnel itself runs over can each independently be IPv6.
You hit a hardware counting-resource limit, not a real fault. When the tunnel's outbound interface is a VLAN member port and you stack ingress port statistics, tunnel statistics, tunnel-plus-VNI statistics, bridge-domain statistics and the outbound VLAN's own statistics on top of each other, you exceed the forwarding engine's per-flow counter capacity — the VLAN statistics silently stop working and the chip raises the instability alarm. Disable any one of the stacked statistics features and both problems clear.
Two checks, in order. First, display bgp evpn peer — confirm the EVPN neighbor that built this tunnel is genuinely Established, not just that the tunnel object exists; a session that flapped and quietly re-established can leave the tunnel up while routes haven't been relearned yet. Second, display mac-address bridge-domain — confirm the destination MAC was actually learned into the bridge domain you expect. A tunnel that shows Up while protecting the wrong bridge domain, or one sitting behind a stale EVPN session, both look identical to “tunnel up, nothing works” from the outside.
This note is built around the Huawei CloudEngine 16800/9800/8800/6800 series V300 maintenance manual's BGP EVPN-based VXLAN model — display vxlan tunnel / vxlan troubleshooting / vxlan peer / bgp evpn peer and the field cases behind them. If your fabric uses multicast-based VXLAN without EVPN, or a different vendor's overlay gateway, the exact commands change, but the diagnostic order — tunnel state, control-plane neighbor, underlay route, then the traffic itself — carries over directly. It doesn't cover EVPN multi-homing (ESI) edge cases or IPv6 VXLAN overlay specifics in depth.
Tell us what display vxlan troubleshooting and display bgp evpn peer show, plus which of these four shapes it matches, and we'll help you read it.