Spanning Tree Topology Change Notification (TCN)

(Brian C) #34

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…

(Rakesh N) #35

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?

(Rene Molenaar) #36

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.

(Paul H) #37

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?

(Paul H) #38

@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.

(Lazaros Agapides) #39

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!


(Paul H) #40

Thanks for the reply Laz.

According to this article, switches in a spanning tree topology send TCNs out of their root port. In the scenario, SW1’s port fa0/14 is not a root port therefore it shouldn’t send a TCN out of that port.

Or is it the case that if a switch detects that it’s root port has gone down, it sends a TCN out of designated ports instead?

These are the tiny little details that make STP operation very hard to master :slight_smile:

1 Like
(Rupesh D) #41

Hi Harris,
I tested myself the scenario, in the event if links towards root bridge or say rootport is down, it will first send inferior BPDU and when it figures out the Root switch via alternate port then that alternate port will become the root Port and then it will send Topology Change notification messgae on that.
here is the log below

Enter configuration commands, one per line.  End with CNTL/Z.
ESW2(config)#int f1/1
*Mar  1 00:39:59.363: STP: VLAN1 Fa1/1 -> blocking
*Mar  1 00:39:59.363: STP: VLAN1 we are the spanning tree root
*Mar  1 00:40:01.283: %LINK-5-CHANGED: Interface FastEthernet1/1, changed state to administratively down
*Mar  1 00:40:02.283: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/1, changed state to down
*Mar  1 00:40:16.051: STP: VLAN1 heard root  8192-c405.4364.0000 on Fa1/0
*Mar  1 00:40:16.051: current Root has 32768-c403.4f94.0000
*Mar  1 00:40:16.051:     supersedes 32768-c403.4f94.0000
*Mar  1 00:40:16.055: STP: VLAN1 new root is 8192, c405.4364.0000 on port Fa1/0, cost 57
*Mar  1 00:40:16.055: STP: VLAN1 sent Topology Change Notice on Fa1/0.

Below is the scenario i used

SW 1 (f1/0) --------------connected to F1/0 (Sw2)
SW1 (f1/1) --------------connected to F1/1 (Sw3)
SW2 (f1/1) --------------connected to F1/1 (SW4)
SW3 (F1/0) ----------------connected to F1/0 (SW4)
It is a box type connection, you can draw on paper
I shut down port f1/1 of sw2 going towards root switch (SW4) on port f1/1

(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.


1 Like
(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!


(Dominique R) #52

Hi Rene and staff,
thanks a lot to Laz for his last post which is a very good clarification when TCN is generated or not
Now, i would like to be clear with BPDU format
The BPDU format use the columns type and flag to handle the different types of BPDU

First with the column “type” you can distinguish configuration BPDU (with type 0x00) and TCN BPDU (with type 0x80)
BPDU TCN is a BPDU with type 0x80 and padding for the following columns

Then the TC BPDU (send by root bridge) is a special configuration BPDU (type 0x00) with flag LSB (that what i read). I dont know what LSB means: could you tell me ? In this case, one bit of TC BPDU flag (1 byte) is set to1: is it the bit 2^8 or the bit 2^0 ?

Then we have the BPDU TCA: this not a config BPDU, neither a TCN; just an acknowledgement of TCN to stop transmission of TCN (each hello time=2s) by the downstream SW to the upstream SW.
So what is the type of BPDU TCA ? i read MSB is the flag for BPDU TCA (i dont know what MSB means)
Could you clarify ?

(Lazaros Agapides) #53

Hello Dominique

Yes, the type field is used to determine if a BPDU is a configuration BPDU or a TCN BPDU. If it is a configuration BPDU, it will have a value of 0 and if it is a TCN, it will have a value of 0x80 (or 128 in decimal).

The flags field of a BPDU frame is made of eight bits or one byte. If the Least Significant Bit (LSB) of that byte is set to 1, then this indicates that the BPDU is a Topology Change (TC) BPDU. If the Most Significant Bit (MSB) of that byte is set to 1 then the BPDU is a Topology Change Acknowledgement (TCA), which is a response.

A BPDU TCA is considered a control BPDU.

I hope this has been helpful!