Rapid PVST+ and advanced STP features

Rapid Spanning-Tree (802.1w)

Over the years, Spanning Tree Protocol (STP) has gained improvements that make it faster and more efficient. Those improvements were brought together in a newer STP standard called Rapid Spanning-Tree, or RSTP, standardized by the IEEE as 802.1w.

RSTP works similarly to legacy 802.1D STP, but it converges much faster. In most cases, it converges within about 6 seconds (this doesn’t apply to ports that aren’t connected to another switch), compared to 802.1D’s 30 seconds (based on the Forward Delay timer). RSTP can transition a port to forwarding quickly using the Proposal/Agreement mechanism. For the CCNA 200-301 v1.1 exam, you don’t need the deep mechanics of this process, but you should recognize the term and its purpose.

Another important change is that RSTP (802.1w) uses slightly different port roles and port states:

• RSTP does not use the Listening state; it transitions through Learning instead.
• RSTP combines the legacy Blocking and Listening behavior into a single state called Discarding.
• The legacy Non-Designated Port role is renamed to the Alternate Port.

These are the RSTP port roles and port states you’ll need for the CCNA 200-301 v1.1 exam. The table below summarizes them and their behavior.

Please study and memorize the Table below for the CCNA 200-301 v1.1 exam

RSTP Port Role	RSTP Port State	Behavior
Alternate Port	Discarding	Not sending Data Frames and discarding received Data Frames but still listening for and processing BPDUs.
Alternate Port	Learning	Learning and storing MAC Addresses and BPDUs but still discarding Data Frames.
Root Port	Forwarding	Single port that is closest to the Root Bridge sending/processing Data Frames and BPDUs
Designated Port	Forwarding	Sending/processing Data Frames and BPDUs

As you can see in the table above, RSTP (802.1w) has 3 Port States (Discarding, Learning and Forwarding) compared to STP having 5 (Disabled, Blocking, Listening, Learning and Forwarding).

Rapid Per-VLAN Spanning-Tree (Rapid PVST+)

802.1D and 802.1W are the IEEE industry-standard versions of STP. Cisco also developed proprietary STP variants.

• The first Cisco version was Per-VLAN Spanning-Tree (PVST+), modeled after 802.1D.
• PVST+ was later superseded by Rapid PVST+, which is essentially PVST+ with the faster convergence and improvements of RSTP (802.1w).

For the CCNA 200-301 v1.1 exam and for the remainder of our discussion on STP, we will strictly be focusing on Rapid PVST+ and from this point forward, whenever “STP” is mentioned, unless stated otherwise, you can assume that it is in reference to the Cisco Proprietary Rapid PVST+ version.

As the name suggests, Cisco’s Per-VLAN implementation runs a separate spanning-tree instance for each VLAN. This gives you flexibility in root bridge placement. For example, a switch can be the root bridge for one VLAN but not for others by adjusting the bridge priority for the STP instance associated with a particular VLAN.

 

In the image above, three switches are connected to each other and running Rapid PVST+. VLANs 1, 10, 20, and 30 are configured on all three switches, and the links between the switches are trunks. Each physical trunk carries multiple VLANs, which are shown logically as multi-colored lines.

• SW1 has a lower bridge priority for VLAN 1 and VLAN 10, so it becomes the root bridge for those VLANs.
• SW2 has a lower bridge priority for VLAN 20 and VLAN 30, so it becomes the root bridge for those VLANs.

You can see the traffic-flow impact by looking at SW3:

• On SW3, the root port for VLAN 1 and VLAN 10 points toward SW1.
• That same physical link to SW1 is blocking traffic for VLAN 20 and VLAN 30.

The opposite is true for the link between SW3 and SW2:

• On SW3, the root port for VLAN 20 and VLAN 30 points toward SW2.
• That same physical link to SW2 is blocking traffic for VLAN 1 and VLAN 10.

This design is called PVST VLAN load balancing. The key idea is that SW3 can use both uplinks (to SW1 and to SW2) at the same time, depending on the VLAN. If you had only one root bridge for all VLANs, SW3 would block all VLANs on its secondary uplink.

Primary and secondary root bridge

You can also plan for redundancy by choosing a primary and secondary root bridge per VLAN:

• Configure one switch as the Primary root bridge for some VLANs by giving it the lowest bridge priority for those VLANs.
• Configure it as the Secondary (backup) root bridge for other VLANs by giving it the 2^nd lowest bridge priority for those VLANs.
• Configure another switch with the opposite priorities (primary for the other VLANs, secondary for the first set).

This approach lets you keep redundancy while still using both distribution switches actively.

For example, if SW1 and SW2 are distribution switches and SW3 is an access switch, you typically don’t want SW3 to become the root bridge if SW1 fails. Access switches are often lower-performance models than distribution switches. That’s why it’s best practice to explicitly set bridge priority values on the switches you want to be root.

Remember: lower bridge priority is better.

 

Also note these bridge priority rules:

• Bridge priority values can only be configured in multiples of 4096.
• 0 (zero) is the lowest (most preferred) value.
• 4096 is the 2^nd lowest value.
• The highest (least preferred) bridge priority value is 61440.

In Cisco’s PVST+ implementation, the bridge priority is also appended with the VLAN ID. For example, if you configure a bridge priority of 4096 for VLAN 2, the switch will show an actual priority of 4098 (4096 + 2). This is the System ID Extension, and it helps keep the bridge priority values unique per VLAN instance on a switch.

Advanced STP features

STP includes features that can optimize convergence and, in some cases, improve security. Many of these features existed in 802.1D, but here we’ll discuss them in the context of Rapid PVST+.

These features are applied on a per-port basis, although some can be applied to all ports.

Portfast

Suppose you connect a PC to a switch and you need it to access the network immediately. With default STP behavior, the port may take up to 30 seconds (the Forward Delay timer) to transition to forwarding. For some PCs, servers, and other endpoints, that delay is unacceptable.

Portfast solves this by allowing a port to bypass the Forward Delay timer and move directly into forwarding.

Portfast is intended for ports where devices that are not Switches connect - ports that should not be able to create a Layer 2 loop. In Rapid PVST+ terminology, these are called Edge Ports.

BPDU Guard

Some ports are not intended to connect to other switches (for example, edge ports). This might be for security reasons (preventing an untrusted device from connecting a switch) or simply to prevent accidental mis-cabling that could create a Layer 2 loop.

BPDU Guard protects these ports by shutting down a port that receives a BPDU when the feature is enabled. Since switches send BPDUs, receiving a BPDU is a strong sign that another switch has been connected.

When BPDU Guard triggers, the port is placed into err-disabled mode. Once a port is err-disabled, a network administrator must access the switch to re-enable it.

It is also important to note that there are other events that could cause a port to be placed into the “err-disabled” state. Another common example would be due to a link that is “flapping” or constantly toggling between the “up” and “down” state within a short period of time.

BPDU Guard is commonly used together with Portfast. In fact, it’s best practice to enable BPDU Guard on Portfast (edge) ports, since those ports should not have switches connected to them.

BPDU Filter

In some situations, you may not want a port to send or receive BPDUs. For example, on edge ports, an endpoint could potentially read BPDUs for reconnaissance.

BPDU Filter prevents BPDU exchange on a port:

• It ignores BPDUs received on that port.
• It does not send BPDUs out of that port.

This keeps BPDUs away from edge devices. It can also be viewed as a security improvement, since endpoints such as PCs, printers, and servers don’t need BPDUs.

You could technically use BPDU Filter to prevent other switches from connecting, but this is not recommended because there is a high risk of creating a Layer 2 loop, especially when redundant links exist.

Root Guard

In a typical design, distribution switches are intended to be the root bridges. Without additional controls, a misconfiguration - or a malicious device - could introduce a switch with a lower (better) bridge priority (or bridge ID) and take over as the root bridge.

Root Guard prevents that by protecting a port from accepting a new root. When Root Guard is enabled on a port, the port is temporarily disabled if it receives a BPDU advertising a better root.

• A BPDU that advertises a better root is called a Superior BPDU.
• When a superior BPDU is received on a Root Guard port, the port enters the Root Inconsistent state.
• In Root Inconsistent, the port discards frames and does not forward.
• When the superior BPDUs stop, the port automatically returns to forwarding.

This helps ensure that the intended root bridges keep their role.

Loop Guard

Loop Guard helps prevent a Layer 2 loop caused by an alternate port incorrectly transitioning to forwarding.

The key risk scenario is a unidirectional link, where a cable between switches works in only one direction (either transmit or receive). For example, if there is a partial fracture or break in the middle of the fiber cable that prevents the light signal from making it all the way through, the port remains up however, data is only carried in one direction, which is the channel within the fiber cable that is still in tact.

In a redundant topology, if the blocked link (alternate port) stops receiving BPDUs due to a unidirectional failure, it may incorrectly assume it should transition to forwarding - creating a loop.

Loop Guard prevents this by monitoring BPDU reception:

• If an alternate port configured with Loop Guard stops receiving BPDUs, it moves into the Loop Inconsistent state.
• In Loop Inconsistent, the port discards data frames and does not forward.
• When BPDU reception resumes (for example, after the link is repaired), the port returns to its original blocking behavior.