I have Cisco 3550 series switch which is frequently sending out TCNs to uplink switch causing port on uplink switch to block VLANs and move STP states from blocking to forwarding affected traffic flow.Is there way to fix this as the physical connection is clean and there is no potential loop.
If a switch is sending TCNs then the most probable cause is that the switch has indeed detected a topology change. Of course, a bug in the IOS may also account for this but that would be an unwarranted guess as of yet.
You are indicating that you are running the Rapid PVST. In such case, it is of utmost importance to configure all edge ports (i.e. ports connected to end stations) using the spanning-tree portfast command. Such ports are not influenced by TCNs and also their up/down state change does not generate a TCN. Often, this fact is forgotten, resulting in a Rapid PVST deployment that performs more poorly than the legacy 802.1D. Now, because the end stations (PCs, notebooks) often make up/down link transitions (restarts, reconfigurations, people coming and leaving, etc.), they may be the primary cause of your problems.
Note that this setting has to be applied on all switches in your network running the Rapid PVST, and on each edge port. For configuration simplicity, you may alternatively want to use the spanning-tree portfast default global configuration mode command that makes all ports currently running as access ports to be considered as edge ports.
Regarding the excessive TCN, you may also want to read this document - it may help you narrow down the problem:
Thanks for prompt response.The edge ports are all portfast.It is one uplink that is not stable.I have SW21(core)>(Access)Sw37(Receiving TCNs)>(generating TCNs)SW54(Access).This is one particular chain that is having issues.All the access ports are checked to be portfast.So ideally this should be the cause of the issue.If there is anything i am missing the info will be highly appreciated.
Personally I suggest using the show spanning tree vlan VLAN-ID detail on your switches to ascertain the source of those TCNs:
Switch# show spanning-tree vlan 987 detail
VLAN0987 is executing the ieee compatible Spanning Tree protocol Bridge Identifier has priority 32768, sysid 987, address 001b.8f8f.de00 Configured hello time 2, max age 20, forward delay 15 Current root has priority 33755, address 0009.e8ee.02c0 Root port is 44 (GigabitEthernet0/44), cost of root path is 4 Topology change flag not set, detected flag not set Number of topology changes 273 last change occurred 1w3d ago from GigabitEthernet0/1 Times: hold 1, topology change 35, notification 2 hello 2, max age 20, forward delay 15 Timers: hello 0, topology change 0, notification 0, aging 300
The highlighted line points you towards the source of the TCNs. On the switch that is positively identified as the source of the TCNs, use the following debug commands to further identify the cause of the TCNs:
debug spanning-tree events
debug spanning-tree switch pm
debug spanning-tree switch state
These debug should be relatively quiet in a stable topology so no large output or load should be generated.
I am very interested in learning whether you have found the cause. Please keep me informed.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...