Last week Meraki released MX12-26 as the new stable release candidate firmware for MX security appliances. For those running Meraki MX networks, this is kind of a big deal.
Let me take you back to December, 2016. MX was about to release the largest single firmware update in the product’s history – MX12. That single upgrade gave MX customers access to a number of significant enhancements, including:
- A massively improved malware inspection engine – Cisco Advanced Malware Protection (goodbye Kaspersky). This unlocked MX customers running the advanced security license to the world of Talos’ security intelligence research and access to the global AMP threat cloud.
- SD-WAN. This was without a doubt the biggest feature to drop in MX12. While other players where making SD-WAN appliances, Meraki added it as a feature. For free. This single enhancement instantly promoted the Meraki’s MX SD-WAN solution to the largest SD-WAN platform in the wild (and still is).
- DC-DC failover automation was added to the AutoVPN protocol. This made multi-homed data center WAN SD-WAN deployments resilient with zero extra configuration effort. Running overlapping data center supernets was now handled seamlessly in failure situations. A great example of better by default.
- 802.1X port authentication for MX64, MX64W, MX65, and MX65W platforms. The all-in-one units received proper wired authentication on LAN switch ports.
- Significant sync improvements to MX warm spare. This was especially helpful for data center concentrator installs that required added state resiliency.
- And much, much more.
It was awesome. Customers were excited to have access to all the new capabilities and Meraki delivered on it’s longstanding tradition of feature velocity.
As customers upgraded to MX12, Meraki learned a few things they could have done better and quickly got to work fixing bugs in AMP inspection, SD-WAN UI tweaks, and generally getting the unexpected kinks worked out.
With MX12 shipped, the while Meraki Engineering team quickly got to work cranking on their next round a feature deliverables planned for MX13.
Tradeoffs and Tough Choices
Meraki’s development operates in an iterative way where security patches and bug fixes are always rolled into the next major code release. That means that all the MX security patches and AMP bug fixes were added to MX13, not the mainline MX12.
For customers who needed fixes and were willing to roll beta firmware, MX13 was solid. MX13 was just a fork of MX12, so it was highly stable for existing features. In spite of that, some customers organizational policies require RC code – leaving them patiently waiting (I’m being kind) for a new stable candidate release (all the while running increasingly dated firmware that was getting stale).
Why did it take so long to ship an updated Stable Release Candidate?
Some of it is just adding more rigorous code quality testing as the Cisco Meraki platform matures. Cloud adoption continues to grow at double-digit numbers which means it’s increasingly important that firmware labeled stable, is.
One of the new features introduced in MX13 is the ability to add a static IP address to MX appliance WAN (uplink) interfaces remotely via the cloud dashboard. It’s been a longstanding ask and the implementation had to be done carefully. This is a “cloud managed” appliance after all. If you don’t add automated rollback mechanisms after an improper static IP is assigned, you risk losing all remote management to the device.
To further complicate things, it turns out that several of the major ISPs in the US use a widely deployed cable modem that doesn’t handle MX uplink IP changes well. As in it drops connectivity to the MX by not respecting the new assignment. This isn’t a MX problem, but its impact would deliver a terrible experience for enough customers that it wouldn’t be good to ship as stable RC.
Which brings us to today.
Meraki just pushed an updated iteration of MX12 as the latest recommended stable firmware, not MX13. Why? Because delivering a stable release with an updated list of security fixes was too important to delay any further.
I think they made the right call. The tradeoff of waiting for ISPs to fix their kit wasn’t worth keeping MX customers stuck on 2016 firmware for another month.
So what’s actually different MX12-26? It primarily includes a long list of security patches that were previously gated to MX13/14 releases.
The full list can be found in the firmware changelog in Dashboard under Organization > Firmware Upgrades. I’ve also provided the CVE patch list below for reference.
MX12-26 CVE Fixes
Its important to note a couple additional points.
First, the MX250 and MX450 stable release is MX14-13. Z3 stable is MX14-16.
Also, the MX team is still working hard on shipping a stable release candidate for MX13 as quickly as possible. It will come with with several new and notable features including:
- Layer 7-based configuration for SD-WAN
- Static IP assignment via Dashboard (via Appliance Status page)
- Device load monitoring
- Uplink SLA for passthrough MXs (loss and latency reporting on the Appliance Status page)
- Support for using a VIP on one uplink and not using a VIP on the other uplink when the MX is in a NAT HA configuration
- Improved ingress and egress interface reporting within the NetFlow export
MX13 also has some major bug fixes that were not rolled into MX12-26, so that still might be the right path if you need a specific fix.
How To Upgrade to MX12-26
Upgrading an MX network or template is a very simple process with the new Firmware upgrades page in Dashboard. The complete step-by-step instructions can be found on the Meraki Documentation site or you can just reference the workflow below.
For those who were eagerly anticipating MX13 to drop as stable RC, this update might not get you excited. For customers who have been unable to access critical security patches due to RC concerns, this should get you patched and prepped for the forthcoming MX13 firmware.
Regardless, its great to see new firmware flowing again with more to come in the horizon. MX13 will be here shortly and MX14 (hello BGP) will follow. Onward.