New MX 18.211.0.1 stable release candidate firmware released: fixes priority queue drop bug

[cmr]

Security appliance firmware versions MX 18.211.0.1 changelog

Important notice

• USB modems with MX/Z series devices running firmware MX 18 or newer will be limited to best effort support and will not be receiving any future firmware fixes or improvements.

Bug fixes

• Fixed an MX 18.211 regression that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances that had traffic shaping rules configured with "high" or "low" priority incorrectly dropping traffic being routed between VLANs or AutoVPN.

Legacy products notice

• When configured for this version, Z1 devices will run MX 14.56.
• When configured for this version, MX400 and MX600 devices will run MX 16.16.9.
• When configured for this version, MX64(W), MX65(W), MX84, MX100, and vMX100 devices will run MX 18.107.10.

Known issues status

• This list is being reviewed and updated.

Known issues

• In rare cases, MX67C, MX68CW, and Z3C appliances may fail to enter into a "Ready" state despite being able to register to a cellular network and obtain an IP address for the modem.
• The Non-Meraki VPN service may fail to properly establish IKEv2 tunnels when the MX appliance is acting as the IKEv2 responder and many allowed subnets are configured.
• Due to an MX 18.2 regression, the link light LED for WAN2 on MX75 appliances will not light up if WAN2 is the only wired interface in use.
• Due to an issue with no known method of reproduction, the IDS and IPS process may unexpectedly restart.
• When a WAN failover occurs, Non-Meraki VPN tunnels will persist on the backup, non-primary uplink after a failback to the primary WAN interface if the WAN interface uses IPv6.
• Due to an issue still under investigation, MX appliances may experience an unexpected reboot when ThreatGrid is enabled.
• MX AutoVPN tunnels fail to generate new connections when the AutoVPN flow has been blocked or filtered unidirectionally by an upstream or intermediary device. This prevents appliances from automatically working around this partially connected state.
• MX appliances may experience unstable eBGP connections when 1) the MX appliance is configured in Routed mode and 2) the MX learns a large number of routes from its eBGP neighbor. This may result in eBGP-learned routes being inaccessible.

[PhilipDAth]

What the hell?  18.211.0.1?

Lets not go Cisco Enterprise on the version number.  18.211.1 would have been fine.

Next thing the version numbers will look like SNMP OIDs.

[TyShawn]

I totally agree with you here. On a second note this release resolved my SNMP issue that was introduced in the prior release. I will report back if new issues or this issue returns.

[RaphaelL]

 According to the doc , https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/... 18.211.0.1 means that is it a urgent fix and not a maintenance.

<Product Name> <Major Version>.<Minor Version>. <Maintenance  Version>. <Hotfix Version (if applicable)>

What confuses me is that part : 

• MX appliances are using an updated version of this convention that will be further supported through the Dashboard UI and API in future updates.

  • Major Versions (major changes, representing a family of feature releases)
  • Minor Versions (represents the feature release within the major version and comes with new features)
  • Point Release (takes minor version definition)

18. ( major ) 2. ( minor ) 11. ( point release ) .0 (?) .1 (?)

I'm lost lol.

[PhilipDAth]

I like this bit.

"The user interface currently represents the minor and point release numbers together. For example, MX 18.1.05 will be represented as MX 18.105. Thus, MX 18.201 would represent a different minor version and feature set than any MX 18.1XX releases."

What does that mean.

[mlefebvre]

They did the right thing using that extra digit here like they should be doing because that's how you use the Semantic Versioning specification, we should be encouraging them to do that more often because it makes the version numbers more meaningful and and tells you (in theory) how much or little has changed and what kind of changes were made from the version number, which is very helpful for testing and phased deployment.

[PhilipDAth]

That is something a developer would say.  🙂

Meraki's core design principle is "keeping it simple." For the market it is pitched at, that principle trumps developer versioning rules.  IMHO.

[mlefebvre]

This isn't just a developer thing though, and they don't make it more complex as long as you know what the four columns in the spec mean. I would argue it actually makes it simpler, because now at a glance you can see more than just that it went up a number, which number went up has much more significance and tells you at an immediate glance what to expect.

In this case I see a dot hotfix and that tells me based on semantic versioning that the only change they've made is probably this exact bugfix, so I have a lot more confidence that I can safely try to apply it right away, whereas I would be much more wary of a patch with the usual dot increments that Meraki would use because it could contain other code that we don't know about and needs testing...such as 18.2.210 -> 211 somehow breaking all inter-VLAN traffic with a QOS rule.

[PhilipDAth]

>as long as you know what the four columns in the spec mean

But why should you have to know this? Meraki is meant to be usable by people who are not technical specialists.  That is the whole premise of the product family.  Using the cloud to remove the complexity from the network.

[mlefebvre]

It is also spelled out in Meraki's documentation. Yes Meraki is meant to be "simple"(ish) but this is still business-grade networking, and I don't really buy that one extra dot of documentation is making their firmware upgrades unusable, it is just a benefit to certain people and meaningless to others.