High rate of STP topology changes on port XX

JustinGA
Getting noticed

High rate of STP topology changes on port XX

hi everyone, i need some help with my meraki / nexus 9372  network.

 

On the merakis that are directly connected to the Nexus switch I see the message of "High rate of STP topology changes on port XX". 

 

I believe they are configured correctly, but i have attached a very low level jpeg of the network. 

 

I saw on another post that it was recommended that we set the Nexus switch with the command "spanning-tree mode mst"... does anyone have experience doing this command in this environment? diagram.jpg

18 Replies 18
alemabrahao
Kind of a big deal
Kind of a big deal

I don't recommend MST, Are you using RSTP?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
JustinGA
Getting noticed

Yes we have RSTP setup on  the nexus 9372, and it is enabled on the meraki's

alemabrahao
Kind of a big deal
Kind of a big deal

Check it out:  https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
JustinGA
Getting noticed

So in my case, i have 2 redundant Cisco 9372... 

 

would i need to add them both in my dashboard? 

 

currently, this is all we have in the meraki dashboard 

JustinGA_0-1678891921280.png

 

alemabrahao
Kind of a big deal
Kind of a big deal

You cannot add the Nexus switch on the dashboard.

 

What MS are you talking about on the topology?

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
JustinGA
Getting noticed

The 2 that are directly connected to Nexus 9372 1. 

alemabrahao
Kind of a big deal
Kind of a big deal

I suggest you to perform a packet capture or review the entire switch priority, or even check if there is no other switch on the network that could be causing the alerts.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
JustinGA
Getting noticed

Alemabrahao, i went through all my switches.. they all identify the same switch as the Root, and it has the lowest priority.  Any other suggestions? 

 

cmr
Kind of a big deal
Kind of a big deal

@JustinGA I think the 2960s might all have a priority of 32768 as well.  Personally I would change the primary Nexus to have a priority of 0 and set the MSs to more than 32768.  Below are examples of one of our (all MS) sites and one with a Catalyst core (which has 0 as the priority):

 

cmr_0-1678899917964.png

cmr_1-1678900006598.png

 

 

If my answer solves your problem please click Accept as Solution so others can benefit from it.
JustinGA
Getting noticed

CMR, if you change the priority to 0 on the Nexus switches, does that involve any kind of downtime?

 

cmr
Kind of a big deal
Kind of a big deal

Yes, you will get a spanning tree election which usually lasts about 30 seconds.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
PhilipDAth
Kind of a big deal
Kind of a big deal

I would recommend mst - and here is why.

 

Cisco Enterprise switches calculate RSTP per VLAN - while Cisco Meraki follows the standard, and only calculates it on the native VLAN (also called single instance).

 

It is very easy to end up with a network of mixed switches with two different spanning tree roots, and all the problems that brings.  Often it makes things intermittent.  Switching environment will work fine for a week, a month - and then you'll get terrible performance for a day, perhaps a complete outage - and then the next day every seems to be fine again.

 

I have run into this too many times now - so as soon as I add a Meraki switch to an environment with Cisco Enterprise switches - I immeidately switch them all to mst to save myself the grief I know is likely to be coming up.

alemabrahao
Kind of a big deal
Kind of a big deal

I'm not confident about this, I've seen and heard many scenarios where MST was an issue.

MST Case

MSTs (IEEE 802.1s) combine the best aspects from both the PVST+ and the 802.1q. The idea is that several VLANs can be mapped to a reduced number of spanning tree instances because most networks do not need more than a few logical topologies. In the topology described in the first diagram, there are only two different final logical topologies, so only two spanning tree instances are really necessary. There is no need to run 1000 instances. If you map half of the 1000 VLANs to a different spanning tree instance, as shown in this diagram, these statements are true:

  • The desired load balancing scheme can still be achieved because half of the VLANs adhere to one separate instance.

  • The CPU is spared because only two instances are computed.

 

 

Map Half of the 1000 VLANs to a Different Spanning Tree Instance

From a technical standpoint, MST is the best solution. From an end-user perspective, the main drawbacks associated with a migration to MST are:

 

MST Region

As previously mentioned, the main enhancement introduced by MST is that several VLANs can be mapped to a single spanning tree instance. This raises the problem of how to determine which VLAN is to be associated with which instance. More precisely, how to tag BPDUs so that the receiving devices can identify the instances and the VLANs to which each device applies.

The issue is irrelevant in the case of the 802.1q standard, where all instances are mapped to a unique instance. In the PVST+ implementation, the association is:

  • Different VLANs carry the BPDUs for their respective instance (one BPDU per VLAN).

The Cisco MISTP sent a BPDU for each instance, with a list of VLANs that the BPDU was responsible for, in order to solve this problem. If by error, two switches were not configured correctly and had a different range of VLANs associated to the same instance, it was difficult for the protocol to recover properly from this situation.

The IEEE 802.1s committee adopted a much easier and simpler approach that introduced MST regions. Think of a region as the equivalent of Border Gateway Protocol (BGP) Autonomous Systems, which is a group of switches placed under a common administration.

 

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
PhilipDAth
Kind of a big deal
Kind of a big deal

>MSTs (IEEE 802.1s) combine the best aspects from both the PVST+

 

On the Cisco enterprise side it is important to only create a single instance MST (so all VLANs are mapped to the same instance).  Do nothing more than "spanning-tree mde mst" - nothing else, and it will be rock solid stable.

JustinGA
Getting noticed

still need the 30 seconds or so for spanning tree election?

 

 

PhilipDAth
Kind of a big deal
Kind of a big deal

MST uses the same query style system as RSTP, so converges very quickly.

JustinGA
Getting noticed

PhilipDAth, the 2 9372 switches are backplanned together... but switch 1 has the lowest priority.. im assuming i just need to run that command on there?

 

 

Brash
Kind of a big deal
Kind of a big deal

Seconding this.

 

Mixed spanning tree modes can get real messy very quickly. Converting to MST would be the way to go - just do your research and plan it out.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels