MS 15.18 Changelog

[RaphaelL]

I had a good laugh !

Switch firmware versions MS 15.18 changelog

Other

• Good idea cmr

[cmr]

Thanks to the Meraki team for adding that, it shows once again that the community is integral to the solution 👍

For completeness below are the notes including half a dozen MS390 fixes:

Switch firmware versions MS 15.18 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.
• MS390 upgrades to this version will result in a full system reload
• MS390 series switches can only downgrade to MS 12 with an incremental step to MS 14

New features

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

Bug fixes

• MS390s with DHCP configurations for over 100 SVIs will fail to apply (present since MS 15.17)
• Collecting out-of-band logs on the local status page for MS390s may result in the management plane restarting (present since MS 15.8)
• MS390s may reboot with incomplete configurations for URL redirection, requiring reconfiguration (present since MS 15.15)
• MS390 SNMP walks for "IfAlias" return empty values (present since MS 14)
• MS390 ports can enter an error-disabled state and not recover without a port bounce (always present)
• MS390s authenticating over 350 dot1x clients at the same time may see its management connection flap (present since MS 15.4)

General known issues

• 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
• Connecting a stacking cable to a stack that is online may result in a stack member going offline (present since MS 12)
• 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)
• Deleting an SVI on a stack results in the stack's highest numbered VLAN which is sharing the same RFC 1918 address to have an incorrect next-hop VLAN (present since MS 14.33)
• 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)
• Loops can be seen when rebooting a stack member containing a cross-stack lag port (always present)
• Sporadically, SNMP walks will fail by not increasing the OID (present since MS 14.13)
• 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
• The next-hop port may be incorrect on L3 stacks and believed to be the result of client flapping between ports (present since MS 14.32)
• 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.
• 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)

Ms120/220 known issues

• 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 of MS125s (always present)

Ms210/225/350/355/425/450 known issues

• In large L2 networks experiencing frequent STP TCs can become fully unresponsive (present since MS 15)

Ms350/355 known issues

• Enabling Combined Power results in events being logged once per minute (present since MS 11)

Ms350x/355 known issues

• Switches do not negotiate UPoE over LLDP correctly (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)
• Fixed IP assignments are not deconfigured until the system is fully reloaded (present since MS 14.33)
• 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 reboot every few minutes and requires a full reboot to self-correct (present since MS 15)
• Loop detection is not supported
• Management plane may lose connectivity after changes are made to the storm control percentage
• Multiple CoA policies sharing the same IP but using different ports fails to be configured (always present)
• Passing line rate traffic on non-uplink ports can have an impact on the management plane connectivity
• Ports fail to be configured if the allowed VLANs character length is greater than 223 (always present)
• Rebooting an MS390 switch in a stack via the UI will result in the entire stack rebooting
• Receiving incorrectly flooded CDP packets may incorrectly report VLAN mismatches and SFP port information (present since MS 12)
• Warm spare/VRRP is not supported

Ms400 known issues

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

Ms425 known issues

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

Other

• Good idea cmr

[KarstenI]

Whatever the idea was, I support it! 😀

[WirelesslyWired]

The bullet was with regards to @cmr s work of sorting the change log by model. 

[KarstenI]

Oh yes! That is a big improvement.

[RaphaelL]

Great addition !!!  Good job cmr !

[Mloraditch]

Amazing! Came here as soon as I saw they had put it in cmr's format! 

[harmankardon]

So glad they adopted this, thanks cmr. Like many I've been having a difficult time reading through switch firmware changelogs. As someone who isn't using a MS390, it's been challenging to try and just focus on the details relevant to my networks because of how much MS390 content has been in the changelogs lately.

I would love to see each section of the changelog arranged this way, or even the ability to just filter by model and only show the changes relevant to my networks.

[RobertPHX]

I agree, filtering to just your products would be a great idea for sure!

And yet, because we have a bunch of MS390s... I like the "shame" factor of showing ALL THE BUG the MS390 still has. Especially when they put in the notes that the issue has been around since version 12. It makes me wonder / worry, will Meraki ever resolve these bugs? Do they care? Will they only resolve these bugs when they discontinue the MS390 and move on to something else?

It feels like Meraki's heart is not in the MS390... And I get it, it's a new unique model / platform (taking a Cisco switch and slapping Meraki code on it), so yeah, writing code for it is probably more challenging for sure.

But to have 10x the amount of bugs vs other Meraki switches is hard to accept as a customer, especially ~3 years into the deployment now.

[redsector]

A little bit too many open issues...

[harmankardon]

Agreed, I've been terrified to do switch firmware upgrades lately. I keep holding out hope that they'll get to a point where things are at least stable for non-MS390 models but doesn't seem likely.