EIGRP Loop-Free Alternate (LFA) Fast Reroute (FRR)

EIGRP Loop-Free Alternate (LFA) Fast Reroute (FRR) is a feature that allows EIGRP to switch to a backup path in less than 50 ms. Fast reroute means we switch to another next hop, Loop-free alternate is an alternative path in the network that is loop free.

Now you might be thinking that this sounds familiar. After all, EIGRP has feasible successors. Those are loop-free alternate paths that EIGRP has calculated. If the successor fails, EIGRP can use a feasible successor right away.

This is true, but there’s one big “gotcha”. EIGRP feasible successors are not installed in the routing table right away. Only the successor route is installed. When the successor fails, EIGRP installs the feasible successor, and this takes time. Fast reroute installs both the successor route and the feasible successor route in the routing table which makes convergence even faster.

IGPs can calculate LFAs using different methods:

  • Per-link: all prefixes that are reachable through a certain link share the same information, they all use the same next hop address. When we calculate the LFA per link, we calculate a single backup next hop address for all prefixes that use the link. This means that if the primary link fails, all prefixes are switched to a secondary link. The advantage of per-link LFAs is that it’s simple to calculate, it uses less CPU and memory resources. The disadvantage, however, is that once the primary link fails, all traffic to the prefixes that used the primary link are suddenly switched to a single backup link. It is possible that your backup link gets overburdened with this sudden spike of traffic.
  • Per-prefix: we calculate an LFA for each prefix, in other words for each possible destination. This requires more resources, but it does offer better load balancing. It’s possible that two prefixes currently use the same path, but once the primary link fails, they use different backup next hops. This spreads your traffic more throughout the network.

When you have multiple possible LFAs, fast reroute has to select one LFA. EIGRP will not just select the “best” (lowest metric) feasible successor but uses some “tie-breakers” to select the best LFA. When you use per-prefix LFA, we have these four attributes:

  • Interface disjoint: don’t select an LFA that uses the same outgoing interface as the primary path. Imagine we have R1, connected to R2 and R3 on a multi-access segment. R1 also has a connection to R4 using a different interface. R2, R3, and R4 all offer a path to a certain destination. R2 is the successor, R3 and R4 are feasible successors. R3 has a better metric. Which feasible successor would you prefer? R1 can reach R2 and R3 using the same interface, R4 through a different interface. There is a risk that once R2 is unreachable that R3 also becomes unreachable (maybe the switch fails). It might be a better idea to prefer R4 instead…I’m going to show you this in an example, later in this lesson.
  • Line card disjoint: don’t select an LFA that shares a line card with the primary card. The same logic as the interface-disjoint applies here. There is a risk that your line card fails which means that both the successor and feasible successor are unusable.
  • Lowest repair path metric: don’t select an LFA with a high metric. This ensures that only the lowest metric LFAs remain.
  • Shared Risk Link Group (SRLG): don’t select LFAs that use the same SRLG. This one requires some more explanation. Imagine we have R1, connected to R2, R3, and R4. R2 and R3 use the same uplink to reach a certain destination. R4 uses a different link to reach the same destination. R2 is the successor, R3 and R4 are feasible successors, but R3 has a better metric. Which feasible successor would you prefer? R3 has a lower metric, but it uses the same uplink…that’s a risk. By adding R2 and R3 to the same SRLG, you can tell EIGRP to prefer R4 since it uses a different uplink. I will show you an example of SRLG on some routers later in this lesson.

You now know the basics of Fast reroute and Loop free alternate. Let’s look at it in action, shall we…

Configuration

Here is the first topology I use to demonstrate the basics of fast reroute:

EIGRP Fast Reroute Topology

These four routers run EIGRP; there’s a loopback on R4 with network 4.4.4.4/32. R1 can go through R2 or R3 to get there. The delay on R1’s GigabitEthernet3 interface has been increased so that R2 is our successor and R3 our feasible successor.



Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

R1

hostname R1
!
interface GigabitEthernet2
 ip address 192.168.12.1 255.255.255.0
 negotiation auto
!
interface GigabitEthernet3
 ip address 192.168.13.1 255.255.255.0
 delay 2
 negotiation auto
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
  exit-af-topology
  network 192.168.12.0
  network 192.168.13.0
 exit-address-family
!
end

R2

hostname R2
!
interface GigabitEthernet2
 ip address 192.168.12.2 255.255.255.0
 negotiation auto
!
interface GigabitEthernet3
 ip address 192.168.24.2 255.255.255.0
 negotiation auto
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
  exit-af-topology
  network 192.168.12.0
  network 192.168.24.0
 exit-address-family
!
end

R3

hostname R3
!
interface GigabitEthernet2
 ip address 192.168.34.3 255.255.255.0
 negotiation auto
!
interface GigabitEthernet3
 ip address 192.168.13.3 255.255.255.0
 negotiation auto
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
  exit-af-topology
  network 192.168.13.0
  network 192.168.34.0
 exit-address-family
!
end

R4

hostname R4
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
!
interface GigabitEthernet2
 ip address 192.168.34.4 255.255.255.0
 negotiation auto
!
interface GigabitEthernet3
 ip address 192.168.24.4 255.255.255.0
 negotiation auto
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
  exit-af-topology
  network 4.4.4.4 0.0.0.0
  network 192.168.24.0
  network 192.168.34.0
 exit-address-family
!
end

Let’s take a look at the EIGRP topology table of R1:

R1#show ip eigrp topology 4.4.4.4/32
EIGRP-IPv4 VR(FRR) Topology Entry for AS(1)/ID(192.168.12.1) for 4.4.4.4/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2048000, RIB is 16000
  Descriptor Blocks:
  192.168.12.2 (GigabitEthernet2), from 192.168.12.2, Send flag is 0x0
      Composite metric is (2048000/1392640), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 21250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 4.4.4.4
  192.168.13.3 (GigabitEthernet3), from 192.168.13.3, Send flag is 0x0
      Composite metric is (2703360/1392640), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 31250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 4.4.4.4

The output above confirms that R2 is our successor and R3 our feasible successor. Let’s take a look at the routing table:

R1#show ip route 4.4.4.4   
Routing entry for 4.4.4.4/32
  Known via "eigrp 1", distance 90, metric 16000, type internal
  Redistributing via eigrp 1
  Last update from 192.168.12.2 on GigabitEthernet2, 00:07:45 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 192.168.12.2, 00:07:45 ago, via GigabitEthernet2
      Route metric is 16000, traffic share count is 1
      Total delay is 21 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

As expected, we only see the successor route in the routing table. Let’s look at the CEF table:

R1#show ip cef 4.4.4.4
4.4.4.4/32
  nexthop 192.168.12.2 GigabitEthernet2

We only see the successor there as well. Now let’s configure fast reroute on R1. I’m using CSR1000v routers that support per-prefix LFA:

R1(config)#router eigrp FRR
R1(config-router)#address-family ipv4 unicast autonomous-system 1
R1(config-router-af)#topology base 
R1(config-router-af-topology)#fast-reroute per-prefix all

Let’s take another look at the routing table:

R1#show ip route 4.4.4.4
Routing entry for 4.4.4.4/32
  Known via "eigrp 1", distance 90, metric 16000, type internal
  Redistributing via eigrp 1
  Last update from 192.168.12.2 on GigabitEthernet2, 00:01:11 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 192.168.12.2, 00:01:11 ago, via GigabitEthernet2
      Route metric is 16000, traffic share count is 1
      Total delay is 21 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 0
      Repair Path: 192.168.13.3, via GigabitEthernet3

The output above is interesting. We still see the successor route, but at the bottom, you can see the repair path…that’s our feasible successor. We can also find this in the CEF table:

R1#show ip cef 4.4.4.4
4.4.4.4/32
  nexthop 192.168.12.2 GigabitEthernet2
    repair: attached-nexthop 192.168.13.3 GigabitEthernet3

The feasible successor is already in the forwarding table, saving valuable time when the successor route fails.

Tie Breakers

Let’s also take a look at some examples to help you understand the tie breakers. In the previous example, we only had one feasible successor, so there’s not much to choose. What if we have two or more feasible successors?

Interface Disjoint

Let’s take a closer look at the interface disjoint tie breaker. I use the following topology to demonstrate this:

eigrp fast reroute interface disjoint topology

Above we have five routers, running EIGRP. Behind R5 we have a loopback interface with network 5.5.5.5/32. R1 can use R2, R3, and R4 to reach it. I used an offset-list on R3 and R4 so that R2 is the successor, R3 and R4 two feasible successors where R3 has a slightly better metric.

Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

R1

hostname R1
!
interface GigabitEthernet2
 ip address 192.168.123.1 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.14.1 255.255.255.0
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
   fast-reroute per-prefix all
  exit-af-topology
  network 192.168.14.0
  network 192.168.123.0
 exit-address-family
!
end

R2

hostname R2
!
interface GigabitEthernet2
 ip address 192.168.123.2 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.25.2 255.255.255.0
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
  exit-af-topology
  network 192.168.25.0
  network 192.168.123.0
 exit-address-family
!
end

R3

hostname R3
!
interface GigabitEthernet2
 ip address 192.168.123.3 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.35.3 255.255.255.0
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
   offset-list 0 out 1000 GigabitEthernet2 
  exit-af-topology
  network 192.168.35.0
  network 192.168.123.0
 exit-address-family
!
end

R4

hostname R4
!
interface GigabitEthernet2
 ip address 192.168.14.4 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.45.4 255.255.255.0
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
   offset-list 0 out 2000 GigabitEthernet2 
  exit-af-topology
  network 192.168.14.0
  network 192.168.45.0
 exit-address-family
!
end

R5

hostname R5
!
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
!
interface GigabitEthernet2
 ip address 192.168.25.5 255.255.255.0
!
interface GigabitEthernet3
 ip address 192.168.35.5 255.255.255.0
!
interface GigabitEthernet4
 ip address 192.168.45.5 255.255.255.0
!
router eigrp FRR
 !
 address-family ipv4 unicast autonomous-system 1
  !
  topology base
  exit-af-topology
  network 5.5.5.5 0.0.0.0
  network 192.168.25.0
  network 192.168.35.0
  network 192.168.45.0
 exit-address-family
!
end

Let’s take a look at the routing table of R1:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 799 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

582 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hi Rene

    Got a couple of questions - firstly after a while you stopped using the acronym LFA and used LSA instead - are they in fact the same thing? (I keep thinking of the completely unrelated Link State Advertisment when I read that!)

    “When you have multiple possible LSAs, fast reroute has to select one LSA. EIGRP will not just select the “best” (lowest metric) feasible successor but uses some “tie-breakers” to select the best LSA. When you use per-prefix LSA, we have these four attributes:”

    Also, is the tiebreaker “Lowest repair path metric” effectively just

    ... Continue reading in our forum

  2. Hi @chrisnewnham17

    Sorry for the confusion, it should be LFA not LSA :smile: Just fixed this.

    Lowest repair path metric basically means that EIGRP selects the feasible successor with the lowest metric as the LFA. All other feasible successors are ignored.

  3. Hi Rene and staff,

    i just want to add a comment about EIGRP named mode, i am discovering again through this lesson since my CCNA (to prepare CCNA i learned a little more than the blueprint)
    Some students could wonder why the metric in the RIB (16000) does not match the composit metric in the EIGRP topology table which is 2 048 000: i could not remember why from my CCNA and i had to google to find the answer
    "
    EIGRP Named mode uses a 64 bit wide metric. The problem with wide metric is the RIB only supports 32 bit value. So, you could have an EIGRP metric valu

    ... Continue reading in our forum

  4. Hi Rene and staff,
    just adding another comment
    I noted in some blogs that sub-interfaces are considered disjointed interfaces by the FRR process
    I don’t know if it is true for all IOS (but it seems true for IOS-XE)
    I think that it is interesting to point this out (to be verified in new labs with various flavors of IOS ?)
    Regards

18 more replies! Ask a question or join the discussion by visiting our Community Forum