A national retailer has EVPN sessions up and host routes on the route reflector, but one leaf VRF never installs those remote hosts. That VRF does not import the route target the other leaves export. What is missing?
Select an answer to reveal the explanation.
Short Explanation
You can think of a route target as the department code on an envelope: the other leaves export that code, but this VRF does not collect it. Add that import to the VRF; the reflector already holds the host routes, so enabling the EVPN address family is not the missing piece.
Full Explanation
EVPN host routes travel in BGP with route targets that determine which VRFs import them. The reflector already has the routes, so the BGP sessions are up and the EVPN address family is working. The VRF that should learn the remote hosts does not import the route target exported by the other leaves; adding that import is the missing step, allowing the routes into the VRF. Activating the EVPN address family would matter if the reflector had no host routes, but the stem confirms that the routes are present. Identical OSPF process tags are not required: those tags are local, and BGP does not compare them when importing a route target. Peer-gateway is also unrelated; it lets a vPC peer route frames sent to the other peer’s router MAC, but it does not copy route targets between peers or VRFs. Exam caveat: the route distinguisher must still keep overlapping prefixes unique, but a missing distinguisher is not the cause when a visible route fails to import. Practical check: compare the route target on the exported route with the import list on the VRF that is missing hosts, add the missing import, and confirm the remote hosts appear in that VRF.