I'm running LACP between access switches and cores in different configurations, cross stack on both sides, sometimes one single access switch with 2 LACP uplinks to 2 cores and sometimes a single switch with one uplink going to one core and a backup link (blocked by RSTP) going via an other switch to an other core. After things settled after the upgrade I didn't notice any LACP issues. We also experienced things not being reachable in a random way and it was either the LACP links misbehaving or L3 on the cores, but in the end disabling all redundant ports (not unconfiguring LACP) helped and that is what I would try in your situation. Since we have all links from access switches spanned across 2 cores I went into one of them and disabled all ports (not the uplink and stacking ofc), after waiting a minute or two things went back to normal, then I started enabling ports and the issues never came back. ... View more

This is weird, if you correctly aggregated them on both switches, this should work. The RSTP blocking sometimes takes a while to update its status on the dashboard. I assume both links are the same speed? ... View more

Hi, can you share what the suggestions were? ... View more

Are you still experiencing issues? What is happening? Curious why you are thinking about an rollback. ... View more

We were upgrading from MS14.33.1. Is this something we should be doing? First upgrade all L2 remote switches and then the cores? ... View more

I have a somewhat big setup and the upgrade went terribly wrong, nothing I'm not used when it comes to Meraki switches (sad, but true) - this will be a long story 😉 I have 4x MS425-32 switches in a stack + a number of MS225-24/48 in different combinations (some are single, some are 2pcs stacks and some are 3pcs or more which is very important in the Meraki world) - overall ~40 Meraki switches + ~10 WS2960X. All "remote" switches are connected to 2 of the core switches using LACP, so no SPOF. I set up a staged upgrade where I first wanted to upgrade the core switches (they are handling all L3 as in your setup), then 2 pure management switches in server rooms and then the rest of the remote switches. Here is what happened: cores upgraded nice, everything green, all ports up, BUT as in your story I had something between 10-20 switches behind the cores offline and not handling traffic despite all ports being up and showing no issues so the upgrade got stuck and I needed to react first I rebooted all cores from the dashboard - didn't change a thing then, since I have a long story with the Meraki switches I started disabling all redundant connections towards the remote switches (so basically all ports on core 02 and 04 disabled, only stacking was up) after that almost all switches started regaining connectivity and started upgrading by saying almost I mean that there is a story if you have more than 2 switches in a stack and a cross stack LACP connection to the cores they tend to "break", some of the switches in a stack will be offline, some online, the best resolution to that is remove all redundant connections (I disabled that from core side) and then reboot one of the switches that is online, if this doesn't help you pick the next one and next one and this will eventually kick in. If you are onsite, then just remove redundant connections and reboot the whole stack. I assume that rebooting the master switch would help right away, but I didn't know that the dashboard shows the info, at least on the latest firmware I waited some time and observed the current firmware version on the dashboard (it will show you if its "not current" or MS 15.21.1) after everything upgraded I rebooted the cores once again and then I started enabling the redundant ports and everything is working as expected since then (two weeks ago) So this was a journey which took me over 2 hours to fix remotely, I even didn't bother to raise a case because I knew that playing with ports and rebooting will work and also I planned to do a full reboot anyway on the cores because I have low trust in the firmware upgrade process (bad experience). If you have any questions - go ahead 😉 ... View more

How does the port setting look like? We set up the multi-domain with VoIP around 2-3 years ago so I might be wrong, but I think you need to provide the vlan and voice vlan on the port despite of the policy "telling" the switch what to do. The vlan we set up to something that we simply don't use anywhere. ... View more

Good question, would like to know that as well - to be honest since a few major issues we had with Meraki switches firmwares I'm reading each and every changelog and discovering bugs that we run into. It has happened a lot that bugs were discovered and noted as known in 15.xx releases, saying that they are known since 14.xx or even 12.xx but they are not shown on the 14.xx affected versions changelogs (seems that they just add that on the current release when this has been acknowledged without updating the old affected ones).   If you have stacks with more than two switches, watch out for this one, its very nasty:  Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12) ... View more

I wonder what you mean by HA. One disappointment was to learn that you can't do firmware upgrades on the switches without a downtime. Example: you have 2 core switches (MS425) stacked you have a bunch of access switches, all of them connected to both core switches, LACP set up and so on each core switch has an uplink to the firewall/router etc. You would expect that you can do a firmware upgrade where only one of the core switches would reboot at a time, thus leaving the whole network operational, but no, this is not supported - you can try to force that using staging, but this is not a supported scenario and the Meraki Support doesn't know how this will behave (I tested that and got mixed results). Obviously rebooting access switches and loosing the clients behind them for a while is expected. In classic cisco world the missing feature is called Rolling Stack Upgrade. ... View more

You can't upgrade single switches, you go either all or none for a given network in your dashboard. The only thing you can do is to stage the switch upgrades, so they won't go all at one time: https://documentation.meraki.com/MS/Other_Topics/MS_Firmware_Upgrades#Staged_Upgrades  ... View more

You can reboot the MS410 stack to see if this is causing you issues (done that quite a few times when that wasn't reported as a known issue). After a reboot everything should run ok, as you set it up in the dashboard. So the current work around if you need to remove a SVI - is either not remove it at all, or remove and then do a reboot of the stack AFAIK.   The MS15.21 is the first 15.xx that got into stable, so I would wait a bit with the upgrade just to be on the safe side. ... View more

Just a side note, this bug can be very nasty (has been fixed on MS 15.20): "Stack routing tables can be incorrect after removing an SVI (present since MS 14.32)" ... View more

You would need to set up different clients (APs) in the NPS, so you can easily differentiate between them in the NPS. Lets say you call the clients SITE1-WIFI and SITE2-WIFI with the IP ranges of the respective AP's. Then in the NPS you can set up policies and use "Client Friendly Name" with a value of "SITE1*" - this will affect only requests coming from APs that are in SITE1 and so on. I hopefully understood your question correctly 😉 ... View more

I'm using a different setup for such a solution, which works well, over a year at least: Whitelist the Sonos speakers (you can do that per SSID) Then on that given SSID, enable the Splash page feature with Sign-on with Meraki Cloud Authentication In advanced settings in captive portal strength set block all access + disable self-registration In this setup all non-whitelisted clients get a splash page asking them to login to meraki, which they will be unable to do, and whitelisted devices don't get the splash page at all. Works flawlessly on a network with hundreds of devices 🙂 ... View more

Sorry for the offtop, but since Meraki totally fails communicating this issue I just want to let you know, that if you are using the "A client is detected sharing its IP address via NAT" alert, please be careful with that, it can cause performance issues on switches (some traffic gets dropped). They were supposed to remove that option, but after few weeks, no luck (I'm not surprised to be honest, but disappointed), more to read about this in this topic: https://community.meraki.com/t5/Switching/CAUTION-ALERT-if-A-client-is-detected-sharing-its-IP-address-via/m-p/151479 ... View more

This is weird then, I didn't use MS210, I have MS225 in production and a few others, but never had this one happening. You could always set up one port in a classic way instead of aggregating them, then you should be 100% sure that there will be nothing happening. Also, if you lost the config, didn't the ports revert to trunk with native vlan 1 as the default setting? Wouldn't that keep your setup running? Meraki switches detect if there is LACP running on the other side and enable that if needed automatically. The dedicated vlan for management is best practice, to separate the management traffic from other production stuff, security reasons and many more. ... View more

Exactly, or on uplink ports there should simply be a 2nd step/popup asking if you really want to do that (test/bounce). ... View more

There is a known bug which occurs when you disconnect stacking cables and then connect them back, it might hit you: "Stack members may go offline after a stacking cable is reconnected requiring a power cycle (present since MS 12)"   We hit these way before it has been reported as a known issue and rebooting one of the switches in the stack most of the time helped, but just expect running into issues, so if you don't want that, then power down the whole stack. ... View more

Exactly ... View more

That is some good news, I must say that our case was closed on the 14 of June 2022, so this took quite some time, but still - better this than nothing for all other customers that simply don't know about the bug. ... View more

We started noticing issues with MS O365 services exactly as you mentioned (also SSO and so on). Their support on these cases was just way under expectations. After someone on their side figured this out and asked us to disable the option I went back to them and said that nowhere on the dashboard or in their documentation is a mention about the load this feature causes (it’s basically overloading the CPUs, that was the symptom that a few technicians confirmed) and that there might be issues. I asked them to add a note and to add the info to the known bugs and as you can see, they never did that. They also don’t give you a option to monitor the load on switches, just in case. The support experience with this case was just rubbish, they would run captures and then say they weren’t correct and they need to do them again (a few weeks in, wasting my time numerous times). And then I would explain to them that they are not able to run proper captures, and we as well, because something is wrong. And to sum up, most of the support experience is bad, they will tell you that the internal team has analyzed some internal logs and the switch is ok, but if you ask them to provide the logs, to show me as a proof - they would just ignore that part of the message. ... View more

I will add that this is noted in the documentation: https://documentation.meraki.com/MS/Layer_3_Switching/MS_Layer_3_Switching_and_Routing#Switch_Management_IP_and_Layer_3_Interfaces ... View more

Sad, but true 😕 ... View more