WEBVTT 1 00:00.000 --> 00:05.440 So, let's say we have a pair of switches and these are 10 gig switches. 2 00:05.440 --> 00:10.720 I've got four of these 10 gig connections between the two switches and I bundle 3 00:10.720 --> 00:10.880 them 4 00:10.880 --> 00:13.240 together in an ether channel. 5 00:13.240 --> 00:17.920 And so, if you're like me, I will refer to this as a 40 gig link. 6 00:17.920 --> 00:20.080 A lot of us probably do. 7 00:20.080 --> 00:24.530 And it's easy to think of this as almost taking these four separate connections 8 00:24.530 --> 00:24.800 and 9 00:24.800 --> 00:30.400 just sort of filling them in almost so that we've got this gigantic pipe and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:24.800 --> 00:30.400 just sort of filling them in almost so that we've got this gigantic pipe and 10 00:30.400 --> 00:30.600 that we 11 00:30.600 --> 00:33.720 can send 40 gig through it. 12 00:33.720 --> 00:36.360 And the question is, is this really accurate? 13 00:36.360 --> 00:39.480 Is this a good way to describe what's really happening? 14 00:39.480 --> 00:41.680 And the answer is no. 15 00:41.680 --> 00:44.120 That's not the best way to describe what this is. 16 00:44.120 --> 00:48.380 Yeah, we're taking four separate 10 gig connections and yes, our total 17 00:48.380 --> 00:49.520 aggregate throughput is 18 00:49.520 --> 00:51.080 40 gig. 19 00:51.080 --> 00:54.560 But the thing about this is if we imagine a highway, let's say there's a two- 20 00:54.560 --> 00:54.720 layer 21 00:54.720 --> 00:59.960 lane highway here and we've got traffic going and I live in the US, so I'll use 22 00:59.960 --> 01:00.480 miles per WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 00:59.960 --> 01:00.480 miles per 23 01:00.480 --> 01:01.480 hour here. 24 01:01.480 --> 01:06.800 Let's say that the speed limit is 60 miles per hour, 60 mph. 25 01:06.800 --> 01:10.640 And so that's great and all, but now we're starting to see some congestion on 26 01:10.640 --> 01:11.360 this two-lane 27 01:11.360 --> 01:12.360 highway. 28 01:12.360 --> 01:13.360 There's lots of cars. 29 01:13.360 --> 01:14.720 And so what might we do? 30 01:14.720 --> 01:17.920 Well, we might add a third lane or even a fourth lane. 31 01:17.920 --> 01:22.500 And this is going to allow us to place more cars on the highway at a time and 32 01:22.500 --> 01:23.280 hopefully 33 01:23.280 --> 01:25.480 relieve some of that congestion. 34 01:25.480 --> 01:28.720 But here's the question, did the speed limit change? 35 01:28.720 --> 01:30.400 And the answer is no. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 35 01:28.720 --> 01:30.400 And the answer is no. 36 01:30.400 --> 01:34.630 So if I were to say, okay, well, well, that's great and all, but how fast can 37 01:34.630 --> 01:35.840 this one car 38 01:35.840 --> 01:38.880 get through now that we've added two other lanes? 39 01:38.880 --> 01:42.120 Well, it can still only go 60 miles an hour. 40 01:42.120 --> 01:49.220 And this has the equivalence of a single traffic flow as it goes through the 41 01:49.220 --> 01:51.560 ether channel. 42 01:51.560 --> 01:56.560 Because when I take a traffic flow and a traffic flow is typically traffic that 43 01:56.560 --> 01:57.640 is flowing 44 01:57.640 --> 02:00.280 from one host to another as part of one process. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 01:57.640 --> 02:00.280 from one host to another as part of one process. 45 02:00.280 --> 02:05.000 So we think about TCP and UDP ports, source and destination IP addresses. 46 02:05.000 --> 02:07.920 This is going to define for us a traffic flow. 47 02:07.920 --> 02:12.970 This one flow is going to arrive on the switch and this switch recognizes it 48 02:12.970 --> 02:13.960 needs to send 49 02:13.960 --> 02:15.840 it out the ether channel. 50 02:15.840 --> 02:16.840 So what does it do? 51 02:16.840 --> 02:21.570 Well, it's going to pick a member interface and it's going to send that traffic 52 02:21.570 --> 02:22.120 flow through 53 02:22.120 --> 02:26.330 that one member interface, which means that this traffic flow has a total 54 02:26.330 --> 02:28.200 throughput capability 55 02:28.200 --> 02:31.480 of only 10 gigabits per second. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 02:28.200 --> 02:31.480 of only 10 gigabits per second. 56 02:31.480 --> 02:35.730 If these two hosts happen to be sending 25 gigabits per second between the two, 57 02:35.730 --> 02:36.240 we might 58 02:36.240 --> 02:37.520 look at it and say, that's fine. 59 02:37.520 --> 02:39.800 I've got 40 gig between these switches. 60 02:39.800 --> 02:42.840 25 is a lot of it, but it's not all of it. 61 02:42.840 --> 02:45.280 Well, it actually is. 62 02:45.280 --> 02:48.520 It's going to be severely bottlenecked by the fact that it's only going to be 63 02:48.520 --> 02:49.040 placed on 64 02:49.040 --> 02:51.640 one of those member links. 65 02:51.640 --> 02:54.720 So the question we might say is, well, why are we doing this? 66 02:54.720 --> 02:59.360 Why wouldn't we take this traffic flow and split it up among these links? 67 02:59.360 --> 03:02.860 And there's a lot of reasons for that, but the primary reason is because this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 67 02:59.360 --> 03:02.860 And there's a lot of reasons for that, but the primary reason is because this 68 03:02.860 --> 03:03.360 is going 69 03:03.360 --> 03:10.270 to create major out of order issues, meaning that as I take packets one, two, 70 03:10.270 --> 03:11.200 three and 71 03:11.200 --> 03:15.260 four and I split them up like this, depending on the inner mechanisms of the 72 03:15.260 --> 03:15.920 switch and 73 03:15.920 --> 03:20.540 the number of packets in each individual queue, we might actually get these 74 03:20.540 --> 03:21.280 packets in the 75 03:21.280 --> 03:22.600 wrong order. 76 03:22.600 --> 03:27.280 And so we receive them as, you know, let's just say three, four, one, two, 77 03:27.280 --> 03:28.200 something like 78 03:28.200 --> 03:29.200 that. 79 03:29.200 --> 03:32.940 And then from there, it's going to take whatever path out towards the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 03:29.200 --> 03:32.940 And then from there, it's going to take whatever path out towards the 80 03:32.940 --> 03:34.560 destination and that packet 81 03:34.560 --> 03:36.480 order is going to be the same at that point. 82 03:36.480 --> 03:40.430 Now, if this is a TCP stream, maybe not that big of a deal, but UDP does 83 03:40.430 --> 03:41.840 nothing to rearrange 84 03:41.840 --> 03:43.160 those packets. 85 03:43.160 --> 03:47.210 And this is going to cause a disaster, not just because it might happen once or 86 03:47.210 --> 03:47.840 twice, 87 03:47.840 --> 03:51.160 but because it's going to happen constantly, it's going to happen all of the 88 03:51.160 --> 03:51.840 time if we're 89 03:51.840 --> 03:55.830 splitting this up on a per packet basis, which is why it makes sense to take 90 03:55.830 --> 03:56.560 one traffic 91 03:56.560 --> 04:00.960 flow and place it onto a single member interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 03:56.560 --> 04:00.960 flow and place it onto a single member interface. 92 04:00.960 --> 04:07.120 We're not going to even consider using this out of order type of method. 93 04:07.120 --> 04:09.760 So how do we decide which member interface to use? 94 04:09.760 --> 04:16.040 Well, this is going to require us to talk about creating a hash. 95 04:16.040 --> 04:20.480 The goal here is for us to identify a traffic flow. 96 04:20.480 --> 04:24.080 We need to actually figure out which packets belong to which traffic flow. 97 04:24.080 --> 04:29.200 So we need to identify this, an individual traffic flow, and then we need to 98 04:29.200 --> 04:29.800 select a 99 04:29.800 --> 04:31.360 member link. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 04:29.800 --> 04:31.360 member link. 100 04:31.360 --> 04:37.200 Now the goal here is to decide which member link to use. 101 04:37.200 --> 04:44.360 But in the middle here, we're going to place this through a hashing algorithm. 102 04:44.360 --> 04:50.320 And this hashing algorithm is going to give us a number, which tells us the 103 04:50.320 --> 04:51.680 member link. 104 04:51.680 --> 04:53.480 So let's give an example here. 105 04:53.480 --> 05:01.480 So let's say a particular packet arrives and it goes through this process. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 105 04:53.480 --> 05:01.480 So let's say a particular packet arrives and it goes through this process. 106 05:01.480 --> 05:05.620 And because of the hash, the resulting hash, let's just say it's a two digit 107 05:05.620 --> 05:07.000 number here. 108 05:07.000 --> 05:10.100 Actually, let's just say it's between zero and seven because that's actually 109 05:10.100 --> 05:10.560 how these 110 05:10.560 --> 05:11.860 switches work. 111 05:11.860 --> 05:14.680 And so it picks one of these numbers based on the hash. 112 05:14.680 --> 05:17.840 And so we end up with a number of four. 113 05:17.840 --> 05:23.920 And so it gets placed onto link number four in the port channel. 114 05:23.920 --> 05:25.680 So that's how we determine it. 115 05:25.680 --> 05:27.440 Now there are a few questions to ask here. 116 05:27.440 --> 05:30.920 First of all, again, how do we identify this traffic flow? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 116 05:27.440 --> 05:30.920 First of all, again, how do we identify this traffic flow? 117 05:30.920 --> 05:34.040 This is going to be based on certain parameters. 118 05:34.040 --> 05:37.600 For example, we're going to be taking a look at the source and destination MAC 119 05:37.600 --> 05:38.280 address. 120 05:38.280 --> 05:41.430 Since this is a layer two flow, the source and destination MAC will look 121 05:41.430 --> 05:42.240 different among 122 05:42.240 --> 05:44.440 the different traffic flows. 123 05:44.440 --> 05:46.780 Although keep in mind, if we're going to the gateway, then that might not be 124 05:46.780 --> 05:47.240 the case 125 05:47.240 --> 05:48.800 in all situations. 126 05:48.800 --> 05:53.160 But either way, we're going to look at the source and destination IP address. 127 05:53.160 --> 05:58.550 We're going to look at the QOS tag, even the IP protocol, which will tell us 128 05:58.550 --> 06:00.120 what's happening WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 128 05:58.550 --> 06:00.120 what's happening 129 06:00.120 --> 06:06.120 inside of the layer three packet and the input interface. 130 06:06.120 --> 06:09.730 So these are the qualities that we're going to be taking a look at to identify 131 06:09.730 --> 06:10.200 traffic 132 06:10.200 --> 06:11.200 flow. 133 06:11.200 --> 06:18.440 These match, then they're part of the same flow. 134 06:18.440 --> 06:23.910 So this way, as these hosts, well, let's just say as host A here is sending 135 06:23.910 --> 06:24.680 traffic 136 06:24.680 --> 06:30.370 to host B, all of the packets that match on all of these parameters are going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 06:24.680 --> 06:30.370 to host B, all of the packets that match on all of these parameters are going 137 06:30.370 --> 06:31.000 to be, 138 06:31.000 --> 06:34.400 it's going to be part of the same traffic flow because all of the packets in 139 06:34.400 --> 06:35.480 this flow, 140 06:35.480 --> 06:40.000 well, working backwards, has all of those same properties. 141 06:40.000 --> 06:42.800 So that's how we identify the traffic flow. 142 06:42.800 --> 06:48.180 But now we need to also draw a little bit deeper here into this concept of 143 06:48.180 --> 06:48.960 identifying 144 06:48.960 --> 06:53.200 a hash ID as well as identifying a link number. 145 06:53.200 --> 06:54.640 So how exactly does this work? 146 06:54.640 --> 06:58.980 Well, I just mentioned earlier, a little bit of a spoiler alert that the result 147 06:58.980 --> 06:59.160 of the 148 06:59.160 --> 07:02.520 hash is going to be between zero and seven. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 148 06:59.160 --> 07:02.520 hash is going to be between zero and seven. 149 07:02.520 --> 07:07.350 This is because once again, our port channels support a max number of links of 150 07:07.350 --> 07:08.000 eight. 151 07:08.000 --> 07:11.080 So zero through seven gives us eight different values. 152 07:11.080 --> 07:15.520 Furthermore, when we have, let's say, let's just start with eight. 153 07:15.520 --> 07:19.960 Let's say we've got eight different connections here in our port channel 154 07:19.960 --> 07:21.440 between our devices. 155 07:21.440 --> 07:23.080 We've got a device here and a device here. 156 07:23.080 --> 07:24.360 We're going to bundle these together. 157 07:24.360 --> 07:27.120 Well, at that point, all of these are going to get an ID. 158 07:27.120 --> 07:31.720 So zero, one, two, three, four, five, six, and seven. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 158 07:27.120 --> 07:31.720 So zero, one, two, three, four, five, six, and seven. 159 07:31.720 --> 07:36.010 So when a packet needs to go out this port channel, we're going to run the hash 160 07:36.010 --> 07:36.580 , find 161 07:36.580 --> 07:41.840 out the hash equals something, zero through seven, based on these parameters. 162 07:41.840 --> 07:46.690 And it's going to therefore get sent out link number five, let's say, in the 163 07:46.690 --> 07:47.620 bundle. 164 07:47.620 --> 07:49.420 So that probably makes sense. 165 07:49.420 --> 07:55.800 But what happens if we don't have eight links that are in the port channel? 166 07:55.800 --> 07:58.700 Well, we can only get these eight different values. 167 07:58.700 --> 08:03.780 And that leads to some interesting problems with certain numbers of links. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 07:58.700 --> 08:03.780 And that leads to some interesting problems with certain numbers of links. 168 08:03.780 --> 08:08.760 So for example, if I have two links here, oh, this isn't a big deal. 169 08:08.760 --> 08:10.800 I'll just evenly divide these numbers up. 170 08:10.800 --> 08:16.300 So maybe zero, one, two, three on one link, four, five, six, and seven on this 171 08:16.300 --> 08:17.440 other link. 172 08:17.440 --> 08:21.040 So if a packet has a result of five again, it's going to go on this link. 173 08:21.040 --> 08:24.520 If as a result of six, it'll also go on that link. 174 08:24.520 --> 08:28.320 Does this always result in it being perfectly load balanced between the two? 175 08:28.320 --> 08:31.560 Probably not, but it's going to get pretty close, at least. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 175 08:28.320 --> 08:31.560 Probably not, but it's going to get pretty close, at least. 176 08:31.560 --> 08:33.600 At least that's the hope. 177 08:33.600 --> 08:35.700 So now what happens if we have four? 178 08:35.700 --> 08:37.160 Well, same thing. 179 08:37.160 --> 08:38.360 I'm going to take these four links. 180 08:38.360 --> 08:40.040 I'm going to divide the numbers up. 181 08:40.040 --> 08:44.360 Maybe it's something like zero, one, and then two, three, four, five, six, and 182 08:44.360 --> 08:44.860 seven. 183 08:44.860 --> 08:47.780 So now if I have a five come through, it goes on this link. 184 08:47.780 --> 08:51.520 But if I have a six, it will go on the different link. 185 08:51.520 --> 08:56.620 And so again, as long as we've got enough, maybe we call entropy in the amount 186 08:56.620 --> 08:57.200 of data 187 08:57.200 --> 09:01.920 and amount of traffic flows that are coming through these switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 187 08:57.200 --> 09:01.920 and amount of traffic flows that are coming through these switches. 188 09:01.920 --> 09:06.140 Ideally, we end up load balancing across all four links, although a perfect 189 09:06.140 --> 09:06.600 load balance 190 09:06.600 --> 09:09.080 is probably still not realistic. 191 09:09.080 --> 09:10.720 But then things get a little interesting. 192 09:10.720 --> 09:13.800 What happens if I have something other than two, four, and eight? 193 09:13.800 --> 09:15.600 What if I have three links? 194 09:15.600 --> 09:17.840 One, two, and three. 195 09:17.840 --> 09:23.430 So I start to divide my numbers up and say, okay, well, let's do zero, one, two 196 09:23.430 --> 09:24.360 , three, 197 09:24.360 --> 09:26.560 four, five. 198 09:26.560 --> 09:30.680 And maybe I could go six and seven, something like that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 198 09:26.560 --> 09:30.680 And maybe I could go six and seven, something like that. 199 09:30.680 --> 09:34.830 Well, regardless of which numbers are used on which link, we see that I've got 200 09:34.830 --> 09:34.960 three 201 09:34.960 --> 09:40.520 numbers on the top link, three numbers in the second link, and two numbers on 202 09:40.520 --> 09:41.160 the bottom 203 09:41.160 --> 09:42.160 link. 204 09:42.160 --> 09:46.230 This means that this bottom link, if all things are created equal, will get two 205 09:46.230 --> 09:46.880 -thirds of 206 09:46.880 --> 09:49.480 the traffic of the other links. 207 09:49.480 --> 09:50.720 This isn't ideal. 208 09:50.720 --> 09:53.000 This is not an ideal load balancing situation. 209 09:53.000 --> 09:58.140 And we're going to find that this happens as well with five, six, and seven, 210 09:58.140 --> 09:59.000 because regardless 211 09:59.000 --> 10:03.470 of the number of links that I have in this range, I'm going to end up with some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 211 09:59.000 --> 10:03.470 of the number of links that I have in this range, I'm going to end up with some 212 10:03.470 --> 10:04.200 unbalanced 213 10:04.200 --> 10:05.400 number. 214 10:05.400 --> 10:08.640 So if I have five, for example, one, two, three, four, five, let's just start 215 10:08.640 --> 10:09.160 splitting 216 10:09.160 --> 10:15.940 up the numbers, one, two, zero, one, two, three, four, five, and six, and seven 217 10:15.940 --> 10:16.000 . 218 10:16.000 --> 10:21.050 So these two links down here will get one half of the traffic of all of these 219 10:21.050 --> 10:21.840 just because 220 10:21.840 --> 10:27.040 there are more hash results that can land on the top links. 221 10:27.040 --> 10:30.280 The idea, generally speaking, is that I should get an even number of all of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 221 10:27.040 --> 10:30.280 The idea, generally speaking, is that I should get an even number of all of 222 10:30.280 --> 10:31.120 these different 223 10:31.120 --> 10:35.050 hash results, again, so long as there's enough chaos and entropy in the data 224 10:35.050 --> 10:36.040 flows that exist 225 10:36.040 --> 10:37.480 in my network. 226 10:37.480 --> 10:42.790 So if I take an even number of these numbers, and then I divide them up among 227 10:42.790 --> 10:43.880 the different 228 10:43.880 --> 10:46.980 links in this way, well, again, this is where you might see twice as much 229 10:46.980 --> 10:47.640 traffic on one 230 10:47.640 --> 10:49.600 link compared to another. 231 10:49.600 --> 10:54.520 Because of this, in a perfect world, we only either have eight links in a port 232 10:54.520 --> 10:55.320 channel, 233 10:55.320 --> 10:58.040 or four links, or two links. 234 10:58.040 --> 11:01.000 That's what we'd want to aim for in any network design. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 234 10:58.040 --> 11:01.000 That's what we'd want to aim for in any network design. 235 11:01.000 --> 11:04.060 Now granted, I might deploy four links into my ether channel, and one of those 236 11:04.060 --> 11:04.640 links goes 237 11:04.640 --> 11:06.040 down for an extended time. 238 11:06.040 --> 11:09.360 Well, then we're operating as if we have three links and there will be 239 11:09.360 --> 11:10.520 imbalance there. 240 11:10.520 --> 11:14.440 But at least in steady state operation, we should be as balanced as possible. 241 11:14.440 --> 11:18.020 That is certainly going to be an element of network design and implementation 242 11:18.020 --> 11:18.360 that we're 243 11:18.360 --> 11:21.360 going to want to take with us when we're talking about real world networks.