BGP PIC contains faster and fails faster

Introduction to BGP PIC

BGP Prefix Independent Convergence (PIC) pre‑computes and installs an alternate forwarding path for each BGP prefix before the primary path fails. The alternate is stored in the FIB as a prefix‑independent entry keyed by the next‑hop or outgoing interface. When the primary next‑hop becomes unreachable, the router switches traffic to the backup without waiting for BGP withdrawals, best‑path recomputation, or per‑prefix FIB updates.

This decouples forwarding‑plane convergence from control‑plane convergence, affecting two operator‑relevant metrics:

1. Failover speed – time from primary‑path failure to traffic restoration via a valid alternate.
2. Bad‑path installation speed – window during which traffic may follow an incorrect or looping path after a route leak before the network suppresses the bad route.

Faster failover improves availability; slower bad‑path installation reduces exposure to black‑holing, sub‑optimal routing, or security impact. PIC directly influences failover speed and can also affect bad‑path installation when a leak is learned as a valid alternate.

BGP PIC Core Functionality

Architecture

Because the same backup next‑hop can protect many prefixes sharing the primary next‑hop, state scales with unique next‑hops, not prefix count.

Convergence Comparison

Conventional BGP after a primary next‑hop failure:

1. Physical/link failure detection (sub‑second).
2. BGP peer notification (session may stay up; hold time expires or fast‑external‑fallover triggers).
3. Withdrawal propagation.
4. Local processing – RIB removal, per‑prefix best‑path selection, FIB reinstall.
5. FIB update for each affected prefix.

Steps 3‑5 repeat per prefix, yielding convergence time that grows with prefix count and best‑path complexity.

With BGP PIC:

1. Physical/link failure detection (same).
2. Next‑hop reachability check – forwarding plane detects primary next‑hop loss via ARP/ND failure or carrier loss (~10 ms).
3. Immediate failover to pre‑installed backup via prefix‑independent FIB lookup (sub‑microsecond).

No BGP UPDATE processing or per‑prefix recomputation is required, making convergence largely independent of prefix count.

Configuration & Deployment

Deployment considerations

• Backup path quality – PIC installs whatever the BGP decision process selects as the best alternate. If that path violates policy, apply inbound/outbound filters or RPKI/AS‑PATH filters before PIC installs the backup.
• State size – Backup table scales with unique primary next‑hops. Verify memory usage (show bgp pic summary or equivalent) before enabling at scale.
• Interaction with other fast‑reroute – PIC can coexist with LFA, TI‑LFA, or SR‑TE; ensure selected backup does not conflict with locally repaired paths (avoid double encapsulation).
• BGP timers – PIC does not alter keepalive/hold timers; session teardown still follows negotiated timers unless fast‑external‑fallover is used.
• Validation – After enabling PIC, confirm backup paths are loop‑free and policy‑compliant (see Control‑Plane Trace section).

Benchmarking BGP PIC for Failover and Leak Scenarios

Testbed Setup

To isolate PIC’s effect, keep all variables constant except the PIC feature toggle. A minimal topology:

[PE1]---(L1)---[P1]---(L2)---[PE2]
   |                       |
   | (BGP session)         | (BGP session)
   +-----------------------+

• PE1 & PE2: route‑reflector clients (or direct peers) originating a prefix set (e.g., 100 k IPv4 routes) toward the core.
• P1: core router; primary next‑hop for prefixes is the interface toward PE2 (L2); backup next‑hop is the interface toward PE1 (L1) – symmetric two‑path design.
• All routers run BGP‑4 with identical timers: keepalive = 3 s, hold = 9 s, and BGP fast‑external‑fallover disabled to isolate PIC effects.
• Traffic generators (IXIA, Spirent, or traffic‑replay) send a steady UDP stream (≈10 Gbps) from a host behind PE1 to a destination behind PE2 using the test prefixes.
• Measurement points (sub‑ms resolution via hardware NIC timestamps or PTP‑synchronized clocks):
  • T_fail – moment L2 is administratively shut down.
  • T_blackhole – when traffic stops arriving at the receiver.
  • T_recover – when traffic resumes (successful failover).
  • T_badpath_start – when a leaked route is first injected into the BGP domain.
  • T_badpath_end – when the leak is withdrawn/filtered and traffic returns to the correct path.

Measuring Correct Failover Speed

Baseline (PIC disabled)

1. Disable PIC, shut down L2 on P1.
2. Record T_fail.
3. BGP session P1‑PE2 stays up until hold timer expires (9 s) or a withdrawal is sent after the peer detects link loss (implementation‑dependent).
4. Router processes withdrawal, runs best‑path selection for each of the 100 k prefixes, and installs the new path (via PE1) into the FIB.
5. Traffic resumes after the last prefix FIB update.

Measured failover interval:
T_recover - T_fail ≈ (hold time or BGP withdrawal propagation) + (per‑prefix RIB/FIB update time).
On a typical Xeon‑based router, per‑prefix update for 100 k prefixes ≈ 120 ms (≈1 µs per prefix for RIB delete + best‑path + FIB insert). Adding a 9 s hold yields ≈ 9.12 s failover.

With PIC enabled

1. Enable bgp pic (vendor‑specific equivalent) on P1.
2. Repeat L2 shutdown.
3. Forwarding plane detects loss of liveness on the primary next‑hop (PE2) via ARP/ND failure or carrier loss (~10 ms).
4. FIB immediately switches to the backup next‑hop (PE1) using the pre‑installed prefix‑independent entry.
5. Traffic resumes essentially at the moment of next‑hop loss detection.

Measured failover interval:
T_recover - T_fail ≈ next‑hop loss detection latency (≈10‑20 ms) + FIB lookup latency (< 5 µs).
Thus, PIC reduces failover from seconds to tens of milliseconds, independent of prefix count—provided the backup path is valid and policy‑compliant.

Evaluating Bad‑Path Installation Speed During a Leak

A route leak occurs when an AS incorrectly advertises prefixes it does not originate, diverting traffic toward the leaking AS. To measure bad‑path installation speed, inject a leak and observe how quickly traffic follows the incorrect path.

Common test procedure (PIC enabled or disabled)

1. Stabilize the network with PIC set as required for the test case.
2. From a rogue router or test host with BGP speaker inside AS 65001, originate a more‑specific prefix (e.g., 10.0.0.0/24) actually owned by AS 65002.
3. Advertise the leak to core router P1 via an eBGP session.
4. Start traffic from a sender behind PE1 toward a destination inside the leaked prefix (the true destination resides in AS 65002).
5. Capture:
   • T_leak_start – time the leak UPDATE is received by P1.
   • T_badpath_start – time the first packet arrives at the leaking AS (mirror port or sFlow on the link toward the leak).
   • T_badpath_end – time the leak is withdrawn or filtered (e.g., outbound prefix‑list on P1) and traffic returns to the correct path.
   • T_blackhole_leak – if the leak causes a blackhole (AS‑path looping), measure when traffic stops arriving at the true destination.

Effect of PIC on bad‑path installation

• PIC disabled – The leak is processed like any other UPDATE: P1 inserts it into the RIB, runs best‑path selection, and if it wins (e.g., lower MED or shorter AS‑path), installs the leak prefix → next‑hop (leaking AS) into the FIB. Time from UPDATE receipt to FIB install is dominated by per‑prefix best‑path computation (≈100‑200 ms for 100 k prefixes).

• PIC enabled – The leak follows the normal RIB path unless it is learned as an alternate for an existing primary prefix. PIC installs a backup only when the primary next‑hop fails. Therefore, a leak that does not cause a primary next‑hop failure does not trigger a prefix‑independent backup install. The leak is installed as a regular prefix entry, and timing is essentially identical to the non‑PIC case.

• Subtle acceleration scenario – If the primary next‑hop for a set of prefixes is the link toward PE2 (L2) and the leak advertises a more‑specific prefix reachable via the same primary next‑hop (PE2) with a better attribute (e.g., lower MED), the leak wins best‑path selection and becomes the new primary. PIC then computes a backup based on the new primary next‑hop (still PE2). Should L2 later fail, the already‑installed backup (possibly pointing toward PE1) is used. In this case, the leak does not speed up bad‑path installation; it merely changes which path is considered primary. The bad path becomes active immediately after the leak wins best‑path selection, which occurs at the same speed as without PIC.

Conclusion for benchmarking

• PIC does not inherently accelerate the installation of a leaking prefix as a primary path.
• PIC can reduce the exposure window after a primary next‑hop failure only when the leaked prefix was installed as the backup. This occurs when the leak is learned as a valid alternate for the primary next‑hop. Operators must weigh faster failover against the potential compression of the reaction window for bad‑path installation when deciding to enable PIC.

All CLI examples assume the vendor’s configuration mode; adjust syntax for specific releases as needed.