A New MS version is out : MS 17.2.1

[RaphaelL]

General important notes

• MS17 introduces a change to the default login credentials for the device local status page, using "admin" as the username, and the device serial number (upper case with dashes) as the password

Ms12x important notes

• MS 16 introduced DAI on MS100 series platforms. If you are upgrading to a current release from MS 15 or earlier please ensure trusted ports and/or DAI-allow lists are configured prior to upgrading.

New feature highlights

• DOM (Digital Optical Monitoring)
• Intelligent Capture
• RSPAN and VLAN Based SPAN
• SmartPorts

New ms130x feature highlights

• Adaptive Policy on MS130X/R models

General fixed issues

• All new LAG configurations will block redundant links if the connected device is not configured for LACP. This change fixes an issue where switches would sometimes move LAG ports to an active forwarding state prior to LACP convergence, creating the potential for loops. The change does not apply to existing LAG configurations.
• Corrected the Local Status Page to show the 1 Gbps (forced) option, previously mislabeled as 1 Gbps (auto)
• Fixed a bug that caused some clients using Hybrid, 802.1X, or MAB Access Policies to fail to authenticate after a switch reboot
• Port-bounce CoA commands now correctly cycle PoE ports
• Resolved an issue that caused some clients to be incorrectly added to a configured Guest VLAN when authenticated via RADIUS immediately after a switch reboot
• Resolved an issue that prevented some MS210 and MS225 devices from correctly releasing MAC addresses from the MAC forwarding table
• Resolved an issue that sometimes caused MS350 switches to remove existing L3 SVIs when enabling Auto-stacking

Ms120 fixed issues

• Fixed a bug that prevented MS120-48 switches from correctly forwarding multicast traffic on ports 25-48
• Resolved a bug that caused Epson POS printers to fail to authenticate when using MAB hybrid auth access policies

Ms12x fixed issues

• Fixed an issue that prevented MS120 and MS125 switches from forwarding link-local multicast (224.0.0.x) traffic when 'Flood unknown multicast traffic' was disabled

Ms130 fixed issues

• Fixed a bug that caused some MS130-X switches to experience slow upstream when connected directly to an MX device via an mGig port

Ms225 fixed issues

• Resolved an issue that caused some MS225-48FP devices to become unresponsive and fail to forward traffic until rebooted

Ms350 fixed issues

• Fixed a bug that prevented cable tests from correctly functioning on mGig ports

Ms35x fixed issues

• Resolved an issue that caused some MS350-24X and MS355 switches to fail to negotiate 802.3bt UPoE LLDP connections

General known issues

• LACP links may take up to two minutes to come back up when the Active Member of a stack reboots
• On MS250 and MS350 switches, MAC addresses learned via AGGR are not removed when LAG ports are disabled. Mac addresses will be removed correctly within 5 minutes of reenabling LAG ports.
• RADIUS communications may not recover after an initial failure when Critical Auth is enabled
• Some switches may encounter an error, "incompatible configuration for attributes: allowed_vlans" when attempting to aggregate ports regardless of allowed VLANs configured in Dashboard

Ms120 known issues

• Switches may fail to provide PoE power to legacy access points (always present)

Ms225 known issues

• In rare circumstances MS225 switches may encounter a software crash that results in a reboot

Ms250 known issues

• In rare circumstances MS250 switches using Multi-Domain Hybrid auth access policies may enter a 'port not forwarding' state, sending clients to the Guest VLAN until the switch is rebooted

Ms355 known issues

• When reconnecting a stack cable between MS355-48X2 swithces a stack member may go offline until both switches are rebooted

Ms35x known issues

• In rare instances, stack ports fail to initialize after an upgrade (always present)
• Incorrect SFP port mappings may disrupt SFP functionality
• Switches may experience an unexpected reboot (present since MS 15)

Ms425 known issues

• In rare circumstances MS425 switches may encounter a software crash that results in a reboot
• MS425s in stack configurations may periodically trigger New DHCP Server alerts that include mismatched VLANs/subnets
• Powering off the active switch in a MS425 stack may result in up to 5 minutes of downtime while the stack reconverges

[RaphaelL]

Ms225 known issues

• In rare circumstances MS225 switches may encounter a software crash that results in a reboot

Ms35x known issues

• Switches may experience an unexpected reboot (present since MS 15)

#Pain

[RWelch]

#Agree100%

[TyShawn]

MS425 KNOWN ISSUES

• In rare circumstances, MS425 switches may encounter a software crash that results in a reboot

same issue and one that is keeping us from pushing these firmware out.

[RWelch]

I upgraded one of two MS425s to MS17.2.1.  It felt like it took an eternity but it did upgrade.  My other MS425 will be upgraded at the next maintenance window….hope it doesn’t take as long as the one I did tonight.

[Bovie2K]

FWIW I'm running MS 17.1.4 and haven't been hit yet but I agree. It would be nice to know that the rare circumstances are.

[nlev]

Upgraded one of our networks. The MS425 took a while but eventually updated. The MS320 stayed on Upgrade Status: Started for a long time and eventually changed to Upgrade Status: -   They still show Firmware Version: Not running configured version.  Does this mean the update failed? Was MS 17.2.1 intended to be made available to the out of support MS320 or were they supposed to stay on an older version?

[RWelch]

MS320s can run current firmware.

Product Firmware Version Restrictions 

[nlev]

Sounds like the documentation is wrong. Here's the response I got from Meraki support: 

"Unfortunately, id does not look like the MS320s will be able to upgrade to 17.2.1. Since, these are end of support, they are no longer providing updates for these switches. The documentation may be outdated and will need to be updated."

[RWelch]

My MS425 showed the same for a LONG time but did finally upgrade.

never had an upgrade take as long or show the same status for as long.

Firmware Version: Not running configured version

[nlev]

It's been several hours now and the MS320 switches are still showing "Not running configured version". I'll ask Meraki support but previously they said "these switches are end of support and we will not be able to troubleshoot"

[cmr]

I like this change, the CS switches always seemed to work this way and I much prefer it:

General fixed issues

• All new LAG configurations will block redundant links if the connected device is not configured for LACP. This change fixes an issue where switches would sometimes move LAG ports to an active forwarding state prior to LACP convergence, creating the potential for loops. The change does not apply to existing LAG configurations

I would however like the port status LEDs to reflect the blocking...

[rhbirkelund]

I think perhaps that if more details were provided on which conditions these "unexpected reboots" would occur, it might help in deciding whether or not to upgrade.

When reading between the lines, it kind of implies that there are certain circumstances that need to be met for these unexpected reboots to occur.

If it's just a general disclaimer, Meraki might as well just add that as a permanent known issue, to every firmware from now on.

[RaphaelL]

^this 

Also , why is this version already promoted to stable if it contains "unexpected reboots" ?

17.2.1 is not a patch from 17.1.4. it is a minor release.

[YoeriOppelaar1]

Thanks for the new release, looks very promising,

But is there any indication when the following known issue is fixed: 

• RADIUS communications may not recover after an initial failure when Critical Auth is enabled

It in the software for multiple releases, it really impacted my customers endpoints. 

Although i use a workaround now, which works for now, i would like to stick with the dashboard provided solutions as close as possible.

[willw]

We just upgraded our 350-24X to the latest 17.2 release, however our new WiFi 7 APs are still showing they are operating in low power mode, 802.3.at.  I thought this release was supposed to address this and provide UPoE.

We have a support ticket open on this

[DustinBu]

Does anyone know if this actually works on MS220? I had an MS225 work, but 4 x MS220 all still say "Not running configured version" after nearly 3 hours. Tried rebooting one, but still no. All were on 16.7 prior to upgrade. Thanks!

[michalc]

Hi @DustinBu , welcome to Meraki Community! 😊

17.2.1 should work on MS220 platform. MS220 does not have a firmware restriction at a time.

Has there been any changes on your network recently?

Have the switches reboot by themself after the upgrade started?

Did the firmware upgrade shows as completed under "Organization->Firmware Upgrades"?

[cmr]

@michalc are you sure?  I upgraded a network with two ms220-8ps in 7 hours ago and neither have rebooted, both still show 'not running configured version'.  They were (and still are) on 17.1.4...

[cmr]

The upgrade shows as completing over 7 hours ago.

[michalc]

Hi @cmr Thanks for tagging me here! It seems like more users are experiencing this issue. The issue has been raised with the product specialist. We should have an update Monday/ Tuesday.

[nlev]

Thanks for looking into this. The response I got on my support case was: " Unfortunately, the dashboard will not be changed. As mentioned, the MS320s have passed the end of support date, and the development team won't make any changes due to the devices no longer being supported."

Is this correct or will they still fix it anyway?

[ShenzouX]

It had better not be - I have tons of 320s and 220s still out there that I cannot feasibly replace this year due to budget and other reasons and I know I'm not the only one.

[cmr]

The MS220-8 switches are not EoL until September 2025, so I think it is a bug, not a feature...

[nlev]

Does it actually show 17.2.1 if you check the switch in the dashboard? The scheduled firmware upgrade shows complete but all our MS320-48FP are stuck at "Not running configured version". No recent changes in the network. The switches did not reboot after starting the upgrade.

[cmr]

@nlev what version were/are they running?

[nlev]

17.1.4

[cmr]

@michalc if yours has truly worked, what version did you upgrade from?

[DustinBu]

Thanks @michalc !

There have been no changes to the network that should affect the upgrade. I had upgraded the organizational level MR firmware just prior, however no upgrades were actually performed due to those devices no longer supported on current firmware - it was more just to clear the alert. I had also restarted our spare MX that morning. The main uplink was always online.

The only switch that rebooted itself was the MS225 which upgraded successfully.

Initially I tried a staged upgrade, with the first stage being a single MS220. That hadn't completed after 40 minutes, still saying "Started - not running configured version", so I called your support team. We manually rebooted, but no change. We then rolled back, and tried a "perform now" upgrade of all switches, which is when only the MS225 worked. We tried rebooting 2 of the MS220, but no change. Nearly 2 days later now, all 4 x MS220 still say "Up to date - Not running configured version".

I'm expecting an update from your support team on my case today. Thanks

[ShenzouX]

I also have 3x MS220s (8 port, 24 port, 48 port) in my lab environment that were running 17.1.4 that I tried upgrading to 17.2.1 and after a few hours they are also still all stuck on Firmware: "Up to date - Not running configured version.

Does anybody have an update on this?  This firmware seems like it has massive problems for several models of switches which seems like a pretty big deal to me.

One of the biggest selling points for Meraki is the ease of organizational level firmware upgrades to all devices so for that to be totally botched here is not good.

[Mloraditch]

The following has been added to the dashboard release notes: 

• Networks configured to run MS 17.2.1 will not upgrade MS22, MS42, MS220, or MS320 switches. Instead, those switches will remain on their previously configured firmware version.
  
  

It looks like (perhaps for the first time?) old switches are finally getting put into firmware jail.

@ShenzouX @nlev @cmr @DustinBu 

[cmr]

It's very sad that a supported switch (MS220-8) is abandoned before it's end of life ☹️

[RWelch]

Adding this additional bit of info (after the fact) is a bit sketchy IMO. 🤔

[ShenzouX]

This.

I don't understand how they are able to just throw a product to the wayside that is clearly documented as still supported until September 2025.

This doesn't make any sense to me.

[Mloraditch]

Supported doesn't mean it gets new features. I suspect 17.2 is a branch for features like 18.211 was for MXs. They do continue to provide fixes to older MXs for example via the 18.107.X train. I would suspect if necessary they may do that for the 220-8P although with only a few months left, it's unlikely outside of a security bug.

Regular Cisco practice is similar. There is a certain period after the end of life is announced where they still do maintenance fixes and then a point where they stop before the official end of support.

We've obviously been blessed for quite a while with the switch product line continuing to get new features and firmware long after EOL for some models but that's not normal practice for most vendors including Cisco.

[nlev]

Looks like the documentation has been updated as well. https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Product_Firmware_Version_R...

Odd behavior to have the dashboard display "Not running configured version" because there no longer seems to be a way to see what version is running currently since that text replace the firmware version. For out of support access points this doesn't happen. For APs the dashboard displays whatever old version the access point is running.

[Mloraditch]

I have a feeling, this being the probable first time this has happened to switches, they don't have the code written/enabled properly to handle all of this and are still working on it to work the same as MX/MR

[ShenzouX]

Can they at least give us the option in the firmware menu to downgrade back to 16.9 so that all the ports on the switch actually work correctly?

This was the last firmware that didn't screw up ports 25-48 on the 48 ports 220s and 320s.

I'm stuck on 17.1.4 and all I can do is stay on that or choose 17.2.1 (which apparently will never work).

[nlev]

Another possible oddity. The release notes now state "Instead, those switches will remain on their previously configured firmware version."  Does this mean that if your switch was not previously running 17.1.4 it's now stuck on whatever old version was previously configured?  Again, this seems different from access points which will update to the latest version that can run on the older hardware when the network is configured for a newer version.

[DustinBu]

This is really disappointing from Meraki.

• Nothing in the release notes
• Nothing on the min/max supported firmware page
• No notification on the dashboard before proceeding with the upgrade that the firmware is not supported
• No warning on the dashboard when devices are EOL
• MS220-8P doesn't work even though not EOL
• Can't see what firmware you're stuck on
• No way of upgrading to the latest supported firmware.

[Edu_Chico]

I updated my MS130-24p switches to version 'MS 17.1.4' and so far, I haven't had any issues. I still have 3 more switches to update, and these are scheduled for the upcoming days. What happened with this version, as it seems to have disappeared? Is version 17.2.1 an improvement over 17.1.4? What is recommended in these cases, and why do they release versions that suddenly go from nothing to being considered stable?

[cmr]

Is it not available to you as stable, latest patch when you go to schedule an upgrade?  I still see it there, alongside 17.2.1.

[Edu_Chico]

You're right, it does still appear for me. However, would it be better to stay on version 17.1.4 and wait, or upgrade to 17.2.1?

[cmr]

I'd check the release notes and as long as there isn't an additional known problem go with 17.2.1 for MS130s.

[AaronS]

Just pushed this version out to one of our locations. The location has a mix of MS120-8FP, MS225-48FP, and MS425-16 switches. Usually if I push out an update, it takes about ten minutes for all switches to update (five for the wait time, five for the update). This time, it took 30 minutes for all of them. They all started blinking around five minutes as usual, but it was then another 25 minutes afterwards before they rebooted to complete the update. This was going from 17.1.4 to 17.2.1.

[cmr]

That'll be adding all the features that the MS220/320 can't have 😉

[MarcelTempelman]

Hi,

This is a FYI post.

We rolled back the MS17.2.1 to MS16.9 (MS250 switch stacks) at a few customer sites because it started causing problems for devices trying to communicate outside their VLAN. Because these are care locations we were unable to do extensive troubleshooting but this is what happens:

- devices (camera's and Android based communication devices) connected to the switch or via MR36H work properly after the switch came up after reboot

- after a while some of these devices stopped communicating with their primary server which is outside their VLAN (in Azure, reachable via VPN). Communication with the local server in the same VLAN was fine.

- resetting a device or cycling a port would restore connectivity but after approx. an half hour problems started to arise again

- not all devices were affected.

Rollback to 16.9 restored functionality and solved the issues.

I've opened a TAC-case with this information. As an engineer I would like to investigate this more and have a real root cause but the care for the clients at these site has priority.

With kind regards,

Marcel Tempelman.

[cmr]

@MarcelTempelman are the MS250s doing the inter VLAN routing, or just trunking to the firewalls (MXs)?

[YoeriOppelaar1]

Looking forward for this as well. Next week i have a customer environment which we want to upgrade van 16.9 to 17.2.1 of 17.1.4 (but that cant be selected anylonger) as i have issues with MS130's which are loosing mgmt plane connection over time. design is mx is routing, switches for L2

[MarcelTempelman]

Hi,

I just thought I forgot to add this detail 🙂 Yes one of the MS250 switchstacks does the routing.