WEBVTT 1 00:00.000 --> 00:03.880 All right, so let's remember our scenario here. 2 00:03.880 --> 00:10.250 The idea is that loops can form if we have an established topology and we've 3 00:10.250 --> 00:10.520 got some 4 00:10.520 --> 00:15.440 kind of loop type of physical loop where spanning tree is blocking a port here. 5 00:15.440 --> 00:21.740 We're receiving our BPDUs to maintain that topology and then the BPDUs just 6 00:21.740 --> 00:22.520 stop. 7 00:22.520 --> 00:27.650 Now if this stops because of a unidirectional link and we have UDLD configured, 8 00:27.650 --> 00:28.480 then we're 9 00:28.480 --> 00:32.480 good to go because we're just going to shut that link down from whichever side WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:28.480 --> 00:32.480 good to go because we're just going to shut that link down from whichever side 10 00:32.480 --> 00:33.040 detects 11 00:33.040 --> 00:37.560 the unidirectionality, maybe both sides place it into air disable. 12 00:37.560 --> 00:40.640 But what if this isn't actually the situation? 13 00:40.640 --> 00:46.750 What if we are in a bidirectional link type of scenario and yet the BPDUs still 14 00:46.750 --> 00:47.520 stop? 15 00:47.520 --> 00:48.920 What would even cause that? 16 00:48.920 --> 00:52.800 Well, believe it or not, I actually got to experience this firsthand. 17 00:52.800 --> 00:56.760 As a consultant, I was called down one of our major customers that their whole 18 00:56.760 --> 00:57.080 data 19 00:57.080 --> 01:00.120 center was down and they couldn't figure out what was going on. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:57.080 --> 01:00.120 center was down and they couldn't figure out what was going on. 20 01:00.120 --> 01:01.960 Fortunately, they're only about 20 minutes away. 21 01:01.960 --> 01:05.890 I popped in my car and drove over there, started logging into the consoles on 22 01:05.890 --> 01:07.040 their core devices 23 01:07.040 --> 01:11.870 and their data center, come to find out that for whatever reason, one of their 24 01:11.870 --> 01:12.800 aggregation 25 01:12.800 --> 01:17.270 switches, so this would be like their distribution switch in the data center, 26 01:17.270 --> 01:18.320 which was the root 27 01:18.320 --> 01:23.360 bridge at the time, just decided to stop sending BPDUs. 28 01:23.360 --> 01:28.710 But spanning tree protocol process that's supposed to send the BPDUs out just 29 01:28.710 --> 01:29.360 crashed 30 01:29.360 --> 01:33.390 and it didn't take all of the iOS device down, it didn't crash the whole switch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:29.360 --> 01:33.390 and it didn't take all of the iOS device down, it didn't crash the whole switch 31 01:33.390 --> 01:33.640 , it 32 01:33.640 --> 01:36.320 just crashed spanning tree topology. 33 01:36.320 --> 01:40.070 It's one of those situations that feels like it's something that should never 34 01:40.070 --> 01:40.640 actually 35 01:40.640 --> 01:43.520 happen and yet it absolutely happened. 36 01:43.520 --> 01:47.430 And had they had loop guard deployed into their environment, then that would 37 01:47.430 --> 01:47.920 not have 38 01:47.920 --> 01:49.120 been a problem. 39 01:49.120 --> 01:52.720 Unfortunately, they set their own environment up and so all of our best 40 01:52.720 --> 01:54.040 practices for deploying 41 01:54.040 --> 01:57.220 loop guard didn't actually happen to be in place. 42 01:57.220 --> 02:02.220 And so what happened was the BPDUs stopped because the spanning tree protocol WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 42 01:57.220 --> 02:02.220 And so what happened was the BPDUs stopped because the spanning tree protocol 43 02:02.220 --> 02:02.840 process 44 02:02.840 --> 02:08.110 stopped and because this switch downstream stopped receiving the BPDUs, it 45 02:08.110 --> 02:09.000 transferred 46 02:09.000 --> 02:14.790 that block state into forwarding and as a result, there was a massive loop in 47 02:14.790 --> 02:16.800 the data center. 48 02:16.800 --> 02:20.160 And I wish I could say we just got the network back online and everything was 49 02:20.160 --> 02:21.080 good to go, 50 02:21.080 --> 02:25.960 but because the network was down for 20 minutes or so, 25, 30 minutes, whatever 51 02:25.960 --> 02:27.120 it was, we 52 02:27.120 --> 02:32.280 got it back online, but their data center experienced a massive data corruption WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 02:27.120 --> 02:32.280 got it back online, but their data center experienced a massive data corruption 53 02:32.280 --> 02:32.520 out 54 02:32.520 --> 02:34.760 of that they were down for a very long time. 55 02:34.760 --> 02:40.580 So it's amazing how loop guard in this environment could have actually saved 56 02:40.580 --> 02:41.800 them from literal 57 02:41.800 --> 02:48.040 days of outages as a result of this simple network outage. 58 02:48.040 --> 02:53.130 So what exactly is loop guard and how is it going to keep us up in this 59 02:53.130 --> 02:54.160 scenario? 60 02:54.160 --> 02:59.630 Well, loop guard sort of does the same thing as UDLD, except it does it from a 61 02:59.630 --> 03:00.280 spanning WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 61 02:59.630 --> 03:00.280 spanning 62 03:00.280 --> 03:02.600 tree protocol perspective. 63 03:02.600 --> 03:09.320 It's going to be watching for BPDUs and specifically when BPDUs stop. 64 03:09.320 --> 03:15.590 If BPDUs stop coming in and the link stays online, which was again part of this 65 03:15.590 --> 03:16.840 scenario, 66 03:16.840 --> 03:21.830 BPDU stop, the link stays online, it says, you know what, in a hubless 67 03:21.830 --> 03:23.160 environment, this 68 03:23.160 --> 03:24.160 is not okay. 69 03:24.160 --> 03:27.780 Remember, the reason why spanning tree says that this is okay is because there 70 03:27.780 --> 03:28.120 might 71 03:28.120 --> 03:29.520 be a hub in here. 72 03:29.520 --> 03:34.600 Like we said, and this link up here goes down, but in the modern network, or at WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 72 03:29.520 --> 03:34.600 Like we said, and this link up here goes down, but in the modern network, or at 73 03:34.600 --> 03:35.320 least in 74 03:35.320 --> 03:38.500 any network where we're being intentional about things, we can look at that and 75 03:38.500 --> 03:38.760 say 76 03:38.760 --> 03:40.760 there is no hub there. 77 03:40.760 --> 03:45.400 And therefore, this is not okay. 78 03:45.400 --> 03:47.240 And so we're going to block the port. 79 03:47.240 --> 03:50.080 Now loop guard doesn't throw it into air disable. 80 03:50.080 --> 03:58.200 Instead it uses that spanning tree protocol inconsistent state inconsistent. 81 03:58.200 --> 04:03.730 And because it uses spanning tree protocol inconsistent, it will actually place WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 03:58.200 --> 04:03.730 And because it uses spanning tree protocol inconsistent, it will actually place 82 04:03.730 --> 04:04.280 it into 83 04:04.280 --> 04:07.800 not the blocking state, but that broken state that we saw. 84 04:07.800 --> 04:13.810 And then if the BPDUs come back and now we're getting those BPDUs again, it 85 04:13.810 --> 04:15.520 will transition 86 04:15.520 --> 04:18.560 to the forwarding state. 87 04:18.560 --> 04:23.370 So loop guard in a way maintains our topology, but it's focusing on the loop 88 04:23.370 --> 04:25.240 protection element. 89 04:25.240 --> 04:29.080 It's saying, hey, I don't care why the BPDUs stopped. 90 04:29.080 --> 04:32.490 If the BPDU stopped for any reason, whether it was a unidirectional link or a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:29.080 --> 04:32.490 If the BPDU stopped for any reason, whether it was a unidirectional link or a 91 04:32.490 --> 04:33.040 spanning 92 04:33.040 --> 04:37.480 tree protocol failure, whatever the situation doesn't matter, that link is 93 04:37.480 --> 04:38.720 online, the BPDU 94 04:38.720 --> 04:42.520 stopped, and that's not okay for lack of better words. 95 04:42.520 --> 04:46.440 And so we're going to go into that broken state via STP inconsistent. 96 04:46.440 --> 04:52.730 And that's effectively holding and maintaining the blocking nature of that 97 04:52.730 --> 04:53.040 interface. 98 04:53.040 --> 04:58.790 Now just like with UDLD, we can enable this on a per port or on a global 99 04:58.790 --> 05:00.160 perspective or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 04:58.790 --> 05:00.160 perspective or 100 05:00.160 --> 05:01.360 global level. 101 05:01.360 --> 05:03.840 However, in this case, it's the same. 102 05:03.840 --> 05:07.600 We're not focusing on fiber versus copper because this could happen on any type 103 05:07.600 --> 05:08.600 of port. 104 05:08.600 --> 05:12.840 It's not more likely on fiber versus copper or anything like that. 105 05:12.840 --> 05:17.100 So if we do it to global or if we do enable it globally, this is going to 106 05:17.100 --> 05:17.880 enable it on 107 05:17.880 --> 05:20.320 all ports. 108 05:20.320 --> 05:23.440 And we might look at that and say, okay, is there any harm in that? 109 05:23.440 --> 05:25.040 Generally speaking, the answer is no. 110 05:25.040 --> 05:26.920 There is no harm in loop guard. 111 05:26.920 --> 05:30.740 The only harm with loop guard would be if there is that hub sitting out there WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 111 05:26.920 --> 05:30.740 The only harm with loop guard would be if there is that hub sitting out there 112 05:30.740 --> 05:31.480 somewhere in 113 05:31.480 --> 05:35.360 which case we would not want to keep that port in a blocking state. 114 05:35.360 --> 05:39.230 But if there are no hubs in our environment, which is every single environment, 115 05:39.230 --> 05:39.840 every single 116 05:39.840 --> 05:43.960 network in the modern era, then this is perfectly fine. 117 05:43.960 --> 05:47.240 This is a okay. 118 05:47.240 --> 05:50.870 And generally speaking, in production networks, we want to see loop guard 119 05:50.870 --> 05:51.800 enabled globally 120 05:51.800 --> 05:53.800 so that it's running on every single port.