STP Topology Changes - Why

[Bill]

I have a situation where some switches are showing STP topology changes, while others are not.
They are in the same STP domain.

I have a Core-Distribution-Access topology.
Dual 9500’s at the core – this is the Root.
Dual 9500’s for distribution.
Various switches for Access – Mostly Meraki.

The Access switches are mostly Meraki’s – C9300’s and MS130’s.
And one or two legacy Cisco’s.

The MS130’s are showing topology changes, while the C9300’s are not.
I did run some debugs on the core, and I am seeing some STP events.
But I cannot determine why.

In the logs on the core switch, I am seeing this.
RSTP(1): starting topology change timer for 35 seconds
And timing seems to coincide with the Meraki alerts.

So there is something happening, but how can I find the source of these events?

Thanks

[Mark Elsen]

    - @Bill             For starters ,  you should be using a common STP algorithm on all switches (=?)

  M.

[Bill]

Good point.
The Cisco root is running RSTP (per vlan).
I believe the Meraki's also run RSTP but only for Vlan 1.
I have seen suggestions that the Cisco root should run MSTP.
I was hoping to find the source of the STP events so I could better understand what is happening.
If there is some external event happening, not sure changing the algorithm will fix it.

[Bill]

Cisco Distribution switch is also running RSTP

[Mark Elsen]

   - @Bill                     >....I believe the Meraki's also run RSTP but only for Vlan 1.
                                             Spanning tree should be used and or configured  for all vlans

                                 >....I have seen suggestions that the Cisco root should run MSTP.
                                     Root and none root devices  must use the same algorithm everywhere

M.

[Bill]

Pretty sure Meraki's don't support per-vlan STP, nor MSTP.

[Raphael_L]

And timing seems to coincide with the Meraki alerts

What are the Meraki alerts ? Topology changes ?

Can you look at the Meraki logs ? I would assume the Meraki switches are being root for a moment

[Bill]

Meraki Dashboard does show STP topology changes under the uplink port.
But the event log shows nothing.
If the Meraki is becoming root, it shouldn't - based on Priority settings.
I do have a ticket open with Meraki but nothing helpful (yet).
What I find strange is that only the Meraki MS130's show the issue in the Dashboard.
The Meraki 9300's do not, even though they are connected similarly.
No users have complained. So I am not sure if this is just cosmetic.

[Bill]

On the Cisco core, I am running debugs.
STP Events and STP Root, and STP General.
But these don't give a lot of info.
Are there debugs I can run that will show more detail?
I see debug STP all - but a little hesitant to run that one.

[Bill]

I found the command I was looking for.
I wanted to find the source of the TCNs.
That command is 'show spanning-tree vlan 1 detail'
With this I was able to find the issue.
There was a bad Access Point that was flapping.
The AP flaps coincided with the TCNs.
We shutdown the port, and the high rate of TCNs stopped.
The APs are connected on Trunk ports.
I must admit, I didn't realize bouncing an AP trunk port would cause a TCN.
But looks like it does.
I am still not sure why the Meraki 9300's do not show a TCN when the Cisco's and Meraki MS130's do.
Meraki support has not provided an answer for that.

[Htonieto]

---

@Bill wrote:

There was a bad Access Point that was flapping.
The AP flaps coincided with the TCNs.

---

Faced this very same situation in the past, after that we changed all the AP ports to the following configuration, this will protect you for the TCNs, the key point is the portfast, everything else is optional.

interface <>
description ACCESS_POINT
switchport mode trunk
switchport trunk native vlan <vlan_id>
switchport portfast trunk
spanning-tree bpduguard enable
spanning-tree guard root
no lldp transmit
no lldp receive
exit

---

@Bill wrote:

I must admit, I didn't realize bouncing an AP trunk port would cause a TCN.
But looks like it does.

---

Yes, because it's just a trunk port and STP will kick in, so any action that cause the interface to bounce will generate, AP booting, reloading etc.

[Bill]

Thank you Htonieto
Good info