Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 18

RSTP Configuration and Rapid Convergence

Recommended resources

Hello! Welcome back to our module on Spanning Tree Protocol.

In our last lesson, we established a strong theoretical foundation, comparing legacy STP with RSTP. We saw that RSTP's main advantage is its dramatic improvement in convergence speed, achieved by replacing passive timers with an active, event-driven handshake mechanism.

This lesson will take that theory and apply it directly to the Cisco IOS command line. Our goal is to configure and verify RSTP and its rapid convergence mechanisms. As a solutions engineer, moving from the "what" and "why" to the "how" is a critical step. We will configure Cisco's implementation of RSTP, called Rapid PVST+, and use verification and debugging tools to see the protocol's rapid convergence features in action.

1. Configuring Rapid PVST+

While RSTP is an IEEE standard (802.1w), Cisco's implementation is Rapid Per-VLAN Spanning Tree Plus (Rapid PVST+). As the name implies, and similar to the PVST+ you know from your CCNA studies, it runs a separate instance of RSTP for each VLAN configured on the switch. This allows for per-VLAN load balancing by manipulating the root bridge for different VLANs, a common design pattern in enterprise networks.

Fortunately, enabling it is straightforward.

Master How to Configure Spanning-Tree Mode – Rapid PVST+

The following article from NetworkUstad provides a clear, practical guide to configuring and verifying Rapid PVST+. We will use it as our primary reference for the command-line interface.

Please read the sections 'Spanning-Tree Mode Configuration' and 'Step-by-Step Configuration Example'. Pay close attention to the global command used to enable Rapid PVST+ and the optional command for setting the root bridge priority.

As you just read, the primary configuration is a single global command:

Switch(config)# spanning-tree mode rapid-pvst

This command enables Rapid PVST+ for all VLANs on the switch.

For a stable topology, it is best practice to manually configure the root bridge placement. As you know, you can do this by setting a low priority value or by using the root primary macro. For example, to make a switch the root for VLAN 10:

Switch(config)# spanning-tree vlan 10 root primary

This command automatically sets the switch's priority to a value lower than the current root bridge's priority, ensuring it wins the election.

2. Verifying the RSTP Topology

Once configured, you need to verify that RSTP is running correctly and interpret the topology it has built. The show spanning-tree command is your main tool, but the output contains specific details that are unique to RSTP.

Let's continue with the same resource to explore the key verification commands.

Master How to Configure Spanning-Tree Mode – Rapid PVST+

Now, let's look at how to verify the configuration.

Review the 'Verification Commands (Enhanced for IOS XE)' section. Focus on the sample outputs for show spanning-tree summary and show spanning-tree vlan <vlan_number>.

The two most important commands are:

  • show spanning-tree summary: This gives you a quick overview, confirming that Rapid PVST is the active mode and listing the number of ports in each state.
  • show spanning-tree vlan <vlan_id>: This command provides detailed information for a specific VLAN.

When you analyze the output of show spanning-tree vlan ..., look for these key RSTP indicators:

  • Protocol: The output will explicitly state Spanning tree enabled protocol rstp.
  • Port Roles: You will see roles like Root, Desg (Designated), and crucially, Altn (Alternate). An Altn port is a key RSTP feature—it's a pre-calculated backup path to the root bridge, ready for immediate failover.
  • Port State: You'll see states like FWD (Forwarding) and BLK (Blocking). In RSTP, BLK corresponds to the Discarding state.
  • Port Type: Notice the Type column. For links between switches, you should see P2p. This indicates a "Point-to-Point" link type (derived from the full-duplex setting), which is a prerequisite for the rapid proposal-agreement handshake.
Spanning Tree Protocol Port Roles and States in Different Network Scenarios
An example of `show spanning-tree` output. Notice on SW3, Fa0/2 is the `Root` port in `FWD` state, while Fa0/1 is the `Altn` port in `BLK` state. This `Altn` port is the immediate backup if the root port fails.
Test your understanding!

Looking at the diagram above, if the link connecting SW1's Fa0/3 to SW3's Fa0/2 were to fail, what would happen to port Fa0/1 on SW3? How quickly would this happen and why?

Show answer

Port Fa0/1 on SW3, currently in the Altn BLK role, would almost instantly transition to become the new Root port and enter the FWD state. This happens very quickly (sub-second) because RSTP has already identified this port as the next best path to the root bridge. It does not need to wait for timers like Max Age or Forward Delay to expire. This is a primary benefit of RSTP's Alternate port role.

3. Observing the Rapid Convergence "Sync" Process

Now for the most interesting part: seeing the rapid convergence mechanism in action. In the last lesson, we discussed the proposal-agreement handshake. In RSTP terminology, this entire process is often called synchronization or the "Sync" process.

To understand how a switch handles a proposal, let's watch a short video segment that explains the theory of the sync process in a multi-switch topology.

CCNP ENCOR // RSTP Sync Process // ENCOR 350-401 Complete Course

This video from Jeremy's IT Lab explains the RSTP Sync Process, which is the core mechanism for rapid convergence. It covers the proposal-agreement exchange and, importantly, what a switch does with its other ports before it agrees to a proposal.

Watch from 03:33 to 09:15. This segment covers the simple two-switch proposal-agreement and then expands to a three-switch scenario, explaining how a switch must put its downstream non-edge ports into a discarding state (the 'sync' part) before agreeing to a superior proposal.

As the video explained, before a switch can accept a superior proposal on one port, it must ensure no temporary loops are created. It does this by transitioning all its other non-edge ports into the Discarding state. Once synchronized, it can safely send the Agreement and bring its new root port to Forwarding.

Now, let's see this exact process unfold on the command line in a lab environment. The following video uses debug commands to trace the sync process as links are brought online one by one.

CCNP ENCOR // RSTP Sync (LAB) / BPDU Filter // ENCOR 350-401 Complete Course

This lab video, also from Jeremy's IT Lab, is the practical demonstration of the theory we just reviewed. It uses debug spanning-tree synchronization to show the proposal and agreement messages in real-time.

This video walks through a 4-switch topology. I recommend watching the following key segments: Basic Handshake (01:32 - 04:10): Observe the initial proposal-agreement exchange between SW1 and SW2. Notice in the debug output how SW1 sends a proposal and SW2 receives a 'superior BPDU', makes its port a Root Port, and sends an agreement. Sync in Action (09:15 - 11:20): This is the most critical part. When the link between SW1 and SW3 is enabled, SW3 receives a superior proposal. Watch the debug output on SW3 carefully. You'll see a message syncing port G0/1 before it sends its agreement to SW1. This is the switch putting its downstream port into a discarding state to prevent a loop. Loop Resolution (12:08 - 13:34): When the final link is added, creating a physical loop, observe how SW4 makes a decision. It receives BPDUs on two ports and chooses the best path as its new Root Port, while placing the other port into the Alternate role (...blocked G0/1; it's now an alternate port).

The debugs in that lab video provide concrete proof of the RSTP mechanisms we've discussed. You can see the protocol actively negotiating the topology in real-time, rather than passively waiting for timers. This ability to trace protocol operations with debug commands is an invaluable skill for troubleshooting at the CCNP level.

Conclusion

Today, we bridged the gap between RSTP theory and practice. We saw how to enable Cisco's Rapid PVST+ and how to interpret the show spanning-tree output to verify its operation, paying special attention to the roles and port types that are unique to RSTP. Most importantly, we observed the sync process in action, confirming that RSTP's rapid convergence isn't magic—it's a well-defined, verifiable handshake.

Key Takeaways:

  • Cisco's implementation of RSTP is Rapid PVST+, which is enabled globally with the spanning-tree mode rapid-pvst command.
  • Verification using show spanning-tree will reveal RSTP-specific port roles like Alternate (Altn) and link types like Point-to-Point (P2p), which are essential for rapid convergence.
  • The proposal-agreement (sync) process can be observed with debug spanning-tree synchronization, providing a real-time view of how ports rapidly transition to the forwarding state.
  • A critical step in the sync process is that a switch must block its downstream non-edge ports before sending an agreement to prevent temporary loops.

Preview of the Next Lesson:

While Rapid PVST+ is a huge improvement over PVST+, it still requires one spanning-tree instance per VLAN. In a large campus network with hundreds of VLANs, this can place a significant load on switch CPUs. In our next lesson, we will analyze the operation and configuration of Multiple Spanning Tree Protocol (MST), the IEEE standard designed to solve this scalability problem by grouping multiple VLANs into a single spanning-tree instance.