WEBVTT 00:00:00.000 --> 00:00:06.360 So now we're going to take a look at Spanning Tree Protocol convergence, 00:00:06.360 --> 00:00:10.920 configuration, as well as manipulation to get ourselves ready for the certification exam. 00:00:10.920 --> 00:00:18.719 So these are the four different states that we find with Purveyland Spanning Tree Plus. 00:00:18.719 --> 00:00:23.840 Rapid Purveyland Spanning Tree Plus is just slightly different but not a whole lot different 00:00:23.840 --> 00:00:28.440 and we'll explore that when we get to it. But with Purveyland Spanning Tree Plus of 00:00:28.440 --> 00:00:35.480 Cisco's proprietary modified version of 802.1d, remember, we have the blocking state, 00:00:35.480 --> 00:00:41.040 the listening state, the learning state, and the forwarding state. So the blocking state you've 00:00:41.040 --> 00:00:46.480 seen it is when our ports are blocked. The forwarding state you've seen it's when our 00:00:46.480 --> 00:00:51.439 ports are root port or designated ports. So in the blocking state we're not going to allow any 00:00:51.439 --> 00:00:58.240 traffic to flow through it. We are blocking that user traffic so that way there we can ultimately 00:00:58.240 --> 00:01:02.279 prevent our loops when it's all said and done. So this is a stable state. This is a good state 00:01:02.279 --> 00:01:08.680 to be in. There's nothing wrong with being in the blocking state. Forwarding is when we learn MAC 00:01:08.680 --> 00:01:14.519 addresses, populate our MAC address table, forward our frames, all of that fun stuff, root ports. 00:01:14.519 --> 00:01:20.239 Again, a stable state is what we're dealing with here. So listening and learning are 00:01:20.239 --> 00:01:25.519 transitionary states. They are transitionary states, meaning that we have a port that is 00:01:25.519 --> 00:01:32.040 transitioning from being, for example, like a block port to a forwarding port. So when you are 00:01:32.040 --> 00:01:38.160 a block port, you will remain a block port until something changes in the topology. So when 00:01:38.160 --> 00:01:43.599 something changes in the topology, you will ultimately receive a BPDU in that environment 00:01:43.599 --> 00:01:47.480 that is different than the one you have been receiving. Why? Because something has changed. 00:01:47.480 --> 00:01:52.839 And when something changes, then BPDUs will change slightly. Why? The information in them 00:01:52.839 --> 00:01:58.599 slightly changes. And as a result of that, that BPDU arrives to you, and you look at it, 00:01:58.599 --> 00:02:05.160 and then you do your calculation. So remember, BPDUs are being sent every two seconds. Our hello 00:02:05.160 --> 00:02:14.199 time is every two seconds. So what we have is we have our BPDUs constantly being sent, 00:02:14.199 --> 00:02:21.000 and if they're always the same, then we're stable. But if something changes at all, and we have a 00:02:21.119 --> 00:02:26.119 change, like in our environment, a link goes down, a link goes up, a device disappears, 00:02:26.119 --> 00:02:30.000 a device comes in, whatever it is, then our switches can generate what is called a topology 00:02:30.000 --> 00:02:36.479 change BPDU. And that topology change BPDU will help us transition from what? From blocking to 00:02:36.479 --> 00:02:43.639 listening to learning to ultimately forwarding when it's all said and done. So if, for example, 00:02:43.800 --> 00:02:52.039 you receive a BPDU in a block port that is different than what you've been receiving, 00:02:52.039 --> 00:02:55.479 then you are going to take that information, and you are going to run with it, 00:02:55.479 --> 00:03:00.199 meaning that you are going to look at it and say, oh, look at that. This is different, 00:03:00.199 --> 00:03:04.679 and it looks like I should no longer be blocking. So you are then going to move to the listening 00:03:04.679 --> 00:03:13.000 state. However, what if you simply stop receiving BPDUs on your interface? If you stop receiving 00:03:13.000 --> 00:03:17.399 BPDUs on your interface, it typically means that the upstream device from you doesn't exist 00:03:17.399 --> 00:03:23.639 anymore. So if you stop receiving BPDUs on your interface, or you don't receive any BPDUs at all, 00:03:24.759 --> 00:03:29.399 then what happens is you've got about 20 seconds. This is what we call our max age timer. 00:03:30.919 --> 00:03:36.440 And that max age timer, every time you receive a BPDU, goes to 20 and starts counting down. 00:03:36.440 --> 00:03:41.000 So if you're receiving BPDUs every two seconds, then essentially your max age timer goes 20, 00:03:41.000 --> 00:03:48.600 19, 18, 20, 19, 18, 20, 19, 18, 20, 19, 18. And then let's say you stop receiving BPDUs. Well, 00:03:48.600 --> 00:03:54.839 then what happens? 17, 16, 15, 14, 13, right? Eventually, it hits zero. At that point in time, 00:03:54.839 --> 00:03:58.759 the max age expires. And what do you do? You've got to transition to the listening phase at that 00:03:58.759 --> 00:04:03.479 point in time. So a couple of different ways from the blocking phase in order to get to the 00:04:03.479 --> 00:04:07.320 listening phase. But regardless of whether it's the max age timer expiring because you stopped 00:04:07.320 --> 00:04:12.520 receiving BPDUs or you received the topology change notification BPDU that ultimately says, 00:04:12.520 --> 00:04:17.880 hey, it's time for you to change. Well, then eventually you end up in the listening phase. 00:04:17.880 --> 00:04:21.880 So when you're in the listening phase, this is a transitionary phase. You never stay in the 00:04:21.880 --> 00:04:26.359 listening phase, right? And when you're in the listening phase, you are listening and processing 00:04:26.359 --> 00:04:31.720 BPDUs. So what does that mean? You're listening, you're waiting for, hey, if I keep receiving BPDUs 00:04:31.720 --> 00:04:35.480 on this port, then what I'm going to do is I'm going to keep seeing if they're the exact same 00:04:35.480 --> 00:04:40.440 over and over and over again. So I received a BPDU that when I was in the blocking phase that 00:04:40.440 --> 00:04:45.799 essentially informed me that I should go to the listening phase based on the calculation I did 00:04:45.799 --> 00:04:49.559 on it. So now that I'm in the listening phase, I want to keep double checking, triple checking, 00:04:49.559 --> 00:04:56.600 quadruple checking, right? And just making sure, is that the right decision? Is that the right 00:04:56.600 --> 00:05:00.920 decision? And so I just keep receiving the BPDUs. So if the BPDUs that keep coming in are the exact 00:05:01.000 --> 00:05:05.480 same over and over and over again, then I know I've made the right decision. If another BPDU 00:05:05.480 --> 00:05:09.480 comes in that changes my mind, well, then we're going to change our mind at that point in time. 00:05:09.480 --> 00:05:17.000 But the idea here is that the topology around us should be the way it needs to be at this point in 00:05:17.000 --> 00:05:21.880 time. And as a result, I'm just double checking, double checking, triple checking, triple checking, 00:05:21.880 --> 00:05:25.480 right? And that's all I'm doing in the listening phase. And we're going to do this for 15 seconds. 00:05:26.040 --> 00:05:31.559 We call this the forward delay time. Make sure you know that. 15 seconds is the forward delay 00:05:31.559 --> 00:05:38.839 time. That's how long we spend in the listening phase, right? That's for a different position. 00:05:38.839 --> 00:05:43.640 No, that is for something else. We're going to talk about PortFast later, right? So PortFast 00:05:43.640 --> 00:05:49.480 would not apply here right now as part of this discussion. So we have our forward delay time. 00:05:50.440 --> 00:05:55.640 And so now my port. So for example, the ports would be these ports here we were talking about 00:05:55.640 --> 00:06:03.559 earlier. So if we go back to like, for example, this page here, right? As this is deciding whether 00:06:03.559 --> 00:06:09.079 it should be designated port, as this is deciding whether it should be root port, whatever that is, 00:06:09.079 --> 00:06:16.440 we are spending 15 seconds hanging out in the listening phase, double checking, double checking, 00:06:16.600 --> 00:06:22.440 triple checking. So, all right, I've decided to be a designated port. Am I going to keep that? 00:06:22.440 --> 00:06:25.799 And then you just keep double check every two seconds when a BPDU comes in. So you do that 00:06:25.799 --> 00:06:30.200 for 15 seconds. And then after 15 seconds is over, then you move to the learning phase. 00:06:31.079 --> 00:06:34.760 So when you're in the learning phase, what does that mean? It means you're doing basically the 00:06:34.760 --> 00:06:38.760 same thing as the listening phase, still receiving those BPDUs and double checking, 00:06:38.760 --> 00:06:42.760 triple checking, quadruple checking. But you're also going to start pre-populating 00:06:42.760 --> 00:06:48.600 your MAC address table. And so you're going to do this for 15 seconds, which is forward delay. 00:06:48.600 --> 00:06:54.119 Again, so you do forward delay twice, one for the listening phase, one for the learning phase. 00:06:54.839 --> 00:07:00.679 And then if no BPDU comes in, that changes your mind. Whatever decision you made, 00:07:00.679 --> 00:07:05.399 if you decided to become a designated port in the listening phase, or you decided to become a 00:07:05.399 --> 00:07:11.399 root port in the listening phase, well, then nothing has changed your mind for 30 seconds. 00:07:11.399 --> 00:07:18.040 Now you're forwarding. So best case scenario takes 30 seconds for you to 00:07:19.000 --> 00:07:26.279 confirm that you should be a designated port or a root port. Worst case scenario, it's 50 seconds. 00:07:27.799 --> 00:07:35.239 Because 50 seconds in total from here to here, or best case scenario, only 30 seconds. So for 00:07:35.239 --> 00:07:42.440 example, if a port comes up for the very first time, it's going to receive a BPDU or not receive 00:07:42.440 --> 00:07:46.920 a BPDU depending on the scenario and situation. But if it's a port that just comes up, then it 00:07:46.920 --> 00:07:52.119 immediately goes to the listening phase. And if it's not receiving BPDUs, it'll go listening, 00:07:52.119 --> 00:07:55.399 learning, then it becomes a designated port if it doesn't receive any BPDUs. 00:07:56.600 --> 00:08:00.279 But if it receives a BPDU right away in the listening phase, then it's going to have to make 00:08:00.279 --> 00:08:04.119 a decision. Based on this, should I be blocking? If I should be blocking, I'm going to block right 00:08:04.119 --> 00:08:08.519 away. I'm not even going to wait. I'm just going to block. But if I decide I should be a root port 00:08:08.519 --> 00:08:15.239 and designated port in the listening phase, then I got to wait. Then I got to wait. Then I got to 00:08:15.239 --> 00:08:21.160 go. So 30 seconds, worst case scenario in that situation. But if you're currently a blocking 00:08:21.160 --> 00:08:27.640 port and you stop receiving BPDUs, then it could take up to 50 seconds to fully go to the forwarding 00:08:27.640 --> 00:08:33.320 state in that particular scenario. So remember that your hello time is two seconds and you can 00:08:33.320 --> 00:08:38.119 tune that. For example, you can go to your global configuration mode and type in the 00:08:38.119 --> 00:08:44.119 spanning tree VLAN10 and set your hello timer. You can set your forward delay timer. You can 00:08:44.119 --> 00:08:49.559 set your max age timer. But always remember, if you start manipulating your timers, 00:08:50.280 --> 00:08:55.960 then that is going to put more pressure on your device to process more and more and more and more 00:08:55.960 --> 00:09:02.440 BPDUs and possibly make decisions prematurely. And as a result of that, you could end up in 00:09:02.440 --> 00:09:08.919 flip-flapping situations until it sorts itself out. So typically, the default timers are the 00:09:08.919 --> 00:09:15.479 best way to go. And if you want to speed yourself up and you don't want to spend all that time, 00:09:15.479 --> 00:09:21.960 then switch protocols, okay? Don't manipulate your timers for these two. That's silly, right? 00:09:21.960 --> 00:09:29.559 Instead, you might as well go with these. And what makes these faster? Is it faster timers? No. 00:09:29.559 --> 00:09:37.000 The same timers are used if and only if they are needed with, I should say, all three of these. 00:09:37.960 --> 00:09:44.599 Why is that? Because the timers are only needed if the device you're talking to 00:09:45.239 --> 00:09:50.119 doesn't speak the same version of spanning tree protocol. So for example, if I have a switch here 00:09:51.080 --> 00:09:57.400 and I have another switch here and we're both running rapid per VLAN spanning tree plus, 00:09:57.400 --> 00:10:03.000 rapid per VLAN spanning tree plus, we don't need timers anymore. We're still going to have the 00:10:03.000 --> 00:10:08.840 timers just in case something goes wrong. But because we're both rapid per VLAN spanning tree 00:10:08.840 --> 00:10:17.000 plus, we have a handshaking mechanism. It's called a proposal and agreement process. 00:10:18.359 --> 00:10:23.960 So essentially, we have the ability to talk to each other whenever changes are happening. 00:10:23.960 --> 00:10:27.960 And so because we have the ability to talk to each other when changes are happening, 00:10:27.960 --> 00:10:34.679 we have the ability to make sure that we can make changes very, very, very fast without causing a 00:10:34.679 --> 00:10:41.080 loop and having to worry about timers to confirm that we've made the right decision. So with these 00:10:41.080 --> 00:10:46.119 two protocols, we're relying on simply timers timing out to determine if we made the right 00:10:46.119 --> 00:10:51.719 decision. Whereas with these ones, we're using the proposal and agreement process to determine if we 00:10:51.719 --> 00:10:57.960 made the right decision. And if for some reason the proposal and agreement process doesn't work 00:10:57.960 --> 00:11:03.880 or it fails, then we'll just use our timers. And so worst case scenario with rapid per VLAN spanning 00:11:03.880 --> 00:11:10.280 tree plus, it is going to be like 30 seconds as an example if an interface comes up. Best case 00:11:10.280 --> 00:11:16.280 scenario, it can be instantaneous, two seconds or less based on the proposal and agreement process. 00:11:16.919 --> 00:11:24.840 Here is two charts just showing us the port rules, port states, and operational effect of 00:11:26.440 --> 00:11:29.880 spanning tree protocol versus rapid spanning tree protocol. So for example, 00:11:29.880 --> 00:11:38.359 it doesn't matter whether this is 802.1D or PV or PVST plus. We're talking about the same thing 00:11:39.239 --> 00:11:51.159 or 802.1W or multiple spanning tree protocol or rapid per VLAN spanning tree plus or 802.1S. 00:11:51.159 --> 00:11:57.080 Okay. So all of those would apply to the chart on the right. 802.1D, PVST plus applies to the chart 00:11:57.080 --> 00:12:01.159 on the right, left. So as you can see here, root port, designated port, forwarding, forwarding, 00:12:01.159 --> 00:12:06.280 they're all the same. That doesn't change at all. That's all the same. The only difference here is 00:12:06.280 --> 00:12:11.880 that we can be more rapid, faster at figuring out the root ports and designated ports based on the 00:12:11.880 --> 00:12:15.799 proposal and agreement process over here, where here we have to rely on those timers timing out 00:12:15.799 --> 00:12:21.719 before we can actually go to the forwarding state. Notice over here in our spanning tree protocol 00:12:21.719 --> 00:12:26.440 ports, we've got non-designated ports that are the blocking ports. So that's like the traditional 00:12:26.440 --> 00:12:31.559 spanning tree protocol, 802.1D, without any additional features added that were invented 00:12:31.559 --> 00:12:35.640 after the fact. It is like if you're blocking, you're blocking, that's it, that's all. And if 00:12:35.640 --> 00:12:39.719 any changes happens, you're going to have to go through the whole process with timers and everything 00:12:39.719 --> 00:12:44.520 else. Eventually, there were some additional features added like backbone fast, uplink fast, 00:12:44.520 --> 00:12:50.280 and stuff like that. So you could speed up the process, speed it up to what, like maybe bypass 00:12:51.559 --> 00:12:55.320 the forward delay timers with something like uplink fast. So you could immediately transition 00:12:55.320 --> 00:13:00.919 a blocking port to a root port. That was something that was added after the fact, backbone fast, 00:13:01.000 --> 00:13:07.239 making just, making the changes faster. So instead of having to wait for the 22nd max 00:13:07.239 --> 00:13:11.239 age timer to expire, you could just immediately change right away. So a lot of those features, 00:13:11.239 --> 00:13:15.719 though, don't matter anymore because they're baked in the rapid spanning tree protocol. 00:13:15.719 --> 00:13:19.239 They're baked in the rapid spanning tree protocol. So instead of just having like 00:13:19.239 --> 00:13:24.280 non-designated ports in the blocking state, we now, as you can see, have two different types 00:13:24.280 --> 00:13:30.200 of ports called alternative and backup. And they're listed as discarding. I mean, it's still blocking 00:13:30.200 --> 00:13:36.679 when it's all said and done. But what I want to point out to you is that we have these ports so 00:13:36.679 --> 00:13:41.239 we can transition faster. So not only do we have the proposal and agreement process, but we have 00:13:41.239 --> 00:13:46.520 the alternative ports and we have the backup ports. So here's an example of an alternative port on a 00:13:46.520 --> 00:13:55.400 switch. An alternative port can become the root port immediately if the root port on that switch 00:13:55.400 --> 00:14:03.400 fails. So basically, your switch has determined, if I go this way and this is discarding, I have a 00:14:03.400 --> 00:14:10.359 loop-free path. If this fails, then this can immediately become the root port. Why? Because 00:14:10.359 --> 00:14:17.880 I know it's an alternative loop-free path as long as this link doesn't exist. So if anything ever 00:14:17.880 --> 00:14:22.520 happens to the communication or connection between these two switches, this immediately 00:14:22.520 --> 00:14:28.039 becomes the root port, like right away, instantaneously, within milliseconds. 00:14:29.559 --> 00:14:36.599 And therefore, traffic is probably not going to be affected when it's all said and done. 00:14:38.200 --> 00:14:44.440 Right? That's just alternative port. The backup port, most of you are probably never going to see. 00:14:45.159 --> 00:14:51.559 The backup port exists because – or the backup port is a port that can become the designated port 00:14:52.440 --> 00:15:01.960 if the designated port fails. The only way that works is if you have two ports connected to the 00:15:01.960 --> 00:15:10.919 same link, connected to the same subnet – sorry, segment, not subnet. You have two ports on that 00:15:11.000 --> 00:15:17.719 You have two ports on that switch connected to the same link, the same segment, the same 00:15:17.719 --> 00:15:24.280 collision domain. So to make sure you understand this fully, you see this designated port here. 00:15:27.559 --> 00:15:37.880 Do we have another port on this same switch that is connected to the exact same link, 00:15:37.880 --> 00:15:41.080 the exact same segment, or the exact same collision domain? 00:15:43.880 --> 00:15:48.520 No, we don't. No, we don't. Right? This is a totally different one. 00:15:52.520 --> 00:15:57.640 So in this case, you would never see a backup port for here or a backup port for here. 00:15:59.159 --> 00:16:06.679 A designated – a backup port happens when you see your own BPDU. That's right. When you see 00:16:06.679 --> 00:16:14.520 your own BPDU. So if I send a BPDU at this port, am I ever going to see that BPDU again? No, 00:16:15.080 --> 00:16:23.000 you are not. Because that BPDU gets gobbled up by this switch. This switch generates its own BPDUs 00:16:23.000 --> 00:16:28.520 and sends them out, gets gobbled up by this switch. This switch generates its own BPDUs, 00:16:28.520 --> 00:16:34.840 sends it out, gets gobbled up by this switch. So no, this switch will not see its own BPDUs. 00:16:35.640 --> 00:16:42.280 So therefore, no backup ports in those scenarios. So I'm going to see a backup port when? When I 00:16:42.280 --> 00:16:49.479 have two ports on the switch in the same segment, link, or collision domain, and I receive my own 00:16:49.479 --> 00:16:57.880 BPDUs on that link, collision domain, or segment. So here's an example of this. This is a hub. 00:16:58.840 --> 00:17:06.199 This is a link. This is a link. Although it's two different physical links, 00:17:07.000 --> 00:17:15.239 what you need to remember is that a hub is a layer one device. Meaning it's a bit spitter. 00:17:15.239 --> 00:17:22.839 Bits come in an interface, bits get spit out all the other interfaces. So when I send a BPDU this 00:17:23.000 --> 00:17:29.160 way, it gets sent, sent, sent, sent, sent, sent, sent, and then sent back up here. Now I just saw 00:17:29.160 --> 00:17:37.079 my own BPDU. You see that? So even though it's two different physical links, we are in the same 00:17:37.079 --> 00:17:44.439 collision domain. We are on the same segment. We are technically one link according to what? 00:17:44.439 --> 00:17:49.479 According to Spanishy protocol in this case. So we do have a loop here. When you think about it, 00:17:49.479 --> 00:17:58.680 when it's all said and done now. Because the hub does not understand BPDUs. So I send my BPDU, 00:17:58.680 --> 00:18:03.000 it arrives back in this side. I send a BPDU at this port, it arrives back in on this side. 00:18:03.959 --> 00:18:12.119 So what happens? Cost is tied. Upstream bridge ID is tied. Therefore the sending port ID is the 00:18:12.119 --> 00:18:18.920 winner. When it goes out this way, it's 128.1. When it goes out this way, it's 128.2. Therefore 00:18:18.920 --> 00:18:25.400 128.1 is lower. Therefore it becomes a designated port and this becomes the block port. In this 00:18:25.400 --> 00:18:31.319 case, discarded backup port because it's a port that could immediately become the designated port 00:18:31.319 --> 00:18:37.079 if this port fails. That's what's happening in that scenario. So you're only going to see 00:18:37.079 --> 00:18:41.079 a backup port in this type of a scenario or let me show you another type of scenario. 00:18:48.920 --> 00:18:59.959 I mean, we all do this, right? There you go. Now, you would see one of these is a designated 00:18:59.959 --> 00:19:03.560 port and the other one's a backup port. I mean, because this does a lot for us. I mean, 00:19:08.359 --> 00:19:11.479 but there you go. If you ever want to see a backup port, if you want to see it, 00:19:11.479 --> 00:19:14.280 just do that on your switch and look, you'll see you'll have a backup port. 00:19:15.160 --> 00:19:20.680 All right. So, be able to pick these terms and items out of a lineup on the certification exam, 00:19:20.680 --> 00:19:25.479 folks. Now, what you're going to see here also is that when we are transitioning, 00:19:25.479 --> 00:19:30.359 we talked about listening and learning. Well, with Rapid Spanning Tree Protocol, 00:19:30.359 --> 00:19:35.640 we don't have listening and learning. We only have learning. So, we have 15 seconds here, 00:19:36.359 --> 00:19:41.239 which is our forward delay timer. We have 15 seconds here, which is our forward delay timer. 00:19:41.239 --> 00:19:47.719 15 seconds here, which is our forward delay timer. But over here, we have 15 seconds times 00:19:47.719 --> 00:19:52.599 two. We go through learning twice. So, we go through learning twice. So, 00:19:52.599 --> 00:19:56.839 that way there, we can be backwards compatible. Backwards compatible. 00:20:04.839 --> 00:20:09.239 So, let's go ahead and show you how to switch over to Rapid Spanning Tree Protocol because right now, 00:20:09.239 --> 00:20:16.040 we are running Per-VLAN Spanning Tree Plus on our device. And how do I know that? Because it 00:20:16.040 --> 00:20:23.319 says IEEE. That means Per-VLAN Spanning Tree Plus. Per-VLAN Spanning Tree Plus. 00:20:25.160 --> 00:20:31.560 So, let's go over right now and type in, configure terminal, Spanning Tree Mode, 00:20:31.560 --> 00:20:34.599 and you'll see that this device supports Per-VLAN Spanning Tree Plus, 00:20:35.560 --> 00:20:40.599 Multiple Spanning Tree Protocol, and Rapid Per-VLAN Spanning Tree Plus. So, 00:20:40.599 --> 00:20:45.719 PVST and Rapid PVST are Cisco proprietary. They don't work with non-Cisco devices. Keep that in 00:20:45.719 --> 00:20:51.560 mind. All right. So, let's switch over to Rapid. Okay. Now that I'm Rapid, type in show span 00:20:56.040 --> 00:20:59.560 Per-VLAN 10. You'll see now it says Rapid Spanning Tree Protocol for us. 00:21:00.520 --> 00:21:06.439 Okay. Let me just refresh this because everything should be good now so far. All right. Still not 00:21:06.439 --> 00:21:11.880 good enough in my opinion. There you go. That's looking perfect now. So, you'll see here that 00:21:11.880 --> 00:21:17.719 because DSW1 is Rapid Spanning Tree Protocol and the rest of my switches are not Rapid Spanning 00:21:17.719 --> 00:21:27.239 Tree Protocol yet, it even tells me that over here. Your peer out these interfaces are running 00:21:27.319 --> 00:21:34.920 Spanning Tree Protocol, Per-VLAN Spanning Tree Plus. So, what does that tell DSW1? It tells DSW1 00:21:34.920 --> 00:21:42.599 that whenever it wants to communicate with any of the switches out of these ports, it cannot use the 00:21:42.599 --> 00:21:48.199 proposal and agreement process. Why? Because they're not running Rapid Spanning Tree Protocol. 00:21:48.199 --> 00:21:53.719 Now, do the other switches know that this is Rapid? No, they don't. Okay. So, only the Rapid 00:21:54.599 --> 00:22:02.280 device knows about the non-Rapid devices. The non-Rapid devices will not know that the Rapid 00:22:02.280 --> 00:22:10.119 devices are actually Rapid. So, we can verify it here. If I go to, for example, like ASW1, 00:22:10.119 --> 00:22:15.239 it doesn't have any information about whether your neighbor is Rapid or non-Rapid. Why? Because it 00:22:15.239 --> 00:22:19.719 doesn't matter, right? Because Per-VLAN Spanning Tree Plus is always going to run as Per-VLAN 00:22:19.719 --> 00:22:24.439 Spanning Tree Plus. It's the Rapid side that has the ability to operate as one or the other. 00:22:25.239 --> 00:22:30.199 So, in this case, even though this is Rapid, everybody else is non-Rapid, there really is 00:22:30.199 --> 00:22:35.079 no benefit because we're still going to be behaving like regular Per-VLAN Spanning Tree Plus. 00:22:35.079 --> 00:22:38.280 So, let's go over to DSW2 as an example now and change that over here. 00:22:41.400 --> 00:22:48.280 So, Spanning Tree Mode Rapid. So, we'll let that cook just for a moment and we'll see that 00:22:50.359 --> 00:22:54.920 we now don't have that information there. So, if you're ever looking at this output 00:22:54.920 --> 00:22:58.839 and you see something like Rapid Spanning Tree Protocol, just by looking at this output, 00:22:58.839 --> 00:23:03.880 you know that whoever's out 17, 18, 19, and 20 is also a Rapid-speaking device, 00:23:05.000 --> 00:23:10.280 whereas 21, 22, 23, 24 is a non-Rapid-speaking device. 00:23:11.239 --> 00:23:15.239 All right. So, let's go ahead and adjust this on all our devices. 00:23:34.439 --> 00:23:35.719 I'm going to change my cost back. 00:23:36.520 --> 00:23:41.319 So, that way, there we have consistent cost. There we go. All right. So, go back to DSW1 00:23:41.319 --> 00:23:46.760 and we'll see that we shouldn't have pure STP anymore. So, we're Rapid for all of our devices 00:23:46.760 --> 00:23:58.680 now. So, now we want to start talking about how we manipulate this. So, we're going to go back to 00:23:58.680 --> 00:24:07.160 DSW1. So, now we want to start talking about how we manipulate Spanning Tree Protocol. 00:24:08.760 --> 00:24:16.920 So, let's look at this environment here. Right now, the environment looks like this. This was 00:24:17.800 --> 00:24:29.000 the diagram that was produced based on this information here. So, all of this information 00:24:29.000 --> 00:24:38.839 here, folks, ultimately, with our default port costs, was able to produce this diagram for us 00:24:38.839 --> 00:24:49.719 here. Now, my equipment that I'm using today does not equal what we see here. So, for example, 00:24:49.719 --> 00:24:56.839 if we go to ASW1 right now and we look at the output of Spanning Tree VLAN10, we'll see here 00:24:57.400 --> 00:25:03.319 that the root port, it's listed here, the root port, as well as down here, 00:25:04.280 --> 00:25:08.920 is gigabit one size zero size 47. So, it's actually this port going this way. 00:25:11.160 --> 00:25:16.280 And if we look and we follow that path, we follow that path. Let me write that in here. 00:25:16.280 --> 00:25:18.920 This is going to be the root port here right now in my diagram. 00:25:21.000 --> 00:25:25.880 And if we follow that path up to DSW2 and we type in show Spanning Tree VLAN, 00:25:26.199 --> 00:25:31.400 we're going to see here that I am the root bridge right now. So, I am actually the root bridge. 00:25:32.920 --> 00:25:39.479 So, the topology that we have right now does not equal what we have seen here. So, let's go ahead 00:25:39.479 --> 00:25:48.280 and show you how you can manipulate Spanning Tree and change the entire architecture, change who the 00:25:48.280 --> 00:25:57.239 block ports are, who the root ports are, who the designated ports are. And we're going to show you 00:25:57.239 --> 00:26:02.280 a couple of different ways that we can do that. But before we do that, let's make sure that we 00:26:02.280 --> 00:26:10.839 have the ability to verify the changes after. So, right now, take a look at this. This is DSW1 00:26:10.839 --> 00:26:19.800 compared to what you see here. That's a big, significant difference. It really is. You look at ASW2. 00:26:25.319 --> 00:26:28.839 We have our root port as 47. This is what we have right now. 00:26:32.599 --> 00:26:38.199 And blocked everything else. And then DSW2 is our root port. 00:26:38.839 --> 00:26:49.560 And then DSW2 is our root bridge. Right? So, what is one way that we can manipulate this entire tree 00:26:50.359 --> 00:26:59.880 in one shot? Change who the root bridge is. That's how we can do that. 00:27:00.680 --> 00:27:07.719 Yeah. So, how do we do that? Well, we can't manipulate the MAC address of the root bridge, 00:27:07.719 --> 00:27:12.920 but we can manipulate the what? We can manipulate the priority that the root bridge is using. 00:27:13.880 --> 00:27:21.959 Right now, everybody's using 32,768 by default in my environment. 00:27:22.920 --> 00:27:27.719 In my environment. And as a result of that, 00:27:29.000 --> 00:27:33.079 DSW2 has elected the root bridge, in my case, in our live environment. 00:27:34.599 --> 00:27:40.839 So, if we start manipulating priorities, we could ultimately manipulate who the root bridge is, 00:27:40.839 --> 00:27:46.119 because we're manipulating what? The bridge ID. So, if we go back to this diagram here, 00:27:46.920 --> 00:27:54.280 recall that we're manipulating these upper four bits. So, we're manipulating the upper four bits. 00:27:54.280 --> 00:28:00.439 It means we're allowed to do what? We're allowed to increment in 4,096. 00:28:04.839 --> 00:28:06.119 As it showed right here. 00:28:06.680 --> 00:28:11.239 Because there's other values for the VLAN. And right now, we're just manipulating VLAN10 as an 00:28:11.239 --> 00:28:28.040 example. So, who do I want to become the root bridge in this case? I want 00:28:28.280 --> 00:28:32.199 DSW1 to become the root bridge in our case. So, right now, DSW2 is, 00:28:33.719 --> 00:28:39.640 but I want DSW1 to be the root bridge. So, how would we do that? Let's type in configure terminal, 00:28:39.640 --> 00:28:43.239 type in spanning tree. And this is something you can do on a VLAN by VLAN basis. 00:28:45.640 --> 00:28:48.359 That's why we have the ability to manipulate our trees 00:28:49.160 --> 00:28:53.319 individually on a VLAN by VLAN basis. And that's why we have the ability to manipulate 00:28:53.319 --> 00:28:58.520 we have the ability to manipulate our trees individually on a VLAN by VLAN basis on Cisco 00:28:58.520 --> 00:29:06.599 devices. So, let's focus on just VLAN10. You'll see here that I have the opportunity to specify 00:29:06.599 --> 00:29:15.239 the priority of this device in increments of 4,096. So, let me put in 5,000 so I can get this 00:29:15.239 --> 00:29:23.000 error. And those are the 16 different possible values. The default value is 32,768. 00:29:23.800 --> 00:29:32.439 And since we're dealing with VLAN10, your values are these plus 10. You just put in these values, 00:29:32.439 --> 00:29:45.560 and it automatically adds 10 to it. So, if we're 32,768 right now for all of our devices, 00:29:46.599 --> 00:29:51.640 what number could we pick folks to force DSW1 to become the root bridge? 00:29:54.280 --> 00:30:01.719 Well, anything lower than 32,768, that's on the list. Absolutely, any one of them. 00:30:02.680 --> 00:30:07.800 So, we could choose any one of these top values here and accomplish our objective. 00:30:08.599 --> 00:30:16.839 Now, let me ask you this. What would be the best value to use in your opinion? 00:30:23.800 --> 00:30:30.520 Zero, right? Because remember, we always said lower is better with spanning tree protocol. 00:30:31.079 --> 00:30:38.680 So, if lower is better, zero would be the best number to pick if you want this device to be the 00:30:38.680 --> 00:30:45.000 root bridge because you can't get any lower than zero. So, that's the recommended best practice is 00:30:45.319 --> 00:30:50.119 best practice is your root bridge for that VLAN, just set it to zero. 00:30:57.880 --> 00:31:00.359 That is the recommended best practice. Now, if you don't follow that, 00:31:00.359 --> 00:31:04.119 that's fine. That is your choice. Whatever works for you, works for you. 00:31:04.280 --> 00:31:14.040 But in this case, I ensure that down the road, if anybody accidentally runs this command on another 00:31:14.040 --> 00:31:23.160 switch, the chances of them becoming the root bridge are far less. Why? Because I am already 00:31:23.160 --> 00:31:29.800 zero. The only way they would be able to become the root bridge if they're also set to zero 00:31:30.040 --> 00:31:33.319 is if they have a lower MAC address. That would be the only way. 00:31:35.079 --> 00:31:42.359 So, I give myself the best chance of being the root bridge by using zero. It doesn't guarantee 00:31:42.359 --> 00:31:46.280 it because if somebody else comes along, they get a priority zero, they have a lower MAC address, 00:31:46.280 --> 00:31:50.599 then they're the root bridge. All right. So, now that this is done, let's take a look at 00:31:51.319 --> 00:31:55.319 show spanning tree VLAN 10. 00:32:00.520 --> 00:32:07.640 And what we're going to see is that now my priority is zero plus 10 for a grand total of 10. 00:32:09.400 --> 00:32:16.599 And everybody else is still at 32,768. So, because of that, 00:32:21.479 --> 00:32:29.400 I am the root bridge. It's also recommended. And so, my topology would look like this. So, 00:32:29.400 --> 00:32:31.719 let's verify the topology before we do anything else. 00:32:33.959 --> 00:32:37.719 Now, is every single port designated like we have up here? Yes, it is. 00:32:39.319 --> 00:32:49.479 Let's go to DSW2 for VLAN 10. Is 17 the root bridge, 18, 19, 20 blocking? Yep. The rest 00:32:49.479 --> 00:32:58.119 designated ports? Yep. All right. Let's go to ASW1. Is gigabit 1.0 size 45 the root port? Yes, 00:32:58.119 --> 00:33:05.800 it is. 46, 47, 48. What? Yes, it is. Look, gig 1 and 2 designated ports. Perfect. 00:33:07.160 --> 00:33:14.280 What about ASW2? Show a span for VLAN 10. We've got 45 root port. Perfect. And the rest are 00:33:14.280 --> 00:33:19.479 blocking. So, as you can see, by manipulating who the root bridge is, you change the entire 00:33:19.479 --> 00:33:27.880 topology. Now, do we ever want these devices to become the root bridge? Do we ever want them to 00:33:27.880 --> 00:33:43.239 become the root bridge? And the answer is no, because if they're the root bridge, 00:33:43.239 --> 00:33:47.800 that could change the path of the flow of traffic. So, for example, let's say this is 00:33:47.800 --> 00:33:54.439 the root bridge. If this is the root bridge, and right now this is the default gateway, 00:33:55.319 --> 00:34:04.599 it is possible, right? It is possible that your traffic flow could do this. I am not joking about 00:34:04.599 --> 00:34:10.199 that. And you would not want that at all, right? It is possible that could happen. 00:34:11.159 --> 00:34:19.959 So, the moral of the story is this. Always, always have your root bridge as close to your 00:34:19.959 --> 00:34:23.959 distribution layer switches as possible, meaning on those distribution layer switches, 00:34:26.120 --> 00:34:30.679 at the entry and exit point to the layer 2 environment. That is the best practice, 00:34:30.679 --> 00:34:38.199 so you typically get the best results. But you could still mess up. For example, even if this 00:34:38.199 --> 00:34:43.000 is the root bridge, is it possible that traffic could end up doing this if I'm not careful? 00:34:43.000 --> 00:34:49.800 Absolutely. Absolutely. So, you got to be mindful of your environment and know how to 00:34:50.760 --> 00:34:56.199 look at the results of Spanning Sheet Protocol and determine, is this the right traffic flow we want 00:34:56.199 --> 00:35:00.840 under normal operating conditions? The answer is yes, then you're good. If not, then you want to 00:35:00.840 --> 00:35:07.320 manipulate it to get what you need. So, one of the things we want to do is make sure if we ever 00:35:07.320 --> 00:35:15.639 have a failure of this device, we don't want that device. We don't want that device. Sorry, 00:35:15.639 --> 00:35:19.639 if we ever have a failure of that device, we don't want these devices to ever become the root bridge. 00:35:20.520 --> 00:35:26.520 So, if this is my primary root bridge, I want this to be my secondary root bridge 00:35:27.639 --> 00:35:35.800 because I want to maintain this right here. So, we can set this one to the next best priority. 00:35:35.800 --> 00:35:42.199 So, when we looked at our priority numbers, what did we have? We had zero, 4,096. So, we could do, 00:35:42.199 --> 00:35:49.159 for example, on DSW-2, set the priority for VLAN 10 to 4,096. So, Spanning Tree, VLAN 10, 00:35:49.159 --> 00:35:56.199 priority, 4,096, and that will ensure that if something happens to DSW-1, 00:35:56.199 --> 00:36:04.040 I will become the root bridge because you're zero, I am 4,096, you're 32,768, 00:36:04.040 --> 00:36:09.479 and you're 32,768. So, that's a recommended best practice at a minimum, at a minimum. 00:36:10.919 --> 00:36:16.919 All right. So, there is another command I want to talk about, 00:36:17.560 --> 00:36:19.479 which doesn't do what you think it does. 00:36:19.479 --> 00:36:31.560 All right. So, I'm going to show the command, and it does not do 00:36:32.360 --> 00:36:36.199 what people are misled to thinking that it does. 00:36:40.280 --> 00:36:45.399 On DSW-1 as an example, oh, I'll just do it on DSW-2 right now. Okay. So, if I type in Spanning 00:36:45.399 --> 00:36:56.360 Tree, VLAN 10, you notice down here there's a thing that says root. If I type that in, notice 00:36:59.320 --> 00:37:09.959 I got primary and I got secondary. I got primary and I got secondary. 00:37:10.679 --> 00:37:24.040 Okay. These are commands that run an embedded script on your switch. They are commands that run 00:37:24.679 --> 00:37:33.560 an in-embedded script on your switch. Let me type this in again. Why? Because I want these numbers, 00:37:33.560 --> 00:37:40.199 so we can talk about it. All right. So, let's say we typed in root primary. 00:37:47.320 --> 00:37:52.679 Okay. Let's say we use that command. What does that do? 00:37:53.560 --> 00:38:06.760 Okay. What it does is it runs a script that says, what is the current priority of the root bridge? 00:38:08.199 --> 00:38:22.280 If the current priority of the current root bridge is 32,768, then I will set my primary 00:38:23.000 --> 00:38:44.280 priority to 24,576. All right. So, if the current root bridge is using the default priority, 00:38:44.840 --> 00:38:54.199 then the value you choose is 24,576. That's it. It will drop itself to 24,576. That's all 00:38:54.199 --> 00:39:01.000 it'll do. Why? Because that is better than the current root bridge. All right. But wait, 00:39:01.000 --> 00:39:10.919 there's more to this craziness. If, if, why that number? Because it's a script 00:39:10.919 --> 00:39:15.719 that Cisco wrote on the device. It's a script. That's it. That's what they chose. That's how 00:39:15.719 --> 00:39:20.280 it works. It is actually not a really good command to use. It's not. And we're going to get to that. 00:39:20.280 --> 00:39:27.719 All right. So, we've got 32,768. If the current root bridge, the current root bridge is 32,768, 00:39:28.520 --> 00:39:34.280 and I run this command, it drops this device to 24,576. All right. There. That one's out of the 00:39:34.280 --> 00:39:42.280 way. Okay. But wait, if, if the current root bridge is not using the default. Okay. So, 00:39:42.280 --> 00:39:49.399 let's say the current root bridge is using this value right here. If I run this command on this 00:39:49.399 --> 00:39:58.600 device, what it does is it says, what is the current value of the root bridge? Oh, it's 20,480. 00:39:58.600 --> 00:40:05.800 Well, that is not the default. Okay. So, what are you going to do? You, Switch, are going to 00:40:05.800 --> 00:40:14.520 determine if you use the same priority, is your MAC address lower? If the MAC address is lower, 00:40:14.520 --> 00:40:20.120 that means you can use the same priority and you become the root bridge. So, go ahead and do that. 00:40:20.760 --> 00:40:26.840 But if your MAC address is higher, then that means you can't use the same priority. So, 00:40:26.840 --> 00:40:34.199 use the next priority lower than that. 00:40:45.560 --> 00:40:51.800 What does that mean? What does that mean? It guarantees nothing. It guarantees nothing 00:40:51.800 --> 00:40:59.639 because once I do this on this switch, if I go to another switch and I run the command, 00:40:59.639 --> 00:41:06.840 it'll do the same thing. Let's do it. Let's have some fun. Let's do spanning tree VLAN 20. Let's 00:41:06.840 --> 00:41:11.239 do VLAN 20, root primary. Let's take this out. Let's check this out. 00:41:19.879 --> 00:41:25.399 That's all it does. Okay. Now, let's go over to somebody like ASW1. 00:41:25.399 --> 00:41:42.919 It's the wrong VLAN. VLAN 20 we want. It guarantees nothing. It's just a script. That's 00:41:42.919 --> 00:41:51.959 all it does. That's all it does. Yep. Why was it invented? Okay. Let's go way back in the day. 00:41:51.959 --> 00:41:57.879 Remember when DTP was created? Remember when VTP was created, right? Well, these commands were to 00:41:57.879 --> 00:42:03.399 make your life easier. Just go to the device, type in primary, type in secondary on another device, 00:42:03.399 --> 00:42:08.120 move on, forget it, it's over, right? And just hope for the best. That's it, right? They were 00:42:08.120 --> 00:42:14.679 trying to make everybody's life easier. But in the end, in modern day networking, it's a command 00:42:14.679 --> 00:42:19.560 that I tell people, just avoid it. It's not even worth it. Why? Because who's your root bridge? 00:42:19.560 --> 00:42:23.800 You want this to be your root bridge? Go to it, set the priority to zero. You want this to be 00:42:23.800 --> 00:42:29.239 secondary? 4,096 for the VLAN. You want this to be the root bridge for VLAN 20? Set the priority 00:42:29.239 --> 00:42:35.159 to zero. You want this to be secondary for VLAN 20? Set it to 4,096. Done. Call it a day. Forget 00:42:35.159 --> 00:42:45.080 this script stuff. It guarantees nothing. Guarantees nothing. Yeah. I know. When I first 00:42:45.080 --> 00:42:51.879 learned about this too, I was misled, misled way back in the day. Primary guarantees it. No, 00:42:51.879 --> 00:43:01.080 it doesn't. And I had to learn the hard way that it didn't. Yeah. All right. So, 00:43:02.439 --> 00:43:07.080 it may or may not come up on the exam, but now you know that that's how it works. 00:43:08.360 --> 00:43:11.959 And it's better to set you in the real world production environment, set it to zero 00:43:11.959 --> 00:43:18.679 on your root bridge. Oh, also watch this now. If I set it to zero in my root bridge, 00:43:19.399 --> 00:43:23.959 watch what happens if somebody tries to use this script. You ready? 00:43:25.399 --> 00:43:32.919 So, right now, ASW1, somebody's trying to use the script. DSW1 is our current root bridge 00:43:33.639 --> 00:43:39.399 with a priority of zero. Remember, I set the priority to zero for VLAN 10. It says, 00:43:39.399 --> 00:43:44.280 no, sorry, denied, because they are zero. 00:43:46.919 --> 00:43:51.080 So, if you set someone to zero, the script is useless on everybody else. 00:43:55.719 --> 00:44:00.760 All right. So, that is setting your primary. That is doing your secondary. 00:44:03.719 --> 00:44:07.879 But that is not all when it comes to manipulating spanning tree protocol. 00:44:10.120 --> 00:44:17.320 We can also adjust our cost. All right. So, this is what our VLAN 10 looks like now in our 00:44:17.320 --> 00:44:29.320 environment. We know that this decision is made how in this topology, the root port decision. 00:44:29.879 --> 00:44:34.280 We know it was made based on, one, cost being tied, 00:44:36.679 --> 00:44:48.280 and then upstream bridge ID being tied still, and then the port ID, 128.21 and 128.22, 00:44:48.280 --> 00:44:50.840 breaking the tie ultimately for this to be the root port. 00:44:52.760 --> 00:44:58.280 What if I don't like that decision, right? I like this decision. I want that to be my root bridge, 00:44:58.919 --> 00:45:05.159 but I don't want this to be the root port. How could I override that? So, for example, 00:45:05.159 --> 00:45:12.679 let's say we want instead this one to be the root port instead. How could we do that? Well, 00:45:12.679 --> 00:45:20.040 let's manipulate cost, right? What if we inflate the cost of this one? Right now, 00:45:20.040 --> 00:45:23.479 it is a cost of four. What if we make it a cost of five? 00:45:23.800 --> 00:45:30.360 Then that means ASW1, when it compares it, we would have eight, eight, five, and four. 00:45:31.399 --> 00:45:37.080 Which would win then? It would be simply the cost of four that wins, and none of the rest of those 00:45:37.080 --> 00:45:41.479 decisions matter anymore. But if that's what you need to do, and that's how you want to manipulate, 00:45:41.479 --> 00:45:47.479 you could totally do that. So, for example, on ASW1 right now, let's look at the spanning tree 00:45:48.280 --> 00:45:53.879 for VLAN10. And we'll see the spanning tree for VLAN10 says 45 is the root port, and it has a 00:45:53.879 --> 00:45:58.840 cost of four, this port. Let's just change that to five, and we'll see how this becomes our root 00:45:58.840 --> 00:46:03.239 port after that. Now, the only reason why I know that's going to happen is because I know how the 00:46:03.239 --> 00:46:07.320 decision was made. You see, if they ask you on the exam to do something like this, you have to 00:46:07.320 --> 00:46:13.080 understand how the original decision was made, so you can then manipulate what you need to. 00:46:13.080 --> 00:46:18.360 And you have to understand how the cost is cumulative. I'll show you an example after by 00:46:18.360 --> 00:46:23.800 using one of the other ports, for example. So, let's go to interface, gigabit ethernet 1.0.0.0.0.45, 00:46:24.679 --> 00:46:32.600 and we'll say spanning tree cost is now going to be five for my interface. So, instead of it being 00:46:32.600 --> 00:46:38.360 four, it's now five. So, look at the output for VLAN10, you'll see that we're now five. 00:46:38.360 --> 00:46:42.360 We are now a blocked port, and the root port is now 46. We made that change. 00:46:43.879 --> 00:46:49.080 So, just by manipulating the cost of interfaces, you have the opportunity to change who your 00:46:49.080 --> 00:46:58.040 root ports are, and possibly even your designated ports. The thing here is, is to realize that if 00:46:58.040 --> 00:47:03.800 this is five now, and this is four, and this is eight, and this is eight, we have to remember that 00:47:04.280 --> 00:47:10.439 we have to remember that this is based on four plus four, right? The four is coming from over 00:47:10.439 --> 00:47:16.199 here. That's where this four is, and this is the one of the interface. 00:47:18.120 --> 00:47:23.000 We know that this is five plus zero, four plus zero. So, 00:47:27.639 --> 00:47:33.639 knowing how the decisions are made can ultimately help you deciding where you make adjustments, 00:47:33.639 --> 00:47:38.840 because I don't necessarily have to manipulate costs here. I could manipulate costs elsewhere, 00:47:38.840 --> 00:47:45.159 right? Because if this cumulative cost is based on information up here, could we drop this down 00:47:45.159 --> 00:47:51.159 to two? Could we drop that down to two and get a value of four, or drop this down to one, 00:47:51.800 --> 00:47:59.800 and have that as two? Manipulate that to two. Now you got three. Would that give us a lower 00:47:59.800 --> 00:48:07.320 cumulative cost? Absolutely. So, realize that it could be multiple interfaces that get adjusted 00:48:07.320 --> 00:48:12.280 to make that change. It could be just one interface that gets adjusted to make that change. 00:48:12.280 --> 00:48:17.879 But let's go ahead and change both of these interfaces now to, let's say, nine, and we'll 00:48:17.879 --> 00:48:23.320 see that because they end up being nine, then it's one of these ports that have to become the root 00:48:23.320 --> 00:48:32.679 port. So, now eight is lower. And so, eight is tied. Upstream bridge ID is tied. Sending port ID 00:48:32.679 --> 00:48:39.159 is going to be 21. So, it should be 47 on ASW1. That becomes the root port if both of those get 00:48:39.159 --> 00:48:45.320 increased. So, let's say interface range, gigabit ethernet, one size zero, size 45 and 46. Let's say 00:48:45.320 --> 00:48:51.239 your spanning tree cost is now going to be nine. And we'll take a look at that output. 00:48:51.719 --> 00:48:55.000 And because we're using rapid spanning tree protocol, it fails over really, really fast, 00:48:55.000 --> 00:49:00.120 as you can see. But there's just another example. We manipulated cost on both those interfaces, 00:49:00.120 --> 00:49:01.879 and now we're actually going this way. 00:49:05.879 --> 00:49:10.040 Oh, root bridge is still the same. We haven't changed that, right? Root bridge is there, 00:49:10.040 --> 00:49:13.560 and now we're just showing you how to manipulate cost to change the direction of traffic. 00:49:14.280 --> 00:49:16.520 So, just keep that in mind for the certification exam. 00:49:17.320 --> 00:49:22.760 All right. So, you might be asked, you know, manipulate the environment so such and such an 00:49:22.760 --> 00:49:27.560 interface is blocked. Well, how might you do that? Well, you might be able to do it by changing the 00:49:27.560 --> 00:49:30.280 root bridge. But the question is, do they want you to change the root bridge? If you can't change 00:49:30.280 --> 00:49:35.320 the root bridge, what's your next option? Can I do it with cost? And if you can do it with cost, 00:49:35.320 --> 00:49:43.879 then you do it with cost. But we're not done yet with that. Why are we not done with that? 00:49:44.360 --> 00:49:48.040 Why are we not done with that? Because there's another way that we can manipulate, 00:49:49.639 --> 00:49:53.000 and that is going to be by adjusting the port ID. But before we get to that, 00:49:53.000 --> 00:49:55.959 I want to revert this all back to our default values. 00:50:01.879 --> 00:50:03.800 So, now we're back to our default values. 00:50:03.800 --> 00:50:18.120 Root port is 45, like we see here. Let's recall how all of this, again, this decision was made 00:50:18.840 --> 00:50:31.320 in this case. This decision was made because cost was tied, upstream, bridge ID, 00:50:32.120 --> 00:50:44.439 bridge ID was tied, and then the port ID was 128.21 and 128.22. 00:50:45.959 --> 00:50:54.360 And so, it was the port IDs of this device that was used by this device to determine what their 00:50:54.360 --> 00:51:03.800 root port should be. That implies, folks, that we could manipulate these values to make a decision 00:51:03.800 --> 00:51:16.600 on ASW1. That's right. We could manipulate these to manipulate ASW1. But that only works 00:51:17.560 --> 00:51:23.479 in scenarios like this, where you get to the deciding factor of the port ID. 00:51:24.520 --> 00:51:29.719 Remember, cost is always first, upstream bridge ID next, and then port ID. 00:51:33.479 --> 00:51:38.360 So, port ID is only going to happen if it's two links, or three links, or four links, 00:51:38.360 --> 00:51:41.719 or five links, or six, right, going between the same two devices. 00:51:42.199 --> 00:51:45.719 And you're using that upstream port ID to break that tie when it's all said and done. 00:51:46.840 --> 00:51:52.120 So, in this particular case, we could go ahead and manipulate it. And what value do we manipulate 00:51:52.120 --> 00:51:56.679 it? Well, earlier, can't remember who asked the question, but they were asking about, 00:51:57.719 --> 00:52:05.639 what does the 128 mean? I'm going back through my chat to find who said, no, I'm too far. It's 00:52:05.719 --> 00:52:16.600 somewhere in there. Conrad, Conrad said, what does the 128 mean? Well, that is a value that 00:52:16.600 --> 00:52:22.919 you can manipulate to manipulate the decision-making factor in this case. That's all it is. 00:52:22.919 --> 00:52:32.280 So, the value is from zero to 255, but it has to be in increments of 16, as we're going to see here. 00:52:33.159 --> 00:52:41.479 So, let's go to DSW1 right now, and look at the output of show VLAN10. We can see that we have 00:52:42.439 --> 00:52:49.399 21 and 22 listed as such for our ports. So, whenever DSW1's sending its BPDUs, 00:52:49.959 --> 00:52:56.520 those are the values, 128.21 and 128.22 that are in there. And right now, if we go to ASW1, 00:52:57.080 --> 00:53:06.760 its decision is based on the fact that 128.21 is lower than 128.22. Meaning, 00:53:06.760 --> 00:53:16.199 128.21 is lower than 128.22. Notice, it's not these numbers here that matter, it's the DSW1 00:53:16.199 --> 00:53:24.120 numbers that matter. So, on DSW1, I could change DSW1's port numbers in this scenario, and that'll 00:53:24.120 --> 00:53:32.840 change ASW1's. So, let's force gigabit one slash zero slash 46 to become the root port by changing 00:53:32.840 --> 00:53:41.800 the values on DSW1. So, right now, this is lower than this. So, all I have to do is make this one 00:53:41.800 --> 00:53:48.199 lower. So, we'll go to interface gigabit ethernet one slash zero slash 22, and I'm going to say 00:53:48.199 --> 00:53:56.280 spanning tree, and it is listed as your port priority. And you'll see that it says you have 00:53:56.280 --> 00:54:03.080 to be increments of 16. So, zero through 16. So, let's pick, what, it was 96, increment of 16. So, 00:54:03.080 --> 00:54:09.879 96. And that's it. All I can do is manipulate that first number, that first number. That's 00:54:09.879 --> 00:54:17.879 what I'm doing. So, done. So, now if we look at DSW1, we'll see that value has changed here. It's 00:54:17.879 --> 00:54:34.040 now 96.22. And I've overused my time in the lab environment. Got to connect back in. 00:54:35.879 --> 00:54:44.120 Had nothing to do with what I just configured, folks. All right. There we go. So, 96.22. 00:54:44.760 --> 00:54:51.239 So, now, that is what's being sent in the BPDU at that port. And then the gigabit one 00:54:51.239 --> 00:54:57.159 slash zero slash 21 is sending 128.21. So, 96 is lower. So, remember, this is what ASW1 looked 00:54:57.159 --> 00:55:05.800 like before, right? We should see that that is now flipped. And there you go. So, yes, 00:55:05.800 --> 00:55:13.560 something I want you to know for the exam. Absolutely, if there's any scenario on the exam, 00:55:15.080 --> 00:55:19.639 and they're talking about manipulating something between these two switches, 00:55:20.280 --> 00:55:26.679 manipulating something between these two switches, but the rule of thumb is that you are not allowed 00:55:26.679 --> 00:55:35.639 to make changes on this switch or this switch, as an example. You can only make the changes 00:55:36.199 --> 00:55:43.239 on the upstream switch. Then you immediately have to think, I have to adjust the port ID. 00:55:43.239 --> 00:55:48.280 Because if you're allowed to touch this device or this device, for example, 00:55:49.080 --> 00:55:53.959 then you could just manipulate the cost. You could just manipulate the cost of the interface. 00:55:54.600 --> 00:56:01.399 But if you're not allowed to touch those devices, then you have to manipulate the port ID 00:56:02.199 --> 00:56:10.840 going down to them. So, can you give an example or two of why you might choose? Yeah, 00:56:10.840 --> 00:56:14.280 I just gave the example. Can you give an example or two of why you might choose to 00:56:14.280 --> 00:56:17.639 change a port priority on an upstream switch as opposed to using another option? 00:56:17.639 --> 00:56:25.800 Because you are being forced to do it that way. Being forced. Yeah. Because we all know, 00:56:25.800 --> 00:56:31.080 based on today's discussion, I could just go to this device, manipulate the cost. If I tell you 00:56:31.080 --> 00:56:35.639 you're not allowed to touch that device, then what's your next best option in this scenario? 00:56:36.120 --> 00:56:38.679 Port ID. That's how you'd have to do it. 00:56:44.600 --> 00:56:46.600 Isn't this fun and exciting, folks? 00:56:50.600 --> 00:56:52.919 Right. One more thing, though, to keep in mind. 00:56:55.879 --> 00:57:01.639 No, it doesn't have to be on the root bridge, for example. So, let's say I told you that 00:57:06.600 --> 00:57:11.399 let's say right now the scenario was that this was the root port, this was blocked, okay? It could 00:57:11.399 --> 00:57:21.560 be this as an example, right? Let's say this was the topology instead. And I told you I wanted 00:57:21.560 --> 00:57:29.479 this port to be the root port instead, but you weren't allowed to log into ASW1. Then that means 00:57:29.800 --> 00:57:35.159 you have to go over here and manipulate the port ID so that this port ID is lower. So, 00:57:35.159 --> 00:57:42.360 no, it does not have to be the root bridge. Yeah. Yeah. So, that's why it's important for 00:57:42.360 --> 00:57:47.560 you to be able to decipher based on the algorithm. What? Who's the root bridge? What are the designated 00:57:47.560 --> 00:57:51.800 ports? What are the root ports? What are the blocked ports? How was it determined so that 00:57:51.800 --> 00:57:58.040 way there you have the ability to do the manipulation? That's why the algorithm is so 00:57:58.040 --> 00:58:01.959 important. If you don't know the algorithm, you can't walk through it. It's tough to determine, 00:58:01.959 --> 00:58:07.560 hey, could I use the port ID here? Or do I use cost? Or do I use this? Think about this scenario 00:58:07.560 --> 00:58:18.520 as well. Upstream bridge ID. Okay, we gave an example earlier that when we were trying to 00:58:18.520 --> 00:58:24.120 figure out the root port as an example, we said that what if this was an Ether channel bundle? 00:58:25.080 --> 00:58:30.679 This was an Ether channel bundle. And this had a cost of eight and this had a cost of eight. 00:58:32.600 --> 00:58:39.800 Well, then what is going to break that tie? What is going to break that tie? Well, the upstream 00:58:39.800 --> 00:58:49.879 bridge ID. So, right now, we know that this has the lower upstream bridge ID, right? 00:58:54.600 --> 00:59:02.040 So, could you technically, if this is the root port right now, could you technically 00:59:03.639 --> 00:59:09.800 change the bridge ID of this and all of this becomes the root port? Yes. But then you're 00:59:09.800 --> 00:59:14.280 actually changing who the root bridge is too, aren't you? Yeah, in that scenario, you would be. 00:59:15.320 --> 00:59:22.760 But just showing you how manipulating things like bridge priority, changing who the root bridge is 00:59:22.760 --> 00:59:29.479 can manipulate the path that is taken, manipulating cost, manipulating port IDs, 00:59:29.479 --> 00:59:33.560 all of those come into play when you're manipulating your Spanish root protocol. 00:59:40.360 --> 00:59:48.120 And so, all things you really need to be aware for the exam, because you are in Encore, you are in 00:59:48.120 --> 00:59:57.639 CCNP. The odds of them testing you on the simpler things are very low. The odds of you 00:59:57.639 --> 01:00:11.159 testing you on strange things like changing port ID or cost are a lot higher. Also, let's not forget 01:00:11.719 --> 01:00:20.280 the power of per VLAN spanning tree plus and rapid per VLAN spanning tree plus 01:00:20.280 --> 01:00:25.479 comes in the fact that you can create a different tree for each and every single VLAN you have. 01:00:27.800 --> 01:00:35.000 So, let's say right now, this is the tree we have for every one of our VLAN. So, VLAN 10, 01:00:35.000 --> 01:00:43.239 VLAN 20, VLAN 50, VLAN 200. Let's say by default, this is what the tree looks like. And that's what 01:00:43.239 --> 01:00:49.959 happens on Cisco devices, just so you know. Every single VLAN you create will automatically have 01:00:49.959 --> 01:00:57.399 this same looking tree. So, if I look at my device, and I look at DSW1, and I log into it, 01:00:57.399 --> 01:01:03.719 I will type in show span. By default, it would be the root bridge for VLAN 1, VLAN 10, VLAN 20, 01:01:03.719 --> 01:01:10.360 VLAN 50, VLAN 200, etc., etc., etc. Why? Because you think about it, the numbers by default are 01:01:10.360 --> 01:01:17.000 all the same. So, unless you start manipulating it, they will all have the same tree. Now, 01:01:17.000 --> 01:01:23.719 they're different trees, but each tree will look the same. So, the power though of per VLAN spanning 01:01:23.719 --> 01:01:28.040 tree plus and rapid per VLAN on Cisco devices is that we can change all of that. And we already 01:01:28.040 --> 01:01:34.360 know that just by simply changing the root bridge, you can change a tree. So, right now, 01:01:34.360 --> 01:01:42.679 for example, VLAN 50 is also using this exact same looking tree. But what if, for example, 01:01:42.679 --> 01:01:53.239 we make this instead the root bridge for VLAN 50? If we do that, it now means that traffic flow 01:01:53.239 --> 01:02:01.560 is going to be totally different for VLAN 50 than it is for VLAN 10. So, right now, right, 01:02:01.560 --> 01:02:08.679 VLAN 10 traffic does this, right? VLAN 50 would be down here, and VLAN 50 traffic would be doing 01:02:08.679 --> 01:02:18.360 this because why? Same tree, same looking tree. So, this, all traffic is flowing through that device, 01:02:18.360 --> 01:02:25.719 all of it. So, what if we make this the root bridge? Does that mean the traffic can now flow 01:02:25.719 --> 01:02:29.959 like this for VLAN 50 while it flows like this for VLAN 10? Yeah, that's a type of 01:02:29.959 --> 01:02:34.600 balancing of traffic. It's not true load balancing because VLAN 50, right, who's in that, 01:02:35.399 --> 01:02:40.600 right? If they're not doing, if they're not consuming a lot of bandwidth or resources, 01:02:40.600 --> 01:02:46.040 right, it's not a low perfect load balancing. But if you can change the way that traffic flows 01:02:46.040 --> 01:02:51.000 and start using more links, start using more distribution devices, 01:02:51.000 --> 01:02:55.479 you're going to get better performance overall in your environment. So, I'm just going to show it 01:02:55.479 --> 01:03:02.520 here. Right now, DSW1 is the root bridge for VLAN 50 as well as VLAN 10 and all the other ones. 01:03:02.520 --> 01:03:07.159 Hey, let's just go ahead and go to DSW2, type in Spanish, VLAN 50 priority zero. 01:03:07.159 --> 01:03:13.159 That now makes me the root bridge. So, like I said earlier, on Cisco devices, 01:03:13.159 --> 01:03:19.639 we're not blocking physical ports, we're blocking logically our ports on a VLAN by VLAN basis. So, 01:03:19.639 --> 01:03:25.159 notice here that all of these are now designated ports, every single one of them for VLAN 50, 01:03:25.159 --> 01:03:31.239 but for VLAN 10, those are blocked and that's a root port. That's right, two different trees now. 01:03:32.679 --> 01:03:37.000 One for VLAN 10, one for VLAN 50, they're different. Instead of looking the same, 01:03:37.000 --> 01:03:42.120 they're now looking different. So, what does that mean now for somebody like ASW2? Take a 01:03:42.120 --> 01:03:47.479 peek at that. Based on the algorithm, based on going through the motions, 47 would be the root 01:03:47.479 --> 01:03:59.399 port in this case. So, that means traffic is going to flow this way for VLAN 50. 01:04:01.719 --> 01:04:08.199 Look at ASW1. If somebody down here was added for VLAN 50, their traffic would flow this way. 01:04:09.159 --> 01:04:16.679 How cool is that now? How cool is that? And if somebody for VLAN 10 is here, their traffic is 01:04:16.679 --> 01:04:21.639 going to flow that way. How cool is that? Look at that. You are starting to use more of your 01:04:21.639 --> 01:04:37.159 links by manipulating. Like, and then that would be your DSW1. 01:04:37.159 --> 01:04:51.479 So, there you go. That's the power of Cisco's proprietary versions of Per-VLAN Spanning Tree 01:04:51.479 --> 01:04:56.439 Plus and Rapid Per-VLAN Spanning Tree Plus. So, question, for all of you, 01:04:58.120 --> 01:05:04.439 how many of you have taken advantage of this in your environment with Cisco switches? Anybody? 01:05:07.159 --> 01:05:14.520 Yes, you can do something like this with multiple Spanning Tree Protocol as well, 01:05:14.520 --> 01:05:16.040 and we'll talk about that when we get there. 01:05:23.000 --> 01:05:28.439 So, a lot of important things there. Little nuggets of information too. What did we talk 01:05:28.439 --> 01:05:34.280 about? We talked about timers. So, know your hello time, know your max age time, 01:05:34.280 --> 01:05:39.000 know your forward delay time. Make sure you know those. Make sure you know the different states, 01:05:39.000 --> 01:05:42.919 blocking, listening, learning, forwarding, and how the timers apply to that. Make sure you know 01:05:42.919 --> 01:05:47.800 about alternative ports and backup ports for the certification exam. Know the command to change 01:05:47.800 --> 01:05:52.600 the Rapid Spanning Tree Protocol. Understand that Rapid Spanning Tree Protocol can be backwards 01:05:52.600 --> 01:05:57.159 compatible with Per-VLAN Spanning Tree Plus, right? Why? Because it's going to use timers 01:05:57.159 --> 01:06:02.439 in order to be backwards compatible with Per-VLAN Spanning Tree Plus. But we have our proposal and 01:06:02.439 --> 01:06:06.439 agreement process for Rapid. So, if two Rapid devices are communicating, they're going to use 01:06:06.439 --> 01:06:11.000 proposal and agreement process. If that fails, then they're going to use timers as a backup 01:06:11.000 --> 01:06:14.439 mechanism for themselves. And then manipulation, manipulation, manipulation, know that. 01:06:15.080 --> 01:06:18.600 There's a really high probability you'll be tested on that on the certification exam, 01:06:18.600 --> 01:06:22.919 and it might actually be a lab, a simulation, as opposed to just multiple choice questions. 01:06:22.919 --> 01:06:28.120 So, keep that in mind. Make sure you are well aware of how to manipulate Spanning Tree Protocol.