Chapter 1 – Introduction
The original spanning-tree protocol was developed way back in the mid-1980’s by Radia Perlman. This is well before switches, as we know them today, even existed.
What you’re seeing here is the original paper published in 1985, outlining how spanning-tree works.
And it worked well for its time. But back in the early-90s, the demand on networks wasn’t what it is today. They didn’t connect phones to their network, they didn’t have mobile devices, or high-speed internet. So if it took a minute for an interface to come up, that wasn’t a big deal.
But it wasn’t long before this needed to change. One of the major improvements is Rapid Spanning-Tree Protocol, which aims to handle changes in the network faster.
We’re going to take a look at what’s changed in Rapid Spanning-Tree, and how it achieves faster convergence.
Chapter 2 – Introducing RSTP
Just because spanning-tree has been improved on, doesn’t mean that we need to throw away what we’ve already learned. There are a lot of similarities:
- There is still a root bridge
- BPDUs are still sent through the network
- Switches still find the best path to the root bridge
- Links are still blocked to prevent loops
So then, what’s changed?
- For one, all switches actively send BPDUs, not just the root bridge
- The BPDU format has changed a little to include more information
- There are some new port states, to supplement the blocking state
- There are improvements to bring up ports quicker
- And Cisco have added their own per-VLAN technology
We’ll take a look at all of these changes in this video.
So, considering that there’s a few versions of spanning-tree, how do you know what your switch is running?
Once again, we come back to the show spanning-tree command. On this switch we see that we’re running a spanning-tree called ieee. This is the original version of spanning-tree.
Usually Cisco switches will run some type of RSTP by default. That means that you can take a brand-new switch out of the box and connect it to your network, and you will automatically have RSTP protection.
But we can’t just leave it at that. We still need to tune it to our needs though, and how to troubleshoot it if something breaks.
Let’s see how we can change the version that we are using. We do this with the spanning-tree mode command. You’ll see that there’s a few different options here.
Rapid-PVST is Cisco’s implementation of RSTP. I say Cisco’s implementation, as they have added features that aren’t strictly part of the RSTP standard. We’ll talk more on this later.
If we look at the version once again, we can see that it has been updated to RSTP.
Quiz
As usual, this video has quizzes to test yourself out on, and to get you thinking outside the box.
Chapter 3 – BPDUs and the Root Bridge
The basic concept of bridge ID’s are still the same in RSTP. That is, the lowest bridge ID becomes the root bridge.
But if you take a look at the bridge priority, you’ll notice it doesn’t quite look right. In the last video we said that the bridge priority was in increments of 4096. But the value here is 61441, which is not divisible by 4096.
Why is this happening? In RSTP, the BPDU message now includes a System ID Extension field. On a Cisco switch, this is the VLAN ID.
That’s why we see the bridge priority broken into two parts; the priority and the sys-id-ext. The system ID is 1 here, because we’re looking at VLAN 1.
You should also notice that the Bridge ID Priority is different to the Root ID Priority. This tells us that the local switch is not the root bridge.
Let’s take a look at our other switch. Notice here that it says this bridge is root. This means that the switch we’re logged onto is the root bridge. Quite simply, if you don’t see this, some other switch is the root bridge.
Let’s look at the BPDUs again for a minute. In the original spanning-tree protocol, only the root bridge would generate BPDUs, and other switches would forward them through the network.
The only exception to this is TCN’s, when a switch would use a BPDU to notify the network of a topology change.
In RSTP, all switches send BPDUs to their neighbours. These are a ‘hello message’ to identify themselves, and learn about neighbours.
Individual BPDUs are no longer flooded or forwarded through the network. BPDUs are now only sent to the immediate neighbour.
A significant advantage of this is being able to use BPDUs to see if an immediate neighbour is up or down. If three BPDUs go missing in a row, then the neighbour is considered to be down.
BPDUs are sent out at regular intervals according to a hello-timer. This is every 2 seconds by default.
We can change the default timer if we want to. In configuration mode, we use the spanning-tree command. Notice that we have to include a VLAN number. This is a Cisco thing, they require configuration to be applied per VLAN.
And we include the hello-time keyword, and the time in seconds that we want.
Quiz
Now a quick architectural question for you. Why would we want to control where the root bridge is within our topology?
Chapter 4 – RSTP Ports
When it comes to ports, some things change, and some things remain the same. The root port for example, is the same. There is still one root port per switch, and it still points out the best path to the root bridge.
The only exception is the root bridge itself, which does not have any root ports. All ports on the root bridge are designated ports.
Designated ports are still the same. They are ports that point away from the root bridge, and can forward regular traffic.
Each network segment can have only one designated port. If there were more than one, there would be a loop.
What do I mean by network segment? In nearly all cases these days, this is a link between two switches. The ‘segment’ is the link between them, and there are only two devices on the segment.
A more complicated scenario is where you have an old fashioned hub, or a dumb switch, or something like that. In a case like this, more than one device can connect to the single segment.
This is rare these days though. We shouldn’t see hubs anymore, but it’s still possible, so be aware of it.
If this does happen, there can only be one designated port for the entire segment. If there was more than one, we would have a loop.
Therefore, one of these ports would need to be blocking instead.
The blocking port is where things get interesting. Blocking ports can now be categorised as either Alternate ports, or as Backup ports.
Any type of blocking port will block regular traffic, but still allow BPDUs. In fact, a port must be receiving BPDUs to be in a blocking state.
Of course, you must be wondering why this is the case. First, remember that all switches send BPDUs to their neighbours. If a port is not receiving BPDUs, then it is not connected to another switch. It’s probably connected to a PC, printer, server, or some other end device.
We can’t create loops on interfaces connected to these devices, so those ports do not need to be blocking.
As I just mentioned, blocking ports can be alternate or backup. An alternate port is one that has received a superior BPDU from a different switch in the same network segment.
The network segment in this case is just the link between two switches.
This is an alternate port, as it is an alternate path to the root bridge. It’s ready to take over if the current root port fails.
Backup ports come into play when there is a shared segment. That is, something like a hub that allows more than two switches to connect to each other.
In our example, one switch has two links. One link on this switch becomes designated. On the other switch, the port is blocking. This would be an alternate port, as we just discussed.
Now, back on the switch with two links, something interesting will happen. The switch will see its own BPDUs. That is each port will send BPDUs, and the other port will receive them.
Only one of these can be designated through, so the other must be blocking. But because the switch receives a BPDU from itself, the blocking port will be a backup port. It’s called a backup port as it’s a backup to this segment.
Please take note though, that hubs are rare, so you’re unlikely to see backup ports. If you find hubs in your network, take steps to replace them.
We can examine the output of show spanning-tree to see these port types. Here we can see:
- The role, which will be root, designated, alternate, or backup
- The status, which can be forwarding or blocking
- And of course, the cost, which we have already spoken about
The cost is determined by the speed of the port. There may be sometimes when we want to override this though. Perhaps we want to make traffic flow over a different path for troubleshooting.
To do this, we configure an interface, and then enter the spanning-tree cost command. The cost is any numerical value.
Of course, we should verify the change with show spanning-tree.
You’ll see that the cost has changed. This has in effect changed which ports are root and alternate.
Quiz
Take a look at this topology. Can you figure out what would happen, from a spanning-tree point of view, if the red link were to break?
Chapter 5 – Port States
In the original spanning-tree, a port needs to work though the blocking, listening, learning, and forwarding states. All up, it would take about 50 seconds for a port to come online, which is far too long in a modern network.
RSTP addresses this issue by changing the states to discarding, learning, and forwarding. The old blocking and listening states have effectively been combined into discarding.
But the big change is how all these work. They don’t have timers anymore. Instead they have a negotiation procedure.
As before, when an interface first comes up, it is in the blocking state, so a loop can’t form before it’s detected.
For our example, imagine that we’re adding a new switch into the network. There’s no loop here, but spanning-tree does not know that yet.
The switches will start sending BPDUs, which starts the negotiation process, called a SYNC. This gets a bit complicated, but basically they use the new fields in the BPDU to share information.
They negotiate the link to the root bridge first, and enable that link. At this point, the downstream links are still blocked.
One switch will propose which links should be forwarding, and which should be blocked. The SYNC process then completes for downstream switches, and the appropriate links transition to forwarding.
I have very much oversimplified this process. The point to remember is that RSTP takes a more active approach in bringing up interfaces. There are no timers, which means interfaces come up faster.
This approach means RSTP can respond very quickly to changes in the network.
Let’s see it in action. First, we’re changing our flavour of spanning tree to PVST. This is Cisco’s implementation of the original spanning-tree standard. I’ll get to why it’s called PVST later.
Next, I’m enabling spanning-tree general and event debugging. In case you’ve forgotten, debugging is getting extra logging information from the switch for troubleshooting. I have a separate video on this if you want a review.
If we’re on the console port, which I am, we will see the debug logs in real time. However, if you’re connecting to a switch with SSH or telnet, you need to run the terminal monitor command first. This just sends the logs to your terminal session.
We’re already getting a few logs, as there’s always something happening.
I’m now bringing up a new link on gigabit 0/2. Notice that we can see the interface going through the various states.
First listening, then learning. Finally forwarding. As you can see, it takes too long for a port to transition into forwarding.
I’m now going to shut that port down so we can try it in RSTP. Of course, we’ll get a few more debug logs along the way.
Now, we’ll change to RSTP mode. This in itself will generate a lot of logs. We’ll just wait until they’re done…
…OK, that looks stable now.
I’m now going to bring gig0/2 up again…
…And that’s done. See how much faster that was with RSTP? We can go back and look at a few of the steps that it took, such as selecting designated as the port role, and sending the RSTP proposal.
Just remember to disable any debugs when you’re done.
Quiz
Another quick quiz question for you. I don’t think you’ll find this one very hard.
Chapter 6 – Port Topologies
When we think of spanning tree topologies, we can think about different ways that ports can behave. So far, we’ve mainly talked about the links between switches
As far as RSTP is concerned, these are either:
- Point-to-point ports, which is a direct connection between two switches, or
- Shared ports, which connect to a shared segment, like having a hub in your network
We’ve looked at both of those already. But there’s a third type we haven’t looked at, called an Edge port. This is where edge devices connect.
These are devices like PCs, printers, routers… Basically anything that’s not connecting switches together.
Why is this important? Because spanning-tree is there to stop loops. And where do loops occur? In devices that forward layer 2 frames. So, basically, hubs and switches.
Edge devices do not forward frames, so they don’t cause loops.
So, as you can see, there’s no reason to worry about BPDUs, port states, blocking ports, and that sort of thing, on edge ports.
In the old days, that would be a problem. Because even if we connected an edge device, it would still take 50 seconds for the port to come online. That’s just wasted time!
To address this, even before RSTP was invented, Cisco created a feature called PortFast. It was such a good feature that when RSTP was released, it became a built-in part, which we now know as the Edge port.
When we know that certain ports are for edge devices only, we can configure them with PortFast. Let’s see how that’s done.
Under interface configuration, we enter the spanning-tree portfast command. Despite being part of the vendor-neutral RSTP, we still call it portfast when using Cisco switches. Just remember that other vendors will call it an Edge port.
Notice that we’re given a warning… We have authorised the switch to bypass many of the spanning-tree procedures on this port, in order to get it to perform better. This is fine, but be aware that connecting a switch here while portfast is active, may introduce a loop into the network.
If we look at the spanning-tree details again, we can see that this interface is now listed as an Edge port. It also goes straight into forwarding mode, bypassing the discarding, learning, and forwarding states.
It’s also worth noting that if this port goes up or down, it will not trigger a TCN BPDU to other switches.
Practically though, what happens if someone plugs a switch into an edge port? Whether it’s malicious or accidental, this can happen.
By default, this may introduce a loop into the network, which of course is very bad. Does this mean that PortFast is just too risky to use?
Not necessarily. There’s another feature that we can use along with PortFast, called BPDUGuard. As far as I know, this is not on the exam, but I feel it’s too important not to mention, at least briefly.
Imagine we have configured an edgeport with PortFast, so we can connect a workstation. To be safe, we also configure BPDUGuard.
Then, someone comes along, disconnects the workstation, and connects a switch. When the new switch is connected, it will start sending BPDUs. The first switch will see this, and think “hang on, that’s not right, there must be a switch connected!”
That port will then lose its Edge port status, and become a regular port. In this way, our network is still protected from loops.
Quiz
A couple of trickier questions for you this time. You might need to do some of your own research on these ones.
Chapter 7 – Per-VLAN Instances
The original spanning-tree, known as 802.1D, has quite a few drawbacks in the modern network. We’ve looked at a few of them in this video.
Over time, there have been a few improvements to the original protocol, and a few new variants of spanning-tree, not all of which are shown here. Cisco even had a few proprietary versions, which only worked with other Cisco switches.
There have also been vendor-neutral versions that work on all switches, like RSTP. To be honest, these just take Cisco’s improvements, like better timers, port roles, and other features, and standardised them.
So RSTP is the vendor-neutral improvement on spanning-tree. Cisco’s implementation of this is called Per-VLAN Rapid Spanning-Tree.
This means that Cisco’s enhanced version of RSTP is aware of VLANs, while the official version of RSTP is not.
Another version of spanning-tree, called MSTP, is the vendor-neutral option that’s VLAN aware.
OK, so what do we mean when we say ‘VLAN aware’ or ‘per-VLAN’?
Well, traditionally, the spanning tree topology is the same for the entire switching domain. If a port is the root port, it’s the root port for all VLANs. If a port is blocked, it’s blocked for all VLANs.
In the per VLAN model, there is a separate spanning-tree instance for each VLAN.
Take this topology for example. We have two VLANs; 10 and 20. We can configure different priorities, root bridges, and link costs for each VLAN. This means that the switch selected to be root bridge for VLAN 10 may be entirely different to the switch selected to be root bridge for VLAN 20.
There are pros and cons to this approach of course.
In a traditional model, some links would be blocked. These links would then be sitting there idle all the time, essentially being wasted. In our per-VLAN model, a link may be blocked for VLAN 10, and a different link is blocked for VLAN 20. This means that we’re utilising all our links.
On the other hand, the switch needs to maintain a separate instance for every VLAN, even if they have the same configuration.
If you have a lot of VLANs, then your switch will have to run a lot of spanning-tree processes. This puts more load on the switch. MST is a reasonable alternative in this case, but that’s outside the scope of a CCNA-level video.
Let’s see how this looks on a switch. First, we’re creating our two VLANs, 10 and 20.
We want this switch to be the root bridge for VLAN 10, but not for VLAN 20. This is done by changing the bridge priority, as we saw in the last video.
This time, I’m going to show you a shortcut. We’re going to run spanning-tree vlan 10 root primary.
This is a macro on Cisco switches that sets the bridge ID for us, so this switch will become root. By specifying VLAN 10, this change will only happen for the VLAN 10 spanning-tree instance.
We can do the same for VLAN 20, using the secondary keyword. This will set a bridge priority that’s a little worse than the current root bridge, but still better than other switches. So if the root bridge fails, this switch will be next in line to take over.
We can now take a look at the result with show spanning-tree vlan 10. This is the same as the show spanning-tree command we’ve been using. It’s just limiting the output to VLAN 10 information only.
We can indeed see that this is the root bridge for VLAN 10.
Let’s do the same for VLAN 20. You can see here that some other switch is the root bridge for VLAN 20. The local bridge priority is a little worse than the root bridge.
Quiz
Question 10 here is the big one for you to think about. I have faced this question in the real world, and it’s likely that you will too. You will need to put in some additional research to find the answer.
Labs
We have a two-part lab today.
In the first part, you need to implement RSTP, and add general enhancements.
In part 2, someone has broken the topology. You need to find the fault, and repair it.
End Scene
We’re now going to move on from spanning-tree. Head on over to the next video, which looks at bundling multiple links into a single Etherchannel.