STP topology change. MAC table aging timer change for how long?


Having a look at CCIE spanning-tree training videos....

The MAC aging timer says how long an inactive mac address stays on the MAC address (MA) table.
A topology change reduces this aging timer to Forwarding Delay timer (assuming its bigger than the Forwarding Delay).

For how long does this aging timer reduction last? How long until the aging timer gets back to the previous value? (300s assuming default)

2nd little question:
Does the topology change aging timer show up in output of "show mac address-table aging-time"? Any command to see if the reducing aging timer is  "in effect" at the moment?



  • Hi Martin,

    What you are saying its aging timer comes down to 15s, for 15s and then goes back to 300s?

  • My understanding is when switch detects topology Change, it will bring timer to 15 from whatever it is. then counts down to 0 from 15, and when timer reaches 0, it starts new timer at 300.


    What I think is happening is when the root bridge receives a TCN it will start sending configuration BPDUs with the TC flag set. It will do that for the forward_time+max_age_time (which by default is 15+20). When the downstream bridges are receiving BPDUs with TC flag set they will reduce the mac aging time to forward_time (which is imposed by the root bridge).

    Now, in the mac table, addresses are aged out by counting backwards and the counter is reset whenever a packet sourced from that mac address is seen on the same port registered in the table (just to keep it simple). So, considering the default timers, for example, for 35 seconds mac addresses in the table will start aging down from 15 (instead of 300 per default). After receiving first BPDU without TC flag set the aging timer resets to previous value which will be applied to every mac address which will be seen again or learnt.

    As for the initial question, I can only guess that even if the mac aging time is less than the forward_time in STP, the aging time will be set to forward_time. Since there is a change in the network, there will be ports which will transition from listening to learning to forwarding and these timers are closely related. But as I said, just a guess.

    I think this is pretty easy to test with two switches and a client.



  • Hi, thank you all for taking the time.

    Gabriel wish I could but have no access to switches unfortunately. Could use GNS for this but Im not trusting as my first tests show mac entries going away from the table in much less than 300s even without a change in topology. So Im not trusting it very much (unless I was doing something wrong)

    Regarding my question I did find a cisco document which backs up Gabriel.

    ...Every bridge is then notified and
    reduces the aging time to forward_delay (15 seconds by default) for a certain
    period of time (max_age + forward_delay)...

    About "initial question" its not actually here but another post




  • About "initial question" its not actually here but another post

    Yes, sorry about that. I might have "merged" the questions by mistake as both posts are alike.



  • I have the same thing in my notes too, max_age + forward delay. So, by default, 35 seconds for legacy spanning-tree.

    For RSTP, when a configuration BPDU with the TC bit set is received, it wipes the cam table for ports upon which the BPDU was not received. By default, config bpdu's with the tc-bit set are sent for 2x the hello interval. So it effecitvely wipes the cam table on the other ports twice in 4 seconds.

  • welshydragonwelshydragon ✭✭ ✭✭

    2nd little question:
    Does the topology change aging timer show up in output of "show mac address-table aging-time"? Any command to see if the reducing aging timer is  "in effect" at the moment?

    I think you will find that this is platform specific - can't see on Cat3560 - I wonder if any controller commands would show this up.  I have seen this countdown when viewed on a Cat 6500.

  • "for a certain
    period of time (max_age + forward_delay)" 
    that would make sense for indirect failures when switch has to wait for max age to expire. Reading CCNP Switch exam book text says 15 sec for Direct failures, and 20+15 for indirect and insignificant (end port goes up/down), that's my understanding anyway. Why wait 20 sec if you are Root sw and TC is on you.

    Seem you are talking about convergence. I believe independent of direct of indirect failure, The switches reduce the aging timer as soon as they get BPDU with TC=1 as we all agree. In case of indirect failures it just takes more time for this event (TC=1) to occur. But once it does it will still be for (max_age + fwd_delay)

    In the videos Brian actually says aging times are reduced to max_age (20s) but does not say for how long (at least I haven't seen) but anyway I believe we have come to a conclusion on how long.

    For debugging MAC table I believe the comand is "debug matm" (never used it)

    I think I found the answer to this. We can use "show spanning-tree vlan (detail?)"  and look for "topology flag set", that tells us that TC bit is set on the BPDU's and thus MAC timer should be reduced. But would be great to know if you find any other ways.


    ESW2(config-if)#do show span vlan 1 | i flag set
      Topology change flag set, detected flag not set

    ESW2(config-if)#do show span vlan 1 | i flag
      Topology change flag not set, detected flag not set

    (done on GNS3 v1)

  • Hi Martin,

    Thanks for the effort it was a good lab.

    why MAC aabb.cc00.0400 would come
    back if "duration" of aging is longer than 15 seconds (up to 35 sec
    or 3x forward delay)? 


    MAC aabb.cc00.0400 comes back certainly because there was traffic from that MAC on that port before the 35s expired. MAC aging does not mean "clear the table and make it empty for 15s", it means "inactive MACs for 15s will be removed from table".

    If any MAC is kept active generating traffic during a topology change it will not be removed from the table during the TC period (for legacy STP)


Sign In or Register to comment.