EIGRP Metric & K-Values

Welcome back to another techtorial blog here at IPexpert! Today’s topic is coming at you all directly from this week here at IPexpert bootcamp!!! Tonight we will be discussing the often misunderstood topic of EIGRP metric and K-Values. how exactly is the metric calculated? What ARE the K values? What are they used for? Perhaps more importantly, we will discuss what K-Values are NOT as this is almost always misunderstood especially because much of the information out there is wrong. Today, we have a rather simple topology to look at.

In this beast of a topology, R7 and R8 each have a loopback configured of x.x.x.x where x is the router number. Additionally, they are running EIGRP AS 78 between them, and each router is advertising their loopback into EIGRP. Right now, all the default K-values are in place ( 0 1 0 1 0 0 ). Before we get into the theory, let’s take a look at the EIGRP topology table on R8 as well are the routing table.

R8(config-router)#do sh ip eigrp top
IP-EIGRP Topology Table for AS(78)/ID(8.8.8.8)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 7.7.7.7/32, 1 successors, FD is 2297856
via 78.78.78.7 (2297856/128256), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 128256
via Connected, Loopback0
P 78.78.78.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0/0
R8(config-router)#do sh ip route eigrp
7.0.0.0/32 is subnetted, 1 subnets
D       7.7.7.7 [90/2297856] via 78.78.78.7, 00:12:27, Serial0/0/0

As we can see above, R8 has the route for R7’s 7.7.7.7 loopback address as expected. We see that the composite metric for the route is 2297856. Cool. First off, how in the world did we get that metric? How is the EIGRP metric calculated? The dreaded formula…this is right from the current 12.4T IOS configuration guide under EIGRP. Note that some other documentation seems to forget the fact that in EIGRP everything is scaled by a factor of 256 : )

EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + K3*Delay)*(K5/(Reliability + K4)))

OK, bad…but not too too bad. Just ugly. Very ugly! Another thing to keep in mind is that when we say “bandwidth” in the formula we are talking about the minimum bandwidth from point A to point B. When we say “delay” we are talking about the cumulative delay between point A and point B. Let’s see if we can figure out how to calculate this and get the same numbers as the router. Before we can do that, we need to understand the other variables in the equation: K1,K2,K3,K4 and K5. These values are simply used to scale things in the metric calculation. A K value is simply an integer between 1 and 255. That’s IT. Nothing magical. They are NOT equal to things like bandwidth, delay, reliability, load, and MTU. They are simply integers we use to multiply times those values to come up with a composite metric. As we know, K1 and K3 are set to a value of 1 by default, and other values are set to 0. Armed with that information, we can reduce our formula to the following:

EIGRP Metric = 256*(Bw + Delay)

Ah…much prettier. That is until we find out that bandwidth and delay in and of themselves have their own formulas as well. So the variable “Bw” in our above equation is defined as:

Bw = (10^7/minimum Bw in kilobits per second)

Furthermore, “Delay” in our above formula is defined as the route delay in tens of microseconds. Interesting. Taking this information our metric formula becomes:

EIGRP Metric = 256*((10^7 / min. Bw) + Delay)

OK, now we are getting somewhere. Let’s go find our variables Bw and Delay. Keep in mind we are calculating the metric for the loopback interface of R7 over on R8. That means we need the MINIMUM bandwidth from point A to point B as well as the CUMULATIVE delay. This can trip you up if you are not careful. Let’s take a look moving from right to left to find the minimum bandwidth and the cumulative delay.

R8(config-router)#do sh int s0/0/0 | i BW
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,

R7(config-router)#do sh int s0/0/0 | i BW
MTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,
R7(config-router)#do sh int lo0 | i BW
MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,

At a glance we can see that the minimum bandwidth is 1544Kb/s. What about cumulative delay? The delay of my serial link between R8 and R7 is 20000 microseconds. Furthermore, the delay on the loopback interface itself on R7 is another 5000 usec. Doesn’t that mean my cumulative delay would be 25000 microseconds? Actually, it doesn’t. The reason is because R7 already calculated out the bandwidth, delay and metric and then sent it to us. This is the AD or the advertised distance. We can see that on R8 in the topology table as 128256. Essentially R7 calculated the metric to itself and sent us that information.

R8(config-router)#do sh ip eigrp top | beg 7.7.7.7
P 7.7.7.7/32, 1 successors, FD is 2297856
via 78.78.78.7 (2297856/128256), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 128256
via Connected, Loopback0
P 78.78.78.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0/0

20,000 / 10 = 2000.

We should have what we need now. Going back to our formula:

EIGRP Metric = 256*((10^7 / min. Bw) + Delay) Let’s plug in our numbers: EIGRP Metric = 256*((10^7 / 1544) + 2000)… so

EIGRP Metric = 256*((10,000,000 / 1544) + 2000)

Time to whip out windows calculator and crunch some numbers…keep in mind decimals will be rounded DOWN to the nearest whole number.

10,000,000 / 1544 = 6476.68 == 6476 EIGRP Metric = 256*(6476 + 2000) = 2169856

Booyah! Nailed it right on the money!!! Nice. We came up with the exact same number as the router. Always a good thing! Next, let’s talk about some misconceptions with respect to K-Values and the EIGRP metric. You may have read somewhere that the various K-Values are EQUAL to various pieces of the metric. This is simply not true. For instance, you see this statement thrown around all over the place:

K1 = Bandwidth K2 = Load K3 = Delay K4 = Reliability K5 = MTU

Back in CCNA days this is what most of us were taught. Unfortunately, this is not technically correct. As I said in the beginning of the article, K values are just integers between 1 and 255 used to calculate the metric in conjunction with things like bandwidth, load, delay, and reliability. The K-Values themselves are not equal to what we see above. This is further confused when we do redistribution. Let’s see what happens on R7 when we attempt to redistribute connected routes…

R7(config)#router eigrp 78
R7(config-router)#redistribute connected metric ?
<1-4294967295>  Bandwidth metric in Kbits per second
R7(config-router)#redistribute connected metric 1 ?
<0-4294967295>  EIGRP delay metric, in 10 microsecond units
R7(config-router)#redistribute connected metric 1 2 ?
<0-255>  EIGRP reliability metric where 255 is 100% reliable
R7(config-router)#redistribute connected metric 1 2 3 ?
<1-255>  EIGRP Effective bandwidth metric (Loading) where 255 is 100% loaded
R7(config-router)#redistribute connected metric 1 2 3 4 ?
<1-65535>  EIGRP MTU of the path
R7(config-router)#redistribute connected metric 1 2 3 4 5

I don’t know about all you guys out there, but I was taught as a CCNA that when you redistribute into EIGRP you have to “set your K-Values.” This leads people to think that the numbers you enter during redistribution ARE the K-Values when in fact they are not. The numbers we enter here are simply values of which SOME are used in the calculation of the final composite metric. IF I was indeed inputting the value of K1 here on the first line, how could it possibly be a range between 1 and 4294967295 if a K-value by definition is an integer between 1 and 255? The answer is it can’t.

We are not specifying a K-Value. We are specifying the bandwidth variable used in the metric calculation. That value will in fact be MULTIPLIED by whatever value has been set for K1. I said SOME of these entered values are used in the calculation of metric. The reason I say SOME is because of the 5th and final value entered in the redistribution metric above. Take a look at the IOS help. It instructs us to enter the MTU of the path. Again, when people are under the impression that they are entering K-values here, it leads them to mistakenly believe that the 5th thing they enter must be K5 and therefore K5 must be equal to MTU. This is not true either. What we are entering here is indeed a value for MTU.

The MTU however is not used at any point during the calculation of the metric. Take a look at our full formula again.

EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + K3*Delay)*(K5/(Reliability + K4)))

Where in that formula do we see MTU? Nowhere. It simply does not exist in the calculation. So why do we enter it then? Because MTU is actually carried in EIGRP packets. It just has nothing to do with metric calculation. We keep saying that K-Values are just integers between 1 and 255 right? If we do not specify them during redistribution, where DO we? Under the EIGRP process using the “metric weights” command. To further illustrate the fact that MTU has nothing to do with metric calculation in EIGRP, let’s go ahead and set K5 = 1 on both sides.

R7(config-router)#metric weights 0 1 1 1 1 1

R8(config-router)#metric weights 0 1 1 1 1 1

While we’re at it…what is that first value that we set to 0 ? It is supposed to be used to specify ToS but was never implemented. Therefore, it HAS to be set to 0. OK. Now that we have altered our K-Values, obviously our metric will change. Let’s take a look at R8’s metric to 7.7.7.7 again.

R8(config-router)#do sh ip eigrp top | beg 7.7.7.7
P 7.7.7.7/32, 1 successors, FD is 9001
via 78.78.78.7 (9001/501), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 128256
via Connected, Loopback0
P 67.67.67.0/24, 1 successors, FD is 642667810
via 78.78.78.7 (642667810/642539810), Serial0/0/0
P 78.78.78.0/24, 1 successors, FD is 8501
via Connected, Serial0/0/0

As expected, our metric changed. Now, let’s change our MTU value and see if anything changes. R7:

R7(config-router)#int s0/0/0
R7(config-if)#mtu 1400
R8(config-router)#
R8(config-router)#int s0/0/0
R8(config-if)#mtu 1250
R8(config-if)#do sh ip eigrp top | beg 7.7.7.7
P 7.7.7.7/32, 1 successors, FD is 9001
via 78.78.78.7 (9001/501), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 128256
via Connected, Loopback0
P 67.67.67.0/24, 1 successors, FD is 642667810
via 78.78.78.7 (642667810/642539810), Serial0/0/0
P 78.78.78.0/24, 1 successors, FD is 8501
via Connected, Serial0/0/0

Nope. Same thing. One last proof of concept – What if we add another loopback to R8 and redistribute it into EIGRP? When we redistribute, we’ll set the MTU value to 1500 and check the metric on R7. We will then take the redistribution off and try it again with an MTU value of 1000. IF MTU was used in the metric calculation, the metric on R7 for that route would have to change.

R8(config-line)#do sh ip int brie | i Loop
Loopback0                  8.8.8.8         YES manual up                    up
R8(config-line)#int lo88
R8(config-if)#ip add 88.88.88.88 255.255.255.255
R8(config-if)#router eigrp 78
R8(config-router)#network 88.0.0.0
R8(config-router)#redistribute connected metric 1 2 3 4 1500
R7(config-if)#do sh ip eigrp top | beg 88.88.88.88
P 88.88.88.88/32, 1 successors, FD is 9001
via 78.78.78.8 (9001/501), Serial0/0/0

OK, we see that we have set the MTU during redistribution to 1500 and that the metric for this route on R7 is 9001. Let’s take off the redistribution and try again with another value.

R8(config-router)#no redistribute connected metric 1 2 3 4 1500
R8(config-router)#redistribute connected metric 1 2 3 4 1000
R7(config-if)#do sh ip eigrp top | beg 88.88.88.88
P 88.88.88.88/32, 1 successors, FD is 9001
via 78.78.78.8 (9001/501), Serial0/0/0
P 8.8.8.8/32, 1 successors, FD is 9001
via 78.78.78.8 (9001/501), Serial0/0/0
P 7.7.7.7/32, 1 successors, FD is 128256
via Connected, Loopback0
P 67.67.67.0/24, 1 successors, FD is 2560000512
via Rconnected (2560000512/0)
P 78.78.78.0/24, 1 successors, FD is 8501
via Connected, Serial0/0/0

I rest my case.

--
Joe Astorino CCIE #24347 (R&S)

EIGRP Metric & K-Values, 4.4 out of 5 based on 16 ratings