In a multitenant EVPN-VXLAN city fabric, why must route distinguishers be unique per tenant routing instance?
Select an answer to reveal the explanation.
Short Explanation
RDs are name tags on identical house numbers from different neighborhoods. When two agencies both announce 10.1.0.0/24, unique RDs keep BGP from treating them as one confused prefix. They do not encrypt VXLAN or replace loopbacks.
Full Explanation
In a multitenant EVPN-VXLAN city fabric, route distinguishers must be unique per tenant routing instance because unique RDs disambiguate otherwise identical prefixes advertised from different tenants in BGP/EVPN. Two agencies can both own 10.10.0.0/16; BGP needs the RD to treat them as distinct VPN routes rather than one conflicting prefix that would break municipal onboarding of overlapping plans.
RDs do not encrypt VXLAN payloads between leaves and spines. RDs do not replace VTEP loopbacks in the underlay IGP. Identical RDs are not required so all tenants share one BGP path—that would destroy disambiguation and is the opposite of multitenant VPN hygiene.
Exam caveat: RD uniqueness is about BGP VPN route identity; do not confuse RD with RT (policy membership) or with underlay loopbacks.
Operational check: inventory RD per tenant instance across leaves, ensure uniqueness, and confirm overlapping prefixes appear as distinct VPN routes in the EVPN/BGP tables during a show route comparison. Add an RD uniqueness check to the pre-change validation script so overlapping civic prefixes cannot collide silently in BGP. 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.