Rapid spanning-tree is not a complete overhaul of the original Spanning-Tree, but rather an evolution. While some internal processes have been optimized for speed, the configuration remains similar to what you're familiar with. I'll refer to the original Spanning-Tree as just "STP."
Let's begin our exploration by examining how RSTP differs from the classic STP. Check out the image below:
Do you recall the port states in STP? There are blocking, listening, learning, and forwarding states. This is one of the key differences between STP and Rapid Spanning-Tree Protocol (RSTP). RSTP uses only three port states, vice four:
- Discarding
- Learning
- Forwarding
While you're already familiar with learning and forwarding, the discarding state is rather new. It essentially merges both the blocking and listening states. Here's a concise overview:
| **Classic Spanning Tree** | **Rapid Spanning Tree** | **Port Active in Topology?** | **Learns MAC Addresses?** |
|---------------------------|-------------------------|------------------------------|----------------------------|
| Blocking | Discarding | No | No |
| Listening | Discarding | Yes | No |
| Learning | Learning | Yes | Yes |
| Forwarding | Forwarding | Yes | Yes |
Do you recall the various port roles in spanning tree? Let’s take a moment to review them and highlight the differences for rapid spanning tree:
Only one designated port is allowed per segment to prevent loops within the network. A port is designated if it can send the best BPDU. Since SW1 is the root bridge, all of its interfaces will be designated. In this example, the Fa0/16 interface on SW2 becomes the designated port because it has a superior bridge ID compared to SW3. This process remains consistent with classic STP principles. The remaining interfaces will be blocked:
SW3 receives superior BPDUs on its Fa0/16 interface from SW2, which leads to it being blocked because SW2 has a lower bridge IT, indicating that it is a better choice for forwarding traffic. This is important because in spanning-tree protocols, only one designated port can forward traffic on a segment to prevent loops. Allowing multiple ports to forward traffic could create a loop, leading to broadcast storms and network congestion.
Since SW2 can provide a better path to the root bridge, SW3s port must be blocked to maintain stability. This ensures that there is a single active path to the root bridge, minimizing the risk of loops and ensuring efficient traffic flow throughout the network. By blocking SW3s port, the network can maintain a stable and predictable topology.
Let's look at an example with a port state that is new for RSTP:
Here's a new port for you to consider: the Fa0/17 interface on SW2, known as a backup port, which is specific to RSTP; however, you're unlikely to encounter this port type in a production environment.
Why would you be unlikely to encounter this type of port in a production environment?
Well, because the Fa0/17 interface is only relevant in scenarios where there are redundant connections to a single segment, typically involving a hub. In modern networks, switches are often interconnected directly without the use of hubs, reducing the need for backup ports. As a result, designated ports are more commonly used, making backup ports increasingly rare in contemporary network designs.
In this scenario, I've added a hub between SW2 and SW3. Normally, without the hub, both Fa0/16 and Fa0/17 would be designated ports.
With the hub in place, the Fa0/16 and Fa0/17 interfaces on SW2 now share the same collision domain. As a result, Fa0/16 is elected as the designated port, while Fa0/17 becomes the backup port for Fa0/16. SW2 recognizes Fa0/17 as a backup because it receives BPDUs on both interfaces, indicating two connections to the same segment. If you were to remove the hub, both Fa0/16 and Fa0/17 would effectively revert to being designated ports, similar to how it operates in a classic STP-operated environment.
However, something else that is different about the BPDU? Can you spot it? Take a look:
The BPDU structure completely changes with RSTP. In classic STP, the flags field has only two active bits:
- Topology change
- Topology change acknowledgement
With RSTP, all bits of the flags field are utilized. The port role of the originating switch is now included in the BPDU, featuring the following options:
- Unknown
- Alternate/Backup Port
- Root Port
- Designated Port
This new structure is referred to as a version 2 BPDU. Switches using the older version of STP will discard these new BPDUs; however, it's worth noting that RSTP maintains compatibility with classic STP incorporating mechanisms to manage interactions with switches that operate on the older protocol.
Let's take a quick minute to explore the key changes in the Rapid Spanning-Tree Protocol (RSTP)
BPDUs are now transmitted every hello time. In classic STP, only the root bridge generated BPDUs, which were relayed by non-root switches if received on their root port. In RSTP, all switches actively generate BPDUs every two seconds by default, although the interval can be adjusted.
In classic STP, BPDUs had a max age timer of 20 seconds before being discarded. RSTP utilizes BPDUs as a keepalive mechanism, similar to routing protocols like OSPF and EIGRP. If a switch fails to receive three consecutive BPDUs from an adjacent neighbor, it assumes connectivity has been lost and promptly removes all associated MAC addresses.
Another significant difference is that RSTP accepts inferior BPDUs, whereas classic STP ignores them. This behavior echoes the BackboneFast feature of classic STP.
The transition speed, or convergence time, is one of RSTPs standout features. In classic STP, an interface has to progress through the listening and learning states before moving to forwarding, often taking 30 seconds with default timers set. RSTP eliminates reliance on timers for this process, instead using a negotiation mechanism, which I will explain shortly.
Do you remember PortFast? In classic STP, enabling PortFast allows an interface to skip the listening and learning states, moving directly to forwarding. Additionally, it prevents topology changes when the interface goes up or down. While RSTP still employs PortFast, it is now termed an "edge port."
RSTP can rapidly place interfaces into the forwarding state, but this is primarily applicable to edge ports (PortFast) or point-to-point interfaces. The protocol identifies two link types:
- Point-to-point (full duplex)
- Shared (half-duplex)
In typical switch-based environments, interfaces operate in full duplex, which RSTP recognizes as a point-to-point (P2P); however, introducing a hub creates a half-duplex scenario, which RSTP views as a shared interface.
Now, let's take a closer look at the negotiation mechanism I mentioned earlier.
Let's explore the synchronization mechanism of Rapid Spanning-Tree using the diagram above. In this scenario, SW1 is the root bridge, while SW2, SW3, and SW4 are non-root bridges.
Once the link between SW1 and SW2 is activated, their interfaces initially enter blocking mode. SW2 receives a BPDU from SW1, prompting a negotiation process known as synchronization.
During this sync process, SW2 assesses the information in the BPDU, including the root bridge ID and its own port role. This evaluation allows SW2 to determine the best path to the root bridge and make informed decisions about transitioning port states.
As soon as the link between SW1 and SW2 comes back up, their interfaces will be in blocking mode. SW2 will receive a BPDU from SW1, and now a negotiation will take place and here's where the sync comes into play:
With the non-edge ports blocked, the link between SW1 and and SW2 transitions into forwarding state. SW2 will then take the following actions:
1. Evaluate Port States: SW2 assesses its remaining ports, determining which ones can become designated or root ports based on the BPDUs received.
2. Update Forwarding Decisions: SW2 updates its forwarding table to reflect the new topology, ensuring data traffic is efficiently routed through the network.
3. Generate and Send BPDUs: SW2 will generate its own BPDUs, informing other switches about its status and the network topology.
4. Monitor Connectivity: SW2 continuously monitors the BPDUs from its neighbors to maintain network stability. If it fails to receive BPDUs from any switch, it will react accordingly, potentially transitioning ports to blocking states.
5. Facilitate Convergence: Through this process, SW2 contributes to rapid convergence in the network, quickly adapting to any changes and minimizing downtime for traffic flows.
SW2 will also initiate a sync operation with both SW3 and SW4, enabling them to transition rapidly to the forwarding state.
Are you following along? The key takeaway here is that Rapid Spanning Tree Protocol (RSTP) employs this sync mechanism instead of the timer-based approach used by Classic Spanning Tree Protocol (CST), which follows the sequence of listening, learning, and forwarding. I'll demonstrate how this works on actual switches shortly.
Now, let’s dive in deeper into the sync mechanism, focusing on the interactions between SW1 and SW2:
Initially, the interfaces will remain blocked until they exchange BPDUs. At this point, SW2 recognizes SW1 as the root bridge due to its superior BPDU information. The sync mechanism is then initiated when SW1 sets the proposal bit in the BPDU's flag field. Upon receiving the proposal, SW2 must take specific actions:
SW2 will block all its non-edge interfaces and begin the synchronization process with SW3 and SW4. After completing this synchronization, SW2 will notify SW1 about the status change:
Once SW2 has its interfaces in sync mode, it will inform SW1 by sending an agreement. This agreement is a modified version of the original proposal BPDU, where the proposal bit is turned off and the agreement bit is activated. Consequently, the Fa0/14 interface on SW2 will transition to forwarding mode. When SW1 receives this agreement, the following occurs:
Once SW1 receives the agreement from SW2, it will immediately set its Fa0/14 interface to forwarding mode. As for the Fa0/16 and Fa0/19 interfaces on SW2, these ports will also be affected by the sync process. Since SW2 has blocked its non-edge interfaces and established synchronization with SW1, these ports will remain in a blocked state until they can determine a valid path to the root bridge. Only after successful negotiations with neighboring switches will they transition to forwarding mode.
The same sync mechanism will now occur on the Fa0/16 and Fa0/19 interfaces. SW2 will send a proposal BPDU on these interfaces to SW3 and SW4. Upon receiving the proposal, both SW3 and SW4 will evaluate the information and respond with their own agreements. This agreement indicates that they have synchronized their states, allowing SW2 to update the status of its Fa0/16 and Fa0/19 interfaces to forwarding mode once the agreements are confirmed.
Since SW3 and SW4 do not have any other interfaces, they will promptly send an agreement back to SW2. This agreement confirms that they are ready to transition to the forwarding state. As a result, SW2 can then update the status of its Fa0/16 and Fa0/19 interfaces to forwarding mode, completing the synchronization process across the network.
SW2 will transition its Fa0/16 and Fa0/19 interfaces to forwarding state, completing the sync process. This mechanism relies on a few quick messages, making it significantly faster than the timer-based approach of classic STP!
Now, let’s explore three more features of Rapid Spanning-Tree Protocol (RSTP):
1. UplinkFast: In classic spanning tree, you had to manually enable UplinkFast. With RSTP, UplinkFast is enabled by default, allowing a switch to immediately transition its alternate port to forwarding mode if it loses its root port.
2. Topology Change Mechanism: Unlike classic spanning tree, where any link failure triggers a topology change, RSTP only considers the transition of non-edge interfaces (those connecting to other switches) to the forwarding state as a topology change. When a topology change occurs, the following happens:
- A topology change timer is activated, set to twice the hello time for all non-edge designated and root ports.
- The MAC address tables on these ports are flushed.
- As long as this timer is active, BPDUs sent out from these ports will have the topology change bit set.
3. Compatibility with Classic Spanning Tree: RSTP is designed to work alongside classic spanning tree networks. When RSTP-enabled switches receive BPDUs from classic spanning tree switches, they can process them appropriately, ensuring smoother transitions and updates.
When a neighbor switch receives a BPDU with the topology change bit set, it will clear its MAC addresses on all interfaces except the one that received the BPDU. It will then start its own topology change timer and propagate BPDUs on its designated and root ports, also marking them with the topology change bit. This streamlined approach allows for quicker convergence and improved network stability.
Instead of propagating a topology change all the way to the root bridge like classic spanning tree, RSTP quickly floods the change throughout the network. This efficient mechanism ensures that all switches receive timely updates. For a detailed breakdown of how this topology change process operates, check out this full tutorial.
Lastly, let’s discuss compatibility. The key point is that Rapid Spanning-Tree (RSTP) and classic STP can work together; however, when RSTP communicates with a switch running STP, the advanced features that enhance RSTP's speed will be disabled.
In our example, RSTP operates between SW1 and SW2, while the connection between SW2 and SW3 defaults to classic STP.
Ready to move beyond theory? In the next lesson, I’ll demonstrate the configuration and debugging of everything we've covered so far.
Until then, Happy RSTP'ing!
Rate This Article
Thanks for reading: RSTP (Rapid Spanning-Tree), Sorry, my English is bad:)