MR 30.5.1 Patch Release - General Fixes Only

[Mloraditch]

Important note

• While Meraki APs have traditionally relied on UDP port 7351 for cloud communication, and TCP ports 80 and 443 for backup communications, with MR 28+ we are beginning the 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 devices that are deployed upstream of your Meraki APs. These requirements have been updated in November of 2022, so it is important that you review them. (Wi-Fi 6 and Wi-Fi 6E APs)
• WEP deprecation (https://documentation.meraki.com/MR/Encryption_and_Authentication/WEP_Deprecation_on_MRs)

Legacy product notice

• When configured for this version, MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 will run MR 26.8.3

Bug fixes

• General stability and performance improvements

Known issues

• Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs)
• In high capacity wireless networks, APs may experience instability when the “Client Balancing” feature is enabled (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)

[Brash]

For a release like this where the only fix is "General stability and performance improvements", it would be nice to get some additional clarity as to what has been fixed.

[K2_Josh]

Agreed. I have read the documentation:

https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Managing_Firmware_Upgrades

https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Cisco_Meraki_Firmware_FAQ

https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Meraki_Firmware_Release_Pr...

From what I read, if one upgraded to the most recent stable release candidate, then a new stable (or potentially not-classified-as stable) release candidate being released will only be support with "best effort". Quoth the Release Process documentation: "The latest stable release candidate firmware is fully supported by our Support and Engineering teams. Older stable release candidates are supported with best effort; an upgrade to the latest beta, stable release candidate, or stable will ensure full support. "

To me this suggests that one should absolutely stay away from all release candidates, even if they are labelled as stable, unless (1) there is a very specific known security fix, (2) a device is experiencing a major issue that Meraki support says will be fixed by a specific release candidate, or (3) an organization has enough extra Meraki gear, time and interest in testing release candidates. But to partially address item #1, the documentation says that "Critical updates, such as those to address high-impact security vulnerabilities, may be scheduled on a shorter timeline."

Quoting again from the Release Candidate documentation on the "Stable Release Candidate" section: "These upgrades can be canceled, modified, or reverted using the firmware upgrade tool on dashboard." That seems scary to me, but maybe reverting is easy if one just opens a support case.

I'm happy to be wrong, corrected or exposed to other opinions on the utility/scariness of pushing the Stable Release Candidate to any production (or soon-to-be-production) device.

[Ryan_Miles]

You can always choose from stable, RC (if one exists at that moment), and beta (again if one exists at that moment). There won't always be RCs or betas as it all depends on code dev cycles.

A recently upgraded network can use the Rollback function within 14 days of the upgrade. Beyond 14 days while the rollback button is no longer available there's nothing to prevent you from manually downgrading back to the stable version.

The only time a Support case would be required is if you want to move to a much older/no longer published version of firmware.

[K2_Josh]

@Ryan_Miles  Thank you again for your help. That sounds great, but how does that square with the language I referenced in the Stable Release Candidate section?
"These upgrades can be canceled, modified, or reverted using the firmware upgrade tool on dashboard."

Does the documentation for the Firmware Upgrade Release Process need to be updated to reflect the information you provided?

[Ryan_Miles]

"These upgrades can be canceled, modified, or reverted using the firmware upgrade tool on dashboard." That is a true statement. I'm not following you on what the gap is.

[K2_Josh]

I completely misread the documentation and am appropriately embarrassed.

That said, I still stand by my comments earlier arguing that almost everyone should stay away from all release candidates, even if they are labelled as stable, unless (1) there is a very specific known security fix, (2) a device is experiencing a major issue that Meraki support says will be fixed by a specific release candidate, or (3) an organization has enough extra Meraki gear, time and interest in testing release candidates. But to partially address item #1, the documentation says that "Critical updates, such as those to address high-impact security vulnerabilities, may be scheduled on a shorter timeline."

I worry that I would be told by support to upgrade/rollback if on a release candidate since "The latest stable release candidate firmware is fully supported by our Support and Engineering teams. Older stable release candidates are supported with best effort; an upgrade to the latest beta, stable release candidate, or stable will ensure full support. "

[cmr]

@K2_Josh from my experience you are often asked to upgrade to the latest stable or stable release candidate by support when there is an issue, if you aren't already on it.  I would always advise to go to the latest version that you feel comfortable with.  We generally only run stable versions in our main data centre, but do run release candidate and beta versions in smaller sites.