New MX 19.1.5 stable release candidate: first 19.1 non beta with fixes mainly for smaller MXs

[cmr]

Security appliance firmware versions MX 19.1.5 changelog

Important notice

• As of MX 19.1, Cisco Meraki will no longer support USB-based Cellular Failover on the MX and Z platforms.

What's new

• Added support for Advanced Security features on vMX appliances in routed mode
• eBGP (CloudWAN Support) for vMX-XL appliances
• Enhanced event logging for vMX-XL appliances
• Enhanced dashboard tools for vMX-XL appliances
• Enhanced uplink statistics for vMX-XL appliances
• Enhanced client tracking for vMX-XL appliances
• Enhanced fragmentation support for vMX-XL appliances
• Enhanced security center reporting for vMX-XL appliances
• Enhanced route tracking for vMX-XL appliances
• Added API support for configuring VPN NAT Translation
• Added API support for configuring Multicast Forwarding
• Added API support for configuring Split DNS

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.

Bug fixes

All

• Resolved an issue that could result in consecutive Dashboard-initiated reboots triggering MX appliances to fallback to an older version of their configuration
• Improved the management of network flows when source ports are exhausted. This will greatly reduce the impact of port exhaustion on network clients.

Small

• Fixed an issue that resulted in client traffic being dropped for clients connected to ports with 802.1X port authentication on MX67(C,W) and MX68(W,CW) appliances after port or VLAN-based group policy configuration changes were made.
• Corrected an issue that could result in the association time for wireless clients connected to Z3(C), Z4(C), MX67(W), and MX68(W,CW) appliances incorrectly reporting as “-”.
• Resolved an MX 19.1 performance regression affecting Z4(C) appliances.

Medium and large

• Corrected an issue that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances failing to forward inbound GRE traffic to LAN clients.

Known issues

• During the upgrade process, MX appliances upgrading from versions prior to MX 19 may experience a failure to properly classify traffic. This issue will be resolved once the appliance has completed the upgrade to MX 19.
• There is an increased risk of encountering device stability and performance issues on all platforms and across all configurations.

[thomasthomsen]

Upgrading right now 🙂

[cmr]

It's been running stably for me on an MX75 for 28 minutes...

[thomasthomsen]

And it also seems fine for me on MX85.

[MartinLL]

Nice! 

[JonnyM]

---

@cmr wrote:

What's new

• Added API support for configuring Multicast Forwarding
• Added API support for configuring Split DNS

---

Is there any documentation about these two features?

[thomasthomsen]

I was also wondering about Split DNS ... but perhaps its for Anyconnect ? - Or do you mean the API support and not the feature as documentation ?

/Thomas

[JonnyM]

Both, I think I was hoping that we'd get some DNS proxy / conditional forwarder support on the MX platform but that might be asking too much.

[jimmyt234]

Security and SD-WAN (MX,Z) Features Directory - Cisco Meraki Documentation

API for Local/Split DNS Service*

Gives administrators the power to control which DNS requests are answered by which servers.

Sounds like it may be just that! Lacking any other documentation at this time. They have also updated that entry to be 'API for..', it used to just say 'Local/Split DNS Service' so sounds like it will only be configurable in the API and not the GUI??

[thomasthomsen]

Very interesting - Lets see what happens.

[JonnyM]

I'm thinking API first and then they'll build the dashboard interface for it later

[RaphaelL]

• During the upgrade process, MX appliances upgrading from versions prior to MX 19 may experience a failure to properly classify traffic. This issue will be resolved once the appliance has completed the upgrade to MX 19.

I dont understand that at all ... 

[cmr]

I'm guessing the traffic classification engine changed and while it updates, it might not work.  Therefore people could visit sites that are blocked or similar, but just for the few minutes the upgrade takes.

[thomasthomsen]

I was wondering the same thing.

So ... "during" the upgrade the MX can misclassify traffic ??? .. until the upgrade is done at it reboots ?

Is that what it is saying ?

[RaphaelL]

Same... because when the MX is upgrading , well it's upgrading , nothing is working and the device has to reboot to perform the upgrade. 

Orrrr let's say you schedule a device upgrade in 2 weeks. The software is downloaded on the MX and untill the upgrade window , the classification is broken ? 🤔

[cmr]

Normally the MX continues to work from the time you schedule the upgrade, through the download and install and only stops for the reboot.  I think it's the install part where it will pass traffic but might misclassify it.

[Brash]

I think it's as @cmr described - Once you kick off the upgrade, there's a few steps involved (simplified below):
 - 1. Downloading
 - 2. Updating packages/services etc.
 - 3. Reboot of device

I assume the time of misclassifying traffic is specifically between steps 2 and 3 which is probably like a 5-10 minute window.

[Holli69]

Running 19.1.5 since 24 hours ago on MX95 without any issue

[AnythingHosted]

Upgrading MX75 now...

[sptech]

I upgraded a few to test with, any without dual WAN connections immediately quit passing traffic. WAN2 showed 100% loss, even though there was never a WAN2 connected. I converted LAN to WAN and then WAN to LAN and everything started functioning properly and the WAN2 loss went away and the networks started functioning properly.

[cmr]

@sptech what models were those? MX67?

[sptech]

Yes, all MX67.

Only effected devices with something plugged into Port 2 from what I can tell. I've found this to be true on 9 devices so far.

Possibly only devices with static addresses assigned to WAN1. I've got some devices that are DHCP on WAN1 and they weren't affected.

[sptech]

One of these devices was a new MX67 that operated perfectly fine for about 22 hours, then at 20:00 yesterday started going offline randomly (100 + times in 12 hours). Reverted back to 18.211.2 and the issue went away. Device has something plugged into port 2 for the LAN side, no way to go on-site and unplug it to check if converting it to a WAN port and back to LAN port would resolve that issue or not so just rolled back firmware. Issue is resolved on it.

[RaphaelL]

If anyone is upgrading from MX 18.107 or MX 18.211 AND has a signifiant network usage ( device utilization over 15-20% before the upgrade ) I would be curious to see the device utilization AFTER the upgrade. Please share your results.

[BHC_RESORTS]

The 19.x train is supposed to have multicore improvements, yes?

[RaphaelL]

18.211 is supposed to have those improvements , so yes. But I'm curious since I experienced some kind of a bug with device utilization with 18.211.3

[RWelch]

MX 18.211.4 did improve one of my many MX75s that had been averaging 67% device utilization while running 18.211.3. 

I’ve yet to roll the dice on MX 19.1.5 and also curious about what others are seeing. 

I’ve had no high device utilization issues on the MX68s.

[GIdenJoe]

The multicast forwarding feature is interesting because that is one of the huge feature holes that has been present.  So I am to assume we might be seeing PIM support for MX in the future so you would finally be able to have multicast streams in datacenters being able to be forwarded to branch offices.

[CptnCrnch]

Looking good so far!

[cmr]

Nearly 4 days uptime here 🎉

[AaronS]

Known issues - november 12 update

• Due to an MX firmware regression, traffic sourced by the MX may incorrectly follow the client routing table if a default route is advertised and multiple AutoVPN hubs are configured. This can affect the MX's ability to establish an iBGP connection over AutoVPN, as well as impacting its ability to correctly route traffic such as NetFlow and syslog.

[jimmyt234]

Looks like this is also in the MX 18.211.4 changelog

[RaphaelL]

This was also added to the change log : 

Added support for Catalyst and Meraki SD-WAN fabric Interconnect

[DanStewart]

"Added support for Advanced Security features on vMX appliances in routed mode"

Anyone know if this will require a different vMX "Advanced Sec" license or will these features be included with the current Enterprise license?
Data sheet only lists a Enterprise license (as there always has been one license flavor for vMX)

[RWelch]

Meraki Licensing FAQs as of 8/7/24 (documentation doesn't reflect any changes).  Perhaps it's forthcoming?

[DanStewart]

Following-up on my own post.
Advanced Security Licensing is now available for ordering for the vMX platforms.
Example sku: LIC-VMX-S-SEC-1Y

Today, the online FAQs and other licensing documents do not look to be updated showing exactly which features this license provides.

Also this new Adv. Sec license tier seems to be impacting dashboards running mixed Enterprise and Advanced licenses that was not an issue with vMX prior.
https://community.meraki.com/t5/Cloud-Security-SD-WAN-vMX/vMX-now-requiring-edition-to-match-org/m-p...

Will keep watching for updates. thx.

[0AK13Y]

There is a known routing issue according to TAC for Z3s running 19.1.5. Excessive flapping to SDWAN site connections and to secure connect