Meraki

Crocker · ‎Mar 2 2023

Are your zScaler tunnels stood up between your MX's and the zScaler datacenters? Or does the internet/zScaler-bound traffic traverse a Meraki AutoVPN tunnel back to a head-end somewhere?

Crocker · ‎Feb 9 2023

Good evening! We installed our first MX75 earlier this week, and I can't seem to get accurate Netflow out of it. I get maybe 1/10th of the flow data that I think I should. Example: If there's 100mbps (sustained) passing through, the conversations I do see account for maybe 10mbps of that. I've got several MX67/MX68's, and a pair of MX85's that are delivering Netflow just fine - no issues with any of them. For the record, we are using a 1gbps fiber SFP to bring in WAN1. WAN2 (or WAN3, I guess?) is just a copper handoff. This appliance is currently running MX17.10.2. Anyone know if there are any gotchas with Netflow and MX75's?

Crocker · ‎Jan 23 2023

It's throwing an HTTP 403, which smells like it doesn't like your API key or the account associated with it. Can you post or put to any other endpoints with that key without error? I've had some issues getting Invoke-RestMethod to consistently follow redirects through https://api.meraki.com/ ; However, usually that issue throws HTTP 308 error codes. Just for grins, it might be worth swapping in your node IE https://n263.meraki.com/ in place of that.

Crocker · ‎Jan 13 2023

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 #

Crocker · ‎Jan 10 2023

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

Crocker · ‎Jan 5 2023

Getting Server Errors after signing into Dashboard on N426. Was working fine up till about 10:30 AM CST. Anyone else? Edit: Dashboard on N426 is behaving itself again as of 10:43 AM.

Crocker · ‎Dec 14 2022

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.

Crocker · ‎Dec 13 2022

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.

Crocker · ‎Dec 2 2022

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.

Crocker · ‎Nov 23 2022

Just noticed this on a handful of MX67 nodes running MX17.10 (not sure how much that info matters). They're showing no VPN connection, though I know the branch is up and running just fine. Also, on the Network summary page, it's showing 0/2 healthy uplinks but if I click into the uplinks all is well. I've got one MX telling me there's no traffic and no clients when I can clearly ping/communicate with clients behind the MX! Anyone else bumping into this? I've opened a ticket with support in the meantime. EDIT: Also, we're on shard 426

Crocker · ‎Oct 31 2022

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

Crocker · ‎Oct 12 2022

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

Crocker · ‎Oct 12 2022

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.

Crocker · ‎Oct 12 2022

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.

Crocker · ‎Sep 15 2022

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.

Crocker · ‎Sep 15 2022

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.

Crocker · ‎Sep 13 2022

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.

Crocker · ‎Sep 12 2022

I'm looking to allow our help desk techs to adjust non-trunk switchports. For example, swapping VLAN assignments when moving different bits of hardware around (phones, desktops, printers, etc). I see that we can create a switchport tag, and grant that tag the ability to modify switchports. With an API script, I can determine if a port is an Access or Trunk port, and assign the tag appropriately. I see that the switchport tag privilege propagates to all networks, which is great; However, I don't see an immediately obvious way to grant a user (or a SAML role) the privilege across the across the board. It appears that I have to add this privilege for each network within our organization to that user (or SAML role)? Am I missing something obvious?

Crocker · ‎Sep 7 2022

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

Crocker · ‎Sep 7 2022

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.

Crocker · ‎Sep 7 2022

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.

Crocker · ‎Aug 19 2022

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.

Crocker · ‎Aug 18 2022

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.

Crocker · ‎Aug 15 2022

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.

Crocker · ‎Aug 11 2022

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.

About Crocker

Crocker

Community Record

Badges