Rapid PVST issue!!!

[LAN Operations]

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.

Karan

[Peter Paluch]

Hello Karan,

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:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080136673.shtml#topology_change

Best regards,

Peter

[LAN Operations]

Hi Peter

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.

Karan

[Peter Paluch]

Hello,

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.

Best regards,

Peter