City operators enable VXLAN on two leaves, but the underlay cannot reach the remote VTEP loopback. What happens to the overlay data plane?
Select an answer to reveal the explanation.
Short Explanation
No road to the other warehouse means no deliveries—period. VXLAN rides IP in the underlay, so if you can’t ping the remote VTEP, you can’t ship encapsulated frames there. Fix underlay reachability before blaming the VNI paint job.
Full Explanation
If city operators enable VXLAN on two leaves but the underlay cannot reach the remote VTEP loopback, encapsulated VXLAN packets cannot be delivered, so the overlay data plane fails until underlay IP reachability to the remote VTEP is restored. Control-plane VNI configuration alone cannot substitute for IP reachability between tunnel endpoints.
VXLAN does not automatically fall back to spanning-tree flooding across access ports only when underlay reachability is missing. Overlay unicast does not continue because VNIs are carried in LLDP regardless of IP reachability. It is false that only multicast BUM fails while all known-unicast overlay traffic is unaffected by underlay loss—known unicast VXLAN also uses outer IP to the remote VTEP.
Exam caveat: underlay reachability to VTEP addresses is a hard dependency of the VXLAN data plane on municipal Clos fabrics.
Operational check: traceroute and ping between VTEP loopbacks; if broken, fix underlay BGP/IGP advertisement and ECMP before debugging VNI maps; retest overlay after underlay reachability returns. Compare link BGP Established state with VTEP host-route presence—sessions can be up while loopbacks are missing. Add the VTEP prefix to underlay export policy and reconfirm remote traceroute before overlay tests.