Classic metrics and wide metrics

Classic metrics and wide metrics

Classic Metric

It is a (32bits) * 256

EIGRP uses composite metric (K values) to calculate the metric for the best path. EIGRP uses composite metric

General formula.

Because the default K1,K3 = 1 and K2,K4,K5 = 0. The Default formula is show below.

K1 = Bandwidth

K2 = Load

K3 = Delay

K4 = Reliability

K5 = MTU

Metric = (k1*BW + k3*DLY) * 256

What is BW? = 10^7/worst bandwidth along the path in Kbps

what is DLY? = The sum of all delays in (microsec)/10

Below is the final formula.

The problem of classic metric is that after 1G, all the metric is considered the same.

metric 1GB = 2560 = 10 microseconds

           10GB = 256 = 10 microseconds

           40GB = 256 = 10 microseconds

           100GB = 256 = 10 microseconds

To better understand the metric calculation, we will analyze the path to 4.4.4.4 network, from R1. We will change the topology to better understand the calculation. So, the connection between R1 <-> R2 and R3 <->R4 will have the BW reduced to 100Mbps all other interfaces will remain 1G. Note that we want to influence the traffic from R1, so, we only consider the outgoing interfaces from R1 and R3

R1

R1(config)#interface gigabitEthernet 1

R1(config-if)#bandwidth 100000

R3

R3(config)#interface gigabitEthernet 1

R3(config-if)#bandwidth 100000

From R1's we have two paths to reach 4.4.4.4, as we can see below. One path is towards R2 and another is towards R3.

Data we have from the output, to help calculate the metric.

1 - The metric 154112. This the value we should have after final calculation.

2 - Total Delay = 5020

3 - Minimum bandwidth = 100000 Kbps

R1#sho ip route 4.4.4.4

Routing entry for 4.4.4.4/32

  Known via "eigrp 1", distance 90, metric 154112, type internal

  Redistributing via eigrp 1

  Last update from 10.1.2.2 on GigabitEthernet1, 00:03:58 ago

  Routing Descriptor Blocks:

  * 10.1.3.3, from 10.1.3.3, 00:03:58 ago, via GigabitEthernet2

      Route metric is 154112, traffic share count is 1

      Total delay is 5020 microseconds, minimum bandwidth is 100000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 2

    10.1.2.2, from 10.1.2.2, 00:03:58 ago, via GigabitEthernet1

      Route metric is 154112, traffic share count is 1

      Total delay is 5020 microseconds, minimum bandwidth is 100000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 1/255, Hops 2

Using the formula, we have.

Metric = (10^7/100000 + 5020/10 ) * 256

            = (10.000.000/100000 + 5020/10) * 256

            = (100 + 502) * 256

            = (602) * 256

            = 154112

Now, let's consider that we do not have information provided by the show route command, and we have to look into the physical topology.

BW - For BW by looking at the topology and also because we know, we can tell that the worse BW is 100000 Kbps.

DLY - for delay we have to check each outgoing interface, including the destination subnet, as we can see below.

First, we analyze the outgoing interfaces in R1. Since both paths are used to reach the destination and have same value, only one will be shown, because the steps and values are the same.

R1#sho int g1 | in DLY

  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 10 usec,

DLY = 10

Next, we analyze the outgoing interface of the next router (R2).

R2#sho int g2 | in DLY

  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

DLY = 10

Last, we analyze the outgoing interface of the next router (R4).

R4#sho int lo0 | in DLY

  MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,

DLY = 5000

So, we have 10 + 10 + 5000 and the final result is 5020. This is the sum of delays we saw in the route to 4.4.4.4.

The K values configured on a router can be viewed by issuing the show ip protocols command.

Example from R3.

R3#sh ip protocols | in K

    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0

The K values can be changed using the metric wight command under EIGRP, as you can see below. Note that K values should match between neighbors, if not, the neighborship will fail.

R3#conf t

R3(config)#router eigrp 1

R3(config-router)#metric weights 0 0 0 1 0 0

IP protocol information after changing the K values.

R3#sh ip prot | in K

    Metric weight K1=0, K2=0, K3=1, K4=0, K5=0

Wide Metric

• EIGRP wide metric moves from a 256 (32 bits) to wide metric (64 bits).
• The wide metric is enabled by default.
• BW calculation is now referred to throughput
• Delay calculation is now referred to as latency.
• Overall metric has not changed (Throughput + Delay)

EIGRP_BANDWIDTH  = 10,000,000

EIGRP_DELAY_PICO = 1,000,000

EIGRP_CLASSIC_SCALE = 256

EIGRP_WIDE_SCALE = 65536

Metric rib-scale 128

EIGRP composite cost metric = 256*(Scaled Bandwidth + Scaled Delay)

Throughput (Scaled Bandwidth1) = K1 * (10^7 * EIGRP Wide Scale) / BW kbps

                       (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE)
 Max-Throughput = K1 * ------------------------------------
                            Interface Bandwidth (kbps)

Latency (Scaled Delay) = K3 * (Delay * EIGRP Wide scale) / EIGRP delay in pico.

                  Delay * EIGRP_WIDE_SCALE
Latency = K3 *   --------------------------
                      EIGRP_DELAY_PICO

K1 = Bandwidth

K2 = Load

K3 = Delay

K4 = Reliability

K5 = MTU

K6 = Jitter and energy

To better understand how the calculation for wide metric works, let's look into the topology which has now been migrated to named mode for wide metrics.

This time we will analyze the path from R1 to 10.2.4.0/24. Below is the ip route and topology table.

1 - Check the route and the computed metric.

R1#sho ip route | be 10.2.4

D        10.2.4.0/24 [90/15360] via 10.1.2.2, 00:14:24, GigabitEthernet1

Only once path exist and the computed metric is 15360

2 - Check the FD

R1#sho ip eigrp topology | be 10.2.4

P 10.2.4.0/24, 1 successors, FD is 1966180

        via 10.1.2.2 (1966180/1310820), GigabitEthernet1

        via 10.1.3.3 (2621440/1966080), GigabitEthernet2, serno 29

3 - Check the total delay in picoseconds

R1#sho ip eigrp topology 10.2.4.0/24

EIGRP-IPv4 VR(CORE) Topology Entry for AS(1)/ID(192.1.3.1) for 10.2.4.0/24

  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1966180, RIB is 15360

  Descriptor Blocks:

  10.1.2.2 (GigabitEthernet1), from 10.1.2.2, Send flag is 0x0

      Composite metric is (1966180/1310820), route is Internal

      Vector metric:

        Minimum bandwidth is 1000000 Kbit

        Total delay is 20001526 picoseconds

        Reliability is 255/255

        Load is 1/255

        Minimum MTU is 1500

        Hop count is 1

        Originating router is 192.2.3.1

4 - Check the metric rib-scale

R1#sho ip protocols | in 128

    Metric rib-scale 128

One successor and feasible successor exists. As we can see, the computed metric from the routing table and the FD are not equal as it is with classic metric.

Details collected from the output.

Computed metric = 15360

FD = 1966180

Total delay = 20001526 picoseconds

Metric rib-scale = 128

FD is way longer than the Computed metric in the routing table. In the classic metric these values are equal.

Scaled bandwidth = 65,536 *10,000,000 / 1,000,000 = 655,360

Scaled delay = 65,536 * 20,001,526 / 1,000,000 = 1,310,820

Composite metric: 655,360 + 1,310,820 = 1,966,180

The final value is 1,966,180 and it equal to que FD we saw from the output above in the topology table.

To find the computed metric we have in the routing table, we divide the composite metric by the metric rib-scale (1,966,180 / 128 = 15360 )

The metric-rib value can be changed under named EIGRP configuration, as shown below.

R1(config)#router eigrp CORE

R1(config-router)#address-family ipv4 autonomous-system 1

R1(config-router-af)#metric rib-scale ?

  <1-255>  Rib scale