EIGRP Metrics: Terms, and Traffic Engineering
Enhanced Interior Gateway Routing Protocol (EIGRP) is a dynamic routing protocol widely used in computer networks. To optimize the routing process, EIGRP employs various metrics and conditions. In this blog post, we will delve into the intricacies of EIGRP metrics, including Reported Distance, Computed Distance, Feasible Distance, Feasibility Condition, Successor, and Feasible Successor.
The EIGRP Metric
The EIGRP metric is a computed value made up of five values, minimum bandwidth, delay, load, reliability and MTU. These are known as K values The original intention of this metric was to take all of these values into consideration when choosing the best path, however, that’s not the case by default in almost every EIGRP network.
By default, only the values of the minimum bandwidth and delay form the metric with load, reliability and MTU all being disabled. It was determined that these additional K values could result in network instability if not disabled.
metric = ([K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]) * 256
Bandwidth is scaled using the formula “10^7/bandwidth in Kbps”. Delay is scaled down by 10.
Reduced, the formula looks like this: metric = (10^7/bandwidth + delay/10)*256
The delay value is taken from the interface and is cumulative. This has the effect of being a pseudo hop count, but with some consideration towards the capability of the links. In the table below, you’ll notice that the default delay value is the same for both the GigabitEthernet and TenGigabitEthernet and the computed metric is the same for every link speed larger than the TenGigabitEthernet.
Because the metric is 10^7 over the link speed, this rounds up to 1 for values larger than this “reference bandwidth”. Because the delay is the same, 10 μs, and this is divided by 10 for the metric, it results in (1+1)*256 or a metric of 512.
This is a similar problem to that in OSPF, where using the default reference bandwidth results in links that are larger than 100Mbps having the same cost. In OSPF, there is a user definable value called the reference bandwidth which changes the scale at which costs are calculated.
Cisco solved this problem with EIGRP by introducing the wide metric to EIGRP. The changes to the EIGRP metric calculation included:
1. Measuring delay in picoseconds
2. Increased the “reference bandwidth” by multiplying by 65536 (2^16) for links above 1Gbps
3. Added an additional K value, K6 for future use
The new wide-scale metric looks like this:
Metric = [(K1*Minimum Throughput + {K2*Minimum Throughput} / 256-Load) + (K3*Total Latency) + (K6*Extended Attributes)]* [K5/(K4 + Reliability)]
Total Latency = (Delay*65536)/10
Minimum Throughput = (10^7* 65536)/Bw)
To add more confusion, EIGRP has the ability to scale the metric that is sent to the RIB (routing table) down to reduce the size of the metric in the routing table. By default, this number is 128. This RIB scaling metric can be changed with the following command.
To use wide-scale EIGRP metrics create your routing process in named mode
In the event that you’ve already deployed EIGRP in classic mode, you can upgrade the process using the command:
The output from the EIGRP topology table will show both the composite metric and the RIB metric after the scale of 128 is applied.
Distances and Metrics
One of the more confusing set of terms for EIGRP are the differences between distance, successor routes, etc. What’s more confusing is that the name for a given metric or route changes based on the point-of-view from which we’re examining the route.
Reported Distance:
The Reported Distance is the metric associated with a route as advertised by a neighboring router.
It represents the total metric value to reach a destination, as reported by the neighboring router.
Computed Distance:
The Computed Distance is the sum of the Reported Distance and the metric of the link over which the routing information was received.
It is the metric value calculated by adding the Reported Distance and the cost of the link to the neighboring router.
Feasible Distance:
The Feasible Distance is the best metric from the local router to a destination network.
It is the lowest Computed Distance among all paths to reach a specific network.
The above distance definitions are straightforward, from the point of view of RouterA, the reported distance is distance that our neighbors have to a destination. The reported distance is that neighbor’s feasible distance, or more accurately our neighbors successor route.
We add the reported distance to the distance to our neighbor to get the computed distance. In the case that RouterA only has one neighbor sending us one route, the computed distance would be the feasible distance. In the case that RouterA has multiple routes to a given destination, the feasible distance is just the best of those routes.
Feasibility Condition:
The Feasibility Condition is a comparison between the Reported Distance of a potential successor route and the Feasible Distance.
If the Reported Distance is lower than the Feasible Distance, the route is considered a feasible successor.
The feasibility condition is just a test that’s applied to a route that helps the router determine whether a given route is “good enough” and not actually the result of a loop.
Successor:
A Successor is the primary route chosen to reach a destination based on the lowest Feasible Distance.
It is the route that is currently being used to forward traffic to a particular network.
Feasible Successor:
A Feasible Successor is a backup route that meets the Feasibility Condition and can be used if the primary route (Successor) fails.
It provides EIGRP with a backup path to a destination, enhancing network resilience.
The successor route and feasible successor routes are essentially, the best route and other routes that are good enough to pass the feasibility condition but not the best. These feasible successor routes are held in the EIGRP topology table as alternative routes. If the successor route goes away for any reason, we can just put the next best feasible successor and carry on.
The reason why a route that has the best feasible distance is not always the successor route is because there may be another routing protocol running with a lower administrative distance.
Route Failure
After a failure of the primary route, if there are no feasible successors available for a particular destination network, the router enters the "active" state. This means that the router sends out queries to its neighboring routers requesting information about alternative paths to the destination network. These queries are known as "queries for feasible successors" or "QFS" packets.
Once the neighboring routers receive the query, they check their own topology tables to determine if they have feasible successors for the queried destination network. If they do, they reply to the originating router with information about their feasible successors. This process continues until the originating router either receives responses from all neighbors confirming no feasible successors or finds a feasible successor.
Once a feasible successor is found, the router updates its routing table accordingly, marking the destination network as active again and removing it from the active state.
EIGRP Path Engineering
While it’s not always necessary to influence EIGRP to route one way or the other, EIGRP does support equal-cost load balancing out of the box, there may be reasons or scenarios where you want to change the default behavior.
There are four main ways influence traffic routing with EIGRP:
· Route length – summarization
· Unequal cost load balancing
· Interface metric changes
· Direct manipulation of route metrics
Route Length
One of the easiest ways to influence traffic flow in EIGRP is by taking advantage of the most basic rule that routers use to find the best path, the most specific route wins.
If we had a scenario where we had multiple paths between two endpoints, we can adjust the route length to direct traffic over one path.
This can be done easily with route summarization, where we suppress any routes that are longer than our summarization and only send the supernet.
Interface gigabitethernet1 ip summary-address eigrp [ASN] [SUMMARY ADDRESS] [MASK] !
Side note here, if you’ve been in the game a while, you might think or remember that EIGRP enabled auto-summarization by default and that you needed to disable this. This was true for a long time but since IOS 15.0(1)M, this feature has been disabled. You no longer need to disable auto-summary in modern IOS or IOS-XE. If you’re still unsure, check the output of “show ip protocols”.
RouterA#show ip protocols *** IP Routing is NSF aware ***
Routing Protocol is "application" Sending updates every 0 seconds Invalid after 0 seconds, hold down 0, flushed after 0 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Maximum path: 32 Routing for Networks: Routing Information Sources: Gateway Distance Last Update Distance: (default is 4)
Routing Protocol is "eigrp 1" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP-IPv4 Protocol for AS(1) Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 Soft SIA disabled NSF-aware route hold timer is 240 EIGRP NSF disabled NSF signal timer is 20s NSF converge timer is 120s Router-ID: No usable Router-ID found Topology : 0 (base) Active Timer: 3 min Distance: internal 90 external 170 Maximum path: 4 Maximum hopcount 100 Maximum metric variance 1
Automatic Summarization: disabled Maximum path: 4 Routing for Networks: 10.0.0.0 Routing Information Sources: Gateway Distance Last Update Distance: internal 90 external 170
There may be times though where we want to create a summary route over one path and also send specific routes over that path as well. This can be accomplished with a leak map.
In this scenario, I want to match the route for 10.0.5.0/24, while sending a summary route for the 10.0.0.0/16 space. Any other route in the 10.0.0.0/16 subnet not matching the “LEAKED-ROUTES” prefix-list will be suppressed.
ip prefix-list LEAKED-ROUTES seq 5 permit 10.0.5.0/24 ! route-map LEAKED-ROUTES permit 10 match ip address prefix-list LEAKED-ROUTES ! interface GigabitEthernet1 ip summary-address eigrp 1 10.0.0.0 255.255.0.0 leak-map LEAKED-ROUTES
Unequal cost load balancing
One of the unique features of EIGRP is the ability to perform unequal cost load balancing. By default EIGRP (and OSPF, IS-IS, and RIP) support equal cost load balancing which will send traffic over two or more paths as long as the route metric is equal. Because EIGRP calculates feasible successor routes, we can actually use this to our advantage and include paths that aren’t the fastest into the forwarding path.
Unequal cost load balancing in EIGRP is enabled when we provide a variance value to the process. When we do this, EIGRP will find the best path to the destination network and then multiply the metric by the variance. Any routes that are better than this modified metric, will be included in the routing table. Paths that are eligible for inclusion with unequal cost load balancing must be feasible successors.
Setting the variance alone includes additional paths in the routing table, and traffic is shared amongst them equally. That is to say, if there are two paths with different costs (and the same interface type) CEF will utilize them as if they are equal. This could lead to an issue where the worse path is overloaded while the better path is under-utilized.
You can change this behavior; however with paths that are very similar, this may not make a difference. EIGRP implements unequal load sharing with the “traffic-share” command.
When using the balance setting of traffic-share it will proportion traffic flows across the various paths. The router determines the traffic share count by dividing the highest path metric by the path metric, and then round down to the nearest integer.
For example, if our best path to a destination has a metric of 512, but a second path has a metric of 1025, the first path would get (1024/512=2) twice as many flows as the second path (1024/1024=1).
Metric Changes
By default, EIGRP uses the values of the interface type to determine the bandwidth and delay. However, often we may want to use an interface only as a standby interface in case of the primary interface going down. As well, WAN interfaces may be policed down by an ISP based on what service we’re paying for. For example, the physical handoff for a WAN circuit may be over a gigabit ethernet connection but the contracted speed of the circuit may be 100Mbps.
In this case, setting the available bandwidth on a circuit is as easy as setting it using the interface sub-command, “bandwidth [speed in Kbps]”. EIGRP will use this speed in its calculations instead of the interface hardware bandwidth.
An easier method to force EIGRP to chose one path over another is to increase the delay on the less preferred path. Use the “delay [delay in ms]” command. It’s generally easier to increase the delay on a less desirable path than it is to decrease the delay on a preferred path.
Be careful not to increase the delay too much or it may prevent the alternative interface from meeting the feasibility condition and being kept in the topology table. During a failure of the primary path, EIGRP may take longer to converge again than it would with a feasible successor route already in the table.
Below is the configuration to show changing the interface bandwidth and delay can impact the route metrics.
interface GigabitEthernet1 bandwidth 50000 delay 20
Manipulating Route Metrics
There are cases where perhaps we want to target just a specific set of routes to prefer one path over another. In this case, we can directly manipulate the metric on a route matching an access-list. This is called an “offset-list” and it offsets the true metric of a route by whatever value you provide it. This is done under the EIGRP process and we need the following information:
An access-list - this argument doesn’t appear to accept a prefix-list as far as I can tell
The direction - are we manipulating the route as it enters in from a neighbor or as it’s leaving out towards a neighbor
The metric offset - a number that will be added to the metric
The interface on which we’ll apply the offset list
It’s worth noting here that an offset list only has the capability of making a metric worse rather than better. Apply offset lists on paths or interfaces that are less preferred.
This is the configuration from RouterB receiving routes from RouterA.
ip access-list standard OFFSET-LIST 10 permit 10.5.5.5 router eigrp 1 network 10.0.0.0 offset-list OFFSET-LIST in 200 GigabitEthernet1
In the below output from “show ip route”, the 10.5.5.5/32 route is matched by the access list and the metric is increased by 200 (130816 increased to 131016). The 10.0.5.0/24 route remains unchanged.
RouterB#show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route H - NHRP, G - NHRP registered, g - NHRP registration summary o - ODR, P - periodic downloaded static route, l - LISP a - application route + - replicated route, % - next hop override, p - overrides from PfR & - replicated local route overrides by connected Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks D 10.0.0.0/16 [90/3072] via 10.0.1.1, 00:19:12, GigabitEthernet1 C 10.0.1.0/24 is directly connected, GigabitEthernet1 L 10.0.1.2/32 is directly connected, GigabitEthernet1 D 10.0.5.0/24 [90/130816] via 10.0.1.1, 00:10:38, GigabitEthernet1 D 10.5.5.5/32 [90/131016] via 10.0.1.1, 00:00:05, GigabitEthernet1
Final Thoughts
Be aware of any routing changes you’re making to your network could result in asymmetrical routing. Often, if these traffic engineering techniques are only applied in one direction, the return route may not follow the same change in metric. You’ll need to review your overall network design an apply each of these techniques in a thoughtful manner.
I hope this clears up some of these terms and makes it clear what they’re used for and then some strategies for manipulating the EIGRP metric to get the most out of your network.
