EIGRP load-balancing though not meeting FC

[mlan]

Hi, 

I'm studying for my CCIE and exercising with EIGRP. 

All my exercises are done in CML2, using IOS Version 15.9(3)M3. 

In my last LAB I was playing around with different paths and how adjusting the metric changes the FD, CD and RD. 

The Routers are setup to consider only DLY for the EIGRP metric calculation (Metric weight K1=0, K2=0, K3=1, K4=0, K5=0)

Now following setup. I have a network 155.1.9.0/24 reachable through two Routers, R7 ad R1. 

By default, the DLY via R7 is 30 (CD = 768/ RD= 512) and DLY via R1 is 50 (CD = 1280 / RD= 1024).

EIGRP is correctly choosing R7 as successor and setting the FD to 768.

For my test I've wanted to increase the metric via R7 step by step to see how the Router behaves in terms of CD and FD. 

As I understood EIGRP, increasing the metric should lead to a recalculation of the CD, but the FD should stay the same as long as the route is not going Active. Increasing the DLY to 40 via R7 confirmed my assumption as the CD increased to 1024 whereas the FD stayed at the expected 768.  

In my second test, I've wanted to increase the DLY by another 10 microseconds, to have a total delay of 50 via both paths, leading to the same metric as well. As the FD is set to 768 and R1's RD is 1024, I've expected to still have just 1 successor, being R7, even though both will have the same metric, but as R1 is not gonna meet the FC (R1 RD =1024 > FD = 768) it should not be considered as a successor. 

After increasing the DLY to 50 via R7 I've ended up with the same metric for both paths (CD=1280), but the Router has installed both of the uplinks into the routing table, even though the FD stayed at the expected 768. 

sh ip eigrp top 155.1.9.0/24
EIGRP-IPv4 Topology Entry for AS(100)/ID(150.1.6.6) for 155.1.9.0/24
  State is Passive, Query origin flag is 1, 2 Successor(s), FD is 768
  Descriptor Blocks:
  155.1.67.7 (GigabitEthernet0/1.67), from 155.1.67.7, Send flag is 0x0
      Composite metric is (1280/512), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 50 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 150.1.9.9
  155.1.146.1 (GigabitEthernet0/1.146), from 155.1.146.1, Send flag is 0x0
      Composite metric is (1280/1024), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 50 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 4
        Originating router is 150.1.9.9

show ip route 155.1.9.0
Routing entry for 155.1.9.0/24
  Known via "eigrp 100", distance 90, metric 1280, type internal
  Redistributing via eigrp 100
  Last update from 155.1.146.1 on GigabitEthernet0/1.146, 00:33:04 ago
  Routing Descriptor Blocks:
    155.1.146.1, from 155.1.146.1, 00:33:04 ago, via GigabitEthernet0/1.146
      Route metric is 1280, traffic share count is 1
      Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 4
  * 155.1.67.7, from 155.1.67.7, 00:33:04 ago, via GigabitEthernet0/1.67
      Route metric is 1280, traffic share count is 1
      Total delay is 50 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2

Shouldn't the Router still just choose the path via R7 (155.1.67.7), as the path via R1 (155.1.146.1) is clearly not meeting the FC in above's output? Am I missing something here? 

Thanks! 

[David Ruess]

Hello,

I also though this. The Feasible Distance is the LOWEST metric for that route the router has seen since the route became Passive. Its more or less a historical record of the metric the router has seen. (Credit: @Peter Paluch) - not sure how to tag people who aren't in the thread. Once you make the route Active and back to Passive this value will change if you have modified the metric. The CM (Composite Metric) is the current metric. As in your discussion you have taken BW out of the equation and only rely on Delay. Once you made them the same they chose to ECMP towards the route.

You can test this theory by shutting down that route or the single link to that route to make it go Active. I'm not sure if clearing the neighbor ship will do the trick, but it might.

Hope that helps

-David

[Joseph W. Doherty]

". . . not sure how to tag people who aren't in the thread."

@ symbol following by typing user name, including spaces.  E.g. for Peter Paluch, "@Peter Paluch", w/o quotes.

[mlan]

Correct, but if you take a look at the EIGRP Topology Table output I've posted, the second path via 155.1.146.1 doesn't even meet the feasible condition, as the Reported distance of the neighbour is clearly higher compared to the local feasible distance. Shouldn't EIGRP only start load-balancing (regardless if ecmp or unequal) when the neighbour meets the feasible condition? 

[David Ruess]

It does meet the feasibility condition. I read my earlier post and I probably could have been a bit more clear. The FD you highlighted in RED is the lowest FD to that route the router has seen since its been up. So if it gets a lower value it will change to the lower value, but if it gets a higher value it wont change (until the route goes Active). Regardless that value is not the value compared to meet the feasibility condition.

So in this context words mean things. The definition most documents have for the Feasible Distance is actually the definition for the Composite Metric (CM).

So in your output the CM is the same, therefore making EIGRP use ECMP.

Composite metric is (1280/1024), route is Internal <- this is the metric compared to the FC

-David

[mlan]

Thanks David for your response. 

In another community post, Peter Paluch described the FD & FC in following way:

//SNIP

If we understand the Feasible Distance as the minimal historical distance to a destination then the Feasibility Condition that says: RD < FD can be put into words as follows:

Any neighbor who is closer to the destination than we have ever been is not on a routing loop.

//SNIP

Reading this I would still say that the FD is always taken into consideration for the feasible condition, and not the CD? 

As the Route never became active it is also correct that the FD stays to the lowest value (768 in my case), which should prevent the second path getting installed in the routing table, shouldn't it? 

[David Ruess]

So the statement you reference is true. Any neighbor (by metric) who is closer than we have ever been is loop free. This is another spot where words mean things. The feasible distance of the current successor route is represented by the CD metric in that line. As mentioned the value you highlighted in red is a snapshot in time and the closest we have ever been to that route. While it is A Feasible Distance, its not THE Feasible Distance used in the calculation of loop free routes...at least every time.

By definition: Feasible distance (FD) – the local router's metric of the best route to reach a specific network.

That being said the best route the router will see to a network is the Composite metric in the brackets (FD/RD). Most CISCO documentation will say the first number is the feasible distance as well. That feasible distance is what used for the calculation for the feasibility condition.

Think of it like this. If that top FD metric IS the FD used in the FC metric what happens when you're playing with metrics or re-structuring your network and you make that top FD a really low number - and the route stays passive (Since the historical FD number changes when the route goes active). Then you go back and change route metrics again and the route gets a higher FD(CM in this definition) In that case that route will never be installed in the topology table and by nature the routing table because you've increased the metric of the route above the historical FD and the historical FD can never be incremented, only decremented unless the route goes active.

I also labbed this up (not he INE lab you were using, but one I made). Same result. However I did notice one thing. I made it to where I only had 1 successor route. When I artificially increased the metric to where the RD was higher than the historically lower FD, then the route went active and recalculated a new historical FD - which ended up being higher since that FD resets when the route goes active. So when I had 2 routes like you a successor and feasible successor, as I kept increasing the metric the route never went active even after rising above the historical FD. My assumption is because the successor route acted as an interim for the FC and that's what it checks against. (debugging eigrp query packets helped)

So to sum up I guess you could say that the the Feasibility Condition states that a route will not be accepted if the Reported Distance is more than the best path's Feasible Distance.

The Feasible Distance in this case can be 1 of 2 numbers. If there are 2 or more routes it will use the current successor routes CD (FD) metric. If these is only 1 route it will use the historical FD metric.

This is the whole community thread I was referencing before:

https://community.cisco.com/t5/switching/eigrp-successor-and-feasible-successor/td-p/2257563

Its a long read but very thorough.

Hope that helps

-David

[Giuseppe Larosa]

Hello @mlan , @Joseph W. Doherty ,

if you study on CCIE R/S by Cisco Press volume I version 5  written by our friend @Peter Paluch

As stated also on Jeff Doyle's Routing with TCP/IP volume I  1st or second edition.

The FD is the record of the value of the distance of last successor to the route.

if no Feasible Successor exists the route goes Active  and the DUAL = Diffusive Update Algorithm is triggered for the affected prefix(es) a Query message is sent out of each EIGRP enabled interface asking the neighbor(s) out that interface if they have an alternate path for the prefixes in active state.

Route filtering, route summarization and EIGRP stub feature allows for scalability of EIGRP protocol in HUB and Spokes topologies all Spokes are configured as EIGRP stub and so on.

IF all neighors answers with a 32 bit value of 0xFFFFFF means not accessible no one knows about that prefix and the prefix is purged from EIGRP database.

EIGRP has become a standard protocol is not anymore a Cisco proprietary protocol.

this is very different from how OSPF and IS-IS works they are not diffusive in computation they keep in sync the link state state DB of each area.

Hope to help

Giuseppe

[Joseph W. Doherty]

"EIGRP has become a standard protocol is not anymore a Cisco proprietary protocol."

@Giuseppe Larosa do I correctly recall (???), Cisco didn't open up ALL of EIGRP for public use (at least initially, possibly they have since).

[Giuseppe Larosa]

Hello @Joseph W. Doherty ,

First Edition of Jeff Doyle's Routing TCP/IP Volume I was so detailed ,that provided a way for some   other companies to implement EIGRP in their products ( i.e. to make reverse engineering)

EIGRP is now public and @Peter Paluch is one of the author of the RFC 7868

Independent Submission                                         D. Savage
Request for Comments: 7868                                         J. Ng
Category: Informational                                         S. Moore
ISSN: 2070-1721                                            Cisco Systems
                                                                D. Slice
                                                        Cumulus Networks  ----> white box BRoadcom vendor
                                                            >>   P. Paluch
                                                    University of Zilina  --> now at Cisco TAC Bruxelles
                                                           >>     R. White before he was with Cisco
                                                                LinkedIn
                                                                May 2016

I met in person Peter Paluch in 2018 and 2020 at Barcelona for EMEAR Cisco Live.

I met also Harold Ritter.

Best Regards

Giuseppe

[Giuseppe Larosa]

Hello @Joseph W. Doherty ,

one of the US patents related to Cisco EIGRP is that about RTT the protocol used over LAN segments to send in a ordered manner the EIGRP updates. The strategy was introduced to accomodate very slow / SW based routers and so on. The idea was to send out on all EIGRP routers on link 224.0.0.10 all updates to wait for ackowneldge and to have a per interface per neighbor queue that traces what is the last update reliabily received ( ack received). Slow neighbors are not considered in DUAL that demonstrates that if all neighbors have received all updates in an ordered manner then diffusive computation can occur without creating temporary  loops

Nowdays multiple EIGRP neighbors are avoived.

US patents are valid for some years and then they become accessible to everyone.

As a result of this EIGRP can be considered a non proprietary protocol.

Cisco on his own has moved to named EIGRP on EIGRP XE that uses a 64 bit composite metric and then uses a scalar to create a 32 bit value to be passed to IP routing table daemon

EIGRP is a good protocol for HUb & Spokes DMVPN.

to be noted SD Access uses IS-IS in the fabric.

SD WAN comes from VIPtela acqusition.

Hope to help

Giuseppe

[David Ruess]

Hello,

I think @Joseph W. Doherty  is correct. Not ALL of EIGRP has been released. Some advanced features are still not available (STUB feature comes to mind). Also I don't believe its a standard so much as its been "released for informational purposes".

In my opinion of the word if something is standard then all if not most vendors have implemented it and all parts are known (and companies can submit for changes) for the most part. To my knowledge this is not the case with CISCOs EIGRP. I'm pretty sure its still proprietary as the RFC @Giuseppe Larosa mentioned is informational (which I think means CISCO still owns it).

-David

[Joseph W. Doherty]

@Giuseppe Larosa, an interesting RFC (of which I was unaware), including it stating "This document is not an Internet Standards Track specification; it is published for informational purposes.", so it makes me wonder whether EIGRP can truly be considered a "standard protocol".

Anyway, checking into this further, and my vague memory of Cisco opening up EIGRP before 2016, I found, goes back to 2013/2014 timeframe, i.e. before the 2016 timeframe of RFC 7868.  I found a thread I posted within, back then, on this subject (2014: EIGRP was Cisco proprietary. Is it an open standard protocol now? )

There are, in that thread, references that note some features of EIGRP were not opened up, such as stubs.  Looking through RFC 7868, I didn't find a mention of stub in the RFC, but I'm far, far from being an expert in EIGRP, so it might be there using different terminology.

Close to 7 years later, there hasn't been, I believe, much uptake of EIGRP by other network vendors, which might raise the question of "why not?", even though EIGRP is a very fine IGP.

[Giuseppe Larosa]

Hello @Joseph W. Doherty  and @David Ruess ,

you both are right the RFC provides inter-operability behind the scenes there were legal issues in first years of 2000.

The RFC reflects this its is a classic tradeoff

I apologize if I couldn't read it front to end, but I need to work and to stdy and  I

Best Regards

Giuseppe