Two VMs on the same hardware VXLAN fabric can't reach each other, or traffic between them drops intermittently, and the path runs through a Spine you can't just stare at. This is the traditional two-stage method for finding the exact device dropping packets — confirm the Underlay/Overlay baseline first, then configure flow statistics to localize the drop.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The traditional way to localize packet loss on a hardware VXLAN spine-leaf fabric isn't forty things to check at once — it's two stages, and the second one only starts once the first comes back clean.
When two VMs on the same fabric can't reach each other, or traffic between them drops intermittently, the instinct is to start pulling configuration from every device on the path at once. The traditional two-stage method used on hardware distributed VXLAN spine-leaf fabrics does the opposite: first confirm the Underlay and Overlay baseline is actually healthy end to end, and only then — if that baseline genuinely checks out — turn on flow statistics to find the one device in the path that's actually dropping packets.
What follows is both stages with the exact display commands, the five-tuple flow-statistics configuration that pinpoints the dropping hop, and the traps that catch people out even when they're following the method correctly.
Stage 2's flow statistics are matched differently at every hop on this path — worth having the picture in front of you before you configure anything.
This is the most common access pattern in a hardware distributed VXLAN fabric: source Server Leaf, across the fabric through a Spine, through a Service/Border Leaf if the destination sits behind one, back through a Spine, and into the destination Server Leaf. Stage 2 only makes sense once you can place the symptom on this path.
Diagram labels are kept in English for engineering clarity.
If Stage 1 turns up a break — a missing route, a Down tunnel, a missing ARP or host route — fix that directly; it's a plain misconfiguration in routing, VXLAN or EVPN, not a packet-loss mystery, and our VXLAN tunnel troubleshooting note covers those causes in depth. Flow statistics in Stage 2 are only worth configuring once the baseline genuinely looks clean end to end.
Five checks in Stage 1, then a five-tuple flow-statistics setup in Stage 2 — in that order, not reversed.
Using VM1 (10.120.120.5, gateway vBDIF111 on Source Server Leaf) failing to reach VM2 (10.141.141.3, gateway vBDIF222 on Dest. Server Leaf) as the example — five checks, each one on both the source and destination Server Leaf.
<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 routeOnly reached once Stage 1 is fully clean on both ends. Traffic statistics work on the five-tuple, but only support the inbound direction — and the packet format is different at every hop.
// 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 deviceOnce the two stages above have told you where the problem sits, these five account for most of what actually goes wrong — including a couple of ways to fool yourself while following the method correctly.
SYMPTOMdisplay ip routing-table toward the peer NVE address comes back empty on one Server Leaf but looks fine on the other — Stage 1 seemed to pass because only one direction got checked.
CAUSEIGP/BGP convergence toward loopback addresses isn't always symmetric — an IGP cost change, a route-policy, or a filter on just one device can leave the reverse path with no route to the peer VTEP while the forward path looks completely normal.
FIXRun the routing-table check on both the source and destination Server Leaf, toward each other's NVE source address, before concluding Stage 1 passed.
SYMPTOMdisplay vxlan tunnel shows State as down for the tunnel on the reference path, even though other tunnels on the same device are up.
CAUSEA VXLAN tunnel only comes up when there's a route to the peer VTEP; if that Down state slips past a quick glance at Stage 1, everything downstream — ARP, host routes, flow statistics — ends up being checked on a path that was never going to carry traffic in the first place.
FIXTreat a Down tunnel as its own fault, not a packet-loss symptom — work through our VXLAN tunnel troubleshooting note first, then come back to this method once the tunnel is confirmed up.
SYMPTOMStep 4 (ARP) passes on both Server Leafs, but step 5 (the EVPN host route) is missing on one side.
CAUSEThe remote Server Leaf did convert the ARP entry into an EVPN route and advertise it — but a VPN-Target mismatch, a route-policy filter, or a Router-ID collision at the route reflector kept the other side from ever accepting it into its routing table.
FIXThis is a routing/EVPN misconfiguration, not a fabric hardware fault — the deep dive on VPN-Target mismatches and route-reflector filtering is in our VXLAN tunnel troubleshooting note; fix that before moving to Stage 2.
SYMPTOMFlow statistics show clean counters at every hop, yet the VM-to-VM ping is still dropping packets.
CAUSETraffic statistics only support the inbound direction, and the packet format changes at every hop: the first NVE device sees the original, pre-VXLAN packet and needs an ACL-based classifier, while every device downstream sees a VXLAN-encapsulated packet and needs a vxlan tag-format classifier instead. Reuse the wrong if-match rule on the wrong hop and that device's counter simply never increments — telling you nothing about where the loss actually is.
FIXMatch the classifier to the hop: if-match acl on the source Server Leaf, if-match vxlan transit tag-format none on transit Spines, if-match vxlan tag-format none on the Leafs that terminate the tunnel.
SYMPTOMThe symptom looks intermittent — some pings get through, some don't — and re-running the same test doesn't reproduce it consistently.
CAUSEECMP across multiple Spines hashes on the five-tuple; a plain ping keeps reusing the same tuple and will keep landing on the same path, which can hide a fault on a Spine that a different flow would have hit, or make a genuinely bad Spine look intermittent if some flows dodge it entirely.
FIXVary the five-tuple deliberately when testing — different source ports, not just repeated pings — or rely on the flow-statistics counters from Stage 2 rather than on ping alone to decide whether a given path segment is actually clean.
Pulled straight from the field — the ones worth having an answer ready for.
Because Underlay and EVPN convergence isn't guaranteed to be symmetric. A route, an ARP entry or a host route can be present in one direction and missing in the other, and checking only the source Leaf tells you the wrong half of the story exactly when it matters most.
You can, but it wastes a configuration pass. Every one of the five Stage 1 checks is faster to run than setting up classifiers, behaviors and policies at every hop, and a plain routing, tunnel-state, ARP or host-route problem shows up immediately in Stage 1 without needing statistics at all.
This method reads counters and tables you configure by hand, hop by hop — it works on any hardware distributed VXLAN fabric and needs nothing beyond CLI access. A controller-based analytics platform automates the same idea — packet-loss records, flow tracing, topology-aware path checks — and gets you to the answer faster if it's deployed, but the underlying logic is identical: confirm the baseline, then localize the drop.
It does, and it's the reason the classifier at each hop has to match what that specific device actually receives — the original packet at the first NVE hop, a VXLAN-encapsulated packet everywhere after. Configuring the counter on the wrong side of a hop, or matching the wrong packet format, is the single most common way this method returns a false “clean” reading.
At that point the fabric itself has effectively been cleared. Check whether a manual configuration change landed on any device in the path around the time the fault started, and if the counters genuinely stay clean across the whole reference path, treat this as a compute-node or application-side issue and coordinate with the IT/server team rather than continuing to chase it inside the network.
This note is built around the traditional, CLI-driven two-stage method for hardware distributed VXLAN spine-leaf fabrics — Underlay/Overlay baseline first, five-tuple flow statistics second. It assumes a fault that's already been placed on the VM-to-VM path shown above; a tunnel that's Down, or an EVPN route that never crossed, are faults in their own right and are covered in depth in our VXLAN tunnel troubleshooting note, not repeated here. It also doesn't cover controller-based analytics platforms that automate the same localization logic — where one is deployed, it will usually get you to the answer faster than the manual method described here. For the same three-source judgment tree (optics, CRC/physical layer, discards) applied to a single link instead of a multi-hop fabric path, see our campus packet-loss note.
Tell us which stage you're stuck at — the Underlay/Overlay baseline or the flow statistics — plus the display output, and we'll help you read it.