Root bridge Change - Convergence Time in RSTP

[Netmart]

Hello,

I am wondering how long it takes to propagate a change of the root bridge in Rapid Spanning Tree Protocol:

Example:

From: 

Switch Root ===DSG, SW1 root [default priority 32,768]

To:

switch Root== DSG, SW1 [Priority 32,768 ] Root ==uplink== DSG ,SW2 [ New root, priority 4096]

Assumption: As soon as the uplink between SW1 and SW2 is enabled, Rapid STP convergence is kicking in. 

And how long will this convergence approximately take considering all the timers where the ports between SW1 and SW2 are going to negotiate the root bridge.

Thanks.

[paul driver]

Hello
as soon as the two switch’s are actively connected they will sync after they receive their first bpdus so one of them becomes the root and the other will have a root port towards the root switch  - this convergence can be almost instantaneous >2 secs 

[Netmart]

Thank you Paul.

Is there any documentation available explaining all the timers?

[julian.bendix]

Agreed!

[Martin L]

I agree with Paul, there is no delay, very simple network, no failure of link, u changing Root manually. I would say convergence is instantaneous and under 1  secs.

Every cert exam book explains RSTP timers; if u don't have Cisco Press book, google RSTP timers

Regards, ML
**Have fun labbing!!!***
***Please Rate All Helpful Responses ***

[Joseph W. Doherty]

This is an "it depends" answer.

Much depends on "why" and "how" the root bridge changed, and the topology of the network, including where the old and new root are located too.

My colleagues have mentioned possible under 1 second and "instantaneous".  Yes, under 1 second is possible, but so is much longer number of seconds too (very unlikely to exceed 15 seconds).  Unless we're well under 1 second (also possible), personally, I wouldn't mention the term "instantaneous."  Again depending on the why and how the root changed, likely re-convergence won't exceed 6 seconds.

Of course, with STP, a bridge change, I believe, pauses the whole L2 network domain.  So, however long it takes, might be much more "noticeable".

There are some "ugly" corner cases to rapid-STP, with root bridge changes.  This document https://cdn2.hubspot.net/hubfs/3985396/Blog/understanding-stp-rstp-convergence.pdf appears to have more details about STP and rapid-STP, including situations not often presented in basic STP documentation.

[Martin L]

note that he is changing Root manually on directly connected switch (no failure of link). 

[Joseph W. Doherty]

---

@Martin L wrote:

note that he is changing Root manually on directly connected switch (no failure of link). 

---

You're referencing his OP example case, correct?

Actually, I'm a bit confused by the OP as to exactly what was done in the example case.

He describes two switches, with a default priority of 32K.  He further describes setting the one switch, SW2, to a priority of 4K.and mentions connecting a link a new uplink between the two switches.  He also mentions (?) the switches have other ports between them.

Yes, agreed, there's something "manual", although, to me, it's a bit unclear what exactly he's doing to effect the root change, if there really was a root change.

So, unclear whether the switches were already interconnected before the "uplink" was connected?  Was the change in priority, for SW2, before or after the "uplink" was connected?  When switches had equal priority, which switch (if interconnected) was the root?

OP describes, STP convergence with connection of "uplink", but was there really a root change, or just a better root port?

Regardless of the forgoing, OP's first paragraph "I am wondering how long it takes to propagate a change of the root bridge in Rapid Spanning Tree Protocol:" was a generic question, which is what I was addressing.  I didn't want OP, or others, believe all root changes, even with rapid-STP, should all be expected to be "instantaneous".

[Netmart]

Joseph/all:

I am not sure where the confusion is kicking in, one just has to read carefully the two scenarios:

From: 

Switch Root ===DSG, SW1 root [default priority 32,768]

To:

switch Root== DSG, SW1 [Priority 32,768 ] Root ==uplink== DSG ,SW2 [ New root, priority 4096]

Assumption: As soon as the uplink between SW1 and SW2 is enabled, Rapid STP convergence is kicking in. 

Meaning: The link between SW1 and SW2 is enabled manually. And since SW2 is manually configured with higher priority of 4096  it is elected as the root. 

The reason for asking: According to the Cisco Documentation "In RSTP, only nonedge ports that are moving to the forwarding state cause a topology change and sending a TC BPDU. " Applying this statement to my illustrated scenario, no TC BPDU would be exchanged. And this is, what I wanted to get confirmed in one of your posts.

To the comment to "Google" it is in my opinion lacking the seriousness and professionalism. And by the way, yes, I am a reader of Cisco Press Material. 

[Joseph W. Doherty]

My confusion was caused by misunderstanding OP, i.e. I thought it wasn't clear when SW2's priority was changed to 4k, but I understand it now.

What threw me off was describing SW2 as a new root.

What you had was two non connected switches, SW1 with priority 32k and SW2 priority 4k.  As such, both would consider themselves root switches.

When you interconnected them, and they shared their BPDUs, each would see SW2 had the superior BPDU, and so it would remain as root but SW1 would give up its root status.  I.e. only SW1 needed to reconverge.

However, after you connected the two switches, if you changed SW2's priority to 64k, SW1 would become the new root and both switches would reconverge.

Consider if there was a whole bunch of other switches downstream of both SW1 and SW2.  The latter case would be more impactful.

So, again, the impact of a root switch change is an "it depends".

Now that I do understand your example case, which is adding an edge switch to an existing topology, where the added switch shouldn't change the root (other then for itself), yea that would you go rather fast, and except for that switch, go unnoticed.

Conversely though, if an added edge switch became the new root, it's often not a good thing.  You can read, within these forums, real cases, of that happening, even if actual reconvergence was "instantaneous" (usually not, but whatever the pause of frame forwarding, the new root's impact can be even more detrimental).

[NetworkNewbie37]

Hello Joseph,

I have a question regarding this. Would the convergence time be quicker if the connection between the new root and former root, assuming they are directly connected, are using switchport mode trunk alongside switchport spanning-tree portfast trunk?

[Joseph W. Doherty]

---

@NetworkNewbie37 wrote:

Hello Joseph,

I have a question regarding this. Would the convergence time be quicker if the connection between the new root and former root, assuming they are directly connected, are using switchport mode trunk alongside switchport spanning-tree portfast trunk?

---

An interesting question, to which I know not the answer.  I recall (?) port fast on a trunk port (non edge?) is even more risky than setting it on an edge port.

FYI: My experience with STP has been to eliminate it (with L3 topologies), except for handling accidental creation of L2 loops.  I.e. I take very little interest in the technology, beyond "knowing" rapid-STP is much, much better, and on Cisco PVST, there's a few very worthwhile STP extensions to also use (a couple of which, though, part of the rapid-STP standard).

In other words, STP root selection and/or STP convergence, by design, generally non-issues in L3 topologies.  Also, generally easier to obtain much faster L3 convergence.

[MD Irshad Ansari]

Hi,

Good question. With Rapid Spanning Tree Protocol (RSTP, 802.1w), convergence is much faster than with classic STP. In the scenario you described, when you connect SW1 and SW2 and SW2 has the lower bridge priority (4096 compared to SW1’s 32768), RSTP will recognize SW2 as the new root bridge very quickly.

• The proposal/agreement handshake between the switches is almost immediate.
• RSTP doesn’t rely on the traditional long forward‑delay timers. Instead, it uses its synchronized handshake mechanism.
• In practice, the convergence should take on the order of a few hundred milliseconds up to 1–2 seconds depending on factors like topology, link type (point‑to‑point vs shared), and whether all involved ports are full‑duplex.

Compared to classic STP (which could take 30–50 seconds with default timers), the change here is very fast and almost unnoticeable in most small to medium networks.

So, for your case (uplink enabled between SW1 and SW2, with RSTP already running), you can expect the root bridge change and port role transition to complete in roughly 1 second or less in a clean environment.

— Irshad

[MarkTrump]

With RSTP, root bridge changes usually converge in under a second to a few seconds on a clean link. It only takes longer if legacy STP or more complex topologies are involved.

[Netmart]

And since some of you were mentioning Cisco Press, this is from my notes when studying for CCNP Switch:

• In RSTP, only nonedge ports that are moving to the forwarding state cause a topology change and sending a TC BPDU. Unlike with 802.1D, loss of connectivity does not generate a topology change.
• In other words, a port that is moving to blocking does not cause the respective bridge to generate a TC BPDU.
• When an RSTP bridge detects a topology change, as depicted in Figure 3-10, it performs these actions:

1.The RSTP bridge starts the TC While timer with a value equal to twice the hello time for all its nonedge designated ports and its root port, if necessary.

ØThe TC While timer is the interval during which the RSTP bridge actively informs the rest of the bridges in the network of a topology change.

2.The RSTP bridge flushes the MAC addresses associated with all nonedge ports.

As long as the TC While timer is running on a port, the BPDUs sent out of that port have the TC bit set. While the timer is active, the bridge sends BPDUs even on the root port.

source: Cisco Press, Implementing Cisco Switched Networks, p.96