WEBVTT 0:00:03.020000 --> 0:00:06.180000 All right, welcome to this video where we're going to introduce the concept 0:00:06.180000 --> 0:00:10.580000 of spanning tree and what problems it was designed to solve, which is, 0:00:10.580000 --> 0:00:15.520000 as the type bill says, loop prevention, we're trying to prevent loops, 0:00:15.520000 --> 0:00:18.000000 and that is the goal of spanning tree. 0:00:18.000000 --> 0:00:19.780000 So this is a quick review. 0:00:19.780000 --> 0:00:22.220000 Hopefully you remember what a bridging loop is. 0:00:22.220000 --> 0:00:26.680000 It's when two switches have redundant connections between them, and both 0:00:26.680000 --> 0:00:30.160000 connections are wide open for the forwarding of traffic, which can cause 0:00:30.160000 --> 0:00:36.140000 especially broadcast frames to loop around indefinitely between the switches. 0:00:36.140000 --> 0:00:40.360000 And that can cause all sorts of problems like MAC address learning, rewrites, 0:00:40.360000 --> 0:00:45.160000 and deletions over and over and over again, many many times per second, 0:00:45.160000 --> 0:00:50.420000 CPU spikes on your switches, MAC addresses are learned on the wrong interfaces, 0:00:50.420000 --> 0:00:54.000000 all kinds of things can be happened with bridging loops. 0:00:54.000000 --> 0:00:57.400000 So spanning tree was originally designed to fix that. 0:00:57.400000 --> 0:01:03.740000 Now the original spanning tree was 802 .1d as in David, and that was introduced 0:01:03.740000 --> 0:01:08.180000 way back in like the late 1970s or early 1980s. 0:01:08.180000 --> 0:01:13.060000 That stuck around for a while, and then later on back in 2001, they updated 0:01:13.060000 --> 0:01:19.200000 it to the 802.1w standard, which was rapid spanning tree. 0:01:19.200000 --> 0:01:25.640000 And then 802.1w was folded into or incorporated into the official 802 0:01:25.640000 --> 0:01:28.840000 .1d standard in 2004. 0:01:28.840000 --> 0:01:33.840000 So if you want to see how the original 802.1d worked and get the specifics 0:01:33.840000 --> 0:01:38.460000 of that, you got to make sure that when you look up the IEEE 802.1d document, 0:01:38.460000 --> 0:01:41.600000 you're getting the like 1999 version. 0:01:41.600000 --> 0:01:47.500000 Anything from 2004 on will not show you the original 802.1d but the newer 0:01:47.500000 --> 0:01:50.180000 rapid spanning tree. 0:01:50.180000 --> 0:01:54.880000 Now this is usually called a common spanning tree because both the original 0:01:54.880000 --> 0:01:59.580000 802.1d as well as rapid spanning tree, one thing they both had in common 0:01:59.580000 --> 0:02:05.280000 was that neither one of them had any consideration of VLANs or VLAN trunks. 0:02:05.280000 --> 0:02:09.820000 The idea was, hey, if you've got three or four or 20 switches, they're 0:02:09.820000 --> 0:02:16.640000 all going to be in tree of some forwarding, some blocking ports, and the 0:02:16.640000 --> 0:02:19.800000 traffic is just going to have to follow whatever that tree says. 0:02:19.800000 --> 0:02:24.800000 It won't matter if that traffic belongs to VLAN 2 or 17 or 2000. 0:02:24.800000 --> 0:02:29.580000 It all has to follow that one common tree that was derived due to spanning 0:02:29.580000 --> 0:02:35.400000 tree. So there was no redundancy in traffic paths for frames. 0:02:35.400000 --> 0:02:38.360000 So once again, this is a review here as a concept of a tree. 0:02:38.360000 --> 0:02:41.060000 Here's the whole idea is that we have a lot of redundancy here. 0:02:41.060000 --> 0:02:44.780000 We have a lot of places where broadcast frames in particular could just 0:02:44.780000 --> 0:02:49.680000 loop. Basically, any place here where you see a triangle is an area where 0:02:49.680000 --> 0:02:51.720000 a bridging loop could occur. 0:02:51.720000 --> 0:02:55.660000 So spanning tree, I'll just say rapid spanning tree for the intents and 0:02:55.660000 --> 0:02:59.760000 purposes of this video, is designed to prevent this. 0:02:59.760000 --> 0:03:03.520000 We don't want our broadcast frames circling around there forever. 0:03:03.520000 --> 0:03:05.080000 We want to stop that. 0:03:05.080000 --> 0:03:09.460000 So the way rapid spanning tree does it is it says, look, I'm going to 0:03:09.460000 --> 0:03:12.840000 remove the redundant tree in this tree. 0:03:12.840000 --> 0:03:14.220000 I'm going to remove a bunch of links. 0:03:14.220000 --> 0:03:16.200000 I'm basically going to put them in the blocking state. 0:03:16.200000 --> 0:03:19.060000 I'm not going to shut the links down, but by putting them in the blocking 0:03:19.060000 --> 0:03:23.920000 state, no user data can come in or go out of that port. 0:03:23.920000 --> 0:03:26.980000 But once a port's in the blocking state from the perspective of your web 0:03:26.980000 --> 0:03:31.440000 browsing traffic, your telnet, your emails, that port doesn't exist. 0:03:31.440000 --> 0:03:34.820000 If you can't use it to send your data through it, it might as well not 0:03:34.820000 --> 0:03:40.020000 even be there. So what ends up looking like this ends up looking like 0:03:40.020000 --> 0:03:42.840000 this. Yes, your blocking ports basically vanish. 0:03:42.840000 --> 0:03:45.780000 And now your redundancy is gone. 0:03:45.780000 --> 0:03:48.840000 And so now there's no way that frames could loop around because from any 0:03:48.840000 --> 0:03:53.400000 two points point a to point b, there is only one path that could be used 0:03:53.400000 --> 0:03:58.820000 to get there. And that is the whole purpose of the various spanning trees 0:03:58.820000 --> 0:04:05.580000 that exist is to create a non-redundant loop free tree that we see right 0:04:05.580000 --> 0:04:11.320000 here. So that concludes this video on our refresher of the goals and purposes 0:04:11.320000 --> 0:04:12.840000 of spanning tree. 0:04:12.840000 --> 0:04:15.880000 Let's look at some further videos on how to actually implement this and 0:04:15.880000 --> 0:04:18.260000 how it creates this tree in the first place.