A municipal NOC captures leaf-to-spine fabric packets and sees a VNI field inside the VXLAN header. What data-plane role does that VNI play on the egress VTEP?
Select an answer to reveal the explanation.
Short Explanation
Think of the VNI like a shipping-container number on a city transit truck: the underlay only hauls the truck, but the warehouse door that opens is picked by that number. On decap, the VTEP uses the VNI to pick the right L2 bridge domain or L3 overlay context before it hands the frame to a local server. Without that binding, the payload has nowhere sensible to land.
Full Explanation
On a municipal leaf-spine fabric, the VNI field inside the VXLAN header selects the bridge domain or routing domain the egress VTEP uses after it decapsulates and forwards the inner frame. That identifier is how the receiving VTEP maps an incoming overlay packet into the correct L2 bridge domain or L3 VNI/VRF context before local switching or routing toward the attached civic workload.
The VNI does not replace the underlay OSPF area ID so spines can route tenant VRF tables directly; spines typically forward on outer IP and do not interpret tenant VNIs for tenant bridging. The VNI is not only a cosmetic dashboard label ignored during encapsulation and decapsulation. It does not force every spine to rewrite the inner VLAN tag to match the city’s campus numbering plan.
Exam caveat: VNI-to-domain mapping at the VTEP is essential for isolation and correct delivery; confusing VNI with underlay IGP areas is a common distractor.
Operational check: on an egress civic leaf, confirm the VNI-to-bridge-domain or VNI-to-VRF map, send traffic for that VNI, and verify decap counters and local forwarding into the expected domain rather than a neighboring tenant context. Also compare the VNI in a packet capture with the configured map before blaming underlay ECMP for a tenant isolation fault.