- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
High Rate of STP topology changes on port
we are seeing "High Rate of STP topology changes on port" when we connect a Meraki switch to a Cisco network. Both cisco and Meraki use the RSTP spanningtree mode. In the switch settings we can change the root bridge setting to a Meraki switch only however the root bridge (core) is a cisco switch. this happens when we need to make the port a trunk port (access ports seem to work fine). Anything we can do to correct the spanningtree issue?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks but sorry to say this sucks. Meraki did a good job making user friendly network devices. however it could not make it work more efficiently with RSTP connecting to Cisco switches?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @hmc250000 , you’ll need to configure your Cisco network for MST. Once done it’ll play nicely. It’s literally a couple lines of config.
https://www.linkedin.com/in/darrenoconnor/
I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's a pain having to make that change on about 30 switches just to add 1 or 2 meraki switches.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
if youre using rapid-pvst just include vlan 1 in the trunk between the Catalyst upstream switch and MS. This will ensure that the stp formatted BPDU makes it to the RSTP process and prune any unused VLANs from the trunk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
vlan 1 is included, I did not remove it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@hmc250000, what @WirelesslyWired said is true, so long as the Meraki switches are not 'between' two Cisco Catalyst switches - i.e. you don't have Catalyst -> Meraki -> Catalyst (Root Bridge). As well as including VLAN1 on the trunk, I believe it also needs to be the Native VLAN, and you need to make sure the Cisco Catalyst is the Root Bridge. I believe the Cisco Catalyst sends a Standard BPDU on the Native VLAN, for VLAN 1 (its a bit more complicated than that, but ultimately that's the easiest configuration to achieve).
If you do have the Meraki switches between the Catalyst switches then the only real option is to move the Catalysts to MST as has already been said.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
the Meraki Sw is on the edge and not inbetween Cisco switches. Not sure if I'm doing anything wrong here but this is what it looks like.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is showing up in the event log? If Port 25 is your only connection to the Cisco Catalyst switches then in general you shouldn’t be seeing that error. Check the STP Bridge Priority for the Meraki switches, by default it is 32768, make sure that the root bridge Cisco Catalyst has a priority lower than this on VLAN 1, like 8192 (the Cisco Catalyst defaults to 32768 too).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, the root bridge has a lower priority and is the core switch in the Cisco network. The bridge settings in the Meraki switch settings were not changed. We cannot change it to a cisco switch anyway. Sorry failed to mention we have plugged in 2 Meraki switches. Both are connected to separate cisco switches on the edge.
These are the latest events I'm seeing.
7 12:45:06 | Port STP change | Port 13 designated→disabled | |
Oct 7 12:45:06 | Port status change | port: 13, old: 1Gfdx, new: down | |
Oct 7 12:44:48 | Port STP change | Port 13 disabled→designated | |
Oct 7 12:44:48 | Port status change | port: 13, old: down, new: 1Gfdx | |
Oct 7 12:44:25 | Port STP change | Port 7 disabled→designated | |
Oct 7 12:44:25 | Port status change | port: 7, old: down, new: 1Gfdx | |
Oct 7 12:44:25 | Port STP change | Port 5 disabled→designated | |
Oct 7 12:44:25 | Port status change | port: 5, old: down, new: 1Gfdx | |
Oct 7 12:44:25 | Port STP change | Port 2 disabled→designated | |
Oct 7 12:44:25 | Port status change | port: 2, old: down, new: 1Gfdx | |
Oct 7 12:44:24 | Port STP change | Port 1 disabled→designated | |
Oct 7 12:44:24 | Port status change | port: 1, old: down, new: 1Gfdx | |
Oct 7 12:44:21 | Port STP change | Port 7 designated→disabled | |
Oct 7 12:44:21 | Port status change | port: 7, old: 1Gfdx, new: down | |
Oct 7 12:44:21 | Port STP change | Port 5 designated→disabled | |
Oct 7 12:44:21 | Port status change | port: 5, old: 1Gfdx, new: down | |
Oct 7 12:44:21 | Port STP change | Port 2 designated→disabled | |
Oct 7 12:44:21 | Port status change | port: 2, old: 1Gfdx, new: down | |
Oct 7 12:44:20 | Port STP change | Port 1 designated→disabled | |
Oct 7 12:44:20 | Port status change | port: 1, old: 1Gfdx, new: down | |
Oct 7 12:44:10 | Port STP change | Port 3 disabled→designated | |
Oct 7 12:44:10 | Port status change | port: 3, old: down, new: 100fdx | |
Oct 7 12:44:07 | Port STP change | Port 3 designated→disabled | |
Oct 7 12:44:07 | Port status change | port: 3, old: 100fdx, new: down | |
Oct 7 12:44:01 | Port STP change | Port 7 disabled→designated | |
Oct 7 12:44:01 | Port status change | port: 7, old: down, new: 1Gfdx | |
Oct 7 12:44:01 | Port STP change | Port 5 disabled→designated | |
Oct 7 12:44:01 | Port status change | port: 5, old: down, new: 1Gfdx | |
Oct 7 12:44:01 | Port STP change | Port 1 disabled→designated | |
Oct 7 12:44:01 | Port status change | port: 1, old: down, new: 1Gfdx |
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is on those ports? It looks like you are seeing the STP changes because the ports are going up and down - they’re flapping. Every time a port goes up or down you see the corresponding change in STP, either moving to designated, or moving to disabled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Access points are plugged into those ports. The AP's worked fine when they were plugged into the Cisco switches.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry I hope I'm not missing anything here. RSTP Meraki is the same thing as rapid-pvst in cisco right? I assume they are compatible?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nope, RSTP is a standard, and rapid-pvst is a Cisco proprietary protocol based on the standard. The two generally play nice together if you have a Cisco switch as the STP root and any Meraki switches are only at the edge, and so long as you don’t go Catalyst - Meraki - Catalyst in the spanning-tree. Otherwise you’ll need to implement MSTP on the Catalyst switches, which is a standard, and should play nice/better with the Meraki switches.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is it a possibility you just have alot of STP TCN BPDU's in your Cisco network that the Meraki switches are just complaining about?
If you have many TCN's in your Cisco network you should ensure all endpoint ports are running in portfast/edge mode so a pc shutting down or booting does not cause a TCN throughout your entire network.
Only switchports running between switches or switchports to an MX should not be in portfast/edge mode.
