Hi Huw,
It seems as if the Dell switches were not running the per-VLAN RSTP variant. That would mean that your Dell switches are most probably running plain RSTP without VLAN support. I now have a hypothesis that this may be at the core of the issues you are seeing. Let me elaborate.
Cisco switches use per-VLAN STP (or RSTP) variants, running a separate STP instance for each VLAN. To provide interoperability on trunks, STP instance for VLAN1 sends and receives normal IEEE-compatible BPDUs and is therefore able to seamlessly interoperate with all other switches out there, even if they do not speak per-VLAN STP. In addition, all per-VLAN STP instances send and receive their per-VLAN BPDUs in a slightly changed format, and most importantly, addressed to a different group MAC address than normal IEEE BPDUs. To switches that do not support the per-VLAN STP, these per-VLAN BPDUs are just multicast frames flooded throughout the network and not processed by them.
This flooding of per-VLAN BPDUs by non-per-VLAN-STP-aware switches is crucial to understanding what could be happening in your network. From the viewpoint of a Cat2960 switch, BPDUs for VLAN1 arriving through a Port-channel are sourced by the immediate neighboring Dell switch. However, per-VLAN BPDUs arriving through the same Port-channel are sourced by some other Catalyst switch in your network, possibly several "switch hops" away, not by the Dell - the Dell just floods them. Now, if there is a topology change somewhere in your network that affects some other Catalyst switch or switches, they may start sending BPDUs from their different ports until the network stabilizes into a new loop-free topology. Because these BPDUs - quite possibly sourced from different ports on Catalyst switches - are just flooded across the Dell switches, they will all arrive over the same Port-channel, and they trick the EtherChannel Misconfig Guard into thinking that the opposite device is not treating the ports as bundled.
The output of the show spanning-tree root command from the Cat2960 suggests that most probably, the Dell switches do not run per-VLAN RSTP - otherwise, they would become root switches in all VLANs. You can see that while VLAN1 has a Dell-based root switch (based on the OUI of 90:b1:1c in the MAC address), all other VLANs use Cisco switches as their respective roots - and even more, VLAN1016 has a different root switch than the other VLANs. All VLANs that have Cisco switches as their root switch in addition have their root switch priority set to 32768 (subtract the VLAN number from the priority shown in the output). Clearly, this is the default configuration of a Cisco switch. These differences indeed suggest that the Dell switches are not running per-VLAN RSTP.
I believe you should start the RSTP-PV (as Dell calls it) on all your Dell switches. According to the interoperability document you have referenced, the Dell switches should be configured with:
spanning-tree mode rapid-pvst
All your Dell switches should be configured with this command. I recommend to perform this change over a maintenance window, as there may be a transient connectivity outage. In addition, make sure that a reasonable switch becomes the root switch for all VLANs. Perhaps the VLT switches should be configured for this. The command should be fairly simple:
spanning-tree vlan 1-4094 priority 0
Just in case you want to proceed with the debugs as well, the debugs will indeed be visible in the show logging command on the Catalyst - but I recommend configuring the buffer for the logs to be bigger and to store all messages including the debugs:
logging buffered 100000 debugging
This command on Catalyst switches will make sure there is 100 Kbytes reserved for the log buffer, and all messages including the debugs will be stored there.
I suggest starting the RSTP-PV on your Dell switches as the first step and seeing if the issue stops occurring.
Best regards,
Peter
