A route-target mismatch causes a municipal leaf to drop all EVPN Type-2 routes for a tenant. What does that symptom reinforce about EVPN route types?
Select an answer to reveal the explanation.
Short Explanation
Wrong route targets are like mailing packages with the wrong ZIP—Type-2 never gets opened on that leaf. EVPN still rides BGP VPN membership rules: import/export must match or the host ads are discarded. Route type alone does not skip RT checks.
Full Explanation
Even though EVPN defines specialized route types, those NLRIs are still BGP VPN-style routes that honor route-target import and export membership. A municipal leaf that drops all Type-2s because of an RT mismatch is behaving correctly: without matching import targets, Type-2 never installs into the tenant MAC-VRF/EVPN instance. Type-2 does not bypass route targets or install from any peer regardless of RT. It is false that only Type-5 needs matching targets while Type-2 is target-free—both are EVPN NLRIs subject to RT policy. Route targets are not limited to underlay IPv4 unicast; underlay unicast typically does not use VPN RTs the way EVPN overlay instances do. Exam caveat: RD uniqueness and RT membership are related but different—duplicate RDs can create operational confusion while wrong RTs cause silent non-import even when BGP EVPN sessions look Established and underlay ping succeeds between loopbacks. Operational check: compare export RT on the advertising city leaf with import RT on the receiver, fix the mismatch, clear or wait for re-advertisement, and confirm Type-2s appear in the tenant EVPN table and MAC table; also validate that unrelated tenants still do not import those routes.