WEBVTT 1 00:00.000 --> 00:05.680 So, we are concerned about loops in a Layer 2 network. 2 00:05.680 --> 00:10.170 If we have this situation where we have two connections between two Layer 2 3 00:10.170 --> 00:10.840 devices, that 4 00:10.840 --> 00:14.770 this will create a loop, especially for broadcast packets, and we have to do 5 00:14.770 --> 00:15.800 something about 6 00:15.800 --> 00:16.800 that. 7 00:16.800 --> 00:21.680 But why do we care about this so much at Layer 2 and not Layer 3? 8 00:21.680 --> 00:26.330 Layer 3 seems like it can handle loops just fine whereas Layer 2 has a lot of 9 00:26.330 --> 00:27.080 issues. 10 00:27.080 --> 00:30.010 Well this has everything to do with the fact that we are running different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:27.080 --> 00:30.010 Well this has everything to do with the fact that we are running different 11 00:30.010 --> 00:30.680 protocols. 12 00:30.680 --> 00:34.200 We are running specifically Ethernet. 13 00:34.200 --> 00:36.320 Not every Layer 2 protocol has this problem. 14 00:36.320 --> 00:40.760 In fact, Ethernet is really one of the only ones that has this problem. 15 00:40.760 --> 00:46.420 And Ethernet was a protocol that happened to win out a long time ago, primarily 16 00:46.420 --> 00:47.080 because 17 00:47.080 --> 00:49.240 it was a cheap protocol. 18 00:49.240 --> 00:53.310 The hardware was cheaper than things like token ring and such, and so it won 19 00:53.310 --> 00:54.000 out, but one 20 00:54.000 --> 00:58.680 of the reasons it was cheaper is that it had some issues. 21 00:58.680 --> 01:02.770 The way it was deployed, it required less sophistication as a result, which is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:58.680 --> 01:02.770 The way it was deployed, it required less sophistication as a result, which is 22 01:02.770 --> 01:03.240 why it 23 01:03.240 --> 01:05.000 was cheaper. 24 01:05.000 --> 01:09.660 And sometimes the cheaper solution wins in an industry that needs to figure out 25 01:09.660 --> 01:10.080 which 26 01:10.080 --> 01:11.640 protocol it is going to get behind. 27 01:11.640 --> 01:14.400 So the industry got behind Ethernet. 28 01:14.400 --> 01:18.620 And within the Layer 3 world, we say, "Well, why doesn't this problem exist 29 01:18.620 --> 01:19.320 there?" 30 01:19.320 --> 01:23.920 Well it is because we run IP version 4 or IP version 6. 31 01:23.920 --> 01:26.200 And there's a couple of things working in our favor here. 32 01:26.200 --> 01:31.760 First of all, we have an actual control plane at the Layer 3 level, meaning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:26.200 --> 01:31.760 First of all, we have an actual control plane at the Layer 3 level, meaning 33 01:31.760 --> 01:32.920 that we're running 34 01:32.920 --> 01:39.880 some kind of routing protocol, so something like EIGRP or OSPF. 35 01:39.880 --> 01:42.680 Even static routing counts as a control plane. 36 01:42.680 --> 01:47.580 It's not a dynamic control plane, but it does provide us with a loop-free top 37 01:47.580 --> 01:48.360 ology in 38 01:48.360 --> 01:49.360 theory. 39 01:49.360 --> 01:54.350 EIGRP and OSPF handle that automatically for us, whereas static routing relies 40 01:54.350 --> 01:54.920 on us as 41 01:54.920 --> 02:00.370 admins being at least somewhat intentional about how we deploy our static WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 41 01:54.920 --> 02:00.370 admins being at least somewhat intentional about how we deploy our static 42 02:00.370 --> 02:01.240 routes. 43 02:01.240 --> 02:04.640 But in theory, these are creating loop-free topologies. 44 02:04.640 --> 02:08.550 Furthermore, in the event that there is a loop, we at least have something 45 02:08.550 --> 02:09.240 known as the 46 02:09.240 --> 02:11.280 Time to Live field. 47 02:11.280 --> 02:17.190 Time to live in IPv4 and IPv6 headers, make sure that eventually if a packet 48 02:17.190 --> 02:18.040 gets looped 49 02:18.040 --> 02:20.920 around, it will eventually get dropped. 50 02:20.920 --> 02:22.320 Either net doesn't have any of this. 51 02:22.320 --> 02:26.440 It doesn't have a control plane at all, and furthermore, it doesn't have any 52 02:26.440 --> 02:26.840 kind of 53 02:26.840 --> 02:31.600 mechanism to eventually time out a packet and allow it to drop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 53 02:26.840 --> 02:31.600 mechanism to eventually time out a packet and allow it to drop. 54 02:31.600 --> 02:35.380 And on top of that, it relies a lot more heavily on broadcasts, even though 55 02:35.380 --> 02:36.360 there are technically 56 02:36.360 --> 02:42.000 broadcast at Layer 3, we don't use them nearly as much as Layer 2 broadcasts. 57 02:42.000 --> 02:46.380 And so the fact that we have a lot of broadcast traffic, like DHCP requests for 58 02:46.380 --> 02:47.040 example, 59 02:47.040 --> 02:51.410 we rely on that at Layer 2, and therefore we're creating a bunch of it, and we 60 02:51.410 --> 02:52.000 don't have 61 02:52.000 --> 02:56.710 the mechanisms in place to make sure that a packet that gets sent out one link 62 02:56.710 --> 02:57.120 doesn't 63 02:57.120 --> 02:59.840 come right back and then get looped around. 64 02:59.840 --> 03:03.230 And indeed, this is the problem with the Ethernet, is that this is exactly what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 64 02:59.840 --> 03:03.230 And indeed, this is the problem with the Ethernet, is that this is exactly what 65 03:03.230 --> 03:04.280 will happen 66 03:04.280 --> 03:07.760 when we're talking about broadcast traffic. 67 03:07.760 --> 03:11.880 And for that matter, by the way, flooded traffic. 68 03:11.880 --> 03:15.020 Which from a behavior perspective is the same, but those are two different 69 03:15.020 --> 03:15.560 scenarios. 70 03:15.560 --> 03:19.830 So broadcast is intentionally sent out all interfaces, a flooded message is 71 03:19.830 --> 03:20.360 sent out 72 03:20.360 --> 03:24.480 simply because we don't know where the destination is. 73 03:24.480 --> 03:30.710 So this situation here is why we needed a hero to save us from the evils of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 03:24.480 --> 03:30.710 So this situation here is why we needed a hero to save us from the evils of 74 03:30.710 --> 03:31.840 this loop, 75 03:31.840 --> 03:36.480 and that hero takes the form of spanning tree protocol. 76 03:36.480 --> 03:38.680 Now I know what you're thinking already. 77 03:38.680 --> 03:42.840 Spanning tree protocol is typically treated like a villain, not a hero. 78 03:42.840 --> 03:45.400 So why are we talking about it in this way? 79 03:45.400 --> 03:49.480 Well, it's because it actually is accomplishing something that we desperately 80 03:49.480 --> 03:49.960 need. 81 03:49.960 --> 03:54.240 It's creating a loop-free logical topology. 82 03:54.240 --> 04:02.160 And I say logical because it still allows for there to be a physical loop. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 82 03:54.240 --> 04:02.160 And I say logical because it still allows for there to be a physical loop. 83 04:02.160 --> 04:07.570 We have physical connections, we have created a physical loop here, and yet it 84 04:07.570 --> 04:08.480 's creating 85 04:08.480 --> 04:13.520 a loop-free logical topology over the top of this. 86 04:13.520 --> 04:21.400 This basically means that from Ethernet's perspective, Ethernet sees no loops. 87 04:21.400 --> 04:24.940 And that's what's going to prevent us from hitting these issues with flooded 88 04:24.940 --> 04:25.680 and broadcast 89 04:25.680 --> 04:26.680 traffic. 90 04:26.680 --> 04:30.700 Now, spanning tree protocol was invented all the way back if we can believe WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:26.680 --> 04:30.700 Now, spanning tree protocol was invented all the way back if we can believe 91 04:30.700 --> 04:32.640 this in 1990. 92 04:32.640 --> 04:36.720 And yes, for those of us who are younger, we did have networks back in 1990. 93 04:36.720 --> 04:40.770 I myself was pretty young at that point and not in the networking world, let 94 04:40.770 --> 04:41.440 alone even 95 04:41.440 --> 04:47.720 in middle school, but at the same time, we had Ethernet networks this early. 96 04:47.720 --> 04:51.980 And it was quickly discovered that, you know, yeah, we could build a physical 97 04:51.980 --> 04:52.440 loop-free 98 04:52.440 --> 04:53.920 topology. 99 04:53.920 --> 04:57.720 But then if this connection goes down, we've broken our network. 100 04:57.720 --> 05:03.840 We'd really like to have a physical loop just for the sake of redundancy. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 04:57.720 --> 05:03.840 We'd really like to have a physical loop just for the sake of redundancy. 101 05:03.840 --> 05:07.290 And furthermore, even if we don't care about the redundancy because in 1990 our 102 05:07.290 --> 05:07.720 networks 103 05:07.720 --> 05:11.990 weren't that critical, we still needed to worry about somebody coming along and 104 05:11.990 --> 05:12.400 saying, 105 05:12.400 --> 05:15.280 "Oh, well, this cable's here, maybe in the event of a failure. 106 05:15.280 --> 05:16.280 It's just not plugged in. 107 05:16.280 --> 05:17.680 Oh, I'll go ahead and plug it in." 108 05:17.680 --> 05:20.990 It looks like somebody accidentally left it unplugged and they plug it in and 109 05:20.990 --> 05:21.560 it creates 110 05:21.560 --> 05:22.560 a loop. 111 05:22.560 --> 05:25.480 And that is going to take down our whole network. 112 05:25.480 --> 05:32.200 So we needed something to step in and that was spanning tree protocol. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 112 05:25.480 --> 05:32.200 So we needed something to step in and that was spanning tree protocol. 113 05:32.200 --> 05:39.630 Tree protocol was the work famously of Radiopherlman and she famously wrote a 114 05:39.630 --> 05:41.520 poem about spanning 115 05:41.520 --> 05:44.120 tree and it goes something like this. 116 05:44.120 --> 05:48.600 I think that I shall never see a graph more lovely than a tree. 117 05:48.600 --> 05:53.640 A tree whose crucial property is loop-free connectivity. 118 05:53.640 --> 05:55.800 So just a bit of a poet as well. 119 05:55.800 --> 06:01.120 And it's a poem you can go Google that or run internet search and see that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 119 05:55.800 --> 06:01.120 And it's a poem you can go Google that or run internet search and see that. 120 06:01.120 --> 06:04.880 But in the end she and her group came up with this based on a lot of 121 06:04.880 --> 06:06.400 mathematical functions. 122 06:06.400 --> 06:12.640 The idea was to create sort of that mathematical tree concept where everything 123 06:12.640 --> 06:13.920 logically hangs 124 06:13.920 --> 06:17.720 off of something else in a tree format. 125 06:17.720 --> 06:20.040 Now you say, "How does that look like a tree?" 126 06:20.040 --> 06:22.120 Well, flip it upside down. 127 06:22.120 --> 06:23.680 Now look at it. 128 06:23.680 --> 06:28.280 When we flip it upside down and we draw things from the root perspective, we do 129 06:28.280 --> 06:28.800 start to 130 06:28.800 --> 06:33.080 see that, oh yeah, that kind of grows like a tree and here at the bottom we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 130 06:28.800 --> 06:33.080 see that, oh yeah, that kind of grows like a tree and here at the bottom we 131 06:33.080 --> 06:33.560 could call 132 06:33.560 --> 06:35.200 this the root. 133 06:35.200 --> 06:36.480 Hmm, interesting. 134 06:36.480 --> 06:40.300 I think that we're going to see a lot more about these spanning tree roots as 135 06:40.300 --> 06:40.740 we talk 136 06:40.740 --> 06:43.240 more and more about the technology. 137 06:43.240 --> 06:44.240 But this is the idea. 138 06:44.240 --> 06:49.040 We might have physical connections in here. 139 06:49.040 --> 06:53.080 But in the end those physical connections are used for redundancy. 140 06:53.080 --> 06:55.320 They're not used to forward traffic. 141 06:55.320 --> 07:01.090 And so when broadcast messages arrive somewhere in the network, we now see that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 141 06:55.320 --> 07:01.090 And so when broadcast messages arrive somewhere in the network, we now see that 142 07:01.090 --> 07:01.880 they can get 143 07:01.880 --> 07:05.040 sent out in that loop free topology. 144 07:05.040 --> 07:07.520 So that is the goal of spanning tree protocol. 145 07:07.520 --> 07:12.690 And again, even though sometimes it gets a bad rap, mostly because we're 146 07:12.690 --> 07:13.800 talking about 147 07:13.800 --> 07:18.080 our spanning tree loops that get formed, what we're really saying is it's a 148 07:18.080 --> 07:18.760 loop that 149 07:18.760 --> 07:21.840 isn't protected by spanning tree for some reason. 150 07:21.840 --> 07:24.800 This is not a flaw of spanning tree, although I guess it could be a flaw of the 151 07:24.800 --> 07:25.360 spanning 152 07:25.360 --> 07:27.880 tree process or something along those lines. 153 07:27.880 --> 07:31.360 Ultimately, it's a flaw of ethernet. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 153 07:27.880 --> 07:31.360 Ultimately, it's a flaw of ethernet. 154 07:31.360 --> 07:33.280 Ethernet is the problem. 155 07:33.280 --> 07:36.760 Spanning tree protocol is a solution to that problem. 156 07:36.760 --> 07:40.450 And what we'll find is sometimes it's not a perfect solution to the point that 157 07:40.450 --> 07:40.960 we'd really 158 07:40.960 --> 07:43.000 rather not rely on it at all. 159 07:43.000 --> 07:46.680 This is why we come up with technologies like ether channels. 160 07:46.680 --> 07:48.600 We just talked about ether channels. 161 07:48.600 --> 07:52.360 I would really rather not rely on spanning tree. 162 07:52.360 --> 07:56.860 If I've got two links here, I could block one of these ports and that prevents 163 07:56.860 --> 07:57.600 a loop. 164 07:57.600 --> 08:02.550 But for a lot of reasons, we might just want to bundle these together and that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 164 07:57.600 --> 08:02.550 But for a lot of reasons, we might just want to bundle these together and that 165 08:02.550 --> 08:03.640 gives us 166 08:03.640 --> 08:08.010 redundancy, it gives us bandwidth and it removes the need for spanning tree to 167 08:08.010 --> 08:08.680 even have to 168 08:08.680 --> 08:11.400 worry about blocking a port. 169 08:11.400 --> 08:16.720 And so this is why as we build out modern networking topologies by using 170 08:16.720 --> 08:18.560 chassis switches. 171 08:18.560 --> 08:21.680 And stackable switches. 172 08:21.680 --> 08:26.700 As well as things like multi-chassis ether channels and virtual port channels, 173 08:26.700 --> 08:27.200 a lot of 174 08:27.200 --> 08:33.020 the goal of this is to eliminate the need for spanning tree to be blocking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 174 08:27.200 --> 08:33.020 the goal of this is to eliminate the need for spanning tree to be blocking 175 08:33.020 --> 08:33.960 ports. 176 08:33.960 --> 08:38.530 That said, spanning tree can't just go away, it needs to continue to run just 177 08:38.530 --> 08:39.360 in case there's 178 08:39.360 --> 08:40.440 a loop. 179 08:40.440 --> 08:44.630 But if we can prevent spanning tree from being a critical part of the process, 180 08:44.630 --> 08:44.880 what we're 181 08:44.880 --> 08:49.710 really saying is we'll build our own physical loop for e topology by leveraging 182 08:49.710 --> 08:50.240 some of 183 08:50.240 --> 08:53.120 these special technologies. 184 08:53.120 --> 08:57.920 Now when spanning tree was created, it ended up getting standardized as an IEEE 185 08:57.920 --> 08:59.040 specification, 186 08:59.040 --> 09:01.960 which is 802.1d. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 186 08:59.040 --> 09:01.960 which is 802.1d. 187 09:01.960 --> 09:07.040 We often will refer to 802.1d as sort of traditional spanning tree protocol, 188 09:07.040 --> 09:07.920 the protocol 189 09:07.920 --> 09:10.440 that was originally created. 190 09:10.440 --> 09:15.350 This protocol has a lot of characteristics that we're a lot of us are familiar 191 09:15.350 --> 09:15.960 with. 192 09:15.960 --> 09:20.160 For example, we often talk about the timers that are associated with 193 09:20.160 --> 09:21.600 traditional spanning 194 09:21.600 --> 09:22.600 tree. 195 09:22.600 --> 09:30.160 And we're going to talk about the election process as well as priorities. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 195 09:22.600 --> 09:30.160 And we're going to talk about the election process as well as priorities. 196 09:30.160 --> 09:33.640 But spanning tree, like a lot of technologies, evolved over time. 197 09:33.640 --> 09:39.280 And we eventually saw the creation of two new standardizations, 802.1w, which 198 09:39.280 --> 09:39.880 is known 199 09:39.880 --> 09:48.310 as rapid spanning tree, and then also 802.1s, which is known as multiple 200 09:48.310 --> 09:50.000 spanning tree or 201 09:50.000 --> 09:51.640 mst. 202 09:51.640 --> 09:55.620 Now we say, well, okay, that's cool and all, but does that mean that all of 203 09:55.620 --> 09:56.720 these properties 204 09:56.720 --> 09:57.840 are no longer needed? 205 09:57.840 --> 10:02.770 The answer is no, actually, all of these properties are going to be used WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 205 09:57.840 --> 10:02.770 The answer is no, actually, all of these properties are going to be used 206 10:02.770 --> 10:03.960 heavily by these newer 207 10:03.960 --> 10:08.040 forms and more modern forms of spanning tree protocol. 208 10:08.040 --> 10:13.880 So this is why we start by learning the basic traditional spanning tree. 209 10:13.880 --> 10:17.900 The purpose is not for us to say, hey, in our networks, go deploy 802.1d 210 10:17.900 --> 10:19.760 spanning tree, 211 10:19.760 --> 10:21.960 because nobody should be running that today. 212 10:21.960 --> 10:25.540 But sometimes in order to understand how a modern protocol works, we need to 213 10:25.540 --> 10:26.160 understand 214 10:26.160 --> 10:28.910 where it came from, sort of that, if we're going to know where we're going, we 215 10:28.910 --> 10:29.280 need to 216 10:29.280 --> 10:31.360 know where we came from. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 216 10:29.280 --> 10:31.360 know where we came from. 217 10:31.360 --> 10:33.720 And that's this situation exactly. 218 10:33.720 --> 10:38.300 So we're going to start by drilling into 802.1d and making sure we fully 219 10:38.300 --> 10:39.640 understand the election 220 10:39.640 --> 10:44.300 process, the priority values, the way ports are blocked, and the timers, 221 10:44.300 --> 10:45.040 because even 222 10:45.040 --> 10:50.090 the timers are used exactly the same way by rapid and mst might say, well, wait 223 10:50.090 --> 10:50.600 a second, 224 10:50.600 --> 10:52.000 wouldn't the timers be faster? 225 10:52.000 --> 10:54.640 No, they're not any faster with rapid spanning tree. 226 10:54.640 --> 11:00.240 It uses a different mechanism, but yet it falls back on the timer mechanism. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 226 10:54.640 --> 11:00.240 It uses a different mechanism, but yet it falls back on the timer mechanism. 227 11:00.240 --> 11:06.060 So we must learn, we must understand all of these basic tenets of 802.1d in 228 11:06.060 --> 11:06.880 order to then 229 11:06.880 --> 11:11.040 talk about rapid and multi-span multiple spanning tree as well. 230 11:11.040 --> 11:16.870 Of course, as Cisco's per VLAN spanning tree, PVSD plus and the rapid flavor of 231 11:16.870 --> 11:17.680 that. 232 11:17.680 --> 11:22.050 So let's go ahead and dive into that and start to see how spanning tree 233 11:22.050 --> 11:23.160 protocol is able 234 11:23.160 --> 11:28.690 to create a loop free topology automatically for us and prevent those broadcast 235 11:28.690 --> 11:29.360 storms.