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?
I don't recommend MST, Are you using RSTP?
Yes we have RSTP setup on the nexus 9372, and it is enabled on the meraki's
Check it out: https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...
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
You cannot add the Nexus switch on the dashboard.
What MS are you talking about on the topology?
The 2 that are directly connected to Nexus 9372 1.
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.
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?
@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, if you change the priority to 0 on the Nexus switches, does that involve any kind of downtime?
Yes, you will get a spanning tree election which usually lasts about 30 seconds.
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.
I'm not confident about this, I've seen and heard many scenarios where MST was an issue.
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:
The protocol is more complex than the usual spanning tree and requires additional training of the staff.
Interaction with legacy bridges can be a challenge. For more information refer, to the Interaction Between MST Regions and the Outside World section of this document.
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.
>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.
still need the 30 seconds or so for spanning tree election?
MST uses the same query style system as RSTP, so converges very quickly.
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?
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.