WEBVTT

1
00:00.000 --> 00:05.040
Recall that when we have an ether channel configured here, we've got these four

2
00:05.040 --> 00:05.560
distinct

3
00:05.560 --> 00:09.760
links that if I get a packet in that's part of a flow, then that packet's still

4
00:09.760 --> 00:10.080
going

5
00:10.080 --> 00:15.040
to have to be delivered and sent on one of these member interfaces.

6
00:15.040 --> 00:19.880
Meaning that if this is four separate 10 gig ports, that yeah, we have 40 gig

7
00:19.880 --> 00:20.720
of aggregate

8
00:20.720 --> 00:25.920
throughput, but this flow, this traffic stream is still going to be limited to

9
00:25.920 --> 00:27.160
10 gigabits

10
00:27.160 --> 00:28.320
per second.

11
00:28.320 --> 00:32.130
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

11
00:28.320 --> 00:32.130
The reason for that is because we want all of the packets in that flow to use

12
00:32.130 --> 00:32.640
the same

13
00:32.640 --> 00:34.480
link to prevent out of order issues.

14
00:34.480 --> 00:38.800
We're not going to load balance these across all four of these connections.

15
00:38.800 --> 00:43.070
So that's an important part of understanding the load balancing of our ether

16
00:43.070 --> 00:44.040
channels and

17
00:44.040 --> 00:48.880
why it matters that we keep the flow all on the same connection.

18
00:48.880 --> 00:54.270
But then we have to remember that there's a process to decide which link is

19
00:54.270 --> 00:55.200
going to be

20
00:55.200 --> 00:59.720
chosen and this is the result of a hash.

21
00:59.720 --> 01:03.620
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

21
00:59.720 --> 01:03.620
We're going to take information from the packet, not the entire packet, but

22
01:03.620 --> 01:04.640
then just specific

23
01:04.640 --> 01:06.240
pieces of information.

24
01:06.240 --> 01:11.140
We're going to plug it into this hashing algorithm and we're going to get a

25
01:11.140 --> 01:11.880
result.

26
01:11.880 --> 01:17.340
And this result on some level is going to be between zero and seven because the

27
01:17.340 --> 01:17.760
zero

28
01:17.760 --> 01:21.240
through seven helps us to identify which port to go across.

29
01:21.240 --> 01:24.480
And we went into detail on this in the last skill.

30
01:24.480 --> 01:31.520
So the question here is now which information are we going to include?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

30
01:24.480 --> 01:31.520
So the question here is now which information are we going to include?

31
01:31.520 --> 01:33.920
This actually matters a whole lot.

32
01:33.920 --> 01:35.640
And here's a classic example.

33
01:35.640 --> 01:41.260
What if I'm only going to look at the destination MAC address in the packet

34
01:41.260 --> 01:42.000
flow?

35
01:42.000 --> 01:44.910
Well we've got to think that on a layer two network that there's all kinds of

36
01:44.910 --> 01:45.440
different

37
01:45.440 --> 01:46.640
destinations out there.

38
01:46.640 --> 01:52.070
Remember we want as much variance and basically variety as possible because we

39
01:52.070 --> 01:53.040
want a lot of

40
01:53.040 --> 01:54.800
different results.

41
01:54.800 --> 01:58.700
For example if everybody had the exact same destination MAC address they would

42
01:58.700 --> 01:59.120
all get

43
01:59.120 --> 02:00.400
the exact same result.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

43
01:59.120 --> 02:00.400
the exact same result.

44
02:00.400 --> 02:02.120
It doesn't matter which flow they came from.

45
02:02.120 --> 02:04.970
They're all going to be a zero or they're all going to be a three or whatever

46
02:04.970 --> 02:05.520
the result

47
02:05.520 --> 02:09.880
is and they're all going to consume one of these links and the other three will

48
02:09.880 --> 02:10.400
be completely

49
02:10.400 --> 02:11.800
ignored.

50
02:11.800 --> 02:14.440
But what are the odds of that happening?

51
02:14.440 --> 02:18.430
Was there a scenario where all of the destination traffic uses the same MAC

52
02:18.430 --> 02:19.160
address?

53
02:19.160 --> 02:23.000
You might assume not just because there could be so many different destinations

54
02:23.000 --> 02:23.520
out there

55
02:23.520 --> 02:26.880
but also keep in mind this is a layer two network.

56
02:26.880 --> 02:34.800
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

56
02:26.880 --> 02:34.800
And most of the hosts in the layer two network are all communicating to one

57
02:34.800 --> 02:36.480
specific interface

58
02:36.480 --> 02:42.760
which is the default gateway which means that it is the destination MAC for the

59
02:42.760 --> 02:43.220
vast

60
02:43.220 --> 02:46.160
majority of our layer two traffic on the subnet.

61
02:46.160 --> 02:50.430
So in our situation if this is the only thing that we're looking at then indeed

62
02:50.430 --> 02:50.920
that's

63
02:50.920 --> 02:55.600
going to create a very heavy load on one of these connections.

64
02:55.600 --> 03:01.030
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

64
02:55.600 --> 03:01.030
And so we see the problem with allowing this hash to rely on a limited amount

65
03:01.030 --> 03:02.600
of information.

66
03:02.600 --> 03:06.730
What really is going to happen from a real world perspective is we're going to

67
03:06.730 --> 03:07.080
take a

68
03:07.080 --> 03:14.370
look at the link utilization and we might find that the utilization is not

69
03:14.370 --> 03:15.720
balanced.

70
03:15.720 --> 03:20.830
Why not necessarily going to know in an environment whether a hashing set of

71
03:20.830 --> 03:21.960
algorithm we want

72
03:21.960 --> 03:26.100
to call it that basically which info we choose if we select hey let's just look

73
03:26.100 --> 03:26.920
at the destination

74
03:26.920 --> 03:31.520
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

74
03:26.920 --> 03:31.520
MAC and see what we've got to go find out is it indeed balanced.

75
03:31.520 --> 03:36.320
And so we can go out and look at the individual links and maybe we find that

76
03:36.320 --> 03:37.280
the links are

77
03:37.280 --> 03:38.400
really not balanced.

78
03:38.400 --> 03:45.700
We have like 5%, 17%, I should not have chosen that number 8%, I think that's

79
03:45.700 --> 03:47.120
30% and then

80
03:47.120 --> 03:48.120
that's 70%.

81
03:48.120 --> 03:51.600
Okay, that should add up to 100% I believe.

82
03:51.600 --> 03:56.440
And so maybe we see that one of those links is completely overloaded.

83
03:56.440 --> 04:02.780
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

83
03:56.440 --> 04:02.780
And so what we can do is we have a choice here we can change the hashing method

84
04:02.780 --> 04:04.520
and specifically

85
04:04.520 --> 04:07.880
the information that's used in the hash.

86
04:07.880 --> 04:11.480
So maybe rather than destination MAC maybe we want to look at source MAC.

87
04:11.480 --> 04:14.560
So we change it to the source MAC address.

88
04:14.560 --> 04:20.040
We're only looking at the source MAC address in this environment there should

89
04:20.040 --> 04:20.880
be a lot of

90
04:20.880 --> 04:23.200
different source MAC addresses.

91
04:23.200 --> 04:27.360
And so as we send it out over whatever network this is whatever ether channel

92
04:27.360 --> 04:28.040
then maybe

93
04:28.040 --> 04:30.120
it gets a little balanced a whole lot more.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:28.040 --> 04:30.120
it gets a little balanced a whole lot more.

94
04:30.120 --> 04:37.430
And so we take a look at the links now and we see that it's 12% and it's 20%

95
04:37.430 --> 04:38.280
and it's

96
04:38.280 --> 04:42.400
18% and it's 50%.

97
04:42.400 --> 04:45.720
So that's a whole lot better but is it good enough?

98
04:45.720 --> 04:48.560
I mean one of these links is still at 50%.

99
04:48.560 --> 04:51.890
And so this might require us to use some trial and error and keep trying

100
04:51.890 --> 04:53.560
different methods.

101
04:53.560 --> 04:57.000
So the question is what methods do we have available to us?

102
04:57.000 --> 04:59.640
Well we've already seen two of them.

103
04:59.640 --> 05:05.740
We have the ability to choose we'll start with source MAC here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

103
04:59.640 --> 05:05.740
We have the ability to choose we'll start with source MAC here.

104
05:05.740 --> 05:10.980
And the reason we'll start with source MAC is because this is actually the

105
05:10.980 --> 05:11.720
default on

106
05:11.720 --> 05:13.760
our catalyst 9Ks.

107
05:13.760 --> 05:18.100
So be aware if you don't change the hashing method this is the method that we

108
05:18.100 --> 05:18.880
're using.

109
05:18.880 --> 05:23.220
Say well that's not bad because again there's going to be a lot of different

110
05:23.220 --> 05:23.880
source MAC

111
05:23.880 --> 05:28.320
addresses here sure but what if the default gateway is sending that traffic

112
05:28.320 --> 05:28.920
down.

113
05:28.920 --> 05:33.530
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

113
05:28.920 --> 05:33.530
And now the MAC address of the default gateway becomes the source for pretty

114
05:33.530 --> 05:34.240
much all the

115
05:34.240 --> 05:37.760
traffic we're going to have the same problem in the other direction.

116
05:37.760 --> 05:43.460
And so source MAC is one option destination MAC is another option we typically

117
05:43.460 --> 05:43.920
don't want

118
05:43.920 --> 05:46.720
to rely on just one piece of information.

119
05:46.720 --> 05:52.020
The more information we have the more chaos or entropy there will be and

120
05:52.020 --> 05:53.000
hopefully just

121
05:53.000 --> 05:57.840
through the law of averages we get a lot more balance on the links.

122
05:57.840 --> 06:01.080
So we also have the ability to throw IP addresses in here.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

122
05:57.840 --> 06:01.080
So we also have the ability to throw IP addresses in here.

123
06:01.080 --> 06:04.160
So source IP address, destination IP address.

124
06:04.160 --> 06:10.200
This eliminates the default gateway concept because the default gateway is not

125
06:10.200 --> 06:10.920
going to

126
06:10.920 --> 06:14.200
show up as a destination or source IP address.

127
06:14.200 --> 06:15.520
It's just sort of in the middle.

128
06:15.520 --> 06:18.950
IP addresses are more end to end and so we should be talking about the host way

129
06:18.950 --> 06:19.480
out here

130
06:19.480 --> 06:22.480
as well as whatever the destination is out here.

131
06:22.480 --> 06:29.220
So that alone might take care of it and then we can also use source port and

132
06:29.220 --> 06:30.560
destination
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

132
06:29.220 --> 06:30.560
destination

133
06:30.560 --> 06:32.560
port as well.

134
06:32.560 --> 06:41.240
So this would be looking at the TCP or UDP port inside of the packet flow.

135
06:41.240 --> 06:43.520
Now we can also look at methods that mix these.

136
06:43.520 --> 06:49.570
So these are six different methods that are just singular but we can actually

137
06:49.570 --> 06:50.320
combine

138
06:50.320 --> 06:53.400
these so we've got a few that we look at a couple of them.

139
06:53.400 --> 06:57.580
For example we can do source and destination MAC address and when we hash them

140
06:57.580 --> 06:58.120
together

141
06:58.120 --> 07:02.180
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

141
06:58.120 --> 07:02.180
only if the source and destination both are the same will the result be

142
07:02.180 --> 07:03.120
guaranteed to be

143
07:03.120 --> 07:04.300
the same thing.

144
07:04.300 --> 07:13.520
We can also do that with IP addresses and we can do that with our ports.

145
07:13.520 --> 07:19.070
And lastly we can also combine multiple so we can take a look at IP and port

146
07:19.070 --> 07:19.920
together

147
07:19.920 --> 07:24.800
which would probably inject a lot more chaos or entropy into it as well.

148
07:24.800 --> 07:31.310
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

148
07:24.800 --> 07:31.310
Now one very important thing to note with the method that we pick is that this

149
07:31.310 --> 07:32.240
is global

150
07:32.240 --> 07:34.520
for the entire switch.

151
07:34.520 --> 07:38.800
Meaning this is not something I get to decide on a per ether channel basis.

152
07:38.800 --> 07:45.080
If I have a switch and I've got ether channels coming out my ears here so lots

153
07:45.080 --> 07:46.360
and lots of

154
07:46.360 --> 07:51.770
ether channels if I make this source IP well that's going to apply to the maybe

155
07:51.770 --> 07:52.520
the ether

156
07:52.520 --> 07:56.400
channel I care about but it's also going to apply it here here and here which

157
07:56.400 --> 07:57.800
might create

158
07:57.800 --> 08:02.440
different load balancing problems on those other ether channels.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
07:57.800 --> 08:02.440
different load balancing problems on those other ether channels.

159
08:02.440 --> 08:06.000
So it is global for the entire switch and always keep that in mind.

160
08:06.000 --> 08:11.260
The other thing to keep in mind I'll write it up here is that we have a one way

161
08:11.260 --> 08:11.960
concept

162
08:11.960 --> 08:15.910
meaning that if I have a switch here and a switch here with an ether channel

163
08:15.910 --> 08:16.440
between

164
08:16.440 --> 08:21.680
them well I've got a setting here and I might say that this is hey I'm going to

165
08:21.680 --> 08:22.400
set this

166
08:22.400 --> 08:27.120
to source and destination Mac and I might set this side to source and

167
08:27.120 --> 08:28.380
destination Mac

168
08:28.380 --> 08:32.080
because generally we like to match things in the networking world.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
08:28.380 --> 08:32.080
because generally we like to match things in the networking world.

169
08:32.080 --> 08:37.840
Well I can't just look at this switch say hey they're all at exactly 25 percent

170
08:37.840 --> 08:38.320
perfect

171
08:38.320 --> 08:42.040
that's as load balance as it gets and assume we're good because that only

172
08:42.040 --> 08:42.880
addresses the

173
08:42.880 --> 08:44.640
traffic that's going this way.

174
08:44.640 --> 08:50.660
It's a one way conversation only impacts the traffic that I'm sending out my

175
08:50.660 --> 08:51.440
local ether

176
08:51.440 --> 08:52.760
channels.

177
08:52.760 --> 08:57.500
Well when we're coming from this way the traffic might look a whole lot

178
08:57.500 --> 08:58.440
different and

179
08:58.440 --> 09:05.540
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

179
08:58.440 --> 09:05.540
so we might have something that's more like this here the 5, 17, 8 and 70 and

180
09:05.540 --> 09:06.480
so we might

181
09:06.480 --> 09:11.470
actually make this different we might make this source IP or something along

182
09:11.470 --> 09:12.960
those lines.

183
09:12.960 --> 09:16.970
This is the tuning process that we need to get into if we find that our ether

184
09:16.970 --> 09:17.600
channels

185
09:17.600 --> 09:19.640
are unbalanced.

186
09:19.640 --> 09:25.240
So what is the ideal hash unfortunately there isn't one we have to experiment a

187
09:25.240 --> 09:25.840
little

188
09:25.840 --> 09:29.740
bit maybe it's with one of these maybe it's with a combination maybe we go all

189
09:29.740 --> 09:30.600
in on IP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
09:29.740 --> 09:30.600
in on IP

190
09:30.600 --> 09:36.450
import but regardless of which one we land on we need to understand why this

191
09:36.450 --> 09:37.160
matters

192
09:37.160 --> 09:40.450
and how we can go about resolving issues with load balancing on our ether

193
09:40.450 --> 09:41.000
channels.