WEBVTT 1 00:00.000 --> 00:04.920 Well, next up, Rapid does make another change that we need to be aware of, and 2 00:04.920 --> 00:05.200 this has 3 00:05.200 --> 00:07.840 to do with our topology change notifications. 4 00:07.840 --> 00:10.520 Let's recall how this worked in 802.1d. 5 00:10.520 --> 00:16.480 We have our tree that forms, and there's a change on the network. 6 00:16.480 --> 00:20.300 And so whatever this change is doesn't matter here, we're going to send a 7 00:20.300 --> 00:21.280 notification up 8 00:21.280 --> 00:22.680 to the root. 9 00:22.680 --> 00:28.270 And the root is then going to turn around and send down to the entire network 10 00:28.270 --> 00:28.440 that there 11 00:28.440 --> 00:31.000 has been a topology change. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:28.440 --> 00:31.000 has been a topology change. 12 00:31.000 --> 00:35.810 And the idea here is that we're trying to prevent the black hole of our MAC 13 00:35.810 --> 00:36.900 addresses. 14 00:36.900 --> 00:45.290 So if, for example, let's say we had a path this way to a host, host A, and 15 00:45.290 --> 00:46.500 this link 16 00:46.500 --> 00:51.520 has been blocked here, and this link just went down. 17 00:51.520 --> 00:56.520 So this link can get restored, let's say after the 50 seconds have passed, now 18 00:56.520 --> 00:57.200 we're in a 19 00:57.200 --> 01:00.160 forwarding state, but where does host A live? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:57.200 --> 01:00.160 forwarding state, but where does host A live? 20 01:00.160 --> 01:03.360 Well, host A lives this direction now. 21 01:03.360 --> 01:04.680 It doesn't live this direction. 22 01:04.680 --> 01:10.130 And so if a packet arrives at the root switch destined for MAC address A, the 23 01:10.130 --> 01:11.240 root switch, 24 01:11.240 --> 01:15.020 even though convergence has happened here and we're back online, the root 25 01:15.020 --> 01:15.760 switch is going 26 01:15.760 --> 01:21.700 to look at its MAC address table and think that it has to send that packet this 27 01:21.700 --> 01:22.040 way. 28 01:22.040 --> 01:24.200 And that's just going to be a dead end. 29 01:24.200 --> 01:26.680 And so it effectively black holes the traffic. 30 01:26.680 --> 01:30.190 And so the purpose of this process is for us to recognize that whether it's 30 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:26.680 --> 01:30.190 And so the purpose of this process is for us to recognize that whether it's 30 31 01:30.190 --> 01:30.680 seconds 32 01:30.680 --> 01:34.930 or 50 seconds for us to get back online, either way, what we want to do is we 33 01:34.930 --> 01:35.920 want to set that 34 01:35.920 --> 01:43.000 MAC aging timer so that everything times out before this timer occurs. 35 01:43.000 --> 01:44.880 So worst case scenario is 30 seconds. 36 01:44.880 --> 01:49.190 If this link hard goes down, this is going to only take 30 seconds to come 37 01:49.190 --> 01:49.920 online. 38 01:49.920 --> 01:55.160 And so we set our MAC address aging to 15 seconds. 39 01:55.160 --> 01:59.240 So this is our traditional 802.1d. 40 01:59.240 --> 02:03.790 And so by the time MAC address A is back online, this root switch's MAC address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 40 01:59.240 --> 02:03.790 And so by the time MAC address A is back online, this root switch's MAC address 41 02:03.790 --> 02:04.880 entry has already 42 02:04.880 --> 02:06.160 timed out. 43 02:06.160 --> 02:09.590 And therefore when that first packet arrives destined for MAC address A, it 44 02:09.590 --> 02:10.280 will get sent 45 02:10.280 --> 02:12.380 the right direction. 46 02:12.380 --> 02:18.340 That's all well and good except rapid spanning tree now presents a problem for 47 02:18.340 --> 02:18.880 us. 48 02:18.880 --> 02:26.320 And that problem is that our recovery is no longer 30 to 50 seconds. 49 02:26.320 --> 02:31.960 Instead, it can be as quick as maybe a few hundred milliseconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 49 02:26.320 --> 02:31.960 Instead, it can be as quick as maybe a few hundred milliseconds. 50 02:31.960 --> 02:37.680 This is roughly zero seconds to recovery because in this situation that would 51 02:37.680 --> 02:38.560 be an alternate 52 02:38.560 --> 02:39.560 port. 53 02:39.560 --> 02:42.320 And as we said, alternate ports have fast failover. 54 02:42.320 --> 02:47.480 So as soon as this link goes down, the alternate port is brought online. 55 02:47.480 --> 02:53.170 So now even waiting 15 seconds for our MAC addresses to converge is way too 56 02:53.170 --> 02:53.880 long. 57 02:53.880 --> 02:56.920 But we have another problem as well. 58 02:56.920 --> 02:59.720 We're trying to be as fast as possible with rapid. 59 02:59.720 --> 03:05.310 And the idea that we have to send our topology changes to the root to propagate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 02:59.720 --> 03:05.310 And the idea that we have to send our topology changes to the root to propagate 60 03:05.310 --> 03:06.240 to the rest 61 03:06.240 --> 03:10.000 of the network, this is perceived as being slow. 62 03:10.000 --> 03:19.500 So we have another problem in that we need our BPDUs for the TCNs to propagate 63 03:19.500 --> 03:20.960 faster. 64 03:20.960 --> 03:24.670 And so these are the two problems that we have to resolve with rapid spanning 65 03:24.670 --> 03:25.240 tree. 66 03:25.240 --> 03:29.400 So what we're going to find is that we have two solutions for this. 67 03:29.400 --> 03:32.440 So let's address the big one, the MAC address problem first. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 67 03:29.400 --> 03:32.440 So let's address the big one, the MAC address problem first. 68 03:32.440 --> 03:39.500 So MAC timers still must be addressed or must be adjusted in rapid spanning 69 03:39.500 --> 03:40.360 tree. 70 03:40.360 --> 03:48.870 However, the way this works is that we're going to immediately flush the MAC 71 03:48.870 --> 03:50.160 tables. 72 03:50.160 --> 03:53.960 This means that all existing entries are immediately flushed out. 73 03:53.960 --> 03:56.400 We're not going to age them out after 15 seconds. 74 03:56.400 --> 04:00.680 So even valid MAC addresses will be impacted by this change. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 74 03:56.400 --> 04:00.680 So even valid MAC addresses will be impacted by this change. 75 04:00.680 --> 04:06.520 It makes it actually more disruptive when that ends up happening. 76 04:06.520 --> 04:10.840 Furthermore, it's going to last for two hello timers. 77 04:10.840 --> 04:14.960 Now this is much less than the amount of time it lasted with traditional 78 04:14.960 --> 04:15.880 spanning tree, 79 04:15.880 --> 04:18.760 which lasted for the combination of forward and MAC's age. 80 04:18.760 --> 04:22.680 So 35 seconds is how long it lasted with 802.1d. 81 04:22.680 --> 04:28.480 Instead, by default, this is going to last four seconds. 82 04:28.480 --> 04:31.040 And so fortunately, it doesn't last that long. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 82 04:28.480 --> 04:31.040 And so fortunately, it doesn't last that long. 83 04:31.040 --> 04:36.250 However, because MAC address tables are flushed and they continue to be flushed 84 04:36.250 --> 04:36.640 during this 85 04:36.640 --> 04:43.240 time, it's going to create a whole lot of flooded traffic. 86 04:43.240 --> 04:48.000 And so we want to reduce this as much as possible and therefore configuring 87 04:48.000 --> 04:48.960 edge ports is even 88 04:48.960 --> 04:51.600 more important with rapid spanning tree. 89 04:51.600 --> 04:55.880 Now the other problem we said was that TCNs should go faster. 90 04:55.880 --> 04:59.600 We don't want to have to send to the root for that. 91 04:59.600 --> 05:07.360 So our TCN BPDUs are instead not going to be sent all the way up to the root, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 04:59.600 --> 05:07.360 So our TCN BPDUs are instead not going to be sent all the way up to the root, 92 05:07.360 --> 05:07.520 but they're 93 05:07.520 --> 05:18.040 going to be directly sent from the switch from the topology change switch. 94 05:18.040 --> 05:22.240 Furthermore, the definition of what it means for there to be a change is going 95 05:22.240 --> 05:22.840 to change 96 05:22.840 --> 05:24.160 as well. 97 05:24.160 --> 05:29.480 For example, we no longer care if a port transitions from forwarding. 98 05:29.480 --> 05:33.090 Instead, there's only going to be one situation where we recognize that changes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 05:29.480 --> 05:33.090 Instead, there's only going to be one situation where we recognize that changes 99 05:33.090 --> 05:33.720 might black 100 05:33.720 --> 05:35.080 whole traffic. 101 05:35.080 --> 05:45.120 And that is if a port transitions to forwarding. 102 05:45.120 --> 05:49.380 This is the only time we're going to send topology changes out and we're going 103 05:49.380 --> 05:49.880 to send 104 05:49.880 --> 05:53.120 it again from the originating switch. 105 05:53.120 --> 05:57.000 So before we had to wait for this slow process to get up here. 106 05:57.000 --> 06:01.750 And so this switch right here in the middle would actually ignore the fact that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 106 05:57.000 --> 06:01.750 And so this switch right here in the middle would actually ignore the fact that 107 06:01.750 --> 06:02.440 TCN BPDU 108 06:02.440 --> 06:07.760 was sent out until the configuration BPDU came down with the flag set from the 109 06:07.760 --> 06:09.320 root switch. 110 06:09.320 --> 06:16.000 Now as soon as the topology change gets sent out from this switch, this switch 111 06:16.000 --> 06:16.760 here doesn't 112 06:16.760 --> 06:17.760 have to wait for the root. 113 06:17.760 --> 06:21.520 It just immediately starts performing these actions. 114 06:21.520 --> 06:25.880 So topology changes are a big deal in all spanning tree environments. 115 06:25.880 --> 06:30.320 But with rapid, it's even more important that we reduce TCNs where possible. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 115 06:25.880 --> 06:30.320 But with rapid, it's even more important that we reduce TCNs where possible. 116 06:30.320 --> 06:34.770 So configure our edge ports everywhere and be aware of how exactly topology 117 06:34.770 --> 06:35.640 changes affect 118 06:35.640 --> 06:39.000 our environment and look for opportunities to clean that up where we can.