EIGRP Metric & K-Values

By Joe Astorino on March 3rd, 2010

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 27 ratings
Be Sociable, Share!

    46 Responses to “EIGRP Metric & K-Values”

    1. Deepak Arora says:

      One of the best explanations I have ever come across for EIGRP k values.

      Great work…

      Can you share something more about EIGRP Redistribution?

      VA:F [1.9.22_1171]
      Rating: 5.0/5 (1 vote cast)
    2. Bill Laing says:

      Just what I wanted to read.

      This business of K1=BW K2=Load etc has been driving me crazy because it does not stand scrutiny when you consider the full metric formula.

      I also just last weekend did the metric calculations for myself (with the default K values) on a test set up with four routers to see if I could get the same feasable distances as the routers and after I realised that

      1) you need to use the minumum bandwith
      2) and cumulative delay
      3) the routers cannot do FP arithmetic

      guess what? the numbers came out bang on.

      Thanks for confirmining my own theories on K values and the metric calculation.

      VA:F [1.9.22_1171]
      Rating: 5.0/5 (2 votes cast)
    3. Deepak Arora says:

      Hi Marko,

      It will be great if you can write a series on redistribution logics like how redistribution process works, how we can avoid routing loops, what are the various techniques to avoid routing loops during multipoint mutual redistribution and above all best practices for it.

      I hope you won’t mind about my long list here :)

      Thanks Again!!1
      Deepak Arora

      VA:F [1.9.22_1171]
      Rating: 3.0/5 (1 vote cast)
      • Not at all. I’ll discuss it with my fellow instructors and see if we can come up with something nice. This may be an interesting thing to talk about, of course.

        You, of course, know that we talk about those things extensively in our workbooks and videos?


        Marko Milivojevic – CCIE #18427
        Senior Technical Instructor – IPexpert

        VN:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)
    4. Manny says:

      Wonderful Joe, It’s very helpful and i really appreciate.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    5. Muhammad Aslam says:

      wonderful!!!

      thanx

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    6. Finally someone got it exactly right ;) Good work!

      VA:F [1.9.22_1171]
      Rating: 4.0/5 (2 votes cast)
    7. Doug says:

      A coupe of things I hope someone can clear up for me…

      If you replace K2, K4, and K5 with 0, the formula actually reduces to 0 (since anything multiplied by 0 = 0, and (K5/(Reliability + K4) = 0 if K5 = 0).

      Ignoring that, you calculated the metric to 7.7.7.7 to be 2169856, while the router says is 2297856. I think you actually calculated the metric to the the connected subnet 78.78.78.0, because you left out the delay of the loopback on R7.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    8. Matt says:

      I was just curious about your delay calculation. How did you come up with ’20,000 / 10 = 2000′ for delay?

      Thanks,

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    9. Matt says:

      Actually I was just confused…as Doug stated below you calculated the route to 78.78.78.0…not 7.7.7.7. It would have been 20,000 + 5,000 /10 = 2500 (to get into tens of msecs, making the metric 2297856). Got a bit confused by ‘Keep in mind we are calculating the metric for the loopback interface of R7 over on R8.’

      Thanks for the very helpful info!!

      VA:F [1.9.22_1171]
      Rating: 3.0/5 (1 vote cast)
    10. Owen says:

      I Love You!! best definition of EIGRP K-Values and metrics I have found. Very concise

      VA:F [1.9.22_1171]
      Rating: 5.0/5 (1 vote cast)
    11. Owen says:

      One question though, if when you are redistributing something into EIGRP and are listing your values of load, delay, and blah blah.. If your metric weights are 010100 specifying default metric weights and only using the bandwidth composite and delays in your metric calculation, if you specify something, for instance load or reliability, as 0 or 1 will that actually end up a different metric then if you put in 255 reliability or 255 load??

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    12. Owen says:

      ok one more question…. If the local router is using the advertised distance from the upstream EIGRP neighbor in its calculation, how does the local router know the lowest bandwidth and cumulative delay. Is there some sort of formula it has to deduce this from the advertised distance or does the routing update specify all the delays/the cumulative delay and minimum bandwidth??

      Thanks in advance

      VA:F [1.9.22_1171]
      Rating: 5.0/5 (1 vote cast)
    13. pp says:

      If you sniff the EIGRP update packet you will see that the router R7 update each value separately:
      Bandwidth, Delay, hop count and others.

      R8 can use this information to find the “lowest bandwidth” value.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    14. Brett Husebye says:

      Doesn’t matter how he derived it. Do the math and the Metric for EIGRP works. Take what you know – what you dont know answer = 10ths of a microsecnd because the next SI unit is 1000 times larger, measurements of 10−5 and 10−4 seconds are typically expressed as tens or hundreds of microseconds.

      That and your dealing with the power of 10′s.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    15. Subham says:

      why does eigrp uses slowest b.w. for metric calc & what will happen if we use a faster b.w. instead….

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    16. [...] Using the metric weights command in EIGRP configuration mode, you can set the variables to a 1 or 0, each of which weights the metric calculation formula more or less heavily for various parts of the formula. Mismatched k-value settings between will prevent neighbor relationships from forming, so they must be configured to match on all routers in which neighborships should form. EIGRP will log when it receives a Hello with mismatching k-values, and you can also check them with the show ip protocols command. I’ll go much more in depth about k-values later on, but for more detail take a look at this site. [...]

    17. [...] EIGRP Metric & K-Values Troubleshooting EIGRP Enhanced Interior Gateway Routing Protocol Cisco IOS Scripting with Tcl. Share this:TwitterFacebookLike this:TetszikJelezd elsőként, hogy neked ez tetszik: post! [...]

    18. [...] Wireless, CCNA Security, MCSA, MCTIP:SA Today 10:19 PM #3 Found this IPExpert EIGRP Metric & K-Values It states it was never fully implemented into EIGRP so it has to be set to Zero. My [...]

    19. Atif says:

      Great work mate. I was unable to understand this thing but the way you described is simply amazing.
      Keep it up bro

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    20. Dave says:

      Joe,
      I do like the explanation you gave above. However I as I understand the slowest link in a route is used as part of the metric. So for the sake of discussion an extra hop is added between R7 and R8 and the link between the newly inserted router and R8 is 64 bit. How does this affect the calculations between R7 AND R8
      As I understand it the BW and DLY are based on the local serial interface of R7. But due to that addition of the 64KB link the over all delay with changed on the FD – correct, what else would be affect and how can I see that?

      I trust I will see different number on R8 but will data on R7 change ?

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

      Please share your insights.
      Thanks Dave

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    21. Mohau Nchake says:

      Ok I get now…!

      About the delay. The value DLY is: 20,000
      It is measured in “tens of microseconds”
      hence: Delay = 20000/10 = 2000

      Thank you Joe, Gr8 work!!!

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    22. Muhammed Adnan says:

      Why is the delay of 20,000 Micro second divided by 10 and then put in Metric formula to get the result? I am finding it difficult to comprehend this step!

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      • dragos says:

        1-128 are values for variance = unequal cost load balance traffic
        0-255 are for k

        VA:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)
      • dragos says:

        on an interface the delay is configured in tens of seconds
        ex: delay 15
        #sh ip eigrp topology 10.10.10.0/24 you will see the value in microseconds; 15×10 = 150 micoseconds
        ….
        Minimum bandwidth is 10000000 Kbit
        Total delay is 100 microseconds

        VA:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)
    23. Ted Haubein says:

      The K value integers mentioned are from 1 – 255. It’s my understanding they are from 0 – 128.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    24. Rob says:

      Sitting here at midnight watching Conan drinking beer when suddenly I couldn’t remember if MTU was in EIGRP’s ‘famous’ equation. Glad this was the first post that popped up on google. Thanks a lot. Look forward to reading more of your blogs.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    25. Nitish Gupta says:

      cool

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    26. Kevin says:

      I am a bit confused about the statement “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.”

      In my quick little lab using a similar configuration, but with only one loopback, I am seeing the cumulative delay being 25000 instead of 20000 like the above paragraph suggests. Why the difference?

      R2(config-router)#do sh ip eigrp top 25.25.25.0/24
      IP-EIGRP (AS 1): Topology entry for 25.25.25.0/24
        State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
        Routing Descriptor Blocks:
        1.1.1.1 (Serial1/0), from 1.1.1.1, Send flag is 0x0
            Composite metric is (2297856/128256), Route is Internal
            Vector metric:
              Minimum bandwidth is 1544 Kbit
              Total delay is 25000 microseconds
              Reliability is 255/255
              Load is 1/255
              Minimum MTU is 1500
              Hop count is 1
      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    27. sreenivash says:

      Superb Explanation over K values in EIGRP great work
      Thanx

      VA:F [1.9.22_1171]
      Rating: 5.0/5 (1 vote cast)
    28. Pawan says:

      Hi there, I am just a little doubtful.

      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

      #######################################################
      Is it necessary to advertise the network 88.0.0.0 into EIGRP, while we are also redistributing the connected networks?

      Regards,
      Pawan

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    29. ravinder dahiya says:

      superb article..

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    30. Hello every one i have one doubt in eigrp metric calculation.

      why EIGRP choose lowest bandwidth for metric calculations.
      can anybody explain with examples?

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    31. Subodh Kumar says:

      Great post!!

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    32. saar says:

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

      Hello Joe,
      great explanation.
      There is a typo though. The *(K5/(Reliability + K4)))
      Should be +(K5/(Reliability + K4)))
      Because of it was *(K5/(Reliability + K4)))
      Then the result would be * (0/(x+0)) which would result in the K3*1 being multiplied by zero which would zero it out and leave you with only.
      256*((K1*Bw)

      Hope I made it clear, if not let me know.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    33. rash says:

      Hi Joe
      Good Article.
      But I have some doubts. This is what I understood about Delay “The time taken by a packet to reach from point A to B”. If it so, how it will be a fixed value on an interface (say on serial interface 20000 us). Because during the high traffic the delay would be increased. I am bit confused about it. If my understanding of delay is wrong, please correct me.
      Thank you….

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    34. Cliff says:

      Great explanation. I was able to compute composite metric after I realized that you only add the delay of OUTGOING interfaces; not both outgoing and incoming.

      THanks

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    35. Andy says:

      Great explanation! Very well described including the bandwidth and delay

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    36. Chris says:

      Hi Joe

      This is a great article, but I’m confused on one thing. Cisco Network Academy, and you above, have given the calculation to multiply by [K5 / (Reliability+K4)]. If the default values for K4 and K5 are 0 when multiplying, the entire formula becomes metric=0.

      My question is, during the equation, if the router sees that there is no configured value for K4 and K5, does it simply “drop” the last part of the equation?

      Or, is everyone wrong, and the calculation should be
      EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + K3*Delay) + (K5/(Reliability + K4)))

      Thanks.

      -Chris

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    37. Venu says:

      If K5 is equal to 0 then reliability quotient is defined to be 1.

      Please refer EIGRP rfc : http://tools.ietf.org/html/draft-savage-eigrp-00#section-3

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    38. ahmed saud says:

      Hope this gives you a hint for your MTU calcuation :)

      (Optional) Adjusts the EIGRP metric or K value.

      EIGRP uses the following formula to determine the total metric to the network:
      EIGRP Metric = 256*((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay)*(K5/(Reliability + K4)))

      Note
      If K5 is 0, then (K5/ (Reliability + K4)) is defined as 1.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    39. Naresh Kumar says:

      great article
      superb !!10/10 for for you sir!!!

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    40. Charles Ferguson says:

      Copied from Enhanced Interior Gateway Routing Protocol (white paper) http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml

      EIGRP uses these scaled values to determine the total metric to the network:
      •metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]

      Note: These K values should be used after careful planning. Mismatched K values prevent a neighbor relationship from being built, which can cause your network to fail to converge.

      Note: If K5 = 0, the formula reduces to Metric = [k1 * bandwidth + (k2 * bandwidth)/(256 - load) + k3 * delay].

      The default values for K are:
      •K1 = 1
      •K2 = 0
      •K3 = 1
      •K4 = 0
      •K5 = 0

      For default behavior, you can simplify the formula as follows: metric = bandwidth + delay

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    41. Jon says:

      Booyah! Nailed it right on the money!!! Nice. We came up with the exact same number as the router

      I may be missing something here but if the metric you are working out on R8 is the metric to R7′s loopback you haven’t though.

      The number you came up with was 2169856. But looking at the topology table on R8 that is not the metric to the loopback on R7. The metric reported is 2297586.

      The reason for this is because you say you do not need to add the delay for the loopback but you do as each router does the calculation in isolation so the delay is –

      20000 + 5000 = 25000 / 10 = 2500

      256 *(6476 + 2500) = 2297586

      Perhaps I have misunderstood something ?

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
    42. another geek says:

      thanks for that clear explanation…and CAN YOU EXPLAIN THE CONCEPT OF WIDE METRICS IN EIGRP.

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)

    Leave a Reply