WEBVTT 1 00:00.000 --> 00:05.000 Well, BPDU Guard was a great start, but it can't be used on all interfaces. 2 00:05.000 --> 00:09.520 For example, what if we've got our distribution layer here and we've got our 3 00:09.520 --> 00:10.620 access layer 4 00:10.620 --> 00:15.050 and we've got BPDU Guard down here, which is exactly where it belongs at the 5 00:15.050 --> 00:15.600 edge of 6 00:15.600 --> 00:16.800 the network. 7 00:16.800 --> 00:20.150 But then I'm going to connect this access layer, switch up to the distribution 8 00:20.150 --> 00:20.880 layer, 9 00:20.880 --> 00:26.000 and what if this is a 4K priority on the root? 10 00:26.000 --> 00:30.280 And then we have an 8K priority on the backup root, but then down here we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:26.000 --> 00:30.280 And then we have an 8K priority on the backup root, but then down here we 11 00:30.280 --> 00:31.160 configure this 12 00:31.160 --> 00:32.400 to be a zero. 13 00:32.400 --> 00:36.670 Maybe it was a misconfiguration, maybe it was, again, an old lab switch that 14 00:36.670 --> 00:37.520 was accidentally 15 00:37.520 --> 00:39.280 connected to the network. 16 00:39.280 --> 00:43.270 Maybe it was malicious, but either way, this switch is going to take over as 17 00:43.270 --> 00:44.000 the root. 18 00:44.000 --> 00:47.960 I say, well, maybe we should deploy BPDU Guard, but we can't. 19 00:47.960 --> 00:53.960 We can't deploy BPDU Guard up here because even though BPDU's tend to flow only 20 00:53.960 --> 00:55.200 downstream, 21 00:55.200 --> 00:59.140 we might have a situation where this port goes down and then it comes up and 22 00:59.140 --> 00:59.480 when the 23 00:59.480 --> 01:03.320 port comes up, this switch sends a BPDU first. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 23 00:59.480 --> 01:03.320 port comes up, this switch sends a BPDU first. 24 01:03.320 --> 01:06.160 Yeah, it's inferior, so it doesn't really matter. 25 01:06.160 --> 01:11.960 But if we have BPDU Guard configured here, then that port will be placed into 26 01:11.960 --> 01:13.200 air disable. 27 01:13.200 --> 01:17.410 And so we cannot place BPDU Guard here on the off chance that we receive an 28 01:17.410 --> 01:18.000 inferior 29 01:18.000 --> 01:19.600 BPDU. 30 01:19.600 --> 01:25.530 So now we have this situation where BPDU Guard is great when there should be no 31 01:25.530 --> 01:27.840 BPDU's expected. 32 01:27.840 --> 01:34.710 But now we need something for up here where we say that inferior BPDUs are okay WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:27.840 --> 01:34.710 But now we need something for up here where we say that inferior BPDUs are okay 33 01:34.710 --> 01:35.160 . 34 01:35.160 --> 01:43.210 However, if we have a superior BPDU come in, then this is not okay for lack of 35 01:43.210 --> 01:43.920 better 36 01:43.920 --> 01:45.640 words. 37 01:45.640 --> 01:49.530 This is the mechanism that, or this is going to lead us to a conversation 38 01:49.530 --> 01:50.640 around a mechanism 39 01:50.640 --> 01:56.050 that's going to do exactly this for us to allow the inferior BPDUs to come in, 40 01:56.050 --> 01:56.600 but not 41 01:56.600 --> 01:58.960 allow superior BPDUs. 42 01:58.960 --> 02:04.290 So that mechanism in particular that we're talking about here is going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:58.960 --> 02:04.290 So that mechanism in particular that we're talking about here is going to be 43 02:04.290 --> 02:04.920 known as 44 02:04.920 --> 02:06.600 root guard. 45 02:06.600 --> 02:12.610 Now yes, there is a pretty large similarity in some of these mechanism names, B 46 02:12.610 --> 02:13.360 PDU Guard 47 02:13.360 --> 02:17.600 or root guard, it's not always easy to keep them all apart in our minds. 48 02:17.600 --> 02:22.590 So as best we can, just keep in mind that BPDU Guard protects against any BPDUs 49 02:22.590 --> 02:23.200 coming 50 02:23.200 --> 02:27.800 in, whereas root guard prevents any kind of root claim from coming in. 51 02:27.800 --> 02:30.200 So try to think of it in that terms. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 51 02:27.800 --> 02:30.200 So try to think of it in that terms. 52 02:30.200 --> 02:34.200 We're trying to block superior BPDUs, meaning you're claiming to be the root. 53 02:34.200 --> 02:36.320 Therefore, I'm going to block you. 54 02:36.320 --> 02:42.120 So root guard is going to go on downstream interfaces. 55 02:42.120 --> 02:46.960 Now remember, in our modern networks, we have a sense of what a downstream 56 02:46.960 --> 02:48.000 interface should 57 02:48.000 --> 02:49.000 be. 58 02:49.000 --> 02:54.200 We know that our root is here at the distribution layer with intentionality, 59 02:54.200 --> 02:55.000 meaning that these 60 02:55.000 --> 03:00.790 two interfaces going down towards axis layer switches should be considered WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 60 02:55.000 --> 03:00.790 two interfaces going down towards axis layer switches should be considered 61 03:00.790 --> 03:02.040 downstream. 62 03:02.040 --> 03:06.640 These are ports that are normally going to be in designated port status. 63 03:06.640 --> 03:08.200 So remember our roles. 64 03:08.200 --> 03:11.220 We've got root ports, designated ports. 65 03:11.220 --> 03:16.560 This is going to be a DP role in a stable network. 66 03:16.560 --> 03:22.840 And importantly, it's going to allow our inferior BPDUs. 67 03:22.840 --> 03:27.910 So if that link flaps for any reason, or if I'm just, for that matter, allowing 68 03:27.910 --> 03:28.480 a, or 69 03:28.480 --> 03:32.670 bringing a new switch online, then it's going to allow those inferior BPDUs to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 03:28.480 --> 03:32.670 bringing a new switch online, then it's going to allow those inferior BPDUs to 70 03:32.670 --> 03:33.480 show up because 71 03:33.480 --> 03:35.480 it ignores inferior BPDUs. 72 03:35.480 --> 03:37.960 They don't impact my topology. 73 03:37.960 --> 03:41.750 In fact, all I have to do is wait for my Hello Timer to expire, and I will send 74 03:41.750 --> 03:42.540 the superior 75 03:42.540 --> 03:44.220 BPDU. 76 03:44.220 --> 03:47.720 And as long as everybody's playing by the right rules, the axis switch will 77 03:47.720 --> 03:48.380 recognize, 78 03:48.380 --> 03:50.540 hey, I'm not actually the root. 79 03:50.540 --> 03:54.420 And therefore I'm going to stop sending BPDUs upstream. 80 03:54.420 --> 03:58.330 But even if for any reason it keeps sending inferior BPDUs upstream, that's 81 03:58.330 --> 03:59.060 fine because 82 03:59.060 --> 04:04.180 inferior BPDUs always get ignored. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 82 03:59.060 --> 04:04.180 inferior BPDUs always get ignored. 83 04:04.180 --> 04:08.710 And I will, as the root, or as another switch, I will continue to send the 84 04:08.710 --> 04:09.800 superior BPDUs 85 04:09.800 --> 04:12.600 down that link. 86 04:12.600 --> 04:17.560 So what happens if a superior BPDU is received on a root guard port? 87 04:17.560 --> 04:21.690 Well, at this point, what happens is we've got a device, and this could be the 88 04:21.690 --> 04:22.280 root. 89 04:22.280 --> 04:24.560 It could just be an upstream switch. 90 04:24.560 --> 04:27.480 And so I connect this switch down here with a priority of zero. 91 04:27.480 --> 04:32.840 It sends a superior BPDU, and we have root guard enabled. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 04:27.480 --> 04:32.840 It sends a superior BPDU, and we have root guard enabled. 92 04:32.840 --> 04:40.400 But what's going to happen is we're going to place that port, that interface, 93 04:40.400 --> 04:41.020 into an 94 04:41.020 --> 04:43.220 interesting status. 95 04:43.220 --> 04:49.660 We're going to call this STP, your Spanning Tree Protocol, inconsistent state. 96 04:49.660 --> 04:54.790 This is not a state that we have covered because it's really not a real 97 04:54.790 --> 04:55.900 spanning tree 98 04:55.900 --> 04:56.900 state. 99 04:56.900 --> 05:00.430 This is something that, again, ties to these Cisco enhancements that are going WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 04:56.900 --> 05:00.430 This is something that, again, ties to these Cisco enhancements that are going 100 05:00.430 --> 05:00.880 to allow 101 05:00.880 --> 05:02.880 us to protect our network. 102 05:02.880 --> 05:08.600 The STP inconsistent is essentially saying, "Hey, we're going to temporarily 103 05:08.600 --> 05:09.320 block a 104 05:09.320 --> 05:10.820 port." 105 05:10.820 --> 05:14.690 Meaning that we're not placing it into shutdown, we're not doing any kind of 106 05:14.690 --> 05:15.560 air disable or 107 05:15.560 --> 05:17.280 anything like that. 108 05:17.280 --> 05:20.800 That is not what root guard is going to do for us. 109 05:20.800 --> 05:24.410 We don't need to worry about a port being inaccessible and us having to go 110 05:24.410 --> 05:24.980 manually 111 05:24.980 --> 05:28.280 intervene or rely on air disable recovery. 112 05:28.280 --> 05:31.640 In this case, we are temporarily blocking the port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 112 05:28.280 --> 05:31.640 In this case, we are temporarily blocking the port. 113 05:31.640 --> 05:37.070 As long as I'm receiving superior BPDUs, I'm going to keep this port in an STP 114 05:37.070 --> 05:38.160 inconsistent 115 05:38.160 --> 05:39.160 state. 116 05:39.160 --> 05:43.390 We'll see in the lab later that this actually does show up as the status in our 117 05:43.390 --> 05:44.080 Spanning 118 05:44.080 --> 05:46.200 Tree commands. 119 05:46.200 --> 05:52.630 The keyword here is temporarily, meaning that once the superior BPDUs stop, 120 05:52.630 --> 05:54.040 once the superior 121 05:54.040 --> 06:00.460 BPDUs stop, then we place this back into our STP listening state and ideally we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 121 05:54.040 --> 06:00.460 BPDUs stop, then we place this back into our STP listening state and ideally we 122 06:00.460 --> 06:01.600 transition 123 06:01.600 --> 06:04.440 all the way up to forwarding. 124 06:04.440 --> 06:08.170 This is meant to protect us in the event that, oops, I accidentally connected a 125 06:08.170 --> 06:08.880 switch with 126 06:08.880 --> 06:10.480 the bed priority. 127 06:10.480 --> 06:14.720 Fortunately, the network was protected by root guard, so I get in here. 128 06:14.720 --> 06:19.120 I make my configuration change. 129 06:19.120 --> 06:25.360 Now it's no longer zero, but it is back to its default 32K, whatever it is I 130 06:25.360 --> 06:26.840 set it to. 131 06:26.840 --> 06:30.820 At this point, the superior BPDUs stop, meaning that I transition from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 131 06:26.840 --> 06:30.820 At this point, the superior BPDUs stop, meaning that I transition from 132 06:30.820 --> 06:32.120 inconsistent now to 133 06:32.120 --> 06:37.450 listening, which eventually goes to learning, which eventually goes to 134 06:37.450 --> 06:38.280 forwarding. 135 06:38.280 --> 06:42.610 Root guard is a very important part of our protection mechanisms and it's 136 06:42.610 --> 06:43.400 absolutely 137 06:43.400 --> 06:46.400 critical that we deploy this into our networks. 138 06:46.400 --> 06:50.920 The question is always where, where are we deploying these key technologies? 139 06:50.920 --> 06:58.630 So I have my distribution layer here, I have my access layer, switches, and so 140 06:58.630 --> 06:59.520 as we've 141 06:59.520 --> 07:04.200 said, our BPDU guard is going to go down here at the edge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 141 06:59.520 --> 07:04.200 said, our BPDU guard is going to go down here at the edge. 142 07:04.200 --> 07:08.400 This is where there's not to be any switches at all. 143 07:08.400 --> 07:12.480 However, that doesn't help us on these links that are among switches. 144 07:12.480 --> 07:14.880 So where does root guard go? 145 07:14.880 --> 07:18.970 Root guard is going to again go on our downstream interfaces specifically here 146 07:18.970 --> 07:20.760 and here, but 147 07:20.760 --> 07:27.210 if for any reason I do have switches hanging off of other switches at the 148 07:27.210 --> 07:28.560 access layer, 149 07:28.560 --> 07:30.680 then it can also go here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 149 07:28.560 --> 07:30.680 then it can also go here. 150 07:30.680 --> 07:35.800 It's any downstream interface in my established topology. 151 07:35.800 --> 07:39.230 And so that prevents a switch from showing up down here, the priority of zero, 152 07:39.230 --> 07:39.560 and this 153 07:39.560 --> 07:43.480 switch thinking that this is the root, at which point root guard will still 154 07:43.480 --> 07:44.320 protect the 155 07:44.320 --> 07:48.280 distribution layer, but it wouldn't actually protect this intermediary switch. 156 07:48.280 --> 07:55.950 So that's why it's useful to put on all downstream ports, again in our stable 157 07:55.950 --> 07:57.040 state or steady 158 07:57.040 --> 07:59.840 state topology. 159 07:59.840 --> 08:01.040 Now here's the question. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 159 07:59.840 --> 08:01.040 Now here's the question. 160 08:01.040 --> 08:03.880 What about this link in here? 161 08:03.880 --> 08:09.200 Because technically speaking, this is a downstream connection. 162 08:09.200 --> 08:12.640 And so we could put root guard on that port here. 163 08:12.640 --> 08:17.300 But it doesn't really, it's not as effective because in this particular 164 08:17.300 --> 08:18.960 scenario, the distribution 165 08:18.960 --> 08:20.160 layer is pretty well set. 166 08:20.160 --> 08:25.100 I mean, the odds of somebody coming in here and changing the priority statement 167 08:25.100 --> 08:25.280 number 168 08:25.280 --> 08:26.840 one is pretty unlikely. 169 08:26.840 --> 08:28.640 It's a very important switch. 170 08:28.640 --> 08:33.010 But number two, it also isn't the worst case scenario for us to have to deal WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 170 08:28.640 --> 08:33.010 But number two, it also isn't the worst case scenario for us to have to deal 171 08:33.010 --> 08:33.760 with that. 172 08:33.760 --> 08:38.780 The topology will shift where now the other distribution switch is the root and 173 08:38.780 --> 08:39.200 yes, that 174 08:39.200 --> 08:43.360 will create a disruptive event, but at least the root remains in the 175 08:43.360 --> 08:44.920 distribution layer. 176 08:44.920 --> 08:49.240 So that's fine to put the root guard here. 177 08:49.240 --> 08:51.960 But here's the biggest caveat. 178 08:51.960 --> 08:59.660 Root guard is not perviland, meaning that if I have multiple topologies in a 179 08:59.660 --> 09:00.840 perviland WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 08:59.660 --> 09:00.840 perviland 180 09:00.840 --> 09:06.130 spanning tree environment, which I absolutely should, well now I can no longer 181 09:06.130 --> 09:06.560 place that 182 09:06.560 --> 09:12.100 link into a root guard perspective because I'm going to be getting superior BP 183 09:12.100 --> 09:12.600 to use 184 09:12.600 --> 09:15.200 this way for the other VLANs. 185 09:15.200 --> 09:21.520 So long story short, we do not actually apply root guard onto this interface 186 09:21.520 --> 09:22.560 between our 187 09:22.560 --> 09:27.150 distribution switches as much as anything because we cannot do it on a perv 188 09:27.150 --> 09:28.120 iland basis. 189 09:28.120 --> 09:32.760 And therefore we can't define which side is downstream perviland. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 09:28.120 --> 09:32.760 And therefore we can't define which side is downstream perviland. 190 09:32.760 --> 09:38.290 So root guard primarily belongs down here on these interfaces facing the access 191 09:38.290 --> 09:38.760 layer 192 09:38.760 --> 09:43.210 and it can also go down here on access layer switches that face other access 193 09:43.210 --> 09:44.160 layer switches 194 09:44.160 --> 09:48.840 always again in the downstream direction. 195 09:48.840 --> 09:52.120 Now one last note on the configuration. 196 09:52.120 --> 09:55.990 We mentioned before that BP-DU guard belongs at the edge and therefore can be 197 09:55.990 --> 09:56.480 deployed 198 09:56.480 --> 09:59.120 automatically to all of our edge ports. 199 09:59.120 --> 10:02.280 And that's based on a port being in access mode. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 199 09:59.120 --> 10:02.280 And that's based on a port being in access mode. 200 10:02.280 --> 10:05.560 Root guard doesn't have that same benefit. 201 10:05.560 --> 10:11.000 Root guard must be configured on every single interface. 202 10:11.000 --> 10:15.270 And this is with intention because we as network admins have to define which 203 10:15.270 --> 10:16.040 interfaces 204 10:16.040 --> 10:18.720 are intended to connect to other switches. 205 10:18.720 --> 10:23.620 Again I have to decide which of these interfaces are downstream and will be 206 10:23.620 --> 10:25.000 receiving on occasion 207 10:25.000 --> 10:27.200 those inferior BP-DUs. 208 10:27.200 --> 10:31.250 So I must do the configuration myself, I can't automatically deploy this and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 208 10:27.200 --> 10:31.250 So I must do the configuration myself, I can't automatically deploy this and 209 10:31.250 --> 10:31.560 that really 210 10:31.560 --> 10:36.590 again does make sense given the location and the role that we expect root guard 211 10:36.590 --> 10:37.080 to play.