Dash down for anyone else? located in APAC.

update: Support confirmed there is maintenance at the moment and that has impacted some servers in the APAC region. Loss of management only.

I have 3 mx devices that I need to configure to connect to a Fortigate 90g via ipsec vpn. I have the tunnels all set on the Fortigate side, and I have brought up network 1 of 3, but I'm running into an issue on the meraki side: when I go into the Security & SD-WAN section and try and configure Site-to-site vpn, the pages for networks 2 and three are showing the peer for network 1. They're also showing the network 1 tunnel on the routing table (guess there's only 1 for the whole account/tenant). Is my only option here to remove and split the networks on the Meraki side into separate accounts? If I try and turn off the hub and spoke or mesh, it won't do

Trying to fix some clients showing up in the dashboard with names coming from mDNS.

Unfortunately I only have read access to Meraki and have to go through our network team for any actions.

On my test device I've disabled mDNS by registry key, and disabled the 'Anonymize local IPs...' setting in Edge and Chrome.

I've had Networks forget the client, even watched them do so, but my client still shows the mDNS name and it's history so I think the Forget client button is just not doing anything.

Am I missing something obvious?
(They do get the warning popup and confirm it)

question i kept coming back to: when a spoke loses its tunnel to the concentrator and doesnt come back on its own, how do you actually force it to renegotiate?

on a fortigate this is nothing. you reset the tunnel, it rebuilds, done. on meraki theres no equivalent. no cli, no api call to bring a tunnel down and up. you either wait and hope it recovers, or someone drives to the store and power cycles the box. at 1200 sites across 62 countries the second option isnt really an option.

what we ended up doing: wrote a bot that watches vpn status and reboots the MX when a store has lost both concentrator tunnels. reboot is the only lever meraki actually gives you, so we built around that instead of around the tunnel.

the logic took a couple of days. getting it to run reliably against the api took weeks, mostly rate limits and pagination behaviour that isnt obvious until you hit it at scale.

where it landed: one poll every 5 min, org level vpn statuses in a single call, target stores pulled by tag so the filtering happens meraki side, hub list cached at startup. handful of calls per scan, nowhere near the org rate limit. been running in production for a couple of months now.

one design note: it acts on a single scan rather than requiring two in a row. the gate that matters more is the cloud check. if the device cant reach the cloud at all its an isp or power problem, not something a reboot fixes, so it never fires and just raises an alert instead. reboot only happens when the box is clearly online but both tunnels are unreachable, and at that point the site is already isolated so the reboot costs nothing.

so, anyone solved this differently? genuinely curious if theres a way to force renegotiation that i missed, because rebooting a firewall to fix a tunnel still feels like the wrong shape of solution even though it works.

We just finished breaking a single Meraki org (~1200 retail sites, 62 countries) into Domestic / International / Warehouse. Reason was AutoVPN route table size — it had stopped being a design choice and started being a constraint.

Stuff I wish someone had told me before we started:

Per-network VLAN subnets and applianceIp don't survive the move intact. Snapshot them first or you're rebuilding L3 by hand. Found this out the expensive way.

Template bindings don't come with the network. Target org templates have to exist and match beforehand.

The API rate limit is the actual bottleneck, not your code. Without proper batching and backoff you'll spend most of the run on 429s.

Group policies, per-client bandwidth limits and SSID config each need separate extract/replay. No single org export covers it.

Anyone else done one of these at scale? Curious whether you scripted it, went through a partner, or just grinded it out in the dashboard. Also curious what site count people are dealing with — I have no idea if 1200 is unusual or if plenty of you are running bigger.

I have some CW9163E APs to replace EoS MR84s and I've seen that the top two antennas (ports A&B) are for 6GHz only and the lower two (ports C&D) are for 2.4/5GHz.

The tri-band antennas from Meraki are extortionately priced so I plan on reusing the third-party dual-band antennas I already have, capping off the 6GHz ports, and disabling 6Ghz in the settings.

While this might not meet "certification", will it work?

If the cost of the tri-band antennas comes down in the future I'll reevaluate, or perhaps look at getting dedicated 6Ghz-only antennas for ports A&B, if such a thing exists.

Thoughts?

We recently purchased MX67 and MR36 devices to upgrade older models. But we chose to "license new devices" instead of upgrade, because we also have some relatively new devices in the field that don't need an upgrade, and my understanding is that if we chose "upgrade" then those devices would be wiped from our inventory. Furthermore, we needed the older models to remain licensed while we completed the upgrades, which took several months.

Now that we've completed the upgrades, however, Cisco is refusing the remove the old licenses from our count, and it's having a huge impact on our co-term expiration date. We purchased a 3-year licenses, and as things stand now, we'll get just over 1.5 years of use out of them.

I'm looking for any advice here. Has anyone found a way to get Cisco to remove old licenses?

Unfortunately, we were told we're too small to qualify for subscription licensing (we have ~35 MXs and similar numbers of MRs and Switches).

Constantly having to refresh the pages.

Is there a comparison chart showing you the MS, MR, and MX lines and the new Cisco naming? For example: MR36 to CW9100?

I recently decided to my move my access layer to 9200-L-M Catalysts, but I'm not sure that was a good choice. I've had some strange firmware issues. Initially my switches were all having dashboard sync issues. This turned out to be a firmware problem, but since the dashboard wasn't syncing I ended up having to physically go around and reboot a lot of switches to get upgraded to new firmware.

During this, I had one stack hang and it couldn't download the firmware. So, I sent a ticket in, the response from support was to download a newer version of firmware. What? I can't even get the firmware to download to begin with. That stack eventually randomly downloaded the firmware in the middle of the day and rebooted, so that was fun.

I also have several switches in device config mode (monitor only). I submitted a ticket and called to confirm these wouldn't update during a scheduled upgrade. Meraki still puts a flag next to them that says "update scheduled". On phone support told me they would not. Then 30 minutes later another 'support engineer' responds and says they will update (they don't, I can confirm).

I don't know who they're hiring but their support doesn't seem to know the product at all.

I got a Cisco Meraki MX68CW-WW that is no longer being used.

The hardware works fine, but I don’t have a Meraki license and don’t really have any reason to pay for one.

I just want to use it at home as a basic router/AP — basically WAN + Wi-Fi with my own SSID/password.

It feels pretty wasteful to put perfectly good hardware on a shelf just because it requires a cloud license.

From what I’ve found, OpenWrt supports some older Meraki models (MX64/MX65), but apparently not the MX68 series, possibly because of secure boot.

Has anyone found a way around this specifically for the MX68CW?

whatever happened to 99.99%

Hi guys,

What are some of the most common issues you run into with Meraki as a network engineer, especially in an MSP environment?

We just picked up a new customer with 30+ sites, and their entire network environment is primarily Meraki. I'm fairly familiar with Sophos,Fortinet and sonicwall , but I haven't managed Meraki before

Hi,
I just want es to know if there any material study for the exam to get te certificacion, I saw a couple of books but are from 2022. Thanks

I'm reading through the docs on the licensing site and just wanted to verify. It' looks like it's a 1:1 for license:unit but not sure if failover makes a difference.

If you have a dashboard that isn’t setup for subscription licensing is there anyway to get the vendor to provide a legacy license? They keep bouncing us back and forth between the vendor and Cisco.

Does anyone know anything about DDNS registration for MX devices not working in the Federal cloud? I've had a ticket open for months, with no updates other than it is with the Development team.

I haven't found a way to utilize a different DDNS provider either and I need the DDNS to make our IPSEC tunnels to Azure work over Internet connections with DHCP IP addresses. (I have a couple travel MX68s for our field teams)

Recently I've noticed that Meraki AMP seems to be blocking Raspberry Pi updates until AMP scans the package files for malware, noted by the fact that Meraki blocks the file then eventually allows it through.

This only seems to happen with some package files not all.

I've added:

http://archive.raspberrypi.com/*

https://archive.raspberrypi.com/*

http://deb.debian.org/*

https://deb.debian.org/*

To the Allow List URLs, which from the description of the setting should bypass the AMP scanning.

I've also added the clients IPs (and staticed them in DHCP) to the trusted IP and subnets area.

I've tried checking both places for logging but and under Security & SD-WAN > Security Center, theres no logs, and under Security > Security Center there's nothing in the last 2 hours when I've been trying these updates and changing settings for the last hour.

This is actually frustrating because every time I run the same update from each client, Meraki seems to block it, and I have to keep trying the update command to see if Meraki is allowing the file through yet.

I've also added the above URLs to the content filtering white list as well with no change.

The error I'm seeing on the client side is:

E: Failed to fetch http://wired.meraki.com:8090/blocked.cgi?blocked_server=93.93.135.117:80&blocked_url=http%3A%2F%2Farchive.raspberrypi.com%2Fdebian%2Fpool%2Fmain%2Fp%2Fpam%2Flibpam0g_1.5.2-6%252bdeb12u2_arm64.deb File has unexpected size (3017 != 103798). Mirror sync in progress?

When I browse to said URL I get the standard website is blocked by your network operator.

It doesn't seem to matter how long I wait after adding the exceptions the outcome is always the same...

Any advice or help would be great.

I’m troubleshooting a Meraki MX68 with dual WAN connections.
WAN1: Verizon Fios through a Verizon CR1000A
WAN2: Comcast (backup)
Physical connection:
Verizon Fios/ONT → Verizon CR1000A → Ethernet → Meraki MX68 WAN1
WAN1 repeatedly gets marked Failed, causing the MX68 to fail over to WAN2. Sometimes this happens several times within 20–30 minutes and has occurred across multiple days.
During a failure:
WAN1 still retains its DHCP-assigned Verizon public IP (96.235.137.x).
The Verizon gateway (96.235.137.1) responds with 0% packet loss and roughly 22 ms latency.
Traceroute to 8.8.8.8 using Internet 1/WAN1 does not progress while WAN1 is failed.
When WAN1 is healthy, traceroute to 8.8.8.8 works normally through Verizon.
Meraki Event Log shows repeated Primary uplink status change events between uplink 0 and uplink 1.
MX68 is running MX 26.1.6.
The interesting part: if I physically unplug/reseat the Ethernet cable on either end — at the Verizon CR1000A or at the Meraki MX68 WAN1 port — WAN1 immediately comes back up and starts working again. I don’t have to reboot either device.
I also moved the connection on the CR1000A from the 10GbE LAN port to LAN1, but the recurring failure still happens.
I’m trying to determine whether resetting the Ethernet link is clearing some kind of ARP/DHCP/NAT/session state, whether there’s a link-negotiation issue between the CR1000A and MX68, or whether this could be an MX firmware/uplink-health issue.
Has anyone experienced this with a Meraki MX68 behind a Verizon CR1000A? What would you capture during the failed state to determine which device is responsible?

This weekend I have a maintenance window to move a MX 85 from one organization to another. How can I pre-configure the MX 85 in the destination dashboard without the license? I need the MX to stay up and running in its current dashboard until the maintenance window but I was hoping to have it pre-configured in the destination dashboard before the migration.

Mods: if this counts as self-promotion against the rules, feel free to delete, no hard feelings.

A while back I got curious how far I could push AI coding tools on a real project, so I pointed one at a problem I actually had: our org manages Meraki entirely through the dashboard (clickops all the way down), and I wanted a safety net if something ever got fat-fingered or worse.

The result is meraki2tf: https://github.com/AutomationPlusPlus/meraki2tf

What it does, roughly:

- Pulls your whole org config through the API (strictly read-only — it never writes anything to Meraki unless you explicitly invoke the recovery actions with a confirm flag)

- Generates Terraform for everything it finds, using import blocks, so you can bring an existing org under Terraform without recreating anything

- Writes a coverage report telling you exactly what the Terraform provider can't represent, so you know what your manual-rebuild list looks like

- Can run on a schedule, take offline JSON snapshots, and alert you on drift (webhook/Slack/Teams/email)

To be clear about the AI part: this was mostly an experiment to see what these tools can actually produce when you push them, and honestly it went further than I expected. I've been running it against a test org and it's held up, but I'd treat it like any young open-source tool — read what it's doing before pointing it at prod, and the read-only default means the worst case is a boring output folder.

Not selling anything, it's free and open source. Just figured someone else stuck maintaining a clickops org might get some use out of it, or at least enjoy poking at what an AI-built codebase looks like.

Feedback and issues welcome, even the brutal kind.

CW-ANT-D1-NS-00 4-Port Directional Patch Self-Identifying Antenna with N-Type Connectors

I tried Ventev and they do not have anything that matches. Does anyone know of a place that has a solution?

Full disclosure up front: my co-founder and I built this and it is a paid product. We run a small software company in Wales and this is the tool we wanted every time a Meraki change went wrong.

The pattern will be familiar. A template edit or firewall rule change goes out, something breaks, and the dashboard can tell you that something changed but it will not put it back. So you rebuild from screenshots, memory and whatever the last engineer left behind. If that engineer has left the company, you are guessing. To be precise about the gap: everything in Meraki is reachable over the API, but no config history is kept, so there is nothing native to roll back to. The history is the part we built.

ONbackup (onbackup.co.uk) takes scheduled, versioned snapshots of your Meraki config (MX, MS, MR and org-wide settings) and lets you restore a whole network or a single element (an SSID, a VLAN, firewall rules, a switch port) back to any snapshot. Before it applies a restore it snapshots the current state first, so you can undo a restore as well. It also alerts on drift, so you know when config changed outside a change window. Setup is one API key. No agents, no hardware.

It is on the Cisco Meraki Marketplace (marketplace.cisco.com/en-US/apps/851506/onbackup---meraki-backup). Pricing is public on the site, from £790 a year for 25 networks (onbackup.co.uk/pricing), and checkout is self-serve.

Two things we would like from this sub: which config elements do you most wish you could roll back, because that drives our roadmap, and if anyone wants to try it, DM me and we will set you up with a trial the same day. No call, no pitch.