Spanning Tree Topology Changes

[NOV Noobie]

Greetings,

I am currently seeing from my root switch that the "Topology Change Count" is constantly incrementing every 90 seconds or so, I have forced RSTP on all the switches on the network, (to make sure MST was not acting funny) but the topology change counter still increments. I lowered the priority on my root switch to make sure that there is no fighting over who is the root switch and made sure that there were no loops on the network (I.E. end users bringing their HUB/Switch from Home and plugging them in) but still no luck. With that said I have 2 questions

First: Are there any commands to see from what port are these Topology Changes coming from?

Second: Any suggestions? :)


Thanks in Advance

[Matt Hobbs]

What I've done in the past is to first capture a 'show span detail', wait for the next topology change and then capture it again.

Compare the 2 files (examdiff is a good program for this) and you should then be able to find out where the TC changes are coming from.

Next go to that switch and follow the same process.

This method is very tedious though, instead of doing this I would usually suggest you make sure your edge-ports are set correctly (RSTP sets edge-port yes by default so you should be okay), and then start to use some of the newer features on your edge ports such as:

bpdu-protection
bpdu-filter
loop-protect

[Mohieddin Kharnoub]

Hi

Additional to Matt's information, i usually use Show Span Detail

Then i will have a look on all the ports one by one to find the TC field for top values.

I will then try to disconnect it, or enable bpdu-filter.

Good Luck !!!

[Holger Hasenaug]

Beginning with K.12.14 on the 5400zl, 3500yl, 6200yl switches you have add. commands to troubleshoot STP issues:


show spanning-tree debug-counters [instance | ports] (Show spanning tree debug counters information.)

spanning-tree clear-debug-counters [instance | ports] (Clear spanning tree debug counters.)


show spanning-tree root-history
cst Show CST Root changes history.
ist Show IST Regional Root changes history.
msti Show MSTI Regional Root changes history.

[OLARU Dan]

After convincing myself that there is no loop in the network (uplink ports shutdown by STP action), I would normally get rid of the STP altogether in the core switches. I would keep it running only on the edge switches (not the core switches!) to make sure that any would-be non-managed switche have a patch cable connected with both its ends to it (it will kill the network, but if somehow STP manages to shutdown the uplink to the non-managed switch, then you're off the hook)

[OLARU Dan]

After convincing myself that there is no loop in the network (uplink ports shutdown by STP action), I would normally get rid of the STP altogether in the core switches. I would probabily keep it running only on the edge switches (not the core switches!) to make sure that any would-be non-managed switche have a patch cable connected with both its ends to it (it will kill the network, but if somehow STP manages to shutdown the uplink to the non-managed switch, then you're off the hook)

[OLARU Dan]

BTW: if your STP is configured correctly in ALL the participating switches, then the behaviour you describe would indicate some intermittent loop(s) taking place in the network.