Hub-and-Spoke VRF Leaking with a Shared-Services Extranet
A provider operates a hub-and-spoke VPN for an enterprise: one hub VRF, 120 spoke VRFs, and a shared-services VRF hosting DNS and a partner extranet. Each spoke imports only the hub route target; the hub imports all spoke route targets; shared services imports every spoke RT. Route leaking is implemented with rib-groups on each PE, and recently spokes began sending traffic directly to each other, bypassing the hub firewall. A new requirement adds a partner VRF belonging to a different customer; only the 10.20.30.0/24 prefix must be exchanged between partner and shared services. The provider uses vrf-table-label. After a PE failure, some leaked prefixes remain in the VRF tables with an unreachable next hop, causing black holes until the session is cleared.
1. Design the route-target and leaking scheme that enforces spoke-to-spoke traffic through the hub, while still allowing every spoke to reach shared services. Explain why the current rib-group design leaks spoke routes into other spokes and how to fix it.
Read the worked answer
Current design: the hub imports all spoke RTs, so the hub VRF contains every spoke prefix. A rib-group that copies the hub VRF into each spoke therefore copies the hub's entire table, including routes learned from other spokes. The spoke then has a direct route to the other spoke's CE and bypasses the hub firewall.
RT design:
- Each spoke exports a unique RT, e.g. 65000:1001 through 65000:1120; spokes import only the hub RT 65000:900 and the shared RT 65000:800.
- The hub imports all spoke RTs and the shared RT; the hub exports 65000:900.
- Shared services imports all spoke RTs and the hub RT; it exports 65000:800.
This alone gives the correct policy if leaking is done by RT import. With rib-groups, the hub-to-spoke rib-group must carry an import policy that only accepts hub-originated routes (tagged with community 65000:900) and the default route, not routes the hub learned from other spokes. Apply the same restriction on the shared-to-spoke rib-group: only shared-originated prefixes. Alternatively, use auto-export with a policy, or a vt-interface with a filter; both make the policy explicit. Verify with show route table spoke.inet.0 on a spoke: it should contain the hub prefix and shared prefixes, but no other spoke prefix.
2. Some leaked prefixes remain in a spoke VRF with an unreachable next hop after a PE failure. Explain the resolution problem and the configuration that prevents the black hole.
Read the worked answer
Leaked routes keep their original next hop. If a spoke imports a hub route whose next hop is a remote PE loopback, the spoke VRF must resolve that next hop through the source VRF or through a label. With vrf-table-label, the VRF has its own label, but the leaked route still needs a resolving route in the target VRF. After a PE failure, the leaked route may remain because the BGP path is still present or the import policy copied it, while the label or next hop is gone.
Fixes:
- Add a static route in the target VRF:
route 0.0.0.0/0 next-table hub.inet.0;so unresolved next hops fall back to the hub VRF, or use a more specific next-table route for the PE loopbacks. - Ensure BGP next-hop tracking and BFD withdraw the path quickly; tune BGP
graceful-restartso it does not hold stale routes longer than desired.
Check show route table spoke.inet.0 <prefix> extensive for the next hop and show route resolution unresolved. Do not rely on clearing the session as the permanent fix.
3. For the partner extranet, how would you exchange only 10.20.30.0/24 between the partner and shared-services VRFs, and what would you verify on both PEs?
Read the worked answer
Create a partner VRF with RT 65000:777 and keep shared services at 65000:800. Use vrf-import/vrf-export policies with prefix-list matching:
- On the partner VRF export: accept only 10.20.30.0/24, then community 65000:777.
- On shared import: accept 65000:777 only for 10.20.30.0/24.
- On shared export: advertise 65000:800; on partner import: accept 65000:800 only for the shared prefix(es) that the partner needs.
Do not import the full shared table into the partner; an extranet is a prefix-level policy, not a VRF-level one. Use route-target filtering on the PE-CE or ASBR if the partner is in another AS. Verify with show route table partner.inet.0 10.20.30.0/24 extensive for the RT and next hop, show route table shared.inet.0 10.20.30.0/24, and a ping/traceroute from each side. Also check that the return route exists in both directions; a one-way import is a common extranet mistake.