- [Narrator] In this video,
we want to take a look
at an EIGRP feature that's unique among routing protocols.
OSPF cannot do this,
it's called the variants feature.
The idea is Yeah,
GRP has the ability
to load balance across unequal cost paths,
different routes
that have different metrics.
That way,
we get some load balancing.
For example,
in this case,
R1 can get down to that server,
which is on network 198.51.100.0/24,
it can get there two different ways.
It can get there via BB1,
or it can get there via BB2.
And currently,
we have an equal metric for each path.
Let's confirm that let's do a show IP route command.
And we see that EIGRP,
is load balancing across both paths.
And the reason is the metric
of each path is 3072.
This path is via BB2,
and this path is via BB1.
Now OSPF can do that as well,
however, what if the metric was higher between R1
and BB1, let's make
that number higher than 3072.
And see if we can still load balance across those
on equal cost paths.
That's where the variance feature comes in.
And it can do that for us.
To make that happen.
Let's go into interface Gigabit0/2.
And I'm going
to artificially increase the delay associated
with that interface.
Remembering that EIGRP by default,
examines bandwidth
and delay to calculate its metric.
And the default delay
for gig interface is 10 microseconds.
Let's increase that I'm going to say
that the delay is 20 microseconds.
To do that,
I give the command delay.
And you can see
from context sensitive help that the unit
of measure is
in 10s of microseconds.
It's also a delay too.
Now, if I take a look
at our IP routing table,
let's do a show, IP route.
You'll see that there's only one path
to get to this 198.51. 100.0/24 network,
and it's via 203.0.113.5,
that's BB2.
We're no longer load balancing between BB1
and BB2,
we can see why by taking a look
at the EIGRP topology table.
Let's do a show IP EIGRP
topology command.
And we see that even though we're only using one path,
to get down to that server,
yeah, EIGRP knows about two different paths.
It knows the path via BB2
and via BB1.
But notice the metrics are different.
Since I increase that delay,
the route via BB1 has a higher metric of 3328,
that's higher than 3072.
And that's the reason only this route
via BB2 is being injected
into the IP routing table.
Let's use the variance option
to use both routes.
And here's the way
that variance option works.
We're going to go
into router configuration mode for EIGRP.
We'll say variants,
and we're going to give an integer.
Now that integer is a multiplier,
we're going to say let's take the feasible distance.
In other words,
3072 of our successor route,
that's our preferred route.
Let's multiply that by two.
And that would give us 6104.
Now we have a range of values,
a range of metric values across which we can load balance.
So if the metric
via another route is 6144,
or lower, it could be equal
to or less than,
then we can load balance across those paths.
Let's make that happen.
Let's go into router configuration mode
for EIGRP autonomous system one,
and I'm going to say variants,
and I'm going to give a multiplier of two.
Because after all two times 3072.
We said that was 6144.
Yeah, but other metric via BB1 it's
in that range.
It's 3328.
That's well under 6144.
So this should work.
Let's do a show IP route.
And look at this.
Now even though the metric values are different,
the variance option is allowing us
to load balance across these
on equal cost paths.
And you might wonder,
are we trying
to send the same amount
of traffic over both links
after all one has a higher metric,
shouldn't we send a less across that link.
And we do EIGRP,
load balances proportionally
with the variance option.
And there's one other critical aspect
of the variance feature
that a lot of people miss,
I want to make sure that you get it,
and that is in order
to load balance across these paths.
Beyond just having a multiplier
which creates a range encompassing,
multiple metric values.
Any additional route that we use,
has to be a feasible successor route it has to have passed
The feasibility condition.
Now if we take a look
at our EIGRP topology table right now,
we can see that,
this route via BB1,
even though it doesn't have the lowest metric,
it has passed the feasibility condition.
And the feasibility condition asks,
is the reported distance
from a feasible successor less than,
not equal to,
but it says less than the feasible distance
of our successor route?
In this case we're asking is 2816 is
that less than 3072?
And yes, it is.
As a result,
this path via BB1,
it is a feasible successor.
If we had a path that was valid,
but the feasibility condition was not met.
Even though we had the variance multipliers set correctly,
we still would not load balance across those paths,
let's prove that let's go set.
The delay on interface Gigabit0/2 back to the way it was,
delay is going to be one 10
of microseconds,
so it's going to be 10 microseconds.
Now if I do a show IP route,
we should be load balancing.
And the paths should have an equal cost.
So they do.
Lets go to BB1
and change the delay there.
What we're trying
to do is have the reported distance,
the distance that BB1 is reporting,
we want that reported distance
to be equal
or higher than the feasible distance
of our successor route via BB2.
Then, even though we have the variance set correctly,
we're not going to be able
to use that backup path.
Let's go over to BB1.
And let's go into interface Gigabit0/2,
remembering that when EIGRP,
calculates delay,
it's cumulative.
We're looking
at the egress interface delay as we go out of R1,
which is the 10 microseconds on G0/2.
But we're also adding
on to that the delay associated
with leaving a BB1 Gigabit0/2.
Now, it's currently 10 microseconds,
but we're going to bump it up,
we're going to set it to 20 microseconds,
I'm going to say delay,
to because the units
of measure are
in 10s of microseconds.
Now let's go back to R1.
And just a moment ago,
we were load balancing.
Let's take a look again,
show IP route.
Now this time,
we're only using one path
to get down to that server.
And it's via BB2.
Well, I've already got the variant set.
I wonder what the reported distance is from BB1,
let's do a show IP EIGRP topology command again.
Look at this,
that backup path
that we were load balancing across a moment ago.
It's not even appearing
in this table.
Where is it?
What happened to it?
Well, it's important to realize
that when we look
at the topology table,
we're only seeing successor
and feasible successor routes,
there may be another route
to get to 198.51.100.0/24.
But that other route has failed
to meet the feasibility condition.
If we want to see that route anyway,
what we can do is say show IP EIGRP topology,
all hyphen links.
And when we do that,
now we see the missing route,
it's down here at the bottom.
And that's via 203.0. .113.1,
that's BB1.
And we can see that it has failed the feasibility condition,
because of the reported distance
from BB one is 3072.
And it was not less than it's equal
to but it's not less than the feasible distance
of our successor out of 3072.
So since the reported distance
of BB1 was not less
than this feasible distance via BB2,
the feasibility condition fails.
And we still have our variance setting set to two.
So if you take a look
at the metric of 3072,
and you multiply it by two,
and we've got that range now of 6144,
all the way down to 3072.
Yeah, that does encompass the 328.
But even though the variance is set correctly,
it's still not going to load balance across
that path now,
because that path did not meet the feasibility condition.
And that's a look
at the variance feature.
Of the sum up,
the variance feature is unique to EIGRP.
It lets us load balance across unequal cost paths,
we specify an integer,
and that integer is a multiplier,
we multiply the variants value by the feasible distance
of our successor route,
and that creates a range
and if an alternate path has a value that is less
than or equal
to that multiplier times the feasible distance
of our successor route,
then that alternate route can be used
to load balance across
and we saw that happen.
And then we had a route that was not a feasible successor.
And we saw that that could not be used
with the variants feature.