Is the MX 18.211.2 ready for prime time?

[gregarican]

So I have this scheduled to upgrade on 7/10/2024. Wondering if there are any trouble reports from early adopters out there that anyone can speak to. I know that a few months ago I had to revert back a Meraki firmware update that tanked our main HQ's MX75. Any 1:1 NAT hosts we had defined with firewall policies had sporadic connectivity issues that had me pulling my hair out one clump at a time. Until I rolled back the firmware upgrade.

So is MX 18.211.2 really good to go?

[jimmyt234]

We've had a variety of customers (so different hardware/config) auto-upgrade to this version and, touch wood, so far no issues.

[Brash]

The 18.211.0 and .1 releases had some major issues which led to the quick release of 18.211.2.

I haven't seen many issues for 18.211.2 in the community forums and haven't seen any issues myself so far.

[gregarican]

Just when I thought that these MX firmware upgrades flagged production-ready were indeed ready for prime time. Today I was thinking our head office was hit with a ransomware attack. Getting all sorts of Meraki dashboard alerts about excessive throughput. Winds up a bug in the firmware that miscalculates this. Per my support case, here are the rep's comment. 😡

"I believe you are running into a known issue on the MX 18.211.2 firmware where Client Usage Data does not match what is seen in the application table. With that said the Application Table is correct and the Usage Download is incorrect."

[cmr]

18.211.3 is now released...

[BenRod]

Depends

18.211.2 on one of our MX105's had us running at 100% CPU utilization after the upgrade. We saw that this was potentially fixed with 18.211.3 so we deployed just .3 (with supports guidance) to this one 105, our entire auto vpn mesh began to flap wildly. We lasted 1 hour on 18.211.3 before we had to roll it back to 18.211.2 to stabilize our hub & spoke auto VPN topology. 

The unit we patched was a single spoke MX (we did not patch all MX's with .3)

For now the device that prompted us to patch to .3 is not showing the high cpu utilization and is back running 18.211.2

Goes without saying, but be careful with firmware loads, even the ones marked stable can sometimes not be stable and anything not in the "stable" bucket is probably very much not stable.

We have a case open and are working with support on our particular issue but the current action plan is "sit and wait" and "reboot it if the CPU gets pinned again".

HTH

[cmr]

@BenRod in case you aren't aware, there is a .4 now with more fixes.

[gregarican]

The operative term "more fixes" sounds promising. Although how many of the fixes were for bugs introduced with the last few point version firmware updates? When a firmware update is flagged as a stable release then one would hope that it went through thorough testing. I can understand some one-off implementations that weren't tested. But some of these bugs in recent MX firmware updates are pretty sizable. Going back to the mid 1990's working with Cisco products, usually a firmware update that's been out there for awhile is as a stable release is reliable for the most part. When it comes to Meraki, it's apparent that the product line wasn't built by Cisco from the ground up. An acquired product line that isn't as rock solid.

[jimmyt234]

I only see 18.211.3 being the latest available patch, not .4 ??

[cmr]

Apologies @jimmyt234 and @BenRod , I was thinking of the recent 31.1.4 wireless release. Oops...

[NFL0NR]

Same issue here.  We patched to 18.211.3 and with the high utilization still happening support suggested turning off Multicore access at one location to test.  We did that and yesterday we lost auto-vpn between two of our locations.

Had to factory reset one site to get it back up.  Called back in and had multicore access re-enabled and it brought our network back up.  Still seeing high utilization but it doesn't appear we're dropping packets.  

[BenRod]

Oh wow, they are pounding out the releases, we will explore .4 and ask support about it.

Thanks cmr!

[GIdenJoe]

For me this version is a no go.  I have a few customers that are using Radius Filter-ID for Cisco Secure Client VPN filter and the enforcement of the rules only seems to be working on ICMP traffic.