New MX 18.211.3 stable firmware: Reboot fix, traffic drop fixes and loads more!

Solved
cmr
Kind of a big deal
Kind of a big deal

New MX 18.211.3 stable firmware: Reboot fix, traffic drop fixes and loads more!

Security appliance firmware versions MX 18.211.3 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

  • Stability improvements for VMX-XL appliances.
  • Corrected an issue that could result in brand new MX67(C,W) and MX68(W,CW) appliances taking significantly longer than expected to perform a firmware upgrade.
  • Resolved an issue that would cause intermittent AnyConnect authentication failures when SAML authentication was in use.
  • Fixed an extremely rare issue that could result in an unpredictable set of firewall rule sets to fail to allow traffic as configured. This would be consistently reproducible as long as the firewall configuration remained identical. Since the likelihood of encountering this is extremely low, any modification to the firewall rule set, including changes that would produce no functional change to network operations, would remediate the issue.
  • Resolved a rare issue that could result in traffic being improperly dropped by MX75, MX85, MX95, MX105, MX250, and MX450 appliances.
  • Fixed an issue that could result in a device reboot when very large or very complex firewall rules were configured in the L3 firewall or the site-to-site VPN firewall.
  • Corrected an issue that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances being unable to successfully establish IPSec VPN connections when NAT-T was required to establish the connection.
  • Fixed an issue that caused disabled ports to still provide PoE.
  • Resolved an MX 18.211 regression that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances failing to properly forward Radius Authentication traffic when configured as a Wireless Concentrator for SSID Tunneling or Layer 3 Roaming. This caused clients to fail to connect to wireless SSIDs.
  • Corrected an issue that resulted in the primary MX appliance in a warm spare configuration advertising an incorrect VRRP priority when cellular active uplink was enabled.
  • Fixed an issue that could result in EBGP peering instability when 1) the MX appliance is configured to operate in routed mode and 2) many EBGP routes are received.
  • Resolved a rare issue that could result in Z3(C) appliances failing to advertise any SSIDs.
  • Corrected a packet routing issue that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continuously operating at 100% device utilization.
  • Fixed an MX 18.2 regression that could result in ThousandEye’s Path Visualization failing for traffic routed over Non-Meraki VPN on MX75, MX85, MX95, MX105, MX250, and MX450 appliances.
  • Resolved a rare issue that resulted in MX appliances failing to block websites when the TLS initialization messages were segmented across multiple packets.
  • Corrected an issue that resulted in MX appliances always setting the NAS-IP attribute in RADIUS Access-Request packets to 127.0.0.1. The NAS-IP will now be the IP address of the MX’s lowest numbered VLAN.
  • Fixed several rare cases that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances improperly dropping traffic destined to or from a VPN peer.
  • Resolved an issue that could result in MX67C and MX68CW appliances failing to correctly establish cellular connectivity after swapping SIM cards.
  • Fixed an issue that resulted in devices not reporting the category that caused a URL to be blocked by content filtering when in full list mode.
  • Fixed a rare issue that could result in a device reboot when IDS/IPS was enabled.
  • Corrected a rare MX 18.2 regression that could result in MX67C, MX68CW, and Z3C appliances failing to establish a cellular connection using the integrated cellular modem. Fixed an issue that could result in the Route Table page failing to display correctly. This was caused by BGP routes with very long AS paths. MX appliances will now only report the first 50 AS paths to the Route Table.
  • Corrected a rare issue that could result in MX67(C,W), MX68(W,CW), MX75, and MX85 appliances failing to forward traffic on a subset of physical ports. This was most likely to occur after extended periods of uptime.
  • Resolved an issue MX67C, MX68CW, and Z3C appliances may fail to apply IPv4-only custom APNs.
  • Disabled IMS for the generic cellular carrier profile.

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.11.

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.
  • Trusted traffic exclusions will not function on Z4(C) appliances if AMP is configured.
  • Due to a rare issue, MX appliances may fail to initiate non-Meraki site-to-site VPN connections when IKEv2 is used. This is most likely to occur when there are mismatched VPN subnets configured between the MX and the non-Meraki VPN peer. This will be resolved in MX 19.1 releases.
  • Due to an issue under investigation, VMX-XL appliances fail to add local networks into the routing table.
  • Due to an issue under investigation MX75, MX85, MX95, MX105, MX250, and MX450 appliances may report an erroneous spike in network traffic usage.

Other

  • Added SIM configuration information for AT&T FirstNet and TRUE-H cellular operators for MX67C, MX68CW, Z3C, and Z4C appliances.
If my answer solves your problem please click Accept as Solution so others can benefit from it.
1 Accepted Solution
RaphaelL
Kind of a big deal
Kind of a big deal

Almost the same fixes that 18.107.11 got  ( which btw the firmware bot missed last week )

View solution in original post

13 Replies 13
PhilipDAth
Kind of a big deal
Kind of a big deal

That is a lot of fixes!

PhilipDAth
Kind of a big deal
Kind of a big deal

Interesting, this does not appear under "Stable firmware" for me - it is in a new category called "Other available versions".  That doesn't sound very comforting.

 

PhilipDAth_0-1723409483935.png

 

ww
Kind of a big deal
Kind of a big deal

107.2 had the same, while other version was .11 at some point

 

It would be better if you could set yourself a default/target version for the org. So that every new location can use this

https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/...

RaphaelL
Kind of a big deal
Kind of a big deal

Almost the same fixes that 18.107.11 got  ( which btw the firmware bot missed last week )

Tony-Sydney-AU
Meraki Employee
Meraki Employee

Hey everyone! It's good to notice that if you Schedule a firmware upgrade and your MX is a Legacy one, you'll not find the latest legacy firmware. E.g.: I have two MX64 and when I schedule a firmware upgrade, only versions listed are 18.211.3 and 19.1.3; however, the end result is both MX running 18.170.11 after successful upgrade.

 

Here you have some screenshots for your reference:

Screenshot 2024-08-12 at 11.44.55.png

Screenshot 2024-08-12 at 11.45.36.png

 

If you found this post helpful, please give it kudos. If my answer solved your problem, click "accept as solution" so that others can benefit from it.
RaphaelL
Kind of a big deal
Kind of a big deal

  • Corrected an issue that resulted in MX appliances always setting the NAS-IP attribute in RADIUS Access-Request packets to 127.0.0.1. The NAS-IP will now be the IP address of the MX’s lowest numbered VLAN.

 

That 'fix' doesn't make any sense. MX RADIUS packets are sourced from the highest vlan ID. Why would you modify the NAS-IP to the IP of the lowest vlan ID ?

FRover
Here to help

Should the 4G cell issues be corrected now with this FW?

ntuccillo
Here to help

Team,

 

Do we know for sure if this is a stable version? Doesn't appear that way in the Firmware Upgrades page.

 

Thanks.

RaphaelL
Kind of a big deal
Kind of a big deal

Hi Before you are able to upgrade directly to the patch version (.3) you must upgrade your firmware to the base version before hand which is 18.211.2 Once you upgrade your devices to this firmware then the option to upgrade to 18.211.3 or any patch version of 18.211.X should be visible.

jimmyt234
Building a reputation

I would not consider this stable firmware as it does not appear under the 'Stable' release tab on the dashboard. We have also had tickets raised where Meraki support engineers refer to this as not being the stable version.

Lourdes
Getting noticed

I'm having an issue with 18.211.2. Whenever I change config in our firewall all of our switches go down. Do you think this will fix our issue?

 

ntuccillo
Here to help

Leaning towards it's a switch issue. Possibly out of date firmware for your switches? Know they made some changes to unexpected reboots and such in the MS/CS 15.X upgrades.

Lourdes
Getting noticed

I change the firmware to .3 and the issue got resolve. However, I'm currently having different issue with the current firmware. 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels