Rapid Spanning-Tree Configuration

Lessons Discussion
21

Hello Josh

First of all, there is no hard limit to the diameter of an RSTP topology. It’s not like if you have X bridges it will work, but if you have X+1 it will fail. The IEEE recommendation is 7 bridges. This means that they guarantee that the feature will function flawlessly with a diameter of 7 or fewer bridges. But this is an extremely conservative value, and it doesn’t mean it won’t work with more, with the appropriate precautions and tweaks.

There is however one parameter that may limit the actual topology by default, and that is the Message Age. This is a value found within BPDUs that starts off at 0 when it is sent from the root bridge, and is incremented by one every time it passes through a non-root bridge. Once the Message Age reaches the Max Age value, the BPDU is discarded. It works kind of like a TTL found in IP packets, to prevent BPDUs from being relayed forever in a topology.

By default, Max Age is 20, so by default, you cannot have a diameter of more than 20 switches in your topology. Max Age can be configured to up to 40, so theoretically, the maximum diameter you can have is 40 switches. But I believe that RSTP will break down well before that size.

Now with your particular case, it looks like it’s taking too long for BPDUs to reach the switch, and previously received BPDU info is becoming expired. This occurs when the Max Age has elapsed without any BPDUs arriving. (Note, this usage of Max Age is different than that of Message Age).

Some things to keep in mind:

  • According to papers such as this one, the reconvergence of RSTP can surpass 10 seconds in the event that you have a diameter of 10 bridges. Note that performance degrades as diameter increases. So what is the limit? It depends upon what delays you can tolerate in your topology.
  • According to IEEE, a ring topology is not recommended for RSTP, but a meshed topology is much more preferable. The protocol performs better in such scenarios.

From my understanding, you are using a ring topology, with 19 switches, which seems to be at the very edge of RSTPs operational capabilities. First, consider increasing Max Age, to simply make the topology operate, and secondly, to improve convergence, if possible, consider modifying the topology to a meshed one.

This makes sense when everything is working correctly, but the real test of the protocol is during a failure, how fast and if it reconverges.

I hope this has been helpful!

Laz

22

Hi team,

For rapid-pvst, how do we implement these two commands:

  1. spanning-tree portfast edge default
  2. spanning-tree portfast edge bpduguard default

Do we implement them at the global level? Or interface level? If on the global level, is there anything additional that is required to be implemented on the interface level?

Many thanks.

23

Hello NetworkGuy

Keep in mind that Rapid PVST+ is simply a Cisco proprietary protocol that delivers a separate instance of RSTP (IEEE 802.1w) for each VLAN. In essence, it is the same as RSTP. Indeed, Rapid PVST+ is the default STP version on all modern Cisco switches. And actually, on Cisco switches, you can’t enable RSTP alone. You only have the option of enabling Rapid PVST+ (simply called rapid-pvst on the Cisco IOS), which is essentially RSTP on a per-VLAN basis.

Take a look at this NetworkLessons Note on the topic for more info.

Now the spanning-tree portfast edge command can be applied either globally or on an interface.
When applied globally, the syntax is as follows:

spanning-tree portfast edge { bpdufilter default | bpduguard default | default }

When applied on an interface, the syntax is like so:

spanning-tree portfast edge [ disable | trunk ]

The interface configuration always overrides the global configuration. If no such command appears in the interface configuration, then the global configuration takes effect. Take a look at the following links to the related command reference:

I hope this has been helpful!

Laz

1 Like
24

This is very helpful. Thank you.

1 Like
25

Hi Rene,

We have a network with running PVST. There is a aggregation switch layer( Two aggregation switches connected with trunk port) and all access switches are connected to this aggregation switches. One of the aggregation switches is root bridge. For our requirement we need to change the spanning tree protocol PVST to rapid PVST only on these aggregation switches. Can it cause for any issues ?

26

Hello ChaD

Just for clarity, we are talking about PVST+ and Rapid PVST+ as opposed to plain PVST. Although we often write it without the “+” it’s important to be clear. PVST without the “+” was a proprietary STP protocol that used ISL instead of the standard 802.1Q VLAN tags.

Switching from PVST+ to Rapid-PVST+ on your aggregation switches should generally not cause any major issues, since these two protocols can interoperate. Rapid PVST+ switches can communicate with PVST+ switches, ensuring network stability and loop prevention. However, it’s important to note that the rapid convergence benefits of Rapid PVST+ are only fully realized when all switches in the network support it. When operating with PVST+ switches, the convergence times will be closer to those of standard PVST+.

You mentioned that you will change to Rapid PVST+ only on the two aggregation switches, correct? If that is the case, and the rest of your switches are running plain PVST+, it will work, but you will see no benefits from the “rapid” characteristic of the protocol. Is there a reason you want to apply this change only to the aggregate switches? Let me know so we can further discuss other options.

Finally, just keep in mind that any changes, even such small ones, may introduce a momentary disruption in service due to STP reconvergence times (or a longer duration disruption if something goes wrong) so always make sure you are making changes during a maintenance window where the impact of failures will be reduced. And always have a rollback plan, to return the network to its previous operational status in the event that your changes cause unexpected disruptions.

I hope this has been helpful!

Laz

27

Hello lagapidis,

Thanks for the shared details. We were able to successfully change the spanning tree mode of two aggregation switches to RPVST+ and its working fine with other access switches running PVST+ without any issue.

28

Hello ChaD

Great to hear that everything is working as expected! Thanks for keeping us updated, it’s always nice to hear about people’s successes.

Thanks again!

Laz

29

Hello Team,

image
image1742×400 40.6 KB

In this snippet, the statement supposed to be like " SW2 thought it was the root bridge. However, it received a superior BPDU on its fa0/14 interface from SW1. Hence, the fa0/14 interface was changed to the root port. "

I had gone through the entire discussion on the RSTP forum, and then I got some understanding of the concepts until I saw this statement.

I would appreciate it if you could clarify my doubts.

30

Hello Sathish

You are correct. The statement should read:

“SW2 thought it was the root bridge, so it set its Fa0/14 port as designated. However, it received a superior BPDU on this interface. Thus it no longer considers itself as the root bridge and changes the role of Fa0/14 to the root port.”

I will let Rene know to review it and make any necessary corrections. Thanks for pointing that out!

Laz

1 Like