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

This topic is to discuss the following lesson:


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 the normal EIGRP way of selecting the best path via lowest metric? (but actually installing it in the routing table)


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.

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 value larger than the 32 bit value of the RIB. To solve this, the metric is scaled down by 128 (default but it can be changed)
2 048 000 / 128 = 16 000
I hope Rene and staff will agree with this comment and that helps some students that wonder about this

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 ?)

Hi Rene and staff,
i did the lab tie-breaker=SRLG with my GNS3, as it is in the lesson, but with my own interfaces in GNS3

I did not have to configure srlg on R1 interfaces,
IOS on R1 install the repair path as R4 (R3 is the best FS with the lower distance)

I suppose, at this point of the configuration, R1 can’t guess that R2 and R3 belong to the same multi-segment access (?)

Is it just because of GNS3 ?

Anyway, the command srlg does not exist on my router

But my question is: why do IOS on R1 choose R4 in my case ?
it could not apply interface-disjoint because all R1 interfaces are disjoint
it could not apply SRLG because there is no configuration srlg on R1 interfaces
So it has to apply best distance to choose the FS as repair path and it did not (it prefers R4 and not R3)

Is there something that could explain this situation ?

Hello Dominique

In order to determine the reason for the specific choice, take a look at the output to the following command:

show running-config all | include tie-break

This will show which attribute is used to determine which route will be chosen as the repair route. Take a look and if you like, share it with us so we can further see what is happening…

I hope this has been helpful!


yes helpful, thanks
Waiting for your response i closed my GNS3 lab
When i restarted the lab, R1 gives me this output

As you can see, R3 became the repair path (instead of R4) as i just closed and restarted the lab
I don’t understand why this happened, but now this is correct with the theory: R3 is the repair path because of its better metric, and R1 does not know that R2 and R3 are on the same multi-access segment
But with my platform / IOS, i cant set SRLG id in the interface mode. If i was in the real world with EIGRP using this platform/ios i will have a problem: so i wonder why this command is not available ? (because i think this is a basic command)

For fun, i found this command under MPLS


Hello Dominique

Sometimes GNS3 can behave in this way. It does occasionally occur where some behaviour is strange, but a reboot or a restart of the lab brings about the expected results. Sometimes it just “gets stuck”. It’s one of the quirks of GNS3 that we have to live with :slight_smile:

SRLG is indeed an important feature of MPLS as seen below.

However, SRLG is also a parameter that can be configured on the interface itself. In some IOS versions, the command is implemented differently. There is an srlg configuration mode under which the participating interfaces can be indicated and values can be configured. This of course is for another IOS version specifically for CRS routers, but you can take a look and see if your IOS version will allow these commands.

I can get Rene to take a look and share which IOS version he is using in his lessons to verify the commands.

I hope this has been helpful!


I am using GNS3, what IOS are you using as mine don’t support the command -
fast-reroute per-prefix all

Hello Kenneth

Take a look at the Cisco feature navigator. It will help you out in determining if particular features are available in the IOS version you are looking at. If you find that your IOS version does not support the specific features, see if you can get your hands on one that does.

I hope this has been helpful!


A post was merged into an existing topic: OSPF Loop-Free Alternate (LFA) Fast Reroute (FRR)

Hi Rene and Team,

Is there any relationship between FRR and BFD? I was doing the lab and got the output below when enabling FRR.

*Jan 26 18:03:26.175: %BFD-6-BFD_SESS_CREATED: BFD-SYSLOG: bfd_session_created, neigh proc:FRR, idb:GigabitEthernet2 handle:1 act

I don’t see any BFD neighbors though…


Hello Luis

FRR employed in EIGRP is a mechanism by which the feasible successor is already installed in the routing table to speed up the installment of the alternate path during reconvergence after a failure. But in order to speed up the installment, it is also necessary to speed up detection. FRR uses multiple methods by which this speedy detection is achieved, and one of them is BFD.

Note here that FRR is a mechanism that is fully described in RFC 5714 and is applicable not only to EIGRP, but to most conventional IP routing protocols. Specifically, it states:

It is critical that the failure detection time is minimized. A
number of well-documented approaches are possible, such as:

  1. Physical detection; for example, loss of light.
  2. Protocol detection that is routing protocol independent; for
    example, the Bidirectional Failure Detection protocol [BFD].
  3. Routing protocol detection; for example, use of “fast Hellos”.

FRR for EIGRP creates a BFD session in order to quickly detect failures. You don’t actually have to configure BFD in order for it to operate here, but it is an underlying mechanism of the FRR functionality. For other routing mechanisms, such as MPLS for example, what is known as “BFD Triggered FRR” must be manually configured.

I hope this has been helpful!


1 Like