Path Metric Calculation
Metric calculation is a critical component for any routing protocol. EIGRP uses multiple factors to calculate the metric for a path. Metric calculation uses bandwidth and delay by default but can include interface load and reliability, too. The formula shown in Figure 2-6 illustrates the EIGRP classic metric formula.
)
Figure 2-6 EIGRP Classic Metric Formula
EIGRP uses K values to define which factors the formula uses and the impact associated with a factor when calculating the metric. A common misconception is that the K values directly apply to bandwidth, load, delay, or reliability; this is not accurate. For example, K1 and K2 both reference bandwidth (BW).
BW represents the slowest link in the path, scaled to a 10 Gbps link (107). Link speed is collected from the configured interface bandwidth on an interface. Delay is the total measure of delay in the path, measured in tens of microseconds (μs).
The EIGRP formula is based on the IGRP metric formula, except the output is multiplied by 256 to change the metric from 24 bits to 32 bits. Taking these definitions into consideration, the formula for EIGRP is shown in Figure 2-7.
)
Figure 2-7 EIGRP Classic Metric Formula with Definitions
By default, K1 and K3 have a value of 1, and K2, K4, and K5 are set to 0. Figure 2-8 places default K values into the formula and shows a streamlined version of the formula.
)
Figure 2-8 EIGRP Classic Metric Formula with Default K Values
The EIGRP update packet includes path attributes associated with each prefix. The EIGRP path attributes can include hop count, cumulative delay, minimum bandwidth link speed, and RD. The attributes are updated each hop along the way, allowing each router to independently identify the shortest path.
Figure 2-9 shows the information in the EIGRP update packets for the 10.1.1.0/24 prefix propagating through the autonomous system. Notice that the hop count increments, minimum bandwidth decreases, total delay increases, and the RD changes with each EIGRP update.
)
Figure 2-9 EIGRP Attribute Propagation
Table 2-7 shows some of the common network types, link speeds, delay, and EIGRP metric, using the streamlined formula from Figure 2-7.
Table 2-7 Default EIGRP Interface Metrics for Classic Metrics
Interface Type |
Link Speed (Kbps) |
Delay |
Metric |
Serial |
64 |
20,000 μs |
40,512,000 |
T1 |
1544 |
20,000 μs |
2,170,031 |
Ethernet |
10,000 |
1000 μs |
281,600 |
FastEthernet |
100,000 |
100 μs |
28,160 |
GigabitEthernet |
1,000,000 |
10 μs |
2816 |
TenGigabitEthernet |
10,000,000 |
10 μs |
512 |
Using the topology from Figure 2-2, the metrics from R1 and R2 for the 10.4.4.0/24 network are calculated using the formula in Figure 2-10. The link speed for both routers is 1 Gbps, and the total delay is 30 μs (10 μs for the 10.4.4.0/24 link, 10 μs for the 10.34.1.0/24 link, and 10 μs for the 10.13.1.0/24 link).
){kind=link}
)
Figure 2-10 EIGRP Classic Metric Formula with Default K Values
If you are unsure of the EIGRP metrics, you can query the parameters for the formula directly from EIGRP’s topology table by using the command show ip eigrp topology network/prefix-length.
Example 2-17 shows R1’s topology table output for the 10.4.4.0/24 network. Notice that the output includes the successor route, any feasible successor paths, and the EIGRP state for the prefix. Each path contains the EIGRP attributes minimum bandwidth, total delay, interface reliability, load, and hop count.
Example 2-17 EIGRP Topology for a Specific Prefix
R1# show ip eigrp topology 10.4.4.0/24
! Output omitted for brevity
EIGRP-IPv4 Topology Entry for AS(100)/ID(10.14.1.1) for 10.4.4.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3328
Descriptor Blocks:
10.13.1.3 (GigabitEthernet0/1), from 10.13.1.3, Send flag is 0x0
Composite metric is (3328/3072), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 30 microseconds
Reliability is 252/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 10.34.1.4
10.14.1.4 (GigabitEthernet0/2), from 10.14.1.4, Send flag is 0x0
Composite metric is (5376/2816), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 110 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 10.34.1.4
Wide Metrics
The original EIGRP specifications measured delay in 10-microsecond (μs) units and bandwidth in kilobytes per second, which did not scale well with higher-speed interfaces. In Table 2-7, notice that the delay is the same for the GigabitEthernet and TenGigabitEthernet interfaces.
Example 2-18 provides some metric calculations for common LAN interface speeds. Notice that there is not a differentiation between an 11 Gbps interface and a 20 Gbps interface. The composite metric stays at 256, despite the different bandwidth rates.
Example 2-18 Metric Calculation for Common LAN Interface Speeds
GigabitEthernet: Scaled Bandwidth = 10,000,000 / 1,000,000 Scaled Delay = 10 / 10 Composite Metric = 10 + 1 * 256 = 2816
10 GigabitEthernet: Scaled Bandwidth = 10,000,000 / 10,000,000 Scaled Delay = 10 / 10 Composite Metric = 1 + 1 * 256 = 512
11 GigabitEthernet: Scaled Bandwidth = 10,000,000 / 11,000,000 Scaled Delay = 10 / 10 Composite Metric = 0 + 1 * 256 = 256
20 GigabitEthernet: Scaled Bandwidth = 10,000,000 / 20,000,000 Scaled Delay = 10 / 10 Composite Metric = 0 + 1 * 256 = 256
EIGRP includes support for a second set of metrics, known as wide metrics, that addresses the issue of scalability with higher-capacity interfaces. The original formula referenced in Figure 2-6 is known as EIGRP classic metrics.
Figure 2-11 shows the explicit EIGRP wide metrics formula. Notice that an additional K value (K6) is included that adds an extended attribute to measure jitter, energy, or other future attributes.
)
Figure 2-11 EIGRP Wide Metrics Formula
Just as EIGRP scaled by 256 to accommodate IGRP, EIGRP wide metrics scale by 65,535 to accommodate higher-speed links. This provides support for interface speeds up to 655 terabits per second (65,535 × 107) without any scalability issues. Latency is the total interface delay measured in picoseconds (10-12) instead of in microseconds (10-6). Figure 2-12 shows an updated formula that takes into account the conversions in latency and scalability.
)
Figure 2-12 EIGRP Wide Metrics Formula with Definitions
The interface delay varies from router to router, depending on the following logic:
If the interface’s delay was specifically set, the value is converted to picoseconds. Interface delay is always configured in tens of microseconds and is multiplied by 107 for picosecond conversion.
If the interface’s bandwidth was specifically set, the interface delay is configured using the classic default delay, converted to picoseconds. The configured bandwidth is not considered when determining the interface delay. If delay was configured, this step is ignored.
If the interface supports speeds of 1 Gbps or less and does not contain bandwidth or delay configuration, the delay is the classic default delay, converted to picoseconds.
If the interface supports speeds over 1 Gbps and does not contain bandwidth or delay configuration, the interface delay is calculated by 1013/interface bandwidth.
The EIGRP classic metrics exist only with EIGRP classic configuration, while EIGRP wide metrics exist only in EIGRP named mode. The metric style used by a router is identified with the command show ip protocols; if a K6 metric is present, the router is using wide-style metrics.
Example 2-19 verifies the operational mode of EIGRP on R1 and R2. R1 does not have a K6 metric and is using EIGRP classic metrics. R2 has a K6 metric and is using EIGRP wide metrics.
Example 2-19 Verification of EIGRP Metric Style
R1# show ip protocols | include AS|K
EIGRP-IPv4 Protocol for AS(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
R2# show ip protocols | include AS|K
EIGRP-IPv4 VR(EIGRP-NAMED) Address-Family Protocol for AS(100)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric Backward Compatibility
EIGRP wide metrics were designed with backward compatibility in mind. EIGRP wide metrics set K1 and K3 to a value of 1 and set K2, K4, K5, and K6 to 0, which allows backward compatibility because the K value metrics match with classic metrics. As long as K1 through K5 are the same and K6 is not set, the two metric styles allow adjacency between routers.
EIGRP is able to detect when peering with a router is using classic metrics, and it unscales the metric to the formula in Figure 2-13.
)
Figure 2-13 Formula for Calculating Unscaled EIGRP Metrics
This conversion results in loss of clarity if routes pass through a mixture of classic metric and wide metric devices. An end result of this intended behavior is that paths learned from wide metric peers always look better than paths learned from classic peers. Using a mixture of classic metric and wide metric devices could lead to suboptimal routing, so it is best to keep all devices operating with the same metric style.
Interface Delay Settings
If you do not remember the delay values from Table 2-7, the values can be dynamically queried with the command show interface interface-id. The output displays the EIGRP interface delay, in microseconds, after the DLY field. Example 2-20 provides sample output of the command on R1 and R2. Both interfaces have a delay of 10.
Example 2-20 Verification of EIGRP Interface Delay
R1# show interfaces gigabitEthernet 0/1 | i DLY MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
R2# show interfaces gigabitEthernet 0/1 | i DLY MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
EIGRP delay is set on an interface-by-interface basis, allowing for manipulation of traffic patterns flowing through a specific interface on a router. Delay is configured with the interface parameter command delay tens-of-microseconds under the interface.
Example 2-21 demonstrates the modification of the delay on R1 to 100, increasing the delay to 1000 μs on the link between R1 and R2. To ensure consistent routing, modify the delay on R2’s Gi0/1 interface as well. Afterward, you can verify the change.
Example 2-21 Interface Delay Configuration
R1# configure terminal R1(config)# interface gi0/1 R1(config-if)# delay 100 R1(config-if)# do show interface Gigabit0/1 | i DLY MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 1000 usec,
Custom K Values
If the default metric calculations are insufficient, you can change them to modify the path metric formula. K values for the path metric formula are set with the command metric weights TOS K1 K2 K3 K4 K5 [K6] under the EIGRP process. The TOS value always has a value of 0, and the K6 value is used for named mode configurations.
To ensure consistent routing logic in an EIGRP autonomous system, the K values must match between EIGRP neighbors to form an adjacency and exchange routes. The K values are included as part of the EIGRP hello packet. The K values are displayed with the show ip protocols command, as demonstrated with the sample topology in Example 2-13. Notice that both routers are using the default K values, with R1 using classic metrics and R2 using wide metrics.
Load Balancing
EIGRP allows multiple successor routes (with the same metric) to be installed into the RIB. Installing multiple paths into the RIB for the same prefix is called equal-cost multipathing (ECMP) routing. At the time of this writing, the default maximum ECMP is four routes. You change the default ECMP setting with the command maximum-paths maximum-paths under the EIGRP process in classic mode and under the topology base submode in named mode.
Example 2-22 shows the configuration for changing the maximum paths on R1 and R2 so that classic and named mode configurations are visible.
Example 2-22 Changing the EIGRP Maximum Paths
R1# show run | section router eigrp router eigrp 100 maximum-paths 6 network 0.0.0.0
R2# show run | section router eigrp router eigrp EIGRP-NAMED ! address-family ipv4 unicast autonomous-system 100 ! topology base maximum-paths 6 exit-af-topology network 0.0.0.0 eigrp router-id 192.168.2.2 exit-address-family
EIGRP supports unequal-cost load balancing, which allows installation of both successor routes and feasible successors into the EIGRP RIB. To use unequal-cost load balancing with EIGRP, change EIGRP’s variance multiplier. The EIGRP variance value is the feasible distance (FD) for a route multiplied by the EIGRP variance multiplier. Any feasible successor’s FD with a metric below the EIGRP variance value is installed into the RIB. EIGRP installs multiple routes where the FD for the routes is less than the EIGRP multiplier value up to the maximum number of ECMP routes, as discussed earlier.
Dividing the feasible successor metric by the successor route metric provides the variance multiplier. The variance multiplier is a whole number, and any remainders should always round up.
Using the topology shown in Figure 2-2 and output from the EIGRP topology table in Figure 2-3, the minimum EIGRP variance multiplier can be calculated so that the direct path from R1 to R4 can be installed into the RIB. The FD for the successor route is 3328, and the FD for the feasible successor is 5376. The formula provides a value of about 1.6 and is always rounded up to the nearest whole number to provide an EIGRP variance multiplier of 2. Figure 2-14 shows the calculation.
){kind=link}
)
Figure 2-14 EIGRP Variance Multiplier Formula
The command variance multiplier configures the variance multiplier under the EIGRP process for classic configuration and under the topology base submode in named mode. Example 2-23 provides a sample configuration for both configuration modes.
Example 2-23 EIGRP Variance Configuration
R1 (Classic Configuration) router eigrp 100 variance 2 network 0.0.0.0
R1 (Named Mode Configuration) router eigrp EIGRP-NAMED ! address-family ipv4 unicast autonomous-system 100 ! topology base variance 2 exit-af-topology network 0.0.0.0 exit-address-family
Example 2-24 provides a brief verification that both paths were installed into the RIB. Notice that the metrics for the paths are different. One path metric is 3328, and the other path metric is 5376. To see the traffic load-balancing ratios, you use the command show ip route network, as demonstrated in the second output. The load-balancing traffic share is highlighted.
Example 2-24 Verification of Unequal-Cost Load Balancing
R1# show ip route eigrp | begin Gateway
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
D 10.4.4.0/24 [90/5376] via 10.14.1.4, 00:00:03, GigabitEthernet0/2
[90/3328] via 10.13.1.3, 00:00:03, GigabitEthernet0/1
R1# show ip route 10.4.4.0
Routing entry for 10.4.4.0/24
Known via "eigrp 100", distance 90, metric 3328, type internal
Redistributing via eigrp 100
Last update from 10.13.1.3 on GigabitEthernet0/1, 00:00:35 ago
Routing Descriptor Blocks:
* 10.14.1.4, from 10.14.1.4, 00:00:35 ago, via GigabitEthernet0/2
Route metric is 5376, traffic share count is 149
Total delay is 110 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
10.13.1.3, from 10.13.1.3, 00:00:35 ago, via GigabitEthernet0/1
Route metric is 3328, traffic share count is 240
Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 254/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2