New MS 15.20 stable release candidate firmware - fixes routing table er on stacks when deleting SVIs

[cmr]

The fix pulled from 15.19 is back, along with some other routing table and ARP fixes for issues that I'm pretty sure we've seen.  Plan is to upgrade a number of L3 MS355 stacks next week...

Switch firmware versions MS 15.20 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

• MS390 series switches can only downgrade to MS 12 with an incremental step to MS 14
• Stacks may fail to complete an upgrade to this version and will revert back to the starting version. If this happens, splitting the stack and upgrading individually is required (present since MS 15.15)
• Upgrades to this version will result in a full system reload

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

General fixes

• AMI IP addresses do not send gratuitous ARP packets which can lead to packet loss if the AMI address has aged out in the network (always present)
• NAT detection incorrectly shows IPv4 addresses as hexadecimal instead of dotted decimal notation (present since MS 15)
• Ports will fail to correctly revert to the previously configured VLAN when disabling SecurePort. A reboot or port VLAN change corrects this (present since MS 15)
• Sporadically, SNMP walks will fail by not increasing the OID (present since MS 14.13)

Ms2xx/35x/4xx fixes

• Clients may fail to be relearned by the MAC table after going into sleep mode and waking back up (present since MS 15.15)
• Stack routing tables can be incorrect after removing an SVI (present since MS 14.32)

Ms390 fixes

• Bundling port(s) that have a voice VLAN configured results in the LACP bundle failing to be configured (present since MS 15.14)
• Changing the OSPF router ID will cause the system to go offline (present since MS 15.19)
• STP event logs are not being logged (always present)
• Stacks will drop DHCP relay ACK packets after modifications are made to the DHCP allowed/blocked policy (present since MS 14.32)

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)
• Enabling NAT detection may cause issues with TCP streams resulting in pages failing to load entirely or taking longer than usual to load (present since MS 14)
• 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)

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)

Ms120/125 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)

Ms125 known issues

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

Ms2xx/350/355/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)
• 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

Ms350/355 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.

Ms355 known issues

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

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)
• Changing the OSPF router ID requires a system restart to become active (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)
• IGMP snooping enabled will send an IGMP message on every configured VLAN every 125 seconds (always present)
• In very rare instances, the management plane will restart every few minutes and requires a full reboot to self-correct (present since MS 15)
• Large stacks may experience intermittent management plane loss resulting in config fetch delays (always present)
• Loop detection is not supported
• Multiple CoA policies sharing the same IP but using different ports fails to be configured (always present)
• 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)
• Stacks may fail to complete an upgrade to this version and will revert back to the starting version. If this happens, splitting the stack and upgrading individually is required (present since MS 15.15)
• 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)

[ewcs]

Oddly, 15.20 no longer shows PoE information at the individual port or PSU level.

[cmr]

What switches have you seen that on?

[ewcs]

I'm seeing this on MS220-48LP, MS320-48LP, MS220-8P so far.

[cmr]

I can confirm the same, even after a reboot, on an MS220-8p.  @Ryan_Miles we have a problem...

[cmr]

I upgraded another network with MS210-48LP and MS225-48LP switches and they do correctly report PoE both in the switchport page and the power supply page.  It looks like the bug is version specific and perhaps only for older models.  I'll schedule in some other switch model upgrades so we can see more.

[Ryan_Miles]

Power info is ok on my 120-8LP and 355. Anyone seeing an issue please open Support cases.

[ewcs]

We've had to roll back to 15.19 because one MS320-48LP continued to reset PoE devices over and over.

We have an open case for the same MS320 that is warm-booting, so we'll add this note to that.

[cmr]

Support case opened - ID 09294416

[cmr]

15.21 is supposed to contain the fix, not sure when it will be released though.

[cockroach_c]

Completely avoiding this update. We have had two issues with two separate clients. One on ms320 other on ms350. MS320 it completely broke poe. Ms350 it completely broke stacking. After downgrading both from 15.20 back to 14.33.1, SFP is now broken. I know it says stable release candidate-- I'd suspect it never becomes an actual stable release. 

[cmr]

We upgraded a stack of four MS355-48X switches this morning from 15.18/19 to this as 15.18/19 just wasn't stable.  So far, so good with this release.

I do worry a bit about the issues with recent releases as they seem to randomly affect certain models and configurations...

PoE and stacking does work on the 355s.

[MiguelMVLA]

Has anyone upgraded to 15.20 on stacked MS390s? If so, what has your experience been like? Specifically, I'm wondering about broken PoE or other major issues.

[kapplejacks]

I still keep getting occasional amber connectivity light on my MS225-48LP 3 switch stack. Tech support suggested going to this version but seems there are still some gremlins.

Anyone have a suggested stable release firmware to run on the MS225-48LP?

[JeffreyB]

We moved to this version and it broke multicast for my PA/CLOCK system. It broke it so bad the server that hangs off a Meraki switch could not talk via multicast to the speakers that were on the same switch. As soon as I rolled back to 14.38.1, the entire system came back up. Sounds like there are bugs in 15.20. Be careful. 

[cmr]

@JeffreyB what switch models are you running it on?  We have one VLAN that needs multicast to work for video feeds and it appears to be fine.  In our case it is a stack of MS355-48Xs as the core with an MS210-48LP hanging off them.

[JeffreyB]

@cmr - We're running MS355's on the edge, and Cisco 9500-16 as the core. The 355's are stacked. We moved equipment off the 355's and were able to communicate. When we rolled back, everything started functioning normally. We're going to stay at this release until this bug is addressed.  

[Banfield75]

Hi. I´m about to upgrade a stacked pair of MS210 and a single MS210 connected through SFP fiber to one of the stacked members. The upgrade is necessary because Merki support incest it should be the latest version switch version after we run in to a problem with that switches lose dashboard connectivity for a few minutes after vi upgraded the Mx version (I know it sounds crazy). CRM you who worked a lot with the product. You have not had any issues with MS210 after update to 15.20? And I don´t see that we affected by the known problem of Cross-stack LACP bundles problem in our environment either.