Introduction
The OSPF Loop-Free Alternate Fast reroute feature can be implemented to optimize convergence within an OSPF routing-domain. It reuses an already precomputed alternate path (next-hop) to reduce the reaction time in case that the primary path fails. It gives you the option to precompute a per-prefix loop-free alternate (LFA) path which redirects the traffic through a secondary next-hop.
LFA Repair Path Attributes
If a primary path fails, many paths can be considered as candidate repair paths. The FRR default selection algorithm prioritizes attributes in the following order:
- srlg
- primary-path
- interface-disjoint
- lowest-metric
- linecard-disjoint
- node-protecting
- broadcast-interface-disjoint
If the evaluation does not select any candidate path, the repair path is selected by load-balancing. This means that repair path selection varies depending on the prefix.
By configuring fast-reroute tie-break you can configure one or multiple repair-path attributes described below to select among all candidates:
Shared Risk Link Groups (SRLG)
A shared risk link group (SRLG) defines a group of next-hop interfaces which have a high risk of simultaneous failure. Different VLANs on a single physical interface are an example of SRLG. If the physical link fails, all VLAN interfaces will fail at the same time. SRLGs are individually configured on the routers and are locally significant. Configuring SRLGs to specify that the LFA repair path does not share the same SRLG as the primary path is highly recommended.
Interface Protection
Point-to-point interfaces do not have an alternate next-hop for rerouting if the primary next-hop fails. In a broadcast network you can configure interface-disjoint attribute to prevent selection of such repair paths, thus protecting the interface.
Broadcast Interface Protection
On point-to-point interfaces the LFA repair path protects links if a repair path and a protected primary path use different next-hop interfaces. However, on broadcast interfaces if the LFA repair path is computed via the same interface as the primary path, but next-hop addresses are different, the node is protected but not the link. You can therefore configure broadcast-interface-disjoint to specify that the repair path never crosses the same broadcast network which the primary path does.
Node Protection
By default, the repair path might not protect the router (node) which is the next hop in a primary path. By configuring node-protection you can make sure that the repair path will not use the same node than the primary path.
Downstream Path
In case of a serious network failure or multiple simultaneous network failures, traffic sent over an alternate path might loop until OSPF recalculates the primary path. By configuring downstream attribute, you can make sure that the metric of any repair path to the protected destination must be lower than that of the protecting node to the destination.
Line-Card Disjoint Interfaces
Line-Card interfaces are very similar to SRLGs because all interfaces on the same line card will fail at the same time in case of a line card failure. You can configure the linecard-disjoint attribute to specify that the repair path should use different interfaces on a different line card than those of the primary path.
Metric
The LFA repair path does not need to be the most efficient of all candidate paths. A high-cost repair path might be preferred over a more efficient alternate path if it is providing better protection against higher-level network failures. This behavior can be changed using the metric attribute where you can configure a repair path policy which has the lowest metric.
Equal-Cost Multipath Primary Paths
Equal-Cost multipath paths (ECMPs) which have been calculated during the initial SPF repair, might not be desirable in a topology where traffic is known to exceed the capacity of a single link. By configuring the primary-path attribute an LFA repair path will be chosen from the ECMP set, or by specifying the secondary-path attribute a LFA repair path which is not part of the ECMP set will be chosen.
Candidate Repair-Path Lists
If OSPF calculates an LFA repair path, it puts in the RIB only the best among all candidate repair paths, in order to conserve memory. For troubleshooting purposes you can configure fast-reroute keep-all-paths to create a list of all candidate repair paths which have been considered. Be aware that this operation will use additional memory and should only be used for troubleshooting.
How to configure OSPF Loop-Free Alternate Fast Reroute
The following network topology will be used for the below configurations. If changes on the design are required, an updated design will be shown in that specific section.
Basic startup configuration without LFA FRR
Configuration
| hostname R1 ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface GigabitEthernet1 description to R2 ip address 10.0.0.1 255.255.255.252 ip ospf network point-to-point ip ospf cost 10 ! interface GigabitEthernet2 description to R3 ip address 10.0.0.5 255.255.255.252 ip ospf network point-to-point ip ospf cost 30 ! interface GigabitEthernet4 description to R2 – Secondary Path ip address 10.0.0.13 255.255.255.252 ip ospf network point-to-point ip ospf cost 20 ! router ospf 1 router-id 1.1.1.1 passive-interface default no passive-interface GigabitEthernet1 no passive-interface GigabitEthernet2 no passive-interface GigabitEthernet4 network 1.1.1.1 0.0.0.0 area 0.0.0.0 network 10.0.0.0 0.0.0.3 area 0.0.0.0 network 10.0.0.4 0.0.0.3 area 0.0.0.0 network 10.0.0.12 0.0.0.3 area 0.0.0.0 |
| hostname R2 ! interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface GigabitEthernet1 description to R1 ip address 10.0.0.2 255.255.255.252 ip ospf network point-to-point ! interface GigabitEthernet3 description to R3 ip address 10.0.0.9 255.255.255.252 ip ospf network point-to-point ! interface GigabitEthernet4 description to R1 – Secondary Path ip address 10.0.0.14 255.255.255.252 ip ospf network point-to-point ! router ospf 1 router-id 2.2.2.2 passive-interface default no passive-interface GigabitEthernet1 no passive-interface GigabitEthernet3 no passive-interface GigabitEthernet4 network 2.2.2.2 0.0.0.0 area 0.0.0.0 network 10.0.0.0 0.0.0.3 area 0.0.0.0 network 10.0.0.8 0.0.0.3 area 0.0.0.0 network 10.0.0.12 0.0.0.3 area 0.0.0.0 |
| hostname R3 ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface GigabitEthernet2 description to R1 ip address 10.0.0.6 255.255.255.252 ip ospf network point-to-point ! interface GigabitEthernet3 description to R2 ip address 10.0.0.10 255.255.255.252 ip ospf network point-to-point ! router ospf 1 router-id 3.3.3.3 passive-interface default no passive-interface GigabitEthernet2 no passive-interface GigabitEthernet3 network 3.3.3.3 0.0.0.0 area 0.0.0.0 network 10.0.0.4 0.0.0.3 area 0.0.0.0 network 10.0.0.8 0.0.0.3 area 0.0.0.0 |
Verification
| R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via “ospf 1”, distance 110, metric 11, type intra area Last update from 10.0.0.2 on GigabitEthernet1, 00:00:53 ago Routing Descriptor Blocks: 10.0.0.2, from 2.2.2.2, 00:00:53 ago, via GigabitEthernet1 Route metric is 11, traffic share count is 1 ! R1#sh ip cef 2.2.2.2/32 detail 2.2.2.2/32, epoch 2 nexthop 10.0.0.2 GigabitEthernet1 |
As you can see there is currently only 1 FIB entry for the destination prefix 2.2.2.2/32. The physical interfaces on R1 do have different cost values, thus there is no ECMP.
LFA FRR without path attributes
Configuration
| router ospf 1 fast-reroute per-prefix enable prefix-priority low |
Verification
| R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via “ospf 1”, distance 110, metric 11, type intra area Last update from 10.0.0.2 on GigabitEthernet1, 00:00:16 ago Routing Descriptor Blocks: 10.0.0.2, from 2.2.2.2, 00:00:16 ago, via GigabitEthernet1 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.14, via GigabitEthernet4 ! R1#sh ip cef 2.2.2.2/32 detail 2.2.2.2/32, epoch 2 nexthop 10.0.0.2 GigabitEthernet1 repair: attached-nexthop 10.0.0.14 GigabitEthernet4 nexthop 10.0.0.14 GigabitEthernet4, repair |
After applying the default LFA FRR configuration, a new repair-path has been added to the RIB and FIB. Which means that the router has chosen GigabitEthernet1 as the primary-path and will failover to GigabitEthernet1 in case of issue on the primary-path.
LFA FRR with SRLG path attribute
Configuration
| interface GigabitEthernet1 description to R2 srlg gid 1 ! interface GigabitEthernet4 description to R2 – Secondary Path srlg gid 1 ! router ospf 1 fast-reroute per-prefix enable prefix-priority low fast-reroute per-prefix tie-break srlg index 10 |
Verification
| R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via “ospf 1”, distance 110, metric 11, type intra area Last update from 10.0.0.2 on GigabitEthernet1, 00:00:13 ago Routing Descriptor Blocks: 10.0.0.2, from 2.2.2.2, 00:00:13 ago, via GigabitEthernet1 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.6, via GigabitEthernet2 ! R1#sh ip cef 2.2.2.2/32 detail 2.2.2.2/32, epoch 2 nexthop 10.0.0.2 GigabitEthernet1 repair: attached-nexthop 10.0.0.6 GigabitEthernet2 nexthop 10.0.0.6 GigabitEthernet2, repair |
Once we have enabled the SRLG path attribute, GigabitEthernet4 is no longer an acceptable repair-path as it is part of the same SRLG than the primary-path. Therefore GigabitEthernet2 is used as new repair-path.
LFA FRR with Node-Protecting path attribute
Configuration
| router ospf 1 fast-reroute per-prefix enable prefix-priority low fast-reroute per-prefix tie-break node-protecting index 10 |
Verification
| R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via “ospf 1”, distance 110, metric 11, type intra area Last update from 10.0.0.2 on GigabitEthernet1, 00:00:12 ago Routing Descriptor Blocks: 10.0.0.2, from 2.2.2.2, 00:00:12 ago, via GigabitEthernet1 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.6, via GigabitEthernet2 ! R1#sh ip cef 2.2.2.2/32 detail 2.2.2.2/32, epoch 2 nexthop 10.0.0.2 GigabitEthernet1 repair: attached-nexthop 10.0.0.6 GigabitEthernet2 nexthop 10.0.0.6 GigabitEthernet2, repair |
After enabling the node-protecting path attribute, we can see that the repair-path is not via GigabitEthernet4 as it was in the default configuration. GigabitEthernet4 and GigabitEthernet1 are both connected to the same node (R2) which we are protecting now. This is the reason why GigabitEthernet4 is no longer eligible as a repair-path and therefore GigabitEthernet2 is used as new repair-path.
PS: In this scenario we are protecting the destination node for simplicity. This makes not really sense in a production environment where we more often protect transit nodes.
LFA FRR with Metric path attribute
Configuration
| router ospf 1 fast-reroute per-prefix enable prefix-priority low fast-reroute per-prefix tie-break lowest-metric index 10 |
Verification
| R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via “ospf 1”, distance 110, metric 11, type intra area Last update from 10.0.0.2 on GigabitEthernet1, 00:01:21 ago Routing Descriptor Blocks: 10.0.0.2, from 2.2.2.2, 00:01:21 ago, via GigabitEthernet1 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.14, via GigabitEthernet4 ! R1#sh ip cef 2.2.2.2/32 detail 2.2.2.2/32, epoch 2 nexthop 10.0.0.2 GigabitEthernet1 repair: attached-nexthop 10.0.0.14 GigabitEthernet4 nexthop 10.0.0.14 GigabitEthernet4, repair |
By enabling the metric path attribute, interface GigabitEthernet4 is used as repair-path because it has the lowest cost (21) out of all candidate repair-paths.
LFA FRR with Secondary path attribute
Before enabling secondary-path, we have to change the cost of our interfaces so that we enable basic OSPF ECMP according to the following diagram:
Configuration
| interface GigabitEthernet1 ip ospf cost 10 ! interface GigabitEthernet4 ip ospf cost 10 |
Verification
| R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via “ospf 1”, distance 110, metric 11, type intra area Last update from 10.0.0.14 on GigabitEthernet4, 00:00:37 ago Routing Descriptor Blocks: 10.0.0.14, from 2.2.2.2, 00:00:37 ago, via GigabitEthernet4 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.2, via GigabitEthernet1 10.0.0.2, from 2.2.2.2, 00:19:43 ago, via GigabitEthernet1 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.14, via GigabitEthernet4 ! R1#sh ip cef 2.2.2.2/32 detail 2.2.2.2/32, epoch 2, per-destination sharing nexthop 10.0.0.2 GigabitEthernet1 repair: attached-nexthop 10.0.0.14 GigabitEthernet4 nexthop 10.0.0.14 GigabitEthernet4 repair: attached-nexthop 10.0.0.2 GigabitEthernet1 |
Now that we have default OSPF ECMP, we can see that we have two active entries in the RIB and FIB each with its dedicated repair-path. Let’s configure the secondary-path attribute to make sure that we don’t use a repair-path out of the ECMP set.
Configuration
| router ospf 1 fast-reroute per-prefix enable prefix-priority low fast-reroute per-prefix tie-break secondary-path index 10 |
Verification
| R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via “ospf 1”, distance 110, metric 11, type intra area Last update from 10.0.0.2 on GigabitEthernet1, 00:00:10 ago Routing Descriptor Blocks: 10.0.0.14, from 2.2.2.2, 00:00:10 ago, via GigabitEthernet4 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.6, via GigabitEthernet2 10.0.0.2, from 2.2.2.2, 00:00:10 ago, via GigabitEthernet1 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.6, via GigabitEthernet2 ! R1#sh ip cef 2.2.2.2/32 detail 2.2.2.2/32, epoch 2, per-destination sharing nexthop 10.0.0.2 GigabitEthernet1 repair: attached-nexthop 10.0.0.6 GigabitEthernet2 nexthop 10.0.0.14 GigabitEthernet4 repair: attached-nexthop 10.0.0.6 GigabitEthernet2 nexthop 10.0.0.6 GigabitEthernet2, repair |
After applying the secondary-path attribute, we see that both ECMP paths use GigabitEthernet2 as the repair-path. So now we are using a repair-path which is not part of the ECMP set.
LFA FRR with Primary path attribute
Configuration
| router ospf 1 fast-reroute per-prefix enable prefix-priority low fast-reroute per-prefix tie-break primary-path index 10 |
Verification
| R1#show ip route 2.2.2.2 Routing entry for 2.2.2.2/32 Known via “ospf 1”, distance 110, metric 11, type intra area Last update from 10.0.0.2 on GigabitEthernet1, 00:00:54 ago Routing Descriptor Blocks: 10.0.0.14, from 2.2.2.2, 00:00:54 ago, via GigabitEthernet4 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.2, via GigabitEthernet1 * 10.0.0.2, from 2.2.2.2, 00:00:54 ago, via GigabitEthernet1 Route metric is 11, traffic share count is 1 Repair Path: 10.0.0.14, via GigabitEthernet4 ! R1#sh ip cef 2.2.2.2/32 detail 2.2.2.2/32, epoch 2, per-destination sharing nexthop 10.0.0.2 GigabitEthernet1 repair: attached-nexthop 10.0.0.14 GigabitEthernet4 nexthop 10.0.0.14 GigabitEthernet4 repair: attached-nexthop 10.0.0.2 GigabitEthernet1 |
As expected, after applying the primary-path attribute, we are now again using the repair-path from the ECMP set.