This was removed. It was accidentally added and to demystify this a bit, it's internal jargon pertaining to how switches snoop traffic to send to the CPU. Examples include snooping DNS traffic to determine if you're requesting `switch.meraki.com` for the LSP, snooping ARP packets for DAI, etc. ... View more

I understand your concern about the potential impact on your organization's testing and deployment efforts. It's important to consider the specific needs and priorities of your organization when making decisions about software updates. While MS 14.33 may be rock solid for you at the moment, it's worth noting that newer releases include important security patches and bug fixes. Waiting until MS 16 becomes GA might mean missing out on these critical updates for a longer period of time. One approach you could consider is to evaluate the potential impact of upgrading to MS 15.22 by initiating testing of this version to simulate your organization's specific use cases and scenarios. This will help you determine whether the benefits of the new release outweigh the potential challenges of retesting and redeploying. While this may initially seem like a duplication of effort vs waiting for MS 16, it's important to recognize that testing MS 16 will build upon the foundation laid during the testing of MS 15. By thoroughly testing MS 15, you gain valuable insights into the potential impact of future updates, such as MS 16. This allows you to proactively address any issues, reducing the overall effort required when transitioning to MS 16. Ultimately, the decision to upgrade depends on the specific needs and risk tolerance of your organization. Taking a cautious and well-planned approach to testing and deployment can help minimize disruption and ensure a successful transition to a newer release. ... View more

Good question! As MS 15 is currently in its General Availability (GA) phase, it is crucial to exercise caution when considering additions for subsequent GA releases. The utmost priority is to avoid introducing any changes that might inadvertently destabilize the system. In this particular case, the severity of the issue appears to be relatively low, as the devices eventually authenticate despite the challenge. Therefore, the risk versus reward assessment leans towards a more cautious approach. It is worth noting that the most recent beta/rc (release candidate) releases tend to include a higher number of fixes. This is due to the slightly higher tolerance for potential bugs that may emerge while attempting to address existing issues. Rest assured, our team is committed to maintaining a robust and stable product, and we appreciate your understanding and support as we strive to continuously enhance its performance. ... View more

Just wanted to call out an addition that will be added to the alerts section in the next couple of hours. Addition to be added:   "MS420 devices configured for this version will run MS 15.21.1" ... View more

I would check to make sure the management port is not connected to the network, since it will serve DHCP. This is so that you're able to connect to the local status page without setting a static IP. https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_the_Cisco_Meraki_Device_Local_Status_Page ... View more

@cmrI apologize for the confusion. MS 15.19 encountered last-minute challenges with the MS1XX/2XX/35X/4XX series switches, so it was not released for those products. Instead of canceling the release entirely, it was decided to move forward with a "split release" due to the important MS390 fixes included. There was a breakdown in communication while the changelog was being written which is why fixes were incorrectly added. This has been corrected and will be reflected in dashboard within a few hours.   MS 15.19 was a "split release" only for the MS390 series switches. This means that if you schedule your network to run MS 15.19 which has MS390s and any other switch, like an MS250, the MS390s will upgrade to 15.19, while the other switch will run MS 15.18.   This has been called out in the changelog alerts as such: MS 15.19 is the same as MS 15.18 for the MS1XX/2XX/320/35X/4XX switch models The SVI fixes are planned to be apart of the next release, MS 15.20, which should be expected in the coming weeks. Again, I apologize for the confusion this has caused. ... View more

@KarstenI , this issue is sort of like hydra as in, we fix one instance of the issue, can no longer reproduce it, and for some reason, it keeps coming back one way or another.   You are right, that this was originally seen in switch 11, but was rare. This issue started getting reported more often in later versions which led to the issue being investigated further and resolved in MS 14.28. The changelog message for this fix was: In rare circumstances, the next hop VLAN is incorrectly modified for existing OSPF SVIs when a new SVI is added which will also participate in OSPF. A reboot will correct this (present since MS 11) Shortly after, additional reports of similar issues were reported. These were resolved in MS 14.31. Changelog message for this: Modifying SVIs on switches could cause the next-hop VLAN to be incorrectly set; which would result in routing outages The most recent occurrence, that is impacting MS 14.31+ versions is yet again, another instance of this issue. The MS 14.32, along with MS 15.2+ changelogs have been modified to have the following issue in the "Known Issues" section: In rare scenarios, changes made to SVIs may result in connectivity loss for one or more SVIs until reboot (present since MS 14.31) This issue is actively being investigated, with hopes that it will make it into a future release soon.    Hopefully, I have been able to add a bit of additional clarity around the troubles you are facing.  ... View more