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 an issue that may have resulted in MX appliances not being able to successfully establish OSPF or BGP sessions.
Fixed several issues that could result in a device reboot.
BGP stability improvements.
Corrected an issue that could result in files with unknown dispositions from the AMP Cloud not being uploaded to the ThreatGrid sandbox for further analysis when the MX was attempting to connect to a ThreatGrid instance in the European Union.
Resolved an issue that resulted in “route connection change” event log messages being emitted for all of an MX’s AutoVPN peers when one AutoVPN peer enabled or disabled AutoVPN.
Corrected a rare issue that could result in an MX appliance failing to properly write a new configuration file to persistent storage. In very rare cases, this may have resulted in static IP configuration being lost.
Known issues
After making some configuration changes on MX84 appliances, a brief period of packet loss may occur. This will affect all MX84 appliances on all MX firmware versions.
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.
Devices connected to ports 3-7 may have issues communicating with devices connected to ports 8-12 on MX68(W,CW) appliances.
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.
NoNAT was initially one of the main reasons for us using it, though we haven't actually used NoNAT yet... We do use the load balancing a lot in the VPN and just connectivity, but that might be in 14.x?
18x MXs now on 15.27 a mix of 64,65,67,84 and 100 models. 84 and 100 models are in HA pairs for SD-WAN, others single for edge protection. Haven't upgraded 250s yet.
Get notified when there are additional replies to this discussion.
