4006 cam aging went to 15 seconds WHEN does it revert?

Unanswered Question
Feb 19th, 2009

On a 4006 switch, a (spurious) topology change notification (TCN) caused the cam aging on the main vlan to be set down to 15 seconds. However, there was no further TCN for a long time (an hour or so) but the vlan 1 cam aging stayed at 15 seconds. Should it revert to the configuration value, and if so after what time or event?

By the way, we are fitting portfast to all leaf device ports to suppress spurious STP TCNs.

If you are able to help, thanks in advance!

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
gesadmin1 Fri, 02/20/2009 - 09:09

It is MaxAge + Forwarding delay. By default this would be 35 seconds (20 + 15). If you have changed your timers this could vary.

Here's some thoughts to consider:

1. Do a show spanning tree vlan 1 det and look for incrementing topology changes and if so what port they are coming from. If they are incrementing, then you may have a problem with the root bridge flip-flopping between switches.

(Are you getting log messages with "relearning xxxx addresses? If so, you may still be experiencing spanning tree issues or the 15 sec timer could be stuck.

2. ID the root bridge for vlan 1 is: sh spanning tree root and whether it is changing. You should have the root primary and backup set manually.

3. If you are running rapid spanning tree, these flip-flopping roots may not impact the network as it happens sub-second.

4. If you don't recognize the root or it's at the edge of your vlan, trace the mac to it. There should be no more than 7 hops in a spanning tree. Check the diameter of vlan 1 (ideally don't mix mgmt and data on same vlan and best practice is to not use vlan 1 at all.)

If there are no TCN's occurring, then you might try upgrading the code.

5. To my knowledge, portfast doesn't prevent tcn's it just moves the port immediately into forwarding state.

If you want to stop TCN's completely, turn off spanning tree for the vlan or that's not desired, use the spanning-tree bpdufilter command (this stops the sending and receiving of bpdu's. I had to use this once when an internal customers switch had stolen the root bridge for a vlan.

I've found that tracking the # of topology changes per week on key vlans is a good measure of network stability and has helped find a number of minor configuration errors and spanning tree issues. Good luck.

Andrew

Actions

This Discussion