Ops notices outer IP headers between civic leaves use loopback addresses as tunnel endpoints. What do those addresses represent in the VXLAN data plane?
Select an answer to reveal the explanation.
Short Explanation
Those leaf loopbacks in the outer header are the VTEP identities—the tunnel doorways—not the tenant VM addresses and not STP bridge IDs in disguise. They need to be reachable across the underlay so VXLAN packets can show up at the far leaf. Link-local-only would not get you across a Clos fabric.
Full Explanation
Outer IP headers between civic leaves that use loopback addresses as tunnel endpoints represent VTEP addresses—the outer IP source and destination of the VXLAN tunnels. Operators commonly place VTEP sources on loopbacks so tunnel identity remains stable when individual fabric links fail, and the underlay must advertise and reach those addresses across the leaf-spine Clos for overlays to function for municipal workloads.
Those outer addresses are not tenant VM addresses rewritten into the outer header for every frame. They are not Spanning Tree bridge IDs encoded as IPv4 for troubleshooting convenience. They must not be link-local-only addresses that cannot be routed across spines if remote VXLAN delivery is required between city leaves.
Exam caveat: VTEP equals the outer tunnel endpoint IP, often a loopback; missing underlay host routes to that IP break overlays even when VNI maps look correct on both sides.
Operational check: identify the configured VTEP source on each leaf, confirm loopback advertisement into underlay BGP, and traceroute between VTEP addresses before blaming VNI mapping when overlay traffic fails. Validate that ECMP paths to the VTEP remain present after a fabric uplink failure in a maintenance window.