The NOC tries to filter municipal EVPN routes using only ordinary IPv4 prefix-lists and finds the policy ineffective. What concept should they apply?
Select an answer to reveal the explanation.
Short Explanation
EVPN routes are not plain prefixes in a city phone book—you cannot catch them with a vanilla IPv4 prefix-list net. Use EVPN-aware policy that understands those NLRIs and attributes. Turning off MP-BGP to "make them look like inet" is the wrong kind of clever.
Full Explanation
EVPN NLRIs are not matched by ordinary IPv4 prefix-lists the way inet unicast prefixes are. Municipal operators need EVPN-aware routing policy—matching route types, route targets, Ethernet Tags/VNIs, IP prefixes inside Type-5, or other EVPN attributes—depending on Junos policy hooks. Claiming EVPN NLRIs are always accepted and cannot be filtered on Junos is false; policy is widely used to scope tenants. IPv4 prefix-lists alone do not magically match Type-2 MACs as /32 hosts. Disabling MP-BGP to force EVPN into classic inet unicast is not a valid filtering strategy and breaks EVPN. Exam caveat: Type-5 prefix filtering can look similar to IP policy but still occurs in the EVPN family context; Type-2 filtering is about MAC/IP EVPN attributes, not copying an inet prefix-list unchanged. Operational check: apply an EVPN-aware policy to block a test tenant RT on a lab leaf, confirm those Type-2/Type-5 routes stop installing while other tenants continue, and show why an IPv4 prefix-list alone did not achieve the same result. Build EVPN-aware policy libraries for RT and route-type matches so tenant isolation changes do not rely on inet prefix-list habits. Build EVPN-aware policy libraries for RT and route-type matches so tenant isolation changes do not rely on inet prefix-list habits.