I85PREP
⌘ K
Arista Foundations study materials
Arista Foundations study resources

Routing Policy and Prefix Leak Between Tenants

Arista Foundations · Put your knowledge to work in context.

All case studies

Routing Policy and Prefix Leak Between Tenants

A managed services provider runs a shared Arista fabric with per-tenant VRFs. Tenant A advertises 400 prefixes into the fabric via eBGP from a customer edge router. Tenant B has a default route to the fabric. After a change window, Tenant B reports reaching destinations it should not, and Tenant A reports intermittent black holes for 12 of its prefixes. The fabric uses route redistribution between eBGP and the underlay, and there is a single route reflector pair. The team wants to know whether the leak is a policy problem, a VRF problem, or a route-reflector problem, and how to contain it.

1. How would you determine whether the leak is a VRF isolation failure or a routing policy failure?

Read the worked answer

Check isolation first. On the tenant VRFs, verify that the route targets and route distinguishers are correct and that Tenant A's prefixes are not imported into Tenant B's VRF. show bgp vrf <tenant> ipv4 unicast and show vrf will show whether Tenant B has Tenant A's prefixes. If the prefixes are present in Tenant B's VRF, it is an import/export or route-target problem, not a policy problem.

If Tenant B does not have Tenant A's prefixes but still reaches them, the leak is likely a default route or a shared underlay path. Then check routing policy: redistribution into the underlay, prefix lists, and whether a default route is being advertised into Tenant B.

The judgement is to prove where the prefix exists before changing policy; a policy fix applied to a VRF isolation bug will not hold.

2. Twelve of Tenant A's prefixes are black-holed intermittently. What would you check on the route reflector and the eBGP sessions?

Read the worked answer

Intermittent black holes for a subset of prefixes point to control-plane instability or policy inconsistency, not a total session failure. Check:

  • Route reflector health: show bgp summary on both RRs, session flaps, and whether the RR pair is synchronized. A single RR with a flapping client can cause temporary withdrawal of a subset.
  • eBGP session stability with Tenant A's CE: flaps, hold-time expiry, and whether the 12 prefixes are the ones most recently advertised.
  • Policy consistency: whether the 12 prefixes match a prefix-list or route-map that is applied differently on the two RRs or on the tenant's edge.
  • Next-hop reachability: if the next hop for those 12 prefixes is resolved through a path that is flapping, they will black-hole intermittently.

Correlate the black-hole windows with RR and session events. The judgement is to look for a subset-specific cause (policy or next-hop) rather than assuming a full routing failure.

3. What containment steps would you take immediately, and what permanent controls would you add?

Read the worked answer

Immediate containment:

  1. Apply an inbound and outbound prefix filter on Tenant A's eBGP sessions so only its authorized 400 prefixes are accepted and advertised.
  2. Remove or tighten Tenant B's default route so it cannot reach Tenant A's space; replace with explicit routes for permitted destinations.
  3. Verify VRF route-target import/export on both tenants and correct any mismatch.
  4. Monitor the 12 black-holed prefixes until stable.

Permanent controls:

  • RPKI or explicit prefix lists per tenant, enforced at the tenant edge and the RRs.
  • Max-prefix limits on eBGP sessions to prevent leaks.
  • Change control that requires a policy review before redistribution changes.
  • Monitoring that alerts on prefix count changes per tenant VRF.

The judgement is to contain first with filters, then fix isolation, then add preventive controls so the same leak cannot recur.