Route Reflector Scaling and Sub-Second BGP Restoration
A wholesale carrier runs AS 64500 with 180 PE routers, 900 IGP routers, and six BGP route reflectors in three clusters. The network carries 1.4 million IPv4 prefixes, 500,000 IPv6 prefixes, and 250,000 labeled routes. Peak RR CPU is 85%, and BGP churn reaches 12,000 updates per second during access flaps. After a core link failure, voice customers see 75 seconds of blackholing; the SLA requires under one second. BGP PIC, add-path, and prefix suppression are not enabled. The IGP is OSPF area 0 with good SPF timers, but BGP next-hop reachability changes trigger full best-path recalculation. Two RR clusters are in the same region, and the third is remote. The carrier wants a design that scales route reflectors and provides fast restoration without increasing configuration complexity per PE.
1. Explain why the route-reflector design hides backup paths from PEs, and recommend a BGP feature set to meet the sub-second restoration target.
Read the worked answer
A route reflector advertises only its best path for a prefix unless additional-path features are enabled. Each PE therefore receives one active path and no alternative, even though the RR may know several diverse paths. When the active path fails, the PE must wait for a BGP withdrawal and a new update before it can forward, which explains the long blackhole.
Enable BGP additional-paths selectively from RRs to PEs so the RR sends a diverse backup path, and enable BGP PIC edge on the PEs so the backup is installed in the forwarding table before the failure. Use route-target or prefix filters to limit add-path to the prefixes that need protection, because add-path increases RIB and update load. Add BGP PIC core so IGP reconvergence can switch to a precomputed backup path without waiting for BGP. Pair this with LFA or TI-LFA in OSPF. Verify that the backup path does not share the same core link or node as the primary. The target is not just faster BGP timers; it is having a usable alternate already installed.
2. The RRs are at 85% CPU. Would you add more RR clusters, deploy confederation, or leave the design and tune? Justify with scaling and operational impact.
Read the worked answer
Add RR clusters or split clients across more RR pairs rather than moving to confederation. Confederation divides the AS into sub-ASes and reduces the iBGP mesh, but it introduces eBGP-like policy between sub-ASes, more complex path selection, and additional operational overhead. It does not solve the immediate RR CPU problem as cleanly as reducing the number of clients and paths per RR.
A practical target is 8 to 12 RRs in four to six clusters, with 30 to 50 PE clients per RR cluster, while keeping redundant RRs in each cluster. Use BGP update groups, peer templates, and selective add-path to control CPU. Avoid enabling add-path for all 1.4 million IPv4 and 500,000 IPv6 prefixes on every session. Measure CPU by process and update rate after each change. Confederation can remain a later option if the AS grows beyond the hierarchy's practical limits, but it should not be the first response to RR CPU at this scale.
3. Design the interaction between OSPF and BGP next-hop reachability so that a core link failure does not cause BGP churn. Include prefix suppression and next-hop tracking.
Read the worked answer
Advertise PE loopbacks as the BGP next-hop and keep those loopbacks reachable through redundant IGP paths. Enable prefix suppression on core transit links so link prefixes are not carried in OSPF; this reduces IGP database size and prevents a core link failure from changing BGP next-hop reachability for every affected prefix. Do not suppress loopbacks or any prefix used as a next-hop.
Use BGP next-hop tracking so a PE withdraws or switches paths when the next-hop route is genuinely lost, not on every IGP topology change. Combine that with BGP PIC core: the IGP computes and installs a backup path to the next-hop, and BGP can switch to the backup without waiting for a new best path. Keep OSPF SPF and PRC timers aggressive but stable, and avoid excessive LSA flooding. The expected result is that a single core link failure is handled by IGP/LFA and BGP PIC locally, while BGP churn is limited to prefixes whose next-hop actually becomes unreachable.