Two hosts on the same city leaf communicate, but the same subnet fails to a host on a remote leaf. Where should VXLAN troubleshooting focus first?
Select an answer to reveal the explanation.
Short Explanation
Same-leaf success is like talking across the desk; remote failure means the campus courier path is broken. Don’t reimage the laptops first—check VTEP reachability, VNI join, and the underlay road. Local bridging never needed the truck.
Full Explanation
When two hosts on the same city leaf communicate but the same subnet fails to a host on a remote leaf, VXLAN troubleshooting should focus first on underlay reachability between VTEPs, remote VTEP/VNI membership, and the overlay path—local switching can succeed while remote VXLAN fails. Local success does not prove the fabric overlay is healthy end-to-end.
Reimaging both hosts because local success proves the fabric is irrelevant wastes time. Lowering spanning-tree priority on every access port until remote works misapplies STP to an IP-fabric overlay problem. Removing all ECMP links so a single spine carries every packet is not a sound first step.
Exam caveat: local-OK/remote-fail is a classic EVPN-VXLAN triage pattern pointing at underlay, VTEP, or membership—not basic NIC health alone.
Operational check: ping between VTEP loopbacks, confirm shared VNI membership and EVPN MAC learning for the remote host, then retest; only after fabric-path checks pass escalate to host reimages. Teach NOC staff this asymmetry with a lab where VTEP advertisement is intentionally omitted. Capture on the local leaf uplink to see whether remote-bound frames are actually encapsulating. Record the validated outcome in the municipal fabric runbook for the next change window.