So if we take a look at the lab topology,
how we're going to show this in the lab is we're going to jump
onto distribution 1 and see how it load-balances traffic
between itself and up to the core,
and specifically we're going to be seeing how it load-balances traffic to
the network that connects the two core devices together,
which is the 10.10 .10 .0 network.
So if we move from the topology into the lab here you'll see
that at the moment there are 2 paths that connect distribution
1 to the 10.10 .10 .0 network,
which is that network that connects Core1 and Core2.
And if we look at this a little closer we'll see that
both have the same route metric, which is 1536.
In this case, as I noted, we disabled the use of bandwidth,
so this is the cumulative delay between here and there multiplied by 256,
and that's how the route metrics are calculated at this point.
So both routes have the same metric,
and both show this traffic share count number as one,
and how this can be interpreted from a load balancing
perspective is that for every one packet that goes to this
path one packet will also go this path.
One will go here, and then one will go here.
Then it'll sort of round robin and go back and forth.
Now again, as I noted in the theory section,
this is assuming that Cisco Express Forwarding is not altering this behavior.
By default, it will,
so the load balancing discussion here is just using EIGRP's load balancing,
and not considering Cisco Express Forwarding's alteration of this behavior.
Now if we take this and we alter the delay between distribution
1 and Core2 to make it have a metric that's something different
than the link between itself and Core1 we'll show that 1 of
these paths will disappear.
Now the original delay on the links between
distribution 1 and the core routers is 10,
and since you configure these in 10's of microseconds on Cisco
devices this is setting the delay from 10 to 40.
So if we go back here and look at the routing table we'll see that now there
is only one route that goes between here and that network,
and the reason for that is because the metric would have
changed on that route that goes through Core2,
and we can see this by looking at the EIGRP topology table,
and in this case we'll see that there are actually two routes that exist in
the topology table to get to the 10.10 .10 .0 network.
The first, which is the one that we're using right now,
which is the one that goes via the 192.168 .127 .1
with a current metric of 1536,
and the second one that's available in the topology table as a
feasibly successor is the one that goes via the 192.168 .127 .5
address that currently has a metric of 3840.
Now, as I noted in the theory section,
by default EIGRP will only perform equal cost load-balancing,
so since these routes do not have the same metric it will
only use the one with the lowest metric,
but the advantage of EIGRP, as I noted again,
is that it supports the ability to do unequal load-balancing,
and it does this whenever you alter the variance multiplier in EIGRP.
But how do we determine what variance multiplier we want to use?
And, in this case, what we're going to do is if you take these two numbers,
1536 and 3840,
we'll see that if we used a variance multiplier of 2 that would allow
routes that have metrics that are less than 3072 and less,
and since the alternative feasible path here has a metric higher than that,
that still wouldn't collect the second route.
But if we multiply it by 3 it would be over 4000, and it would include this.
So we need to set the variance to a value that's larger than three or larger.
So if we do this on a Cisco device it's just done under the EIGRP process,
and you would set variance to three.
And when we do this we --- topology table doesn't change,
but the routing table does.
Now we'll see that both of these routes are included,
but they are not balanced in a way that's equal
because that wouldn't really make sense.
If one path has a cost that's less than the next one,
then it would make more sense that the one with the lowest cost
would get more traffic than the higher cost path.
So, in this case,
this is shown on Cisco equipment in this display with this traffic share count.
In this case, this path with a metric of 3840,
that is a traffic share count of 2, and the second one with the lower cost,
1536, has a traffic share count of 5.
The simplistic way of thinking about this is for every two
packets that are sent via this higher cost path,
five are sent via this lower cost path.
So, in this case, you would take the metric 3840,
and you would take the metric 1536 and add them
together to get you a total of 5376,
and then you use that as a denominator to find a similar ratio.
So it will be 1536 divided by 5376 would get you roughly the same
number as if you would divide 2 by --- 2 in this case,
by 7, which would --- whenever you add 5 and 2 together,
and if you notice,
that's an inverse relationship between the metric and the share count.
So 5376, sorry,
1536 divided by 5376 will get you a ratio that's
basically the same as 2 divided by 7.
So now if we show this in the routing table,
from the normal routing table here I want to highlight something here,
top of this routing table is these two routes,
and the other thing that I wanted to note here is we
need to talk about maximum paths.
By default on most Cisco devices there is a maximum path of four for EIGRP,
and what this means is if there are four or more paths available,
or if there are more than four paths available,
then only four of them will ever be inserted into the
routing table at the same time.
If one of, let's say if you had five paths that were available,
four of them would be inserted into the routing table,
and if one of those four would fail, then the fifth one would be put in there,
and you would still be using four paths,
but it wouldn't go ever above this number.
So if you had more than four paths that were available that
you wanted to actively use for forwarding,
then you need to change the maximum path variable.
For this, in this lab,
we're going to show this and how this works by altering it
from its default of four down to one.
As we showed,
there's currently 2 routes that exist in the routing table for that 10 network,
and since there are 2 networks that are available,
and the maximum path is 4, or sorry, maximum values is 4,
then it will allow both routes, but if I change the maximum number from 4 to 1,
when we do this then the path with the lowest cost in this case,
which was the one that we altered the delay on,
which goes through Core2, goes away because it's saying,
yes I know I have multiple paths that go there,
but you're saying the maximum number that I'm allowed to
insert into the routing table is one,
so I'm going to choose the one with the best metric.
Now this is really something that's going to be only a problem in
networks that are large enough where there are multiple paths that are
going to be available from point A to point B,
and sometimes you want to make that number higher,
and sometimes you want to make it less.
It's all situationally specific,
but I wanted to make sure to show that as an example and how it
affects what's inserted into the routing table.
So with that, that completes this lab.
It's not a very complicated lab,
but we wanted to point out how load balancing can be configured.
Now, in this case, this is specific to a Cisco device,
and as far as I can tell, load balancing isn't actually part of the EIGRP RFC,
but it does support the capability,
so if EIGRP is implemented on a different vendor's equipment the
possibility that they use unequal load balancing is there, especially if they want to simulate Cisco default behavior.