Ops confuses a VXLAN VNI with the local VLAN ID while reading control-plane advertisements on a county leaf. What is the correct distinction?
Select an answer to reveal the explanation.
Short Explanation
Treat the VNI like the city’s parcel code for an overlay neighborhood, and the VLAN ID like the door tag on one building’s access switch. At the VTEP you map that local door tag into the VNI the fabric actually forwards on. They are related by mapping, not by being the same number everywhere.
Full Explanation
When ops confuses a VXLAN VNI with the local VLAN ID on a county leaf, apply this distinction: the VNI is the overlay segment identifier carried in the VXLAN data-plane header and referenced by the EVPN control plane, while a local VLAN ID is an access-side tag that maps to a VNI at the VTEP edge. Different leaves may use different access VLAN numbers that still map into the same civic VNI—or into different VNIs—purely based on configuration, not numeric equality.
VLAN ID and VNI are not always identical integers end-to-end, so advertising either one is not automatically equivalent. The VNI does not exist only in OSPF LSAs and never in encapsulated packets—it appears in the VXLAN header on the wire. Local VLAN tags need not be preserved unchanged across every spine hop inside the outer IP header; spines forward outer IP/UDP toward VTEP addresses while the VNI rides in the VXLAN header.
Exam caveat: VLAN-to-VNI mapping is an edge function; assuming VLAN number must equal VNI number is a common JN0-683 misconception.
Operational check: display the bridge-domain or VLAN-to-VNI map on a county leaf, capture a VXLAN packet and read the VNI field, and confirm transit spines need not carry the access VLAN for underlay forwarding of the encapsulated flow.