Spanning Tree Topology Change Notification (TCN)

Hello Rene,
i would like to see if I understand theory Of tcn:
When a non-root switch detect a topology change ,maybe an interface goes down, it delete mac learned From that interface , generate and forward a tcn towards root bridge on its root port and reduce aging time to forward delay.The upstream switch detect on its designated port this tcn, ack this tcn, reduce its aging time, generate a tcn itself and forward to root bridge on its root port, right? These 2 switch has not to wait tc of rootbridge, to reduce aging time, maybe other switch in other side Of the network, reduce aging time as they receive tc generate by rootbridge… Is correct my discuss?
best regard

Hello Rene,

In addition to the mac address table being cleared faster upon receiving TCN’s, does it also clear the ARP entries (faster) for it as well?
Or is the faster clearing, strictly mac address table?

Regarding the "All switches received the topology change notification and set their age out timer to 15 seconds. ", is there anyway to tune this timer to more smaller like 5 sec?

@Rafael This only applies to the MAC addresses, not the ARP table.

@Amy You sure can. This is the forward delay timer which is 15 seconds by default. It can be changed per VLAN:

SW1(config)#spanning-tree vlan 1 forward-time ?
  <4-30>  number of seconds for the forward delay timer


Hi Rene,
Thanks for great document,I have a one question.
When would switches reduces its aging time? On receiving of tcn messages or tc messages?


If we are talking about traditional spanning tree (802.1 D), and not rapid spanning tree (802.1 W), a switch will set the aging of the MAC address table equal to the Max Age timer when it receives the Topology Change Acknowledgement from the Root Bridge. It works like this:

A switch, let’s say it is not the root bridge, has event that causes it to generate a topology change. It’s goal is to send this to the root bridge, and then it is the root bridge’s job to acknowledge this change. This acknowledgement starts with the Root Bridge and makes its way throughout the network from there. Once the other switches receive this acknowledgement, that’s their indication that they need to set the MAC address table aging to the Max Age timer value.

Rapid Spanning tree works completely differently, by the way.

1 Like

Hi Rene,

Thanks for creating this blog, it’s written very well.

Can you please explain in detail the Designated port. Is it not that the designated port has to be only on the root bridge? Are all forwarding ports designated port? What is the difference between root port and designated port? if you can explain with your example in the blog, it would be great?

Thank You
Best Regards,
Prathamesh Gokarn

Hi Prathamesh,

Glad to hear you like it.

For each segment in the network, there has to be a designated port that forwards traffic. This means that you will also find designated ports on non-root bridges.

For example, imagine we have SW1, SW2 and SW3 connected in a triangle. SW1 is the root bridge.

On the connection between SW2 and SW3…someone has to forward traffic there, either SW2 or SW3. One of the interfaces will become a designated port, the other one will be non-designated and blocked.

The root port is the interface that has the best (shortest) path to the root bridge.


1 Like

Awesome lesson, thanks.

HI Rene,

I have some doubt on selecting Designated and Non Designated port on non root bridge.
Can you pls explain how D and ND ports selected in your 4 switches topology on the segment
between SwitchB--------SwitchD , will it be mac address or port cost ? while switchC is root bridge,

and one more thing on switchB in your 4 switch topology SwitchA-------(Root port)SwitchB, So port connected to SwitchB Root port on switchA will automatically
become Designated port ?

Hi Rohitendu M,

Let’s take piece by piece. The switches share BPDU to elect the root bridge. They look at the priority + MAC address==> we call it Bridge ID.
The switch which has the lowest bridge ID will be the root bridge. In the lesson, Rene has lowest the priority on Switch C so it became the root bridge.
As Switch C is the root bridge, then all interfaces will be as Designated ports.
In our case for Switch C:
F0/13 = Designated Port
F0/19 = Designated Port

For non-root bridges, they will check the shortest path to the root bridge and that’s the root port. In this lab, we assume that the speed of the interface is 100 Mbps, so the cost will be 19.
Then now we have:
F0/16 = Root Port
F0/19 = Root Port

As Rene has increased the cost on F0/19 of SwitchB, then this port will be in blocking state, thus the possible loop is not available anymore in the network which means all other switch ports will be in forwarding states.For every segment, there should be a designation port so the port F0/16 of SwitchD will be a designated port after the F0/19 of Switch B became in a block states.

We still have the segment between SwitchA and SwitchB. Every switch has only 1 Root port. As SwitchA has already a root port on F0/16 interface, then F0/14 will become a Designated Port. As I mentioned previously, there should be 1 designated port per segment, then F0/14 of SwitchB will move to Root Port.

I hope I could answer your question.
For more information, please read the following lesson:

Introduction to Spanning-tree Protocol

1 Like

19 posts were merged into an existing topic: Spanning Tree Topology Change Notification (TCN)

Hello everybody. I’m new here, this is my first post :slight_smile:

I have a question on the mac address table flush.

I don’t understand if a switch flush the cam table when receveid a topology change notification (bpdu with bpdu type field changed) or it will flush the cam only after it received a configuration bpdu from Root with topology change flag field set?

Thanks a lot.

Hello Americo

Once the root bridge is aware of a change in the topology of the network, it sets the TC flag on the BPDUs it sends out, which are then relayed to all the bridges in the network. When a bridge receives a BPDU with the TC flag bit set, it reduces its bridging-table aging time from 300 seconds to 15 seconds. This ensures a relatively quick flush of stale information.

I hope this has been helpful!



OMG I just found I missed a small paragraph that has me confused about Max Age Timer and the Mac Address Timer.

see quote:

When the switches receive this message they will reduce the aging time of the MAC address table from 300 seconds to 15 seconds (this is the forward delay timer). This message is called the TCN (Topology Change Notification).

So I am confused now, and need help understanding.

if the max age timer is the 20 seconds is this the 20 seconds blocking timer at the first.

edited For my notes: the Max age timer has nothing to do with mac address aging. it has to do with the time that the switches wait before sending a topology change. basically the hello packets(BPDU) are sent every two seconds after 20 seconds it initiates a topology change. which starts the forward delay.

If that is the 20 second block timer at the first then where is the timer for 15 seconds the mac age before its dropped.

if the entire process is 50 seconds max age timer(20s)>(listening(15s)>Learning(15s) then finally it starts forwarding and has is considered converged where does that mac address aging of 15 seconds fit in???

it obviously has to fit into either the listening or learning or the math does not add up someone please explain this as I just confuzzled myself!

ok may be on a lead just found the following:

The Forward Delay The Forward Delay is the time that is spent in the Listening and Learning state. When the port transitions to the Listening state, it indicates a change in the current Spanning Tree topology and that the port will go from a Blocking state to a Forwarding state. The Forward Delay is used to cover the period between the Blocking and Forwarding states, which includes the Listening and Learning states.

This time is set to 15 seconds (sec) by default but can be manually set to be between 4 and 30 seconds.

Tafa, Farai. Cisco CCNP SWITCH Simplified (Kindle Locations 2039-2043). Reality Press Ltd. Kindle Edition.

in addition, if we want to look at the forward delay default timer it can be seen and computed below:

Assuming all the default values, we can calculate the Forward Delay as follows:

Forward Delay = ((4 * hello) + (3 * Diameter)) / 2

Forward Delay = ((4 * 2) + (3 * 7)) / 2 Forward Delay = ((8) + (21)) / 2

Forward Delay = (29 / 2 Forward Delay = 29 / 2)

Forward Delay = 14.5 seconds (rounded up to 15 seconds)

Tafa, Farai. Cisco CCNP SWITCH Simplified (Kindle Locations 2045-2050). Reality Press Ltd. Kindle Edition.

that says the forward delay by default in a single switch is 15 seconds which would seem to say that the total time for listening and learning was 15 seconds on a single switch anyway. There is more information about message age timer that is increased per switch I am still banging my head against wall trying to figure out that detail. will report back findings.

The Message Age timer is used in conjunction with the Max Age timer.

Tafa, Farai. Cisco CCNP SWITCH Simplified (Kindle Location 2025). Reality Press Ltd. Kindle Edition.

so I cannot figure this out. it sounds like the default diameter which is what sets the message age timer has to do with covering the listening and learning stage and is part of the forward delay but I don’t know its confusing.

Whatever the case mac address aging is handled during this time and it seems that message age timer is in here as well and it has a default diameter of 7 but it depends on the amount of switches you go through on actual time. all that gobbly goop adds up to the listening and learning stage.

So uplinkfast basically cuts out most of that time allowing for very quick convergence. partially by getting rid of mac addresses which are part of the forward delay but also cuts out the rest by saying use me immediately basically in the code.

backbone fast on the other hand just cuts out the max age timer and does not wait on the loss of hello(BPDU) packets by sending RLQ to the root and once it gets its reply it moves the forward delay state immediately. It does nothing about the forward delay which comprises the mac address table and other gobbly goop like the message age timer.

someone should right a simple detailed engineering spec on that process so we have granular detail or maybe after we looked at it we would not want to know lol…

Hi Rene,

What are the scenarios when the TCN bit is set or a TCN BPDU is sent by a switch? Is it only when a port goes down or comes back up in a switch or even when a root bridge gets updated in a switch?

Hi Rakesh,

The TCN bit is set when:

* An interface that was in forwarding mode goes down.

* An interface goes into forwarding and has a designated port.

Changing the root bridge does not trigger setting the TCN bit directly but it is possible that the TCN bit is set because of interface state changes that occur because of a new root bridge.

EDIT: Having looked into this further, I don’t think the process as described in the article is actually correct… if the root port on SW1 goes down, rather than sending a TCN, it will start sending inferior BPDUs to SW2. That’s according to this:

In the scenario given, it says that SW2 receives the TCN from SW1 and then immediately makes Fa0/19 the new root port.

A topology change doesn’t necessarily mean that the root port needs to change, so how does it know to immediately change the root port? My suspicion is that a switch should never expect to see a TCN on a root port, unless that path to the root bridge has gone down (or unless it originates from the root bridge itself). Would that be correct?

@ReneMolenaar Please could you comment on this?

I borrowed the CCIE book from a colleague and after reading the relevant section, I’m quite convinced the article is wrong.

Hello Paul

Thanks for the discussion. It’s always good to dig deep and find out what’s really going on in all aspects.

If the root port on SW1 goes down it MUST send TCNs. From the moment there is a topology change of any kind, TCNs are sent. This is a fundamental part of STP. However, at the same time, inferior BPDUs are sent as described in the article you sent to make STP re-converge correctly. The sending of TCNs and inferior BPDUs are not mutually exclusive.

Remember that in the stable configuration, SW2 had Fa0/14 as its root port. When it received the TCN from SW1, it was informed that it was the root port of SW1 that had gone down. Therefore, the new cost to the root bridge via that path is infinite i.e. unreachable.

So, it has to choose an alternate root port. It knows the cost via Fa0/19 is the next available option, so it changes its root port accordingly.

You’re right that a topology change alone is not enough to cause a root port to change unless that topology change informs a switch that its path to the root bridge is no longer available via the current root port. This is learned via TCN.

I hope this has been helpful!