Site A and Site B use different EVPN route-target schemes for the same logical tenants. What DCI planning step is essential before multi-site membership works?
Select an answer to reveal the explanation.
Short Explanation
Route targets are the guest list for which EVPN routes a VRF will accept. If each city wrote different guest lists, DCI will not join until you align import/export on purpose. Selective RT design beats hoping VNIs alone sort it out.
Full Explanation
When Site A and Site B use different EVPN route-target schemes for the same logical tenants, the essential DCI planning step is careful route-target import (and export) design so each site selectively accepts the intended multi-site EVPN routes. Route targets are the membership policy that lets a civic VRF or MAC-VRF import remote EVPN routes; mismatched RT plans without translation or explicit import mapping yield silent non-connectivity. Deleting all route targets and relying on VNI equality alone for EVPN import removes the BGP policy mechanism EVPN uses to scope which routes enter which tables. Configuring identical RD values on every leaf in both cities so RT policy becomes optional confuses route distinguishers (uniqueness) with route targets (import/export policy) and is neither required nor sufficient. Disabling RT import/export and flooding all Type-2 routes to every BGP peer in the AS abandons selective multi-site membership and can leak overlays between unrelated municipal departments. Exam caveat: multi-site EVPN membership is an RT policy problem—VNI sameness or identical RDs do not replace import/export design. Operational check: document the RT export set each site advertises for the tenant and the RT import set each site accepts; after change, verify remote Type-2/Type-5 routes install only in the intended VRFs and that unrelated civic VRFs remain empty of foreign DCI routes.