Wow!
Engineering must be doing a spring cleaning of their old defects. Better late than never as they say 😊
Corrected an issue that resulted in client traffic being will be dropped by MX65(W), MX67(C,W), and MX68(W,CW) appliances when 1) The client was connected to a LAN port with 802.1X authentication enabled and 2) The VLAN ID of the port was configured to 16, 32, 48, 64, 80, 96, 112, 128, 144, 160, 176, 192, 208, 224, or 240.
That's been there for a while. 😄
This bit must be stuck in de code
00000000
Yeah... I'm guessing some Dev is cutting corners or doing something "clever" in binary conversion.. 😉
I'd love to see the patch on that one tnough!
I naturally cannot go into more details about the nature of the defect, but I will say, I was the one who scoped that internally, and I got quite the laugh when I determined the scope.
"Wired 802.1X client traffic dropped when port VLAN ID < 256 && VLAN ID % 16 == 0" is certainly one of the more absurd bug subjects I've ever submitted 😁
I've applied it to an MX64, MX65 and pair of MX100s. So far, so good... The MX84 pairs will be the real test.
We updated our MX84 HA yesterday. Everything looks fine so far.
Does this address the WAN speeds issue when IDP is turned on?
I can confirm the "Fixed an issue that resulted in wireless clients experiencing degraded performance for HTTP and HTTPS traffic when content filtering was enabled." worked on a network using a MX68W for firewall/wifi.
They were complaining of slow wifi speeds off the MX since being upgraded to 17.10.2 a month ago, and this patch fixed their complaints on wifi speeds.
Can anyone confirm if this helped correct the below error with Anyconnect? We've been experiencing this and other odd errors ever since we moved from 16.6.6 to 17.10.
Solved: Re: Cisco Anyconnect - SAML using OneLogin for MFA - The Meraki Community
Hi What about URL categories? Are there some big changes? Regards
We have hit one issue with this update. On a site with an HA pair of MX100s that are running in multiple VLAN mode serving DHCP IP addresses on most of them, it stops working for multiple of them and we see the below:
You can see that the device with MAC ending 43 seems to receive an offer in the same way that the device below did, yet it then complains that it doesn't have one. The device does not get an IP and falls off the network.
We tried rebooting the MXs but the issue reoccurred within 5 minutes, so we rolled back.
We don't have any other HA pairs of MXs that serve DHCP and the single MXs we have that do serve DHCP are lesser models such as MX84, MX67 etc. and they all seem okay.
Has anyone else upgraded and HA pair to this release that is acting as a DHCP server for multiple subnets?
This fix might have caused it as 17.10.2 worked fine...
???
Yes we have just run into this today. Our current work around is to swap roles between primary and spare. DHCP service is resurrected. How successful that might be long term is as yet unknown. We have multiple MX100 HA deployments and it has only affected one so far. All template builds so rolling back one means rolling back many. Not keen.
We've run into this same problem with all of our MX100 deployments, as well... I built a quick & dirty script to dig through event logs in the past 5 minutes looking for DHCP failures, then swap the active/standby units, then reboot the standby. I have one pair of MX100s at a large-ish site that gets failed over & rebooted several times per day. *sigh*
We have 10 sites with HA MX100 . This "DHCP problem extra: no_offers_received, vap: 0" bug affected only 1 out of the 20 devices that were upgraded to 17.10.4. So at one site swapping the primary for the spare solved issue. However we didn't want to take the reliability hit and have somewhat reluctantly rolled back to 17.10.2
Rolling back to 17.10.2 and then forward again to 17.10.4 has resolved our DHCP issue.
"Fixed an issue that resulted in fragmented packets that were received by an MX appliance and transmitted across AutoVPN getting fragmented after encryption took place."
We are still seeing this issue with 17.10.4 on a MX67W. Specifically, any SSID advertised on this unit with RADIUS authentication (or wired splash pages with RADIUS authentication) fail due to the MX dropping fragmented RADIUS response packets. The last version of MX to handle this correctly was 16.16.8, which we had to rollback to when 17.10.4 broke RADIUS once again.
For anyone else with similar problems, our MX67W is advertising a 802.1x authenticated wireless SSID and wired VLAN using RADIUS and the RADIUS servers are across the autoVPN in remote datacenters. We have had case 08991820 open since 12/3/2022 for this issue.
We ran into this exact same Radius failure issue with the 17.10.2 firmware (and still with the 17.10.4 patch). We have a couple of branch locations using the MX wifi and Radius over the AutoVPN to a data center. We rolled those MX's back to 16.16.8.
For those couple of MX's at those branch offices, since no patch is forthcoming and we want to update the MX's, we've shipped them an AP to use instead of the built-in MX wifi.
We opened a ticket with Meraki ourselves just to keep it on Meraki's radar.
Tacking onto what NJNetworkGuy100 said, in our lab network, we upgraded an MX68W to 18.106 and RADIUS fails there as well.
Can anyone verify that they are still seeing the issue with access to the status page via Mgmt port? I have an MX84 that we can't get to the status page on, but another one (going to be an HA pair) right next to it that works fine. The one not working has not been online yet, because it needs a static for our ISP.
FYI, All computers behind MX can no longer install OfficeSetup.exe. I was told it was HTTP Content Caching issue. Will need to upgrade to MX 17.10.5