New MX 17.10 Stable Release Candidate - fixes for VPNs and smaller appliances, no longer unstable!

cmr
Kind of a big deal
Kind of a big deal

New MX 17.10 Stable Release Candidate - fixes for VPNs and smaller appliances, no longer unstable!

Security appliance firmware versions MX 17.10 changelog

IMPORTANT NOTICE

  • While Meraki appliances have traditionally relied on UDP port 7351 for cloud communication and TCP ports 80 and 443 for backup communications, with MX 16 we are beginning a transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that traffic using TCP port 443 between 209.206.48.0/20 is allowed through any firewalls that may be deployed upstream of your Meraki appliances.
  • HTTP proxy, which allows default management traffic from MX appliances to be sent through a proxy, is deprecated on MX 16 and higher firmware versions.
  • The transition to Cisco Talos intelligence for our content filtering services means that some URL categories have changed names, some categories are no longer available, and multiple new categories are now available. Please review your configuration after upgrading to ensure content filtering is effectively tailored to your needs and deployment environment.

LEGACY PRODUCTS NOTICE

  • When configured for this version, Z1, MX60, MX60W, MX80, and MX90 devices will run MX 14.56.
  • When configured for this version, MX400 and MX600 devices will run MX 16.16.5.

BUG FIXES

  • Stability improvements for MX67(C,W), MX68(W,CW), MX75, and MX85 appliances.
  • Fixed an issue that resulted in AnyConnect authentication improperly failing when an external browser was used to perform SAML authentication for RA VPN.
  • Resolved an issue that could result in period packet loss on Z3(C) appliances when 802.1X port authentication was configured.
  • Corrected an issue that could result in scheduled group policy firewall rules still being enforced when outside of the scheduled time.
  • Fixed a rare issue on MX64W and MX65W appliances that resulted in higher than expected device utilization when No wireless SSIDS were enabled.
  • Resolved an issue that resulted in MX67W and MX68(W,CW) appliances being unable to use more than 20MHz-wide wireless channels when the regulatory domain was configured as Japan.
  • Fixed a rare MX 17.8 regression that could result in MX appliances entering into a reboot loop when 1) the MX has a large number of AutoVPN routes and 2) the AutoVPN routes are shared across multiple hubs.
  • Corrected an issue that resulted in increased device utilization when non-Meraki VPN traffic was present. This fix reintroduces a bug that results in non-Meraki VPN traffic not respecting configured traffic shaping rules.
  • Resolved an issue that could cause small, periodic packet loss on MX100 appliances.

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
  • Due to an MX 15 regression, the management port on MX84 appliances does not provide access to the local status page
  • Client traffic will be dropped by MX65(W), MX67(C,W), and MX68(W,CW) appliances if 1) The client is connected to a LAN port with 802.1X authentication enabled and 2) The VLAN ID of the port is configured to 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, or 240.
26 REPLIES 26
cmr
Kind of a big deal
Kind of a big deal

About half of our networks have had Meraki schedule upgrades from 17.9 already and we have upgraded 2 sites manually.  So far, so good.

cmr
Kind of a big deal
Kind of a big deal

So far we have upgraded a number of the below, running the Enterprise license:

 

MX64

MX65

MX67

MX84

 

And the below with the SD-WAN plus license

 

MX75

incinrea
Here to help

I've upgraded my MX85 from 17.9 to 17.10. Unfortunately I observed that after the upgrade to 17.10, my uplink WAN connection (1x PPPoE to a single ISP) has capped to around 100 Mbps download and 100 Mbps upload. With 17.9, I manage to get the true speed subscribed from ISP which is 800 Mbps download and 200 Mbps upload.

 

Now I fallback my MX85 to 17.9 and everything back to normal speed.

cmr
Kind of a big deal
Kind of a big deal

@incinrea that is interesting, on the MX75 I have a 500/500 line and it is still running at 500 both ways. No PPPoE though... 

right. I noticed some user that downloaded MX18.101 beta has experience similar experience where the WAN speed has been capped into certain limit.

 

Unfortunately, the content has been removed.

 

FYI, I've PPPoE with IPv6 capabilities.

hi, I just want to update you and the team here that I've tried to upgrade my MX85 from 17.9 to 17.10 again and this time I want to report that my I manage to get the true PPPoE connection speed, i.e. Download 800 Mbps and Upload 200 Mbps.

 

So far so good.

 

Thank you.

rhbirkelund
Kind of a big deal

I wonder when this will get fixed.

 


  • Client traffic will be dropped by MX65(W), MX67(C,W), and MX68(W,CW) appliances if 1) The client is connected to a LAN port with 802.1X authentication enabled and 2) The VLAN ID of the port is configured to 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, or 240.

 

LinkedIn ::: https://blog.rhbirkelund.dk/

Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂

All code examples are provided as is. Responsibility for Code execution lies solely your own.
sebas
Getting noticed

Fortunately this has been fixed from 17.9: 

  • There is an increased risk of encountering device stability and performance issues on all platforms and across all configurations.

 

We'll wait for 17.10 to become the stable version.

RandyD
Here to help

MX67W updated to 17.10 but wireless clients experiencing extreme slowness.  Had to roll back to 17.9.

See also this community thread: After firmware update 17.10 - WLAN, iOS devices are slow and App Store runs... - The Meraki Communit...

harmankardon
Getting noticed

This firmware finally resolved the issue I was experiencing with MX67C devices randomly rebooting, been waiting a while for this one.

thomasthomsen
Head in the Cloud

I think Im seeing some strange behaviour on MX84 and Layer 7 Firewall rules.

The layer 7 firewall seems to block internal DNS requests (Clients on one vlan - dns server on another). DNS seems to be classified as eDonkey P2P traffic ... 😕

To external DNS servers it seems to work fine ... very strange.

 

Im also seeing some strange behaviour on MX85 where it will stop traffic for small periods of time during the day, seems to be related to IPS rules that is being hit a lot of times all of a sudden, but Im more unsure of this one, --- It could also be a coincidence , and its in reality the WAN switch in this setup that is running out of buffer (for some reason).

Hmmmm ... I think 17.10.2 reintroduced the EEE bug on the MX85 boxes I monitor ...

From just around the update I have started to see a lot of "Ethernet port carrier change" in the eventlog.

I will try to "investigate" some more .... 

 

Amir_Khurshid
Conversationalist

Hello All,

You need to check Content Filtering for the sites. As with upgrade Meraki is pushing some additional Content filtering groups on the site which impact Internet and IPSEC traffic (Syspro & Flowcentric ).

Removing Content filtering categories resolved the issue.

Also check Layer 7 rule and change Peer to peer traffic

Security_IR
New here

Hellos All ,
Merakis MX100 will no longer have reboots after updating the version of the fireware

cmr
Kind of a big deal
Kind of a big deal

@Security_IR, in my experience, you need 17.10.2 to remove reboot issues for both MX100 and MX84.

Erminio
Here to help

All our MX's (64, 65, 67, 68, 84, 100) have been running 16.16.7 for a while. I have tried to upgrade to 17.10 on several customers, but they all encountered slow dns performance. Basically because i could not change the content filtering setting to Top sites only (better performance). I had to roll-back the upgrade to 16.16.7. Meraki support told me in the next version it will be solved. Does anyone know if the slow dns/category filtering problem is solved in 17.10.2 ?

Lurick
Getting noticed

Not yet, I'm still having issues on 17.10.2 as well and have rolled back to 16.x until this is fixed.

Erminio
Here to help

I will upgrade some customers this weekend. Lets see what happens next week.

I will keep you posted 🙂

Erminio
Here to help

Migrated 2 customers to 17.10.2 and the first test and production weeks reveals no dns performance problems.

I had to adapt/change/add all the "content filtering" categories as they were change to the Talos cloud solution.

Apart from that, its looking good.

RobertMueller
Conversationalist

It seems that there is a problem with the 17.10.x Version when a iOS Devices uses WIFI to connect to the INet. The performance is incredible slow.. Is there a chance that this will getting fixed soon?

We have a lot of Wifi iOS devices, who are using the internet without any problem.

Are you using Meraki MR access points as a Wifi solution ?

Erminio
Here to help

Still some performance problems with dns requests to the internet. Had to go for a roll-back to 16.16.8.

Are you still experiencing this problem because I am. 😞

I've not checked recently on 17.x but I'm on the latest 18.107 image and haven't seen the issue but it's on a limited lab rollout right now.

I am on MX 18.107 and my MX67W is performing well on this version.  I am not seeing the slowness in resolution like I was, and content category filtering appears to be working too.

I was able to fix the problem by upgrading to v18 and change Client tracking to "IP Address." The problem was the new Content filtering changed in v17 was not working well with my internal L3 routing. 

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