Two unrelated agency VRFs accidentally share the same route target import/export values. What is the likely result?
Select an answer to reveal the explanation.
Short Explanation
Shared RTs are shared club membership cards—suddenly both agencies get each other's routes. That accidental merge is how multitenancy dies quietly while configs still look 'almost right.' Keep RT hygiene as strict as badge access.
Full Explanation
If two unrelated agency VRFs accidentally share the same route target import/export values, the likely result is that the tenants can unexpectedly merge routes and defeat intended multitenancy separation. Shared RTs are shared club membership cards: both VRFs import each other's routes and isolation quietly fails even though instance names still look different in the configuration.
VXLAN source UDP ports randomizing more aggressively is unrelated to RT collision. BFD sessions on the underlay administratively shutting down is not caused by matching RTs. IRB interfaces losing MAC addresses until reboot is fiction relative to RT misconfiguration and should not be blamed first.
Exam caveat: RT hygiene failures present as “mysterious” inter-tenant reachability even when VRF names look correct.
Operational check: compare import/export RT lists for both agencies, correct accidental overlap, clear and relearn routes, and verify each VRF only contains its own plus explicitly approved shared-services prefixes. After correcting RTs, clear EVPN routes for both VRFs if needed and confirm lateral prefixes disappear from each table. Retain before-and-after show commands in the change ticket so the municipal NOC can prove the isolation or steering outcome without relying on memory.