Showing results for 
Search instead for 
Did you mean: 
Join Customer Connection to register!

802.1d - unexpected TCNs

Dear guys,

as far as I read only port up/downs can trigger TCNs.

I have got 4 switches connected to each other.

The direct link to the root bridge breaks down. The other switch (switch2) now asumes

itself as root. I guess that's the reason why it does not start to send a

tcn. But I don't understand why it does not receive a tcflagged bpdu from

the old root coming from the other path.

switch2 sets the topology change flag when it sends out its bpdus with its

own id as root id. As it receives a better bpdu (without tc-flag). It sends

a TCN.

Do you have an explaination why the TCN is sent 20 seconds after the port

went down? Afaik receiving a better Bpdu should't result in sending TCNs.

Short overview:

link failure

10x switch2-> switch1 ConfBPDU: (root=switch2)+TCFlag

1x switch1<- switch2 ConfBPDU: (root=switch3)

1x switch2 > switch1 TCN

Thank you very much for any tipps!!

best wishes from austria =)


Giuseppe Larosa
Hall of Fame Master

Hello Silvia,

>> Do you have an explaination why the TCN is sent 20 seconds after the port

went down?

max-age timer applies to 802.1D switch2 waits 20 seconds that is the max-age timer before reacting to the missing BPDUs on the previously root port.

Switch2 then sends out its BPDUs out its other ports with TCN flag set and claiming to be the root bridge.

In this way it advertises the others that it has seen a topology change.

When it receives BPDUs with a better lower bridge id it stops to advertise itself as the root.


TCN travels upstream until it reaches the root bridge that then (the root bridge) sends out its own BPDUs with TCN set for 15+15 seconds.

Other switches move cam aging time from 300 seconds to 15 seconds for the potential multiple moves (at the cam level )

Hope to help


Hi Giuseppe,

thank you for writing back so quickly.

You brought already some light in this issue :-) ... but there are still some inconsistencies for me ...

I think that didn't come out in my last message:

switch2 sends straight away (without waiting for timers) config BPDUs with TC flag set.

But I don't understand where's the point in sending the TCN _after_ it has send config BPDUs with the TC flag set?



Hello Silvia,

I agree that it looks like strange to send TCN set after max age expiration.



reviewing BPDU format the following can be noted:

BPDU with TC flag set are sent by root bridge.

So in your case they are set in configuration BPDUs sent by SW2 and claiming SW2 to be the new root bridge.

TCN is set in a BPDU sent upstream by a non root bridge device to advise the root bridge of a change in topology.

So now what is strange for me is that SW2 shouldn't send out those BPDUs with TC flag set before max-age timer expiration.

This is probably done to reduce convergence time.

the last TCN is set as a form of acknowledgement that SW2 has given up to its attempt to be the new root.

being a non-root this a change so SW2 sends out BPDU with TCN set.

Hope to help


It's because of the difference between TCN and TC I guess. When you need to notify a change:

- if you are the root bridge, you just set TC in your BPDUs.

- if you are not the root bridge, you send a TCN on your root port. This TCN is acknoledged to you by the upstream bridge and then relayed toward the root bridge via another TCN. Eventually, the TCN reaches the root bridge that sets TC.

So basically, when switch2 thinks it's the root, it sets TC. When it realizes it's not the root (by receiving a superior BPDU), it switches to the other mode of expression, which is sending TCN on its root port.

Check: for information on the whole process.