New MX 19.1.6 stable release candidate: lots of fixes, not a beta, better formatting 🎉

[cmr]

Security appliance firmware versions MX 19.1.6 changelog

Important notice

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

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 - general fixes

• Corrected a rare device reboot that could occur when BGP was in use.
• Resolved an issue that could cause eBGP routes learned over non-Meraki VPN tunnels to become unreachable after other device configuration changes were made.
• Fixed an issue that resulted in failover between non-Meraki VPN tunnels not occurring in some cases.
• Resolved an issue that could result in MX appliances incorrectly dropping traffic destined for AutoVPN peers for traffic that was received through the WAN interface. This occurred when the MX appliance was configured in passthrough mode and a default route was learned through eBGP.
• Resolved an issue that could result in MX appliances failing to establish an eBGP session with a peer on the LAN. This happened in configurations that used a route overlapping the IP address of the eBGP peer for failover and failback of non-Meraki VPN peers.
• Corrected a regression that caused traffic sourced by the MX to incorrectly follow the client routing table when a default route was advertised and multiple AutoVPN hubs were configured. This affected 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.
• Corrected an MTU issue that could result in MX appliances erroneously performing fragmentation of AutoVPN traffic after encapsulation had been performed. This occurs when the MX appliance is using an MTU other than 1500, such as 1230 or 1486.
• Resolved an issue that resulted in traffic shaping priorities not being applied correctly when default traffic shaping rules were enabled.
• Corrected an issue that could result in an unexpected reboot when an IPv6 DHCPv6-PD packet advertised a prefix of larger than /64.

Bug fixes - limited platform fixes

• Corrected an MX 19.1.4 regression that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances encountering an unexpected device reboot when processing a large volume of network flows.
• Fixed other circumstances that could result in MX75, MX85, MX95, MX105, MX250, and MX450 appliances continually operating at 100% device utilization.
• Corrected a regression that resulted in being unable to perform a factory rest on MX95, MX105, MX250, and MX450 appliances.
• Resolved an issue that resulted in MX75, MX85, MX95, MX105, MX250, and MX450 appliances dropping traffic destined to itself when the traffic was received over AutoVPN. This could cause a lack of response to things like an SNMP walk sent over AutoVPN.
• Fixed an issue that could result in GRE traffic being incorrectly dropped by MX75, MX85, MX95, MX105, MX250, and MX450 appliances when using a 1:1 NAT and the traffic path was a “hairpinned” NAT.
• Corrected an issue that resulted in ​​Z4(C) appliances failing to forward ARP messages that had a VLAN tag, even when the VLAN tagging correctly matched with the Z4(C)'s port configuration.
• Fixed a rare issue that could result in unexpected device reboots for MX67(W), and MX68(W,CW) appliances operating under heavy network load.
• Fixed an issue that could result in the ping live tool failing when trying to ping an IPv6 IP address over a cellular uplink.
• Fixed an issue that could result in port forwarding rules for integrated cellular modems not working after a device reboot was performed.
• Fixed an issue that resulted in vMX appliances running on Cisco UCS servers failing to upgrade to MX 19.1 versions when the vMX appliance was running a version older than MX 17.
• Further resolved cases where MX68(W,CW) and MX85 appliances could improperly attempt to provide PoE power to connected devices.

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.
• Z4(C) appliances fail to properly forward STP frames received on its LAN interfaces.

Other

• MX appliances will now use the IP address of their highest number VLAN as the NAS-IP in RADIUS Access-Request messages.
• The local status page will no longer display fields related to the cellular modem when no SIM card is present in the MX.
• Reduced the power consumption of MX67(W), MX68(W,CW), MX75, and MX85 appliances in some cases.

[thomasthomsen]

I do wonder why this is mentioned under "other":

"MX appliances will now use the IP address of their highest number VLAN as the NAS-IP in RADIUS Access-Request messages." ?

Was this changed to something else ? has this not always been the case (and we are still waiting for the feature where we can actually change this 🙂 ).

[GreenMan]

Yeah - I'm not sure why this has been called out here either.   As you say, it was previously the case anyway.

No news on having UI flexiblity for this, at this stage, unfortunately - customers ask for a lot of different features, particularly for MX.    Fitting them all in and making them work together is a challenge.  If it's particularly pressing for you, I suggest contacting your Meraki account team and explaining the business case, so they can add weight to the official request.

[thomasthomsen]

Thanks. No not a particular challenge (that we cannot work around).

There are other more pressing things, as you mention, on the MX 🙂

[RaphaelL]

Yes. 

Prior to MX18.211.3 it was 127.0.0.1 , we asked Meraki to fix this and comply to the RFC. 

In MX18.211.3 they started using the lowest vlan ID ( which after testing didn't even work). We complained and they changed it in MX 19.1.6 to the highest vlan which makes way more sense since RADIUS packets are sourced from the highest vlan ID.

[RaphaelL]

• Corrected an MTU issue that could result in MX appliances erroneously performing fragmentation of AutoVPN traffic after encapsulation had been performed. This occurs when the MX appliance is using an MTU other than 1500, such as 1230 or 1486.

Those are such odd MTU values. And who is using 1230 ? wow

[thomasthomsen · Accepted solution]

When I see such strange things, I always quote Timmy Turner : "uhh Internet ?" 🙂

[CptnCrnch]

Looking good so far!

[thomasthomsen]

Yeah, no issues here as well (MX85)

[thomasthomsen]

"Fun" issue on MX250 HA pair.

Everytime I did a change (what seemed like any change at the start), the network just freezes up for a minute. 😕

I have narrowed it down to DHCP.

[thomasthomsen]

Me from a normal Cisco switch on "one side" of the MX, pinging a C9300-M on the "other side" of the MX, and then changing the DNS server of a unrelated VLAN on the MX from Umbrella To Google.

(some output omitted).

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!...............................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (9969/10000), round-trip min/avg/max = 1/2/44 ms

Ok those timeouts are of course not a whole minute, but it feels like a LONG time.

😕

[cmr]

@thomasthomsen just for clarity, is it only when you change a DHCP option, range or other setting?

[thomasthomsen]

In the beginning I actually thought it was more things that caused this, like changing / adding / removing an ACL and so on.

But it seems to only be when I change a DHCP setting.

It happens when I change DNS settings, when i reserve an IP in a scope, and so on.

I created a case, just to check my sanity 🙂

And I only discovered it because I was setting up this new network for a customer, and of course, in that process, where changing "a lot" of settings.

And my network connection was , ehhh, wonky. Initially I thought sure, I was connected to a switch or AP that was just connected and needed a firmware upgrade, but I have now narrowed it down to this.