RLFA Tiebreakers?
Last updated
Last updated
Load basic.isis.ldp.enabled.cfg
Configure the R3-R4 link to have a metric of 5.
The operator wants to protect prefix 9.9.9.1/32 on R1 without turning on SR. They wish to provide node protection so that the path takes R1-R4-R5-R9.
First let’s enable LFA:
R1’s LFA is R4. However, R1 has no control over how R4 will route to 9.9.9.1/32. R4 will simply use its best path via R3, which does not provide node protection. Notice that the NP flag is not set.
You may think, what if we enable RLFA? R1 should be able to calculate that using R5 as the PQ node would provide node protection if we forward the packets via R4. Let’s try it out.
R1 is still simply using the LFA via R4:
Filfil’s SR book states that RLFA cannot use node or SRLG protection, and this appears to prove it. Only simple link protection can be provided by RLFA. What we are trying to do is really a task for TI-LFA: we are trying to steer a backup path along an explicit node-protecting path.
RLFA is also not very scalable. It does not use the post-convergence path (so high metric links might be overutilized momentarily, resulting in packet loss), and it requires targetted LDP sessions. It also does not provide 100% coverage.
LFA, while providing good coverage in most topologies, and also providing for basic tiebreakers, does not strictly follow the post-convergence path, nor can you steer traffic along more complex backup paths.
We will see that TI-LFA solves all of these issues.
