This topic is to discuss the following lesson:
Is there any reason in a real world deployment you might not want to disable BW? It seems more deterministic to use just BW.
As Rene has mentioned in the lesson, Cisco by default has Bandwidth and delay enabled while load and reliability are disabled as they change dynamically and Cisco recommended us to not enable them.
So in other term, Cisco wanted to say keep BW and delay only active. In the real world, I don’t see any reason to disable BW & delay. In case you want to disable any of them then it is better to disable the delay and keep the bandwidth enabled because the delay is calculated based on the sum of delays in the path as per the below formula’s
Metric = bandwidth (slowest link) + delay (sum of delays)
Here a good lesson explaining EIGRP K Values for more information.
Hope I could answer your question
The calculation is sum of all the delays and the lowest bandwidth.
So if you only enable the bandwidth then essentially the path length is not taken into consideration.
Usually you would prefer a shortest path if all the bandwidths are the same.
I was reading and researching on Google about the K6, and they say it represents jittler and energy. Jittler makes sense, but energy can’t understand. Are you going to use electricity as a metric? LOL
Would you know clearly how to explain the real need of K6 and how the metric is calculated?
As weird as it sounds, that’s exactly what they intend with energy yes
Here’s an excerpt from RFC 7868:
Use of Energy-based Path Selection results in paths with the lowest
energy usage being selected in a loop-free and deterministic manner.
The amount of energy used is accumulative and has results in a higher
aggregate metric than those having lower energy.
Presently, EIGRP does not report energy usage, and as such the
default value will be zero (0).
On the Cisco site, you can find this:
likewise energy would be expressed in power per kilobytes per second of usage
So the idea is to select an interface, based on how much power it consumes.
You can find the wide metrics formula (that includes K6) here:
Hope this helps!
I am going to use the below topology as a reference for my question.
I am trying to manipulate EIGRP path by changing the interface delay on ROUTER-1.
By default, this is how everything looks like.
Then I increased the interface delay and now the prefix is showing up as
FD is Infinity in the EIGRP topology table and the prefix is not in the routing table anymore. Additionally, I am not running any other routing protocol and don’t have any static route either. Please shed some light on it.
Thank you so much in advance.
Usually, this happens when there is another routing protocol (or a static route) that provides a route to the destination in question with a smaller Administrative Distance (AD). But since you have already stated that you don’t have any of those, and the fact that the routing table is empty, indicates that the problem is elsewhere.
Now the FD will be infinity if the EIGRP metric is maxed out. Let’s do a calculation.
The EIGRP metric is a 32 bit value, which means it’s maximum value is 4,294,967,295. If you look at the EIGRP equation, taking into account only K1 and K3, you get the following:
Metric = 256 * [(10,000,000/bandwidth)+delay]
where bandwidth is in kilobits and delay is in tens of microseconds.
Looking at your configuration, I wasn’t able to see the speed of the link between the routers, but I did see that we are looking at an Ethernet port (not fast or giga), so I’m assuming 10 Mbps. So:
bandwidth = 10,000 kbps
delay ethernet = 1,677,721 tens of microseconds
delay loopback = 500 tens of microseconds
Plugging this into the equation, we get:
metric = 256 * [(10,000,000/10,000)+(1,677,721+500)] = 429,880,576
This is indeed smaller than the maximum of 4,294,967,295 and should not result in a maximum
However, looking at the FD of the route before you changed the delay, we see a composite metric of 131153920 but I calculate, based on the vector metrics, a metric of 512256. Also, I see a reported metric of 163840 to the loopback destination, whereas it should be 128320.
Again, in your output after the change in delay, I see that the composite metric is greater than the maximum EIGRP metric, although this calculation is not “correct” according to the equation.
The only thing I can think of is to check that the other K values are indeed 0 and that the delay and other parameters of the loopback interface have not been changed in some way. Check the default values of these parameters for the loopback to see if the specific router and IOS combination have some other defaults.
The discrepancy in the calculations must be due to a parameter that has not been included in our calculations of EIGRP. Can you take a look and let us know your findings?
I hope this has been helpful!