Recall that when we have an ether channel configured here, we've got these four
distinct
links that if I get a packet in that's part of a flow, then that packet's still
going
to have to be delivered and sent on one of these member interfaces.
Meaning that if this is four separate 10 gig ports, that yeah, we have 40 gig
of aggregate
throughput, but this flow, this traffic stream is still going to be limited to
10 gigabits
per second.
The reason for that is because we want all of the packets in that flow to use WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The reason for that is because we want all of the packets in that flow to use
the same
link to prevent out of order issues.
We're not going to load balance these across all four of these connections.
So that's an important part of understanding the load balancing of our ether
channels and
why it matters that we keep the flow all on the same connection.
But then we have to remember that there's a process to decide which link is
going to be
chosen and this is the result of a hash.
We're going to take information from the packet, not the entire packet, but WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to take information from the packet, not the entire packet, but
then just specific
pieces of information.
We're going to plug it into this hashing algorithm and we're going to get a
result.
And this result on some level is going to be between zero and seven because the
zero
through seven helps us to identify which port to go across.
And we went into detail on this in the last skill.
So the question here is now which information are we going to include? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the question here is now which information are we going to include?
This actually matters a whole lot.
And here's a classic example.
What if I'm only going to look at the destination MAC address in the packet
flow?
Well we've got to think that on a layer two network that there's all kinds of
different
destinations out there.
Remember we want as much variance and basically variety as possible because we
want a lot of
different results.
For example if everybody had the exact same destination MAC address they would
all get
the exact same result. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the exact same result.
It doesn't matter which flow they came from.
They're all going to be a zero or they're all going to be a three or whatever
the result
is and they're all going to consume one of these links and the other three will
be completely
ignored.
But what are the odds of that happening?
Was there a scenario where all of the destination traffic uses the same MAC
address?
You might assume not just because there could be so many different destinations
out there
but also keep in mind this is a layer two network.
And most of the hosts in the layer two network are all communicating to one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And most of the hosts in the layer two network are all communicating to one
specific interface
which is the default gateway which means that it is the destination MAC for the
vast
majority of our layer two traffic on the subnet.
So in our situation if this is the only thing that we're looking at then indeed
that's
going to create a very heavy load on one of these connections.
And so we see the problem with allowing this hash to rely on a limited amount WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so we see the problem with allowing this hash to rely on a limited amount
of information.
What really is going to happen from a real world perspective is we're going to
take a
look at the link utilization and we might find that the utilization is not
balanced.
Why not necessarily going to know in an environment whether a hashing set of
algorithm we want
to call it that basically which info we choose if we select hey let's just look
at the destination
MAC and see what we've got to go find out is it indeed balanced. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
MAC and see what we've got to go find out is it indeed balanced.
And so we can go out and look at the individual links and maybe we find that
the links are
really not balanced.
We have like 5%, 17%, I should not have chosen that number 8%, I think that's
30% and then
that's 70%.
Okay, that should add up to 100% I believe.
And so maybe we see that one of those links is completely overloaded.
And so what we can do is we have a choice here we can change the hashing method WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so what we can do is we have a choice here we can change the hashing method
and specifically
the information that's used in the hash.
So maybe rather than destination MAC maybe we want to look at source MAC.
So we change it to the source MAC address.
We're only looking at the source MAC address in this environment there should
be a lot of
different source MAC addresses.
And so as we send it out over whatever network this is whatever ether channel
then maybe
it gets a little balanced a whole lot more. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it gets a little balanced a whole lot more.
And so we take a look at the links now and we see that it's 12% and it's 20%
and it's
18% and it's 50%.
So that's a whole lot better but is it good enough?
I mean one of these links is still at 50%.
And so this might require us to use some trial and error and keep trying
different methods.
So the question is what methods do we have available to us?
Well we've already seen two of them.
We have the ability to choose we'll start with source MAC here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We have the ability to choose we'll start with source MAC here.
And the reason we'll start with source MAC is because this is actually the
default on
our catalyst 9Ks.
So be aware if you don't change the hashing method this is the method that we
're using.
Say well that's not bad because again there's going to be a lot of different
source MAC
addresses here sure but what if the default gateway is sending that traffic
down.
And now the MAC address of the default gateway becomes the source for pretty WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now the MAC address of the default gateway becomes the source for pretty
much all the
traffic we're going to have the same problem in the other direction.
And so source MAC is one option destination MAC is another option we typically
don't want
to rely on just one piece of information.
The more information we have the more chaos or entropy there will be and
hopefully just
through the law of averages we get a lot more balance on the links.
So we also have the ability to throw IP addresses in here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we also have the ability to throw IP addresses in here.
So source IP address, destination IP address.
This eliminates the default gateway concept because the default gateway is not
going to
show up as a destination or source IP address.
It's just sort of in the middle.
IP addresses are more end to end and so we should be talking about the host way
out here
as well as whatever the destination is out here.
So that alone might take care of it and then we can also use source port and
destination WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
destination
port as well.
So this would be looking at the TCP or UDP port inside of the packet flow.
Now we can also look at methods that mix these.
So these are six different methods that are just singular but we can actually
combine
these so we've got a few that we look at a couple of them.
For example we can do source and destination MAC address and when we hash them
together
only if the source and destination both are the same will the result be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
only if the source and destination both are the same will the result be
guaranteed to be
the same thing.
We can also do that with IP addresses and we can do that with our ports.
And lastly we can also combine multiple so we can take a look at IP and port
together
which would probably inject a lot more chaos or entropy into it as well.
Now one very important thing to note with the method that we pick is that this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now one very important thing to note with the method that we pick is that this
is global
for the entire switch.
Meaning this is not something I get to decide on a per ether channel basis.
If I have a switch and I've got ether channels coming out my ears here so lots
and lots of
ether channels if I make this source IP well that's going to apply to the maybe
the ether
channel I care about but it's also going to apply it here here and here which
might create
different load balancing problems on those other ether channels. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
different load balancing problems on those other ether channels.
So it is global for the entire switch and always keep that in mind.
The other thing to keep in mind I'll write it up here is that we have a one way
concept
meaning that if I have a switch here and a switch here with an ether channel
between
them well I've got a setting here and I might say that this is hey I'm going to
set this
to source and destination Mac and I might set this side to source and
destination Mac
because generally we like to match things in the networking world. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because generally we like to match things in the networking world.
Well I can't just look at this switch say hey they're all at exactly 25 percent
perfect
that's as load balance as it gets and assume we're good because that only
addresses the
traffic that's going this way.
It's a one way conversation only impacts the traffic that I'm sending out my
local ether
channels.
Well when we're coming from this way the traffic might look a whole lot
different and
so we might have something that's more like this here the 5, 17, 8 and 70 and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so we might have something that's more like this here the 5, 17, 8 and 70 and
so we might
actually make this different we might make this source IP or something along
those lines.
This is the tuning process that we need to get into if we find that our ether
channels
are unbalanced.
So what is the ideal hash unfortunately there isn't one we have to experiment a
little
bit maybe it's with one of these maybe it's with a combination maybe we go all
in on IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in on IP
import but regardless of which one we land on we need to understand why this
matters
and how we can go about resolving issues with load balancing on our ether
channels.