New 15.x firmware

[cmr]

15.24 and 15.25 no longer mention the MX84 suffering packet loss after reconfiguration, however it is now mentioned that MX67/68 may do...:

Security appliance firmware versions MX 15.25 changelog

Important notice

• This is a beta version for the next major MX release. Due to this, we recommend taking additional caution before upgrading production appliances. Where applicable, MX 14 releases will provide a more stable upgrade alternative.
• The DES encryption algorithm is no longer supported for use in formation of VPN tunnels.
• Creating VPN tunnels using aggressive mode IKE is no longer supported.

Supported products notice

• Z1, MX60, MX60W, MX80, and MX90 devices are not supported on MX 15 and newer releases.

Bug fixes

• Resolved a rare issue that could result in content filtering lists not updating properly.
• Corrected a potential issue that may have resulted in unnecessary CPU utilization.
• Made slight improvements to the efficiency of processing traffic in some cases.
• Resolved an issue that may have decreased the resilience of the BGP functionality on MX.
• Fixed an issue that may have resulted in MI loss calculations being less reliable on the MX67(C,W) and MX68(W,CW) platforms.

Known issues

• Some stability-impacting issues present in MX 14.19 that affect a small population of MX250 and MX450 devices still exist.
• Please note that until certification has been obtained, the Z3C will not be supported on Verizon's network.
• World-wide device SKUs of the MX67C, MX68CW, and Z3C units cannot be deployed in North America and North America device SKUs of the MX67C, MX68CW, and Z3C units cannot be deployed outside of North America.
• When deployed in warm spare / high availability (HA), MX67C and MX68CW do not support using their cellular connectivity to pass client traffic. In this deployment, the cellular connectivity can only be used for device monitoring or network troubleshooting. This is an expected limitation for these platforms.
• When MX67(C,W) and MX68(W,CW) units are deployed in warm spare / high availability (HA), rebooting the spare appliance may cause a disruption of client connectivity for 10 or more seconds.
• After making some configuration changes on MX67(C,W) and MX68(W,CW) appliances, a period of packet loss may occur for 10 or more seconds.
• For a brief period of time upon boot, MX67(C,W) and MX68(W,CW) platforms can become bridged. This increases the likelihood of network loops forming in topologies with multiple inter-connected network devices for this brief period of time.
• MX67C, MX68CW, and Z3C units must be connected to the Meraki Dashboard initially to retrieve an update to allow for proper use of the integrated cellular connectivity. This is most likely to be an issue when bringing the units online for the very first time.
• On the MX67(C,W) and MX68(W,CW) platforms, when the MX is providing PoE to a connected device, this information will not be reflected on the Meraki Dashboard.
• Once a Z3 has been updated to this firmware version it can only run MX 14.31 or MX15.8 and higher. This is an expected result of updates to the device booting mechanisms and this limitation will not be resolved in future releases.
• Due to MX 15 regressions, USB cellular connectivity may be less reliable on some modems.
• Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page.
• Due to issues still under investigation, MX84, MX100, MX400, and MX600 appliances may not be able to establish OSPF or BGP sessions.
• As a new major version evolving through beta, there are a number of new, uncommon issues that may result in device reboot that we are continuing to investigate and work through. In particular, the Z3(C), MX84, MX100, MX400, MX600, MX250, and MX450 appliances have unresolved issues that we are tracking closely and continuing to investigate and drive towards resolution.
• Devices connected to ports 3-7 may have issues communicating with devices connected to ports 8-12 on MX68(W,CW) appliances.

[Banfield75]

Will this be the final 15.x “Beta” version?Is it good enough so that customers will move from 14.x to 15.x? No, I don’t think so. So tired of yet another beta with few fixes. Speed up the adoption, specific in the beta which “old” product is “safe” to upgrade, because the same fixes exist in the new version. 

[cmr]

We've been using the 15.x train for over six months for our UK WAN and customer internet edge. We haven't had any unexpected issues across 9 sites, thousands of users and ~25 MXs.

Big caveats:

We don't use the advanced license features

We don't use cellular or Wi-Fi models

We don't use BGP/OSPF in production

We have MX64,65,67,84,100&250 models.

[Banfield75]

Yes.... maybe at your sites 😀 But a firmware that don´t move from Beta to Stable release candidate tells us that it´s lack of system that have upgraded. Why? The big question is how to get an faster and wider adoption?
I believe that better information will speed up the adoption. Example... This Beta 15.x is equal with 14.x when it comes to fixes for the following products  xx,xx,xx.... So it "safe" to upgrade as long you don´t use these network features. 

[CptnCrnch]

Have you read https://documentation.meraki.com/zGeneral_Administration/Firmware_Upgrades/Meraki_Firmware_Release_P...

Especially this part:

“The latest beta firmware is fully supported by our Support and Engineering teams. Older betas are supported with best effort; an upgrade to the latest beta will ensure full support.“

[Jwiley78]

I had to use Beta version about a week ago in order to get a client up to PCI compliance.

[Banfield75]

My point is how could we/Meraki speed up the span of deployed sites? Customers don´t have time to upgrade now and then beta versions, even if it is supported. I believe the majority of customers consider upgrading when the software hits "Stable Release candidate".

Look in to this..... 

Stable: When Meraki's install-base hit a specified threshold for a major version (roughly 10-20% of nodes), that firmware revision will be promoted to GA"

This means firmware 15.x haven't reached 10-20% of the installations?

[hailst0rm]

I thought it was less about time and more that its always been convention never to use anything that is beta or release candidate in a production environment.

[cmr]

Meraki don't use beta and release candidate in the same way as other vendors.  They simply mean that it hasn't been rolled out to more than a certain percentage of users.

It is something like:

<10% of major version deployed leads to beta

<10% of minor version deployed, but >10% major version deployed leads to release candidate.

i.e. Stable MR is 26.6, new MR 26.7 comes out, it will be RC, new MR 27.3 comes out, it will be Beta