This continues to occur on n426 at seemingly random intervals. So far they tend to last 8-12 minutes, though just recently I had one last from 2:39 to 2:58 PM CT.   Support is aware of the issue (Case 09090667, if any Meraki folks are haunting the forums today) and has notified the product team. I was able to get support on the line while the issue was occurring and they were able to reproduce. Sounds like there's at least one other ticket reporting similar issues.   Anyone else having short outages on their nodes?   EDIT: Added case # ... View more

Occurring again as of 1/10 @ 2:30 PM CT. Same node.   Edit: working fine as of 1/10 @ 2:39 PM CT. ... View more

No, I ended up band-aiding this via an API script that looks for Critical Auth complaints from the switch event logs, identifies the affected ports, removes the Access Policy from those ports, waits 2-3 minutes, then places the Access Policy back in place. ... View more

I've done something similar to this, but use it to get into the web interface of the upstream ISP router/modem/whatever  acts as the internet gateway for the MX/Z3 devices at our remote branches. At the remote site:   SD-WAN & Traffic Shaping -> Local Internet Breakout -> Create a rule that excludes TCP 80 (or TCP 443, or both) destined for 192.168.1.75 (or whatever the FritzBox's DHCP address is).   Then, remote into a workstation/server at the remote site - we use this as a proxy to connect to HTTP(S)://192.168.1.75. The host-specific (or subnet-specific) VPN Exclusion rule makes sure that the traffic targeting 192.168.1.75 on whatever ports we defined doesn't get wrapped up in the AutoVPN and dead-ended at your core. ... View more

I've run into this a few times, and it seems to only occur when performing a POST or PUT via Invoke-RestMethod. My GETs via Invoke-RestMethod tend to work as expected. You can try to specify -maximumredirection ## (default value is 5) to get around this, though I'm not sure if it'll work - can't remember if I fiddled with this or not.   I kludged my scripts to point directly to the shard I'm on - n426.meraki.com/api/v1/. It's not recommended, and I'm sure this will bite me at some point.     ... View more

Am on 426 and it's feeling awfully sluggish this morning. ... View more

Wonder if my notes are wrong. Have you rebooted that MS since disabling those settings? ... View more

I believe we saw something similar when we installed our first MS250 at our HQ, hanging off a stack of Catalyst 3650's. Our firewall suddenly started seeing a bunch of IPv6 router solicitation requests and that set off some alarms (we shouldn't see any IPv6 traffic).   In the end, we ended up disabling IGMP snooping and Flood unknown multicast traffic  under Switch -> Switch Settings -> Multicast Settings. These were enabled by default, with no way to adjust separate settings between IPv4 and IPv6. ... View more

Support can poll the device uptime. Alternatively, you can look through the event log for "Ethernet port carrier change" messages for all of the connected interfaces. For example, when I see that message for ports 1, 2, 3 (we generally don't connect anything to 4 & 5) all with the same timestamp, I know the device rebooted. ... View more

Any chance you control a server/workstation on both ends of the link? Could look at iPerf testing between them. It's a little rough, but you can script around the iPerf3.exe to automate testing and log results per site. ... View more

Took a swing at this this morning and all I'm getting when I try to PUT against  https://developer.cisco.com/meraki/api-latest/#!update-organization-saml-role  the endpoint as documented is either 400 Bad Request or "There was a problem with the JSON you submitted".   I may be doing something wrong but...I dunno. Just for grins, I copied a Request Body example, generated with the form from the endpoint documentation, using just the default values (read-only for org, full access for network) and it just blows up. Curious. ... View more

I'll give that a try and see how it plays, good suggestion.   Honestly was hoping I could use a network tag to tie the switchport modify privileges to a subset of networks to put a nice little bow on this, but when I try to do that I don't see the switchport access tag as an option...bummer. ... View more

100% agree. Being told to use third party products just to see rule blocks is a cop-out. ... View more

I have the same question. We're looking at enabling IDS/IPS on our AutoVPN spoke MX's, but that has the adverse effect of bricking the vulnerability scans against clients/devices behind the spokes. The only exceptions I thought I saw were for particular rules, rather than particular IP's. ... View more

We bumped into this after our first Nessus vulnerability scan against the first few Meraki devices (MR33's and MX67C's) we implemented circa 2020. I can't remember if we reached out to Meraki support about it or not, but our workaround/permafix was to disable the Local Device Status Page across the board.   You can temporarily re-enable the Local Device Status Page if/when you need it. ... View more

Ran low on time so didn't get to do as much testing as I wanted; However, I did work with support today and was able to reproduce the issue by blocking comms between the switch and NPS via FW rule. With the comms interrupted, the port went into critical auth state as expected.   VLAN 10, the workstation VLAN, worked just fine - full open as expected; However, the support rep on the line mentioned that the phone appeared to come up in VLAN 10 instead of 20 (voice vlan - also, the dashboard showed it on 20). He ran a capture and mentioned he could see the phone attempting DHCP (unsure if it was doing this on VLAN10 or VLAN20) and getting no response. The workaround for this is to remove the 802.1X access policy from the switchport...   Additionally, once communications between the switch and NPS server were restored, the port stuck in critical auth mode and did not recover. We verified comms between switch and NPS via the radius test button in the access policy. This appears to be a known issue/is with development for resolution. The workaround for this is to remove the 802.1X access policy from the switchport, and then re-apply it.   If any of the Meraki folks that haunt the forums want to take a glance, this is case # 08412961. ... View more

Tossing my hat in on this as well. Super minor gripe, but it's something that's bothered me for awhile now.   Also...is it just me or is the session timeout kind of hit or miss in general? Anecdotally, I've left the Dashboard open/inactive in another tab for what I'm sure was longer than our timeout and not been prompted to re-login. I've also left the dashboard open/inactive in another tab for less than our timeout and been prompted to re-login. I'm pretty sure I've also seen one tab timeout while another tab did not. ... View more

Yup, I've got an open case with Support at the moment. They grabbed what they could, but need some real-time examples.   These are all MS120 switches   After some research/poking about last week, I've got a bit more information. First and foremost, this seems to surface if the remote network has had any sort of WAN/AutoVPN disruption. From what I've gathered, once a port has gone into crit auth mode, it seems to stay 'stuck' in that state until the 802.1X access policy is removed & re-applied. I suspect a switch reboot would also resolve.   Going to do some on-site testing with a test network (MX67 + MS120) on Wednesday. Pretty confident I can reproduce this by simply pulling the WAN connection for the MX and connecting a workstation to a switchport with the 802.1X access policy. Or using an MX FW rule to explicitly block traffic between the MS120 and the NPS/Radius server.   Will follow-up once this is done. ... View more

The switches in question are running 14.33, I'm gonna go ahead and bump them to 14.33.1 tonight and see if the weirdness goes away before taking this much further. Want to see if that has any impact on these things getting 'stuck' in critical auth, or if it at least fixes the issue with the Voice VLAN not failing open when in a crit auth state.   I'm using separate Data and Voice VLANs (ID's 10 and 20, respectively), though. ... View more

14.33 - That's a good call, hadn't even thought to check the 14.33.1 release notes. I (now) see a mention in there about NAC enhancements, is there anywhere I can look to see what that actually means? ... View more