Theoretical foundations and architecture
Even with instant IP FRR in the core, BGP convergence remains the slowest part of the service: the failure of an egress PE or its link to the CE invalidates hundreds of thousands of VPN prefixes, and without optimisation each is reprogrammed one by one, so the loss time grows with the prefix count and reaches seconds or tens of seconds. Prefix Independent Convergence (PIC) removes this dependency: the FIB is hierarchical, thousands of prefixes point to a shared BGP next-hop object, which in turn points to an IGP path, so a path change updates one pointer regardless of the prefix count. PIC Core reacts to a failure in the core, PIC Edge switches to a pre-installed backup BGP path. For a backup path to exist at all, the RR must send it: use unique RDs, BGP Add-Path (RFC 7911), best-external and multipath. The lesson explains the hierarchical FIB, additional paths, ECMP in VPNv4 and the MRAI, next-hop tracking and scan interval timers. It assumes the knowledge of iBGP, RR and L3VPN from the earlier modules.
Why BGP converges slowly
In the classical scheme each VPN prefix has its own next hop in the FIB, and an egress PE failure means the same next hop for hundreds of thousands of entries. The router must process a withdrawal or next-hop loss for every prefix, select the best path again and reprogram the FIB. If an entry updates in 10-50 microseconds, 500 thousand prefixes give from several seconds to tens of seconds of loss, and more on software platforms. The time grows linearly with the prefix count, and this is exactly the dependency PIC removes.
The hierarchical FIB and PIC Core
With PIC the FIB becomes two-level (in practice a chain or indirect next hop): the prefix points to a shared BGP next-hop object (the PE2 address), and this object points to the IGP path to PE2 (transport label, interface). If a path inside the core breaks, only the lower object changes, for example the ECMP set towards 10.255.0.2: tens of thousands of prefixes are not touched. This protection is called PIC Core: the switchover time does not depend on the prefix count and is set by the speed of the IGP/IP FRR. It needs no additional BGP paths and is usually on by default on modern platforms, but depends on the platform and software version.
PIC Edge and the backup path
PIC Edge answers the failure of an egress PE or its link to the CE. It needs a backup path installed in the FIB: the BGP next-hop object holds the primary and backup next hop (PE2 and PE3), and when PE2 is lost all prefixes switch by pointer to PE3. The backup path must be available in the BGP table, and its next hop must be reachable and should not share fate with the primary (ideally a different PE). The trigger is the disappearance of the next hop /32 in the IGP: therefore PE loopbacks must not be summarised at area borders, otherwise PE1 will not see the failure and will wait for the BGP hold timer (180 s by default on Cisco, 90 s on Junos); the next lesson solves this with BGP-LU and unsummarised /32s.
Where the second path comes from
The RR selects one best path per prefix and reflects only that one unless configured otherwise, so the client does not see a backup. The options. First: a unique RD per VRF and PE (65000:2 and 65000:3): the NLRI differ, both routes are reflected as different VPNv4 routes, and the RT import places them into the VRF. This is the simplest and most widely supported method, but it enlarges the VPNv4 table on the RR (every prefix is multiplied by the number of PEs). Second: BGP Add-Path (RFC 7911): capability 69 negotiates send/receive per AFI/SAFI, and a 4-byte Path Identifier is added to the NLRI, making every path a separate key (prefix + path ID); implicit withdraw works per pair, not per prefix. The RR selects the N best or all paths (for example best 2) or a diverse path (RFC 6774) so that the second path does not traverse the same failing node. Third: best-external - a PE whose best path is internal (from the RR) still advertises the external one (from the CE). Add-Path needs support on the RR and the clients and increases memory and update load, so choose the number of paths deliberately.
Multipath and ECMP in VPNv4
When local preference, AS path length, origin, MED and the IGP metric to the next hop are equal, iBGP multipath (maximum-paths ibgp, multipath) installs several paths in the VRF and spreads traffic across them (per-flow balancing, not per-packet). With different RDs the paths enter the VRF as independent imported routes, and multipath works at the VRF level. The IGP metrics for PE2 and PE3 are usually not equal, so ECMP requires equal metrics or unequal-cost support (Junos: vpn-unequal-cost, Huawei: load-balancing and others). Multipath and PIC complement each other: with ECMP the failure of one path removes only its share of the flow.
BGP timers
MRAI (Minimum Route Advertisement Interval) limits the advertisement rate to one neighbour: 30 s for eBGP by default, usually 0 for iBGP on Cisco (other platforms have different values). A large MRAI slows the background convergence but does not affect the PIC switchover. Next-hop tracking (NHT) is the event-driven BGP reaction to RIB changes: bgp nexthop trigger delay is 5 s by default (Cisco), and for fast convergence it is reduced to 0 (or 1-2 s) on PEs. The scan interval (bgp scan-time, 60 s in classic implementations) checks next-hop reachability periodically; today NHT does this job, so do not rely on the scanner. The BGP hold timer (for example 180 s on Cisco) is only the last line of defence. BFD (single-hop on links) and the IGP watch the core, while BGP watches next-hop reachability. Note that speeding up with small timers increases CPU load during flaps: use dampening or flap protection.
