EIGRP LAB # 2 : Load Balancing

In this lab I will explore equal and unequal-cost load-balancing for EIGRP and will explain how EIGRP calculates its metric values.


R1 is the router we will be doing our tests from. It will connect through R2 and R3 to IP address on the WAN.


  1. Set up the base EIGRP configuration.
  2. Configure and verify load balancing
  3. Configure and verify Unequal-cost load balancing.

I have done objective one, configured all the interfaces and set up the EIGRP AS, network commands and set up a default route for Here’s the configuration so far.

Okay, so the base configuration is done. I have verified the EIGRP process with the “show ip eigrp neighbours” command.
For loadbalancing we will be concentrating on the connection between R1 and on the WAN.

Let’s do a “show ip route” on R1 to see what the current situation is.

We have a Gateway of last resort for as intended and it looks like we have two equal-cost routes for this same network, one going through R2 and one going through R3.

To get some more information on our default route, we can use the command “show ip eigrp topology“.

In the third line we can see that this router has 2 Successors (next hops) with a FD (Feasible distance) of 2323456.

You can also see the ‘composite metric‘ for both routes. (2323456/2297856) The first number is the Feasible distance (as seen from R1), the second number is the Reported Distance (as seen from the neighbour).

The metric calculation for EIGRP is based on something called the K-values.
These K values are a reference to the entries under “Vector metric” in the screenshot above.

The K values only act as multipliers or modifiers in the composite metric calculation.

K1 = default 1Bandwidth = This is used in the calculation by default.
K2 = default 0Load = Not participating in the calculation by default.
K3 = default 1Delay This is used in the calculation by default.
K4 = default 0Reliability = Not participating in the calculation by default.
K5 = default 0MTU = Not participating in the calculation by default.

So in this calculation, we would use 1 x Bandwidth and 1 x Delay (values on the interface). Here’s the complete formula for EIGRP.

I’ve however come across some contradicting information that claims that K5, or MTU is or isn’t used in the EIGRP Metric calculation. In fact, if you look at the last part of the formula, K5/K4 + Reliability, you will see that if K5 is set to the default of zero, it will completely eliminate this part of the calculation as zero divided by anything is always zero.

So, you would think MTU is never used, however, I’ve found an interesting arcticle that explains it will still be used as a tie-breaker when dealing with equal cost paths even if K5 is set to zero.

If your router would have to ignore some equal-cost paths to the same destination (the number of equal-cost paths exceeds the value of the maximum-paths router configuration parameter), it ignores those with the lowest MTU metric.

When processing inbound EIGRP updates, the minimum of the MTU value in the inbound UPDATE packet and the interface MTU is stored in the EIGRP topology database. No MTU processing is done on the outbound updates. The MTU metric thus represents the minimum unidirectional MTU between the current router and the originating router.

How to verify Load Balancing

The default setting for Load Balancing under EIGRP is “per-destination”.
As we’re working with only one destination, we will still end up using one link for all traffic, so it is better to implement “per-packet” load-balancing.

To enable “per-packet” load-balancing we will need to check our CEF (Cisco Express Forwarding) settings. If this device did not use CEF, we would have to disable fast-switching on the interfaces with the interface command “no ip route-cache

To check CEF for this route, use the command “show ip cef

You can see here that per-destination sharing is enabled for these two routes.
To change this to “per-packet” use the interface command “ip load-sharing per-packet” on all interfaces that forward traffic to the destination.

R1#conf t
R1(config)#int fa 0/0
R1(config-if)#ip load-sharing per-packet
R1(config-if)#int fa 0/1
R1(config-if)#ip load-sharing per-packet

If you now enter the command “show ip cef” again, you can see that sharing is now per-packet based.

That’s it, We’ve configured and verified Equal-Cost Load Balancing.

On to objective 3, Configure and verify Unequal-cost load balancing.

To start this, I will higher the Delay value for R1, Fa 0/0 and R2, Fa 0/0 to make one of the links appear faster and therefor more preferred.

R1(config)#int fa 0/0
R1(config-if)#delay 5000
R1(config)#int fa 0/1
R1(config-if)#delay 5000

If you look at the EIGRP topology now, you can see one of the routes has a higher metric. This has as result that only the route via R3 is being used to forward traffic.

If we want to use multiple links that do not have the same metric for Load-Balancing, we need to use the router process command “variance x” where x is a multiplier for the lowest metric of the routes that you want to use.

So for example “Variance 2” would use routes with a metric between 2323456 and, twice that, 4646912. In this case it would allow our higher metric route via R2 to be used in Unequal-cost Load-Balancing for the route to

R1#conf t
R1(config)#router eigrp 10
R1(config-router)#variance ?
<1-128> Metric variance multiplier

R1(config-router)#variance 2

And if we take another look at the EIGRP topology, we can see both the router via R3, and the higher metric route via R2, are being used.

Looking at the output from “Show ip cef“, we can see that both routes are being used, but the lower route has a higher traffic share, meaning that it will get to forward a bigger share of the traffic that is being Load-Balanced.

And with this, we have successfully implemented and verified Unequal-cost Load-Balancing.

Influencing EIGRP Metrics