Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Rapid STP Timers and indirect link failures

Hi, I've tried to find info about timers used with 802.1w RSTP. If network topology is done i.e. with 4 square-looped switches (4500 and 3750), Gbit links, and ports are access not trunked - Can there be used 1 sec Hello timer?

What might be the function of Forward-timer, because by altering it, convergence time during indirect link failures seems to follow it?

Thanks, some1!?

  • Other Network Infrastructure Subjects

Re: Rapid STP Timers and indirect link failures

the use of a 1 second hello timer may not be too bad. default is 2 seconds. i've never neededto decrease it but don't think other than doubling your hello's it will have much impact on the RSTP performance.

the forward-delay timer is used to adjust how long each state of the spanningTree protocol waits before moving to the next state.

ie: a port is in blocked mode.

1) another port dies causing the blocked mode port to begin coming active due to it's the next best DP. (designated port)

2) the port moves from the blocked mode to the listening mode. it stays in listening mode for the length of the 'forwardDelay timer'. default is 15 seconds.

3) after 15 seconds, the port moves into the learning mode. it again stays in this mode for the duration of the 'forwardDelay timer', again 15 seconds.

4) after 15 seconds, the port moves into the forwarding mode.

as you can see the forwardDelay timer is used to tell STP how long to stay in a particular mode before moving onto the next mode. this provides STP the time it may need to get all the accurate information about the network to make its decisions.

you are correct that adjusting the forwardDelay timer has a direct impact on the convergence time of STP.

see this link for more info:

PS..remember that RSTP differs from STP in the fact that it does not process the blocking, listening or disabled states. it only performs 'discards' when in any of those states. this allows RSTP to transition RPs and DPs to the forwarding state immediately.

Re: Rapid STP Timers and indirect link failures

Make sure that all your switches are running RSTP (I guess you are in rapid-pvst mode) and that all the ports in your square topology are seen as point-to-point (p2p) and RSTP neighbors (not STP).

If one of the switch detects the link failure by a link down indication, the reconvergence should not depend on any timer. If the forward-delay has an influence in your convergence, it means that you don't have RSTP like recovery. Or there is a config problem, or the link failure is detected by the periodic BPDUs. In that latter case, reducing the hello time from 2 to 1 seconds should help. But the forward-delay would not make any change so I don't think that's the case for you.



Re: Rapid STP Timers and indirect link failures

Also, stupid question, how do you determine you network has reconverged? If it's by pinging between two hosts connected to two switches in the square topology, you may need to configure portfast on the port connecting the PCs. If you don't, the PC port may be blocked by an RSTP sync, and there, you will need 2xforward_delay to go back to forwarding.



New Member

Re: Rapid STP Timers and indirect link failures

Hi ftallet,

yes very stupid question, but also very effective - hit&plunged ;)

Tested only by pinging from the PC connected to one of the bottom switches towards root. Have checked that boxes were running rstp mode and debug did reveal something about this sync-matter. Frwd-delay was definitely making the diffence in ping-delays.

Thanks, have to test it tomorrow!

New Member

Re: Rapid STP Timers and indirect link failures

Yep, it was hard to find information, but you solved the case - portfast activated edge-p2p link immediately.