So for this module we are going to talk about another advantage that
EIGRP has over other routing protocol options.
Well,
every routing protocol has the ability to load-balance over
multiple available paths when the cost to reach a destination
is the same across each path.
Most, however, don't support the ability to load-balance over unequal paths.
EIGRP is the only common routing protocol that supports this functionality.
In this module we are going to quickly discuss how EIGRP implements
this functionality before moving into the lab and showing how it can
be implemented on a Cisco iOS device.
First,
let's note that by default EIGRP is configured to only
perform equal cost load balancing.
To support unequal load balancing EIGRP must be configured to
specifically perform it and in what way.
To have a device begin to unequally load-balance traffic,
a non-default variance multiplier must be configured.
By default it is set to one.
This means that only routes that are of equal cost are used for forwarding.
If this variance is set to two this means that a device will take all feasible
routes in the topology table that have a metric to a destination that is equal
to or less than the best metric multiplied by two.
Let's illustrate this with a simple example.
Specifically, let's focus on the route from R1 to network A.
The numbers in this case indicate the link metrics.
Looking strictly at the metrics, and not considering feasibility,
R1 would have 2 different path options to reach
network A; Via R3 with a cost of 20, and Via R2 with a cost of 40.
Since these options are not equal, only the path Via R3 would be used by default.
If we altered the variance multiplier from 1 to 2,
then R1 would consider all routes that it has in its topology table
with metrics equal to or less than the best metric.
In this case, the best metric is 20,
so it will use all options that have metrics less than 40.
Again, based only on the metrics, and not considering feasibility,
this would allow both paths to be used.
However,
if we consider feasibility this wouldn't happen because R1 would
only accept the route to network A Via R3.
This is because the other route, Via R2,
wouldn't pass the feasibility condition because the advertised
cost from R2 is 20 and the best metric is 20.
Now the second thing to consider is the setting of the maximum paths setting.
By default, on Cisco iOS devices, for example,
this setting is set to four,
meaning that regardless of whether there is one path available or eight,
only four of them will ever be load-balanced.
This is true of both equal cost and unequal cost load balancing.
And finally,
the last thing that we will note before moving into the lab is about how a
device performs the load balancing when paths are unequal.
By default,
routes that are unequal are balanced based on a ratio between the cost
of a route and the cost of the highest cost route.
So using the same example topology from before,
again, not considering feasibility,
R1 with a variance multiplier set to 2 would have 1 route with
a cost of 20 and another with a cost of 40.
The first ratio would be 40 divided by 20 to give us 2,
and the second would be 40 divided by 40 that gives us 1.
This means that R1 would send 2 packets via its route with
a cost of 20 for every 1 packet that it would send over
the route with a cost of 40.
It's also important to keep in mind that this ratio
is calculated based on integers,
so any result that is not an integer should be rounded down.
Another problem to keep in mind is that by default most Cisco
devices use Cisco Express Forwarding or CEF.
On most platforms it defaults to per destination load balancing.
This would affect the way that this weighted balancing worked by sending all
traffic destined for a specific destination via a single path.
If the result is not as expected this default CEF behavior would need to be changed.