Two municipal tenant hosts are mapped to the same VNI number on different leaves, but each leaf mistakenly binds that VNI into a different VRF. What is the data-plane consequence?
Select an answer to reveal the explanation.
Short Explanation
Same hallway number painted on two doors that open into different locked offices—chaos. The VNI has to land in the same VRF/bridge-domain story on every leaf or isolation and routing go sideways. Match the bindings, don’t just match the integer.
Full Explanation
If two municipal tenant hosts map to the same VNI number on different leaves, but each leaf mistakenly binds that VNI into a different VRF, intended isolation and forwarding break because correct VNI-to-VRF or bridge-domain binding is required for consistent overlay forwarding. Identical VNI IDs with divergent VRF bindings produce inconsistent classification after decap and violate the isolation model operators expected.
The underlay does not automatically merge the VRFs because identical VNI values override VRF names. Traffic does not succeed only for multicast while unicast load-balances harmlessly across both VRFs. Spines do not rewrite VRF context from the outer DSCP field so the mismatch self-heals.
Exam caveat: VNI identity is only meaningful with consistent bridge-domain/VRF binding on every participating municipal leaf.
Operational check: audit VNI-to-VRF and VNI-to-bridge-domain maps on both leaves, align them to the tenant design, clear stale state if needed, and retest unicast and BUM between the hosts under the corrected binding. Use a configuration compliance check to flag the same VNI bound into different routing instances across the pod. After remediation, confirm EVPN route targets still match the intended tenant VRF membership.