## Metric Formula

The Enhanced Interior Gateway Routing Protocol, or EIGRP, metric is going to show us some big numbers. It's a 32-bit value. It means it's got a big space to play in. So the number that's in the thousands, that's no big deal. That's chump change, okay, it's chump change. The EIGRP metric, which we call the feasible distance, when we see it in topology tables and the routing table, the EIGRP metric has a very complex formula. We're not showing you the formula, so you memorize it in its mathematical formulaic representation. But we need you to understand the spirit of this functionality and how it plays out. So, let's describe the EIGRP metric and how we can talk about it and think of it in a practical sense.

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

Three words, bandwidth plus delay. It's really what it breaks down to. If you remember, that equation we see, that convoluted metric equal really breaks down to bandwidth plus delay by default, you're set. You're definitely set. Now why does it work out that way? We have K values that are plugged into the equation as well.

Router#show ip protocols | include metric weightEIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0

And as you can see the default K values, K1-1, K2-0, K3-1, K4-0, K5-0. If you plugged in those numbers and you didn't care about the value of bandwidth or load or delay in that equation right now, you just broke everything down to its simplest values, well multiplying by zero, dividing zero, you end up with zero. So essentially in the end, we end up with bandwidth plus delay. We broke it down to its just fundamental components and that's what you want to remember. But now, let's dive into what aspects of bandwidth, what aspects of delay? Well bandwidth, we're really looking at the lowest bandwidth from source to destination. So, let's say, we have four links from source to destination. A 10 gigabits link, a 1 gigabit link, a 100 megabits link and a T1 at 1.544Mbps. In our bandwidth calculation, which one of those is going to be utilized?

So if those links were all one after the other, and I'm trying to calculate the bandwidth for that path, I don't use all four of them. I pick one. And what are you going to pick? If you had to pick one input to the bandwidth formula, would you choose the really high-speed aspect of that path or would you choose the bottleneck - that portion of the network that has less throughput and is going to constrain our traffic? Well, it's really nice that we have a 10 gigabits link and 1 gigabit link and a 100 megabits link on the path. But once we get to that T1 link, that's our bottleneck, and that's going to slow us down and we can only truly be as fast as our slowest link because everything is just going to jam up there and things are going to slow down on us.

Another way to think of it, it's your weakest link. And there's that phrase, a chain is only as strong as its what? What is that? Weakest link? So we sometimes refer to it as the weakest link bandwidth. It helps us understand that. Think of it as a chain, okay? And then, wait a minute, we gave you three words though. So we worked with the first word, weakest link bandwidth, second one was plus, addition, delay. How does the delay portion of this calculation play out?

Well the delay is accumulative. So we factor in the delay of all the links from source to destination, we add it all together and it's put into the overall calculation. And then we can see in the formula that it's multiplied by 256. All right, but the major components, bandwidth plus delay, that's really what we want to focus on here.

Now you might be thinking, I really want to tune my operation. I want to make it really accurate. Well EIGRP originally when it came out, they were thinking that we wanted to factor in things like stability of a network and current utilization of the network. And so, they gave us two additional metric components that are turned on and off with what are called K values. These K values can turn off reliability or on, and turn on and off load, now they're off by default. Only ones that are on by default are bandwidth and delay, which have a metric way of one, which says it's on at the equal proportion, the default proportion. And a K value can say zero, which turns it off or it can be really high, which makes it more factored. The problem with this though, is if you think to yourself, I want to turn on reliability, don't even think about it. Don't even think about turning on load either. Why is that?

Well we can see that Cisco recommends that it's not recommended that you do it. But why, from a real world perspective, why leave those alone? Well reliability and load, those values will change based on intervals for the particular interface. So if the reliability numbers and the load numbers are constantly being updated for those interfaces, what is that going to do to EIGRP and the metric that will have to be advertised? It's constantly going to change. So reliability or loads being updated every five minutes, well guess what? Your metric changes every five minutes and you know what's going to happen? You're going to have to advertise that out and then advertise it out. And now, that's just a waste. It's not worth it. And if you're reconverging to different pathways, during a problem where there's instability and you got dropped traffic, how are you going to even know which path your packets were taking at that moment and time? This is a big old mess. So bandwidth and delay, weakest link bandwidth and a small accumulative value added up value, that is our delay, which is based on the time that it takes to encapsulate and serialize bits into that media.

## Metric Values

Where does EIGRP find the information related to bandwidth, delay, reliability, and load? Interface level. So if we do show interfaces, every single one of our interfaces has default inputs to the five values. Now when I say five, MTU is also factored in. We didn't really talk about it there. And that works out just to be a tie break.

Router#show interfaces serial 0/0/0Serial0/0/0 is up, line protocol is downHardware is GT96K SerialDescription: Backup LinkMTU 1500 bytes, BW 1544 Kbit/sec, DLY 20000 usec,reliability 255/255, txload 1/255, rxload 1/255

We can see bandwidth, that's the BW. The delay, DLY. Wait a minute, how is it measured? Now I wanted to give you a hint of how this is measured. Cisco gives us an input here and their engineers precalculated this measurement which is in U-seconds (microsecond). U is to replace the **µ** symbol, which is the micron symbol. It has got the very curved M. And so, it's 20000 usec, so what does that work out to? It works out 20 milliseconds. That's not a lot of time. Nor is it going to be impactful in your calculations in a measurable way, in a highly measurable way. It'll tip the scales when we have very, very similar pathways. Otherwise, it's going to be about the same. So these are the two that you can manipulate, by the way. You can manipulate bandwidth, go to the interface level, **bandwidth** command, you should definitely do that for serial links, right? Because what's the default bandwidth on our serial links?

1.544 megabits per second or 1544 Kbit/sec. And EIGRP uses this number for its bandwidth calculation. So let's say, this was truly a 64K link. Would EIGRP see it as a 64K link right now or a 1.544 megabits per second link? It would see it as 1.544 even though it's truly only 64. So that could really hurt the metric calculation and possibly incur EIGRP to choose a suboptimal path.

You could also tweak the delay if you wanted to. It's rarely going to help you. It's rarely going to be the right thing to do, I'll say that. And then, we can see reliability and load, and reliability 255/255. So it hasn't had a fluctuation in the last few minutes. And loading looks like there's not a lot going on right now. But remember again, we don't want our K values to enable those aspects of the calculation. You want to stick to bandwidth and delay.