WEBVTT 1 00:00.000 --> 00:02.040 All right, same deal here. 2 00:02.040 --> 00:06.480 We are going to go through a quiz of six questions once again, and we're going 3 00:06.480 --> 00:06.720 to talk 4 00:06.720 --> 00:10.730 about rapid spanning tree and understand how it changes from traditional 5 00:10.730 --> 00:11.960 spanning tree, 6 00:11.960 --> 00:17.280 and also talk about multiple spanning tree MST and how it differs from rapid PV 7 00:17.280 --> 00:18.400 ST plus. 8 00:18.400 --> 00:22.050 So first question here, what is the primary mechanism used for faster 9 00:22.050 --> 00:25.000 convergence in 802.1w 10 00:25.000 --> 00:27.000 rapid spanning tree? 11 00:27.000 --> 00:30.590 Well, rapid spanning tree, there's one takeaway we have from all of these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:27.000 --> 00:30.590 Well, rapid spanning tree, there's one takeaway we have from all of these 12 00:30.590 --> 00:31.600 conversations is 13 00:31.600 --> 00:36.400 that it's going to rely on switch negotiation rather than something like faster 14 00:36.400 --> 00:37.000 timers or 15 00:37.000 --> 00:39.240 even requiring better bandwidth. 16 00:39.240 --> 00:43.250 The idea here is that in traditional spanning tree, we're going to connect 17 00:43.250 --> 00:44.240 these two switches 18 00:44.240 --> 00:47.530 and they're going to send BPDUs back and forth, and the switch with the 19 00:47.530 --> 00:48.800 inferior BPDU is just 20 00:48.800 --> 00:52.690 going to stop sending them, leaving this switch to just sort of hope that the 21 00:52.690 --> 00:54.480 other side places 22 00:54.480 --> 00:58.680 it's poured into blocking or otherwise figures out another port to block. 23 00:58.680 --> 01:03.360 In our situation with a rapid spanning tree, instead of simply stopping to send WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 23 00:58.680 --> 01:03.360 In our situation with a rapid spanning tree, instead of simply stopping to send 24 01:03.360 --> 01:04.200 the inferior 25 01:04.200 --> 01:08.350 BPDUs, I'm going to still send an upstream message that says, hey, guess what, 26 01:08.350 --> 01:08.760 I'm going 27 01:08.760 --> 01:13.130 to block my port or I'm going to be, or this is going to be my root port, one 28 01:13.130 --> 01:14.360 of the two, 29 01:14.360 --> 01:18.520 and as a result, we can just bring this connection online immediately. 30 01:18.520 --> 01:20.840 We don't have to wait for 30 seconds. 31 01:20.840 --> 01:24.820 And so even though the timers are the exact same and they are, by default, with 32 01:24.820 --> 01:25.200 rapid 33 01:25.200 --> 01:29.220 spanning tree, all three timers have the same values, we are still a whole lot 34 01:29.220 --> 01:30.480 faster because WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 34 01:29.220 --> 01:30.480 faster because 35 01:30.480 --> 01:36.230 of these negotiations and messages that we can send essentially agreeing that 36 01:36.230 --> 01:36.960 we are going 37 01:36.960 --> 01:41.560 to establish these ports in a specific state. 38 01:41.560 --> 01:46.560 Question two, what two port states were eliminated by rapid STP? 39 01:46.560 --> 01:50.710 And technically there was another state that was in this, I just couldn't 40 01:50.710 --> 01:51.680 really include 41 01:51.680 --> 01:56.240 it for the sake of the fact that it has the same three letters, but the 42 01:56.240 --> 01:57.360 disabled state 43 01:57.360 --> 01:59.680 as well was removed. 44 01:59.680 --> 02:01.720 So let's go and dive into this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 01:59.680 --> 02:01.720 So let's go and dive into this. 45 02:01.720 --> 02:07.350 Remember, what we recognize at some point is that if we're blocking, if we're 46 02:07.350 --> 02:07.880 in the 47 02:07.880 --> 02:12.020 listening state, and if we're in the disabled state here, that would be a port 48 02:12.020 --> 02:12.920 is shut down 49 02:12.920 --> 02:17.260 or not running spanning tree in either any of these cases, we're doing the 50 02:17.260 --> 02:17.920 exact same 51 02:17.920 --> 02:18.920 thing. 52 02:18.920 --> 02:23.240 We are discarding the traffic that comes in. 53 02:23.240 --> 02:27.560 As a result, this state replaces all three of these states. 54 02:27.560 --> 02:29.200 So yeah, we could call it DIS. 55 02:29.200 --> 02:33.200 We just have to be careful because DIS stood for disabled and the traditional WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 02:29.200 --> 02:33.200 We just have to be careful because DIS stood for disabled and the traditional 56 02:33.200 --> 02:33.800 spanning 57 02:33.800 --> 02:34.800 tree. 58 02:34.800 --> 02:37.320 And so that's why I couldn't include it in the question. 59 02:37.320 --> 02:39.440 But either way, we only have three states. 60 02:39.440 --> 02:40.720 We have forwarding. 61 02:40.720 --> 02:43.160 We have learning and we have discarding. 62 02:43.160 --> 02:45.040 Just keep in mind a couple of things. 63 02:45.040 --> 02:48.910 First of all, even though listening doesn't actually show up in the command 64 02:48.910 --> 02:49.600 line, it's 65 02:49.600 --> 02:53.080 pretty rare that we actually see states in rapid spanning tree. 66 02:53.080 --> 02:56.760 We don't typically progress through listening and learning, so to speak. 67 02:56.760 --> 03:01.610 But if we do see it happening, we will see it go through the discarding state WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 67 02:56.760 --> 03:01.610 But if we do see it happening, we will see it go through the discarding state 68 03:01.610 --> 03:02.280 and then 69 03:02.280 --> 03:06.720 directly into the learning state still for 15 seconds at a time by default. 70 03:06.720 --> 03:10.450 So we do still wait for 30 seconds if we don't get those negotiations to work 71 03:10.450 --> 03:11.040 for whatever 72 03:11.040 --> 03:12.440 reason. 73 03:12.440 --> 03:16.290 But also we don't see this happen very often because again, rapid spanning tree 74 03:16.290 --> 03:16.720 brings 75 03:16.720 --> 03:19.560 ports online immediately in most situations. 76 03:19.560 --> 03:24.600 The other thing to consider is that Cisco still uses BLK at the command line. 77 03:24.600 --> 03:25.920 So we do show spanning tree. 78 03:25.920 --> 03:29.280 We're going to see BLK representing a discarding link. 79 03:29.280 --> 03:34.250 And so the terminology can get a little bit, get our wires crossed, I suppose, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 79 03:29.280 --> 03:34.250 And so the terminology can get a little bit, get our wires crossed, I suppose, 80 03:34.250 --> 03:34.880 a couple 81 03:34.880 --> 03:38.880 of times when we're running Cisco commands between traditional and rapid 82 03:38.880 --> 03:39.840 spanning tree. 83 03:39.840 --> 03:45.600 But do be aware that there are only three states in rapid spanning tree. 84 03:45.600 --> 03:47.360 So that was a question on port states. 85 03:47.360 --> 03:49.480 Let's talk about port roles. 86 03:49.480 --> 03:54.880 Now we want to identify the rapid spanning tree port role used for each of the 87 03:54.880 --> 03:55.760 following 88 03:55.760 --> 03:58.040 topology locations. 89 03:58.040 --> 04:04.800 So when we're looking at a connection here, we're going to have the concept of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 03:58.040 --> 04:04.800 So when we're looking at a connection here, we're going to have the concept of 90 04:04.800 --> 04:05.320 let's 91 04:05.320 --> 04:07.760 say this is the root port, we're going to have downstream ports, we're going to 92 04:07.760 --> 04:08.000 have 93 04:08.000 --> 04:12.630 upstream ports, we're going to have potentially other upstream ports that could 94 04:12.630 --> 04:13.480 go a different 95 04:13.480 --> 04:14.480 way. 96 04:14.480 --> 04:17.830 And then we might have two different types of downstream ports, one where we're 97 04:17.830 --> 04:18.280 blocking 98 04:18.280 --> 04:19.920 and one where we're not. 99 04:19.920 --> 04:23.850 So same thing here, we might have one that we're blocking on the left and one 100 04:23.850 --> 04:24.400 where we're 101 04:24.400 --> 04:26.040 not going straight up. 102 04:26.040 --> 04:31.090 So these are the four situations where we need to figure out what port role is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 102 04:26.040 --> 04:31.090 So these are the four situations where we need to figure out what port role is 103 04:31.090 --> 04:31.960 used for each 104 04:31.960 --> 04:33.360 one. 105 04:33.360 --> 04:38.400 So as we go through these upstream blocking, if I'm blocking this, this is 106 04:38.400 --> 04:39.200 going to be 107 04:39.200 --> 04:42.880 serving as an alternate port. 108 04:42.880 --> 04:46.480 Remember we got rid of the blocking or the non designated, we're just saying, 109 04:46.480 --> 04:46.840 Hey, this 110 04:46.840 --> 04:48.400 is an alternate port. 111 04:48.400 --> 04:52.630 If this link goes down, my my upstream forwarding port goes down, I can 112 04:52.630 --> 04:54.240 immediately transition 113 04:54.240 --> 04:58.400 this into the forwarding state, that makes it an alternate port. 114 04:58.400 --> 05:02.320 My upstream forwarding is simply my root port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 114 04:58.400 --> 05:02.320 My upstream forwarding is simply my root port. 115 05:02.320 --> 05:04.880 This doesn't change from traditional spanning tree. 116 05:04.880 --> 05:08.510 The one that faces the route that's my best path to the route is going to be my 117 05:08.510 --> 05:09.960 root port. 118 05:09.960 --> 05:14.000 Now downstream is interesting because usually we are forwarding downstream. 119 05:14.000 --> 05:17.920 At this point, we call this a designated port. 120 05:17.920 --> 05:21.200 And this again doesn't change from traditional spanning tree. 121 05:21.200 --> 05:24.040 But what is that downstream blocking situation? 122 05:24.040 --> 05:28.440 Well, again, we have a situation where we might have a hub in the network. 123 05:28.440 --> 05:34.200 And if we have two connections going into a hub, these BPDUs are going to cross WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 123 05:28.440 --> 05:34.200 And if we have two connections going into a hub, these BPDUs are going to cross 124 05:34.200 --> 05:34.920 through 125 05:34.920 --> 05:39.800 the hub and we're going to see essentially our, we're connecting to ourselves. 126 05:39.800 --> 05:43.680 And technically, if we have a switch and we loop a cable between two ports, 127 05:43.680 --> 05:44.280 then we'd 128 05:44.280 --> 05:45.720 see this as well. 129 05:45.720 --> 05:49.060 So whichever one of these is in a forwarding state, that's going to be my 130 05:49.060 --> 05:50.040 designated port, 131 05:50.040 --> 05:55.200 whichever one is in a blocking state, that is going to be a backup port. 132 05:55.200 --> 05:59.090 It's essentially saying that, hey, if for any reason this other link goes down, 133 05:59.090 --> 05:59.320 I can 134 05:59.320 --> 06:00.320 bring this online. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 134 05:59.320 --> 06:00.320 bring this online. 135 06:00.320 --> 06:02.640 It's just not going to come online quickly and that's fine. 136 06:02.640 --> 06:07.320 We can't really use rapid spanning tree mechanisms where there's hubs or other 137 06:07.320 --> 06:08.040 wacky things 138 06:08.040 --> 06:10.240 like this happening in the network. 139 06:10.240 --> 06:13.350 For the most part, we're not going to see a whole lot of backup ports in our 140 06:13.350 --> 06:13.800 modern 141 06:13.800 --> 06:14.800 networks. 142 06:14.800 --> 06:19.240 We should see one root port as many alternate ports as we can have. 143 06:19.240 --> 06:22.400 And paths to the root, those would be all of our blocking ports. 144 06:22.400 --> 06:26.920 And then as many designated ports as we have facing downstream. 145 06:26.920 --> 06:32.010 Question four, how does an RSTP or rapid spanning tree device respond to a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 145 06:26.920 --> 06:32.010 Question four, how does an RSTP or rapid spanning tree device respond to a 146 06:32.010 --> 06:33.360 change in the STP 147 06:33.360 --> 06:34.820 topology? 148 06:34.820 --> 06:38.720 This is a big conversation in traditional spanning tree and rapid. 149 06:38.720 --> 06:41.000 It's the topology change notifications. 150 06:41.000 --> 06:45.230 The goal is to convert spanning tree, but in a way where we're not black hole 151 06:45.230 --> 06:46.240 in traffic, 152 06:46.240 --> 06:50.460 where maybe because of the topology change now, I should send a packet that I 153 06:50.460 --> 06:50.920 get in. 154 06:50.920 --> 06:53.640 I should send it this way instead. 155 06:53.640 --> 06:56.840 But before the change, I should have sent it this way. 156 06:56.840 --> 07:00.420 So I still think that I should send it that way, even though spanning tree is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 156 06:56.840 --> 07:00.420 So I still think that I should send it that way, even though spanning tree is 157 07:00.420 --> 07:01.280 converged, 158 07:01.280 --> 07:05.180 even though maybe there's a switch down here that used to connect upstream and 159 07:05.180 --> 07:05.640 it's no 160 07:05.640 --> 07:06.640 longer there. 161 07:06.640 --> 07:09.840 And therefore, this is going to black hole the traffic just going to send it 162 07:09.840 --> 07:10.240 off and 163 07:10.240 --> 07:11.640 let it get dropped. 164 07:11.640 --> 07:13.920 So we want to update this as fast as possible. 165 07:13.920 --> 07:19.720 The problem is that rapid spanning tree is so fast that we just have to do what 166 07:19.720 --> 07:20.760 B suggests, 167 07:20.760 --> 07:25.040 which is to flush our Macaductress tables and set the aging timer to zero. 168 07:25.040 --> 07:28.910 Now the amount of time we do that is for three hello timers, which might be six 169 07:28.910 --> 07:29.400 seconds 170 07:29.400 --> 07:30.840 if we're using the default value. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 170 07:29.400 --> 07:30.840 if we're using the default value. 171 07:30.840 --> 07:35.460 So it's not for a very long time, but it's all the more reason to reduce TCNs 172 07:35.460 --> 07:36.840 in the environment. 173 07:36.840 --> 07:40.930 One of the ways we can do that is by putting port faster, port type edge ports 174 07:40.930 --> 07:41.680 everywhere 175 07:41.680 --> 07:46.280 where we have end devices connecting. 176 07:46.280 --> 07:50.260 Because every time I exist in this topology change status of having an aging 177 07:50.260 --> 07:50.880 timer set 178 07:50.880 --> 07:54.880 to zero and flushing my Macadress table, I'm going to be flooding a lot of 179 07:54.880 --> 07:55.760 traffic because 180 07:55.760 --> 07:57.560 I'm not learning any Macadresses. 181 07:57.560 --> 08:02.040 So it's going to turn my network into a massive flooding domain. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 181 07:57.560 --> 08:02.040 So it's going to turn my network into a massive flooding domain. 182 08:02.040 --> 08:04.840 And again, for six seconds, that's fine. 183 08:04.840 --> 08:08.820 But if it continues to happen constantly, then we have a big problem, 184 08:08.820 --> 08:09.800 especially in a 185 08:09.800 --> 08:11.800 rapid spanning tree environment. 186 08:11.800 --> 08:18.210 All right, question five, what does multiple STP or MST accomplish that Cisco's 187 08:18.210 --> 08:18.800 rapid 188 08:18.800 --> 08:20.840 PVST plus is unable to do? 189 08:20.840 --> 08:24.120 Well, this is a big factor with MST. 190 08:24.120 --> 08:28.360 MST looked at rapid per VLAN spanning tree and said, hey, what you guys are 191 08:28.360 --> 08:29.000 doing is 192 08:29.000 --> 08:30.000 great. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 192 08:29.000 --> 08:30.000 great. 193 08:30.000 --> 08:31.000 However, it's inefficient. 194 08:31.000 --> 08:34.920 If I have 100 VLANs, then that's going to be 100 topologies. 195 08:34.920 --> 08:36.000 And that's no good. 196 08:36.000 --> 08:39.750 We would rather say, hey, you define however many topologies you want in most 197 08:39.750 --> 08:40.720 modern networks, 198 08:40.720 --> 08:42.840 we can get away with two topologies. 199 08:42.840 --> 08:47.120 And then we map the VLANs into the two different topologies. 200 08:47.120 --> 08:50.400 And so that's exactly what MST is going to be able to do. 201 08:50.400 --> 08:54.780 It's going to be able to deploy an efficient number of topologies, not making 202 08:54.780 --> 08:55.440 it so that 203 08:55.440 --> 08:59.920 we have to send BPDUs for every single VLAN, not making it so we run the risk 204 08:59.920 --> 09:00.800 of enabling WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 204 08:59.920 --> 09:00.800 of enabling 205 09:00.800 --> 09:04.760 so many VLANs that we run out of spanning tree topologies as we demonstrated. 206 09:05.760 --> 09:07.920 All right, last question here. 207 09:07.920 --> 09:09.000 And this is a big one. 208 09:09.000 --> 09:13.100 What are the three MST attributes, there's three of these that must match among 209 09:13.100 --> 09:13.680 switches 210 09:13.680 --> 09:15.480 in the same layer two region? 211 09:15.480 --> 09:19.380 I left this as an open ended question because I wanted us to pause this video 212 09:19.380 --> 09:19.920 and make sure 213 09:19.920 --> 09:24.320 that I can bring these to mind myself without having to go and look it up. 214 09:24.320 --> 09:26.600 If you do have to look it up, that's perfectly fine. 215 09:26.600 --> 09:29.490 But again, we should know what these three attributes are because we have to 216 09:29.490 --> 09:29.960 configure 217 09:29.960 --> 09:33.800 them every time in an MST environment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 217 09:29.960 --> 09:33.800 them every time in an MST environment. 218 09:33.800 --> 09:40.590 So these three attributes don't exist in PVST plus or rapid spanning tree alone 219 09:40.590 --> 09:41.000 . 220 09:41.000 --> 09:43.760 It's an MST specific concept. 221 09:43.760 --> 09:46.600 So it starts with the region name. 222 09:46.600 --> 09:49.920 I have to name this region and we all have to agree on what that name is. 223 09:49.920 --> 09:51.680 It's just going to be a string. 224 09:51.680 --> 09:55.840 It could be CBT and or something along those lines or it could be your company 225 09:55.840 --> 09:56.480 name, whatever 226 09:56.480 --> 09:58.040 we want to use. 227 09:58.040 --> 10:00.040 Next we have that revision number. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 227 09:58.040 --> 10:00.040 Next we have that revision number. 228 10:00.040 --> 10:04.030 And even though it's great that we have the concept of being able to say, hey, 229 10:04.030 --> 10:04.720 I'm making 230 10:04.720 --> 10:09.070 a change, I'm going to increment this for maybe revision number one to two in 231 10:09.070 --> 10:09.680 the real 232 10:09.680 --> 10:10.680 world. 233 10:10.680 --> 10:14.090 We may or may not use that, but just understand that we do have to match on 234 10:14.090 --> 10:14.880 that revision 235 10:14.880 --> 10:17.200 number, whether we use it or not. 236 10:17.200 --> 10:19.400 And lastly, this is a big one as well. 237 10:19.400 --> 10:25.320 We need to make sure that the VLAN to instance mapping is the same. 238 10:25.320 --> 10:31.260 These are going to hash perform a hash of the VLANs and instances to share them WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 238 10:25.320 --> 10:31.260 These are going to hash perform a hash of the VLANs and instances to share them 239 10:31.260 --> 10:31.720 with 240 10:31.720 --> 10:35.360 one another, compare the hashes and make sure that they're identical. 241 10:35.360 --> 10:39.390 And so again, if we have two topologies here, maybe I'd throw VLANs 10 through 242 10:39.390 --> 10:40.560 15 into this 243 10:40.560 --> 10:44.480 instance, VLAN 16 through 20 into this instance. 244 10:44.480 --> 10:48.110 But either way, we have to agree on this as well as the instance number, by the 245 10:48.110 --> 10:48.520 way, maybe 246 10:48.520 --> 10:52.660 instance zero here and instance three over here for whatever reason. 247 10:52.660 --> 10:56.120 But if we don't agree on all three of these, then we are going to act like we 248 10:56.120 --> 10:57.000 're completely 249 10:57.000 --> 10:58.700 different topologies. 250 10:58.700 --> 11:02.620 And that's going to change the rules for how we end up blocking between the two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 250 10:58.700 --> 11:02.620 And that's going to change the rules for how we end up blocking between the two 251 11:02.620 --> 11:03.300 different 252 11:03.300 --> 11:07.060 domains that we or however many domains we end up creating. 253 11:07.060 --> 11:11.780 So this was again, a, a an opportunity for us to identify areas of weakness to 254 11:11.780 --> 11:13.220 say, hey, 255 11:13.220 --> 11:17.770 maybe I should go back and review MST or rapid per VLANs, bandage, plus or 256 11:17.770 --> 11:18.500 whatever the 257 11:18.500 --> 11:20.320 situation is. 258 11:20.320 --> 11:22.400 If not, hey, then we're good to go and we can move on. 259 11:22.400 --> 11:25.290 It's time to jump into the lab and make sure we remember how to configure these 260 11:25.290 --> 11:25.840 protocols.