WEBVTT 1 00:00.000 --> 00:03.440 Alright, let's go ahead and jump into a quiz. 2 00:03.440 --> 00:07.060 As we usually do with these types of quizzes, we're just going to read the 3 00:07.060 --> 00:07.800 question and 4 00:07.800 --> 00:11.550 encourage you to hit the pause button and make sure you can answer it yourself 5 00:11.550 --> 00:11.880 before 6 00:11.880 --> 00:13.560 I go into the solution. 7 00:13.560 --> 00:16.740 There's going to be seven questions total here where we go through these 8 00:16.740 --> 00:17.480 together and 9 00:17.480 --> 00:20.400 then we'll continue the challenge and other formats moving forward. 10 00:20.400 --> 00:22.720 But let's just go ahead and again start with a quiz. 11 00:22.720 --> 00:26.720 So question number one, which spanning tree protocol port roll? 12 00:26.720 --> 00:33.920 Keep in mind our terminology here, but our port roll allows for sending BPDUs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:26.720 --> 00:33.920 Keep in mind our terminology here, but our port roll allows for sending BPDUs. 13 00:33.920 --> 00:36.720 Well there's actually a lot packed into this question. 14 00:36.720 --> 00:39.760 So this concept of sending BPDUs is important. 15 00:39.760 --> 00:46.770 We have to remember that BPDUs are unidirectional, they only get sent one 16 00:46.770 --> 00:49.360 direction and specifically 17 00:49.360 --> 00:53.680 it's sent downstream from the root. 18 00:53.680 --> 00:59.320 So if we have our root switch, we've got a bunch of switches hanging off of the 19 00:59.320 --> 01:00.240 root switch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:59.320 --> 01:00.240 root switch 20 01:00.240 --> 01:03.040 or for that matter it could all loop back around. 21 01:03.040 --> 01:09.270 But either way we send those BPDUs downstream and these are how we determine 22 01:09.270 --> 01:10.240 what we're 23 01:10.240 --> 01:13.360 doing, which boards are blocking and such. 24 01:13.360 --> 01:16.000 And recall how exactly we broke this down. 25 01:16.000 --> 01:21.090 So a switch is going to determine upstream ports by recognizing there's a 26 01:21.090 --> 01:23.400 superior BPDU. 27 01:23.400 --> 01:29.040 It's going to identify the downstream ports by recognizing that it has a 28 01:29.040 --> 01:30.400 superior BPDU, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 28 01:29.040 --> 01:30.400 superior BPDU, 29 01:30.400 --> 01:35.280 meaning it's receiving inferior BPDUs. 30 01:35.280 --> 01:38.360 And so we're talking about receiving not sending here by the way. 31 01:38.360 --> 01:42.000 So I receive superior BPDUs upstream, that means it's towards the root. 32 01:42.000 --> 01:46.400 I receive inferior BPDUs downstream, at which point I ignore those, I send my 33 01:46.400 --> 01:47.280 own BPDU 34 01:47.280 --> 01:49.960 and the other side is supposed to stop sending them. 35 01:49.960 --> 01:53.410 And that's what turns into unidirectional because this switch down here might 36 01:53.410 --> 01:53.760 start 37 01:53.760 --> 01:56.280 by sending an inferior BPDU. 38 01:56.280 --> 02:00.680 But as soon as I send my superior BPDU, if everything's working properly, this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:56.280 --> 02:00.680 But as soon as I send my superior BPDU, if everything's working properly, this 39 02:00.680 --> 02:01.160 switch 40 02:01.160 --> 02:07.260 will recognize, oh, I have an inferior BPDU, therefore I'm going to stop 41 02:07.260 --> 02:08.520 sending the inferior 42 02:08.520 --> 02:12.480 BPDUs and I will just continue to receive them. 43 02:12.480 --> 02:15.520 So when we're talking about upstream ports, we have two different types. 44 02:15.520 --> 02:20.520 We have the root port, of which there will always be exactly one, and then we 45 02:20.520 --> 02:21.640 have non-designated 46 02:21.640 --> 02:23.120 ports. 47 02:23.120 --> 02:26.170 And that's going to make a lot more sense when we recognize the downstream 48 02:26.170 --> 02:26.600 ports are 49 02:26.600 --> 02:29.120 called designated ports. 50 02:29.120 --> 02:32.880 So be careful, it doesn't stand for downstream port, although that is what it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 50 02:29.120 --> 02:32.880 So be careful, it doesn't stand for downstream port, although that is what it 51 02:32.880 --> 02:33.280 is. 52 02:33.280 --> 02:36.800 It's facing downstream, it's going away from the root. 53 02:36.800 --> 02:43.580 So at this point, we see that I am going to have the root port here, the in a 54 02:43.580 --> 02:44.120 forwarding 55 02:44.120 --> 02:45.120 state. 56 02:45.120 --> 02:49.750 The designated port gets to be in a forwarding state, but the non-designated 57 02:49.750 --> 02:50.640 port becomes 58 02:50.640 --> 02:54.160 a blocking port and enters into the blocking state. 59 02:54.160 --> 02:55.440 And this is how we prevent loops. 60 02:55.440 --> 03:00.510 So we're looking at this diagram I just drew here, and this switch down here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 60 02:55.440 --> 03:00.510 So we're looking at this diagram I just drew here, and this switch down here 61 03:00.510 --> 03:01.720 needs to prevent 62 03:01.720 --> 03:04.920 this loop that we see in the middle of the network. 63 03:04.920 --> 03:08.030 So what it's going to do is recognize I've got one root port, let's say this 64 03:08.030 --> 03:08.440 one on the 65 03:08.440 --> 03:11.320 right, but it has two total upstream ports. 66 03:11.320 --> 03:14.960 And so I'm going to have to throw this one into the category of being a non- 67 03:14.960 --> 03:15.680 designated 68 03:15.680 --> 03:18.680 port, which means it ends up getting blocked. 69 03:18.680 --> 03:21.840 And at that point, we do prevent a loop from forming. 70 03:21.840 --> 03:27.700 So let's go back to the question now, which SDP port role allows for sending BP 71 03:27.700 --> 03:28.240 to use? 72 03:28.240 --> 03:31.920 Well, we said we send BP to use downstream. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 72 03:28.240 --> 03:31.920 Well, we said we send BP to use downstream. 73 03:31.920 --> 03:37.600 We said there's only one port role for downstream ports, and that would be 74 03:37.600 --> 03:39.040 designated ports. 75 03:39.040 --> 03:44.100 Our other two port types, our root port, our non-designated port, these would 76 03:44.100 --> 03:44.960 be upstream 77 03:44.960 --> 03:50.010 and we will never send our BP to use upstream towards the route, at least in 78 03:50.010 --> 03:51.200 standard spanning 79 03:51.200 --> 03:52.680 tree operation. 80 03:52.680 --> 03:56.160 So B here would be the answer. 81 03:56.160 --> 04:02.420 All right, question number two, switch ones for delay timer is set to 12 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 03:56.160 --> 04:02.420 All right, question number two, switch ones for delay timer is set to 12 82 04:02.420 --> 04:03.600 seconds there, 83 04:03.600 --> 04:06.040 and the max age timer is set to 16 seconds. 84 04:06.040 --> 04:09.920 How long does it take for a new port to come online? 85 04:09.920 --> 04:14.900 So we've got our switch, we've got a device, let's say it's a laptop that plugs 86 04:14.900 --> 04:15.320 in into 87 04:15.320 --> 04:19.800 a switch, and now we have to bring this port online. 88 04:19.800 --> 04:23.560 Now ideally, we have port fast enabled and it just comes online immediately, 89 04:23.560 --> 04:24.400 but in traditional 90 04:24.400 --> 04:28.160 spanning tree when this port comes online, whether it's connecting to a laptop 91 04:28.160 --> 04:28.880 or connecting 92 04:28.880 --> 04:34.060 to another switch, either way, we must progress through the listening and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 92 04:28.880 --> 04:34.060 to another switch, either way, we must progress through the listening and 93 04:34.060 --> 04:35.520 learning states. 94 04:35.520 --> 04:38.440 I'll draw it out a little better, there we go. 95 04:38.440 --> 04:44.110 So listening and learning, each one of these is going to require the full 96 04:44.110 --> 04:45.000 forward delay 97 04:45.000 --> 04:47.280 timer. 98 04:47.280 --> 04:50.720 So this is the trickiest part about the timer calculation, is just the fact 99 04:50.720 --> 04:51.320 that we have 100 04:51.320 --> 04:53.520 to double the forward delay. 101 04:53.520 --> 04:58.530 So if it takes 12 seconds, or if we set it to 12 seconds, then it's going to 102 04:58.530 --> 04:59.400 take 12 103 04:59.400 --> 05:03.750 seconds for listening, 12 seconds for learning, and the answer is going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 103 04:59.400 --> 05:03.750 seconds for listening, 12 seconds for learning, and the answer is going to be 104 05:03.750 --> 05:04.840 24 seconds. 105 05:04.840 --> 05:07.000 Now remember what Max Age implies. 106 05:07.000 --> 05:12.590 So let's say that our root switch is over here, we're sending BP to use down, 107 05:12.590 --> 05:13.560 it's flowing 108 05:13.560 --> 05:19.400 this direction, and meanwhile I've got another path this way. 109 05:19.400 --> 05:22.840 And so maybe this actually travels through several switches. 110 05:22.840 --> 05:25.600 So we'll draw it out like this. 111 05:25.600 --> 05:30.680 So this is two different upstream ports from this switch's perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 111 05:25.600 --> 05:30.680 So this is two different upstream ports from this switch's perspective. 112 05:30.680 --> 05:36.880 This is my root port facing the root, and this is my non-designated port up 113 05:36.880 --> 05:37.880 here, and I'm 114 05:37.880 --> 05:39.280 blocking. 115 05:39.280 --> 05:44.970 So I'm expecting to continue to receive superior BP to use from both directions 116 05:44.970 --> 05:45.040 . 117 05:45.040 --> 05:51.100 But what happens when this link here goes down, and this switch decides, ah, I 118 05:51.100 --> 05:51.680 am the 119 05:51.680 --> 05:56.520 root, and therefore I'm going to send an inferior BP to you. 120 05:56.520 --> 06:03.160 So this is now an inferior BP to you. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 120 05:56.520 --> 06:03.160 So this is now an inferior BP to you. 121 06:03.160 --> 06:11.770 Well this switch here has to wait because the superior BP to you has a timeout 122 06:11.770 --> 06:12.640 equal to 123 06:12.640 --> 06:16.000 Max Age. 124 06:16.000 --> 06:19.060 And so it's going to have to wait whatever is left of the 20 seconds from the 125 06:19.060 --> 06:19.560 last time 126 06:19.560 --> 06:22.120 I've received one of those superior BP to use. 127 06:22.120 --> 06:25.240 We'll just say it's 20 seconds, actually in this example it's 16 seconds. 128 06:25.240 --> 06:27.320 So let's stick with the example here. 129 06:27.320 --> 06:31.120 So I'm going to wait 16 seconds to time that out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 129 06:27.320 --> 06:31.120 So I'm going to wait 16 seconds to time that out. 130 06:31.120 --> 06:36.440 Then I'm going to progress to listening and then learning. 131 06:36.440 --> 06:37.640 So here's a bonus question. 132 06:37.640 --> 06:39.160 Feel free to pause. 133 06:39.160 --> 06:44.360 What is the total amount of time it will take for this switch here to bring 134 06:44.360 --> 06:45.120 this port 135 06:45.120 --> 06:50.800 into an online state if indeed this link goes down? 136 06:50.800 --> 06:56.460 Well the answer here is simply my listening and my learning and my Max Age 137 06:56.460 --> 06:57.200 because it'll 138 06:57.200 --> 07:02.390 take the full 16 seconds, in our example again, 20 seconds by default, it'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 138 06:57.200 --> 07:02.390 take the full 16 seconds, in our example again, 20 seconds by default, it'll 139 07:02.390 --> 07:04.040 take 16 seconds 140 07:04.040 --> 07:05.720 to time out. 141 07:05.720 --> 07:10.900 Then it will place this port into listening and it will sit in listening for 12 142 07:10.900 --> 07:11.520 seconds 143 07:11.520 --> 07:14.960 according to our example and then learning for 12 seconds. 144 07:14.960 --> 07:19.200 And so the total amount of time that these switches will both be down is 145 07:19.200 --> 07:20.080 actually going 146 07:20.080 --> 07:22.840 to be 40 seconds. 147 07:22.840 --> 07:26.280 That's a really long time to be down and if we were using the default settings 148 07:26.280 --> 07:26.640 it'd be 149 07:26.640 --> 07:30.400 50 seconds because it would just be longer at that point. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 149 07:26.640 --> 07:30.400 50 seconds because it would just be longer at that point. 150 07:30.400 --> 07:34.280 So let's keep in mind what all of these timers are doing in steady state 151 07:34.280 --> 07:35.560 operation with traditional 152 07:35.560 --> 07:36.560 spanning tree. 153 07:36.560 --> 07:40.390 Fortunately, rapid does speed this up quite a bit, which is what it's designed 154 07:40.390 --> 07:41.040 to do. 155 07:41.040 --> 07:44.100 But at the same time if for any reason, rapid can't figure things out, it will 156 07:44.100 --> 07:44.640 still fall 157 07:44.640 --> 07:49.870 back on these timers making these timers and these mechanisms relevant even in 158 07:49.870 --> 07:50.520 rapid spanning 159 07:50.520 --> 07:51.520 tree environments. 160 07:51.520 --> 07:57.110 Alright question number three, a Cisco switch running PBST plus is configured 161 07:57.110 --> 07:58.440 with 10 VLANs 162 07:58.440 --> 08:02.000 and five interfaces are in a forwarding state per VLAN. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 162 07:58.440 --> 08:02.000 and five interfaces are in a forwarding state per VLAN. 163 08:02.000 --> 08:05.120 How many STP instances are active? 164 08:05.120 --> 08:09.500 Well even though we're throwing a lot of numbers, really what it comes down to 165 08:09.500 --> 08:10.640 is how many VLANs 166 08:10.640 --> 08:13.320 are there that are active on the device. 167 08:13.320 --> 08:17.850 So our focus tends to be on, hey I've got 10 VLANs configured, VLANs one 168 08:17.850 --> 08:18.880 through ten. 169 08:18.880 --> 08:23.230 And therefore we're going to have 10 topologies because that's what per VLAN 170 08:23.230 --> 08:24.080 spanning tree 171 08:24.080 --> 08:29.520 means is every spanning tree or every VLAN gets its own spanning tree instance. 172 08:29.520 --> 08:33.720 However do keep in mind in the real world that if I've got let's say just a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 172 08:29.520 --> 08:33.720 However do keep in mind in the real world that if I've got let's say just a 173 08:33.720 --> 08:34.640 single trunk 174 08:34.640 --> 08:38.250 interface here, maybe we've got a bunch of access ports, all these access 175 08:38.250 --> 08:38.880 points are 176 08:38.880 --> 08:40.200 in VLAN five. 177 08:40.200 --> 08:43.760 And on this trunk I'm carrying VLANs one through seven. 178 08:43.760 --> 08:48.620 Well if there are no ports active for a VLAN then a spanning tree instance will 179 08:48.620 --> 08:50.000 not run. 180 08:50.000 --> 08:54.320 And so that's something that is just a little bit more call of advance I 181 08:54.320 --> 08:55.720 suppose but it usually 182 08:55.720 --> 09:00.210 goes beyond the scope of talking about some of these you know topology counts WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 182 08:55.720 --> 09:00.210 goes beyond the scope of talking about some of these you know topology counts 183 09:00.210 --> 09:00.920 and such. 184 09:00.920 --> 09:04.760 In our case we'd really only have topologies for VLANs one through seven. 185 09:04.760 --> 09:08.780 But as soon as a port comes online whether it's a trunk or access with VLAN 186 09:08.780 --> 09:09.520 eight will 187 09:09.520 --> 09:13.600 now all of a sudden we're going to need an eighth spanning tree topology. 188 09:13.600 --> 09:18.740 So so long as we have active VLANs meaning they're enabled on at least one port 189 09:18.740 --> 09:19.400 whether 190 09:19.400 --> 09:23.670 access or trunk doesn't matter as long as that VLANs active there will be a 191 09:23.670 --> 09:24.280 spanning 192 09:24.280 --> 09:27.850 tree instance running for it and we need to make sure that we have enough 193 09:27.850 --> 09:28.520 instances to 194 09:28.520 --> 09:31.680 support all of the VLANs that are in our environments and for that we'll just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 194 09:28.520 --> 09:31.680 support all of the VLANs that are in our environments and for that we'll just 195 09:31.680 --> 09:32.000 need to 196 09:32.000 --> 09:35.400 check the spec sheets for the switches that we're deploying. 197 09:35.400 --> 09:41.130 Alright next question what do switches do when a TCN the topology change 198 09:41.130 --> 09:42.360 notification 199 09:42.360 --> 09:44.240 is sent into the network. 200 09:44.240 --> 09:48.600 So recall what happens here if there's a topology change let's say a port comes 201 09:48.600 --> 09:48.960 online 202 09:48.960 --> 09:52.520 it goes into the forwarding state or maybe this link goes down whatever the 203 09:52.520 --> 09:53.120 situation 204 09:53.120 --> 09:58.430 is we are going to alert the root to the fact that there's been a topology 205 09:58.430 --> 09:59.240 change we're 206 09:59.240 --> 10:05.510 going to send a BPDU it's the one time we send a BPDU upstream that is a TCN B WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 206 09:59.240 --> 10:05.510 going to send a BPDU it's the one time we send a BPDU upstream that is a TCN B 207 10:05.510 --> 10:06.000 PDU. 208 10:06.000 --> 10:12.000 From there the root in its normal BPDU's so these are those config BPDU's will 209 10:12.000 --> 10:12.120 now 210 10:12.120 --> 10:18.560 have a flag set where our topology change bit is now equal to one. 211 10:18.560 --> 10:23.400 This tells the network every time it receives a BPDU that there has been a top 212 10:23.400 --> 10:24.440 ology change. 213 10:24.440 --> 10:27.560 So what happens when this gets sent out? 214 10:27.560 --> 10:32.960 Well what we're going to do is we are going to reduce the MAC address timeout. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 214 10:27.560 --> 10:32.960 Well what we're going to do is we are going to reduce the MAC address timeout. 215 10:32.960 --> 10:36.940 We went through several examples of this the idea is that because there was a 216 10:36.940 --> 10:37.560 topology 217 10:37.560 --> 10:42.600 change we run the risk of black holing traffic and so we don't want to make the 218 10:42.600 --> 10:43.360 mistake of 219 10:43.360 --> 10:50.660 sending MAC addresses or really packets and frames towards the wrong switch 220 10:50.660 --> 10:51.280 based on the 221 10:51.280 --> 10:54.840 destination MAC address which is now a stale entry. 222 10:54.840 --> 10:59.010 So the timeout is going to be very important it goes down to the forward delay 223 10:59.010 --> 10:59.480 timer and 224 10:59.480 --> 11:03.080 so because it goes down to the forward delay timer if we're using default WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 224 10:59.480 --> 11:03.080 so because it goes down to the forward delay timer if we're using default 225 11:03.080 --> 11:03.880 settings that 226 11:03.880 --> 11:09.720 will go down to a 15 second timeout which is way less than the 300 seconds that 227 11:09.720 --> 11:10.080 we use 228 11:10.080 --> 11:11.960 for by default. 229 11:11.960 --> 11:15.790 As a result MAC addresses were more likely to timeout in this scenario and 230 11:15.790 --> 11:16.440 there will 231 11:16.440 --> 11:21.480 be a lot more flooding on the network and always remember that portfast will 232 11:21.480 --> 11:22.080 prevent 233 11:22.080 --> 11:26.660 this from happening if I have a laptop and I plug it in portfast will suppress 234 11:26.660 --> 11:27.880 the TCN. 235 11:27.880 --> 11:31.660 It's very important that we have portfast enabled otherwise we are going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 235 11:27.880 --> 11:31.660 It's very important that we have portfast enabled otherwise we are going to 236 11:31.660 --> 11:32.560 more or less 237 11:32.560 --> 11:37.310 constantly be sitting in a state where our MAC address timeouts are at 15 238 11:37.310 --> 11:38.120 seconds. 239 11:38.120 --> 11:43.400 Alright question number five what happens if a BPDU is received on an interface 240 11:43.400 --> 11:44.240 configured 241 11:44.240 --> 11:45.720 with portfast? 242 11:45.720 --> 11:50.450 So something we have to worry about here is I might enable portfast on this 243 11:50.450 --> 11:51.200 port and a 244 11:51.200 --> 11:54.360 laptop is supposed to connect to it and maybe most of the time there is a 245 11:54.360 --> 11:55.240 laptop connected 246 11:55.240 --> 11:56.240 to it. 247 11:56.240 --> 12:00.370 But all of a sudden maybe this is a college student and this is in a dorm or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 247 11:56.240 --> 12:00.370 But all of a sudden maybe this is a college student and this is in a dorm or 248 12:00.370 --> 12:01.040 something 249 12:01.040 --> 12:08.200 like that and they connect a switch and all of a sudden we're receiving a BPDU 250 12:08.200 --> 12:08.680 's on our 251 12:08.680 --> 12:10.440 portfast port. 252 12:10.440 --> 12:16.020 Does this make a spanning tree loop are we now subject to potential loops on 253 12:16.020 --> 12:16.640 every one 254 12:16.640 --> 12:18.680 of our portfast ports. 255 12:18.680 --> 12:22.730 And so fortunately we don't need to worry about that too much because portfast 256 12:22.730 --> 12:23.240 is going 257 12:23.240 --> 12:28.240 to transition us back into the listening state if this were to happen. 258 12:28.240 --> 12:30.740 So A here is the correct answer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 258 12:28.240 --> 12:30.740 So A here is the correct answer. 259 12:30.740 --> 12:35.420 We place ourselves into the listening state and ultimately we revert back to 260 12:35.420 --> 12:36.080 standard 261 12:36.080 --> 12:39.840 STP behavior. 262 12:39.840 --> 12:43.820 That is what happens as a result we don't need to stress too much about port 263 12:43.820 --> 12:44.480 fast creating 264 12:44.480 --> 12:48.260 loops just do keep in mind that if I were to connect this to two different port 265 12:48.260 --> 12:48.560 fast, 266 12:48.560 --> 12:54.720 ports and we don't send out a BPDU for two, three, four seconds depending on 267 12:54.720 --> 12:55.320 the hello 268 12:55.320 --> 12:56.320 timer. 269 12:56.320 --> 13:00.610 Well then we're not going to know that there's a loop and so it's going to loop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 269 12:56.320 --> 13:00.610 Well then we're not going to know that there's a loop and so it's going to loop 270 13:00.610 --> 13:01.120 traffic 271 13:01.120 --> 13:03.440 until a BPDU is received. 272 13:03.440 --> 13:07.500 So there is still a possibility of loops forming but they should be temporary 273 13:07.500 --> 13:08.200 only until I 274 13:08.200 --> 13:14.120 receive a BPDU from the downstream switch that just connected to that port. 275 13:14.120 --> 13:15.120 We're almost there. 276 13:15.120 --> 13:20.020 Two questions to go, a switch with bridge ID starting with 0.9, so I'd be the 277 13:20.020 --> 13:20.440 start 278 13:20.440 --> 13:24.320 of the MAC address, is configured with the root primary macro. 279 13:24.320 --> 13:28.880 The current root has a priority of 4096 with a MAC address starting with 0A. 280 13:28.880 --> 13:31.480 What priority does the switch change to? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 280 13:28.880 --> 13:31.480 What priority does the switch change to? 281 13:31.480 --> 13:32.840 So this is really important. 282 13:32.840 --> 13:37.910 We spent quite a bit of time talking about this here with the STP macros 283 13:37.910 --> 13:39.400 conversation. 284 13:39.400 --> 13:41.680 This root primary is a macro. 285 13:41.680 --> 13:45.430 It's going to run additional commands on the back end but importantly it's 286 13:45.430 --> 13:46.960 going to change 287 13:46.960 --> 13:50.320 which commands it's running depending on the current situation. 288 13:50.320 --> 13:56.170 Root primary remember what this does is it essentially says, hey, I'm going to 289 13:56.170 --> 13:57.640 make myself 290 13:57.640 --> 14:07.120 the highest, yes, highest numbered priority that makes me the root. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 290 13:57.640 --> 14:07.120 the highest, yes, highest numbered priority that makes me the root. 291 14:07.120 --> 14:11.150 So if I win a MAC address battle with the current root then I can choose the 292 14:11.150 --> 14:12.480 same priority level 293 14:12.480 --> 14:14.280 because I'll win the tiebreaker. 294 14:14.280 --> 14:17.590 If I don't win that tiebreaker I won't win it if I were to change it then I'll 295 14:17.590 --> 14:18.040 have to 296 14:18.040 --> 14:19.280 go lower. 297 14:19.280 --> 14:23.880 So there's a few things in place here, a few forces that we have to kind of gel 298 14:23.880 --> 14:24.880 together. 299 14:24.880 --> 14:27.640 We also will not pick 0. 300 14:27.640 --> 14:33.080 This is not an option to go down as low as 0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 300 14:27.640 --> 14:33.080 This is not an option to go down as low as 0. 301 14:33.080 --> 14:37.160 And so we have a current root which has a priority of 4096. 302 14:37.160 --> 14:38.800 So here's the question. 303 14:38.800 --> 14:43.900 Can we go to 4096 or do we have to go to 0 and at that point we're not allowed 304 14:43.900 --> 14:44.240 to go 305 14:44.240 --> 14:45.240 to 0. 306 14:45.240 --> 14:46.680 So this is kind of a little tricky. 307 14:46.680 --> 14:53.800 So the current root has 4096 MAC address starting with 0a. 308 14:53.800 --> 14:54.800 Here's me. 309 14:54.800 --> 15:00.690 I just put this configuration onto this switch here so I'm running the macro WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 309 14:54.800 --> 15:00.690 I just put this configuration onto this switch here so I'm running the macro 310 15:00.690 --> 15:01.480 here and it has 311 15:01.480 --> 15:03.520 a MAC address of 0, 9. 312 15:03.520 --> 15:05.800 So we have to compare these two MAC addresses. 313 15:05.800 --> 15:07.520 What is the situation? 314 15:07.520 --> 15:13.280 Well the situation is that 0a is actually a higher number and therefore the 315 15:13.280 --> 15:14.080 priority 316 15:14.080 --> 15:18.400 actually exists over here with our macro switch. 317 15:18.400 --> 15:23.890 So in other words if it's the same priority value then we will win because 0, 9 318 15:23.890 --> 15:24.240 is a 319 15:24.240 --> 15:28.120 lower number than 0a which is effectively 0, 10 there. 320 15:28.120 --> 15:29.520 A is hex for 10. 321 15:29.520 --> 15:34.400 And 10 is higher and spanning tree that means worse than 9. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 321 15:29.520 --> 15:34.400 And 10 is higher and spanning tree that means worse than 9. 322 15:34.400 --> 15:41.040 So all we're going to see is that this switch chooses a priority value of 4096. 323 15:41.040 --> 15:47.970 So 4096 is going to win because now we compare our priorities and they're the 324 15:47.970 --> 15:48.720 same and so 325 15:48.720 --> 15:50.400 we compare our MAC addresses. 326 15:50.400 --> 15:54.420 They're not the same, hopefully they're never the same and our macro switch 327 15:54.420 --> 15:55.120 will win. 328 15:55.120 --> 15:59.960 So remember how these priorities work and all the rules around how they work. 329 15:59.960 --> 16:05.330 Remember that the secondary command will always choose a value of that 28k even WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 329 15:59.960 --> 16:05.330 Remember that the secondary command will always choose a value of that 28k even 330 16:05.330 --> 16:06.000 if it won't 331 16:06.000 --> 16:09.110 make it the secondary it doesn't matter because it doesn't know all the 332 16:09.110 --> 16:10.360 priorities out there. 333 16:10.360 --> 16:12.880 So we just have to use 28k. 334 16:12.880 --> 16:21.400 Also remember that the highest priority that will be picked is 2k no 24k. 335 16:21.400 --> 16:27.160 It won't choose 28k because of the secondary being or using that option already 336 16:27.160 --> 16:27.400 and the 337 16:27.400 --> 16:31.520 default priority for all of our Cisco switches are 32k. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 337 16:27.400 --> 16:31.520 default priority for all of our Cisco switches are 32k. 338 16:31.520 --> 16:35.370 So all these numbers do actually add up and they make a lot of sense for how 339 16:35.370 --> 16:36.120 this deploys 340 16:36.120 --> 16:38.750 and so we just need to make sure that we're being as intentional as possible 341 16:38.750 --> 16:39.240 when we're 342 16:39.240 --> 16:40.840 using these macros. 343 16:40.840 --> 16:43.920 Alright last question. 344 16:43.920 --> 16:48.750 Switch 5 has two possible paths to the root with BPDUs each arriving on 10 gig 345 16:48.750 --> 16:49.400 ports. 346 16:49.400 --> 16:50.600 Let's just draw this out real quick. 347 16:50.600 --> 16:58.630 So switch 5 each one of these is 10 gig ports and the BPDUs arriving here are 348 16:58.630 --> 17:00.160 two different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 348 16:58.630 --> 17:00.160 two different 349 17:00.160 --> 17:01.160 BPDUs. 350 17:01.160 --> 17:06.010 I mean they're from the same root but they are advertised from two different 351 17:06.010 --> 17:06.800 switches. 352 17:06.800 --> 17:10.520 And we know that because the cost is different so we have one over here we'll 353 17:10.520 --> 17:11.120 call this A 354 17:11.120 --> 17:13.480 on the left and B on the right. 355 17:13.480 --> 17:20.700 So we have a cost of 8,000 the bridge ID the bridge priority I should say is 16 356 17:20.700 --> 17:21.480 k coming 357 17:21.480 --> 17:25.720 from this other switch and the port priority is 80. 358 17:25.720 --> 17:33.130 Over here path B cost of 6,000 then we have a priority of 32k and a port WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 358 17:25.720 --> 17:33.130 Over here path B cost of 6,000 then we have a priority of 32k and a port 359 17:33.130 --> 17:35.320 priority of 128. 360 17:35.320 --> 17:40.470 So what's interesting about this scenario is that these priority values the 361 17:40.470 --> 17:41.320 bridge priority 362 17:41.320 --> 17:46.280 and the port priority are much better than these values over here. 363 17:46.280 --> 17:50.710 And so our eyes might be inclined to look here at the bridge priority and the 364 17:50.710 --> 17:52.240 port priority. 365 17:52.240 --> 17:56.960 The problem is that nothing matters more than the cost. 366 17:56.960 --> 18:02.270 If switch B whatever that switch is upstream has a better path to the root than WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 366 17:56.960 --> 18:02.270 If switch B whatever that switch is upstream has a better path to the root than 367 18:02.270 --> 18:02.880 switch 368 18:02.880 --> 18:07.760 A on the left then I will always go out that path. 369 18:07.760 --> 18:11.280 And so we don't need to even worry about the tiebreakers at that point. 370 18:11.280 --> 18:14.160 Remember these tiebreakers are arbitrary. 371 18:14.160 --> 18:17.580 It's really just a way for us to say hey I've got two great paths or at least 372 18:17.580 --> 18:18.840 equal paths 373 18:18.840 --> 18:21.790 and therefore I just need to pick one at random and that's essentially my way 374 18:21.790 --> 18:23.800 of doing so. 375 18:23.800 --> 18:28.660 Now if I'm configuring priority values then usually there's more intentionality 376 18:28.660 --> 18:29.160 behind 377 18:29.160 --> 18:33.320 it and I don't need to worry about it being random. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 377 18:29.160 --> 18:33.320 it and I don't need to worry about it being random. 378 18:33.320 --> 18:37.950 But at the same time yeah we just understand that tiebreakers don't matter when 379 18:37.950 --> 18:38.600 the costs 380 18:38.600 --> 18:40.400 are not equal. 381 18:40.400 --> 18:42.000 So which path is chosen? 382 18:42.000 --> 18:44.500 The answer here is going to be B based on the path. 383 18:44.500 --> 18:47.920 So how can switch V be tuned to prefer the other path? 384 18:47.920 --> 18:50.360 Well importantly we say it's switch V that's being tuned. 385 18:50.360 --> 18:53.120 We're not going to tune anything else in the network. 386 18:53.120 --> 18:59.130 These are being brought in on 10 gig links each with a cost by default of 2000 387 18:59.130 --> 18:59.360 if we're 388 18:59.360 --> 19:04.240 using the long path costs otherwise it's a cost of two for short path costs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 388 18:59.360 --> 19:04.240 using the long path costs otherwise it's a cost of two for short path costs. 389 19:04.240 --> 19:05.960 Either way it's the same. 390 19:05.960 --> 19:10.150 And so what we can do is one of two things I want to prefer this path so I can 391 19:10.150 --> 19:10.680 either 392 19:10.680 --> 19:15.600 lower the cost on this side or I can raise the cost on this side. 393 19:15.600 --> 19:20.680 Now what we're trying to do here is overcome the difference in costs of 2000. 394 19:20.680 --> 19:25.240 And so I can't really reduce this down. 395 19:25.240 --> 19:29.900 But we don't want to use a cost of zero for example we can't decrease the two 396 19:29.900 --> 19:30.360 at all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 396 19:29.900 --> 19:30.360 at all 397 19:30.360 --> 19:33.160 if this happens to be configured with short. 398 19:33.160 --> 19:35.680 And so we're going to have to increase the other side. 399 19:35.680 --> 19:39.740 And so the idea here is that we will increase the side by at least 2001 meaning 400 19:39.740 --> 19:40.360 I'm either 401 19:40.360 --> 19:48.490 going to increase this to 4001 or I'll increase this to well I guess 2003 yeah 402 19:48.490 --> 19:49.520 that would 403 19:49.520 --> 19:50.760 be it. 404 19:50.760 --> 19:52.320 2001 plus two. 405 19:52.320 --> 19:57.130 So either way depending on whether we're running long or short we just need to 406 19:57.130 --> 19:58.120 increase this 407 19:58.120 --> 20:00.240 path cost by 2001. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 407 19:58.120 --> 20:00.240 path cost by 2001. 408 20:00.240 --> 20:06.740 At that point the total cost for path B will be 8001 instead of the 6000 that 409 20:06.740 --> 20:07.480 was there. 410 20:07.480 --> 20:10.360 And now we will prefer the lower path. 411 20:10.360 --> 20:14.160 So that is how we can go about tuning the path. 412 20:14.160 --> 20:17.920 And that's a big part of spanning tree and understanding it is looking at it 413 20:17.920 --> 20:18.560 and saying 414 20:18.560 --> 20:19.800 okay well how can I change it? 415 20:19.800 --> 20:22.640 How can I change which ports are going to be blocked? 416 20:22.640 --> 20:26.980 And now we've covered in great amount of detail how we can do that inbound 417 20:26.980 --> 20:27.920 using cost, 418 20:27.920 --> 20:32.480 outbound using port priorities if indeed it's connected to the same switch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 418 20:27.920 --> 20:32.480 outbound using port priorities if indeed it's connected to the same switch. 419 20:32.480 --> 20:34.880 So that is it brings us to the end of this quiz. 420 20:34.880 --> 20:38.020 Now we're going to jump into a couple more challenges to really cement our 421 20:38.020 --> 20:38.720 knowledge of 422 20:38.720 --> 20:42.880 house spanning tree determines topologies and determines blocked ports.