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!