Loss of Root Bridge and Reconvergence

[Mike Soha]

I am trying to understand the mechanics and timing for the recovery from the loss of the root bridge.  From my limited knowledge of STP and RSTP, I suspect all ports would enter Blocking/Discarding while the new Root Bridge is elected, followed by the establishment of the Spanning Tree.  Can someone summarize the specific bridge states and timing for reconvergence?  One area of concern is how long would the entire network be shut down during this time.  Thanks in advance, Mike S 

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/19120-122.html

check this link for more detail 

[Mike Soha]

Thanks, I've seen that document - good review of the timers, but lacking in terms of describing reconvergence for the loss of the root bridge.  I was hoping someone more knowledgeable than me could answer the question.   

[Mike Soha]

This is what I believe happens for STP and RSTP – comments and corrections welcomed

Time to recover from the loss of the Root Bridge

• STP: ~70 seconds
• RSTP: ~6 seconds

Root Bridge Fails

• STP, A non-root bridge will wait 10*Hello Timer before sending out its Hello BPDU (20 seconds)]
• RSTP, A non-route bridge will wait 3*Hello Timer before sending out its Hello BPDU (6 seconds)

The time to elect a Root Bridge doesn’t appear to be specified, although I have found references to a few seconds - which I find odd.  Why would Bridge Election not consider End-to-end BPDU delay?  Assuming a diameter of 7 and 1 second transit delay, this would be 6 seconds (7-1)*(bridge transit delay).  Now, if one assumes 3 BPDU could be lost, this number becomes 14 seconds.  

The only rationale I can think of is that the consequence of incorrectly selecting a Root Bridge, are not significant and hence one can be aggressive.

Root Bridge elected

• The establishment of the Spanning Tree (i.e., user data forwarding) for STP would take on order of another 50 seconds
• The establishment of the Spanning Tree (i.e., user data forwarding) for RSTP would take a few seconds

[Joseph W. Doherty]

". . . 1 second transit delay . . ."

Or course, actual transit delays likely will take (much) less time.

In my experience RSTP usually recovers with a couple or few seconds (long enough that you start to "what the" and it recovered), STP recovery takes noticeably longer, like 10 seconds or more (long enough, you start to wonder is it going to recover).  (BTW, this for "typical" networks which don't hit the full diameter boundaries, also on Enterprise class switches less that 25 years old.)

[Mike Soha]

Joseph,  Thanks for the reply - much appreciated.  A couple of follow-up questions

- My question about bridge election wasn't about how long, rather why wasn't it conservative and based on timers related network diameter like other aspects of STP/RTSP state changes.    For example the new root is other side of the network, thus requiring the Hello BPDU to traverse the entire network.  

- I came across an article from Siemens discussing root bridge failure in RSTP network, which suggests that convergence from the loss of a Root Bridge in RSTP is dependent on network connectivity and will result in "root bridge flapping"  pun intended.  Do you agree? 

https://assets.new.siemens.com/siemens/assets/api/uuid:d4af5d17-728c-493f-b00a-9c4db67b23ed/RSTP-whitepaper-EN-09-2020.pdf

Thanks Mike S

[Joseph W. Doherty]

Ah, "My question about bridge election wasn't about how long, . . ." vs. in OP "One area of concern is how long would the entire network be shut down during this time."  I did also see in OP you wanted very specific details, but, in my defense (laugh), most often for practical networking we often don't care about 1.3 seconds vs. 1.7 seconds STP convergence.  Nor, do we often want to get into calculating millisecond and/or microsecond delta for every link or transit device.  I.e. this is why I only provided, possible common, ballpark differences, for convergence times, for STP vs. RSTP.  Reading (or actually only skimming) your reference, appears you really are into the deep details.

Unsure whether I can help much with such deep analysis, and actually, and personally, I not very much interested in doing so.  (Again, mainly for my practical purposes, just "knowing" ballpark convergence times, and/or which are the better/improved STP variants benefits, for me, is "good enough".  (Further, in the networks I've dealt with, L2 domains were very small, and STP only used as a safeguard against someone accidentally creating a L2 loop - actually those networks were often large, and L3 for multi-path and fast convergence.)

BTW, skimming your reference, I didn't see any glaring errors (errors would have been a bit of a surprise as this is a Siemens whitepaper), although since the document focused much on rings, surprised REP not mentioned (as an alternative to STP) at all.

Also interesting, in the white paper, was mention of how difficult computing root bridge failure times for mesh networks are, i.e.:

Root bridge failure in a meshed network is very hard to analyze and predict, and a result may be totally different for every specific topology.  The common conclusion is though, that the root bridge failover time grows exponentially as more redundant paths are added to the network topology. The root bridge failure in meshed topology is a well recognized problem.

Another laugh, in my experience did I mention minimal use of L2 and using L3?

So, anyway, do you have a real issue/problem you're dealing with, or is this just a mental exercise?  (BTW, nothing wrong with the latter, just, of course, "in the ball park" answers are likely not the "right" answer.)

[Mike Soha]

Joseph,
Thank you for the prompt reply. As for the genesis of the question, it is more of a mental exercise on the mechanics of RSTP with regard to failure modes. As you know, a lot of people see L2 switching as a panacea for internetworking – this was one of our key concerns back in the 80’s at DEC when we were working on the Transparent Bridge design. So, this exercise is a little déjà vu for me.
I agree that use of bridging in a richly connected network is not a good idea, but it does expose an interesting characteristic of RSTP wrt to Root Bridge Flapping given the failure of the Root Bridge.
Thanks again, Mike S
Ps My analysis in the 4th reply on 10-05-2022 12:00 PM is incorrect since it doesn’t include the potential for root flapping.

[Joseph W. Doherty]

". . . back in the 80’s at DEC . . ."

Well back in the early 80's, in my first professional job, I spent several years programming on a DECsystem-20, what a wonderful system!  During that time, I actually turned down a DEC job offer, supporting TOPS-10, in Maynard, MA.

Next job, I was a programmer on an IBM 370 mainframe system, to acquire "state-of-the-art" (compared to TOPS-20 NOT!!!) experience.  (However, programming on IBMs did pay more - which made sense, for all information you needed to know to program on an IBM.  Also as an aside, I was stunned when I first learned that 360/370 architecture did not have stack instructions.)

Besides being concerned with L2, did you do any work on DECnet back then?

[Mike Soha]

The 80’s were pretty cool, Ethernet had just come out running at a blazing 100 Mbps and was really the first multiaccess datalink – which introduced a number of new challenges for routing (e.g., multiple addresses on a single interface).  I was fortunate to join the Network Architecture Advanced Development team at DEC in 1983.  Looking back, it was an impressive collection of individuals with KK Ramakrishna, Radia Perlman, Raj Jain, Tony Lauck, Dah Ming Chui, George Varghese, Dave Oran, George Harvey, Bill Hawe, and Alan Kirby.  I joined just after they filed the bridge patent so we were working on loop detect and had a couple of choices with Radia’s, George V’s and others.  In the end, we chose Radia’s STP, because we were in the midst of LAN wars with IBM and needed to ensure the stability of the bridged network given our desire to push Ethernet.  Bridging was huge for Ethernet because (unlike repeaters) it isolated collision domains which was one of IBM’s attacks on Ethernet (stability concerns with too much contention).  Token ring vs Ethernet later evolve to Bridge Wars with IBM (Token Ring and Source Routing Bridges) where I spent 3-4 years of my life fighting source routing and shepherding the 801.1D standard.  It was a transition time for the DECnet, while we had a robust suite of protocols, we were wrestling strategic direction: DECnet vs ISO (never have a standards body build anything, they should just standardize proven designs) vs ARAPNET-TCP/IP.  We all know how that story turned out and most of the team disbanded.

Back to Root Bridge failure, I may dig a little deeper, I’m consulting for a customer who is considering a design based on L2 and a rich network (each switching node has multiple interfaces).  I can reach out to you directly with some of the analysis if you’re interested.  Thanks for the walk down memory lane.  Mike Soha

[Joseph W. Doherty]

Wow, that's quite a who's who list.

Thanks for your offer about sharing your L2 analysis, but, within networking, my interest lies with QoS and traffic management.  IMO, a much sorely overlooked aspect of networking, until things like VoIP and other real-time apps started to run across networks.

[Mike Soha]

Latest update on STP and RSTP with loss of root bridge

Using Cisco packet tracer I built a sample network and simulated the loss of the root bridge.

Topology: Hub and spoke with a total of 11 nodes (One hub  attached to 10 nodes (spokes), each of the spokes are connected to their neighbors (i.e., wheel).

Loos of root bridge 

- STP: 45 seconds to reconverge, resulting spanning tree is deterministic

- RSTP: 6 seconds to reconverge, resulting spanning tree is indeterministic.   My suspicion is that the indeterminism is a result of the randomness of each bridge's 2 second Hello Timer coupled with RSTP aggressive handshake approach to enable links.  

Has anyone else see indeterminism with RSTP for rich networks?

Thanks Mike S 

[rujipars_a]

I've got some useful information from this thread, so I think it will be also useful to share my information in contribution to this.

I happen to get involve in some network that have > 300 switches with diameter of around 20 switch hops. 
It is relatively highly meshed per the switch network norm.

We tested primary root bridge failure and found the old information of the failed primary root bridge injected back and keep some other switches, even the backup root bridge, remain for 15 seconds before all switches successfully eliminate the old information and agree to select the secondary root bridge as the new root.  In conjunction with the "hold count" limit, I believe that cause the update to be slower than simply RSTP synchronization in small network that might not hit the hold count limit.

I don't like to see that large number of switches in the network.  Or I would consider MSTP with region segregation to minimize impact of topology change.   But unfortunately, I get involve in the stage that the network deployment was completed and changing become too costly.