TI-LFA Pt. 2 (Implementation)
Lab
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.
LFA
Before we enable fast reroute, we can check that there are no backup prefixes calculated by the IGP or installed in the FIB.
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:
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.
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.
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.
Let’s configure rLFA on 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:
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:
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:
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.
We can see the label stack imposed on the backup path:
Both labels are the same purely out of coincidence. The first label is R3’s advertised label for R5:
The bottom 24009 label is R5’s advertised label for 6.6.6.6/32:
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.
R1 no longer has a backup path to 6.6.6.6/32:
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.
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:
Now check the IGP’s fast-reroute calculation and the FIB entry for 6.6.6.6/32:
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.
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:
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.
Last updated