12

We have about 20 vlans on a L2 network running Rapid PVST+ where the root bridge is a stack of Cisco's 3750 switches. I am a bit puzzled by the number of TCN notifications I receive on the switch..

The 3750 stack is the root for all VLANs and it receives TCN notifications on a daily basis (sometimes more, sometimes a little less). It receives the TCNs at the same time and on the same port for all VLANs. When I trace back where these TCNs come from with show spanning-tree detail | inc ieee|occurr|from|is exec, I end up on a switch (switch-b) with only 5 trunks configured and no access ports.

I cannot match an event like a link on this switch going up or down on the same time the TCNs are received. When I issue the above command on this switch the results tells me that the last topology change was much longer ago.

My conclusions:

The TCN sent must be trigged by an event on a trunk link or an entire switch because all VLANs received the topology change notification. It must be something local on switch-b.

What can be the reason for originating these TCNs? The 5 trunk links didn't change their state. It cannot come further downstream because the last topology change on switch-b doesn't match the last topology change on the core. The last topology change on switch-b is much longer ago.

Any thoughts?

Improve this question
2
  • Did you get any further with this? I am seeing similar. I suspect TCNs are sent out on trunks even if they don't participate in the VLAN making it trickier to track down. Even worse they seem to be forwarded across switches when the switch itself is not participating in that VLAN
    – user2056
    Jul 15, 2013 at 14:40
  • Actually not yet, i did found some switches with access ports with no portfast on it. But that stil isnt a real explanation for reveiving topology changes on al vlans at the same time..But strange enough i do get a lot less tcn's these last couple of days. Thats why my focus is on some other matters with more priority. I think the answer from dockmaster by simply do some debugging is a good one. Trace as close to the source and then do some debugging...
    – user209
    Jul 15, 2013 at 20:59

2 Answers 2

Reset to default
12

You should be able to simply debug the TCNs. In my case I recently debugged them using debug spann mstp tc (as I run MSTP), but also using debug spanning-tree events you will see them:

Jul 10 07:42:18 UTC: STP: VLAN0228 Topology Change rcvd on Gi1/0/9       <<< received
Jul 10 07:42:18 UTC: STP: VLAN0228 sent Topology Change Notice on Po10   <<< forwarded
Improve this answer
1

just had the same issues...and if you run portfast on all your access ports it will not send TCN messages and you do not receive the TCN message and it is not sent to all the switches....if you do not enable portfast on all your access ports and a device is down/up it will send a TCN message and flush arp on all your switches they will have to learn the MACS all over again....

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.