Network & Infrastructure / EVPN, VXLAN & Data Center Fabrics
VNI and route-target mismatch across a tenant fabric
Two leaf switches advertise the same tenant's endpoints, but each ignores the other's routes. Matching VLAN names can obscure different VNI or route-target assignments.
Environment and inputs: BGP EVPN overlays on a routed underlay; supported route types and multihoming behavior depend on the network OS. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Compare MAC-VRF membership, VLAN-to-VNI mappings, import/export route targets and BGP extended communities. Check the actual received route attributes instead of relying on configuration comments.
Explain the result
VNI identifies a forwarding context, while route-target policy controls which VPN routes enter that context. Similar local VLAN labels do not create an interoperable overlay.
Plan the fix
Correct the source-of-truth mapping and use a narrowly scoped coordinated rollout. Avoid importing every route target as a quick way to make one endpoint visible.
Check the result and rollback
Verify the intended Type-2 and inclusive multicast routes on both VTEPs, then test isolation from another tenant. Restore the prior mapping if forbidden MACs or IP routes appear.