New MS 15.21.1 stable patch - fixes PoE on Meraki Go switches, no other changes

[cmr]

Switch firmware versions MS 15.21.1 changelog

Alerts

• HTTP proxy is no longer supported on MS 15+. Nodes that use HTTP proxy without any other means to connect to dashboard may fail to connect.
• While Meraki switches have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MS 15.1+ we are beginning a transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that all “Meraki cloud communication” traffic specified in the Help > Firewall Info page is allowed through any firewalls or security filtering devices that may be deployed upstream of your Meraki switches. These requirements have been updated on Nov 2022, so it’s important that you review them.

Ms390 alerts

• Switches can only downgrade to MS 12 with an incremental step to MS 14
• Upgrades from MS 15.20 or later will result in minimal impact to client traffic

Ms390 features

• Additional client analytics added
• Alternate Management Interface (AMI) support
• Critical/failed authentication support
• Group policy ACL support
• IPv6 static routing support
• MAC flap detection support
• Meraki authentication support
• Multi-auth with voice VLAN bypass support
• Netflow and Encrypted Traffic Analytics (ETA) support
• STP anomaly detection
• Stack power is supported by default
• UDLD support
• UPoE (802.3bt) support
• URL redirect support

New features

• IPv6 management interface support

Bug fixes

• Meraki Go switches fail to provide PoE to connected Powered Devices (present since MS 15.20) Note: this does not apply to MS model switches, and only applies to Meraki Go (GS model)

General known issues

• Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12)
• Non-MS390 switches move LACP ports to an active forwarding state if configured. This can cause loops when connecting to an MS390 unless the bundles are configured on the MS390 first. All Non-MS390 ports are configured in passive LACP mode so that loops do not occur between Meraki switches (always present)

Known issues

• In rare instances, the port status will fail to update to dashboard until the system reboots (present since MS 14)

Ms120 known issues

• In rare instances, switches may return empty packet captures until they are rebooted
• Switches in extremely rare instances will experience reboots every few minutes (present since MS 11)

Ms125 known issues

• The local status page cannot be accessed from the management port (always present)

Ms12x known issues

• Ports with an odd-numbered MTU value fail to initialize (predates MS 11)
• Switches will never move a RADIUS server's connectivity status to available if it was ever lost resulting in all authentications being placed into the critical auth VLAN (present since MS 14.32)

Ms2xx/35x/4xx known issues

• Cross-stack LACP bundles experiencing a switch reboot will cause the remaining online port to experience an outage for up to 30 seconds. The same is seen again when the switch comes back online (present since MS 10)
• If the same MAC address is associated with multiple IPs, adding or removing an SVI may lead to an incorrect VLAN ID mapping leading to packet loss on one or more SVIs
• Loops can be seen when rebooting a stack member containing a cross-stack lag port (always present)
• Switch stacks will learn MAC addresses from ports in the STP blocking state which can trigger a constant flood of MAC flaps in the event log

Ms355 known issues

• In rare instances, stack ports fail to initialize after an upgrade (always present)

Ms35x known issues

• Enabling Combined Power results in events being logged once per minute (present since MS 11)
• UPoE does not negotiate over LLDP correctly (always present)
• mGig switches will have an amber light for all physical ports that do not negotiate to the highest supported speed. Dashboard will continue showing a light green status for all ports above 100Mbps. For example, MS355 switch ports will incorrectly show an amber light for 1G, 2.5G, and 5G, but will show a green light for 10G.

Ms390 known issues

• "Port Up/Down" events will generate an event log for each stack member
• Adding additional ports to a port bundle will cause the entire bundle to be reconfigured causing traffic loss (always present)
• Cloning a stack member results in configurations for LACP to be missing, requiring the bundles to be reconfigured or the system to be rebooted (present since MS 15.14)
• DHCP options longer than 180 characters may fail to be configured on the device resulting in the configuration being reverted (always present)
• IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (always present)
• If a link aggregate has an adaptive policy group added or removed, the link aggregate ports will be disabled and stay disabled
• Large stacks may experience intermittent management plane loss resulting in config fetch delays (always present)
• Loop detection is not supported
• Rebooting a switch in a stack via the UI will result in the entire stack rebooting (always present)
• Receiving incorrectly flooded CDP packets may incorrectly report VLAN mismatches and SFP port information (present since MS 12)
• Warm spare/VRRP is not supported

Ms425 known issues

• Stacks in rare instances will start dropping DHCP traffic on trusted ports while DAI is enabled until rebooted (present since MS 12)

Ms4xx known issues

• When an SFP module is inserted/removed, BPDUs can be delayed leading to STP transitions in the network (predates MS 12)

[BrandonS]

Am I last to find out that Meraki Go switches run the same firmware as "regular" Meraki?  Now I wonder about the Go GX firewall and GR wireless..

[cmr]

Lol, no I only found out with the 15.21 release...  I'd guess there is a good amount of commonality in all of them.

On another note, this known issue was added to 15.21 and remains in 15.21.1 which could be a bit alarming as a lot of DHCP devices show 0.0.0.0 before getting a real IP, hopefully it doesn't mean that!  Also when you connect a Meraki AP it often hunts around the VLANs, especially if it was static on VLAN n and is now set to DHCP with a different native VLAN on the trunk to the port.

• If the same MAC address is associated with multiple IPs, adding or removing an SVI may lead to an incorrect VLAN ID mapping leading to packet loss on one or more SVIs

[Frank-NL]

MS390 SNMP ifIndex integer offset starts at 9 instead of 1

This is mentioned in 15.6 as fixed but I can confirm this is an issue on 15.21.1

[Frank-NL]

With a stack 2* MS390-24:

First switch first port starts at 9

Second switch first port starts at 53

[MlatParl]

With a stack 6x MS390-48P

Firmware updated this noon -> tonight the entire stack is unreachable from the Meraki cloud...  amazing...

All other switch (MS350, MS220) are ok...

[DaveNet]

Updated to this release this week. After upgrade, all switches with DHCP relay configured over WAN would not allow clients to connect to the network. Previous 14.33.1 worked fine, does anybody know if this is a known issue? I haven't downgraded yet, simply unblocked the local Routers DHCP server in Dashboard. 

[jtranchina]

Anyone else having an issue with MAB authentication? All of our devices using MAB are getting the following error: "RADIUS server returned an invalid VLAN name". I confirmed that it's the correct VLAN being provided by the radius server and it only started occurring after the upgrade. 

[RaphaelL]

Only this version or any version from the MS 15 branch ?

I'm not aware of any issue with MAB currently sorry.

[NolanHerring]

So all my networks are on 14.33.1 and I was looking at upgrading to 15.21.1 and did some community searches and found several red flag discussions with people reverting back to 14.33.1. I'm not in any rush so I'll hold off, but it seems like 15.21.1 is causing issues for people. Thoughts?

[cmr]

We have it deployed on various networks with 355s and some with 225, 220, 210 and 120 models.  Seems okay to us, but we don't use DHCP relay and don't have 390s.

[RaphaelL]

Make sure to re-test your Group Policies. Seems that some behavior might have changed ( like DNS/DHCP were always implicitly allowed , might not be the case now ). I have to do more testing about that.

[JacekJ]

Using it with MS425, 225 and 120 switches and apart of upgrade not going very well the devices seem to work just fine (no rollback done or so).

DHCP relays 802.1x, SecurePort all work correctly, didn't notice any POE issues as some reported.