08-21-2013 11:50 AM - edited 03-07-2019 03:03 PM
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.
Solved! Go to Solution.
08-21-2013 12:23 PM
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:
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
08-21-2013 12:23 PM
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:
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
08-21-2013 12:50 PM
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...
08-21-2013 01:30 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide