Hi everyone, and thanks for taking some time to read this article. In one of my articles on network reliability, I promised to dive deep into the complex EIGRP composite metric. This article is an attempt to keep that promise. We will start by exploring the elements of the composite metric and how we can manipulate the elements of that metric. We will then move on to see how this works on a real network. So let’s get right to it.

What makes the EIGRP metric different from other IGP metrics?

Unlike other routing protocols (such as RIP and OSPF), EIGRP does not use a single attribute to determine the metric of its routes. In RIP, we use hop counts to determine the metric. This means that all routes received from the same router will have the same metric. This is regardless of what kind of interface we receive that route from. The OSPF metric is a bit more granular. Instead of hop counts, the OSPF metric is the sum of interface costs. The cost assigned to an interface is an inverse function of the bandwidth of the interfaces. This seems to scale well, since routes received on interfaces with higher bandwidths are preferred to interfaces with lower bandwidth.

EIGRP uses a combination of four different features to determine its metric. These features are:

  1. Bandwidth—Yes, EIGRP uses bandwidth in its metric calculation. But it uses it in a different manner. For EIGRP metric calculation, the lowest bandwidth is always used. So, as topology information is exchanged from one neighbor to the other, the lowest bandwidth is always selected in a recursive manner (the recipient compares the bandwidth received to the bandwidth of the interface on which it received it and uses the lower one to compute the metric). This makes sense, because the link with the lowest bandwidth in a network path is usually the one that has the highest probability of causing congestion when traffic is being sent. Simply put, a chain is only as strong as its weakest link.
  2. Delay—EIGRP also uses interface delays to calculate the metric of the interface. After capacity issues, the next greatest network constraint is latency. In fact, many times sensitive applications (such as VOIP) will not work in environments with high latency (even if there is sufficient bandwidth to support the applications). This is why the delay of the link is incorporated into EIGRP’s metric calculation. So which delay value does EIGRP use? Lowest? Highest? The answer is both! In EIGRP, the delay used in computation is actually the sum of all the delays of the link.
  3. Load—This is a measure of the utilization of the interface. It is not considered in the EIGRP metric calculation by default, but you can include it into the metric calculation by changing the default values (more about that later).
  4. Reliability—The reliability is a value between 0 and 255 that shows the “quality” of the interface. Usually, interfaces have a reliability value of 255/255. This shows that the interface is stable and there are no errors on the interface. You can configure EIGRP to take the reliability of a link into account when computing the metric of routes received on that link (it is not turned on by default). Personally, I think that links with reliability less than 255 should be avoided altogether, if possible.

Where does EIGRP get all these values mentioned above? These are all physical characteristics of an interface. If you do a “Show Interface” command, you should see the values of these physical attributes in the output. Here is the output of showing the interface on a Fast Ethernet link:

Here we can see that the bandwidth is 100Mb, delay is 1000micro seconds, reliability is 255/255, and txload and rxload are 1/255. Similarly, if we check this on a serial link, we will see:

In this case, we can see that the bandwidth is now 1.54Mb and delay is 20000 microseconds, while the reliability and load values are still the same as the Fast Ethernet link.

Note: A lot of people mistakenly assume that MTU is one of the attributes used in determining the EIGRP metric. This misconception comes from the fact that we have five K values and so we should have five attributes. This is false, as you will see in the next section.

Tying It All Together—K Values

We have established that EIGRP uses four attributes to determine its metric. So how does it determine its metric from these values? It uses the metric computation formula below:

metric = [K1 * bandwidth + (K2 * bandwidth) / (256 – load) + K3 * delay] * [K5 / (reliability + K4)]

In this formula, bandwidth is 256 * 107/minimum bandwidth in the path (expressed in kbits), while delay is 256 * sum of all the delays in a link (expressed in 10 microseconds) in the network path.

These K values are constant values (they can be set between 0 and 255). The default values in EIGRP are K1 = 1, K2 =0, K3=1, K4=0, and K5=0.

If we simplify the formula using these default values, we have:

metric = [1 * bandwidth + (0) / (256 – load) + 1 * delay] * [0 / (reliability + 0)]

= bandwidth + delay * 0

Ideally, this should be zero, but there is a caveat here. The EIGRP metric ignores the reliability section when K5 = 0. So, when K5 =0, the EIGRP formula becomes:

metric = [K1 * bandwidth + (K2 * bandwidth) / (256 – load) + K3 * delay]

Substituting default values for K1 (1), K2 (0), and K3 (1) gives us:

Metric = bandwidth + delay. And this can be further expanded to mean:

Metric = 256 * [ 107/bandwidth (in kbits) + delay (in 10s of microseconds) ]

Sounds confusing, right? Okay, let’s look at this on a real world network. Assume we have a network connected like this:

Let’s take a look at R2’s EIGRP topology table and see the properties of the subnet:

The route is advertised from R2 with a metric of 2169856, which is computed from its serial link. This uses a bandwidth of 1544 kbit and a delay of 20000 microseconds. If we plug this into our formula, we have:

256*(107/1544+2000) <– Notice we use 2000 because delay is in 10s of microseconds

= 256 * (6476 + 2000)

= 2169856

It gets more interesting when we check on R2.

Here we can see that the composite metric is 2195456. We can also see that the bandwidth is 1544 Kbit (this is the minimum bandwidth in the path) and the delay is 21000, which is the sum of the delays of the two links.

Applying the formula again, we have:

Metric = 256 * (107/1544 + 2100)

= 256 * (6476 + 2100)

= 2195456

Now the numbers are beginning to make more sense. And we can see why they look so large. This is even more important when we begin to examine the feasibility conditions for selecting feasible successor routes in the EIGRP topology table.

Modifying K Values

We have seen how the default K values impact the calculation of the metric. So how do we change these values from the default? There are two things to keep in mind when doing this. First is that you should not change these unless you absolutely have to, because the default values work in over 85% of EIGRP scenarios. The second is that you need to change these values across the entire autonomous system so that you can have consistent metric calculations across the AS. With that in mind, here is how you do change the values:

R2(config)#router eigrp 1
R2(config-router)#metric weights 0 1 0 1 0 0

You use the metric weights command and you supply six integer values. The first will always be zero (TOS value) and the next five values will be the values of K1 through K5. The example above sets the values to the default, so no change is made here.


EIGRP is a unique routing protocol because it seems to combine the great features of both distant vector and link state routing protocols. The composite metric allows multiple features to be taken into consideration when computing the metric, but this also makes it more difficult to understand. In this article, we have seen the elements of the composite metric and how the K values impact these values. We also used this understanding to demystify the values we see on real routers when we configure EIGRP.

Thanks again for reading and I hope you found this article useful. As usual, if you have any questions or comments, please use the comments section. If you have other subjects that you would like to learn about, do not hesitate to drop a comment about this.

I am looking forward to writing the next article. Until then, keep building reliable networks.