Meraki

Crocker · ‎Apr 3 2025

Yeah, it was only on the WAN SFP ports that I saw this. My sample size isn't great, I only had the two locations with MX85's that used a WAN SFP port and both showed the same weirdness. Upgrading from MX18.211.2 to MX18.211.5.2 fixed it.

Crocker · ‎Apr 3 2025

Appears to have been a bug with 18.211.2. Upgrading to MX 18.211.5.2 resolved the issue.

Crocker · ‎Mar 31 2025

Oops, I typo'd in the subject line. I meant they're showing 10mbps/full. Have only seen this on my two MX85's using SFP's in WAN1 today, we don't have any 95's.

Crocker · ‎Mar 31 2025

Noticed this morning when looking at an issue at one of my sites - I only have two MX85's deployed that are using the SFP WAN ports, but both show 10mbps/full instead of 1gbps/full when I hover over the port in the Dashboard. Speed tests at the sites show we're getting way more than 10mbps up/down, seems like just a display bug. Anyone else got a few places to check, do you see it too? Edit: Corrected post title, meant 10mbps/full, not 10gbps/full!

Crocker · ‎Feb 20 2025

Anyone else seeing this, or are we just lucky? We have an alerting script that fires 2x a day, 6 AM and 6 PM, which queries the '/organizations/$orgid/appliance/vpn/statuses' endpoint to look for situations where a spoke is online, but cannot reach one or more of our four VPN Hubs (the hubs are Meraki MX450's, most of the spokes are MX67/MX68's). This morning the 6 AM check generated a report listing every. single. one. of our spokes as being unable to reach any of the VPN hubs. To double-check this, I've pulled up the VPN status page at several spokes. Invariably, all of them show uplink decisions as expected, but also show gray for the connection status to all 4 VPN hubs. Our network monitoring system doesn't show any issues reaching any of the spokes, and when I check the 4 VPN hubs I see the expected level of traffic flowing through them. All appears to be working as expected, but the API still claims none of the spokes can reach any of the hubs, and the VPN status pages all show the same. I opened a ticket with support, who mentioned this is a known issue, but from our conversation it sounded like there is/was a known issue with a previous version of the MX software that could generate this problem. The VPN hubs are all on 18.211.2. Most of the spokes are on 18.211.2 or 18.211. I have a test spoke that's on 19.1.6 that also shows the same issue.

Crocker · ‎Jan 29 2025

Yep, time zone is configured correctly at the locations I've noticed this at. I'm in the same timezone as them, as well.

Crocker · ‎Jan 29 2025

I've noticed over the past couple of days, when looking at the Event Log for some of our MX's, that there is a large delay in events appearing in the log. As an example, I'm looking at a network right now (local time 11:48AM CST) whose last event log entry was 8:30:31 AM; I know there's been plenty of events since then. Has anyone else noticed this?

Crocker · ‎Oct 18 2024

From what I can remember (and from what I posted) this was fixed in MX 18.205. There were no additional error messages to check for, I tracked it down by running a constant ping to something at an affected site and matching up packet drops with the DHCPv6 renewal logs showing up in the eventlog.

Crocker · ‎Oct 7 2024

The closest you can get is by going to Network-Wide -> Clients. Set the search filter from All to All Clients with a Policy. Then you can Download As either CSV or XML.

Crocker · ‎Sep 20 2024

If the only thing you're interested in is basic 802.1X/Radius (and you're a Microsoft shop), you could also look at Microsoft's Network Policy Server (NPS). We had it available as part of our Microsoft contracting, and it was a breeze to set up and configure. For HA, we just set up 2 NPS servers and mirrored policy configurations between them, then pointed our Meraki stuff at both of them. ISE only for Radius is major overkill, IMO. Now, if you're looking to move into a more zero-trust security approach and have the budget/time to fully build out/utilize ISE's full suite of features, it's hands-down one of the better options. But just for radius? That's pulling a wagon with a semi.

Crocker · ‎Sep 20 2024

Yes, I don't have a % failure rate, but API calls are not dependable at the moment. I also completely lost access to the dashboard itself in the past 10 minutes or so, it now times out when I try to even pull it up.

Crocker · ‎Sep 20 2024

Appears to be possibly affecting API calls, too EDIT: Appears to be heavily intermittent. I do have several MX's showing offline in the dashboard, but can confirm I can reach the 'offline' devices over the VPN. @Meraki hasn't learned not to make changes on Fridays, apparently

Crocker · ‎Sep 19 2024

Seconding BGP between the concentrators and your core(s)! We have a very similar setup - 2 DC's each with 2 hubs (each hub on a different ISP), DC's connected via dark fiber, with ~200 spoke sites participating in the AutoVPN. All the spokes are full-tunnel AutoVPN. We have BGP stood up between the concentrators and the core L3 switches at both DC's, with the core L3 switches advertising their local supernet into the AutoVPN and receiving routes to the spokes from the AutoVPN. The BGP routes are redistributed into EIGRP, and the core L3 switch at both DC's share routes with eachother via EIGRP. We control/massage load by adjusting the hub priority on a per-site basis to spread the love between both datacenters (and between the concentrators/ISP's at those datacenters). Prior to standing up BGP between the concentrators and the core switches, we were using OSFP and the 'local networks' to advertise the DC supernets into the AutoVPN. However, in this setup, if we lost one or both of the concentrators at one DC, the routes through that VPN concentrator never dropped out of AutoVPN and caused a black-hole situation. This may have been a configuration issue on our side, not sure. One gotcha I remember having to chase up was getting Meraki support to stop the hubs from routing between eachother over the AutoVPN (instead of dumping traffic to the L3 core and letting it route across the dark fiber).

Crocker · ‎Sep 19 2024

When can we expect the postmortem on this? What steps will be taken to try to ensure this doesn't happen again?

Crocker · ‎Sep 18 2024

Throwing in a +1 here. We were fine until around 10:00 AM Central Time, then everything broke/blipped. Luckily enough, we had one of four VPN concentrators running 18.107.X due to an issue with SSID tunneling on MX 18.2, so it picked up the load until we could reboot its buddies which are all on MX18.2.11.2

Crocker · ‎Sep 13 2024

You cannot 😞 If you want any sort of proper reporting on usage, you'll need to stand up a product to process Netflow from your devices.

Crocker · ‎Sep 10 2024

Looking for options to replace an existing L3 Catalyst 2960. Topology is something like: Internet <-> Core network <-> L3 Catalyst (acting as a router for a handful of 'facility' VLANs) <-> L2 Switches <-> Endpoints Everywhere I've deployed an MX has been a spoke facility connecting via the AutoVPN over the internet, so onboarding is pretty easy. Get the MX online, define the VLANs, enable Site-to-Site VPN, and you're off to the races. In this topology, the 'spoke' MX would be on the left-hand side of 'Internet'. Now, I've got a facility that's direct-connected to our network core via and under-the-street fiber connection, they do not have an internet connection. We have static routes on the core switch pointing at the L3 Catalyst to get traffic to the branch, and vice-versa on the L3 catalyst to get traffic to the core. Works great. To swap in an MX, though...Most of the topologies I've seen seem to assume the MX will be a spoke of the AutoVPN, not a direct connection to a network core. Any recommendations on this? Is it as simple as swapping the MX in, pointing my core static routes to whatever IP I give the WAN1 interface to get traffic to the facility VLANs, and adding a GWLR static route to my MX telling it to send everything to my core switch?

Crocker · ‎Aug 27 2024

This is *probably* way over-simplifying things, but we ended up with a similar situation at a couple sites. The way we handled it was using two unused VLANs to stretch the ISP connection from building A to building B, and vice-versa. Talked to the provider(s) to have them widen the subnet a smidge to handle 2 active devices, set IP's on WAN2 on both devices. So, we have ISP auto-failover for both buildings, but not warm/spare in the event we lose one of the MX's; The idea being that one of our regional spares could be easily swapped with the 'dead' MX if/when needed.

Crocker · ‎Aug 22 2024

Seems unlikely, but any chance your organization has more than 1000 networks? I know the Get Organization Networks API call defaults to a perpage value of 1000 if not otherwise specified. You can adjust the perpage value up to 10,000, if this happens to be the case. I don't see a similar limit documented for the other two API calls you mentioned. Recently ran into something similar with the Get Organization Devices API call, except that one doesn't let you request more than 1000 and instead makes you learn pagination (bleh).

Crocker · ‎Aug 22 2024

I asked via my ticket, but I got a pretty general answer. Not a direct quote: Engineering implemented some back-end changes which inadvertently irritated SAML. The changes were backed out, which resolved the problem.

Crocker · ‎Aug 15 2024

Ditto, seems to be working for my folks as well.

Crocker · ‎Aug 15 2024

Spent ~30 minutes on the call while the rep looked into the problem. Had to bail due to a meeting. No progress made thus far.

Crocker · ‎Aug 15 2024

Glad it's not just me. On the line with Support about it now, will post what we find out. Note: We're on N426, incase this is a node specific issue.

Crocker · ‎Aug 15 2024

Anyone else bumping into this today?

Crocker · ‎Jul 1 2024

Do you happen to have a bunch of Site-To-Site VPN Firewall rules? Or a small # of rules with a huge # of associated subnets/hosts? We tried using Z3's in our network, and they worked pretty well for a year or two until we started building out VPN firewall rules. After some point, some critical mass, it was apparently too much for the Z3's to handle and they became very unstable after VPN connectivity blipped for any reason.

About Crocker

Crocker

Community Record

Badges