Rapid Spanning-Tree Configuration

Hi Shanmugasiva,
I suspect this simply might be a case of label in the picture not matching the configured IOS. In one of the outputs from Switch A it says “This bridge is the root” and it lists the Root ID of 4097.

Notice, the same thing is true for Switch B. It says in the text output it says its priority is 8193, but the label in the picture shows 32768.

Good catch!

--Andrew

Hello Rene,
I have configured a lab connecting three switches on gns3 (SW1,SW2 and SW3). SW1 is the Root switch. They are connected like this:
SW1(e1/3-DP)>>>SW2(e1/3-RP)
SW1(e3/0-DP)>>>SW3(e3/2-RP)
SW2(e3/0-DP)>>>SW3(e3/3-ALT/BLK)
The issue is that as soon as i admin down the port on SW3(e3/2-RP), the other port e3/3 becomes the new RP. This is expected. But when i bring back the port up on SW3(e3/2), the port doesn’t becomes automatically RP again, because its far end device port SW1 (e3/0) is going into err-disabled state, essentially the moment that i admined down the port on SW3(e3/2). Hence, in order e3/2 of SW3 reclaim again the RP role, i have to manually bounce the interface e3/0 of SW1. After that e3/0 of SW1 becomes UP, and e3/2 of SW3 becomes RP again. Is this expected behavior? Thank you in advance.

Ok i think i have found the issue here. I have configured udld mode aggressive on all the ports. So that is why when i admin down the port on SW3(e3/2-RP), the Root switch port SW1 (e3/0) goes into err-disable state! Since Root Switch port e3/0 will not receive any traffic, it goes into err-disable state. Finally, i just needed to bounce it, to work as before.

Also, when i tried to admin down the port on the Root Switch (SW1-e3/0) i noticed that the far end port doesn’t go to the error-disable state, even though the far end port (SW3-e3/2) is configured with udld mode aggressive. But then i remember that this should be expected, since i am admining down a port on a Root Switch, and the root switch is not sending BPDUs ever, so that is why SW3-e3/2 doesn’t go also into err-disable state!

Hello Angelos

Thanks so much for sharing your experiences with us. It’s great to learn from the learning experiences of others as it helps us all to identify similar situations in our studies and our jobs.

Once again, greatly appreciated!

Laz

Hi .

Whats P2p in type ?


whats the meaning of : SW3#
RSTP(1): updt rolesroot port Fa0/14 is going down
RSTP(1): Fa0/16 is now root port . whats updt rolesroot

SW2#
RSTP(1): updt roles, root port Fa0/14 going down
RSTP(1): we become the root bridge
RSTP(1): updt roles, received superior bpdu on Fa0/16
RSTP(1): Fa0/16 is now root port

now sw2 is he root bridge not SW1 ?


SW2#
RSTP(1): initializing port Fa0/2
RSTP(1): Fa0/2 is now designated
*Mar 1 04:08:32.931: %LINK-3-UPDOWN: Interface Fast Ethernet/2, changed state to up

how fa0/2 is designated in fa0/2 ?

Hello Abdul

Take a look at this post:

Based on the debug output you have displayed here, it looks like on SW3, Fa0/14 was originally the root port of the switch, but it is “going down”. Therefore, a new root port had to be designated, and it looks like the switch chose Fa0/16 for the new root port.

On SW2, it looks like Fa0/14 went down on this switch as well. The initial result was that SW2 made itself the root bridge. But in the meantime, it received a superior BPDU on Fa0/16, which informed SW2 that another switch will become the root. Therefore, SW2 changes its own role (it is no longer the root bridge), and thus it must choose a root port, choosing Fa0/16 for this role.

So to answer your question, no SW2 is not the root bridge. It temporarily became the root bridge until it received a superior BPDU. Remember that these events take place quite quickly and can occur in a different order each time. SW3 didn’t get a chance to become root bridge, but immediately received the appropriate BPDU on Fa0/16 to make that root port. While SW2 decided to become the root bridge until a superior BPDU is received, which it was. But these things happen so quickly that the order doesn’t really matter. For users, the quickness of reconvergence is still quite fast.

Fa0/2 is a new port that just came up. It becomes designated immediately simply because it didn’t receive a superior BPDU on that port.

I hope this has been helpful!

Laz

Thanks Really. The best explanation I have ever read!

Hello, new here
im trying to enable debug on these switches and keep on getting the error below on all three switches.im using packet tracer what am doing wrong ?.Thanks

S1>en
S1#debug spanning-tree events
          ^
% Invalid input detected at '^' marker.

S2>en
S2#debug spanning-tree events
          ^
% Invalid input detected at '^' marker.

Hello Bernard

Unfortunately, Packet Tracer doesn’t support all of the commands and features available on real Cisco devices. This is one example of unsupported commands. Alternatively, you can use the GNS3 emulator which includes all of the commands available in a particular IOS image, or a choice of several other emulators including Cisco CML. More info on these can be found at the following lesson. The lesson may refer to CCIE, but the same applies for all Cisco certifications:

I hope this has been helpful!

Laz

1 Like

Hi,

Stupid question, think I may have missed something but I understand that RSTP uses Discarding, learning and forwarding port roles however uses the sync/proposal mechanism for convergence and Edge Ports can go immediately to forwarding with PortFast. In which circumstances does it go through the port roles (Discarding, learning and forwarding)?

Hello Samad

One thing that we have to keep in mind when examining the port states of rapid spanning tree is the fact that we have no timers. You are correct that the states are Discarding, Learning, and Forwarding. How they relate to classic STP states can be seen in this lesson:

Now you bring up a good question. When does a port actually enter each state, and under what circumstances? Well, STP states are straightforward, because they are timer-based, and they take place in sequential order, except when you have portfast configured.

For rapid spanning tree, these states are associated with the synchronization mechanism used. Specifically, as soon as a link between two switches running rapid spanning-tree comes up, the interfaces are in blocking mode. As the first BPDUs are being exchanged, the ports go into the learning state. This learning state is momentary and exists until the BPDU sync process (proposal bit and agreement) are exchanged. Once that takes place, the port will go into the forwarding state.

If you configure an edge port, then no synchronization process takes place. Thus the port immediately goes into the forwarding state without the need to send and receive BPDUs with proposals and agreements.

Now keep in mind that RTP is backward compatible with STP. If it detects an STP switch on the other end of the link, it will go into a classic STP operation, with the normal STP timers for all the states.

I hope this has been helpful!

Laz

Hi ,

I’d really like some clarification on RSTP and if there is a maximum\default diameter.
There are multiple links that seems to have conflicting information.

Some saying that the max age time decrements each switch it travels through, others saying max diamter of 20-40. I can’t find anything concrete written by Cisco.

I’m currently trying to troubleshoot an issue with a large spanning tree ring on the cusp of 20 switches, and one of the sides has had a break which is basically worst case secnario, as there is now one leg with the last switch in 19th place.

Is there a maximum size by default for RSTP? i was under the impression that it would just negotiate root ports \ superior BPDU’s with it’s neighbour. But what i’m seeing is that it is constantly flapping between making itself root and designated.

RSTP

I have run a few debugs and this is what i’m receving.

Jan 11 2022 22:01:48.364 UTC: RSTP(150): Gi1/1 is now designated
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 150, port_id 128.1
Jan 11 2022 22:01:48.364 UTC: RSTP(210): Gi1/1 rcvd info expired
Jan 11 2022 22:01:48.364 UTC: RSTP(210): updt roles, information on root port Gi1/1 expired
Jan 11 2022 22:01:48.364 UTC: RSTP(210): we become the root bridge
Jan 11 2022 22:01:48.364 UTC: RSTP(210): Gi1/1 is now designated
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 210, port_id 128.1
Jan 11 2022 22:01:48.364 UTC: RSTP(303): Gi1/1 rcvd info expired
Jan 11 2022 22:01:48.364 UTC: RSTP(303): updt roles, information on root port Gi1/1 expired
Jan 11 2022 22:01:48.364 UTC: RSTP(303): we become the root bridge
Jan 11 2022 22:01:48.364 UTC: RSTP(303): Gi1/1 is now designated
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 303, port_id 128.1
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 303, port_id 128.9
Jan 11 2022 22:01:48.364 UTC: Found no corresponding dummy port for instance 303, port_id 128.9
Jan 11 2022 22:01:48.364 UTC: RSTP(303): Gi1/9 not in sync
Jan 11 2022 22:01:48.385 UTC: RSTP(150): updt roles, received superior bpdu on Gi1/1 
Jan 11 2022 22:01:48.385 UTC: RSTP(150): Gi1/1 is now root port
Jan 11 2022 22:01:48.385 UTC: Found no corresponding dummy port for instance 150, port_id 128.1
Jan 11 2022 22:01:48.385 UTC: STP[150]: Generating TC trap for port GigabitEthernet1/1
Jan 11 2022 22:01:48.385 UTC: RSTP(210): updt roles, received superior bpdu on Gi1/1 
Jan 11 2022 22:01:48.385 UTC: RSTP(210): Gi1/1 is now root port
Jan 11 2022 22:01:48.385 UTC: Found no corresponding dummy port for instance 210, port_id 128.1
Jan 11 2022 22:01:48.385 UTC: STP[210]: Generating TC trap for port GigabitEthernet1/1
Jan 11 2022 22:01:48.385 UTC: RSTP(303): updt roles, received superior bpdu on Gi1/1

and on the otherside i see similar, and disputes.

033478: Jan 11 12:04:19.464: RSTP(500): transmitting a proposal on Gi1/2
033479: Jan 11 12:04:19.474: RSTP(500): received an agreement on Gi1/2
033480: Jan 11 12:04:19.474: Found no corresponding dummy port for instance 500, port_id 128.2
033481: Jan 11 12:04:19.474: RSTP[500]: Gi1/2 dispute resolved
033482: Jan 11 12:04:19.995: RSTP(150): Gi1/2 Dispute!
033483: Jan 11 12:04:19.995: Found no corresponding dummy port for instance 150, port_id 128.2
033484: Jan 11 12:04:20.072: RSTP(210): transmitting a proposal on Gi1/2
033485: Jan 11 12:04:20.075: RSTP(210): received an agreement on Gi1/2
033486: Jan 11 12:04:20.075: Found no corresponding dummy port for instance 210, port_id 128.2
033487: Jan 11 12:04:20.075: RSTP[210]: Gi1/2 dispute resolved
033488: Jan 11 12:04:21.470: RSTP(500): Gi1/2 Dispute!
033489: Jan 11 12:04:21.470: Found no corresponding dummy port for instance 500, port_id 128.2
033490: Jan 11 12:04:21.501: RSTP(603): Gi1/2 Dispute!
033491: Jan 11 12:04:21.501: Found no corresponding dummy port for instance 603, port_id 128.2
033492: Jan 11 12:04:21.505: RSTP(603): transmitting a proposal on Gi1/2
033493: Jan 11 12:04:21.512: RSTP(603): received an agreement on Gi1/2
033494: Jan 11 12:04:21.512: Found no corresponding dummy port for instance 603, port_id 128.2
033495: Jan 11 12:04:21.512: RSTP[603]: Gi1/2 dispute resolved
033496: Jan 11 12:04:21.998: RSTP(150): transmitting a proposal on Gi1/2
033497: Jan 11 12:04:22.001: RSTP(150): received an agreement on Gi1/2
033498: Jan 11 12:04:22.001: Found no corresponding dummy port for instance 150, port_id 128.2
033499: Jan 11 12:04:22.001: RSTP[150]: Gi1/2 dispute resolved
033500: Jan 11 12:04:22.078: RSTP(210): Gi1/2 Dispute!
033501: Jan 11 12:04:22.078: Found no corresponding dummy port for instance 210, port_id 128.2
033502: Jan 11 12:04:22.078: RSTP(210): transmitting a proposal on Gi1/2
033503: Jan 11 12:04:22.092: RSTP(210): received an agreement on Gi1/2
033504: Jan 11 12:04:22.092: Found no corresponding dummy port for instance 210, port_id 128.2
033505: Jan 11 12:04:22.096: RSTP[210]: Gi1/2 dispute resolved

Is anyone able to shed any light on what could be causing this.
When the ring is in tact, spanning tree converges normally and everything is how it would be expected in terms of root bridges etc.

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

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.

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

This is very helpful. Thank you.

1 Like

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 ?

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

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.

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