We’ll use the topology from the Theory section for our lab. We will use ISIS for our IGP, as Nick Russo’s series uses OSPF, so if you read through both you will get some hands on experience with LFA using both IGPs.
All routers are XR for the simplicity of the config style. Here are the startup configs, which only enable the IGP/SR and LDP. LFA is not configured yet. The default LDP preference is kept.
#R1
hostname R1
int Gi0/0/0/0
ip address 10.1.2.1/24
no shut
int Gi0/0/0/1
ip address 10.1.3.1/24
no shut
int Lo0
ip address 1.1.1.1/32
!
router isis 1
net 49.0001.0000.0000.0001.00
is-type level-2-only
address-family ipv4 unicast
segment-routing mpls
metric-style wide
!
int Gi0/0/0/0
point-to-point
address-family ipv4 unicast
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
int Lo0
address-family ipv4 unicast
prefix-sid index 1
!
mpls ldp
int Gi0/0/0/0
int Gi0/0/0/1
#R2
hostname R2
int Gi0/0/0/0
ip address 10.1.2.2/24
no shut
int Gi0/0/0/1
ip address 10.2.4.2/24
no shut
int Lo0
ip address 2.2.2.2/32
!
router isis 1
net 49.0001.0000.0000.0002.00
is-type level-2-only
address-family ipv4 unicast
segment-routing mpls
metric-style wide
!
int Gi0/0/0/0
point-to-point
address-family ipv4 unicast
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
int Lo0
address-family ipv4 unicast
prefix-sid index 2
!
mpls ldp
int Gi0/0/0/0
int Gi0/0/0/1
#R3
hostname R3
int Gi0/0/0/0
ip address 10.1.3.3/24
no shut
int Gi0/0/0/1
ip address 10.3.5.3/24
no shut
int Lo0
ip address 3.3.3.3/32
!
router isis 1
net 49.0001.0000.0000.0003.00
is-type level-2-only
address-family ipv4 unicast
segment-routing mpls
metric-style wide
!
int Gi0/0/0/0
point-to-point
address-family ipv4 unicast
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
metric 20
int Lo0
address-family ipv4 unicast
prefix-sid index 3
!
mpls ldp
int Gi0/0/0/0
int Gi0/0/0/1
#R4
hostname R4
int Gi0/0/0/0
ip address 10.4.6.4/24
no shut
int Gi0/0/0/1
ip address 10.2.4.4/24
no shut
int Lo0
ip address 4.4.4.4/32
!
router isis 1
net 49.0001.0000.0000.0004.00
is-type level-2-only
address-family ipv4 unicast
segment-routing mpls
metric-style wide
!
int Gi0/0/0/0
point-to-point
address-family ipv4 unicast
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
int Lo0
address-family ipv4 unicast
prefix-sid index 4
!
mpls ldp
int Gi0/0/0/0
int Gi0/0/0/1
#R5
hostname R5
int Gi0/0/0/0
ip address 10.5.6.5/24
no shut
int Gi0/0/0/1
ip address 10.3.5.5/24
no shut
int Lo0
ip address 5.5.5.5/32
!
router isis 1
net 49.0001.0000.0000.0005.00
is-type level-2-only
address-family ipv4 unicast
segment-routing mpls
metric-style wide
!
int Gi0/0/0/0
point-to-point
address-family ipv4 unicast
metric 15
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
metric 20
int Lo0
address-family ipv4 unicast
prefix-sid index 5
!
mpls ldp
int Gi0/0/0/0
int Gi0/0/0/1
#R6
hostname R6
int Gi0/0/0/0
ip address 10.4.6.6/24
no shut
int Gi0/0/0/1
ip address 10.5.6.6/24
no shut
int Lo0
ip address 6.6.6.6/32
!
router isis 1
net 49.0001.0000.0000.0006.00
is-type level-2-only
address-family ipv4 unicast
segment-routing mpls
metric-style wide
!
int Gi0/0/0/0
point-to-point
address-family ipv4 unicast
int Gi0/0/0/1
point-to-point
address-family ipv4 unicast
metric 15
int Lo0
address-family ipv4 unicast
prefix-sid index 6
!
mpls ldp
int Gi0/0/0/0
int Gi0/0/0/1
LFA
Before we enable fast reroute, we can check that there are no backup prefixes calculated by the IGP or installed in the FIB.
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 15:21:27.957 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
No FRR backup
RP/0/0/CPU0:R1#show cef 6.6.6.6/32
Sun Aug 28 15:22:07.635 UTC
6.6.6.6/32, version 29, labeled SR, internal 0x1000001 0x81 (ptr 0xa12dbd34) [1], 0x0 (0xa12c189c), 0xa28 (0xa155b398)
Updated Aug 28 15:19:50.565
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, 19 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa166e224 0x0]
next hop 10.1.2.2/32
local adjacency
local label 24012 labels imposed {24011}
The FIB shows us that the LDP label will be imposed on IP traffic, as we are preferring LDP imposition by default. (sr-prefer is not configured).
Let’s enable LFA. For ISIS you must do this on a per-interface basis. In our lab we will only enable LFA on the PLR, R1, but in the real world you would probably enable this on all routers in the topology. We are only interested in protecting the R1-R2 link right now, which is Gi0/0/0/0 on R1.
Besides per-prefix you have the option for per-link. When using per-link, the router generates a single, shared backup path for all prefixes reachable through the link. When using per-prefix, you gain better backup paths, as they are calculated on a per-prefix basis. Multiple prefixes sharing the same primary link may have different best backup paths in reality.
The IGP shows us that a backup path as been calculated, which uses R3:
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 15:27:18.163 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: 55
The FIB shows us the label stack that will be imposed on the backup path. Since R3 has a shortest path to 6.6.6.6/32 that does not use the protected link, all R1 needs to do is send R3 the LDP label it advertised for 6.6.6.6/32.
RP/0/0/CPU0:R1#show cef 6.6.6.6/32
Sun Aug 28 15:28:49.187 UTC
6.6.6.6/32, version 37, labeled SR, internal 0x1000001 0x81 (ptr 0xa12dbd34) [1], 0x0 (0xa12c189c), 0xa28 (0xa16f412c)
Updated Aug 28 15:27:05.654
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, 13 dependencies, weight 0, class 0, protected [flags 0x400]
path-idx 0 bkup-idx 1 NHID 0x0 [0xa17d31fc 0x0]
next hop 10.1.2.2/32
local label 24012 labels imposed {24011}
via 10.1.3.3/32, GigabitEthernet0/0/0/1, 13 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}
RP/0/0/CPU0:R1#show mpls ldp bindings 6.6.6.6/32
Sun Aug 28 15:29:23.305 UTC
6.6.6.6/32, rev 24
Local binding: label: 24012
Remote bindings: (2 peers)
Peer Label
----------------- ---------
2.2.2.2:0 24011
3.3.3.3:0 24011
Remote LFA
If we increase the cost of the R3-R5 link to 25, then R3 is no longer an LFA for 6.6.6.6/32.
If we examine the IGP’s fast reroute calculations and the FIB, we can see that we no longer have a backup path for 6.6.6.6/32 on R1.
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 15:32:08.314 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
No FRR backup
RP/0/0/CPU0:R1#show cef 6.6.6.6/32
Sun Aug 28 15:32:19.693 UTC
6.6.6.6/32, version 43, labeled SR, internal 0x1000001 0x81 (ptr 0xa12dbd34) [1], 0x0 (0xa12c189c), 0xa28 (0xa155b2f8)
Updated Aug 28 15:31:34.897
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, 21 dependencies, weight 0, class 0 [flags 0x0]
path-idx 0 NHID 0x0 [0xa166e224 0x0]
next hop 10.1.2.2/32
local adjacency
local label 24012 labels imposed {24011}
LFA fails in this topology, but Remote LFA will succeed. This is because R5 is a PQ node. If we can tunnel traffic from R1 to R5, R5’s shortest path to R5 is naturally via its Gi0/0/0/0 link. It will not loop traffic back to R1.
The command remote-lfa tunnel mpls-ldp refers to the fact that we will tunnel traffic from R1 to the PQ node via LDP. Targeted LDP is needed to learn the PQ node’s label for the given destination.
Let’s look at the fast-reroute calculation again:
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 15:52:14.221 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
Remote FRR backup via R5 [5.5.5.5], via 10.1.3.3, GigabitEthernet0/0/0/1 R3, SRGB Base: 16000, Weight: 0, Metric: 35
Label stack [16005, 16006]
Do you notice anything strange about this output? The label stack is using SR labels, not LDP. But don’t we have LDP preference still enabled by default? Why is it using SR? This is because R1 cannot form a targeted LDP session with R5. Check the LDP neighbors on R1:
RP/0/0/CPU0:R1#show mpls ldp nei br
Sun Aug 28 15:52:25.920 UTC
Peer GR NSR Up Time Discovery Addresses Labels
ipv4 ipv6 ipv4 ipv6 ipv4 ipv6
----------------- -- --- ---------- ---------- ---------- ------------
2.2.2.2:0 N N 00:33:54 1 0 3 0 12 0
3.3.3.3:0 N N 00:33:49 1 0 3 0 12 0
The reason for this is that by default, a router will not accept and form a targeted LDP neighborship session. On R5 we must configure it to accept targeted LDP neighborships. This is the drawback of rLFA - you should configure this on all routers in the topology to allow any router to be the PQ node.
Our targeted LDP neighborship with R5 is now up on R1:
RP/0/0/CPU0:R1#show mpls ldp nei br
Sun Aug 28 15:55:52.186 UTC
Peer GR NSR Up Time Discovery Addresses Labels
ipv4 ipv6 ipv4 ipv6 ipv4 ipv6
----------------- -- --- ---------- ---------- ---------- ------------
2.2.2.2:0 N N 00:37:20 1 0 3 0 12 0
3.3.3.3:0 N N 00:37:15 1 0 3 0 12 0
5.5.5.5:0 N N 00:00:03 1 0 3 0 12 0
In my lab the FRR path is still using SR. I have to disable SR on the IGP in order to see the LDP backup path.
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 15:58:11.146 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
Remote FRR backup via R5 [5.5.5.5], via 10.1.3.3, GigabitEthernet0/0/0/1 R3, SRGB Base: 16000, Weight: 0, Metric: 35
We can see the label stack imposed on the backup path:
RP/0/0/CPU0:R1#show cef 6.6.6.6/32
Sun Aug 28 15:58:50.034 UTC
6.6.6.6/32, version 107, internal 0x1000001 0x0 (ptr 0xa12dbdbc) [1], 0x0 (0xa12c19bc), 0xa28 (0xa1742260)
Updated Aug 28 15:58:06.028
local adjacency 10.1.2.2
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 10.1.2.2/32, GigabitEthernet0/0/0/0, 9 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, 9 dependencies, weight 0, class 0, backup [flags 0x300]
path-idx 1 NHID 0x0 [0xa166e338 0x0]
next hop 10.1.3.3/32
local adjacency
local label 24012 labels imposed {24009 24009}
Both labels are the same purely out of coincidence. The first label is R3’s advertised label for R5:
RP/0/0/CPU0:R1#show mpls ldp bindings 5.5.5.5/32
Sun Aug 28 15:59:39.850 UTC
5.5.5.5/32, rev 23
Local binding: label: 24011
Remote bindings: (3 peers)
Peer Label
----------------- ---------
2.2.2.2:0 24012
3.3.3.3:0 24009
5.5.5.5:0 ImpNull
The bottom 24009 label is R5’s advertised label for 6.6.6.6/32:
RP/0/0/CPU0:R1#show mpls ldp bindings 6.6.6.6/32
Sun Aug 28 16:00:06.399 UTC
6.6.6.6/32, rev 24
Local binding: label: 24012
Remote bindings: (3 peers)
Peer Label
----------------- ---------
2.2.2.2:0 24011
3.3.3.3:0 24011
5.5.5.5:0 24009
TI-LFA
If we increase the cost of the R5-R6 link to 100, R5 is no longer a PQ node, as its best path to R6 uses the R1-R2 link.
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 16:03:05.626 UTC
L2 6.6.6.6/32 [40/115]
via 10.1.2.2, GigabitEthernet0/0/0/0, R2, SRGB Base: 16000, Weight: 0
No FRR backup
Remember that LFA and rLFA are topology dependent. Depending on the IGP topology, there may not be a fast-reroute path that is gauranteed to be loop free.
The only way to achieve fast-reroute in this scenarion is to enable TI-LFA. I’ll re-enable SR, remove rLFA, and add TI-LFA. To configure TI-LFA for ISIS, you must enable it on a per-interface basis. With OSPF, you can enable it per-interface, per-area or per-instance. Note that to use TI-LFA you must have two fast-reroute commands - fast-reroute per-prefix and fast-reroute per-prefix ti-lfa.
router isis 1
address-family ipv4 unicast
segment-routing mpls
int lo0
address-family ipv4 unicast
prefix-sid index 1
int Gi0/0/0/0
address-family ipv4 unicast
no fast-reroute per-prefix remote-lfa
fast-reroute per-prefix ti-lfa
fast-reroute per-prefix
As a challenge, before we examine the backup path, what will the label stack look like?
The answer is that R1 will impose two labels: the top label is the label for R5’s prefix-SID, and the send label is the label for R5’s Gi0/0/0/0 link, which is represented by its adjacency-SID.
As a second challenge, try to determine these label values using the LSP database. The prefix-SID should be quite easy to determine, but the adjacency-SID will take a little extra work.
If you need help, check R5’s R5.00-00 LSP:
RP/0/0/CPU0:R1#show isis data R5.00-00 verbose
Sun Aug 28 16:07:56.746 UTC
IS-IS 1 (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R5.00-00 0x0000000c 0x4975 894 0/0/0
Area Address: 49.0001
NLPID: 0xcc
IP Address: 5.5.5.5
Metric: 10 IP-Extended 5.5.5.5/32
Prefix-SID Index: 5, Algorithm:0, R:0 N:1 P:0 E:0 V:0 L:0
Prefix Attribute Flags: X:0 R:0 N:1
Metric: 25 IP-Extended 10.3.5.0/24
Prefix Attribute Flags: X:0 R:0 N:0
Metric: 100 IP-Extended 10.5.6.0/24
Prefix Attribute Flags: X:0 R:0 N:0
Hostname: R5
Router Cap: 5.5.5.5, D:0, S:0
Segment Routing: I:1 V:0, SRGB Base: 16000 Range: 8000
SR Algorithm:
Algorithm: 0
Algorithm: 1
Node Maximum SID Depth:
Subtype: 1, Value: 10
Metric: 25 IS-Extended R3.00
Interface IP Address: 10.3.5.5
Neighbor IP Address: 10.3.5.3
Link Maximum SID Depth:
Subtype: 1, Value: 10
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24001
Metric: 100 IS-Extended R6.00
Interface IP Address: 10.5.6.5
Neighbor IP Address: 10.5.6.6
Link Maximum SID Depth:
Subtype: 1, Value: 10
ADJ-SID: F:0 B:0 V:1 L:1 S:0 P:0 weight:0 Adjacency-sid:24003
Now check the IGP’s fast-reroute calculation and the FIB entry for 6.6.6.6/32:
RP/0/0/CPU0:R1#show isis fast-reroute 6.6.6.6/32
Sun Aug 28 16:08:48.463 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 (link), 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
R5 is the P node, and R6, the destination itself, is the Q node. Remember that in this topology, there is no PQ node found. Only R6 has a shortest path to its own loopback which doesn’t use the protected link.
RP/0/0/CPU0:R1#show cef 6.6.6.6/32
Sun Aug 28 16:10:39.015 UTC
6.6.6.6/32, version 134, labeled SR, internal 0x1000001 0x85 (ptr 0xa12dbdbc) [1], 0x0 (0xa12c19bc), 0xa28 (0xa17421dc)
Updated Jul 1 10:40:32.335
local adjacency 10.1.2.2
Prefix Len 32, traffic index 0, precedence n/a, priority 15
via 10.1.2.2/32, GigabitEthernet0/0/0/0, 12 dependencies, weight 0, class 0, protect-ignore [flags 0x40400]
path-idx 0 bkup-idx 1 NHID 0x0 [0xa166e224 0x0]
next hop 10.1.2.2/32
local adjacency
local label 24012 labels imposed {24011}
via 10.1.3.3/32, GigabitEthernet0/0/0/1, 23 dependencies, weight 0, class 0, backup [flags 0x300]
path-idx 1 NHID 0x0 [0xa166e338 0x0]
next hop 10.1.3.3/32
local adjacency
local label 24012 labels imposed {24009 24003}
Notice that the backup path as seen in the FIB has a different label stack imposed than what we saw calculated by the IGP. It uses the LDP label instead of SR label. This is because LDP preference is used by default. R1 was able to use an LDP label for 5.5.5.5/32 that R3 advertised, which is 24009. 24003 looks like it could be an LDP label, but it is actually the dynamically-allocated adajcency-SID which we saw in the IGP output earlier. You can confirm this again by checking R5’s LFIB for 24003:
RP/0/0/CPU0:R5#show mpls forwarding labels 24003
Sun Aug 28 16:13:32.885 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24003 Pop SR Adj (idx 3) Gi0/0/0/0 10.5.6.6 0
Conclusion
In this article we briefly explored how to configure and verify LFA/rLFA/TI-LFA. We also saw the short comings of LFA and rLFA, and how TI-LFA provides 100% converage no matter what the topology looks like. TI-LFA can do this thanks to adjacency-SIDs which bypass the IGP bestpath forwarding decision.
In the next article we will explore additional protection options using TI-LFA: node protection and SRLG protection.
