# Understanding EIGRP. Part 1: Metric

This is the first post in a series about routing protocol EIGRP.
Today we will deep dive into how metric is calculated in EIGRP classic mode.

EIGRP is a distance-vector routing protocol, but what does it really mean? How does a distance-vector routing protocol differ from link-state?
Distance-vector is also referred to as “routing by rumor”. It means that a router makes its decision based on the metrics reported by his neighbors.

This is unlike a link-state routing protocol where every router in an area (OSPF) or level (IS-IS) knows the whole topology for this area/level and calculates the best path locally using the shortest-path algorithm (Dijkstra). Because routers have the same information, it results in a consistent choice of the best path.

Let’s start by defining several EIGRP terms that will be used throughout this post:

**Reported Distance (RD)** - best metric to the destination from neighbor’s perspective.

**Computed Distance (CD)** - calculated metric to the destination which takes into account reported distance from the neighbor as well as parameters of the interface where an update was received.

Metric in EIGRP is **composite** and calculated from four individual components: minimal bandwidth, cumulative delay, lowest reliability, highest load.

There are also 5 K-values in classic mode that are just coefficients ranging from 0 to 255.

Let’s look on the formula of metric calculation in classic mode:

where

**min_bandwidth**is a minimum bandwidth across the path in kbps,**total_delay**is a cumulative delay across the path in microseconds,**load**is the highest load across the path,**reliability**is the lowest reliability across the path.

If **K5=0**, the formula changes to:

A couple of interesting facts:

- Even though
**minimum MTU**is calculated and included in an update, MTU has absolutely**no effect**on EIGRP metric calculation or path selection. - Change of a load or reliability does not trigger an update in contrast to change of delay or bandwidth.
- K-values must match across the whole EIGRP domain to establish adjacencies and are exchanged only in Hello messages. By default,
**K1=K3=1**and**K2=K4=K5=0**so only bandwidth and delay impact metric calculation.

An interesting question is *“How does EIGRP know about minimum bandwidth or total delay across the path if it routes by rumor?”*

To answer this question the first thing you should know is that in an update EIGRP ** never sends** calculated values (Computed Distance or Reported Distance), it sends only individual metric components.

Let’s look on the topology below:

We have three routers: R1, R2 and R3. On R3 there is a loopback 0 with IP address 10.1.3.3/32. We will analyze the metric to this prefix from all three routers.

I also set bandwidth on R1 e0/0 to 5 Mbps.

Let’s look on Loopback0 interface statistics and parameters:

Bandwidth is **8 Gbps** and delay is **5000 microseconds**.

I have EIGRP enabled already, so let’s look on EIGRP topology table for the prefix 10.1.3.3/32 on R3:

We can see that **Computed Distance** is **128256** and **Reported Distance** is **0**.

The latter one is 0, because this router originated the prefix. Computed distance is calculated from the individual metric components which are listed in the same output.

Let’s calculate the metric manually (I usually use IPython for this purpose):

Bingo! The same value.

**Note:** because division does not give an integer value, I had to use function **int**, which takes only integer part of the value.

The only thing I didn’t explain yet is what the values of individual metric components listed in *show ip eigrp topology* output are. In this case they are the same as loopback interface parameters. So are those values always equal to the interface parameters?

The answer is **no**.

Let’s have a look on R2 topology table:

**Computed Distance** is **409600** and **Reported Distance** is **128256**.

Before we understand how these values were received, let’s take a look on the metric components:

- Minimum
**bandwidth**is**10000**Kbit - Total
**delay**is**6000**microseconds

An interface where an update was received has the following parameters:

Bandwidth is **10000 kbps** and delay is **1000 microseconds**.

The values listed in *show ip eigrp topology* are obtained using the following process:

- Minimum bandwidth: min(8 Gbps, 10 Mbps) = 10 Mbps =
**10000 kbps** - Total delay: 5000 + 1000 =
**6000 microseconds**

If we plug the resulting values into EIGRP formula we should receive Computed Distance **409600**:

Perfect!

I told you already that both Reported Distance and Computed Distance are never sent in EIGRP update. So how does R2 get the value **128256** for Reported Distance?

### EIGRP metric calculation process when an update is received

- EIGRP update contains individual metric components that the neighbor is using to calculate
**Computed Distance** - Receiving router takes those values and plugs them into the formula. Result of this calculation is
**Reported Distance** - Next, EIGRP calculates new values of metric components using old values and values of the interface where an update was received:
- Lowest bandwidth between two:
*min(bw_update, bw_link)* - Sum of delays:
*dly_update + dly_link* - Lowest reliability:
*min(reliability_update, reliability_link)* - Highest load:
*max(reliability_update, reliability_link)*

- Lowest bandwidth between two:
- EIGRP plugs these new values into the formula again and gets
**Computed Distance**

When this router is going to send an update, it will include these new individual components.

To reinforce this knowledge let’s calculate the metric once again for R1 in our topology. R2 sends an update to R1 with these values:

- Bandwidth: 10000 kbps
- Delay: 6000 microseconds
- Reliability: 255
- Load: 1

Interface Ethernet0/0 on R1 has the following parameters:

- Bandwidth: 5000 kbps
- Delay: 1000 microseconds
- Reliability: 255
- Load: 1

Reported Distance should be the same as Computed Distance from R2 perspective: **409600** (calculated above).

Let’s now calculate new metric components and **Computed Distance**:

- Bandwidth:
*min(bw_update, bw_link) = min(10000, 5000) =***5000** - Delay:
*dly_update + dly_link = 6000 + 1000 =***7000** - Reliability:
*min(reliability_update, reliability_link) = min(255, 255) =***255** - Load:
*max(reliability_update, reliability_link) = max(1, 1) =***1**

So RD should be **409600** and CD should be **691200**.

Let’s check:

Great! It wasn’t so hard, was it?

This is it for this post. In the next EIGRP post we will see what Feasible Distance, Successor, Feasible Successor are. Additionally I will show that Feasible Distance may differ from the lowest Computed Distance and how EIGRP may go to Active state even when there is a Feasible Successor.

Useful EIGRP Resources:

- My slidedeck with a quick overview of EIGRP for CCIE R&S
- EIGRP RFC 7868
- Book CCIE R&S 5.0 Official Certification Guide, Volume 1
- Book EIGRP for IP: Basic Operation and Configuration

Thanks for reading! If you liked the post, don’t hesitate to share and subscribe!

Till next time!