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.
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).
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.
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.
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.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...