Day 54 — BGP PIC: Prefix-Independent Convergence and the Data-Plane Fast Path

1. Opening

BGP PIC changes the convergence problem from 'recalculate thousands of prefixes after failure' toward 'preinstall or precompute an alternate next-hop relationship and switch the affected forwarding dependency.' The value is not that BGP suddenly selects a different best path faster in theory; the value is that the data plane can avoid per-prefix convergence work after a shared next-hop failure.

2. Concept and standards behavior

Cisco describes BGP Prefix Independent Convergence as an architecture in which alternate next-hop information can be prepared so Cisco Express Forwarding can switch affected prefixes rapidly when a failure is detected. Cisco documentation distinguishes convergence work in the control plane from data-plane convergence and notes that actual subsecond behavior depends on software/hardware implementation. PIC terminology and support are implementation-specific; do not turn a platform feature into a universal BGP RFC behavior.

A recurring discipline in convergence engineering is to separate failure detection, control-plane reaction, RIB decision, and FIB repair. Different features accelerate different stages. A design that reports a fast protocol event but still forwards into a dead path has not achieved useful convergence.

3. Scenario success criteria

1. Define the failure signal before tuning convergence.
2. Capture control-plane and forwarding state before modification.
3. Change only one detection or HA mechanism at a time.
4. Use a positive traffic test and a negative/containment test.
5. Preserve logs and timing evidence through the fault.
6. Roll back if instability increases or forwarding safety becomes less certain.

4. Topology

                 +--------------------+
                 |   CORE / UNDERLAY   |
                 +----------+---------+
                            |
        +-------------------+-------------------+
        |                                       |
   EDGE-A / AS65010                        EDGE-B / AS65020
   Lo0 192.0.2.10                          Lo0 192.0.2.20
        |                                       |
        +----------- service / test ------------+
                     203.0.113.0/24

The exact node roles change by day; the matching SVG/PNG diagram is authoritative for the lab arrangement.

5. Prerequisites

• Cisco IOS XE 17.18.x documentation baseline unless the post explicitly calls out a broader 17.x feature document.
• Documentation-safe addressing and lab-only credentials.
• Stable IGP/underlay before enabling fast failure mechanisms.
• Time synchronization for event sequencing.
• Independent management access.
• Baseline captures of BGP summary, route detail, RIB/FIB state and traffic.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors
show bgp ipv4 unicast 203.0.113.0/24
show ip route
show ip cef 203.0.113.1 detail
show logging

Where relevant, add BFD, redundancy, graceful-restart or platform-specific verification commands documented for the actual image.

10. Step-by-step troubleshooting

1. Establish the exact failure time from logs/telemetry.
2. Determine whether endpoint reachability changed.
3. Determine whether the BGP TCP session changed state.
4. Determine whether BFD/IGP/next-hop tracking changed first.
5. Inspect the selected BGP path and recursive NEXT_HOP.
6. Inspect RIB installation.
7. Inspect CEF/FIB programming.
8. Check stale/GR/NSR state if HA behavior is involved.
9. Compare the observed event order with the expected convergence design.
10. Correct the smallest proven cause.
11. Repeat the identical fault and measurements.
12. Observe stability after recovery.

12. Post-fix verification

Verify BGP state, selected path, route validity, RIB/FIB installation, end-to-end traffic, negative test, logs/counters, and a stability interval appropriate to the lab. A protocol-state recovery is not accepted as success if forwarding remains broken.

13. Rollback

Revert only the new timer, BFD, tracking, GR/NSR or PIC control introduced by the day. Restore the captured baseline and repeat the original verification set. Roll back immediately for repeated oscillation, unexpected multi-peer resets, persistent stale blackholing, loss of forwarding redundancy, or a platform behavior inconsistent with the documented prerequisite.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

router bgp 65010
 address-family ipv4
  maximum-paths 2
 exit-address-family
!
! PIC feature enablement/support varies by IOS XE platform and use case.
! Verify exact BGP PIC edge/core syntax and prerequisites before lab execution.

show bgp ipv4 unicast 203.0.113.0/24
show ip cef 203.0.113.1 detail

Exact commands, defaults and support must be verified on the actual IOS XE hardware/software image before execution.

8. Controlled modification

Prepare a supported alternate path and capture BGP, RIB and CEF state before failure. Then fail the shared primary next hop and measure which layer switches first.

State the expected detection source, expected BGP event, expected RIB change and expected FIB behavior before applying the change.

9. Fault injection

Illustrative lab — not a real incident.

Withdraw the primary next-hop reachability for a large prefix set. Keep the BGP control plane otherwise stable so the experiment isolates shared next-hop convergence rather than session reset.

11. Root cause and correction

If forwarding still waits on per-prefix recalculation, the alternate forwarding dependency was not precomputed/installed as assumed or the platform/use case does not support the intended PIC behavior. Correct the feature prerequisites or redesign the convergence objective rather than claiming PIC from multipath configuration alone.

14. Deep-dive engineering notes

Prefix independent refers to failure fan-out

Many prefixes can share one recursive next hop. If failure handling is represented at that dependency, the data plane can switch the shared relationship instead of rewriting each prefix individually.

PIC edge and PIC core are not interchangeable labels

Edge convergence commonly concerns loss of an external/PE path and switching to an alternate BGP exit. Core convergence concerns transport/IGP reachability beneath BGP next hops. Platform documentation should determine which feature is actually supported.

Multipath is related but not equivalent

Having more than one BGP path does not prove the FIB has the precomputed backup structure required for PIC. Inspect recursive/CEF state, not just show bgp.

Measurement discipline

Measure detection time, FIB switch time, packet-loss window, and later BGP reconvergence separately. A fast FIB repair can happen before the control plane has fully converged. That separation is the central operational lesson of PIC.

15. Production lessons

• Faster failure detection is useful only when the signal is trustworthy.
• Do not combine multiple fast-convergence mechanisms until each works independently.
• Preserve the distinction between control-plane recovery and forwarding-plane continuity.
• High-availability features often have platform, topology and address-family restrictions.
• Measure actual traffic loss and event ordering instead of advertising a theoretical convergence number.

16. Knowledge check

1. Which stage does today's feature accelerate: detection, BGP decision, RIB update, FIB repair, or more than one?
2. What failure could make the feature produce a false sense of availability?
3. What evidence would prove forwarding recovered before the BGP control plane fully reconverged?

Answers

1. See the day's mechanism: the answer must name the specific accelerated stage rather than saying simply 'BGP convergence.'
2. A false/unstable detection signal, unsupported HA state, invalid stale-route assumption, or absent precomputed forwarding alternate depending on the topic.
3. Timestamped traffic/FIB evidence showing forwarding switched while BGP path processing was still completing.

17. Sources

• Cisco IOS XE 17.x: BGP Multipath/PIC — https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-routing/b-ip-routing/m_irg-bgp-mp-pic-0.html
• Cisco IOS XE 17.x: BGP next-hop tracking — https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-routing/b-ip-routing/m_irg-nexthop-track.html
• RFC 7938: Use of BGP for Routing in Large-Scale Data Centers — https://www.rfc-editor.org/rfc/rfc7938.html