Rapid Spanning Tree (RSTP)

Nowadays we see more and more routing in our networks. Routing protocols like OSPF and EIGRP are much faster than spanning tree when they have to deal with changes in the network. To keep up with the speed of these routing protocols, another flavor of spanning tree was created…rapid spanning tree.

Rapid spanning tree is not a revolution of the original spanning tree but an evolution. Behind the scenes, some things have been changed to speed up the process, configuration-wise it’s the same as what you have seen so far. I will refer to the original spanning tree as “classic spanning tree”.

Let’s dive into rapid spanning tree and we’ll see what the differences are with the classic spanning tree. Take a look at the picture below:

Remember the port states of spanning tree? We have a blocking, listening, learning, and forwarding port state. This is the first difference between spanning tree and rapid spanning tree. Rapid spanning tree only has three port states:

• Discarding
• Learning
• Forwarding

You already know about learning and forwarding but discarding is a new port state. Basically, it combines the blocking and listening port states. Here’s a nice overview:

Do you remember all the other port roles that spanning tree has? Let’s do a little review, and I’ll show you what is different for rapid spanning tree:

The switch with the best bridge ID (priority + MAC address) becomes the root bridge. The other switches (non-root) have to find the shortest cost path to the root bridge. This is the root port. Nothing new here, this works the same for rapid spanning tree. The next step is to select the designated ports:

On each segment, there can be only one designated port, or we’ll end up with a loop. The port will become the designated port if it can send the best BPDU. SW1 as a root bridge will always have the best ports so all of interfaces will be designated. The fa0/16 interface on SW2 will be the designated port in my example because it has a better bridge ID than SW3. There’s still nothing new here compared to the classic spanning tree. The interfaces that are left will be blocked:

SW3 receives better BPDUs on its fa0/16 interface from SW2, and thus it will be blocked. This is the alternate port, and it’s still the same thing for rapid spanning tree. Let me show you a new example with a port state that is new for rapid spanning tree:

Here is a new port for you. Take a look at the fa0/17 interface of SW2. It’s called a backup port, and it’s new for rapid spanning tree. You are very unlikely to see this port on a production network, though. Between SW2 and SW3, I’ve added a hub. Normally (without the hub in between) both fa0/16 and fa0/17 would be designated ports.

Because of the hub, the fa0/16 and fa0/17 interface on SW2 are now in the same collision domain. Fa0/16 will be elected as the designated port, and fa0/17 will become the backup port for the fa0/16 interface. The reason that SW2 sees the fa0/17 interface as a backup port is because it receives its own BPDUs on the fa0/16 and fa0/17 interfaces and understands that it has two connections to the same segment. If you remove the hub, the fa0/16 and fa0/17 will both be designated ports, just like the classic spanning tree.

Something else that is different is the BPDU, take a look:

The BPDU is different for rapid spanning tree. In the classic spanning tree, the flags field only had two bits in use:

• Topology change.
• Topology change acknowledgment.

All bits of the flag field are now used. The role of the port that originates the BPDU will be added by using the port role field, it has the following options:

• Unknown
• Alternate / Backup port.
• Root port.
• Designated port.

This new BPDU is called a version 2 BPDU. Switches running the old version of spanning tree will drop this new BPDU version. In case you are wondering…rapid spanning tree and the old spanning are compatible! Rapid spanning tree has a way of dealing with switches running the older spanning tree version.

Let’s walk through the other stuff that has been changed:

BPDUs are now sent every hello time. Only the root bridge generated BPDUs in the classic spanning tree, and those were relayed by the non-root switches if they received it on their root port. Rapid spanning tree works differently…all switches generate BPDUs every two seconds (hello time). This is the default hello time, but you can change it.

The classic spanning tree uses a max age timer (20 seconds) for BPDUs before they are discarded. Rapid spanning tree works differently! BPDUs are now used as a keepalive mechanism similar to what routing protocols like OSPF or EIGRP use. If a switch misses three BPDUs from a neighbor switch, it will assume connectivity to this switch has been lost, and it will remove all MAC addresses immediately.

Rapid spanning tree will accept inferior BPDUs. The classic spanning tree ignores them. Does this ring a bell? This is pretty much the backbone fast feature of classic spanning tree.

Transition speed (convergence time) is the most important feature of rapid spanning tree. The classic spanning tree had to walk through the listening and learning state before moving an interface to the forwarding state. This took 30 seconds with the default timers. The classic spanning tree was based on timers.

Rapid spanning doesn’t use timers to decide whether an interface can move to the forwarding state or not. It will use a negotiation mechanism for this. I’ll show you how this works in a bit.

Do you remember portfast? If we enable portfast while running the classic spanning tree it will skip the listening and learning state and put the interface in the forwarding state right away. Besides moving the interface to the forwarding state it will also not generate topology changes when the interface goes up or down. We still use portfast for rapid spanning tree, but it’s now referred to as an edge port.

Rapid spanning tree can only put interfaces in the forwarding state really fast on edge ports (portfast) or point-to-point interfaces. It will take a look at the link type, and there are only two link types:

• Point-to-point (full duplex)
• Shared (half duplex)

Normally we are using switches, and all our interfaces are configured as full duplex, rapid spanning tree sees these interfaces as point-to-point. If we introduce a hub to our network, we’ll have half duplex, which is seen as a shared interface to rapid spanning tree.

Let’s take a close look at the negotiation mechanism that I described earlier:

Let me describe the rapid spanning tree synchronization mechanism by using the picture above. SW1 on top is the root bridge. SW2, SW3 and SW4 are non-root bridges.

As soon as the link between SW1 and SW2 comes up, their interfaces will be in blocking mode. SW2 will receive a BPDU from SW1, and now a negotiation will take place called sync:

After SW2 receives the BPDU from the root bridge, it immediately blocks all its non-edge designated ports. Non-edge ports are the interfaces that connect to other switches, while edge ports are the interfaces that have portfast configured. As soon as SW2 blocks its non-edge ports, the link between SW1 and SW2 will go into forwarding state. SW2 will now do the following:

SW2 will also perform a sync operation with both SW3 and SW4 so they can quickly move to the forwarding state.

Are you following me so far? The lesson to learn here is that rapid spanning tree uses this sync mechanism instead of the “timer-based” mechanism that the classic spanning tree uses (listening > learning > forwarding). I’m going to show you what this looks like on real switches in a bit. Let’s take a closer look at the sync mechanism. Let’s look at what happens exactly between SW1 and SW2:

At first, the interfaces will be blocked until they receive a BPDU from each other. At this moment, SW2 will figure out that SW1 is the root bridge because it has the best BPDU information. The sync mechanism will start because SW1 will set the proposal bit in the flag field of the BPDU. When SW2 receives the proposal, it has to do something with it:

SW2 will block all its non-edge interfaces and will start the synchronization towards SW3 and SW4. Once this is done, SW2 will let SW1 know about this:

Once SW2 has its interfaces in sync mode, it will let SW1 know about this by sending an agreement. This agreement is a copy of the proposal BPDU where the proposal bit has been switched off, and the agreement bit is switched on. The fa0/14 interface on SW2 will now go into forwarding mode. When SW1 receives the agreement, here’s what happens:

Once SW1 receives the agreement from SW2, it will put its fa0/14 interface in forwarding mode immediately.

What about the fa0/16 and fa0/19 interface on SW2?

The exact same sync mechanism will take place now on these interfaces. SW2 will send a proposal on its fa0/16 and fa0/19 interfaces to SW3 and SW4. SW3 and SW4 will send an agreement: