A retail bank's leaves already show EVPN routes in BGP, including remote host advertisements, but no VXLAN tunnel forms to one VTEP. The BGP next hop is a loopback that underlay OSPF does not advertise. What is missing?
Select an answer to reveal the explanation.
Short Explanation
A map to the house does not help if the road to the driveway is closed. You already have the EVPN routes, and the tunnel still fails because the underlay cannot reach that next-hop loopback. Enabling the EVPN family again does not create reachability you still lack.
Full Explanation
EVPN routes tell a VTEP which remote hosts exist and which next hop to encapsulate toward. That next hop is the remote VTEP loopback, and the underlay must already be able to route to it or the NVE has nowhere to send the tunnel. The bank has the overlay advertisements and still has no tunnel because OSPF never advertised that loopback, so underlay reachability is the missing piece. The EVPN address family is already doing its job: the routes are in the BGP table. Activating it again does not invent a route to a next hop the underlay cannot reach. The OSPF process tag is local. VTEPs do not need matching tags to advertise loopbacks or to forward VXLAN, and identical tags would not create the missing loopback route. HSRP preempt changes which router owns a gateway after a failure. It does not create underlay reachability and it does not bring up a VXLAN tunnel to a remote VTEP. Caveat: a route that reaches the loopback through the overlay, or through an interface the underlay is not supposed to use, can still leave the tunnel unresolved or recursive. Operational check: confirm the next-hop loopback is learned in the underlay routing table, then verify the NVE shows the remote VTEP as up.