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 ?)
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 ?
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)
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
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.
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.
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:
Physical detection; for example, loss of light.
Protocol detection that is routing protocol independent; for
example, the Bidirectional Failure Detection protocol [BFD].
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.
…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:
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.
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:
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:
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:
Thank you for your reply.
I am using EVE-NG as emulator. When I used “vIOS” as Node in this lesson,
vIOS don’t support the command fast-reroute per-prefix all.
Next, I changed the node, “CSR1000v”. Then, CSR1000v support the command.
Everything is good! Thank you so much!