Rapid SPT: Max Age ?

[duchesne_ced]

Hi,

I've got a simple question.

802.1W has a fast aging mechanism where protocol informations are aged out after missing three consecutives BPDU.

Now my question is, if you age out after 3 bpdu (so after 6sec, with a hello time of 2 sec), how does a switch reach the MaxAge timeout of 20sec ?

regards

Cedric

[dnewell24]

I beleive the MaxAge timer is for interoperability and integration of RSTP Bridges into networks that include legacy STP Bridges. At least that’s what Section 17.14 of the IEEE 802.1D standard states. You can look there for clarification.

If you find out anything different please post.

Ryan

[arvindchari]

IMHO the max age timer is the time interval a switch will store a BPDU before discarding it. While running STP each port keeps a copy of the best BPDU it has heard and if the BPDU's source loses contact with the switch port, the switch notices that a topology change occured after the max age timer elapses and the BPDU is aged out. The default value for this timer is 20 secs and probably this timer deals with the amount of time when the BPDU is aged out of the table without recieveing an update. The expiration would indicate an indirect failure with designated or root bridge

[dnewell24]

I agree with your statement as it applies to STP. RSTP, I believe, operates differently.

I found this in Cisco Documentation…

"RSTP can achieve much faster convergence …Classic 802.1d timers such as forward delay and max_age are nearly only used as a backup and should not be necessary if point-to-point links and edge ports are properly identified set by the administrator, and if there is no interaction with legacy bridges."

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

[duchesne_ced]

I tought also that the max-age was only there for compatibility but recently i've received this log:

-->> SPANTREE-5-MSGAGEEXPIRY: Msg Age timer expired on port 1/2 in vlan 35

in a RSTP environement. I've had a physical error on this port 1/2 (both RX and TX) and udld did not detect it. (I was not in udld aggressive mode).

Anyway, I can't explain this error in a RSTP environment.