RSTP convergence times

global_trekker1 · ‎07-16-2008

I'm a little confused on the RSTP convergence process.

When I first learned RSTP, I learned that RSTP collapses the listening and learning into a single period of 15 seconds. Yesterday I read a whitepaper that said a switch immediately sets its designated ports to forwarding after receiving confirmation from the downstream switch that the best path to the root is through itself. If that's true it shouldn't take very long for the entire network to converge.

I don't have the link to that whitepaper right now. I'll post it when I find it.

Francois Tallet · ‎07-16-2008

RSTP or MST don't change anything in the way the timers are used. It's just that you have an additional mechanism (the proposal-agreement) that allows bypassing the timers in order to provide immediate convergence (see http://www.cisco.com/warp/public/473/146.html).

So because RSTP does not depend on any timer for its convergence, the platform handling will be the limit for the convergence time. With an ideal switch, immediately processing BPDUs, setting new state for ports, instantly flushing cam tables etc..., RSTP convergence could be as close as you want to 0 seconds! Practically, I would expect RSTP/MST convergence to be of the order of the second (in a network appropriately configured).

Regards,

Francois

a.alekseev · ‎07-16-2008

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#converge2

Conclusion

RSTP (IEEE 802.1w) natively includes most of the Cisco proprietary enhancements to the 802.1D spanning tree, such as BackboneFast, UplinkFast, and PortFast. RSTP can achieve much faster convergence in a properly configured network, sometimes in the order of a few hundred milliseconds. Classic 802.1D timers, such as forward delay and max_age, are only used as a backup and should not be necessary if point-to-point links and edge ports are properly identified and set by the administrator. Also, the timers should not be necessary if there is no interaction with legacy bridges.

[Pls RATE if HELPS]

global_trekker1 · ‎07-16-2008

So if you didn't specifically designate the port as p2p with the command "spanning-tree link-type point-to-point", would the network revert to using the timers?

Francois Tallet · ‎07-16-2008

RSTP and MST can only do the proposal agreement on point to point links indeed. And edge ports must me clearly identify so that they go forwarding immediately as they can't participate in the proposal agreement. That's why I always try to mention that the network must be "appropriately" configured in order to get the benefit of those protocols.

By default, a link is consisted as point to point if it is full duplex. Else it is configured "shared". In most of the case, your point to point link will indeed be full duplex and you will not have to enter any configuration command on your port.

Regards,

Francois

global_trekker1 · ‎07-16-2008

I just tested the p2p behavior on my network. I first tried it without specifying "spanning-tree link-type point-to-point". And then I tried it with the command. Both times it took about 25-30 seconds for the network to converge.

The switches on each end are both 3750s. The interfaces are both CAT5 Gig ports. One switch is hardcoded to be the spanning-tree root.

a.alekseev · ‎07-16-2008

how did you test it?

Francois Tallet · ‎07-16-2008

The only things I can tell you from the information you provide are:

- you have a problem

- the problem is not coming from RSTP not considering the link between the 3750s as point to point...

How did you measure the convergence time? Could you be pinging from a port that does not have portfast configured on it;-)?

global_trekker1 · ‎07-16-2008

I just realized that I'm still using pvst. I'll convert to rapid-pvst tomorrow. Thanks for your help

Mike