EIGRP Metric Calculation

Home Lab, Routing

If you’ve worked with or studied EIGRP, you’ve probably seen that scary formula with the K values that EIGRP uses to calculate routing metrics. It turns out that if you’re using the default K values so that only bandwidth and delay are being considered, the math involved isn’t that bad. In this article we’ll explore “classic” and wide metric EIGRP calculations using the default K values, the RIB scaling value for wide metrics, and a hidden command in Cisco IOS.

Demo Network

For this article, we’ll focus on the triangle of routers shown below. This is part of a larger EIGRP lab I’ve been working on, but 3 routers will suffice for looking at the metric formulas. The links have IP addresses where the 3rd octet represents the interconnected routers, and the last octet represents the router number. Each router has a loopback where all 4 octets are the router number. For instance, R4 G0/1 is 172.16.45.4/24, R5 G0/1 is 172.16.45.5/24, and R5s loopback is 5.5.5.5/32.

“Classic” Metrics

There are a lot of excellent resources that explain the EIGRP K values, their configuration, and the EIGRP composite metric formula. If you’re not familiar with these and general EIGRP operation, I encourage you to stop reading and familiarize yourself with those topics before continuing. This article is not a comprehensive resource on EIGRP.

R4, R5, and R7 are running “classic” EIGRP in autonomous system 33. Let’s start by checking the EIGRP topology table on R7 to see what information it knows about on how to reach R5s loopback, 5.5.5.5/32. The output below shows that R7 has one successor route to 5.5.5.5 with a feasible distance (FD) of 130816. Let’s explore how R7 came up with 130816. 

R7#show ip eigrp topology 5.5.5.5/32
EIGRP-IPv4 Topology Entry for AS(33)/ID(7.7.7.7) for 5.5.5.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 130816
  Descriptor Blocks:
  172.16.57.5 (GigabitEthernet0/2), from 172.16.57.5, Send flag is 0x0
      Composite metric is (130816/128256), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 5010 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 5.5.5.5
  172.16.47.4 (GigabitEthernet0/1), from 172.16.47.4, Send flag is 0x0
      Composite metric is (131072/130816), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 5020 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 5.5.5.5

As mentioned earlier, this network uses the default K values so only minimum path bandwidth and cumulative path delay are used to calculate the EIGRP metric. The output above tells us that the topology table entry with FD 130816 has a minimum path bandwidth of 1000000 Kbps and a cumulative path delay of 5010 microseconds. The hop count is 1, so we know that this route is via R7s G0/2 interface. Before we get mathematical, let’s see where these values came from.

The output below shows that G0/2 has bandwidth of 1000000 Kbps (aka 1 Gbps) and delay (DLY) of 10 microseconds (usec). Where is the other 5000 microseconds of delay coming from?

R7#show interfaces gigabitEthernet 0/2 | include DLY
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

Up on R5, we can see that it’s loopback 1 interface has bandwidth 8000000 Kbps and 5000 microseconds of delay. 5000 usec loopback delay + 10 usec delay of the Gigabit link to R7 gives us the 5010 microseconds delay we saw in R7s topology table. Recall that the formula only considers the interface with the lowest bandwidth along the path, so our minimum bandwidth in this example is the gigabit link connecting the routers.

R5#show interfaces loopback 1 | include Internet|DLY
  Internet address is 5.5.5.5/32
  MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,

Now that we’ve seen the source of these values, we can get mathematical. By plugging in these values into the formula shown, we come up with metric 130,816. This is the FD we saw in the topology table earlier. The original formula used by IGRP did not have the 256 multiplier. EIGRP added this to provide greater metric resolution. Later we’ll see that wide metrics increased this further.

Minimum path bandwidth = 1,000,000 Kbps
Cumulative path delay = 5010 microseconds
Metric = 256 * (10^7 / Min. Bandwidth + Cumulative Delay / 10)
130,816 = (10^7 / 1,000,000 + 5010 / 10)

Wide Metrics

Cisco IOS has two different “modes” of EIGRP. There is “classic” mode and named mode. Classic mode is configured under configuration statement “router eigrp AS#”. Named mode is configured under “router eigrp Virtual Instance Name”. It’s not immediately obvious, but “classic” mode that we saw earlier uses 32-bit metrics and measures delay in microseconds. This limitation causes 10Gbps and higher links to have the same metric. Named mode uses “wide” metrics that are 64-bit, allowing metric scaling up to roughly 4.2 Terabits per second. Named mode measures delay in picoseconds, providing better resolution.

I’ll start by reconfiguring R4, R5, and R7 for EIGRP named mode to enable wide metrics. Fortunately, Cisco makes this conversion easy with the “eigrp upgrade-cli” command. I’ll show the before and after of the running configuration so we can see the difference. I used virtual instance name EIGRP_LAB, but this is locally significant and does not have to match between routers.

Classic EIGRP Configuration:

R5#show running-config | section router eigrp
router eigrp 33
 network 5.5.5.5 0.0.0.0
 network 172.16.0.0
R5#

Conversion to Named Mode: 

R5#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
R5(config)#router eigrp 33
R5(config-router)#eigrp upgrade-cli EIGRP_LAB
Configuration will be converted from router eigrp 33 to router eigrp EIGRP_LAB.
Are you sure you want to proceed? ? [yes/no]: yes
R5(config)#
*Mar 27 16:11:04.100: EIGRP: Conversion of router eigrp 33 to router eigrp EIGRP_LAB - Completed.
R5(config)#
*Mar 27 16:11:14.099: %DUAL-5-NBRCHANGE: EIGRP-IPv4 33: Neighbor 172.16.57.7 (GigabitEthernet0/0) is resync: route configuration changed
*Mar 27 16:11:14.100: %DUAL-5-NBRCHANGE: EIGRP-IPv4 33: Neighbor 172.16.45.4 (GigabitEthernet0/1) is resync: route configuration changed
*Mar 27 16:11:14.100: %DUAL-5-NBRCHANGE: EIGRP-IPv4 33: Neighbor 172.16.25.2 (GigabitEthernet0/3) is resync: route configuration changed
*Mar 27 16:11:14.101: %DUAL-5-NBRCHANGE: EIGRP-IPv4 33: Neighbor 172.16.35.3 (GigabitEthernet0/2) is resync: route configuration changed

Named Mode Configuration:

R5#show running-config | section router eigrp
router eigrp EIGRP_LAB
 !
 address-family ipv4 unicast autonomous-system 33
  !
  topology base
  exit-af-topology
  network 5.5.5.5 0.0.0.0
  network 172.16.0.0
 exit-address-family
R5#

Now that all 3 routers are configured for named mode, we can check out the 64-bit wide metrics. Let’s look at R7’s topology table for R5s loopback again. For variety, I’ll use the newer address-family command. The old command used previously still works and displays the same output. 

R7#show eigrp address-family ipv4 topology 5.5.5.5/32
EIGRP-IPv4 VR(EIGRP_LAB) Topology Entry for AS(33)/ID(7.7.7.7) for 5.5.5.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1392640, RIB is 10880
  Descriptor Blocks:
  172.16.57.5 (GigabitEthernet0/2), from 172.16.57.5, Send flag is 0x0
      Composite metric is (1392640/163840), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 11250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 5.5.5.5
  172.16.47.4 (GigabitEthernet0/1), from 172.16.47.4, Send flag is 0x0
      Composite metric is (2048000/1392640), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 21250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 5.5.5.5

This time we see that the successor route via G0/2 has a feasible distance of 1392640. The minimum bandwidth from the classic mode example is unchanged, but we now see delay in picoseconds.

The formula used to come up with 1392640 is:

Minimum path bandwidth = 1000000 Kbps

Cumulative path delay = 21250000 picoseconds

Metric = ((65,536 * 10,000,000 / Min. Bandwidth) + ((65,536 * Delay) / 1,000,000)

1,392,640 = ((65,536 * 10,000,000 / 1,000,000) + ((65,536 * 21250000) / 1,000,000)

If we scroll up to check the result, we see that 1,392,640 is the FD in the topology table.

Wide Metric RIB Scaling

Observant readers might have noticed a difference in the EIGRP topology table for the wide metric example. On the second line of the output, values are printed for the Feasible Distance (FD) and the RIB value. Let’s see what that’s about. 

R7#show eigrp address-family ipv4 topology 5.5.5.5/32
EIGRP-IPv4 VR(EIGRP_LAB) Topology Entry for AS(33)/ID(7.7.7.7) for 5.5.5.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1392640, RIB is 10880
  Descriptor Blocks:
  172.16.57.5 (GigabitEthernet0/2), from 172.16.57.5, Send flag is 0x0
      Composite metric is (1392640/163840), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 11250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 5.5.5.5
		
		~ lines omitted for brevity ~

Earlier it was stated that wide metrics are 64-bit. However, the Cisco IOS routing table (or RIB) can only handle 32-bit metric values. This means that EIGRP wide metrics might be a larger value than the RIB can store. To solve this problem, EIGRP wide metrics implement a RIB scaling value. The solution is to simply divide the wide metric FD by the RIB scale value. The default is 128 and is configurable. The routing table entry confirms that the route metric in the RIB is 10,880.

RIB = Feasible Distance / Rib Scale Value.
10,880 = 1392640 / 128 

R7#show ip route 5.5.5.5 255.255.255.255
Routing entry for 5.5.5.5/32
  Known via "eigrp 33", distance 90, metric 10880, type internal
  Redistributing via eigrp 33
  Last update from 172.16.57.5 on GigabitEthernet0/2, 01:00:07 ago
  Routing Descriptor Blocks:
  * 172.16.57.5, from 172.16.57.5, 01:00:07 ago, via GigabitEthernet0/2
      Route metric is 10880, traffic share count is 1
      Total delay is 12 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

We can see the default RIB scale value and serval other good-to-know default parameters with “show running-config all”, show below. 

R7#show running-config all | section eigrp
router eigrp EIGRP_LAB
 no shutdown
 !
 address-family ipv4 unicast autonomous-system 33
  !
  af-interface default
   no shutdown
   bandwidth-percent 50
   test-bandwidth 0
   test-delay 0
   no dampening-change
   no dampening-interval
   hello-interval 5
   hold-time 15
   add-path 0
   no passive-interface
   split-horizon
  no stub-site wan-interface
  exit-af-interface
  !
  topology base
   no cts propagate sgt
   metric maximum-hops 100
   variance 1
   traffic-share balanced
   timers active-time 3
   eigrp event-log-size 500
   distance eigrp 90 170
   no auto-summary
   !
   topo-interface default
   no redistribute maximum-prefix
  exit-af-topology
  timers graceful-restart purge-time 240
  network 7.7.7.7 0.0.0.0
  network 172.16.0.0
  metric rib-scale 128
  metric version 64bit
  metric weights 0 1 0 1 0 0 0
  eigrp log-neighbor-changes
  eigrp log-neighbor-warnings 10
  no shutdown
  no soft-sia
 exit-address-family
monitor event-trace eigrp perf-events rate-limiting 1
R7#

Below is an example of modifying the RIB scale value. Legal values are between 1-255. I chose 1 for the demo because the FD we’re examining is small enough to fit in the 32-bit RIB entry.

R7(config)#router eigrp EIGRP_LAB
R7(config-router)#address-family ipv4 unicast autonomous-system 33
R7(config-router-af)#metric rib-scale ?
  <1-255>  Rib scale

R7(config-router-af)#metric rib-scale 1

The topology table RIB value now matches the FD.

R7#show eigrp address-family ipv4 topology 5.5.5.5/32
EIGRP-IPv4 VR(EIGRP_LAB) Topology Entry for AS(33)/ID(7.7.7.7) for 5.5.5.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1392640, RIB is 1392640
  Descriptor Blocks:
  172.16.57.5 (GigabitEthernet0/2), from 172.16.57.5, Send flag is 0x0
      Composite metric is (1392640/163840), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 11250000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 5.5.5.5
		
		~lines omitted for brevity~

The Hidden Command

The “show running-config all” output earlier in the article contained “metric version 64bit”. This isn’t too surprising considering that we now know that named mode uses 64-bit metrics for supporting high bandwidth links. Is it possible to use 32-bit metrics in named mode? Cisco IOS supports it, but the command is hidden. Let’s dig deeper.

As shown below, context sensitive help does not display a command to change the metric version. 

R7#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#router eigrp EIGRP_LAB
R7(config-router)#address-family ipv4 unicast autonomous-system 33
R7(config-router-af)#metric ?
  rib-scale  set scaling value for rib installation
  weights    Modify address-family metric coefficients

R7(config-router-af)#metric

Despite there being no obvious sign that the command exists, the CLI will accept configuration of 32-bit metrics in named mode. I made this change on R4, R5, and R7.

R7(config-router-af)#metric version 32bit
R7(config-router-af)#end
R7#
*Mar 27 17:27:40.701: %SYS-5-CONFIG_I: Configured from console by console
R7#
*Mar 27 17:27:48.121: %DUAL-5-NBRCHANGE: EIGRP-IPv4 33: Neighbor 172.16.57.5 (GigabitEthernet0/2) is resync: route configuration changed
*Mar 27 17:27:48.122: %DUAL-5-NBRCHANGE: EIGRP-IPv4 33: Neighbor 172.16.47.4 (GigabitEthernet0/1) is resync: route configuration changed
*Mar 27 17:27:48.122: %DUAL-5-NBRCHANGE: EIGRP-IPv4 33: Neighbor 172.16.78.8 (GigabitEthernet0/0) is resync: route configuration changed
R7#

If we view the topology table entry again for 5.5.5.5/32 we’ll find that there is no longer a separate RIB value, the FD and RD values changed, and delay is again in microseconds. This gives us the same metric as we saw in classic mode. The next time you lab EIGRP, I encourage you to repeat this experiment and start by only reverting the router in position of R7 back to 32-bit metrics. After making the change, notice the FD value and try to justify it. With R4 and R5 still using 64-bit metrics and R7 using 32-bit metrics, you should see a different value than shown below. 

R7#show eigrp address-family ipv4 topology 5.5.5.5/32
EIGRP-IPv4 VR(EIGRP_LAB) Topology Entry for AS(33)/ID(7.7.7.7) for 5.5.5.5/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 130816
  Descriptor Blocks:
  172.16.57.5 (GigabitEthernet0/2), from 172.16.57.5, Send flag is 0x0
      Composite metric is (130816/128256), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 5010 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 5.5.5.5
  172.16.47.4 (GigabitEthernet0/1), from 172.16.47.4, Send flag is 0x0
      Composite metric is (131072/130816), route is Internal
      Vector metric:
        Minimum bandwidth is 1000000 Kbit
        Total delay is 5020 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 5.5.5.5