By default, TI-LFA implements only link protection for the backup/repair path. The repair path is calculated by finding the best path with the protected link removed from the topology. However there are two other protection option you can use: node protection and SRLG protection.
Node protection means that the next-hop node is pruned from the topology when the backup path is calculated. SRLG protection means that all local links that are part of the same SRLG group as the primary link, are pruned from the topology when the backup path is calculated.
If you are not familiar with SRLG (Shared Risk Link Group), it is used to indicate that two or more links share the same fate. For example, two links may run inside the same conduit, so if a backhoe takes one link out, it is highly likely the other link is cut as well. When you use SRLG protection, you are telling the router that other links may very well be down when the primary link goes down, so use other links that are not in the same SRLG as the primary link. Note that only locally configured interfaces are considered when TI-LFA finds SRLG-disjoint paths. The local node will not run CSPF with other router’s links pruned which share the same SRLG.
Whether node, link, or SRLG protection is used, the link failure event is always what triggers the backup path. The router does not actually know whether the node on the other end went down or just the link went down, so when using node or SRLG protection you may get a backup path that differs from the post-convergence path. If the node does not go down, but you are avoiding it in your backup path, you might re-converge on a different path compared to the backup path. This is usually not really an issue, it just means that the backup path did not take the most optimal path.
To configure TI-LFA for node or SRLG protection, you use tiebreakers. In regular LFA, tiebreakers are used to select a single LFA among multiple LFA candidates. However with TI-LFA, the tiebreaker is used to specify the protection mode (link, node or SRLG) and the order in which to prefer the protection modes. You can configure node or srlg protection modes. Both of these also must be link-protecting by definition, as you cannot find a node or srlg protecting path that does not also protect the link.
If you configure both node and SRLG protection, the router will attempt to find a backup path in the following order:
A path that is both node and SRLG protecting
A path that is only node or only SRLG protecting path (the mode with highest preference)
A path that is only node or only SRLG protecting path (the mode with lowest preference)
A path that is only link protecting
Here is an example in ISIS with both node protection and SRLG protection configured. Node protection is given priority. First the router will try to find a path that is node and SRLG protecting, then node protecting only, then SRLG protecting only, then fall back to link protecting.
router isis 1
int gi0/0/0/0
address-family ipv4 unicast
fast-reroute per-prefix tiebreaker node-protecting index 20
fast-reroute per-prefix tiebreaker srlg-disjoint index 10
The higher index number is more preferred. You can confirm the TI-LFA tie breakers using the following show command:
RP/0/0/CPU0:R1#show isis interface gi0/0/0/0 | begin FRR
Sun Aug 28 20:50:04.897 UTC
FRR (L1/L2): L1 Enabled L2 Enabled
FRR Type: per-prefix per-prefix
Direct LFA: Enabled Enabled
Remoter LFA: Not Enabled Not Enabled
Tie Breaker Default Default
Line-card disjoint 30 30
Lowest backup metric 20 20
Node protecting 40 40
Primary path 10 10
TI LFA: Enabled Enabled
Tie Breaker Default Default
Link Protecting Enabled Enabled
Node protecting 20 20
SRLG disjoint 10 10
As a comparison, Gi0/0/0/1 has TI-LFA enabled but no tiebreakers are configured. The default link protecting mode is enabled, and node and SRLG modes have an index of 0.
RP/0/0/CPU0:R1#show isis interface gi0/0/0/1 | begin FRR
Sun Aug 28 20:50:36.475 UTC
FRR (L1/L2): L1 Enabled L2 Enabled
FRR Type: per-prefix per-prefix
Direct LFA: Enabled Enabled
Remoter LFA: Not Enabled Not Enabled
Tie Breaker Default Default
Line-card disjoint 30 30
Lowest backup metric 20 20
Node protecting 40 40
Primary path 10 10
TI LFA: Enabled Enabled
Tie Breaker Default Default
Link Protecting Enabled Enabled
Node protecting 0 0
SRLG disjoint 0 0
The configuration for OSPF is similar but you can configure this at the instance level:
router ospf 1
segment-routing mpls
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa enable
fast-reroute per-prefix tiebreaker node-protecting index 200
fast-reroute per-prefix tiebreaker srlg-disjoint index 100
area 0
int Gi0/0/0/0
network point-to-point
int Gi0/0/0/1
network point-to-point
int Lo0
prefix-sid index 1
I use index values of 200 and 100 to differentiate from other tiebreakers which have indexes of 20 and 10 by default.
RP/0/0/CPU0:R1#show ospf int Gi0/0/0/0 | be tiebreaker
Sun Aug 28 20:54:41.698 UTC
IPFRR per-prefix tiebreakers:
Name Index
No Tunnel (Implicit) 257
Node Protection 200
SRLG Disjoint 100
Lowest Metric 20
Primary Path 10
Downstream 0
Line-card Disjoint 0
Secondary Path 0
Post Convergence Path 256
Topology Independent LFA enabled
Lab
We’ll re-use our topology from the previous section, and add a link between R2-R3:
R1 still has the same IGP configuration, with the default TI-LFA link protection mode.
RP/0/0/CPU0:R1#show run router isis
Sun Aug 28 21:09:47.826 UTC
router isis 1
is-type level-2-only
net 49.0001.0000.0000.0001.00
address-family ipv4 unicast
metric-style wide
segment-routing mpls
!
interface Loopback0
address-family ipv4 unicast
prefix-sid index 1
!
!
interface GigabitEthernet0/0/0/0
point-to-point
address-family ipv4 unicast
fast-reroute per-prefix
fast-reroute per-prefix ti-lfa
!
!
interface GigabitEthernet0/0/0/1
point-to-point
address-family ipv4 unicast
!
!
!
Configure the new R2-R3 link:
#R2
int gi0/0/0/2
ip address 10.2.3.2/24
no shut
!
router isis 1
int gi0/0/0/2
point-to-point
address-family ipv4 unicast
#R3
int gi0/0/0/2
ip address 10.2.3.3/24
no shut
!
router isis 1
int gi0/0/0/2
point-to-point
address-family ipv4 unicast
Now R3’s shortest path to 6.6.6.6/32 is via R2:
RP/0/0/CPU0:R3#show route 6.6.6.6/32
Sun Aug 28 21:12:55.332 UTC
Routing entry for 6.6.6.6/32
Known via "isis 1", distance 115, metric 40, labeled SR, type level-2
Installed Aug 28 21:12:08.515 for 00:00:46
Routing Descriptor Blocks
10.2.3.2, from 6.6.6.6, via GigabitEthernet0/0/0/2
Route metric is 40
No advertising protos.
R1’s backup path for 6.6.6.6/32 is simply to send the traffic to R3:
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 21:12:22.665 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
FRR backup via 10.1.3.3, GigabitEthernet0/0/0/1, R3, SRGB Base: 16000, Weight: 0, Metric: 50
RP/0/0/CPU0:R1#show cef 6.6.6.6/32
Sun Aug 28 21:13:26.551 UTC
6.6.6.6/32, version 178, labeled SR, internal 0x1000001 0x81 (ptr 0xa12dbdbc) [1], 0x0 (0xa12c19bc), 0xa28 (0xa1742444)
Updated Aug 28 21:12:07.437
local adjacency 10.1.2.2
Prefix Len 32, traffic index 0, precedence n/a, priority 3
Extensions: context-label:16006
via 10.1.2.2/32, GigabitEthernet0/0/0/0, 24 dependencies, weight 0, class 0, protected [flags 0x400]
path-idx 0 bkup-idx 1 NHID 0x0 [0xa179f0e4 0x0]
next hop 10.1.2.2/32
local label 24012 labels imposed {24011}
via 10.1.3.3/32, GigabitEthernet0/0/0/1, 24 dependencies, weight 0, class 0, backup (Local-LFA) [flags 0x300]
path-idx 1 NHID 0x0 [0xa166e338 0x0]
next hop 10.1.3.3/32
local adjacency
local label 24012 labels imposed {24011}
Coincidentally, both R2 and R3 have allocated the same label, 24011, for 6.6.6.6/32
Current backup path
Node Protection
Now let’s configure TI-LFA for node protection. This means that the IGP should remove node R2 completely from the topology when calculating the repair path in order to avoid it, as we are protecting traffic in the event that R2 crashes completely. In MPLS-TE we specified a TE tunnel with a strict path that would exclude 2.2.2.2. With TI-LFA we can simply turn on node protection.
#R1
router isis 1
int gi0/0/0/0
address-family ipv4 unicast
fast-reroute per-prefix tiebreaker node-protecting index 100
The repair path is now back to what we saw before adding the R2-R3 link (R1-R3-R5-R6).
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 21:17:21.885 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (node), via 10.1.3.3, GigabitEthernet0/0/0/1 R3, SRGB Base: 16000, Weight: 0
P node: R5.00 [5.5.5.5], Label: 16005
Q node: R6.00 [6.6.6.6], Label: 24003
Prefix label: ImpNull
Backup-src: R6.00
SRLG Protection
Let’s add a second link to R1-R2. Instead of configuring an LACP bundle, we will use this link as a backup interface with a metric of 15.
Let’s configure the interfaces and also remove node-protection for TI-LFA.
#R1
int gi0/0/0/2
ip address 10.1.12.1/24
no shut
!
router isis 1
int gi0/0/0/2
point-to-point
address-family ipv4 unicast
metric 15
!
int Gi0/0/0/0
address-family ipv4 unicast
no fast-reroute per-prefix tiebreaker node-protecting
#R2
int gi0/0/0/3
ip address 10.1.12.2/24
no shut
!
router isis 1
int gi0/0/0/3
point-to-point
address-family ipv4 unicast
metric 15
R1 will now select Gi0/0/0/2 as the backup path, as this is the post-convergence path if link Gi0/0/0/0 fails:
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 21:49:26.693 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
FRR backup via 10.1.12.2, GigabitEthernet0/0/0/2, R2, SRGB Base: 16000, Weight: 0, Metric: 45
Let’s imagine that the fiber for these two links shares the same conduit. We are concerned that if Gi0/0/0/0 goes down, Gi0/0/0/2 may also go down. We’ll configure both of these interfaces as part of the same SRLG and configure TI-LFA to select a SRLG-disjoint backup path if it is available. To do this, the IGP will remove all local links belonging to the same SRLG as Gi0/0/0/0 from the topology, and then run SPF to determine the backup path.
#R1
srlg
group CONDUIT_A 1 value 1
!
int Gi0/0/0/0
group 1 CONDUIT_A
int Gi0/0/0/2
group 1 CONDUIT_A
!
router isis 1
int gi0/0/0/0
address-family ipv4 unicast
fast-reroute per-prefix tiebreaker srlg-disjoint index 200
Can you predict the backup path? Spend a few minutes thinking it through and then scroll down to check your answer.
The backup path is the following:
This is because TI-LFA is only attempting to find an SRLG disjoint backup path, not an SRLG disjoint plus node protecting path.
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 21:54:02.104 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (srlg), via 10.1.3.3, GigabitEthernet0/0/0/1 R3, SRGB Base: 16000, Weight: 0
Prefix label: 16006, Strict-SPF label: None
Backup-src: R6.00
Node and SRLG Protection
If we want node protection as well as SRLG-disjoint, we can configure both and the router will first prefer a backup path that is both SRLG-disjoint and node protecting. Let’s set node protection as index 150.
#R1
router isis 1
int Gi0/0/0/0
address-family ipv4 unicast
fast-reroute per-prefix tiebreaker node-protecting index 150
commit
end
!
RP/0/0/CPU0:R1#show run router isis 1 int gi0/0/0/0
Sun Aug 28 21:57:55.268 UTC
router isis 1
interface GigabitEthernet0/0/0/0
point-to-point
address-family ipv4 unicast
fast-reroute per-prefix
fast-reroute per-prefix tiebreaker node-protecting index 150
fast-reroute per-prefix tiebreaker srlg-disjoint index 200
fast-reroute per-prefix ti-lfa
!
!
The backup path is now both SRLG disjoint and node protecting!
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 21:58:06.487 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
Backup path: TI-LFA (node+srlg), via 10.1.3.3, GigabitEthernet0/0/0/1 R3, SRGB Base: 16000, Weight: 0
P node: R5.00 [5.5.5.5], Label: 16005
Q node: R6.00 [6.6.6.6], Label: 24003
Prefix label: ImpNull
Backup-src: R6.00
Conclusion
In this series, we’ve explored the theory behind the IPFRR technologies - LFA, rLFA and TI-LFA. We’ve seen the benefits that TI-LFA and had some practice implementing all IP FRR flavors.
I hope this series has been helpful. I highly suggest working through Nick Russo’s blog posts if you haven’t already. You will likely gain even more insight from his reading and also some practice using IP FRR with OSPF.
