EIGRP Wide Metrics

[lagapidis (Lazarus Agapidis)]

Hello Christopher

Unlike OSPF, EIGRP doesn’t provide a full picture of the whole network topology to each router. But the question remains, how does a particular EIGRP router “know” about the cost of the whole path to the destination if it doesn’t have this information? Well, take a look at this network topology with the EIGRP metrics noted for each link:

When R4 advertises the destination network to R3, it says “my distance to the Destination is 5”. That’s the advertised distance. When R3 receives that information, it will add a value of 4 to that metric, because it knows that the cost of its link to R4 is 4. So when R3 records the metric to the destination, it will say 5+4=9.

When R3 advertises that network and its metric to R2, it will say, “my distance to the Destination is 9”. R2 will receive that and it will add a value of 9 to that, which is the cost of the local link to R3. So when R2 records the metric to the destination via R3, it will say 9+9=18.

So you see, each EIGRP router will simply add to the advertised metric the cost of the link through which the path was learned, thus obtaining a cumulative cost to the destination, without the need to “know” the topology of the whole network. Does that make sense?

I hope this has been helpful!

Laz

[rivc1982 (Christopher R)]

Somewhat. I guess i have to presume that instead of R2 knowing that the AD(or BW) is is just simply 9, somehow it must be provided with the individual AD’s (or BW’s) along the path because it is a requirement for end to end K1 calculation. Maybe only the lowest bandwidth info is passed along.

Wish that part was spelled out somewh
ere.

[lagapidis (Lazarus Agapidis)]

Hello Christopher

Let’s take a deeper look into this one. Each EIGRP router when advertising a network, will use the EIGRP formula to determine that metric.

1. So R4 has the destination as directly connected. Using the formula, and taking into account the bandwidth of the link, it measures a metric of 5. R4, in its update to R3, will send that metric which is the advertised distance.
2. R4 will receive that information, and will rerun the EIGRP formula, and will take into account the characteristics of its link to R4. Based on the formula (including the bandwidth of the link), it generates a metric of 9 for itself to the destination. It shares that with R2.
3. R2 receives the advertised distance of 9 from R3, and runs the EIGRP formula and takes into account the link between R2 and R3. The result is a metric of 18.

Now this is a simplistic description. In truth we’re not just summing costs, but we’re using the EIGRP formula to determine the cost. The outcome of the formula itself that R4 originally generates has embedded in it, the BW of the link to the destination. Similarly, R3, uses this advertised metric and recalculates the cost using the formula. R3 will take into account the bandwidth of the link to R4 in the metric it sends to R2. So R2, although it doesn’t explicitly receive the information of the lowest bandwidth link to the destination, the advertised metric itself has that information indirectly included in it. Does that make sense?

I hope this has been helpful!

Laz

[samirkhair (Samir K)]

Hi, I cant seem to make your equation work on a 10GB interface. The result is wrong by a factor of 10:

The interface:

R5#sh ip eigrp topology 155.1.5.0/24
EIGRP-IPv4 VR(CCIE) Topology Entry for AS(1)/ID(150.1.5.5) for 155.1.5.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 720896
Descriptor Blocks:
0.0.0.0 (GigabitEthernet0/1.5), from Connected, Send flag is 0x0
Composite metric is (720896/0), route is Internal
Vector metric:
Minimum bandwidth is 10000000 Kbit
Total delay is 10000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 0
Originating router is 150.1.5.5

Minimum Throughput = (10^7 * 65536)/Bw)

Total Latency = (10^7 * 65536/10) / Bandwidth

Where Bandwidth is kbps.

Substitute bandwidth into formula:

Minimum Throughput = (10^7 * 65536)/10^7) = 65536
Total Latency = (10^7 * 65536/10) / 10^7 = 6553.6

EIGRP Composite Cost Metric = (K1 * Minimum Throughput) + (K3 * Total Latency)

EIGRP Composite Cost Metric = 65536 + 6553.6 = 72,089.6

Which is 10x smaller that the composite metric calculated by EIGRP.

Am I missing something?

Thanks.

Sam

FYI… I have been experimenting and it seems that the metric calculation is the same regardless of the interface speed being above or below 1GB. I got from formulae from EIGRP rfc7868, section 5.6.3.1:

Minimum Throughput = (10^7 * 65536)/Bw
Total Latency = ((Total delay in Picoseconds)/10^6) *65536

For the above interface:

Minimum Throughput = (10^7 * 65536)/10^7 = 65536
Total Latency = (10^7/10^6) *65536 = 655360

EIGRP Composite Cost Metric = 65536 + 655360 = 720896

Which is correct. I tried changing the BW to other values above 1GB and they also worked.

Aside from the above, I have a second question.

In the notes it says wide metrics supports a maximum interface speed of 4.2 terrabits. But the formula:

Minimum Throughput = (10^7 * 65536)/Bw)

indicates that the Bw can be up to 65536 * 10^7, which is 655.36 terrabits.

Or am I misunderstanding?

Thanks again,

Sam.

[roi9098 (Roi Mordecai)]

Hi,

How is the Hop Count value is used in the Wide metric formula?
it was also said that the classic metric formula is using it and I can’t understand how and where

Thanks!

[lagapidis (Lazarus Agapidis)]

Hello Roi

Yes, I can see how the mention of hop count here may be misleading or confusing. EIGRP does not use hop count as a parameter that directly affects the calculated metric. This is true for both classic and wide-metrics EIGRP. However, hop count still plays a role in EIGRP, but it is used differently.

It serves as a limit to prevent routing loops and to control the scale of routing domains. EIGRP has a default maximum hop count limit of 100, which can be configured up to a maximum of 255. This limit ensures that routes with hop counts exceeding this threshold are considered unreachable, thus helping to maintain network stability and manageability. If the hop count exceeds this limit, the route is considered unreachable and is given a metric of infinity (i.e. 4294967295 for classic EIGRP).

What is being stated in the lesson is that this hop count limit is still in effect for EIGRP wide metrics. You can actually see the configured value in the lesson in the output of the show ip protocols | begin eigrp command where it says:

Maximum hopcount 100

I hope this has been helpful!

Laz

[davidilles]

Hello, everyone.

There is one thing that I didn’t quite understand even after finishing ENARSI. In the Classic formula, why exactly do we multiply the result by 256? I’ve read that this pushes the metric from 24 bits (which is what IGRP used) to 32 bitss.

However, I don’t quite understand how the math behind this works. Can’t you just make it so that the EIGRP metric will be represented in 32 bits without having to multiply by 256? How does multiplying by 256 allow for greater metrics?

If you have a value like 1, multiplying it by 256 will just… set it to 256? It feels like you’d just end up with a higher number for no reason at all, and that’s it.

As far as my logic goes, this only gives you a bigger number in the end, but without tweaking the delay and bandwidth values, multiplication by 256 doesn’t seem to… allow for greater metrics than 24-bits?

This probably has to do something with shifting the bits but I don’t quite understand how this all works, could someone please explain it to me?

David

[lagapidis (Lazarus Agapidis)]

Hello David

This is a great question, and it gave me the opportunity to do some research. As you mention, the multiplication by 256 in the EIGRP formula is to ensure backward compatibility with IGRP which has a 24-bit metric. By multiplying by 256 we are converting the 24-bit metric to a 32-bit metric. What the multiplication actually does is it shifts the binary value of the metric to the left by eight positions. So if you have a metric of 5876966 in IGRP for example, that would look like this in 24-bit binary:

010110011010110011100110

Multiply that by 256 and we shift all bits to the left by eight positions, and add zeros at the end like this:

01011001101011001110011000000000

Now the concern remains, by doing so, we don’t increase the granularity of the metric value, since we can only have values divisible by 256. So do those eight zeros at the end ever become no-zero?

Strictly speaking, according to the formula no. So for the most part, the extra bit space doesn’t directly benefit granularity. However, there are some mechanisms that can affect the metric in such a way so that you have a more granular result. These include QoS extensions in EIGRP, as well as the use of EIGRP in DMVPN. In addition, the larger bit space gives room for future enhancements and protocol extensions.

So in most implementations today, these last 8 bits are typically kept at values of 0, but they are available for some specialized uses, as well as future expansion of the protocol.

I hope this has been helpful!

Laz