High-Availability FAQ: Minimizing MTTR and Configuring Redundancy in BGP Add-Path

Overview & Thematic Scope

In high-availability BGP architectures, standard best-path selection often hides viable backup paths behind a route reflector, forcing traffic to wait for full BGP reconvergence after a failure. This FAQ addresses the critical configuration and operational questions engineers face when deploying BGP Add-Path (RFC 7911) to achieve sub-second path diversity, specifically focusing on redundancy, failover mechanics, and MTTR minimization.

Frequently Asked Questions

Q1: How does BGP Add-Path enable sub-second path diversity compared to standard BGP?

BGP Add-Path achieves sub-second diversity by pre-programming backup next-hops into the FIB, allowing line-rate failover without waiting for a new BGP update. Standard BGP advertises only the single best path, so when that path fails, the router must wait for the route reflector to detect the failure, rerun its decision process, and propagate a new best path . With Add-Path, the route reflector sends multiple paths (each tagged with a unique Path Identifier), so the local router already holds the backup path in its RIB/FIB and can switch instantly upon primary link failure . This effectively decouples data-plane failover from control-plane convergence.

Q2: What is the fundamental configuration requirement to negotiate Add-Path between a router and a route reflector?

Both the route reflector and the client must exchange the Add-Path capability (Capability Code 69) with the appropriate Send/Receive flags during BGP OPEN. The receiving device must set its capability to receive (value 1 or 3), and the advertising device must set its capability to send (value 2 or 3) for the specific AFI/SAFI . On Cisco NX-OS, for example, you configure this under the address-family with additional-paths receive on the client and additional-paths send on the reflector . A session reset is typically required because Add-Path is negotiated in the OPEN message, not as a dynamic capability refresh .

Q3: Which path selection mode should I use to balance sub-second failover against control-plane load?

For most high-availability deployments requiring sub-second failover with bounded resource impact, Add-N-Paths (advertising the best path plus the next N-1 diverse paths) is the recommended trade-off. Add-All-Paths provides maximal visibility and the fastest possible failover because every path is known, but it imposes unbounded memory and CPU overhead on both the route reflector and clients . Add-N-Paths caps the number of advertised paths per prefix, keeping the control plane predictable while still ensuring that the most likely backup paths are pre-installed. For networks where path optimality is less critical than absolute simplicity, Add-LP1-LP2-Paths (advertising all highest-local-preference paths plus second-highest) is an alternative that avoids oscillations .

Q4: How do I verify that Add-Path is actually negotiated and functioning on a live BGP session?

Check the BGP neighbor capability output for the specific AFI/SAFI and confirm that both local and remote Add-Path capabilities show Send and Receive flags. On Nokia SR OS, for example, show router bgp neighbor | match "AddPath" should display the negotiated send limit and receive status . On Cisco IOS-XR or NX-OS, inspect the neighbor capability details or use show bgp neighbor to confirm the Add-Path capability code is present. Additionally, the RIB entry for a prefix should show multiple paths with distinct Path-IDs (not just one best path), and the FIB should contain the backup next-hop as a pre-resolved entry.

Q5: What are the risks of enabling Add-Path without adjusting max-prefix limits?

Enabling Add-Path without increasing max-prefix limits will likely cause BGP session flaps due to the surge in additional path advertisements. When a route reflector begins sending multiple paths per prefix, the total number of received prefixes on a client can multiply by the send-limit factor (e.g., 2x, 4x, or more) . If the existing maximum-prefix threshold was tuned for single-path BGP, the session will hit the limit and tear down, defeating the purpose of high availability. Always audit and raise max-prefix limits on all Add-Path-enabled sessions before turning on the feature .

Q6: Can Add-Path cause forwarding loops or deflection in a non-encapsulated network?

Yes, Add-Path can exacerbate forwarding deflection or loops if routers advertise non-best paths inconsistently in a hop-by-hop forwarding environment. If the ingress router selects a path based on its local policy but an egress router downstream has a different view of the best path (due to tie-breaking or local-preference modification), traffic may be deflected . The mitigation is to ensure that the best path is always advertised alongside any backup paths, and that all routers share a consistent path selection policy. In networks using MPLS encapsulation (e.g., BGP/MPLS VPNs), this risk is largely eliminated because forwarding decisions are label-based at the ingress, not hop-by-hop IP lookups .

Q7: How does BFD complement Add-Path for achieving true sub-second failover?

BFD provides the fast failure detection that triggers the pre-computed Add-Path failover; without BFD, BGP’s default hold timer (often 90 seconds or 3 seconds minimum) would still delay the switchover. Add-Path gives the router the backup next-hop, but the router only uses it when the primary next-hop is declared unreachable. BFD (typically configured with 50–150ms intervals) detects link failure in milliseconds, immediately invalidating the primary path and allowing the FIB to activate the standby entry without waiting for BGP withdrawal processing . For sub-second path diversity, the recommended pairing is BFD for detection plus Add-Path for pre-installed backup paths.

Q8: What is the operational impact of Add-Path on memory and CPU, and how do I monitor it?

Add-Path increases memory usage linearly with the number of additional paths advertised per prefix, and CPU load rises due to processing more UPDATE messages and maintaining larger Adj-RIB-In tables. On a route reflector serving many peers, the impact can be significant if Add-All-Paths is used . Monitor the show bgp summary output for total path count vs. prefix count, and track BGP process CPU utilization. For Cisco platforms, the show bgp afi-safi update-group and show bgp memory commands help quantify the overhead. If memory pressure is a concern, reduce the Add-Path send-limit (e.g., from 4 to 2) or restrict Add-Path to critical prefixes via route-map selection .