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

Lessons Discussion
1

This topic is to discuss the following lesson:

2

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)

Thanks

3

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.

4

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
Regards

5

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

6

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

Image21
Image21.png732Ă—490 12.5 KB

Image23
Image23.png1172Ă—216 7.58 KB

Image25
Image25.png1130Ă—312 6.7 KB

Image27
Image27.png1136Ă—524 19.7 KB

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)

Image29
Image29.png1136Ă—166 3.49 KB

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 ?

Image31
Image31.png1250Ă—202 10.3 KB

Anyway, the command srlg does not exist on my router

Image33
Image33.png1170Ă—282 7.32 KB

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

7

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!

Laz

8

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

Image3
Image3.png1088Ă—360 7.4 KB

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

Image5
Image5.png1026Ă—300 9.84 KB

Regards

1 Like
9

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.

https://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/fs29srlg.html#wp1027195

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.

https://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r5-3/mpls/command/reference/b-mpls-cr-53xcrs/b-mpls-cr-53xcrs_chapter_0100.html#wp1203470800

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!

Laz

10

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

11

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!

Laz

12

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

13

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 192.168.12.2 proc:FRR, idb:GigabitEthernet2 handle:1 act

I don’t see any BFD neighbors though…

Thanks,
LP

14

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!

Laz

1 Like
15

Hi guys,

in which order does the tie-breakers take precedence?

Example, does SRLG Disjoint take precedence over the others because it has the lowest priority, or does Linecard-Disjoint take precedence because it is the highest?

16

Hello Joseph

When implementing FRR LFA for EIGRP, there is a default priority that is assigned to each tiebreaker. By default, the priority that is assigned is:

srlg-disjoint —10
interface-disjoint —20
lowest-backup-path-metric —30
linecard-disjoint —40

…where the lower the number, the higher the priority.

All tie-breakers that are configured are applied, regardless of how many candidate paths remain after each. However, if a tie-breaker results in the elimination of all paths, that tie-breaker is skipped. Remember that these tie breakers are elimination tie breakers. They remove any paths that do not conform to the specific attribute. More than one LFA may remain in the routing table after all tie breakers are applied.

You can modify the rules used using the fast-reroute tie-break command. More about this command can be found here:

I hope this has been helpful!

Laz

17

Hello,
In the lesson Rene says that there is Per-link and Per-prefix method. The per-link method is the default one because i didn’t see any config in the lesson? How exactly it works? I mean if the primary link fails and we have 2 secondary links how it will choose which to switch all prefixes that used the primary link?
Does this method has to do anything with the command fast-reroute load-sharing under the topology base config mode?
Thanks in advance.

18

Hello Marios

In the description in the lesson, Rene mentions that IGPs in general calculate their LFAs using different methods. Now EIGRP always calculates an LFA, which is called the feasible successor. And EIGRP always computes prefix-based LFAs. This is something that cannot be changed because it is an intricate part of the routing protocol itself. This is also confirmed by this Cisco documentation where it states:

EIGRP always computes prefix-based LFAs.

So far, when talking about LFAs, EIGRP, by its very nature, performs this function, and it only performs it on a per-prefix basis.

The further configuration done in the lesson simply enables FRR, which means the feasible successor, whichever one EIGRP natively chooses, will be placed as a repair path using the fast-reroute per-prefix command.

The fast-reroute load-sharing disable command, is used to disable the default behavior of FFR which is to load share across LFAs if they have the same metric. If this is disabled, then the tie-breaking rules will be applied and only a single LFA will be installed as the repair route. More information on this command can be found here:
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-3/command_reference/b_173_9500_cr/ip_routing_commands.html#wp1624013282
Now other routing protocols, such as OSPF (depending on the platform and IOS version) do support per-link LFA. For more information on LFA FFR for OSPF take a look at this lesson:

I hope this has been helpful!

Laz

1 Like
19

cant understand the difference between per-prefix and per-link based LFA ?.

Can we configure LFA in all IGP and BGP as well ??

Does LFA uses BFD in back-end ?

Can we configure the LFA in Classic EIGRP or its only available in named mode EIGRP ??

20

Hello Narad

The explanation is extensive in the lesson, but I’ll add some information here. The per-link method calculates a single LFA for all the prefixes that share the same exit interface. Per-prefix on the other hand, calculates an LFA for each individual prefix.

LFA is available to be used in OSPF as well as IS-IS routing protocols. However, it is not a feature that is directly related to BGP. BGP does benefit from it because LFA computes the alternate next-hops to all IGP destinations, which include alternate next-hops to the AS exit router’s router-ID for BGP. BGP simply inherits the alternate next-hop from IGP. The BGP decision process is unaltered, however.

Take a look at this post:

After going into the lab, I checked it out and it seems the command is only available in EIGRP named mode. At least on Cisco CML using IOSv version 15.9(3)M2. This seems to be confirmed by the following command reference:

I hope this has been helpful!

Laz