I want to remind you of something - the fact that we get one root bridge per broadcast domain, which really translates to one root bridge per virtual LAN, or VLAN. It didn't used to be the case where it worked that way. In fact, we used to run a version of 802.1D that was Common Spanning Tree, or CST. You don't see this anymore. To be very clear, we do not see this anymore. This is something that we saw 15 years ago where we could have VLANs, but all of the VLANs would share one spanning-tree domain. So there would be one root bridge for the whole thing, but very quickly we realized that we need to have different reference points in different VLANs. So classic Spanning-Tree Protocol was adjusted and what we got with a changed 802.1Q trunking was Per VLAN Spanning Tree Protocol Plus, or PVST+, Per VLAN Spanning Tree Plus, okay. That allows us to have one root bridge per VLAN, but 802.1D is still running in PVST+. It is just we run it on a per-VLAN basis and if we think about a topology that might have hundreds if not thousands of VLANs, we don't see thousands of VLANs in everyday network, but we may see them in a metro Ethernet environment. We may see it in a very large infrastructure or maybe a very large datacenter.
Running a large number of VLANs can be a big challenge to us. Nevertheless, another challenge that faces us is speed to converge. Convergence is a term that we have mentioned to you about dynamic routing protocols. It's speed to adapt, speed of letting the dust settle. You don't want to be too, too fast. We want to be as fast as we can without being nervous about changes, to being unstable. The problem is 802.1D harkens back to the bridge era and in the bridging era we were just hyper concerned about reacting too quickly. And as a result, they are engineered for slow convergence, such slow convergence that we don't want to run them. So we need something that's going to allow us to eliminate loops, but react in a timely manner, react in a way that doesn't cause 30 seconds of downtime when I switch from one root port to a different root port because I lost a link. So what are my options if I want a quickly adapting spanning-tree version?
|Protocol||Standard||Resources Needed||Convergence||Numbers of Trees|
|PVST+||Cisco||High||Slow||One for every VLAN|
|Rapid PVST+||Cisco||Very high||Fast||One for every VLAN|
Well the Institute of Electrical and Electronics Engineers, or IEEE, introduced the standard known as Rapid Spanning Tree Protocol, or RSTP. Rapid for being a fast version of Spanning-Tree Protocol and it was labeled as 802.1w, whereas if you remember Common Spanning Tree Protocol was 802.1D. And you should know the IEEE standards. So we've seen a few now in the Cisco curriculum, 802.1Q for trunking, 802.1D for classic Spanning-Tree Protocol, 802.1w for Rapid Spanning Tree Protocol.
Now when they introduced 802.1w, notice one tree per all VLANs exactly like the 802.1D standard. All right, Cisco's implementation of Rapid Spanning Tree Protocol, known as Rapid Per VLAN Spanning Tree Plus, per VLAN, they enhanced Rapid Spanning Tree Protocol. They wanted one instance of spanning tree for each and every single VLAN. So it is Rapid PVST+ that we can place on our Cisco Catalyst switches.
By default, when we turn our switches on we get spanning tree. We get Per VLAN Spanning Tree, or PVST. The other way of running it based on this chart is Rapid PVST+. So we can switch between those two modes and many switches also support Multiple Spanning Tree, or MST, that's a topic for another day. So you cannot set classic STP, you cannot set the regular RSTP, you have to choose one of the per VLAN kinds. Now if you look at the standards, yes, we've covered that. Resources needed, it starts to get extremely high. Take that with a grain of salt. The resources needed are proportional to the number of VLANs that you have. So if you have 5, 10, 20, even 64 VLANs, I'm not going to be worried about the resources that my Rapid PVST+ is going to consume. I will start to worry about it when my switches can't handle it and switches have different limits, but 64 is the lower limit. Sometimes you will see 128 or 256 and when we start getting a large number of VLANs, there is a different protocol to use, that's MST. But understand this, if Cisco tells you recommendations, they're quite consistent about it now. Use RSTP+, that's it. Fast to converge, works really well, and builds on what we taught you. You know, we taught you about classic Spanning-Tree Protocol so that might have left a bitter taste in your mouth, but the reality is you can't learn Rapid Spanning Tree Protocol without having a solid foundation in classic.
So by default, PVST+, one instance of spanning tree for each and every single VLAN, but be careful here. By default, every switch will make the exact same decision based on the exact same information. Therefore, each and every single spanning-tree instance will have the same root bridge for each and every single VLAN. So everything will be the same by default. How do we know we are running PVST+? The output of show spanning-tree, we will see ieee. All right, it says ieee but we're not running 802.1D in its IEEE native format, no. It's PVST+, Cisco's enhanced version of 802.1D. It is enabled by default on all ports. But remember the slow convergence when we have topology changes. We rely on timers with Per VLAN Spanning Tree Plus when things don't go so well, and these timers make convergence unacceptably slow in today's environment.
There are two entry points into this flowchart that we're going to really try to help you master. There's a pre-established port in the blocking state because we found it to be a loop and it did not get the report or designated port status, but there is also a new link coming up. Let's look at it from the vertical pathway, where we have a pre-established blocked port first. So Spanning-Tree Protocol convergence finds the best ports and then it found maybe two blocked ports. We will converge, we will adapt, we will not assume that a blocked port is permanently blocked. So what will keep a blocked port blocked is when it receives Bridge Protocol Data Units, or BPDUs, which supply it with information, which indicate that this port is inferior and redundant. It comes in every two seconds because that's the BPDU interval. Now in the absence of received BPDUs, they made this timer, the blocking timer, it is called the max age timer. It is ten missed BPDUs. Imagine missing ten BPDUs, we're probably not going to get it on the eleventh try, right? So what happens is after 20 seconds, which is 10 times 2, the 2 being the BPDU interval, we move to listening. Now in listening, it would further towards being in forwarding in either root port or designated port, we don't know, we don't care. Probably root port.
Listening is still functionally very like blocking. It's just got a different name and it's further towards forwarding. We're still not sending and receiving frames, we're still only listening to BPDUs. We stay here for 15 seconds and if you want to know where that 15 seconds came from, it came from the BPDU interval, which is 2 BPDU timer times the diameter that the spanning-tree designers chose, which was 7 switch hops, 2 times 7 is 14, round up to 15, that's where they got that forward delay timer. Who cares? Not many people. But anyway, we stay there for 15 seconds and then we restart that same timer, begin anew, and now we're in learning. Learning is different. We are not forwarding frames, we are not receiving frames other than BPDUs to learn about the topology, but we learn about Media Access Control, or MAC, addresses now.
So we're going to start to put in MAC addresses in the dynamic table. Here is why. Because when we flip the switch, move to forwarding, we don't want to just flood everything out. We don't want to flood. We know what MAC addresses live downstream of this learning port now. So when we switch to forwarding, I know exactly where they are and I don't have to flood that out to every port except the port that they came in on. Okay, and then forwarding. Finally, we are finding ourselves in root port or designated port, we don't know, again, we don't care. Our operational status is forwarding and we're working like a normal switch port at this point. So do the math here, folks. It takes almost as long to do that port transition as for me to explain it.
I'm adding up the numbers here, 20 + 15 + 15, that's 50 seconds. Fifty seconds from the initial point that we did not receive a BPDU. That's a long time, that's a really long time in today's environment. But what happens when we plug a device into a switch port? Have you ever plugged a PC, a phone, anything in and were not able to establish connectivity for 30 seconds? You're sitting there trying to figure out why. Well this is the reason why. More than likely Per VLAN Spanning Tree Plus running on that port, we plug in the PC, we still have to progress to the listening and learning phases, 15 seconds for listening, 15 seconds for learning, then we're forwarding. So these timers are which make Spanning-Tree Protocol so slow by default. Why timers though? Well first and foremost, the BPDU exchange is really fast, every 2 seconds by default and those can be flooded and propagated throughout the entire topology within seconds. The problem lies in the fact that there is no mechanism to make sure that the correct decision is being made. It's really what it boils down to. We don't know if we should truly be a root port or truly be a designated port. It looks good but we can't verify whether that was the best decision. So these timers give us the ability to sit there and just wait and lay back and say, well, 50 seconds have gone by, should be good, we must have made the right decision. It's what it comes down to, just protecting ourselves from accidentally introducing a loop.