WEBVTT 1 00:00.000 --> 00:04.660 We've mentioned a few different times that things happen in a spanning tree top 2 00:04.660 --> 00:05.280 ology 3 00:05.280 --> 00:08.280 according to specific timers. 4 00:08.280 --> 00:13.040 So for example, we talked about how we send BPDUs every two seconds. 5 00:13.040 --> 00:18.240 Well that's because we have a hello timer that is configured as part of our 6 00:18.240 --> 00:19.040 spanning 7 00:19.040 --> 00:25.040 tree operation and the default value, as we look at all of these having default 8 00:25.040 --> 00:25.760 values, 9 00:25.760 --> 00:28.240 the default is two seconds. 10 00:28.240 --> 00:29.960 So what exactly is the little timer? 11 00:29.960 --> 00:35.600 Well once again, it's how often BPDUs get generated. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:29.960 --> 00:35.600 Well once again, it's how often BPDUs get generated. 12 00:35.600 --> 00:40.240 So the root switch is responsible for sending out BPDUs and it will send it out 13 00:40.240 --> 00:40.920 not every 14 00:40.920 --> 00:46.080 two seconds necessarily, but ultimately what really matters is whatever the 15 00:46.080 --> 00:46.960 hello timer 16 00:46.960 --> 00:47.960 is set to. 17 00:47.960 --> 00:51.240 So if we set it to three seconds, then BPDUs will be sent out every three 18 00:51.240 --> 00:51.920 seconds and 19 00:51.920 --> 00:55.200 we could send it to one second if we desired as well. 20 00:55.200 --> 00:59.640 There's also a timer known as the forwarding delay. 21 00:59.640 --> 01:06.200 The forwarding delay defaults to 15 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:59.640 --> 01:06.200 The forwarding delay defaults to 15 seconds. 22 01:06.200 --> 01:10.590 And this value might sound familiar, recall that when we are in the listening 23 01:10.590 --> 01:11.120 state or 24 01:11.120 --> 01:15.120 the learning state that it was going to sit in that state for 15 seconds. 25 01:15.120 --> 01:22.560 Well again, these are default values, but each one of these states are going to 26 01:22.560 --> 01:22.760 use 27 01:22.760 --> 01:27.380 the forwarding delay, which effectively means that we're going to be in these 28 01:27.380 --> 01:28.040 two states 29 01:28.040 --> 01:32.280 for two times the forward delay. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 29 01:28.040 --> 01:32.280 for two times the forward delay. 30 01:32.280 --> 01:35.560 So if I have the forwarding delay set to the default of 15 seconds, that means 31 01:35.560 --> 01:36.000 we're going 32 01:36.000 --> 01:39.690 to be in listening and learning for 30 seconds, which is exactly what we had 33 01:39.690 --> 01:40.320 said when we 34 01:40.320 --> 01:42.120 covered this earlier on. 35 01:42.120 --> 01:46.430 However, if I change the forwarding delay to be say 10 seconds, well that doesn 36 01:46.430 --> 01:47.000 't remove 37 01:47.000 --> 01:53.010 five seconds from our final timer, it actually removes 10 seconds because it 38 01:53.010 --> 01:55.040 removes it twice, 39 01:55.040 --> 01:58.800 thanks to the fact that both of these states use the forwarding delay. 40 01:58.800 --> 02:03.680 Now lastly, we have a really interesting timer known as the max age. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 40 01:58.800 --> 02:03.680 Now lastly, we have a really interesting timer known as the max age. 41 02:03.680 --> 02:07.520 And the max age is going to default to 20 seconds. 42 02:07.520 --> 02:12.720 And we have yet to really explore a situation that requires max age. 43 02:12.720 --> 02:17.620 Now one thing to consider before we jump into spanning tree protocol timers is 44 02:17.620 --> 02:18.160 the fact 45 02:18.160 --> 02:22.920 that these same timers are going to be used in rapid spanning tree. 46 02:22.920 --> 02:26.720 And Cisco's version of rapid is rapid pbsd plus. 47 02:26.720 --> 02:29.680 So let's talk about this just for a quick moment. 48 02:29.680 --> 02:32.480 We're going to go into details on rapid spanning tree coming up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 48 02:29.680 --> 02:32.480 We're going to go into details on rapid spanning tree coming up. 49 02:32.480 --> 02:35.880 But as we said at the start of the spanning tree conversation, rapid spanning 50 02:35.880 --> 02:36.280 tree is 51 02:36.280 --> 02:40.640 built on the same principles as basic spanning tree. 52 02:40.640 --> 02:43.960 And when I say the same principles, that includes the same timers. 53 02:43.960 --> 02:47.510 As the name implies, rapid spanning tree is going to speed things up, 54 02:47.510 --> 02:48.400 especially around 55 02:48.400 --> 02:51.360 convergence in the event that a link goes down. 56 02:51.360 --> 02:57.050 Traditional 802 dot 1d spanning tree might take 30 or even 50 seconds for that 57 02:57.050 --> 02:57.320 outage 58 02:57.320 --> 03:00.040 to be resolved by spanning tree. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 58 02:57.320 --> 03:00.040 to be resolved by spanning tree. 59 03:00.040 --> 03:03.680 Rapids Pervieland spanning tree tries to say, we don't want to wait 30 or 50 60 03:03.680 --> 03:04.240 seconds. 61 03:04.240 --> 03:06.320 We just want to come up immediately. 62 03:06.320 --> 03:08.960 And it does that using new mechanisms. 63 03:08.960 --> 03:15.780 So we might assume that a protocol that's supposed to be faster uses faster 64 03:15.780 --> 03:16.840 timers. 65 03:16.840 --> 03:20.980 And that would be a bad assumption in this case, because rapid pervieland 66 03:20.980 --> 03:21.880 spanning tree 67 03:21.880 --> 03:25.040 uses the same timers. 68 03:25.040 --> 03:28.490 So this is one of these reasons why we don't just want to skip ahead and learn 69 03:28.490 --> 03:29.040 rapid. 70 03:29.040 --> 03:32.770 We need to learn traditional spanning tree because we need to understand what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 03:29.040 --> 03:32.770 We need to learn traditional spanning tree because we need to understand what 71 03:32.770 --> 03:33.560 these timers 72 03:33.560 --> 03:38.920 do because it does the same thing as it does in the rapid world. 73 03:38.920 --> 03:40.880 So let's go ahead and go through these real quick. 74 03:40.880 --> 03:45.540 So when we're talking about the hello timer, we're talking about BPDU 75 03:45.540 --> 03:46.720 propagation. 76 03:46.720 --> 03:50.780 So we recall that the root bridge in traditional spanning tree is responsible 77 03:50.780 --> 03:51.640 for sending a 78 03:51.640 --> 03:56.080 BPDU every hello timer. 79 03:56.080 --> 03:58.520 So by default, that's two seconds. 80 03:58.520 --> 04:03.980 And I'm going to therefore send a BPDU down to the next switch every two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 80 03:58.520 --> 04:03.980 And I'm going to therefore send a BPDU down to the next switch every two 81 04:03.980 --> 04:05.000 seconds. 82 04:05.000 --> 04:09.500 Now the thing to keep in mind is that this switch is going to receive this BPDU 83 04:09.500 --> 04:10.960 and trigger 84 04:10.960 --> 04:13.640 the next BPDU downstream. 85 04:13.640 --> 04:17.880 So in theory, we have a steady stream of BPDUs going down. 86 04:17.880 --> 04:22.360 I generate a BPDU at the top and it flows down and it very quickly results in 87 04:22.360 --> 04:23.120 everybody 88 04:23.120 --> 04:25.520 getting a BPDU update. 89 04:25.520 --> 04:29.760 And so from everybody's perspective, it happens about every hello timer. 90 04:29.760 --> 04:32.630 Just keep in mind that they have to come from the root, meaning if for some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 04:29.760 --> 04:32.630 Just keep in mind that they have to come from the root, meaning if for some 91 04:32.630 --> 04:33.280 reason I don't 92 04:33.280 --> 04:37.880 get this BPDU, I don't actually send one out either. 93 04:37.880 --> 04:40.760 With forwarding delay, we already talked about this. 94 04:40.760 --> 04:44.320 This is going to be when I bring up a new connection. 95 04:44.320 --> 04:48.960 This is a new connection between switches or for that matter, it's a new 96 04:48.960 --> 04:49.960 connection to 97 04:49.960 --> 04:52.520 a laptop or a PC. 98 04:52.520 --> 04:58.650 Either way, we're going to transition from the listening state to the learning 99 04:58.650 --> 04:59.360 state. 100 04:59.360 --> 05:05.360 And then ideally, we land in either the forwarding state or the blocking state. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 100 04:59.360 --> 05:05.360 And then ideally, we land in either the forwarding state or the blocking state. 101 05:05.360 --> 05:11.730 Depends on whether we're a designated port or a root port or possibly a non- 102 05:11.730 --> 05:12.880 designated 103 05:12.880 --> 05:18.560 port or a role is going to determine which state we end up in after all of this 104 05:18.560 --> 05:18.880 . 105 05:18.880 --> 05:20.600 But we start with the listening state. 106 05:20.600 --> 05:25.400 And as we already said, with the listening state, I'm not doing anything to 107 05:25.400 --> 05:26.200 insert anything 108 05:26.200 --> 05:28.240 I learn in the cam table. 109 05:28.240 --> 05:32.660 With learning state, I absolutely am inserting addresses into the cam table, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 05:28.240 --> 05:32.660 With learning state, I absolutely am inserting addresses into the cam table, 110 05:32.660 --> 05:33.600 which prevents 111 05:33.600 --> 05:35.120 a little bit of flooding. 112 05:35.120 --> 05:38.460 I suppose when I first come online, I will have learned some amount of MAC 113 05:38.460 --> 05:39.360 addresses thanks 114 05:39.360 --> 05:44.600 to the broadcasts and flooding that might be coming down the link. 115 05:44.600 --> 05:49.220 Now in this situation, both switches are going to go through the listening and 116 05:49.220 --> 05:50.040 learning. 117 05:50.040 --> 05:52.750 And so there's not going to be any traffic really flowing there, so there's not 118 05:52.750 --> 05:53.040 going 119 05:53.040 --> 05:55.160 to be a whole lot of learning happening. 120 05:55.160 --> 05:58.210 Another way, as we've said, this is going to require two times the forwarding 121 05:58.210 --> 05:58.840 delay, which 122 05:58.840 --> 06:01.640 by default would be 30 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 122 05:58.840 --> 06:01.640 by default would be 30 seconds. 123 06:01.640 --> 06:03.840 So now let's talk about MAC's age. 124 06:03.840 --> 06:08.050 This is probably going to be the most interesting part of the conversation 125 06:08.050 --> 06:09.160 because MAC's age 126 06:09.160 --> 06:11.880 does some interesting things. 127 06:11.880 --> 06:20.680 And specifically what it defines is how long a BPDU is valid. 128 06:20.680 --> 06:22.240 Just kind of interesting. 129 06:22.240 --> 06:26.520 For what I just said, there is a situation where maybe I didn't get a BPDU. 130 06:26.520 --> 06:28.440 So what do I do in that scenario? 131 06:28.440 --> 06:33.870 Well I already have a BPDU that I received before and I start this at MAC's age WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 131 06:28.440 --> 06:33.870 Well I already have a BPDU that I received before and I start this at MAC's age 132 06:33.870 --> 06:34.640 timer. 133 06:34.640 --> 06:39.560 So I know that this stays fresh if we're going to think of it that way for 20 134 06:39.560 --> 06:40.440 seconds. 135 06:40.440 --> 06:43.680 So if I miss one BPDU and two seconds later I get a new one, not a big deal 136 06:43.680 --> 06:44.440 because this 137 06:44.440 --> 06:49.880 will take down to 18 seconds and I actually missed it so it kicks down to 16 138 06:49.880 --> 06:51.080 seconds and 139 06:51.080 --> 06:52.760 at that point I get one. 140 06:52.760 --> 06:58.310 Well when I get it I refresh this back up to the full 20 seconds or whatever 141 06:58.310 --> 06:59.120 MAC's age 142 06:59.120 --> 07:01.200 timer is configured for. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 142 06:59.120 --> 07:01.200 timer is configured for. 143 07:01.200 --> 07:08.040 So the purpose of this is to detect indirect failures. 144 07:08.040 --> 07:10.880 A direct failure is pretty well detected. 145 07:10.880 --> 07:16.590 If I have a switch and a connection and this link goes down I don't have to 146 07:16.590 --> 07:17.760 wait very long 147 07:17.760 --> 07:23.240 to know that this port can be transitioned immediately into the disabled state. 148 07:23.240 --> 07:26.670 Furthermore I know that there can't be a loop out that connection because again 149 07:26.670 --> 07:27.640 it's a direct 150 07:27.640 --> 07:28.640 failure. 151 07:28.640 --> 07:33.170 The port being down means that I can make some pretty good deductions about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 151 07:28.640 --> 07:33.170 The port being down means that I can make some pretty good deductions about 152 07:33.170 --> 07:33.920 what's going 153 07:33.920 --> 07:34.920 on. 154 07:34.920 --> 07:39.320 An indirect failure on the other hand is much more difficult to detect. 155 07:39.320 --> 07:44.800 And also remember that spanning true was developed back when there were hubs. 156 07:44.800 --> 07:50.860 So maybe there's a hub here and for whatever reason this link goes down between 157 07:50.860 --> 07:51.480 these two 158 07:51.480 --> 07:52.840 switches. 159 07:52.840 --> 07:56.360 Well this link for better or worse stays online. 160 07:56.360 --> 08:00.240 Even though we lost a connection to let's say this being the root bridge we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 160 07:56.360 --> 08:00.240 Even though we lost a connection to let's say this being the root bridge we 161 08:00.240 --> 08:00.840 were sending 162 08:00.840 --> 08:06.700 BPDUs and so from this switch's perspective the port stays online it's in an up 163 08:06.700 --> 08:07.440 state and 164 08:07.440 --> 08:11.120 yet I'm no longer receiving BPDUs. 165 08:11.120 --> 08:13.040 So what's going to happen here? 166 08:13.040 --> 08:17.540 Because maybe I have another path to the root that goes this way but it's in a 167 08:17.540 --> 08:18.160 blocking 168 08:18.160 --> 08:20.160 state. 169 08:20.160 --> 08:25.680 Well what's going to happen is we're going to wait for max age time to go down. 170 08:25.680 --> 08:29.920 So again I'm storing that BPDU that I had received last. 171 08:29.920 --> 08:35.230 I'm going to tick down from 20 seconds to 5 seconds 4, 3, 2, 1, 0 and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 171 08:29.920 --> 08:35.230 I'm going to tick down from 20 seconds to 5 seconds 4, 3, 2, 1, 0 and 172 08:35.230 --> 08:36.320 eventually I'm 173 08:36.320 --> 08:42.280 going to say hang on a second I no longer have a valid BPDU. 174 08:42.280 --> 08:46.700 If I no longer have a valid BPDU I need to start the whole spanning tree 175 08:46.700 --> 08:48.000 protocol process 176 08:48.000 --> 08:49.080 over again. 177 08:49.080 --> 08:52.440 I'm going to assume I am the root. 178 08:52.440 --> 08:58.090 I'm going to place all of my ports into the listening state and I'm going to 179 08:58.090 --> 08:59.000 attempt to 180 08:59.000 --> 09:04.290 send BPDUs out to try to figure out if I am the root or if there's another root WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 180 08:59.000 --> 09:04.290 send BPDUs out to try to figure out if I am the root or if there's another root 181 09:04.290 --> 09:06.000 out there. 182 09:06.000 --> 09:10.800 Now remember how long it takes to go from listening to learning to forwarding. 183 09:10.800 --> 09:15.880 Our focus right now at this point is this port right here. 184 09:15.880 --> 09:22.040 We want to get this port into the forwarding state and therefore we are going 185 09:22.040 --> 09:22.760 to rely on 186 09:22.760 --> 09:24.240 the timers for this. 187 09:24.240 --> 09:29.560 So we had to wait 20 seconds for us just to re-initialize things. 188 09:29.560 --> 09:31.880 Then we had to go through listening and learning. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 188 09:29.560 --> 09:31.880 Then we had to go through listening and learning. 189 09:31.880 --> 09:36.410 So how long did it take to transition this from blocking all the way up to 190 09:36.410 --> 09:37.360 forwarding? 191 09:37.360 --> 09:42.400 Well, it took max age plus 2 times forwarding delay. 192 09:42.400 --> 09:46.360 So this actually takes 50 seconds by default. 193 09:46.360 --> 09:50.760 This is a very long time to wait for the network to come back online. 194 09:50.760 --> 09:56.080 But all of the users that are here connecting in to this switch they have no 195 09:56.080 --> 09:56.960 choice but 196 09:56.960 --> 10:00.590 to wait 50 seconds because we can't just pull this block port out of forwarding WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 196 09:56.960 --> 10:00.590 to wait 50 seconds because we can't just pull this block port out of forwarding 197 10:00.590 --> 10:01.280 immediately 198 10:01.280 --> 10:03.320 with traditional spanning tree. 199 10:03.320 --> 10:07.320 Instead we have to wait for this whole process to resolve itself. 200 10:07.320 --> 10:11.360 So again, if this would have been a direct failure, if this port had just gone 201 10:11.360 --> 10:11.840 down, we 202 10:11.840 --> 10:17.170 could have immediately said hey, I lost my root port, I lost this BPD who is no 203 10:17.170 --> 10:17.760 longer 204 10:17.760 --> 10:22.080 valid, I could skip max age and just go straight to listening and learning. 205 10:22.080 --> 10:30.080 So it still takes 30 seconds to get into a transition into a forwarding state. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 205 10:22.080 --> 10:30.080 So it still takes 30 seconds to get into a transition into a forwarding state. 206 10:30.080 --> 10:36.380 But this is only possible if it's a direct failure, if it's an indirect failure 207 10:36.380 --> 10:36.960 we see 208 10:36.960 --> 10:40.360 that it's going to require the full 50 seconds. 209 10:40.360 --> 10:42.240 So here's the question. 210 10:42.240 --> 10:44.440 That's great, that's an error with hubs. 211 10:44.440 --> 10:48.040 Does this still happen in an era without hubs? 212 10:48.040 --> 10:50.120 If I just have switches. 213 10:50.120 --> 10:53.600 And the answer is yes, this does indeed happen. 214 10:53.600 --> 10:55.720 So let's go ahead and draw this real quick. 215 10:55.720 --> 11:00.320 We've got a triangle of switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 215 10:55.720 --> 11:00.320 We've got a triangle of switches. 216 11:00.320 --> 11:04.240 We'll say that switch one is the root. 217 11:04.240 --> 11:11.000 Switch two is not, but switch three is the one that is blocking down here. 218 11:11.000 --> 11:16.700 So what happens if there's an indirect failure from switch three's perspective? 219 11:16.700 --> 11:19.360 That would be this link going down potentially. 220 11:19.360 --> 11:21.280 So let's say this link goes down. 221 11:21.280 --> 11:23.400 That's a direct failure for switch two. 222 11:23.400 --> 11:28.120 It immediately recognizes that it's BPDU is invalid because that was its root 223 11:28.120 --> 11:28.720 port. 224 11:28.720 --> 11:34.050 And the root port is now down, therefore my path to the root is no longer valid WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 224 11:28.720 --> 11:34.050 And the root port is now down, therefore my path to the root is no longer valid 225 11:34.050 --> 11:34.120 . 226 11:34.120 --> 11:35.120 So that's great. 227 11:35.120 --> 11:38.680 It's going to place this port into the listening state. 228 11:38.680 --> 11:43.040 And it's going to say that I am the root as it's supposed to be. 229 11:43.040 --> 11:47.440 It's going to start its process over and try to figure things out. 230 11:47.440 --> 11:49.480 What is switch three going to do? 231 11:49.480 --> 11:51.680 Switch three has a blocking port here. 232 11:51.680 --> 11:57.640 It had been receiving BPDUs that were the superior BPDUs. 233 11:57.640 --> 12:02.370 And now it's getting inferior BPDUs because switch two is saying that it's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 233 11:57.640 --> 12:02.370 And now it's getting inferior BPDUs because switch two is saying that it's the 234 12:02.370 --> 12:03.080 root even 235 12:03.080 --> 12:06.840 though it doesn't have as good of a priority as switch one. 236 12:06.840 --> 12:12.000 Switch three is going to ignore those BPDUs. 237 12:12.000 --> 12:13.120 It has no choice. 238 12:13.120 --> 12:18.680 The BPDU is valid for 20 seconds or whatever max age is. 239 12:18.680 --> 12:22.610 And so it has to wait 20 seconds before it clears out the BPDU and then it can 240 12:22.610 --> 12:23.360 transition 241 12:23.360 --> 12:26.720 that port through listening and learning. 242 12:26.720 --> 12:31.210 So even in this era of just having switches without having hubs, we can see WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 242 12:26.720 --> 12:31.210 So even in this era of just having switches without having hubs, we can see 243 12:31.210 --> 12:31.880 that this 244 12:31.880 --> 12:36.960 is still going to require a total of 50 seconds in order for switch two to come 245 12:36.960 --> 12:38.120 back online. 246 12:38.120 --> 12:41.050 Because switch two doesn't have a path to switch one and it's path to switch 247 12:41.050 --> 12:41.560 three is 248 12:41.560 --> 12:42.560 blocked. 249 12:42.560 --> 12:45.040 Therefore, it's going to be isolated for quite a while. 250 12:45.040 --> 12:49.840 So this is why reliance on timers isn't ideal because we'd really rather have 251 12:49.840 --> 12:50.600 different 252 12:50.600 --> 12:55.040 mechanisms and we'll see those mechanisms with rapid that speeds this process 253 12:55.040 --> 12:55.440 up. 254 12:55.440 --> 12:59.990 But even rapid is going to fall back on these timers if those mechanisms fail 255 12:59.990 --> 13:01.600 for any reason. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 255 12:59.990 --> 13:01.600 for any reason. 256 13:01.600 --> 13:05.590 And these timers, even though they're slow, they do give us the best chance of 257 13:05.590 --> 13:06.120 forming 258 13:06.120 --> 13:10.360 a loop free topology because the worst case scenario in all of this is that we 259 13:10.360 --> 13:11.240 rush through 260 13:11.240 --> 13:15.370 the process of recovery and we end up creating loops in the network that 261 13:15.370 --> 13:17.040 creates further disaster.