Eigrp Metric Manipulation

One of the great unique features EIGRP brings to the table is the ability to load-balance traffic across unequal links.

To properly configure R1 to load balance traffic on a 5:1 scale to network 164.1.26.0 we need to understand how the EIGRP composite metric.
The composite metric consists of
– BW : the minimum bandwidth of any outgoing interface along a specific path
– Delay : the cumulative delay of all the outgoing interface along a specific path
– Load : effective load of a route on the interface
– Reliability : likelihood of successful packet transmission
– Smallest MTU along a path.

There is a big long formula that takes each of the above metrics into account using specific K-values. But I’m not going to cover that here. The only thing of importance is that the K-values could be changed to en/disable some of the above metrics
By default, only BW & Delay is taken into account when calculating the metric according the the following shorten formula:
Metric = 256 * ((10^7/BW) + (DLY/10))

Let look at a example on R1:

We can see the route metric here is 3026432.  The BW is 1280k , and DLY is 40100 msec
If we use the formula above:
Metric = 256 * ((10000000/ 1280) + (40100/10))
= 256 * (7812 + 4010)
= 256 * 11822
= 3026432

Back to our original goal to load balance traffic on R1 using a 5:1 ratio between the 256k link and the 1,544mb links. By far the easiest way, is to disable the metric calculation, thereby only using BW with K-value set to (0 1 0 0 0 0) or only DLY with K-value set to (0 0 0 1 0 0). In the practice labs that is often not the case, your likely not allowed to change the configured BW on any interface, nor change the default metric calculation, which leaves you with the only option: change DLY. So how do you go about it.

Firstly you need to know the calculated metric of the alternate path that in currently not used. There are two ways to do this. The first and most common is the look at the EIGRP topology table with
#sh ip eigrp topology (prefix)


But the route via the alternate destination might not always show there, because for a route to be listed in the topology table as a feasible successor (FS), the advertised distance (AD) must be lower than the current feasible distance (FD). The better way to see a alternate path’s metric, is by setting the variance to a high value. The variance defines a multiplier by which metric may differ, or vary, from the metric of the lowest-cost route (the FD). This is how EIGRP does unequal-cost load balancing.

So by setting the variance to a arbitrary high number like 30, you will see will any route that has a metric 30 times worse that the current best route. Look at the output of the same command now:

The variance here is set to 28 and we want to change the ratio to be 5:1, i.e. for every one packet sent across the frame cloud, five should be sent via R3. Now there is different ways to work this out, honestly I prefer the shortest.

That would be as follow: Take the lowest metric value, 3026432 via R3, and multiply by 5 (ratio 5:1) to see what we want the metric to be for the route via the Frame cloud. That gives us 15132160. Now all that left is using the same formula as above with the values we have. We have the wanted metric = 15132160, and we have the BW = 256k. Then:
Metric = 256 * ((10^7/BW) + (DLY/10))
15132160 = 256 * ((10000000/256) + DLY/10)
59110 = (39062) + (DLY/10)
20048 = DLY/10
TOTAL DLY = 200480

Remember that DLY is cumulative,  you have to subtract the delay of other outbound interfaces along the path to know what your local interface delay should be.
In the above scenario, R2 adds 100 microseconds. That gives us a Local Interface DLY of 200380 to meet our requirement.

Easy right! Now to change DLY on interface S0/1/0, you need to know that IOS requires the command to be entered in tens of microseconds :
int Se0/1/0
delay 20038

That will then give you the following output:

Here you can see the traffic share count reflect the 5:1 ratio required or needed.