New Tenant Prefix Missing from the WAN Advertisement
Two border leaves, bl-1 and bl-2, run eBGP to WAN routers in AS 65100 and carry EVPN routes from the data center leaves. The export policy DC-TO-WAN on both borders contains one term: from route-filter 10.20.0.0/16 orlonger, then accept, followed by a final then reject. The data center has historically used 10.20.0.0/16, and the WAN has received those prefixes for months. A new tenant is deployed on subnet 10.21.48.0/24 with an anycast gateway, and EVPN distributes it correctly to both borders. On bl-1, show route 10.21.48.0/24 shows the prefix as active. The WAN router reports that it still has no route to 10.21.48.0/24. There are no BGP session flaps, and the WAN-facing interfaces show no errors.
1. How do you prove where the advertisement is being lost, using three commands?
Read the worked answer
Work from the route table outward. First run show route 10.21.48.0/24 on bl-1 to confirm the prefix is active and see its protocol, which rules out an EVPN or next-hop problem. Second run show route advertising-protocol bgp <WAN-peer-address> and search for 10.21.48.0/24; if it is absent, the loss is local to export policy, not the session. Third run test policy DC-TO-WAN 10.21.48.0/24, which reports accept or reject and identifies the matching term.
In this case the test returns reject. 10.20.0.0/16 orlonger matches only prefixes inside 10.20.0.0/16, and 10.21.48.0/24 is in a different /16, so it never matches the accept term and falls through to the final reject. The session is healthy, which is why the WAN sees nothing rather than seeing an error.
2. Write the policy change and explain the ordering and verification steps on both borders.
Read the worked answer
Add an explicit term for the new prefix before the reject term, for example a term matching route-filter 10.21.48.0/24 exact with then accept, keeping the existing 10.20.0.0/16 term and the final reject. Using exact prevents accidentally advertising more-specific junk from that range. Alternatively, maintain a prefix-list containing both ranges, which is easier to audit as tenants grow.
Order is critical: Junos evaluates terms top-down, and then accept ends evaluation, so the reject must remain last. Run commit check, then commit both borders; a policy change takes effect for the BGP export process without resetting the session. Verify with test policy DC-TO-WAN 10.21.48.0/24 and show route advertising-protocol bgp <peer> on both bl-1 and bl-2, then confirm on the WAN router with show route receive-protocol bgp <border-address>.
3. After the change, the prefix is advertised by both borders but the WAN router still does not install it. What would you check next?
Read the worked answer
Once the prefix appears in the WAN router's received table, the problem has moved to the WAN side. Check show route receive-protocol bgp <border-address> on the WAN router: if the prefix is there but not active, an inbound import policy is rejecting it, or the route is hidden for a next-hop or validation reason. show route hidden and show route 10.21.48.0/24 detail show the reason.
Also compare what each border advertises. If only one border sends it, the WAN may have an asymmetric path or a policy that prefers the other peer, and the prefix can appear present but unusable. Confirm the AS path and next hop are what the WAN expects, and check that the WAN's inbound policy permits this tenant range. Fixing the data center export policy was necessary but not sufficient; end-to-end verification must include the receiving side.