The municipal NOC needs to confirm a leaf can source and reach VXLAN traffic as a VTEP. Which verification focus is most appropriate?
Select an answer to reveal the explanation.
Short Explanation
No return address on the truck, no delivery. Confirm the leaf’s VTEP source IP is configured and that the underlay can reach the far VTEP. Pretty LLDP banners don’t move VXLAN packets.
Full Explanation
When the municipal NOC needs to confirm a leaf can source and reach VXLAN traffic as a VTEP, focus on verifying that the VTEP source address or interface is present and reachable in the underlay to remote VTEPs. A VTEP must own a stable source IP—often a loopback—used as the outer address for VXLAN encapsulation, and that address must be advertised and reachable.
Serial cable inventory for out-of-band consoles does not prove VTEP data-plane readiness. LLDP neighbors showing the city hostname banner do not prove VTEP IP reachability. Each server NIC having a public Internet default route is unrelated to fabric VTEP underlay reachability.
Exam caveat: VTEP source IP plus underlay reachability are early VXLAN health checks on civic NOC checklists.
Operational check: display the VTEP source configuration, confirm the address in underlay BGP/IGP, ping and traceroute from remote VTEPs, then retest overlay; failure here blocks tunnels even when VNIs exist. Alarm on missing VTEP host routes in the underlay RIB as a first-class fabric KPI. After leaf RMA, verify the replacement advertises the same VTEP addressing role before returning to production. Record the validated outcome in the municipal fabric runbook for the next change window.