BGP Fast Reroute
This chapter provides information about BGP Fast Reroute.
Topics in this chapter include:
Applicability
The CLI in the latest update of this chapter is based on SR Linux Release 26.3.3.
Overview
Border Gateway Protocol (BGP) is a key protocol for ISPs, supporting inter-Autonomous System (inter-AS) and intra-Autonomous System (intra-AS) applications with many address families. Additionally, ISPs need to maintain the service level agreements with their customers, even in case of network failures.
MPLS Fast Reroute (FRR) is often used to provide resiliency to intra-AS services, and relies on alternate label switched paths being established through the network. Traffic is switched to alternate paths in case of a failure of primary paths.
However, the traffic for inter-AS services crosses the boundaries of multiple ASs, so to provide resiliency, BGP FRR can be used. Before a network failure occurs, multiple paths must be received for a prefix to take advantage of this feature. When a prefix has a backup path and its primary paths fail, the affected traffic is rapidly diverted to the backup path without waiting for the control plane to reconverge. When many prefixes share the same primary paths, and in some cases also the same backup path, the time to divert traffic to the backup path is independent of the number of prefixes; this is also known as Prefix Independent Convergence (PIC). The traffic goes back to the primary paths when those paths are restored. Multiple primary paths can be active simultaneously when Equal Cost Multi Path (ECMP) applies.
Two BGP FRR functions are supported: Core PIC and Edge PIC. Core PIC describes a scenario where a link or node on the path to the BGP next-hop fails, but the BGP next-hop remains reachable; see Core PIC. Edge PIC describes a scenario where an edge node or edge link fails, which results in a change of the BGP next-hop; see Edge PIC.
Core PIC is enabled by default and cannot be disabled. Therefore, this chapter describes the use of Edge PIC.
BGP FRR is supported for different BGP address families in the default network instance or within a specific IP-VRF network instance. This chapter focuses on the IPv4 address family within the default network instance.
BGP add-paths can be used to allow BGP to maintain multiple paths through an autonomous system.
Convergence goes through several phases, which also apply to BGP:
detect the network failure
distribute updated routing information, and update the network topology
calculate new routes, and optionally change next-hops
update the forwarding plane
Several mechanisms are available to enhance BGP network convergence, such as Bidirectional Forwarding Detection (BFD) and Minimum Router Advertisement Interval (MRAI).
Configuration
The example topology used in this chapter is shown in BGP FRR topology, and has the following characteristics:
IBGP sessions are established between AS 65537 routers using RR-6 as route reflector (RR) with P-2, P-3, P-4, and PE-5 as RR clients.
EBGP sessions are established between P-2 and P-3 of AS 65537 and PE-1 of AS 65536.
PE-1 advertises a BGP route for prefix 172.16.1.0/24 with community "1:0" to P-2 and P-3.
P-2 changes the local preference to 150 for the route advertised to RR-6. Import policy rp-import-LP150 on P-2 accepts routes with community "1:0" and modifies the local preference to 150; import policy rp-comm-1:0 on P-3 accepts routes with community "1:0" without modifications.
PE-5 advertises a BGP route for prefix 172.16.5.0/24 with community "1:0" to RR-6. This route is re-advertised to the other RR clients and eventually, by P-2 and P-3 to PE-1.
These characteristics enforce traffic for destination 172.16.1.0/24 to leave AS 65537 via P-2. P-2 (and also PE-5) learns the destination and the local preference via RR-6. But because P-3's own local preference is lower (default LP=100), it stops advertising prefix 172.16.1.0/24 toward RR-6, so that P-4 is aware of the path via P-2 only.
The objective is for P-4 to receive multiple alternate paths for the 172.16.1.0/24 prefix with redundant next-hops, to provide for faster convergence under failure. BGP must have at least one valid alternate path candidate with a different next-hop.
BGP add-paths is needed if the topology would otherwise hide alternate paths, for example, nodes only learn one path because the upstream only advertises one path. The BGP add-paths feature is required in scenarios with route reflectors.
In this example, multiple exit paths for prefix 172.16.1.0/24 leaving AS 65537 are available, improving the convergence time on the IBGP peers because they only need to update their FIBs if they lose the primary route.
BGP add-paths
P-2, P-3, P-4 and RR-6 are configured with the BGP add-paths feature. PE-5 does not require the add-paths feature, because the alternate path to 172.16.1.0/24 starts in P-4.
# on P-2, P-3, P-4, RR-6:
enter candidate
network-instance default {
protocols {
bgp {
group grp-IBGP {
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
The BGP configuration on P-2 is as follows:
# on P-2:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 65537
router-id 192.0.2.2
best-path-selection {
advertise-inactive true
}
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP {
peer-as 65536
export-policy [
rp-comm-1:0
]
import-policy [
rp-import-LP150
]
}
group grp-IBGP {
next-hop-self true
peer-as 65537
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 10.0.12.1 {
peer-group grp-EBGP
}
neighbor 192.0.2.6 {
peer-group grp-IBGP
}
}
The BGP configuration for P-3 and P-4 is similar and is not shown here.
The BGP configuration on RR-6 is as follows:
# on RR-6:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 65537
router-id 192.0.2.6
best-path-selection {
advertise-inactive true
}
afi-safi ipv4-unicast {
admin-state enable
}
group grp-IBGP {
peer-as 65537
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
route-reflector {
client true
cluster-id 192.0.2.6
}
}
neighbor 192.0.2.2 {
peer-group grp-IBGP
}
neighbor 192.0.2.3 {
peer-group grp-IBGP
}
neighbor 192.0.2.4 {
peer-group grp-IBGP
}
neighbor 192.0.2.5 {
peer-group grp-IBGP
}
The default behavior of a route reflector is to only consider the best path. By enabling the add-paths feature on RR-6, multiple paths are considered.
Both P-2 and P-3 advertise route 172.16.1.0/24 to RR-6, as follows:
--{ + running }--[ ]--
A:admin@P-2# show network-instance default protocols bgp neighbor 192.0.2.6 advertised-routes ipv4
-----------------------------------------------------------------------------------------------------------------
Peer : 192.0.2.6, remote AS: 65537, local AS: 65537
Type : static
Description : None
Group : grp-IBGP
-----------------------------------------------------------------------------------------------------------------
Origin codes: i=IGP, e=EGP, ?=incomplete
+---------------------------------------------------------------------------------------------------------------+
| Network Path-id Next Hop MED LocPref AsPath Origin |
+===============================================================================================================+
| 172.16.1.0/24 1 192.0.2.2 - 150 [65536] i |
+---------------------------------------------------------------------------------------------------------------+
-----------------------------------------------------------------------------------------------------------------
1 advertised BGP routes
-----------------------------------------------------------------------------------------------------------------
--{ + running }--[ ]--
A:admin@P-3# show network-instance default protocols bgp neighbor 192.0.2.6 advertised-routes ipv4
-----------------------------------------------------------------------------------------------------------------
Peer : 192.0.2.6, remote AS: 65537, local AS: 65537
Type : static
Description : None
Group : grp-IBGP
-----------------------------------------------------------------------------------------------------------------
Origin codes: i=IGP, e=EGP, ?=incomplete
+---------------------------------------------------------------------------------------------------------------+
| Network Path-id Next Hop MED LocPref AsPath Origin |
+===============================================================================================================+
| 172.16.1.0/24 1 192.0.2.3 - 100 [65536] i |
+---------------------------------------------------------------------------------------------------------------+
-----------------------------------------------------------------------------------------------------------------
1 advertised BGP routes
-----------------------------------------------------------------------------------------------------------------
For more examples of the BGP add-paths feature, see the BGP Add-Paths chapter.
Backup paths
P-4 is the place in the topology where an alternate path is created. The data plane part of the Edge PIC configuration is performed by configuring backup-paths for afi-safi ipv4-unicast in the bgp context. In the following, backup-paths are considered for the IPv4 address family only, but the IPv6, label-IPv4, and label-IPv6 address families are allowed too.
# on PE-1, P-4:
enter candidate
network-instance default {
protocols {
bgp {
afi-safi ipv4-unicast {
admin-state enable
ipv4-unicast {
backup-paths {
install true
}
}
In this way, BGP considers all alternate paths which are present through the BGP add-paths feature. The BGP configuration on P-4 is as follows:
# on P-4:
enter candidate
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 65537
router-id 192.0.2.4
afi-safi ipv4-unicast {
admin-state enable
ipv4-unicast {
backup-paths {
install true
}
}
}
group grp-IBGP {
peer-as 65537
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 192.0.2.6 {
peer-group grp-IBGP
}
In the default BGP behavior, without the backup-paths install true configuration, two BGP routes exist. Both routes are valid, but only the first one is the best path, as follows:
--{ + running }--[ ]--
A:admin@P-4# show network-instance default protocols bgp routes ipv4 prefix 172.16.1.0/24
-----------------------------------------------------------------------------------------
Show report for the BGP routes to network "172.16.1.0/24" network-instance "default"
-----------------------------------------------------------------------------------------
Network: 172.16.1.0/24
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.6
Route Preference: MED is -, LocalPref is 150
BGP next-hop : 192.0.2.2
Path : i [65536]
Communities : 1:0
Path 2: <Valid,>
Route source : neighbor 192.0.2.6
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.3
Path : i [65536]
Communities : 1:0
Path 1 was advertised to:
[ ]
-----------------------------------------------------------------------------------------
In the routing table, route 172.16.1.0/24 has next hop 192.0.2.2, as follows:
--{ + running }--[ ]--
A:admin@P-4# show network-instance default ipv4 route 172.16.1.0/24
=========================================================================================
IPv4-unicast route table for default network-instance
-----------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
-----------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
-----------------------------------------------------------------------------------------
172.16.1.0/24 bgp 10 170 > 192.0.2.2(route:isis)
With the backup-paths install true configuration, both BGP routes are valid and used; the first route is the best path, and the second route is explicitly marked to be a backup path, as follows:
--{ + running }--[ ]--
A:admin@P-4# show network-instance default protocols bgp routes ipv4 prefix 172.16.1.0/24
-----------------------------------------------------------------------------------------
Show report for the BGP routes to network "172.16.1.0/24" network-instance "default"
-----------------------------------------------------------------------------------------
Network: 172.16.1.0/24
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.6
Route Preference: MED is -, LocalPref is 150
BGP next-hop : 192.0.2.2
Path : i [65536]
Communities : 1:0
Path 2: <Valid,Used,Backup,>
Route source : neighbor 192.0.2.6
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.3
Path : i [65536]
Communities : 1:0
Path 1 was advertised to:
[ ]
-----------------------------------------------------------------------------------------
In the routing table, route 172.16.1.0/24 has next-hop 192.0.2.2 for the best path and next-hop 192.0.2.3 for the backup:.
--{ + running }--[ ]--
A:admin@P-4# show network-instance default ipv4 route 172.16.1.0/24
=============================================================================================
IPv4-unicast route table for default network-instance
---------------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
---------------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
---------------------------------------------------------------------------------------------
172.16.1.0/24 bgp 10 170 > 192.0.2.2(route:isis)
backup:192.0.2.3(route:isis)
The detailed route information for prefix 172.16.1.0/24 includes next-hop-group 93479432 with primary next-hop 934794322 with IP address 192.0.2.2 and backup next-hop 934794321 with IP address 192.0.2.3, as follows:
--{ + running }--[ ]--
A:admin@P-4# show / network-instance default ipv4 route 172.16.1.0/24 detail
============================================================================================
Prefix: 172.16.1.0/24
--------------------------------------------------------------------------------------------
Active : yes
Route Type : bgp
Route Owner : bgp_mgr, 2026-06-15T09:32:24.389Z (56 seconds ago)
Id : 0
Leakable : no
Leaked : no
Metric : 10
Preference : 170
Internal Tags : none
Dynamic LB : no
Resilient Hash : no
FIB Suppressed : no
FIB Failed : no
Next-Hop-Group : 934794321
Net-Instance : default
FIB Failed : no
Primary NH Count : 1
Backup NH Count : 1
Primary NH : 934794322
LB Weight : 1
Type : indirect
IP Address : 192.0.2.2
Resolved : yes
Resolving Route : 192.0.2.2/32(isis)
Backup NH : 934794321
Type : indirect
IP Address : 192.0.2.3
Resolved : yes
Resolving Route : 192.0.2.3/32(isis)
The active and standby selection is also visible in the following command that shows what is actually programmed in the FIB for next-hop-group 934794321:
--{ + running }--[ ]--
A:admin@P-4# info from state with-context / network-instance default route-table next-hop-group 934794321
network-instance default {
route-table {
next-hop-group 934794321 {
backup-next-hop-group 0
backup-active false
fib-programming {
last-successful-operation-type add
last-successful-operation-timestamp "2026-06-15T09:32:24.390Z (2 minutes ago)"
pending-operation-type none
last-failed-operation-type none
}
next-hop 0 {
next-hop 934794322
resolved true
resource-allocation-failed false
}
backup-next-hop 0 {
next-hop 934794321
resolved true
resource-allocation-failed false
}
}
}
}
In summary, two paths are available out of P-4 and leading to 172.16.1.0/24 in the remote AS, but only one is installed in the forwarding plane. The active route is P-4-P-2-PE-1; the backup route is P-4-P-3-PE-1. A traceroute command confirms the active path, as follows:
--{ + running }--[ ]--
A:admin@PE-5# traceroute network-instance default 172.16.1.1 -n
Using network instance default
traceroute to 172.16.1.1 (172.16.1.1), 30 hops max, 60 byte packets
1 192.168.45.1 2.141 ms 2.119 ms 2.105 ms
2 192.168.24.1 3.054 ms 3.036 ms 3.024 ms # on P-2
3 172.16.1.1 4.017 ms 4.008 ms 3.994 ms
Faster convergence through BFD
As already described, BFD can help speed up BGP convergence, mainly when detecting network failures. In the following, BFD is enabled on the EBGP sessions and on the IS-IS protocol.
The BFD parameters are defined at subinterface level, enabling BFD for a protocol is done in the protocol context. Because PE-1 only has EBFD sessions toward P-2 and P-3, it is enabled at the BGP global level, but it can also be enabled at the BGP group or neighbor level.
# on PE-1:
enter candidate
bfd {
subinterface ethernet-1/2.1 {
admin-state enable
}
subinterface ethernet-1/3.1 {
admin-state enable
}
}
network-instance default {
protocols {
bgp {
failure-detection {
enable-bfd true
}
Because the BFD configuration for P-2 and P-3 is similar, it is only shown for P-2, as follows:
# for P-2:
enter candidate
bfd {
subinterface ethernet-1/1.1 {
admin-state enable
}
subinterface ethernet-1/4.1 {
admin-state enable
}
}BFD is enabled at group level, for group grp-EBGP only, as follows:
# on P-2:
enter candidate
network-instance default {
protocols {
bgp {
group grp-EBGP {
failure-detection {
enable-bfd true
}
}
}
BFD for IS-IS is enabled at the IS-IS interface level, and is enabled for IPv4 unicast only, as follows.
# on P-2:
enter candidate
network-instance default {
protocols {
isis {
instance 0 {
interface ethernet-1/4.1 {
ipv4-unicast {
enable-bfd true
}
}
}
Faster convergence through MRAI
Adjusting the BGP MRAI also can help speed up network convergence, using the following command:
--{ +* candidate shared default }--[ network-instance default protocols bgp group grp-EBGP timers ]--
A:admin@PE-1# minimum-advertisement-interval <value:5>
usage: minimum-advertisement-interval <1..255>
The value assigned to the MinRouteAdvertisementIntervalTimer of RFC 4271, for both EBGP and IBGP sessions
Each session runs its own independent timer and the timer affects both route advertisements and route withdrawals, regardless of address family. For route withdrawals only, this timer is bypassed if rapid- withdrawal is set to true.
Positional arguments:
value [number, range 1..255, units seconds, default 5]
Lowering the MRAI puts a higher load on the CPM, so a trade-off must be made between convergence time and processing load.
Switchover
To demonstrate a switchover scenario, a failure is introduced by disabling subinterface ethernet-1/2.1 on PE-1, as follows:
# on PE-1:
enter candidate
interface ethernet-1/2 {
subinterface 1 {
admin-state disable
The path through the network is PE-5-P-4-P-3-PE-1, as follows:
--{ + running }--[ ]--
A:admin@PE-5# traceroute network-instance default 172.16.1.1 -n
Using network instance default
traceroute to 172.16.1.1 (172.16.1.1), 30 hops max, 60 byte packets
1 192.168.45.1 2.796 ms 2.766 ms 2.750 ms
2 192.168.34.1 2.676 ms 2.674 ms 2.662 ms # on P-3
3 172.16.1.1 3.640 ms 3.636 ms 3.622 ms
On P-4, traffic is now diverted to P-3, and the BGP routes are as follows:
--{ + running }--[ ]--
A:admin@P-4# show network-instance default protocols bgp routes ipv4 prefix 172.16.1.0/24
-----------------------------------------------------------------------------------------
Show report for the BGP routes to network "172.16.1.0/24" network-instance "default"
-----------------------------------------------------------------------------------------
Network: 172.16.1.0/24
Received Paths: 1
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.6
Route Preference: MED is -, LocalPref is 100
BGP next-hop : 192.0.2.3
Path : i [65536]
Communities : 1:0
Path 1 was advertised to:
[ ]
-----------------------------------------------------------------------------------------The route table is as follows:
--{ + running }--[ ]--
A:admin@P-4# show network-instance default ipv4 route 172.16.1.0/24
========================================================================================
IPv4-unicast route table for default network-instance
----------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
----------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
----------------------------------------------------------------------------------------
172.16.1.0/24 bgp 10 170 > 192.0.2.3(route:isis)
The forwarding plane is reprogrammed to send traffic for the 172.16.1.0/24 subnet to P-3, as follows:
--{ + running }--[ ]--
A:admin@P-4# show network-instance default ipv4 route 172.16.1.0/24 detail
=========================================================================================
Prefix: 172.16.1.0/24
-----------------------------------------------------------------------------------------
Active : yes
Route Type : bgp
Route Owner : bgp_mgr, 2026-06-15T09:38:46.662Z (33 seconds ago)
Id : 0
Leakable : no
Leaked : no
Metric : 10
Preference : 170
Internal Tags : none
Dynamic LB : no
Resilient Hash : no
FIB Suppressed : no
FIB Failed : no
Next-Hop-Group : 934794322
Net-Instance : default
FIB Failed : no
Primary NH Count : 1
Backup NH Count : 0
Primary NH : 934794321
LB Weight : 1
Type : indirect
IP Address : 192.0.2.3
Resolved : yes
Resolving Route : 192.0.2.3/32(isis)
Bringing subinterface ethernet-1/2.1 on PE-1 up again results in the path PE-5-P-4-P-2-PE-1 being reactivated. Switchback takes longer, because the external BGP session needs to be re-established, and routes have to be relearned.
Conclusion
BGP FRR provides ISPs the means to offer backup paths with fast switchover times when used in combination with short failure detection times and short advertisement intervals. By guaranteeing service in case of network failures, ISPs can provide enhanced service offerings to their customers.