In many networks, if we've got a successor route, the winner,
and then we have our backup route, the feasible successor,
in the wings, we may want to do load balancing across both
of those, except we wouldn't want
to do equal cost load balancing because one link is
a lot faster, or one route's faster than the other.
But what if we could do proportional load balancing,
which is the topic of this video.
[MUSIC PLAYING]
And what we're going to discover is
that EIGRP does have the unique ability,
with one simple little command, to do unequal cost WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
with one simple little command, to do unequal cost
and proportional load balancing across multiple routes
in the routing table.
And this is how the unequal cost load balancing works in EIGRP.
We're going to start off with a router that has a successor
route, that means the winner, and it's
feasible distance, and any routes
that meet the feasibility condition,
meaning they aren't the successor route,
but the advertised distance from the neighbors
is less than our current feasible distance, all
of those routes-- well, by default, up to four of them--
could be used to proportionally load balance traffic, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
could be used to proportionally load balance traffic,
if we tell the router to do it.
And here's how we tell the router to go ahead and do
proportional load balancing.
We go into router config and we use the command variance.
Now, the variance command says, OK, you
wanted to go ahead and use the successor route and possibly
some others, but then you have to tell them how bad
or what range of metrics do you want
to support for any of these feasible successors
to be included in load balancing?
And the answer is we put a number here.
And so what that number means is this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so what that number means is this.
If we have an R3--
right here, we have a R3-- we have a feasible distance
of that number--
I'll just point to it--
2,173,184.
If we say variance 2, what that means to the router is that any
feasible successors that meet the feasibility condition that
have a metric of 2,173,184 or double that--
that's what this multiplier is--
those are going to be acceptable as load balancing routes
that we can do proportional load balancing across. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that we can do proportional load balancing across.
So if we said variance 3, what that means
is that you could go ahead and use the successor route
with this metric and any feasible
successors that have a metric of that feasible distance times 3
or better.
And that's what the variance is all about.
And we can actually see this in action on R3.
And so on R3, what I'm going to do is for a demo,
I'm just going to go to R3.
We'll take a look at the topology table.
We'll verify that there is a successor route and a feasible
successor.
And then we'll see that only one route is in the routing table. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we'll see that only one route is in the routing table.
And then we'll include the variance command.
And then we'll see that we have both routes
in the routing table, and it'll start doing load balancing
across both of those routes.
So for the demonstration, let's do a show ip route.
And let's take a look at this specific route, 10.2.68.
That's the route we've been focusing on throughout this set
of videos.
And currently, it has an administrative distance of 90
because we learned it via EIGRP.
And there's its metric 2 million--
yada, yada, ya-- ending in 184.
And the egress interface is gig 1/0, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the egress interface is gig 1/0,
which is the path up to R1.
So if we did a show ip eigrp topology and press Enter,
there is that route once again.
There's the 10.2.68 network.
And there's that metric that we just
saw a moment ago ending in 184.
And this is that same metric here.
So those two numbers are the same.
And this is the [INAUDIBLE] that's the reported distance.
Now, the second route here that's
going to 34.4, which is over through R4, through the Fast
Ethernet connection, as opposed to gigabit,
it's metric is 2,174,976, and that's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it's metric is 2,174,976, and that's
why it's not in the routing table.
It's got a worse metric.
And the advertised distance coming from R4
is this number right here.
And again, the feasibility condition simply
says that the advertised distance
has to be less than the current feasible distance
to be considered a feasible successor.
And this number right here, the advertised distance
for that alternate route, is indeed
less than our current feasible distance.
So we have a feasible successor.
But that second route is not shown in the routing table WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But that second route is not shown in the routing table
yet because we haven't enabled variance for anything
more than the default. Let's take a look at that too.
So if we do a show ip protocols and press Enter,
this is showing us right here the default variance,
the variance of 1, which basically says, if you're not
exactly equal to the metric or the feasible
distance for the successor route, you're not making it in.
But we could simply change that.
And if we go back-- in fact, I'll
just scroll up a little bit here.
What this is showing us right here regarding the successor
route is that this metric for the successor route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
route is that this metric for the successor route
is just a hair, like 1,000 and change.
So the variance command is done in full digits.
But these are just so close, these metrics,
that just a variance of 2 would actually
bring in that feasible successor as an alternate route.
So let's go ahead and do that.
And just to verify real quickly to show--
that we can do a before and after picture--
show ip route for the 10.2.68.0 network.
And we have one route that's going through R1.
And there's the metric for that successor route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And there's the metric for that successor route.
So that's great.
Router eigrp.
Autonomous system 1.
And I'm going to use the variance command.
I'm going to use a question mark.
And then we simply put in the variance multiplier.
Think of the multiplier as for any routes that
meet the feasibility condition, that whatever
the current feasible distance is times whatever we put here--
2, or 3, or 4--
those would be the additional routes
that would be included in our load balancing.
So we can just say 2 here, because those metrics
for the successor route and the feasible successor WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for the successor route and the feasible successor
were so darn close that a multiplier of 2
is going to bring in that second route.
So we'll press Enter.
And then let's do this.
Do show ip route.
We'll do that same route again, 10.2.68.0.
Check this out.
Now we have two entries.
I should look down before I confirm that.
Now we have two entries.
No, we don't.
Yes, we do.
So here's the show ip route command.
And this is showing us the metric
for the primary route, which is through R1.
And this is showing us the metric for the second,
or what used to be the feasible successor, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or what used to be the feasible successor, which
is now in the routing table.
Now I'd like to address a little question about load balancing.
And that is this traffic share count right here.
Because the metrics for the successor route and the-- what
was the feasible successor, which is now also
in the routing table--
because they were so darn close, the traffic share count
is 1 each, which means equal cost balancing regarding
both routes.
Now, if we had a metric that was significantly different--
you know what?
We can do that.
So now that I mentioned that, let's actually WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now that I mentioned that, let's actually
go to our topology and let's tweak it
a little bit so you and I can see the results.
So right now, going this way and this way,
the metric is so darn close to the traffic
share on both those paths is 1.
And the two factors are bandwidth,
which is the lowest bandwidth in the path, and delay.
So what we could do is we could actually
manipulate this interface on R3 and tell it
that its bandwidth is, let's say, one--
1,000 kilobits per second or one megabit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1,000 kilobits per second or one megabit
per second, as opposed to 100 megabits per second.
And that would skew the metric quite a bit.
And we currently have a variance of 2.
So as long as we don't make this path through R4 twice as bad--
and we can just visually see it when we're done--
it'll still be used because the variance is 2.
So let's modify this bandwidth on 4/0
to make it artificially bad, or worse.
And that would make that metric worse.
And then when those metrics are further and further apart,
we can then see the traffic share count WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can then see the traffic share count
reflect that with how the router is going to do load balancing.
So currently, the metrics are very, very close.
So let's go into interface 4/0 and artificially increase
the bandwidth statement that EIGRP
is using for its calculations.
So we'll go back to the CLI.
And we'll go to interface Fast Ethernet 4/0.
And we'll say bandwidth--
and let's make sure we get our numbers straight--
so bandwidth in kilobits-- so if we say 1,000 kilobits, that's
1 megabit.
And the current lowest bandwidth on that path is 1.54. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the current lowest bandwidth on that path is 1.54.
And we can actually see that up here as well.
So on this interface here, it currently
shows that the minimum bandwidth in the path is 1.54.
We're going to set it to 1,000 just
on that interface, which it's going to make the metric worse
using that path.
I just want these numbers here, this metric and this metric,
to be further apart so that we can see the traffic share count
isn't just 1 and 1 equal.
I want to see a bigger difference with the traffic
share count than just 1 to 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
share count than just 1 to 1.
And changing this bandwidth is going
to move us in that direction.
So we'll press Enter.
And then we'll do that same command again,
do show ip route for 10.2.68.0.
And we'll check the results.
So now on our route going through R1,
our metric hasn't changed.
That's our feasible distance.
And-- oh, this is good--
now our metric for going through R4 on our Fast Ethernet
interface is 3,077,120.
So here, we have 2 million and change.
This is 3 million and change. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is 3 million and change.
And check this out.
Now check this out, the traffic share count.
169 versus 240.
It's proportional, so it identified what the costs were.
And based on that ratio, it's going
to do proportional load balancing in that level
or in that amount regarding those two routes, which
is really, really darn cool with EIGRP and variance.
In this video, I did a demo how we
could do unequal cost load balancing on a Cisco router
running EIGRP using variance.
Now, there's a critical thing I want
you to take away from this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you to take away from this.
Just typing in variance space 10 doesn't
mean that every possible route that
has a metric that is 10 times or better the feasible
distance for a certain route--
not every single route comes in.
Those routes that come in still have
to meet the feasibility condition,
meaning they have to have an advertised, or reported,
distance from a neighbor that's less than our current feasible
distance.
And then if they do, then if we have a multiplier of 10,
then their metric can be 10 times the current feasible
distance and still make it. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
distance and still make it.
So thanks for joining me in this video.
I'll see you in the next one.
Meanwhile, I hope this has been informative for you,
and I'd like to thank you for viewing.