Introduction and motivation

I have always felt the EIGRP metric as being really overwhelming. I see values like «2820096» and instead of understanding it, I always end up asking what the hell does that number mean.

For example, in RIP:

R    192.168.0.0/24 [120/3] via 172.16.1.1, 00:00:15, FastEthernet0/0

Just by looking at the metric of «3» I immediately know what is means: there are three steps between the announced network and the router receiving the advertisement. Easy, right? «Understanding the number» makes it easy for me to manage and diagnose it.

In OSPF, the metric (cost) is still not as cumbersome as EIGRP’s. However, in the following example, can you identify what does «66» mean? For you, is it «just a number» that won over another because of its numerical value being lower? How do you know if the number is right or not?

O   192.168.0.0/24 [110/66] via 172.16.1.1, 00:00:82, FastEthernet0/0

The EIGRP metric formula is better, functionally speaking. It is calculated from various components. As a result, it is more complex. Furthermore, the resulting value is bigger. When you try to read the number in the route table, it is no longer obvious.

D   192.168.0.0/24 [90/2820096] via 172.16.1.1, 00:00:12, FastEthernet0/0

So, what does «2820096» mean? Well, it’s pretty simple. Take 2820096 and divide it by / 25600 and you get the estimated travel time in milliseconds: .

The EIGRP metric is an approach to calculating the total travel time. By default, EIGRP calculates the packet travel time like is: take the transmission delay in all hops in the path (the famous «delay» part) and —instead of adding all of the serialization delays— add only that of the bottleneck bandwidth for a 100 Kilobit sample.

The goal of this article is to show you how to mathematically get to that conclusion in the particular case of the default K values. This will allow the article to be much shorter and understandable, because the rest of the terms that compose the complete EIGRP metric are more complex and there is less on-line documentation reference for those. Also, Cisco doesn’t recommend changing the K values by default unless you REALLY know what you are doing.

Besides, we can get our engines started and warmed up for a later article with an analysis for the whole formula, don’t we?

Step 0: Starting to think

To put a «meaning» to this number, I will first ask you: if you designed your own «perfect» routing protocol, what would you use as a metric? What formula do you think would provide the routers with the best and closest to reality information in order to always take the most optimal routing decisions, at all times, and whatever the network circumstance is? It is not an easy question, though it is one that any protocol designer will never be able to escape. Think about this for a moment.

When I asked myself this question, my answer was: I think everybody wants the packets to get to its destination (unmodified, of course) as quickly as possible. I would like all participating routers to know the exact time it will take a packet to get to router B. Travel time should be used as *the* metric. In my «perfect» routing protocol, the metric would be measured in some submultiple of seconds. Even the Internet would be better if this were true, except that it’s way too expensive, complex, and difficult to manually control if done this way (that’s were BGP jumps in).

The EIGRP protocol gives it a shot at this approach.

Quoting complete the EIGRP metric formula, by Cisco

To analyze the default metric behavior I will start by quoting the complete EIGRP metric formula specified by Cisco¹:

where:

• 
  • where is the least bandwidth of all outgoing interfaces on the route to the destination network represented in kilobits.
• 
  • where is the sum of the delays configured on the interfaces, on the route to the destination network, in tens of microseconds. The delay as shown in the show ip eigrp topology or show interface commands is in microseconds, so you must divide by 10 before you use it in this formula. Throughout this paper, we use delay as it is configured and shown on the interface.
• If , the formula reduces to .
• Cisco routers do not perform floating point math, so at each stage in the calculation, you need to round down to the nearest integer to properly calculate the metrics.
• The default values for K are:
  • 
  • 
  • 
  • 
  • 

For default behavior, you can simplify the formula as follows:

I found out that sentence to be a source of confusion for myself. Even the simplified, default-behavior metric formula is expressed in a way that assumes we can add apples and oranges, though this is impossible. Cisco wants us to add «bandwidth» with «delay». So, how do they actually do it? How much is «10 bps + 10 s»?

Step 1: Arranging the mathematical expression in its default K values

Let’s try to state the formula in its default behavior. I will use the following symbols:

• : metric.
• : resulting scaled bandwidth.[/pmath]
• : bandwidth(i), the least bandwidth of all outgoing interfaces on the route to the destination network represented in kilobits.
• : resulting scaled delay.[/pmath]
• : delay(i), the sum of the delays configured on the interfaces, on the route to the destination network, in tens of microseconds.
• : 1000000 (as in 10 Mega-something).

Let’s arrange the formula in a way it really looks like a mathematical equation:

where:

Step 2: moving the «256» out of the way and getting to the original IGRP metric formula

EIGRP metric is 256 times that of IGRP². This is easily provable: as both, B and D are a multiple of 256, we can divide by it. The result is the exact original IGRP formula3. (Though this is also true in the complete formula, please remember we are only working with the particular case of the default metric behavior.)

This means that the EIGRP metric will be always inflated and will be a multiple of 256.

Let’s do the procedure. First, lets get all into one big formula. Let’s replace B and D for their corresponding formulas:

There we can see how the 256 factor is present in the two terms. We could factor it out but for convenience I will divide everything by 256.

The right side is the default metric for IGRP.

Step 3: Unit analysis and T₃

Or put another way: what is the resulting value measured in, is it Kilobits, seconds, hops, packets…?

The last formula from step 2 has the following form:

where:

• (metric)
• 
• 

The terms and must have the same units. Otherwise, addition couldn’t be possible.

The easiest term to analyze is . According to Cisco must be in tens of microsegundos. Therefore:

And thus, units (and therefore the whole M units) must be tens of microseconds, also.

So:

• (time)
• (time)
• (time)

So, given is a delay, the other term and the total metric must be a delay too in the same scale. Remember what I said at the beginning about using travel time as my «perfect» metric for a routing protocol? EIGRP is actually giving it a shot.

Step 4: Analyzing T₁

In step 3 we let be defined as:

And also that must be in tens of microseconds.

We know the units for and , but what are the units for ?

: tens of millibit

How many bits are ?

So finally, is like this:

Just like , also , so means «serialization delay for 100 Kbits under that bandwidth B_min«.

Conclusion and interpretation

D   192.168.0.0/24 [90/2820096] via 172.16.1.1, 00:00:12, FastEthernet1/1

We know that 2820096 is given in and multiplied by 256.

So we take 2820096 / 256 = 11016.

To convert it to instead, divide the metric / 25.6:

Or to milliseconds, divide it by / 25600:

As I said, the EIGRP default metric is an approach to calculating the total travel time. By default, EIGRP calculates the packet travel time like is: take the transmission delay in all hops in the path (the famous «delay» part) and —instead of adding all of the serialization delays— add only that of the bottleneck bandwidth for a 100 Kilobit sample.

References

¹ Cisco Document ID 16406, actualizado: Sep 09, 2005. Enhanced Interior Gateway Routing Protocol: http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml

² IP Routing, by Ravi Malhotra, January 2002. Chapter 4: Enhanced Interior Gateway Routing Protocol (EIGRP) http://oreilly.com/catalog/iprouting/chapter/ch04.html#45434

³ Cisco Document ID 13678, actualizado: Aug 10, 2005. IGRP Metric [IP Routing], http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405c.shtml