WEBVTT 0:00:02.940000 --> 0:00:08.420000 Hello and welcome to this video titled the RSTP sync process. 0:00:08.420000 --> 0:00:11.680000 The topic I'm going to cover here is we're going to talk about what exactly 0:00:11.680000 --> 0:00:14.160000 is the sync process. 0:00:14.160000 --> 0:00:20.160000 How does it use some special flags within the rapid spanning tree BPDU? 0:00:20.160000 --> 0:00:24.540000 And when a new root bridge is added to an existing topology, how does 0:00:24.540000 --> 0:00:29.460000 the sync process make that convergence happen very, very quickly? 0:00:29.460000 --> 0:00:36.320000 Okay, so if you've been watching any of my rapid spanning tree videos 0:00:36.320000 --> 0:00:39.920000 or videos from other instructors or read some books, one of the first 0:00:39.920000 --> 0:00:44.960000 questions you might have is why do they call it rapid spanning tree protocol? 0:00:44.960000 --> 0:00:47.040000 What about this is rapid? 0:00:47.040000 --> 0:00:50.540000 Well, in order to understand this, you sort of have to go back in time 0:00:50.540000 --> 0:00:55.560000 to the original spanning tree protocol, the 802.1D specification that 0:00:55.560000 --> 0:00:58.520000 was first formalized in 1998. 0:00:58.520000 --> 0:01:02.780000 Recall that the IEEE first came out with their specification of 802.1D 0:01:02.780000 --> 0:01:07.000000 in 1998. That existed for many, many years. 0:01:07.000000 --> 0:01:13.960000 And between 1998 and 2004, so in that six year period, there was another 0:01:13.960000 --> 0:01:17.460000 version of spanning tree called rapid spanning tree, which originally 0:01:17.460000 --> 0:01:21.600000 was an amendment called 802.1W that came out. 0:01:21.600000 --> 0:01:28.780000 Then 802.1W was rolled into 802.1D when they versioned it again in 2004. 0:01:28.780000 --> 0:01:33.820000 So right now, if you pull up the IEEE 802.1D specification from 2004 or 0:01:33.820000 --> 0:01:37.380000 more recent, rapid spanning tree is rolled into it. 0:01:37.380000 --> 0:01:39.960000 But it wasn't always rapid. 0:01:39.960000 --> 0:01:43.600000 In the original spanning tree specification, it was actually very, very 0:01:43.600000 --> 0:01:47.200000 slow, especially when changes to the topology happened. 0:01:47.200000 --> 0:01:50.940000 It had timers that were involved that could potentially mean that if a 0:01:50.940000 --> 0:01:54.080000 change in the topology happened, you could potentially have networked 0:01:54.080000 --> 0:01:59.420000 downside of 50 seconds, almost a minute of networked downtime on a per 0:01:59.420000 --> 0:02:03.320000 -link basis. Once a link transitioned over, then you might have another 0:02:03.320000 --> 0:02:07.200000 50 seconds of networked downtime on another link. 0:02:07.200000 --> 0:02:11.120000 So changes to your spanning tree topology could be very intrusive to your 0:02:11.120000 --> 0:02:15.320000 end hosts and users that were connected to that switch topology. 0:02:15.320000 --> 0:02:18.680000 So the reason why they call this rapid spanning tree is because they made 0:02:18.680000 --> 0:02:22.480000 some significant changes, which is what this video is going to talk about, 0:02:22.480000 --> 0:02:26.180000 to make all that happen much more rapidly. 0:02:26.180000 --> 0:02:30.920000 So the goal of rapid spanning tree is to synchronize a new port or even 0:02:30.920000 --> 0:02:34.580000 a new switch with the rest of the topology as quickly as possible. 0:02:34.580000 --> 0:02:39.060000 And the way they did that, they made it more rapid was by going into the 0:02:39.060000 --> 0:02:45.580000 BPDU. So if you take a look at the original 802.1D BPDU structure, it 0:02:45.580000 --> 0:02:50.100000 looks almost identical to the rapid spanning tree BPDU structure with 0:02:50.100000 --> 0:02:52.460000 one small little tweak. 0:02:52.460000 --> 0:02:58.780000 In the original 802.1 BPDU, if I was to draw that out here, so this was 0:02:58.780000 --> 0:03:01.780000 your original bridge protocol data unit. 0:03:01.780000 --> 0:03:05.380000 There are all sorts of flags in here like who's the root, what's the cost 0:03:05.380000 --> 0:03:08.740000 to the root, let me give you my sending bridge ID since I'm following 0:03:08.740000 --> 0:03:10.200000 this BPDU to you. 0:03:10.200000 --> 0:03:15.960000 And there was a field in here, which was called the flags field, the flags 0:03:15.960000 --> 0:03:19.000000 field. And if we expand that out and I'm going to show you a sniffer trace 0:03:19.000000 --> 0:03:24.500000 of what that looks like in just a second, it was eight bits, eight bits 0:03:24.500000 --> 0:03:29.820000 of flags. But in the original 802.1D specification, only the bits on the 0:03:29.820000 --> 0:03:33.880000 ends actually had any significance or had any meaning. 0:03:33.880000 --> 0:03:37.700000 The bits in the middle were just reserved for future use. 0:03:37.700000 --> 0:03:41.720000 So that was six bits that were in there that weren't used really for anything. 0:03:41.720000 --> 0:03:45.240000 Well, in rapid spanning tree, they decided, hey, let's actually give some 0:03:45.240000 --> 0:03:48.400000 definition and meaning to those bits in the middle. 0:03:48.400000 --> 0:03:54.180000 And two of those bits have a very special meaning and purpose, which is 0:03:54.180000 --> 0:03:58.740000 what we call the proposal and agreement bits. 0:03:58.740000 --> 0:04:03.560000 This, the usage of these bits is what allows rapid spanning tree to converge 0:04:03.560000 --> 0:04:08.280000 so much more quickly than its older counterpart. 0:04:08.280000 --> 0:04:09.960000 So here we can see those bits. 0:04:09.960000 --> 0:04:12.820000 Now in this particular sniffer trace, those bits are not turned on, they're 0:04:12.820000 --> 0:04:16.560000 set to zeros. But by using those bits, and we'll see how they're used 0:04:16.560000 --> 0:04:21.040000 here in just a moment, this is how we got rapid spanning tree. 0:04:21.040000 --> 0:04:26.480000 So let's go into this and see how exactly are these bits used for anything. 0:04:26.480000 --> 0:04:29.840000 So let's take two switches right here. 0:04:29.840000 --> 0:04:32.700000 Okay, so we're going to connect a link between them. 0:04:32.700000 --> 0:04:39.520000 There we go. Now in original 802.1d, the 1998 version, these guys would 0:04:39.520000 --> 0:04:45.000000 exchange, have a quick exchange of BPDUs and then we have to wait at least 0:04:45.000000 --> 0:04:49.260000 30 seconds, maybe more for the links to finally transition to whatever 0:04:49.260000 --> 0:04:52.960000 they were going to be, not so with rapid spanning tree. 0:04:52.960000 --> 0:04:56.960000 So in rapid spanning tree, as soon as those links come up, both switches 0:04:56.960000 --> 0:04:59.760000 are going to say, hey, I want to be the root. 0:04:59.760000 --> 0:05:01.900000 They don't know each other. 0:05:01.900000 --> 0:05:03.640000 They haven't exchanged any BPDUs yet. 0:05:03.640000 --> 0:05:06.240000 All they know is that, hey, I just have a port that just came up. 0:05:06.240000 --> 0:05:08.380000 I need to run rapid spanning tree on here. 0:05:08.380000 --> 0:05:09.500000 We need a root bridge. 0:05:09.500000 --> 0:05:11.300000 I'll do it. No, I'll do it. 0:05:11.300000 --> 0:05:14.340000 So what's going to happen is both of these switches are going to exchange 0:05:14.340000 --> 0:05:19.600000 BPDUs claiming to be the root, so they're going to put their own bridge 0:05:19.600000 --> 0:05:25.000000 ID in the root bridge field of the BPDU and they're going to set the proposal 0:05:25.000000 --> 0:05:27.840000 flag. They're just going to set that bit to a one saying, this is what 0:05:27.840000 --> 0:05:32.680000 I propose. Now this takes like one second to happen. 0:05:32.680000 --> 0:05:36.040000 You can see here that as soon as this bidirectional exchange of BPDUs 0:05:36.040000 --> 0:05:43.900000 happens, the switch on the right, so this guy right here, he's going to 0:05:43.900000 --> 0:05:45.440000 recognize that he lost. 0:05:45.440000 --> 0:05:49.840000 He's going to say, oh, okay, well, we both do have the same priority, 0:05:49.840000 --> 0:05:53.700000 but my bridge ID is 0, 0, 0, 2, 3. 0:05:53.700000 --> 0:05:56.980000 His bridge ID is 0, 0, 2, 1. 0:05:56.980000 --> 0:05:58.600000 He's actually better than me. 0:05:58.600000 --> 0:05:59.960000 He's got a lower name. 0:05:59.960000 --> 0:06:02.960000 He really is deserving of being the root bridge. 0:06:02.960000 --> 0:06:08.620000 Now if this had been old style 802.1d and this happened, then the bridge 0:06:08.620000 --> 0:06:13.000000 on the left would just go quiet. 0:06:13.000000 --> 0:06:17.680000 And we'd have about 30 seconds here until this interface finally transitioned 0:06:17.680000 --> 0:06:21.420000 into our forwarding root port. 0:06:21.420000 --> 0:06:25.400000 But because we can use proposals and agreements, here's what can happen. 0:06:25.400000 --> 0:06:30.040000 The next stage is that the switch on the right will say, you know what, 0:06:30.040000 --> 0:06:34.060000 I lost. I'm not the root bridge and I'm going to let the other guy know 0:06:34.060000 --> 0:06:35.940000 that I'm humble. 0:06:35.940000 --> 0:06:37.520000 I'm going to let him know, you know what, you're right. 0:06:37.520000 --> 0:06:38.680000 You should be the root bridge. 0:06:38.680000 --> 0:06:40.260000 Why don't you take over? 0:06:40.260000 --> 0:06:43.340000 So the switch on the right will now send a BPDU back. 0:06:43.340000 --> 0:06:48.060000 He'll set the proposal bit to a 0 and raise the agreement bit. 0:06:48.060000 --> 0:06:49.040000 He'll say, you're right. 0:06:49.040000 --> 0:06:49.940000 I agree with you. 0:06:49.940000 --> 0:06:51.240000 You really should be the root bridge. 0:06:51.240000 --> 0:06:52.800000 Why don't you take over? 0:06:52.800000 --> 0:06:55.840000 And with that simple exchange, notice their ports can now transition. 0:06:55.840000 --> 0:06:58.680000 The guy on the left can be the designated port because he is the root 0:06:58.680000 --> 0:07:01.640000 bridge and the guy on the right can be the root port. 0:07:01.640000 --> 0:07:05.740000 And this happens literally within like one or two seconds for this proposal 0:07:05.740000 --> 0:07:08.160000 and agreement to take place. 0:07:08.160000 --> 0:07:11.280000 It is so fast, you can even barely see it. 0:07:11.280000 --> 0:07:14.820000 So instead of waiting 30 seconds for these ports to ultimately be forwarding 0:07:14.820000 --> 0:07:20.800000 on both sides, it only takes about one or two seconds to happen. 0:07:20.800000 --> 0:07:24.380000 So that's when we have, you know, just two switches connecting together 0:07:24.380000 --> 0:07:26.360000 and one of them has to be the root bridge. 0:07:26.360000 --> 0:07:32.220000 Now what if we have a stable topology that already has an existing root 0:07:32.220000 --> 0:07:37.040000 bridge and a new bridge has introduced to that topology who actually is 0:07:37.040000 --> 0:07:40.620000 worthy of taking over that job? 0:07:40.620000 --> 0:07:44.660000 The same process of proposals and agreements can be used to make that 0:07:44.660000 --> 0:07:48.080000 a very seamless, very quick transition. 0:07:48.080000 --> 0:07:50.080000 So that's what we're going to talk about here. 0:07:50.080000 --> 0:07:53.300000 We know that whenever a new bridge enters a topology, he doesn't know 0:07:53.300000 --> 0:07:55.160000 what that topology looks like. 0:07:55.160000 --> 0:07:58.520000 Initially he has no idea if there's an existing root bridge or not. 0:07:58.520000 --> 0:08:02.300000 So every switch that's connected to an existing topology, one of the first 0:08:02.300000 --> 0:08:05.100000 things he's going to do, well it's really a matter of timing here. 0:08:05.100000 --> 0:08:06.120000 It's a matter of timing. 0:08:06.120000 --> 0:08:09.140000 If I'm a switch and I connect to you, let's say that you're already part 0:08:09.140000 --> 0:08:10.700000 of an existing topology. 0:08:10.700000 --> 0:08:12.240000 Now we connect a cable. 0:08:12.240000 --> 0:08:14.120000 One of two things is going to happen. 0:08:14.120000 --> 0:08:15.740000 We can't really predict it. 0:08:15.740000 --> 0:08:20.700000 Either you're going to get a BPDU to me first and you're going to tell 0:08:20.700000 --> 0:08:26.020000 me about the existing root bridge or I'm going to beat you to it. 0:08:26.020000 --> 0:08:29.620000 I'm going to send you a BPDU before you have a chance to send me one. 0:08:29.620000 --> 0:08:32.100000 We don't really know who's going to beat who. 0:08:32.100000 --> 0:08:36.300000 Now, if I connect to you, you're part of an existing topology, I'm a brand 0:08:36.300000 --> 0:08:41.360000 new switch. And if I beat you and I send a BPDU to you, I'm going to have 0:08:41.360000 --> 0:08:42.740000 the proposal bit set in there. 0:08:42.740000 --> 0:08:45.900000 I'm going to say, hey, don't know what you are. 0:08:45.900000 --> 0:08:49.060000 Don't know if you're a host or a route or another switch, but I know you're 0:08:49.060000 --> 0:08:52.040000 something because my ethernet link just came up. 0:08:52.040000 --> 0:08:56.460000 So I'm going to propose that I be the root bridge in this topology. 0:08:56.460000 --> 0:09:03.100000 Now, if the root bridge already exists and he's actually better than me, 0:09:03.100000 --> 0:09:06.800000 you're going to send a proposal back to me saying, Keith, sorry, you're 0:09:06.800000 --> 0:09:08.280000 not worthy of being the root bridge. 0:09:08.280000 --> 0:09:11.020000 Keith, let me tell you who the real root bridge is. 0:09:11.020000 --> 0:09:14.380000 I will send you an agreement and I'll just be added into your topology 0:09:14.380000 --> 0:09:17.180000 as another non-root bridge. 0:09:17.180000 --> 0:09:21.920000 But what if I actually am worthy of taking over from that guy out there 0:09:21.920000 --> 0:09:24.520000 and I really should be the new root bridge? 0:09:24.520000 --> 0:09:28.420000 That's what we're going to see happen right here. 0:09:28.420000 --> 0:09:30.760000 So let's take a look at this topology. 0:09:30.760000 --> 0:09:34.280000 So notice on the left, we've got three switches which are part of an existing 0:09:34.280000 --> 0:09:37.860000 topology. We have a new switch who's about to connect and lo and behold, 0:09:37.860000 --> 0:09:41.600000 that new switch actually is worthy of taking over. 0:09:41.600000 --> 0:09:47.960000 His bridge priority of 4096 is lower than the current root bridge's priority. 0:09:47.960000 --> 0:09:52.840000 So here we go. His link connects. 0:09:52.840000 --> 0:09:57.140000 Now, this is kind of hard to animate and PowerPoint because like it says, 0:09:57.140000 --> 0:09:59.980000 a lot of things are going to happen simultaneously here. 0:09:59.980000 --> 0:10:02.220000 So just try to follow along. 0:10:02.220000 --> 0:10:07.720000 So the moment that connects, there's going to be an exchange of proposals. 0:10:07.720000 --> 0:10:11.420000 Now, switch three. 0:10:11.420000 --> 0:10:15.040000 The moment switch three sees that proposal on the bottom, switch three 0:10:15.040000 --> 0:10:17.820000 is going to say, oh, there really is a new sheriff in town. 0:10:17.820000 --> 0:10:19.440000 We really do have a new root bridge. 0:10:19.440000 --> 0:10:25.400000 At that point, switch three is going to do several things all at once. 0:10:25.400000 --> 0:10:28.440000 Now it's going to look in the slides here like it's sequential one after 0:10:28.440000 --> 0:10:29.760000 the other, but it's not. 0:10:29.760000 --> 0:10:31.560000 It's all happening simultaneously. 0:10:31.560000 --> 0:10:32.900000 So just imagine this. 0:10:32.900000 --> 0:10:37.320000 He sends an agreement back with that one to exchange of proposals and 0:10:37.320000 --> 0:10:43.560000 agreements that link between switch three and the new root bridge can 0:10:43.560000 --> 0:10:44.740000 be what it's supposed to be. 0:10:44.740000 --> 0:10:47.520000 Switch three can now move his root port over. 0:10:47.520000 --> 0:10:51.400000 So now that link is forwarding at exactly the same time that happened. 0:10:51.400000 --> 0:10:53.380000 Notice what he did on his link to the left. 0:10:53.380000 --> 0:10:59.460000 He blocked it. At the same time that happens, he sends his own proposal 0:10:59.460000 --> 0:11:01.400000 out to the left. 0:11:01.400000 --> 0:11:08.280000 Switch two gets that like half of a second later, he sends an agreement. 0:11:08.280000 --> 0:11:11.000000 And now that link can switch over. 0:11:11.000000 --> 0:11:15.060000 Switch three can become the designated port. 0:11:15.060000 --> 0:11:17.780000 And now the whole process happens again. 0:11:17.780000 --> 0:11:23.440000 Switch two blocks his downstream interfaces, sends his own proposal out. 0:11:23.440000 --> 0:11:29.620000 Once the agreement comes back, now that link going upwards in the diagonal, 0:11:29.620000 --> 0:11:31.200000 that can switch over. 0:11:31.200000 --> 0:11:39.540000 And we end up with our steady state topology. 0:11:39.540000 --> 0:11:44.560000 So in this situation, once a new root bridge enters the scene, instead 0:11:44.560000 --> 0:11:49.620000 of the old way where you might have links that were down for 30 seconds 0:11:49.620000 --> 0:11:53.680000 or more while everything took time to converge here, because it's simply 0:11:53.680000 --> 0:11:59.040000 a bam, bam proposal, agreement exchange, it happens within seconds where 0:11:59.040000 --> 0:12:07.080000 the new root bridge can be learned. 0:12:07.080000 --> 0:12:11.240000 All right, one other thing that's built into rapid spanning tree, it's 0:12:11.240000 --> 0:12:15.260000 not part of the proposal and agreement sequence, but this is also something 0:12:15.260000 --> 0:12:20.140000 that's built into the protocol that allows it to converge faster is when 0:12:20.140000 --> 0:12:24.960000 you have an existing root port that fails. 0:12:24.960000 --> 0:12:36.380000 So for example, let's take old style spanning tree, the 1998 version where 0:12:36.380000 --> 0:12:40.480000 you have a new add port zero slash one here, zero slash two here, and 0:12:40.480000 --> 0:12:43.960000 so on the switch, let's just say this is, let's just keep them the same, 0:12:43.960000 --> 0:12:45.360000 zero one zero two. 0:12:45.360000 --> 0:12:52.500000 So in the old style, we would have had forwarding designated, forwarding 0:12:52.500000 --> 0:12:57.640000 designated, forwarding root port blocking. 0:12:57.640000 --> 0:13:01.660000 So that would be the same for both rapid spanning tree and it's precursor. 0:13:01.660000 --> 0:13:03.560000 But here's where things would be different. 0:13:03.560000 --> 0:13:08.120000 In old style spanning tree, if this port here on the left physically went 0:13:08.120000 --> 0:13:11.160000 down, somebody yanked out the cable or there was some electrical malfunction 0:13:11.160000 --> 0:13:13.760000 or something, what would have happened? 0:13:13.760000 --> 0:13:18.720000 Well, in that situation, zero slash two on the bottom would have left 0:13:18.720000 --> 0:13:22.200000 the blocking state and gone into something called a listening state. 0:13:22.200000 --> 0:13:27.100000 He would have stayed there for 15 seconds. 0:13:27.100000 --> 0:13:32.160000 He would have gone into a learning state, stayed there for another 15 0:13:32.160000 --> 0:13:35.740000 seconds. And then finally, he could transition to becoming a new root 0:13:35.740000 --> 0:13:40.820000 port. So that's 30 seconds while he was in listening and learning, he 0:13:40.820000 --> 0:13:42.740000 could not process traffic. 0:13:42.740000 --> 0:13:47.320000 So when he hosts that were connected to the switch downstream, they were 0:13:47.320000 --> 0:13:51.280000 stuck. As long as zero slash two was in listening or learning, it would 0:13:51.280000 --> 0:13:53.820000 not transmit or receive any user data. 0:13:53.820000 --> 0:13:58.200000 So that's 30 seconds that they would be out in the cold, not able to send 0:13:58.200000 --> 0:13:59.940000 or transmit anything. 0:13:59.940000 --> 0:14:04.640000 Well, with rapid spanning tree, that's not the case. 0:14:04.640000 --> 0:14:16.620000 So in rapid spanning tree, get rid of some of the stuff here. 0:14:16.620000 --> 0:14:23.000000 In rapid spanning tree, if our root port physically goes down and if we 0:14:23.000000 --> 0:14:25.120000 have a blocking port, guess what? 0:14:25.120000 --> 0:14:27.200000 We don't have to go through that listening and learning. 0:14:27.200000 --> 0:14:31.700000 We can instantly move this into becoming a new root port. 0:14:31.700000 --> 0:14:37.920000 We can recover and get a new root port right away in like a second. 0:14:37.920000 --> 0:14:42.440000 So that's another built in feature of rapid spanning tree. 0:14:42.440000 --> 0:14:45.760000 Another reason why we call it rapid. 0:14:45.760000 --> 0:14:48.320000 And that's what this is talking about. 0:14:48.320000 --> 0:14:53.280000 Cisco has a proprietary feature called uplink fast, which did the same 0:14:53.280000 --> 0:14:59.760000 thing. So if you're on a Cisco switch, let's just take a look here. 0:14:59.760000 --> 0:15:11.020000 If you're on a Cisco switch, spanning dash tree mode, PVST, okay. 0:15:11.020000 --> 0:15:15.860000 So if you're on a Cisco switch and you do show spanning dash tree summary 0:15:15.860000 --> 0:15:24.140000 and you see that says switch is in PVST mode, you could get that same 0:15:24.140000 --> 0:15:28.440000 behavior. You could get that same benefit of, hey, if I have a root port, 0:15:28.440000 --> 0:15:34.240000 I'm going to get that and if I have a blocking port, if my root port fails, 0:15:34.240000 --> 0:15:37.660000 I want my blocking port to instantly be recovered and become a new root 0:15:37.660000 --> 0:15:41.980000 port. You can get that by typing in this command right here. 0:15:41.980000 --> 0:15:50.860000 Spanning dash tree, hold on a second. 0:15:50.860000 --> 0:15:57.220000 You could say spanning dash tree uplink fast and then hit enter. 0:15:57.220000 --> 0:16:01.060000 So that was a Cisco proprietary feature, which did the same thing. 0:16:01.060000 --> 0:16:04.860000 Now with rapid spanning tree, you don't have to do that. 0:16:04.860000 --> 0:16:08.560000 So if your switch is already in rapid spanning tree mode, spanning dash 0:16:08.560000 --> 0:16:13.720000 tree mode, rapid PVST, now there's nothing special you have to get for 0:16:13.720000 --> 0:16:18.200000 that behavior. That behavior is built into rapid spanning tree. 0:16:18.200000 --> 0:16:21.960000 No configuration commands required. 0:16:21.960000 --> 0:16:26.920000 So that completes this video on the sync process and some of the things 0:16:26.920000 --> 0:16:30.520000 that make rapid spanning tree so rapid, thank you for watching.