WEBVTT 1 00:00.000 --> 00:05.520 In order to understand how a network starts to figure out which links should be 2 00:05.520 --> 00:06.000 blocked 3 00:06.000 --> 00:10.800 and who's the root of the network and all of these things, well, we're going to 4 00:10.800 --> 00:11.000 need 5 00:11.000 --> 00:15.000 a flow of information among the switches. 6 00:15.000 --> 00:19.000 And this flow of information is going to come in the form of bridge protocol 7 00:19.000 --> 00:21.000 data units or BPDUs. 8 00:21.000 --> 00:26.000 The BPDUs are what's going to share the information. 9 00:26.000 --> 00:30.000 And a lot of that information is going to have to do with my priority value. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:26.000 --> 00:30.000 And a lot of that information is going to have to do with my priority value. 10 00:30.000 --> 00:32.000 It's going to have to do with my MAC address. 11 00:32.000 --> 00:36.000 Once we know who the root is, it's going to be the cost to the root. 12 00:36.000 --> 00:41.450 And I can share all of this information by encapsulating it into a bridge 13 00:41.450 --> 00:45.000 protocol data unit and sending it out. 14 00:45.000 --> 00:48.450 Now what's interesting about this is that at first we might find that we send 15 00:48.450 --> 00:50.000 each other BPDUs, 16 00:50.000 --> 00:53.940 but we're going to very quickly realize that one of these two BPDUs is better 17 00:53.940 --> 00:55.000 than the other. 18 00:55.000 --> 00:59.000 And so let's say that the root of the network is up here. 19 00:59.000 --> 01:01.000 This would be called our root bridge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:59.000 --> 01:01.000 This would be called our root bridge. 20 01:01.000 --> 01:06.440 And as a result, the BPDU flowing downstream here, that would be known as the 21 01:06.440 --> 01:07.000 superior BPDU. 22 01:07.000 --> 01:13.450 We can have superior BPDUs, which imply usually a better priority or a better 23 01:13.450 --> 01:17.000 cost to root or even a better MAC address in the case of ties. 24 01:17.000 --> 01:21.430 Either way it's evaluated to be superior, and then the other one's going to be 25 01:21.430 --> 01:23.000 known as inferior. 26 01:23.000 --> 01:29.330 So the superior BPDU is going to take precedence over the inferior BPDU to the 27 01:29.330 --> 01:34.000 point that the inferior BPDU doesn't continue to get sent. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 27 01:29.330 --> 01:34.000 point that the inferior BPDU doesn't continue to get sent. 28 01:34.000 --> 01:38.000 This means that our BPDUs are all one way. 29 01:38.000 --> 01:43.430 We're going to send BPDUs down, and they're going to flow as if they're flowing 30 01:43.430 --> 01:45.000 down a waterfall. 31 01:45.000 --> 01:50.000 All right, BPDUs get sent downstream only. 32 01:50.000 --> 01:56.000 And it's only going to happen in one direction, so they are unidirectional. 33 01:56.000 --> 02:00.470 This is a very important part about the flow of information through the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 33 01:56.000 --> 02:00.470 This is a very important part about the flow of information through the 34 02:00.470 --> 02:02.000 spanning tree network. 35 02:02.000 --> 02:06.130 And although this changes just a little bit later on with Rapid Spanning Tree, 36 02:06.130 --> 02:10.000 Rapid Spanning Tree is still built on these fundamental principles, 37 02:10.000 --> 02:16.390 which is that the BPDUs start with the root and they get propagated down to the 38 02:16.390 --> 02:18.000 rest of the network. 39 02:18.000 --> 02:21.000 Now what happens on this link down here? 40 02:21.000 --> 02:25.600 Well, both of these switches, or bridges, depending on what we want to call 41 02:25.600 --> 02:28.000 them, are going to receive a BPDU, 42 02:28.000 --> 02:33.000 and they're going to want to send that BPDU further downstream. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 02:28.000 --> 02:33.000 and they're going to want to send that BPDU further downstream. 43 02:33.000 --> 02:36.000 The question is, which direction is downstream? 44 02:36.000 --> 02:41.630 Well, that is where we're going to land with this whole conversation, because 45 02:41.630 --> 02:43.000 we see that there's a loop here, 46 02:43.000 --> 02:47.000 and one of these ports must be placed into the blocking state. 47 02:47.000 --> 02:49.000 Let's say it's this one here. 48 02:49.000 --> 02:53.000 If that's in the blocking state, then we've prevented our loop, which is good. 49 02:53.000 --> 02:57.280 But that also says, is that this BPDU that was getting sent upstream, this is 50 02:57.280 --> 03:01.000 the inferior BPDU, and therefore we're not going to send it anymore. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 02:57.280 --> 03:01.000 the inferior BPDU, and therefore we're not going to send it anymore. 51 03:01.000 --> 03:07.300 Even as I continue to get BPDUs from the root, I would not forward them this 52 03:07.300 --> 03:08.000 direction. 53 03:08.000 --> 03:13.000 Instead, the BPDUs are going to flow this way, continuously. 54 03:13.000 --> 03:18.050 And so as I continue to get my BPDUs flowing through the network, we see how 55 03:18.050 --> 03:23.000 exactly they end up flowing, again, from a downstream perspective. 56 03:23.000 --> 03:28.210 Starting at the root, getting sent down to a switch, which then further sends 57 03:28.210 --> 03:32.000 its own BPDU downstream, which has a lot of the same information, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 57 03:28.210 --> 03:32.000 its own BPDU downstream, which has a lot of the same information, 58 03:32.000 --> 03:36.000 but also has its own information like its own MAC address. 59 03:36.000 --> 03:41.000 So it's not an exact copy of the BPDU that was received, but at the same time 60 03:41.000 --> 03:42.000 we use this as a triggering mechanism. 61 03:42.000 --> 03:48.070 To say, "Okay, now it's time for me to send my BPDU further downstream," which 62 03:48.070 --> 03:52.970 will include the information about the root, but it's also going to include my 63 03:52.970 --> 03:56.000 own MAC address, and so on and so forth. 64 03:56.000 --> 04:00.500 Now the first question we have to ask in a spanning tree network is, "How do we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 64 03:56.000 --> 04:00.500 Now the first question we have to ask in a spanning tree network is, "How do we 65 04:00.500 --> 04:02.000 determine the root?" 66 04:02.000 --> 04:05.000 This is going to come down to an election process. 67 04:08.000 --> 04:12.440 Any switch in the network can become the root, and so we have to figure out 68 04:12.440 --> 04:18.070 which one has the best configuration, essentially, to decide which one becomes 69 04:18.070 --> 04:19.000 the root. 70 04:19.000 --> 04:26.100 In order to do this, what we're going to do is we're going to compare what we 71 04:26.100 --> 04:28.000 call bridge IDs. 72 04:28.000 --> 04:32.580 The bridge ID consists of two values that are concatenated or essentially WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 72 04:28.000 --> 04:32.580 The bridge ID consists of two values that are concatenated or essentially 73 04:32.580 --> 04:34.000 smashed together. 74 04:34.000 --> 04:41.670 So we've got the priority value, and then we might put a colon here and say we 75 04:41.670 --> 04:45.000 're also going to add our system MAC address. 76 04:45.000 --> 04:51.000 Now the system MAC address is going to be determined by the operating system. 77 04:51.000 --> 04:55.350 For example, Cisco might decide that this is a MAC address that is virtual and 78 04:55.350 --> 04:59.990 they use it on their SBIs. It might be a reserved MAC address that's only used 79 04:59.990 --> 05:05.000 as the system MAC, but every piece of hardware, even within Cisco's portfolio, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 04:59.990 --> 05:05.000 as the system MAC, but every piece of hardware, even within Cisco's portfolio, 80 05:05.000 --> 05:09.260 and different operating systems will all have different ways of deciding what 81 05:09.260 --> 05:11.000 their system MAC address is. 82 05:11.000 --> 05:14.360 The best way to find that out is just to get on to a switch and run some show 83 05:14.360 --> 05:18.000 commands and figure out what exactly that MAC address is. 84 05:18.000 --> 05:25.000 So what's interesting about this is that we have the ability to also configure, 85 05:25.000 --> 05:29.000 so this is configurable, a priority value. 86 05:29.000 --> 05:37.000 This priority value ranges from 0 to 65, 535, and on Cisco devices for reasons WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 86 05:29.000 --> 05:37.000 This priority value ranges from 0 to 65, 535, and on Cisco devices for reasons 87 05:37.000 --> 05:42.000 we'll see later must be in increments of 4096. 88 05:42.000 --> 05:48.240 But zero is a value that we are able to use, so we could actually say zero, and 89 05:48.240 --> 05:54.270 it's important to realize as part of this conversation, is that the lowest 90 05:54.270 --> 05:56.000 value wins. 91 05:56.000 --> 06:01.050 Now I said this is part of our LACP conversation, and I like to say it a lot WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 05:56.000 --> 06:01.050 Now I said this is part of our LACP conversation, and I like to say it a lot 92 06:01.050 --> 06:05.850 because it comes up a lot, but when we're trying to remember whether it's the 93 06:05.850 --> 06:10.000 highest or the lowest wins for the vast majority of time, 94 06:10.000 --> 06:14.270 this is not a hard rule that works every single time, but as a way to help us 95 06:14.270 --> 06:20.300 remember, usually if we have a layer two protocol, it's the lower priority that 96 06:20.300 --> 06:21.000 wins. 97 06:21.000 --> 06:26.090 If we have a layer three protocol, for example, like OSPF or HSRP, then that's 98 06:26.090 --> 06:30.000 usually going to be that the higher priority value wins. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 06:26.090 --> 06:30.000 usually going to be that the higher priority value wins. 99 06:30.000 --> 06:33.840 It's kind of interesting how that came together, I don't know how intentional 100 06:33.840 --> 06:37.460 that was, but when we look at layer two protocols like LACP as well as spanning 101 06:37.460 --> 06:42.510 tree, it happens to be that the lowest value wins, whereas all routing 102 06:42.510 --> 06:46.000 protocols that I can think of off the top of my head, 103 06:46.000 --> 06:50.010 as well as again, first-topper redundancy protocols and layer three protocols, 104 06:50.010 --> 06:52.000 those all seem to like higher values. 105 06:52.000 --> 06:55.460 Keep that in mind, and just when you're learning about a protocol, if you find 106 06:55.460 --> 06:58.630 one that doesn't fit that model, then be sure to flag that otherwise if it 107 06:58.630 --> 07:02.060 comes down to trying to remember which is which, this can be our rule of thumb, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 107 06:58.630 --> 07:02.060 comes down to trying to remember which is which, this can be our rule of thumb, 108 07:02.060 --> 07:06.000 understanding that there might be some exceptions out there. 109 07:06.000 --> 07:09.960 So let's look at some examples here. When we look at Cisco's iOS default 110 07:09.960 --> 07:17.000 configuration, the default priority value is going to be $32,768. 111 07:17.000 --> 07:22.570 Now, when we're talking about these different priority values, usually we use a 112 07:22.570 --> 07:27.620 shorthand shortcut, whatever we call it here, I'd say this is 32K, where K 113 07:27.620 --> 07:32.000 stands for 1000, and so we see that it's about 32,000. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 113 07:27.620 --> 07:32.000 stands for 1000, and so we see that it's about 32,000. 114 07:32.000 --> 07:38.330 So we might say zero as a priority, we might say 4K for 4096, might say 8K and 115 07:38.330 --> 07:44.200 12K and 16K, those are all estimates, but it does tie back to specific values 116 07:44.200 --> 07:50.000 since they must be done or chosen on Cisco devices increments of 4096. 117 07:50.000 --> 07:56.190 So either way, we say that all the default priority values on iOS are 32K. So 118 07:56.190 --> 08:02.580 if I have two switches and I connect them together, the interesting thing when WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 07:56.190 --> 08:02.580 if I have two switches and I connect them together, the interesting thing when 119 08:02.580 --> 08:13.000 we first tie two switches together is that first, we all think I am the root. 120 08:13.000 --> 08:17.340 So I think I'm the root on the left, I think I'm the root on the right, and as 121 08:17.340 --> 08:21.000 a result, we're both going to try to start sending BPDUs. 122 08:21.000 --> 08:24.680 Now, one of these BPDUs is going to be superior, the other one's going to be 123 08:24.680 --> 08:28.400 inferior, but what's interesting about this is they both have the same priority 124 08:28.400 --> 08:29.000 value. 125 08:29.000 --> 08:41.310 So how do we end up deciding which one is going to win as root? Well, that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 125 08:29.000 --> 08:41.310 So how do we end up deciding which one is going to win as root? Well, that 126 08:41.310 --> 08:43.450 comes down to the second half of the priority or the bridge ID, rather, which 127 08:43.450 --> 08:45.410 is the system MAC address, because MAC addresses must be unique in the 128 08:45.410 --> 08:46.000 environment. 129 08:46.000 --> 08:52.190 One of these is going to win, because one of them is going to be lower than the 130 08:52.190 --> 08:57.200 other. So if they have basically the same MAC address except at the very end of 131 08:57.200 --> 09:02.000 the MAC address, we have a 01 on the left and we have a 05 on the right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 131 08:57.200 --> 09:02.000 the MAC address, we have a 01 on the left and we have a 05 on the right. 132 09:02.000 --> 09:15.050 Well, 01 is lower than 05 and as a result, that's going to end up winning. So 133 09:15.050 --> 09:16.560 we send the superior BPDU, which means once again the other switch, stop 134 09:16.560 --> 09:18.000 sending BPDUs altogether, because we do not send BPDUs upstream. 135 09:18.000 --> 09:22.320 Incidentally, if these BPDUs happen to cross at the same time, or if there's 136 09:22.320 --> 09:26.380 one switch that's just kind of not doing what it's supposed to do and it keeps 137 09:26.380 --> 09:31.060 sending BPDUs upstream, at that point the upstream device, knowing it has the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 137 09:26.380 --> 09:31.060 sending BPDUs upstream, at that point the upstream device, knowing it has the 138 09:31.060 --> 09:34.000 superior BPDU, it's just going to completely ignore those. 139 09:34.000 --> 09:37.210 So that switch on the left that first fires up, it says, "I'm the root, I think 140 09:37.210 --> 09:40.910 I'm the root." And so I'm just going to start sending BPDUs. And again, if they 141 09:40.910 --> 09:44.540 happen to cross at the same time and I receive the other BPDU, I'm going to 142 09:44.540 --> 09:47.000 look at it and say, "No, I'm still good. 143 09:47.000 --> 09:51.080 So I just keep sending them and I ignore inferior BPDUs." So inferior BPDUs, if 144 09:51.080 --> 09:54.760 they are received on a link, where they're not expected to and they truly are 145 09:54.760 --> 09:57.000 inferior, they will just be ignored. 146 09:57.000 --> 10:02.470 Meanwhile, the switch on the right, which receives the superior BPDU here, is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 146 09:57.000 --> 10:02.470 Meanwhile, the switch on the right, which receives the superior BPDU here, is 147 10:02.470 --> 10:07.780 going to ideally, in a proper scenario, realize that it's wrong, that this 148 10:07.780 --> 10:13.000 device has a better bridge ID and therefore it's going to become the root. 149 10:13.000 --> 10:17.110 Now, what if I wanted to change this? What if I want the device on the right to 150 10:17.110 --> 10:21.000 be the root? Well, I can't change the MAC address. The MAC address is unique 151 10:21.000 --> 10:26.000 and it's not configurable, whereas the priority is the configurable field. 152 10:26.000 --> 10:30.500 And it matters more because it's in more significant, the more significant WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 10:26.000 --> 10:30.500 And it matters more because it's in more significant, the more significant 153 10:30.500 --> 10:34.520 digits, so to speak. It's in the, if we want to think about it, like this is 154 10:34.520 --> 10:38.000 the ones in the tens column and this is the hundreds in the thousands column, 155 10:38.000 --> 10:42.000 even one change in priority here is going to completely overrule 156 10:42.000 --> 10:47.130 anything that happens down here. And so this is where I as the admin can get on 157 10:47.130 --> 10:54.040 here and say, "Okay, you're not 32K anymore. Now you're 28K or you're 24K or 158 10:54.040 --> 10:56.000 whatever value I want." 159 10:56.000 --> 11:01.180 As long as it's a multiple of 4096. And the idea here is that I'm making it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 159 10:56.000 --> 11:01.180 As long as it's a multiple of 4096. And the idea here is that I'm making it 160 11:01.180 --> 11:04.000 lower so that it's going to become the root. 161 11:04.000 --> 11:09.370 At that point, this becomes the superior BPDU because it doesn't matter that I 162 11:09.370 --> 11:13.930 have a higher MAC address anymore. What matters the most is I have a lower 163 11:13.930 --> 11:15.000 priority value. 164 11:15.000 --> 11:20.170 So that is how I control which device in the network is the root and I should 165 11:20.170 --> 11:26.060 absolutely 100% be intentional about which switch on my network is the root 166 11:26.060 --> 11:27.000 bridge. 167 11:27.000 --> 11:33.110 Now, incidentally, what if we have a real world network that's established and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 11:27.000 --> 11:33.110 Now, incidentally, what if we have a real world network that's established and 168 11:33.110 --> 11:38.320 I've got a root switch, maybe it's in my distribution layer and I've got my 169 11:38.320 --> 11:43.150 backup other distribution switch here, but ultimately I've got a bunch of 170 11:43.150 --> 11:45.000 access layer switches. 171 11:45.000 --> 11:50.040 And again, even in this scenario, I would only still have one root at a time 172 11:50.040 --> 11:54.010 when we're running Cisco. It's on a Pervy Land basis, but either way I have a 173 11:54.010 --> 11:56.000 single root in my spanning tree topology. 174 11:56.000 --> 12:00.160 So I'm probably going to be blocking a lot of links like this to make sure that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 174 11:56.000 --> 12:00.160 So I'm probably going to be blocking a lot of links like this to make sure that 175 12:00.160 --> 12:02.000 the network stays loop free. 176 12:02.000 --> 12:06.840 So that's well and good, but what happens if I bring a switch out and it's mis 177 12:06.840 --> 12:11.000 configured? So maybe this root has an 8K priority value. 178 12:11.000 --> 12:16.290 The switch on the right has 12K and all these other ones are using 32K, which 179 12:16.290 --> 12:19.000 is the default setting on Cisco switches. 180 12:19.000 --> 12:22.680 So if this root bridge goes down, this switch will take over as the root 181 12:22.680 --> 12:26.640 because it's in better shape than any of these switches down here, and that's 182 12:26.640 --> 12:28.000 exactly what we want. 183 12:28.000 --> 12:34.320 In fact, it's what we want, but notice it does require for me to now say, "Hey, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 183 12:28.000 --> 12:34.320 In fact, it's what we want, but notice it does require for me to now say, "Hey, 184 12:34.320 --> 12:38.000 guess what? I am the root because things have changed." 185 12:38.000 --> 12:41.870 Something on the network is different and now I have the lowest ID and that's 186 12:41.870 --> 12:44.000 because this root switch went down. 187 12:44.000 --> 12:48.710 But what happens if this switch is configured with a priority of 4K and I 188 12:48.710 --> 12:53.000 connect it up to, maybe I even connected it up to this switch over here? 189 12:53.000 --> 12:58.600 What happens in this scenario? Well, I send my superior BPDU and this switch 190 12:58.600 --> 13:01.000 says, "Oh, you're my upstream." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 190 12:58.600 --> 13:01.000 says, "Oh, you're my upstream." 191 13:01.000 --> 13:06.000 And therefore, I've got to completely change the way I view the network. 192 13:06.000 --> 13:10.430 So this superior BPDU ends up getting propagated throughout the rest of the 193 13:10.430 --> 13:14.000 network and now this switch does indeed become the root. 194 13:14.000 --> 13:18.000 I'm no longer the root here because 8K loses to 4K. 195 13:18.000 --> 13:23.100 This means that, yes, in a real-world environment, if we're not careful, I 196 13:23.100 --> 13:28.410 could plug in a switch that's misconfigured and this could actually cause major 197 13:28.410 --> 13:32.000 downtime on my network as the network converges over to the new root. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 197 13:28.410 --> 13:32.000 downtime on my network as the network converges over to the new root. 198 13:32.000 --> 13:37.010 Fortunately, we do have a way to protect against this. We have protection 199 13:37.010 --> 13:41.000 mechanisms that we can deploy but we have to make sure that we do deploy them. 200 13:41.000 --> 13:45.240 And this is why we're all sitting here learning about spanning tree because we 201 13:45.240 --> 13:49.240 need to be able to apply this to the real-world networks that we manage and 202 13:49.240 --> 13:57.130 understand that there's going to be configurable mechanisms that would go on to 203 13:57.130 --> 14:00.000 our network and would make it so much more resilient, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 203 13:57.130 --> 14:00.000 our network and would make it so much more resilient, 204 14:00.000 --> 14:04.390 not just the intentional configuration of our priority values but also these 205 14:04.390 --> 14:08.000 protection mechanisms we're going to end up talking about. 206 14:08.000 --> 14:11.550 And when we fully tune our networks to be this way, then they can be very 207 14:11.550 --> 14:13.000 stable and if we don't do it, 208 14:13.000 --> 14:19.000 well then we run the risk of causing major outages by making misconfigurations.