A municipal EVPN design uses a route-target community so only matching VRFs import a tenant's Type-2 and Type-5 routes. What does that extended community primarily control?
Select an answer to reveal the explanation.
Short Explanation
Route targets are membership badges for the tenant club — import only if your badge matches. That decides which VRF/VNI pulls in the EVPN routes, not IGP costs, VXLAN ports, or ZTP order. Wrong club, no routes.
Full Explanation
Route-target extended communities on EVPN routes decide which EVPN VRF or VNI members import the advertised Type-2, Type-5, and related NLRIs into their local tables. In a city fabric, matching RTs are what keep one tenant's MAC/IP and prefix routes out of another tenant's instance. RTs do not set the underlay IGP metric to spine loopbacks. They do not negotiate the VXLAN UDP destination port between VTEPs. They do not control whether Junos runs ZTP before or after BGP comes up. Exam caveat: export RT without a corresponding import RT on the receiver looks like BGP is up but the tenant is empty; the reverse leak from over-broad import merges tenants—both are RT design failures, not underlay failures. Operational check: document the RT set for a municipal tenant, verify export on the source leaf and import on intended receivers only, intentionally mis-import on a lab VRF to prove isolation, then correct it and confirm Type-2/Type-5 install only where membership is intended. Audit RT spreadsheets against live Junos policy on a schedule; civic tenant merges from a typo are silent until an incident. Audit RT spreadsheets against live Junos policy on a schedule; civic tenant merges from a typo are silent until an incident.