I did update to 11.31 this morning, but the STP flapping continues. Noticed this upgrade did not reboot the switches, and did not show a progress bar on the local GUI of each switch as it usually does. Also, nothing on the logs about the firmware upgrade. I really wish Meraki would make the logs more useful.   Meraki tech suggested the follwing Disable bonded nics in our Cistrix xenservers. We had about 4 hosts with bonded nics (active-active) going to multiple switches. This causes a VM's mac to flap quickly between those nics when the host rebalances the traffic. It pins mac address hashes to each nix so that each VM is always on the same nic, but if traffic is too much on one nic, it rebalances all connections every 30 mins. I dont see why this would cause STP flapping since none of these VMs or hosts are talking STP and the ports that are STP-flapping are not any of these ports where the bonded nics were. But Citrix does warn that bonded nics should go to the same switch because some switches cannot tolerate the mac flapping during rebalancing and so I changed the bond type to active-passive, where only 1 nic is used, and I disabled the switch ports for all but 1 nic on each of those servers. The STP flapping continued, though I dont see anymore UDLD alerts (for the last 3 days). Re-created the aggregate groups. The 4 switches I have are not stacked, they are connected to each other with 4-8 cables each which are aggregated. Those aggregate ports are what I see being flapped by STP currently about every hr or so. The tech wants me to de-aggregate the groups and aggregate them again. I have not tried this yet. ... View more

According to the tech CPU was still high so he disabled some DNS inspection:   "I did notice a spike in the CPU after the update as well. I have disabled DNS and MDNS inspection on the core switch " SW1A "since we had noticed an unusual amount of DNS traffic during the pcaps taken on the switch."   I am seeing less of the UDLD alerts, but the 3-4 alerts from the last few days have caused network blips and alerts to come out at the same time. I do still see a ton of STP alerts about it changing the aggregate ports that interconnect the 4 switches, something like 4-25 times per hour with no alerts about network issues.    I also noticed that there is already a new version 11.31 thought it doesnt list this particular issue, here are the release notes:   Alerts MS210/225/250 switches cannot forward IPv6 Router Advertisement and Neighbor Solicitation packets when flood unknown multicast is disabled (has always been true) MS 11.31 is identical to MS 11.30 for all models EXCEPT the MS390 Additions Support for MS125, MS355, and MS450 Series switches Support for MS390 Series Switches Support port bounce AVP for RADIUS CoA (Cisco:Avpair="subscriber:command=bounce-host-port") Support MLD Snooping (currently enabled/disabled based on IGMP Snooping configuration) Event logging for errors with ECMP routes Support use of alternate interface to source DHCP Relay, RADIUS, SNMP and Syslog traffic Improve stability during high inbound PIM Register load on MS350/355/410/425/450 series switches STP BPDU inter-arrival monitoring CoPP hardening for DNS, MDNS snooping on MS210/225/250/350/355/410/420/425/450 series switches Bug fixes MS390 switches do not support port mirroring Known issues MS390 series switches Max MTU is limited to 9198 bytes MS390 series switches do not display stackport connectivity status in dashboard MS390 series switches will not display packet details in the DHCP Servers page MS390 series switches do not support the 'next-server' or 'bootfile' parameters in DHCP messages Rebooting a single switch in an MS390 stack will reboot the entire stack LLDP frames from MS390 series switches will use a single system name instead of the Dashboard given name MS390 series switches will not display the advertising router ID for OSPF MS390 series switches with OSPF enabled will default to an IP MTU of 1500 bytes on every OSPF enabled interface MS390 series switches do not support the multicast routing livetool Stacked MS390 series switches do not report traffic/client analytics correctly in all cases MS390 series switches do not support tagged traffic bypass for voice on ports with a Multi-Auth access policy Dynamic VLAN assignment from a RADIUS server on MS390 series switches must already be an allowed VLAN on the port for it to function MS390 series switches may not display link state on links at mGig speeds (2.5G, 5G) MS390 series switches do not currently support the following features: VRRP, SM Sentry, Syslog server, SNMP, Traceroute, IPv6 connectivity to dashboard, Meraki Auth, URL Redirection, MAC Whitelisting, RADIUS testing, RADIus Accounting Change of Authorization, QoS, Power Supply State, PoE power status/usage, ARP entry on L3 switch can expire despite still being in use (predates MS 10.x) SM Sentry does not support Windows based clients (predates MS 10.x) MS425 series switches do not forward frames larger than 9416 bytes (predates MS 10.x) MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10.x) ... View more

I had to call support by phone to get someone to move the case forward. The phone tech said that he noticed 97% cpu usage on my core switch. I wish they expose that info in the portal, all I can see as far as health for the switch is  a nice green "Healthy", meanwhile CPU is at 97% and ports are flapping in the logs. He thinks the CPU might be causing ports to go down and then generating the UDLD and STP alerts. He asked me to update to the latest (11.30) which I did this morning, but still see the same flapping in the logs, and I am waiting to a support tech to tell me what the CPU looks like now. He also cannot explain what he is seeing and thought it might be a performance bug (hence he asked me to upgrade).  To clarify, in the logs the ports that are flapping are the 16 ports that connect 3 switches to my root switch and they are only alerting from the perspective of the other 3 switches, the root switch sees no issues with the his end of those 16 connections (its own 16 ports). There are another 8 ports that connect 2 of those switches to the secondary root switch, but those are disabled (correctly) by STP and are not seen flapping in the logs. These ports are aggregated what I usually see in the logs is that a few of the individual ports alarm about becoming unidirectional (alert by UDLD, no enforcement, means BPDU packets only going in one direction), and then back to bidirectional right away. Then I see STP cycle the entire aggregate port between root, alternate or disabled. This is constantly happening on the logs, but I only see a measurable outage when lots of UDLD alerts appear together. ... View more

Same here, my Case 04772658. The Meraki support rep so far has done nothing but say that these things happen when the port or cable are bad. But there is no way 16 ports on 3 diff switches are bad at the same time. Also this started for me when I updated to MS 11.22 and since then we are seeing short sporadic outages, enough to trigger alerts externally from Pingdom. When these alerts come in, I always see a bunch of UDLD alerts and ports flip-flopping between down and up, SPT from designated to disabled. The UDLD alerts only happen on ports that connect the switches to each other: 4 switches with redundant connections (thus STP is needed and seems to be correctly disabling the redundant links) but why do these 16 ports that happen to be in aggregate groups of 4-8 ports connecting the switches to each other, keep flapping? No useful answer from Meraki 5 days into the ticket.   Example: Jan 27 13:15:40 SW2B   UDLD alert port: 41, state: unidirectional (outbound fault), port_blocked: false  more » Jan 27 13:15:25 SW2A   UDLD alert port: 42, state: bidirectional, port_blocked: false Jan 27 13:15:19 SW2B   UDLD alert port: 44, state: unidirectional (outbound fault), port_blocked: false  more » Jan 27 13:14:47 SW2A   UDLD alert port: 42, state: unidirectional (outbound fault), port_blocked: false  more » Jan 27 13:14:46 SW1B   UDLD alert port: 44, state: bidirectional, port_blocked: false Jan 27 13:14:16 SW2A   UDLD alert port: 43, state: bidirectional, port_blocked: false Jan 27 13:14:10 SW1B   UDLD alert port: 44, state: unidirectional (outbound fault), port_blocked: false  more » Jan 27 13:13:39 SW2A   UDLD alert port: 43, state: unidirectional (outbound fault), port_blocked: false  more » Jan 27 13:13:19 SW1B   UDLD alert port: 41, state: bidirectional, port_blocked: false Jan 27 13:12:43 SW1B   UDLD alert port: 41, state: unidirectional (outbound fault), port_blocked: false  more » Jan 27 13:12:30 SW2B   UDLD alert port: 42, state: bidirectional, port_blocked: false Jan 27 13:12:26 SW2B   UDLD alert port: 44, state: bidirectional, port_blocked: false Jan 27 13:11:52 SW2B   UDLD alert port: 42, state: unidirectional (outbound fault), port_blocked: false  more » Jan 27 13:11:50 SW2B   UDLD alert port: 44, state: unidirectional (outbound fault), port_blocked: false  more » Jan 27 13:11:18 SW2B   Port STP change Port AGGR/1 designated→alternate Jan 27 13:11:18 SW1B   Port STP change Port AGGR/1 designated→alternate Jan 27 13:11:17 SW2A   Port STP change Port AGGR/3 designated→root Jan 27 13:11:17 SW2A   Port STP change Port AGGR/2 alternate→designated Jan 27 13:11:17 SW2A   Port STP change Port AGGR/1 root→designated Jan 27 13:11:17 SW2A   Port STP change Port AGGR/2 designated→alternate Jan 27 13:11:17 SW2A   Port STP change Port AGGR/1 designated→root Jan 27 13:11:16 SW2B   Port STP change Port AGGR/1 alternate→designated Jan 27 13:11:16 SW1B   Port STP change Port AGGR/1 alternate→designated Jan 27 13:11:15 SW2A   Port STP change Port AGGR/3 root→designated Jan 27 13:11:14 SW2B   Port STP change Port AGGR/1 designated→alternate Jan 27 13:11:14 SW1B   Port STP change Port AGGR/1 designated→alternate Jan 27 13:11:13 SW2A   Port STP change Port AGGR/1 alternate→designated Jan 27 13:11:13 SW2A   Port STP change Port AGGR/1 designated→alternate Jan 27 13:11:12 SW2B   Port STP change Port AGGR/1 alternate→designated Jan 27 13:11:12 SW1B   Port STP change Port AGGR/1 alternate→designated ... View more