Wierdness in EIGRP topology table

[James Baird]

I've been experimenting with EIGRP unequal cost load balancing, and I've come up with some puzzling stuff.  I have two (virtual) routers, one with a two-link Multilink PPP and one with a single serial link.  When I first set it up, the traffic actually prefered the single link, because the delay was set to 100000 microseconds on the Mu link and that was enough to prefer the other one, but I got that worked out.  What puzzling me now is the reported FD of the route itself.

If I change the bandwidth of the interface, when I look at the topology table, it reports the FD of the route as being what it would be without the bandwidth statement, even as it reports the actual route to the successor correctly!  F'rinstance, here is a topology entry without the bandwidth statement:

R3(config-if)#do sh ip eigrp top 1.1.1.1/32

IP-EIGRP (AS 100): Topology entry for 1.1.1.1/32

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1494528

  Routing Descriptor Blocks:

  10.2.3.1 (Multilink1), from 10.2.3.1, Send flag is 0x0

      Composite metric is (1494528/409600), Route is Internal

      Vector metric:

        Minimum bandwidth is 3088 Kbit

        Total delay is 26000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 2

Here is the entry after the bandwidth for Multilink1 is set to 2500:

IP-EIGRP (AS 100): Topology entry for 1.1.1.1/32

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1494528

  Routing Descriptor Blocks:

  10.2.3.1 (Multilink1), from 10.2.3.1, Send flag is 0x0

      Composite metric is (1689600/409600), Route is Internal

      Vector metric:

        Minimum bandwidth is 2500 Kbit

        Total delay is 26000 microseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 2

The FD of the entry itself changes, and that's what it reports to upstream routers as an RD, but it still has the original FD as the FD of the route.  Is this a bug?  Or is there some reason for this?  Does the Feasibiilty condition only apply if the incoming RD is below the route's FD, or the entrie's FD?  I did a lot of googling, and I couldn't find any reference to this behavior.

[Peter Paluch · Accepted solution]

Hi James,

Welcome to the truth about EIGRP's FD

The Feasible Distance is not necessarily the actual distance to the destination. Rather, it is the minimum distance to the destination since the last time the route went from Active to Passive state. In other words, the FD is the historical minimum of the distance to the destination, with the "history" starting anew with the Active->Passive transition.

If you modify your bandwidth setting so that the total distance increases, you will change your actual distance to the destination but the FD, being the historical minimum, stays at its current value. This is not a bug - on the contrary, it is the required and intended behavior. The logic here, in very vague words, is:

• A routing loop does not ensue if you send packets towards a neighbor that is closer to the destination than you are (if there was a routing loop under these circumstances, at least one link in the network would need to have a negative metric which is impossible).
• However, during topology changes, it is not certain if all routers have the same changed information at the same instant, and in fact, they do not because the information about changed topology (or metrics) needs a time to propagate. In fact, routing loops in dynamic routing protocols are caused by making decisions based on outdated information that does not correspond to the momentary state. Simply thinking "in the moment my distance has increased for whatever reason, a neighbor X that currently reports a lower distance than myself can be used as a next hop" is wrong - what if this neighbor X is in fact using us as its own next hop, and it does not yet know about our increased distance? This is why we can not simply compare our actual distance to our neighbor's distances when choosing a loop free neighbor because it is not certain the neighbors already know what we know.
• However, choosing a historical minimum of the distance (i.e. the FD) removes this temporal dependency from our decisions. In a stable loop free network, indeed, our current best distance (used to initialize the FD) is higher than our next hop's distance. If anything happens to our current distance, we do not know if our neighbors already have been updated, but what we know for sure that if they still are closer to the destination that we have ever been, they can not form a routing loop.

This is the idea behind the FD, and in fact, the last sentence of the last bullet is an alternative wording of the Feasibility Condition:

If a neighbor is closer to the destination than we have ever been, it can not be on a routing loop closing back through us.

So what you see is completely normal, expected, and is the very core of EIGRP's loop free mechanism. It's somewhat sad it is not explained better in most textbooks and EIGRP courses.

Feel welcome to ask further!

Best regards,

Peter

[James Baird]

Aha!  I just did some more tests, and sure enough, when I LOWER the bandwidth, the FD doensn't change - ate least not locally (the downstream routers do, I guess getting the updated RD counts as "going active").  RAISING it changes it immediately.  And then if I've lowered it, bouncing the interface causes the FD to go to the new value.

One other thing I've learned with this testing: bandwidth statements don't take effect immediately, at least not as far as EIGRP is concerned.  After I change the bandwidth, it takes a few seconds to be reflected in the topology table.  I imagine this is some sort of dampening feature...

Anyway, thanks for the info!  Hopefully I can win a bar bet with the knowledge one day...

[Peter Paluch]

Hi James,

when I LOWER the bandwidth, the FD doensn't change - ate least not  locally (the downstream routers do, I guess getting the updated RD  counts as "going active"). 

Yes, that is true. Note that by definition, the FD as the historical minimum can only decrease. The only way to increase the FD is to go through the Active state, in which case you actively negotiate the true distances with your neigbhors, and therefore you are sure that when you transition back from Active to Passive state, the neighbors have been informed and have made their appropriate choices.

One other thing I've learned with this testing: bandwidth statements  don't take effect immediately, at least not as far as EIGRP is  concerned.

True, that is my observation as well. It always took 10 seconds after changing either the bandwidth or the delay setting on an interface for this change to be reflected in EIGRP.

Best regards,

Peter