If I have two switches connected redundantly and both are capable of using STP, RSTP, or MSTP, how quickly can an alternate route be detected and normal communication resume if the main route is disconnected?

Is there a theoretical limit to the three protocols and what are some practical delays that add to it?

  • 1
    Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 15 '17 at 4:31

Realistically, it depends on the size of the current spanning tree and how it is disrupted.

In an RSTP or MSTP environment, if an interface goes hard down (eg: it's disconnected or otherwise shut down), then the topology change will trigger immediately - between only two switches, a new tree should establish in less than a second and forwarding will recommence.

If there is break not caused by link down (eg: configuration change, intermediate device failure etc), then RSTP and MSTP will wait for 3x Hello Interval (3x2 (default) = 6 seconds by default) before re-converging.

STP on the other hand is a lot slower because it has a slightly different state machine - it will wait 10x Hello Interval (20 seconds) for a BPDU timeout, and then sits in listening State for another 15 seconds, followed by the learning state for another 15 seconds, giving you somewhere around 50 seconds to converge.

Bear in mind though that these figures are for a single switch - if you have a large network diameter, downstream switches may start detecting failure at slightly later times, meaning they will start this process later and ultimately add more time to a complete topology re-convergence.

Added to this is when you're using protocols like VSTP/PVST/PVST+ the switch needs to do this re-convergence for every VLAN, which if there are a lot can be quite taxing on the CPU thus slowing down the r-econvergence further.

  • Thank Ben! Follow up question, why do link down failures recover much quicker and are not subject to the 3x hello interval delay? Oct 24 '16 at 20:44
  • The purpose of the BPDU is to determine if the topology has changed - if an interface changes state/goes down, then this is a pretty strong indication that the topology has changed, so STP can move quickly into the next state and begin forming a new tree. There is also no point in sending a BPDU out an interface and expecting a reply on an interface that is physically down. Aug 16 '18 at 0:22

RSTP is going to be much faster than STP during failover. STP is going to have a failover time between 30-50 seconds. STP Timer = Max Age 20sec. Forward Delay 15 sec. maximum delay in STP = 20 + 15 + 15 = 50 sec. (Bridge Protocol Data Units) BPDUs are sent to all the switches to notify that there is a change and in STP this is done by the root switch. The root switch is selected by lowest priority or lowest MAC address. The problem with this is that if something fails far away from the root switch then the convergence will be very slow. In RSTP, all the switches are allowed to send BPDUs and are able to converge faster. In STP, BPDUs are RELAYED by the switches but in RSTP are sent every hello time(2s by default).

In my networking class in college, the equation they gave us for network failover time in stp was:

Failover = failure_detection + failure_recovery; failure_detection = Max_Age_Timer(20s default) failure_recovery = Fwd_dly(listening state 15s default) + Fwd_dly(learning state 15s default).


Network failover time in RSTP:

Failover = failure_detection + failure_recovery; failure_detection = 3 x Hello_Timer(2s default) = 6s failure_recovery = Fwd_dly(fast_learning(<<1))

Not too sure about MSTP but i hope this helps somewhat

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.