Loop-Free Alternate Routes

Whilst at Cisco Live recently I was intrigued to learn about an apparently simple yet effective fast routing convergence technique called Loop-Free Alternate Fast ReRoute (LFA-FRR), a.k.a. IP Fast ReRoute (IP-FRR).

Many service providers and enterprises these days tune their interior gateway protocol (IGP) timers, aiming to achieve sub-200ms convergence. This can be quite an intensive and design impacting challenge.

LFA-FRR claims to be able to automatically provide local sub-50ms convergence times and complement any other fast convergence tuning techniques that have been employed. Some literature even claims it to achieve sub-25ms convergence.

It works with link-state routing protocols, ie. OSPF and IS-IS. It can be configured on a single router and works by calculating one loop-free alternate backup path for every prefix. It then installs this path into the Routing Information Base (RIB) to provide local restoration in the event of a failure in the primary path. As it is prefix-independent, the convergence time is deterministic and doesn’t vary according to parameters such as the size of the routing table or link-state database.

The diagram below shows a small network with LFA-FRR configured on Router B. Router B is using its primary path to reach the destination prefix via Router D, but has also calculated a loop-free alternate path via Router C which it has pre-installed into its RIB.

There is now a link failure between Routers B and D. As soon as Router B detects the failure, which could be due to loss of carrier or a keepalive mechanism such as Bi-directional Forwarding Detection (BFD), Router B begins using its loop-free alternate path via Router C to quickly restore traffic flow. If Router D is also configured for LFA-FRR, it will do likewise to restore traffic flow in the reverse direction.

For those of you familiar with EIGRP, you’ve probably already spotted that this is the same principle as Successors and Feasible Successors. Feasible Successors are loop-free alternates to the primary path which is the Successor. EIGRP also uses this technique to perform unequal cost load balancing by sending a percentage of the traffic to the Feasible Successor, so I wonder whether this could potentially be a future enhancement to LFA-FRR.

However, neither EIGRP nor LFA-FRR can always provide a loop-free alternate path; it depends on the network topology and metrics. Indications are that LFA-FRR may be able to provide protection of 70-85% of prefixes at the edge of a typical network.

In summary, LFA-FRR is easily configured on a router by a single command, calculates everything automatically, complements other fast routing convergence techniques, works on 70-85% of prefixes and doesn’t break anything, so why wouldn’t you want to use it?

Well, firstly it’s only currently available in IOS-XR, so it will be predominantly service providers using it for the time being. Due to the larger routing tables the routers may require more memory. There will also be some additional load on the router CPU, but this should be minimal as the LFA paths are calculated after the primary path.

In general, this technique appears to have good merit and be one for both service providers and enterprises to keep an eye on. However, it should be considered a ‘bonus’, as it is not a replacement for proper design and tuning to achieve fast routing convergence.