Spanning Tree Topology Change Notification (TCN)

(Pradeep M) #42

Hi All,
Everybody talks about a link breaking down when it comes to Topology Change. Can i know what exactly happens when a new switch is added to current STP topology.

  1. What would be the first state of new switch port and how it works?(I know it starts from blocking state, I want to know the series of events that happens between those two ports - old and the new one)
  2. I am pretty sure that TCN message won’t be sent to root by adjacent switch because nothing to be erased from MAC Addr table(whole purpose of TCN message). Please confirm my understanding on this!
  3. will there be a RB election process again?

Thanks for your reply in advance!
I will also work it out in my lab by enabling “debug spanning-tree events” command.

(Lazaros Agapides) #43

Hello Pradeep

For the following, we assume that we are using simple STP (802.1D). If you have a stable topology where STP has converged, and you add a new switch to one of the switchports of the switches already in the topology, then the following would happen:

  1. The new switch considers itself the root bridge. The port on which it is connected to the other switch will begin briefly in the blocked state as you mentioned.
  2. Next, that port will transition to the Listening state. During the listening state, BPDUs are exchanged. Note that both ports on both ends of the link will be transitioning from state to state at the same time assuming the timers are the same, so both ends will be in the Listening state as they exchange BPDUs. During the BPDU exchange, the new switch will learn if it is indeed the root bridge or if the current root bridge will remain, depending on the priority values and the MAC address.
  • If the new switch is not the root bridge, its port will assume a role of root port while the interface at the other end of the link will assume a role of designated. (assuming no L2 loop is created with the new switch).
  • if the new switch is the root bridge, the port becomes designated and superior BPDUs are sent on the link which will cause the rest of the switches to re-converge their STP orientation.
    The ports continue to transition until the topology converges.

The conditions under which a TCN is sent are very specific and they are stated in detail by Cisco. Cisco states:

A bridge has detected a topology change:

  • When a port that was forwarding is going down (blocking for instance).
  • When a port transitions to forwarding and the bridge has a designated port. (This means that the bridge is not standalone.)

Once a topology change has been confirmed, a TCN will be sent.

The process to send a notification to all bridges in the network involves two steps:

  • The bridge notifies the root bridge of the spanning tree.
  • The root bridge “broadcasts” the information into the whole network.

It is only under those circumstances that a TCN is sent. It does not specify that a TCN is sent only if there are actual MAC addresses in the MAC address table of the new switch that is being connected. It doesn’t take this into account. A TCN will be sent and the aging time will be reduced regardless of whether or not there are actually new MAC addresses to be learned.

Yes there will be. As stated at the beginning, BPDUs will be exchanged and if the priority and MAC address of the new switch are indeed superior, then yes, an election and a subsequent STP reconvergence will take place.

I hope this has been helpful!


(Syed R) #44

Hi Rene,

One question. What’s the point of clearing the ARP cache (default timeout 300s) on a TCN? Once an address expires, don’t you just fetch it from the ARP table again (timeout 4hours)? Or do the 15 second timers apply to both the ARP cache and table?

I am guessing that there is no ARP even if the 15 seconds duration expires since the ARP timeout is 4 hours.

Any clarification here would be helpful.


(Lazaros Agapides) #45

Hello Seyed

When a TCN is recieved, it’s not the ARP table that is cleared, but the MAC address table. The ARP table remains intact. The purpose of clearing the MAC table is that MACs of devices not directly connect to a particular switch may appear to be associated with an incorrect port on that switch if a topology change takes place. If this is the case, you have to wait 300 seconds for the MAC address entry to expire before that particular MAC address is correctly updated in the table of that particular switch. The result is having STP reconverge in several seconds, but having to wait up to 300 seconds for the correct MAC address table entries to converge.

I hope this has been helpful!


(Ignacio R) #46

my question is when the switches set the mac address table aging time to 15 seconds?
when they receive a TCN from any switch? When they receive a TCA from root bridge or when they receive a TC from the root bridge?
Thanks in advance.

(Lazaros Agapides) #47

Hello Ignacio

According to this Cisco documentation, aging time is reduced to 15 seconds by switches when they recieve the TC from the root bridge.

I hope this has been helpful!


(Pradeep M) #48

Thanks Laz,

sorry for late reply from my side. what you have explained is perfect and my professor also told the same. Even i told the same answer in one of my interview as well!

Thank you

(Lazaros Agapides) #49

Hello Pradeep

Great to hear that I was of help! Always here for anything else you need.


(Vaughan-Reese J) #50

Hi Rene,
Based on your explanation and examples a TCN is generated any time a port goes up and down. In the case of a link that goes down between two non-root switches, which one of the switches will generate the TCN toward the root bridge or will both?

(Lazaros Agapides) #51

Hello Vaughan

According to Cisco, in the original STP specification, a TCN will be generated:

  • When a port that was forwarding is going down (blocking for instance).
  • When a port transitions to forwarding and the bridge has a designated port. (This means that the bridge is not standalone.)

Now there are two scenarios. Let’s look at this topology, where all switches are interconnected as shown and the red X’s show which ports are blocked by STP:

Now if the link between SW1 and SW3 goes down, SW1 will send a TCN because one of its ports went down. SW3 will not be able to send a TCN, since the port that went down was the port through which it had connectivity to the root bridge (and to the network itself). SW3 has thus lost connectivity, at least until STP reconverges. So in this scenario, only SW1 will send the TCN and not SW3. However, when STP reconverges, we get the following new topology:

In this case, a port on SW3 (that connects to SW4) has transitioned from blocking to the forwarding state and thus a TCN will be sent via that interface to SW4 and onward to the Root. Note however, that the port of SW4 connected to SW3 has not changed states, thus SW4 will not send a TCN.

Now for the second scenario, let’s go back to the original STP topology and imagine this time that the link between SW3 and SW4 has failed. Remember, SW3 had this port blocked:

In this case, only SW4 will send the TCN. This is because SW3 had its port in the blocking state and it has changed to the down state. By definition, TCNs are not generated in such a case. However, the port of SW4 was in a forwarding state, even though its counterpart on SW3 was blocked. This transitioned to the down state, and thus SW4 will generate a TCN.

A link that has one end blocked by STP will have the other end in a forwarding state. So if the link goes down, that port will have moved from a forwarding state to a down state, which would generate a TCN.

I hope this has been helpful!