WEBVTT 1 00:00.000 --> 00:02.860 All right, let's go ahead and jump into this review and the way we're going to 2 00:02.860 --> 00:04.200 do it is how we've done it in the past 3 00:04.200 --> 00:07.840 We're going to start with some quizzes each quiz question is going to have the 4 00:07.840 --> 00:08.880 the skill 5 00:08.880 --> 00:12.360 referenced at the bottom where you can go back and review that skill if you 6 00:12.360 --> 00:14.120 want to refresh around it again 7 00:14.120 --> 00:17.670 These quiz questions are intended to help us to recognize where we might have 8 00:17.670 --> 00:19.000 an area of weakness for example 9 00:19.000 --> 00:22.770 This is a question about BP do guard if I can't immediately answer this 10 00:22.770 --> 00:23.240 question 11 00:23.240 --> 00:25.320 I might want to go back and review BP do guard 12 00:25.320 --> 00:29.440 So make sure that as we ask these questions that you pause the video and you 13 00:29.440 --> 00:31.240 confirm that you can answer the question WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 13 00:29.440 --> 00:31.240 confirm that you can answer the question 14 00:31.240 --> 00:35.880 Before I give the answer and if you get the question right then great 15 00:35.880 --> 00:39.320 If not just mark it down and make sure you go back and review that again 16 00:39.320 --> 00:43.800 It's all about identifying our areas of weakness. So first question here 17 00:43.800 --> 00:48.320 What happens when a port enabled for BP do guard receives a BP do? 18 00:48.320 --> 00:54.020 So be be be you guard is one of our topology protection mechanisms 19 00:54.520 --> 00:58.320 Remember the convert or the concept of a topology 20 00:58.320 --> 01:03.320 Protection mechanism is getting away from spanning trees super dynamic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 20 00:58.320 --> 01:03.320 Protection mechanism is getting away from spanning trees super dynamic 21 01:03.320 --> 01:08.050 Methodology for example if we have our root bridge up here, maybe for one 22 01:08.050 --> 01:09.160 specific VLAN 23 01:09.160 --> 01:15.040 Then we are in a place where if I connect a switch down here that wants to be 24 01:15.040 --> 01:15.520 the root 25 01:15.520 --> 01:17.840 Maybe our root has a priority of 4k 26 01:17.840 --> 01:21.560 But this switch has a priority of zero for whatever reason that it can 27 01:21.560 --> 01:24.500 dynamically go and take over as the 28 01:24.700 --> 01:26.700 Root from the current root bridge 29 01:26.700 --> 01:30.300 This is not an ideal situation in our modern networks WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 01:26.700 --> 01:30.300 This is not an ideal situation in our modern networks 30 01:30.300 --> 01:34.270 We have established topologies and we want to make sure that only maybe this 31 01:34.270 --> 01:36.520 switch and this switch could be the root 32 01:36.520 --> 01:40.850 I would never want this switch or anything downstream to be able to claim it 33 01:40.850 --> 01:43.280 since natively spanning tree can't do that for me 34 01:43.280 --> 01:47.460 We're going to have to deploy one of Cisco's topology protection mechanisms 35 01:47.460 --> 01:51.400 We have a couple of different protection mechanisms to talk about we have BPD 36 01:51.400 --> 01:54.020 you guard and root guard and as you might imagine 37 01:54.020 --> 01:58.470 We're going to have a question on that coming up. So BPD you guard is not going 38 01:58.470 --> 02:01.420 to necessarily look for superior BPD WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:58.470 --> 02:01.420 to necessarily look for superior BPD 39 02:01.420 --> 02:03.740 You just gonna look for any BPD you 40 02:03.740 --> 02:07.300 Where do we not want any BPD you really any? 41 02:07.300 --> 02:13.050 Connection down here at on out an access port. We're not expecting switches to 42 02:13.050 --> 02:14.300 connect in on access ports 43 02:14.300 --> 02:18.910 So if a switch shows up and sends a BPD you we would want to shut this link 44 02:18.910 --> 02:19.260 down 45 02:19.540 --> 02:23.670 So therefore we would apply BPD you guard to this and we can apply it manually 46 02:23.670 --> 02:25.180 to ports or we can apply it to all 47 02:25.180 --> 02:29.940 Access ports via global commands, but either way we are going to use this as a 48 02:29.940 --> 02:34.140 protection mechanism against any BPD you and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 48 02:29.940 --> 02:34.140 protection mechanism against any BPD you and 49 02:34.140 --> 02:40.300 the response to any BPD you being received is to place our port into that air- 50 02:40.300 --> 02:41.380 disabled state 51 02:41.380 --> 02:46.100 Air disable effectively shuts the port down either requiring manual 52 02:46.100 --> 02:48.420 intervention for me to go on and do a shut 53 02:48.420 --> 02:51.860 No shot on the port or I could configure air-disabled 54 02:51.860 --> 02:56.890 Recovery in order to attempt to recover automatically within a given time 55 02:56.890 --> 02:57.700 interval 56 02:57.700 --> 03:01.970 Maybe every 30 or 60 seconds, but either way air-disabled is an important part WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 56 02:57.700 --> 03:01.970 Maybe every 30 or 60 seconds, but either way air-disabled is an important part 57 03:01.970 --> 03:03.340 of the protection mechanism 58 03:03.340 --> 03:07.460 It does effectively shut the port down and so be here is going to be our answer 59 03:07.460 --> 03:08.180 if any 60 03:08.180 --> 03:13.960 BPD was received inferior or superior on an interface with BPD you guard it 61 03:13.960 --> 03:15.780 will be placed into air-disabled 62 03:17.260 --> 03:21.300 All right question number two and it just so happens to be about root guard 63 03:21.300 --> 03:25.940 What happens when a BPD was received on a port enabled for root guard? 64 03:25.940 --> 03:30.320 Well, this does have to do with that situation where we just described we've WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 64 03:25.940 --> 03:30.320 Well, this does have to do with that situation where we just described we've 65 03:30.320 --> 03:31.220 got our topology 66 03:31.220 --> 03:35.300 We have our route and now a switch is claiming to be the route 67 03:35.300 --> 03:40.730 so maybe our route has a 4k here and I either misconfigured this switch to have 68 03:40.730 --> 03:42.860 a zero or maybe I grab a switch off the shelf 69 03:43.500 --> 03:47.500 unwittingly connecting it to the network and not realizing that it is 70 03:47.500 --> 03:49.460 configured for priority of zero 71 03:49.460 --> 03:54.660 So at this point this is going to generate a superior BPD you and 72 03:54.660 --> 03:58.940 This is what we're trying to avoid on root guard enabled ports 73 03:58.940 --> 04:03.690 So I would place root guard here and here and I could look at putting it on all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 73 03:58.940 --> 04:03.690 So I would place root guard here and here and I could look at putting it on all 74 04:03.690 --> 04:05.500 downstream interfaces 75 04:05.500 --> 04:09.440 But generally speaking we're trying to protect our roots and so I would place 76 04:09.440 --> 04:10.500 root guard here 77 04:10.980 --> 04:15.140 To protect these roots and it will cut off that switch from 78 04:15.140 --> 04:20.940 Being able to be part of the network when it is also propagating a superior BPD 79 04:20.940 --> 04:21.420 upstream 80 04:21.420 --> 04:25.780 Whether it's one that connected in or whether it itself was misconfigured 81 04:25.780 --> 04:30.840 So at this point what we're going to find is that we're going to use this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 04:25.780 --> 04:30.840 So at this point what we're going to find is that we're going to use this 82 04:30.840 --> 04:32.500 special spanning tree state 83 04:32.500 --> 04:35.380 we call it STP inconsistent and 84 04:36.500 --> 04:40.700 It will tell us exactly why it's in an inconsistent status in this case 85 04:40.700 --> 04:42.060 It's because of root guard 86 04:42.060 --> 04:45.900 But we're also going to see this show up in Cisco show commands as being a 87 04:45.900 --> 04:47.540 broken port or BKN 88 04:47.540 --> 04:51.700 And so we're not going to place the port into a broken status regardless 89 04:51.700 --> 04:57.470 It's only going to be if it's a superior BPD you if an inferior BPD you shows 90 04:57.470 --> 04:57.580 up 91 04:57.580 --> 05:01.300 Which is what we'd expect when we first turn a switch on it's going to send an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 04:57.580 --> 05:01.300 Which is what we'd expect when we first turn a switch on it's going to send an 92 05:01.300 --> 05:03.060 inferior BPD upstream 93 05:03.060 --> 05:06.220 That would be if this is configured for the default of 32k 94 05:06.220 --> 05:11.600 Let's say sends an inferior BPD upstream as soon as the superior BPD who comes 95 05:11.600 --> 05:11.740 down 96 05:11.740 --> 05:15.930 I stopped sending my inferior BPD use but I wouldn't want to stop that process 97 05:15.930 --> 05:16.740 from happening 98 05:16.740 --> 05:20.780 Therefore, I'm only going to react if the BPD is superior 99 05:20.780 --> 05:24.660 All right question number three and by the way there are six questions 100 05:24.660 --> 05:29.900 How is a UDLD unidirectional link detection applied if enabled globally? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 101 05:30.260 --> 05:34.180 Well, the answer here is if we enable it globally, it's only going to apply to 102 05:34.180 --> 05:34.740 fiber ports 103 05:34.740 --> 05:38.620 And that's because UDLD is primarily beneficial on fiber ports 104 05:38.620 --> 05:40.900 Remember we're trying to prevent unidirectional 105 05:40.900 --> 05:45.380 Links from forming and so if I have a switch here and I've got a fiber 106 05:45.380 --> 05:47.020 connection between these switches 107 05:47.020 --> 05:51.700 We know that that fiber connection actually consists of two strands. I send 108 05:51.700 --> 05:56.340 out one strand I receive on the other from the perspective of the switch on the 109 05:56.340 --> 05:56.820 left and 110 05:57.540 --> 06:03.220 The problem can occur here if this port is in a spanning tree blocking state WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 110 05:57.540 --> 06:03.220 The problem can occur here if this port is in a spanning tree blocking state 111 06:03.220 --> 06:08.700 So if this is blocking and then all of a sudden this strand on top breaks 112 06:08.700 --> 06:14.380 Well, I no longer get the BPD use that we're coming in and therefore because I 113 06:14.380 --> 06:15.980 'm no longer getting BPD use 114 06:15.980 --> 06:19.420 I would transition out of blocking and start transmitting upstream 115 06:19.420 --> 06:23.530 This can also cause a lot of problems with other protocols not just spanning 116 06:23.530 --> 06:23.820 tree 117 06:23.820 --> 06:28.870 And that's why UDLD exists because it's really just designed to help us detect 118 06:28.870 --> 06:32.100 this issue again primarily on fiber ports WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 06:28.870 --> 06:32.100 this issue again primarily on fiber ports 119 06:32.100 --> 06:35.860 And it will allow the switches to detect that there's an issue 120 06:35.860 --> 06:39.690 Regardless of what protocols were worried about spanning tree or a routing 121 06:39.690 --> 06:41.780 protocol or anything along those lines 122 06:41.780 --> 06:47.420 So when we come back to this conversation, we are focusing on fiber ports 123 06:47.420 --> 06:52.720 But UDLD can apply to copper ports. We just have to explicitly configure it on 124 06:52.720 --> 06:53.860 that interface 125 06:53.860 --> 06:57.980 But you're playing it globally will only apply it to fiber ports. The good news 126 06:57.980 --> 06:59.980 is it'll apply it to fiber ports today 127 06:59.980 --> 07:01.540 And if we add WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 06:59.980 --> 07:01.540 And if we add 128 07:01.540 --> 07:05.590 Fiber ports in the future it will get automatically added to those ports as 129 07:05.590 --> 07:08.380 they come online if we do enable it globally 130 07:08.380 --> 07:14.570 All right question number four how is UDLD aggressive mode different from UDLD 131 07:14.570 --> 07:16.120 normal mode choose to? 132 07:16.460 --> 07:21.660 So UDLD aggressive mode as the name implies is going to be a little bit more 133 07:21.660 --> 07:24.860 aggressive in terms of detecting issues and 134 07:24.860 --> 07:28.780 Responding to issues the first big difference is it's going to attempt to 135 07:28.780 --> 07:30.180 reform lost connections WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 135 07:28.780 --> 07:30.180 reform lost connections 136 07:30.180 --> 07:34.140 Let's keep in mind how UDLD works. I've got my two strands here 137 07:34.140 --> 07:39.980 And if I enable UDLD on this side first, it's expecting to send 138 07:41.300 --> 07:45.980 UDLD messages and have those loop back around. This is how we detect if there's 139 07:45.980 --> 07:48.220 an issue on either one of the strands 140 07:48.220 --> 07:52.380 I can't just send and hope that the other side is receiving it 141 07:52.380 --> 07:56.290 I need acknowledgment and so the echo as we talked about is how we accomplish 142 07:56.290 --> 07:58.340 that then I can figure it on this side 143 07:58.340 --> 08:03.350 And I get an echo in the other direction. So both of these are echoing back and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 143 07:58.340 --> 08:03.350 And I get an echo in the other direction. So both of these are echoing back and 144 08:03.350 --> 08:03.720 forth 145 08:03.720 --> 08:07.020 Questions what happens if I don't get a response? 146 08:07.540 --> 08:12.860 Well, UDLD normal mode just continues as is it just logs that it's happening 147 08:12.860 --> 08:15.540 aggressive mode is going to take two major 148 08:15.540 --> 08:19.310 Different approaches first of all, it's going to attempt to reform the lost 149 08:19.310 --> 08:19.900 connections 150 08:19.900 --> 08:24.500 It's going to send eight consecutive messages one per second 151 08:24.500 --> 08:29.160 Trying to get a response back just in case the switch got busy and wasn't able 152 08:29.160 --> 08:32.940 to loop that message back around and so this is probably WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 152 08:29.160 --> 08:32.940 to loop that message back around and so this is probably 153 08:32.940 --> 08:35.900 Just attempting to find that 154 08:36.780 --> 08:40.790 Restore that connection rather before the spanning tree for delay time or 155 08:40.790 --> 08:41.300 expires 156 08:41.300 --> 08:46.210 Now the other situation or the other thing it's going to do is it's going to 157 08:46.210 --> 08:47.660 place ports into air disable 158 08:47.660 --> 08:52.060 Which UDLD normal mode doesn't do so for the most part? 159 08:52.060 --> 08:55.500 UDLD normal mode is not going to be very useful to us 160 08:55.500 --> 09:00.020 Especially from a spanning tree protocol perspective if we're going to use UDLD WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 160 08:55.500 --> 09:00.020 Especially from a spanning tree protocol perspective if we're going to use UDLD 161 09:00.020 --> 09:03.660 We're almost always going to deploy aggressive mode so that we can try to 162 09:03.660 --> 09:05.940 restore the connection and if that fails 163 09:05.940 --> 09:10.090 We can place the port into air disable and therefore protect ourselves from 164 09:10.090 --> 09:10.500 loops 165 09:10.500 --> 09:16.600 All right next question. It's a question about loop guard in what scenario will 166 09:16.600 --> 09:19.740 spanning trees loop guard help to prevent a loop 167 09:19.740 --> 09:25.380 So what exactly is loop guard doing? Well, it's going to be sort of like UDLD 168 09:25.380 --> 09:27.540 in that it's looking for 169 09:27.540 --> 09:31.420 Situation where messages can't make it across unidirectionally WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 169 09:27.540 --> 09:31.420 Situation where messages can't make it across unidirectionally 170 09:31.780 --> 09:38.380 However, unlike UDLD this is going to be running from an STP perspective and 171 09:38.380 --> 09:42.900 Specifically it's going to look at the BP to use that are coming in 172 09:42.900 --> 09:46.700 So BP to use coming in as a requirement for loop guard 173 09:46.700 --> 09:51.490 That's why it's an STP concept whereas UDLD applies to just every link in 174 09:51.490 --> 09:55.500 general where we apply it and therefore all protocols will be impacted 175 09:55.500 --> 09:59.540 So there might be a conversation about whether to configure one of these or 176 09:59.540 --> 10:00.340 both of these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 176 09:59.540 --> 10:00.340 both of these 177 10:00.580 --> 10:04.330 There's no harm in enabling both of them just understand that they from a 178 10:04.330 --> 10:07.420 spanning tree perspective largely accomplish the same thing 179 10:07.420 --> 10:11.140 however, UDLD as we've mentioned is mostly going to be focused on 180 10:11.140 --> 10:13.900 fiberports and 181 10:13.900 --> 10:18.670 Having loop guard enabled is really a good thing from the perspective of maybe 182 10:18.670 --> 10:21.780 a spanning tree process failing versus a 183 10:21.780 --> 10:26.260 Link becoming unidirectional. So with that said, let's go ahead and answer the 184 10:26.260 --> 10:28.980 question of what scenario is loop guard going to help to prevent a loop 185 10:29.260 --> 10:33.910 well what we have here is a situation where switch has two upstream interfaces WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 185 10:29.260 --> 10:33.910 well what we have here is a situation where switch has two upstream interfaces 186 10:33.910 --> 10:35.220 and it's blocking one and 187 10:35.220 --> 10:40.770 Always remember that in order to keep a port blocking from a spanning tree 188 10:40.770 --> 10:43.780 perspective. I must be receiving BPD use 189 10:43.780 --> 10:49.540 Now these BPD use are going to be better than mine on some level because I know 190 10:49.540 --> 10:51.240 that this is an upstream 191 10:51.240 --> 10:56.060 Interface it's closer to the root to go that way in that sense 192 10:56.060 --> 10:59.060 It's an alternate port for me if this port goes down I can swing over 193 10:59.060 --> 11:00.860 especially with rapid spanning tree and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 193 10:59.060 --> 11:00.860 especially with rapid spanning tree and 194 11:00.860 --> 11:05.610 So we know that that means it's an upstream port and then I have downstream 195 11:05.610 --> 11:06.940 ports down here as well 196 11:06.940 --> 11:10.660 The question is what happens if these BPD use stop coming? 197 11:10.660 --> 11:15.380 Spanning tree suggests that if the BPD use stop coming but the port is still 198 11:15.380 --> 11:16.020 online 199 11:16.020 --> 11:18.620 That it's not an upstream port anymore 200 11:18.620 --> 11:23.110 It's now a downstream port if it's a downstream port that means I don't need to 201 11:23.110 --> 11:25.460 be blocking and I can send my own BPD use 202 11:25.460 --> 11:31.380 And that's a big problem if that port remains online and we actually still have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 202 11:25.460 --> 11:31.380 And that's a big problem if that port remains online and we actually still have 203 11:31.380 --> 11:32.260 a loop here 204 11:32.260 --> 11:37.600 We talked about in the skill a situation where maybe the spanning tree protocol 205 11:37.600 --> 11:39.060 process fails on the switch 206 11:39.060 --> 11:43.780 Maybe it's a unidirectional situation. We don't know what the problem is 207 11:43.780 --> 11:50.140 But we do know that in a modern network BPD use not showing up is not a normal 208 11:50.140 --> 11:50.340 situation 209 11:50.900 --> 11:54.960 Back in the day if we had a hub in here, sure that could absolutely happen and 210 11:54.960 --> 11:56.340 then we could not use loop guard 211 11:56.340 --> 11:59.140 But in a modern network loop guard is 212 11:59.140 --> 12:04.870 Absolutely going to help us here because there's no normal situation where this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 212 11:59.140 --> 12:04.870 Absolutely going to help us here because there's no normal situation where this 213 12:04.870 --> 12:07.500 happens and so at that point 214 12:07.500 --> 12:12.270 We are going to place the port into that inconsistent state meaning that it's 215 12:12.270 --> 12:13.780 broken or blocking and 216 12:13.780 --> 12:20.580 We essentially just lock in this blocked port the theory is that if that link 217 12:20.900 --> 12:23.620 Had gone down sure that's one thing 218 12:23.620 --> 12:28.630 But if it's up still then we would never want to transition from blocking to 219 12:28.630 --> 12:31.580 affording if we know it's an upstream port WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 219 12:28.630 --> 12:31.580 affording if we know it's an upstream port 220 12:31.580 --> 12:36.980 So the answer here is D BPD use stop showing up where they had been arriving 221 12:36.980 --> 12:39.420 That is where loop guard is going to help us 222 12:39.420 --> 12:43.080 All right last question and it's meant to be a fun one. I encourage you to 223 12:43.080 --> 12:45.340 pause the video and follow the instructions 224 12:45.940 --> 12:50.660 Sketch this out on a separate sheet of paper and then again mark this topology 225 12:50.660 --> 12:53.940 with indicators for where each of the protection mechanisms belong 226 12:53.940 --> 12:57.500 All right, let's go through each one individually BPDU guard 227 12:57.500 --> 13:00.780 We know BPDU guard blocks against all BPDUs WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 227 12:57.500 --> 13:00.780 We know BPDU guard blocks against all BPDUs 228 13:00.780 --> 13:06.570 So I'm going to place BPDU guard onto my access ports where I don't expect to 229 13:06.570 --> 13:07.860 ever receive a BPDU 230 13:07.860 --> 13:12.260 I can't place on any other ports because I'm expecting to receive BPDUs there 231 13:12.500 --> 13:16.100 Now root guard on the other hand is all about looking for 232 13:16.100 --> 13:21.100 Superior BPDUs coming in so I'm going to place root guard here on 233 13:21.100 --> 13:23.780 my downstream ports 234 13:23.780 --> 13:29.000 For switch one and switch two we also remember we can't enable root guard on a 235 13:29.000 --> 13:31.020 per VLAN per topology basis WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 235 13:29.000 --> 13:31.020 per VLAN per topology basis 236 13:31.020 --> 13:36.030 And so I can't place it on these ports because I am getting superior BPDUs on 237 13:36.030 --> 13:37.940 one VLAN or another on each side 238 13:38.180 --> 13:43.980 Now next is UDLD and UDLD is largely a fiber conversation 239 13:43.980 --> 13:46.900 Once again, we would expect to deploy it globally 240 13:46.900 --> 13:51.970 But if I were to deploy it here in this topology explicitly, I would have to 241 13:51.970 --> 13:53.740 enable it on both sides of a link 242 13:53.740 --> 13:57.340 And so I would place it on all of these connections 243 13:57.340 --> 14:00.500 between the among the switches really and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 243 13:57.340 --> 14:00.500 between the among the switches really and 244 14:00.500 --> 14:05.200 Loop guard is going to be the same way loop guard is something that's meant to 245 14:05.200 --> 14:06.180 be looking for 246 14:07.220 --> 14:11.860 BPDU stopping to come in so I place these here loop guard 247 14:11.860 --> 14:16.950 It is one sided. I don't need it configured on the other side. There's 248 14:16.950 --> 14:19.020 certainly no harm in configuring it on the other side 249 14:19.020 --> 14:22.940 It's just given the root situation. I wouldn't expect to need it there 250 14:22.940 --> 14:27.230 So I could enable it globally on switch three and switch four or I could enable 251 14:27.230 --> 14:28.300 it on those uplinks 252 14:28.300 --> 14:32.380 So that is where we would expect to deploy all of these different topology WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 252 14:28.300 --> 14:32.380 So that is where we would expect to deploy all of these different topology 253 14:32.380 --> 14:32.980 mechanisms 254 14:33.060 --> 14:37.940 This is a great example or great exercise because it forces us to make sure we 255 14:37.940 --> 14:39.780 understand what these topology 256 14:39.780 --> 14:44.020 Mechanisms are doing or these topology protection mechanisms are doing and 257 14:44.020 --> 14:45.540 where they belong in a network 258 14:45.540 --> 14:47.900 So with that, let's go ahead and move on to the next topic 259 14:47.900 --> 14:48.760 Welcome.