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

Overview & Thematic Scope

This technical FAQ addresses the pre-sales and post-sales engineering questions most frequently raised when designing BGP Add-Path for sub-second path diversity in enterprise and service provider cores. The focus is strictly on high-availability mechanics: how RFC 7911 changes BGP’s default best-path-only advertisement model, how to negotiate send/receive capabilities correctly across vendors, and how to combine Add-Path with BFD and BGP Fast Reroute to achieve forwarding-plane failover before the control plane converges. All answers assume a route-reflector or route-server topology where path hiding is the primary obstacle to sub-second restoration.

Frequently Asked Questions

Q1: Does BGP Add-Path by itself guarantee sub-second failover for path diversity?

No. BGP Add-Path alone does not guarantee sub-second failover; it only ensures that the local router has pre-computed backup paths in its RIB and FIB. The actual failover speed depends on how quickly the failure is detected and whether the backup path is already installed in hardware. With Add-Path, a router holds multiple paths for the same prefix, each with a unique Path Identifier, allowing it to pre-install a backup next-hop in the FIB; if the primary peer fails, failover can occur at line rate without waiting for a new BGP update from the route reflector . To approach sub-second restoration, you must pair Add-Path with a fast failure-detection mechanism such as BFD on the BGP session or next-hop tracking in the IGP .

Q2: What capability must be negotiated on both peers before BGP Add-Path can send or receive multiple paths?

Both peers must advertise the ADD-PATH Capability (Capability Code 69) with compatible Send/Receive values for the specific AFI/SAFI. Per RFC 7911, the Send/Receive field uses value 1 for receive-only, 2 for send-only, and 3 for both send and receive . For a route reflector to send multiple paths to a client, the RR must be configured to send for that address family, and the client must be configured to receive. If only one side is configured, the capability negotiation fails and standard best-path-only behavior persists . Always verify the negotiated capability with vendor-specific show commands before assuming Add-Path is active.

Q3: How does BGP Add-Path eliminate the path-hiding problem introduced by route reflectors?

BGP Add-Path eliminates path hiding by allowing the route reflector to advertise multiple paths for the same prefix instead of only its single best path. In a standard route-reflector design, the RR selects one best path and reflects only that path to clients; if that path fails, clients must wait for the RR to recompute and send a withdrawal plus a new update . With Add-Path enabled, the RR attaches a unique 4-octet Path Identifier to each path and advertises the backup paths alongside the best path, so clients have visibility into alternative next-hops before a failure occurs . This is particularly critical in public peering and large iBGP meshes where the RR’s best-path choice may not align with the client’s local policy or latency requirements.

Q4: What is the recommended configuration pattern to install a backup path for fast reroute without making it active?

The recommended pattern is to use a route policy that selects and installs the backup path while advertising it with the multipath-protect or backup designation, depending on vendor syntax. On Cisco IOS-XR, for example, a route policy can use set path-selection backup 1 install multipath-protect advertise to install one backup path for fast reroute while still advertising the best path and the protected multipath path to neighbors . The key principle is that the backup path must be present in the RIB and FIB but must not win the best-path selection until the primary becomes unreachable. Nokia SR-OS implements a similar model with a configurable send-limit per address family per peer, allowing up to 16 paths to be advertised while the receiving router decides which to install .

Q5: How many additional paths can typically be configured per prefix, and what limits should be audited before enabling Add-Path?

Vendor implementations commonly support up to 16 paths per prefix per peer for advertisement, though the exact send-limit is platform-dependent. Nokia SR-OS, for example, allows a configurable send-limit of up to 16 paths per address family per peer . The critical pre-deployment audit is max-prefix limits: because Add-Path increases the number of routes received for the same prefix, a session that previously received one path per prefix may now receive three or more, potentially triggering a max-prefix session flap if the limit is not raised . You should also verify TCAM and FIB scale on the receiving routers, because pre-installing backup paths consumes forwarding table entries that would otherwise be unused.

Q6: Which failure-detection mechanism should be paired with Add-Path to achieve the fastest possible switchover?

BFD is the recommended failure-detection mechanism to pair with Add-Path for sub-second switchover. BFD provides sub-second detection on the BGP session or on the data path, and when combined with BGP Fast Reroute and Add-Path, it allows the router to invalidate the primary path and activate the pre-installed backup before the BGP withdrawal propagates through the route reflector . Without BFD, you rely on BGP hold timers or IGP next-hop tracking, both of which are slower than a dedicated detection protocol. For direct eBGP sessions, enable BFD on the eBGP neighbor; for iBGP through a route reflector, enable BFD on the underlying IGP path or use next-hop tracking so that the failure is detected locally on the receiving router.

Q7: Does BGP Add-Path increase routing churn or destabilize the control plane during link flaps?

No; properly configured BGP Add-Path actually reduces routing churn by constraining the scope of withdrawal propagation. Without Add-Path, a flapping link causes a withdrawal to propagate through the route reflector to all clients, followed by a new advertisement for the next-best path, creating repeated update cycles . With Add-Path, the route reflector continues advertising the stable backup path while the primary flaps, so downstream routers do not experience a full withdrawal-and-relearn cycle for every flap. Nokia documentation notes that Add-Path helps reduce routing churn by constraining the effect of failures to the local AS where they occur, rather than propagating instability across the entire iBGP domain . The one caveat is that you should monitor CPU and RIB memory, because more paths per prefix means more state to maintain.

Q8: How do I verify that Add-Path is actually negotiating and receiving multiple paths with unique Path IDs?

Use vendor-specific operational commands to confirm three things: capability negotiation, multiple next-hops per prefix, and Path ID uniqueness. On Junos, show bgp neighbor should display “NLRI’s for which peer can receive multiple paths” and “NLRI’s for which peer can send multiple paths,” and show route detail should list multiple entries with distinct Addpath Path IDs . On Nokia SR-OS, show router bgp neighbor | match "AddPath" confirms Local and Remote AddPath Capability status, and show router bgp routes displays the Path-Id column for each received path . If you see only one next-hop per prefix after enabling Add-Path, check that both send and receive capabilities are configured on both ends and that the session has been reset or refreshed to renegotiate the capability.