City monitoring shows a leaf encapsulating frames, yet the remote host MAC never appears and traffic fails. How should troubleshooting be split?
Select an answer to reveal the explanation.
Short Explanation
Wrapping boxes is not the same as the far warehouse stocking the shelf. Encapsulation counters say the local leaf tried; they don’t prove underlay delivery, VNI join, or EVPN/MAC learning worked. Split the problem: road, membership, then learning.
Full Explanation
If city monitoring shows a leaf encapsulating frames yet the remote host MAC never appears and traffic fails, troubleshooting should isolate whether the break is underlay reachability, VNI membership, or MAC learning/control-plane distribution—not assume encapsulation alone means end-to-end success. Ingress encapsulation indicates a local VXLAN attempt; remote MAC presence still depends on delivery, shared membership, and EVPN or learning mechanisms.
Replacing all optics first because encapsulation counters supposedly prove the control plane is perfect skips layered isolation. Disabling VXLAN city-wide and extending VLANs with spanning tree is not the only next step. Assuming the server NIC driver is the sole fault whenever encapsulation counters increment ignores fabric-path classes of failure.
Exam caveat: split underlay, membership, and learning planes explicitly in municipal VXLAN procedures.
Operational check: verify VTEP underlay reachability, confirm both leaves share the VNI/RT membership, then check EVPN Type-2 or MAC tables; only after those pass deepen into host NIC diagnostics. Record which layer failed in the incident ticket to improve future MTTR metrics. Use a known-good second VNI as a control test when the first VNI misbehaves.