The city underlay already runs BGP for IP fabric routes, and the overlay needs EVPN. What must engineers apply regarding Multiprotocol BGP?
Select an answer to reveal the explanation.
Short Explanation
Underlay BGP getting /32s to leaves is not the same conversation as EVPN host and IMET ads. Turn on the EVPN MP-BGP family so overlay NLRIs have a real seat at the table. OSPF opaque tricks and static-only overlays miss the professional pattern.
Full Explanation
EVPN NLRIs are carried in Multiprotocol BGP as a dedicated address family (AFI/SAFI), not as plain IPv4 unicast. When the city underlay already uses BGP for IP fabric routes, engineers still enable EVPN family capability on the appropriate sessions so Type-1 through Type-5 routes can negotiate and exchange alongside underlay families as designed. Reusing IPv4 unicast only is insufficient; EVPN does not piggyback without the EVPN family. Replacing BGP with static VXLAN tunnels abandons EVPN's dynamic control plane. OSPF opaque LSAs are not the JNCIP-DC mechanism for carrying Type-2 and Type-5 in Juniper EVPN-VXLAN fabrics. Exam caveat: underlay and overlay may share a session with multiple families or use separate sessions—both patterns appear—but in every case EVPN must be explicitly negotiated. Operational check: inspect BGP neighbor negotiation for EVPN AFI/SAFI on municipal leaves and spines/RRs, confirm Established with EVPN capability, advertise a Type-2, and verify the NLRI appears via EVPN show commands rather than inet.0 alone. Put EVPN family checks into the leaf onboarding playbook so new municipal devices never join the underlay without overlay capability. Put EVPN family checks into the leaf onboarding playbook so new municipal devices never join the underlay without overlay capability.