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.
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.
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.
Hi everyone,
I’m troubleshooting an authentication issue with Cisco routers/switches using \*\*Microsoft NPS as the RADIUS server\*\*.
\*\*Environment:\*\*
Cisco routers/switches
RADIUS authentication
Microsoft NPS
Trying to authenticate using an AD account
RADIUS communication appears to be working between the Cisco device and NPS
User credentials have been verified and are correct
\*\*Issue:\*\*
When I try to perform an administrative login to the Cisco router/switch using RADIUS/NPS, authentication fails with \*\*NPS Reason Code 66\*\*.
The same issue occurs on multiple Cisco devices.
I have already checked:
AD username/password
RADIUS server configuration
RADIUS shared secret
Cisco aaa configuration
NPS Network Policy
NPS connection request policy
Connectivity between the Cisco device and NPS
RADIUS ports
I’m still getting the authentication rejection.
\*\*Cisco configuration is roughly:\*\*
aaa new-model
aaa authentication login default group radius local
aaa authorization exec default group radius local
radius server NPS
address ipv4 <NPS-IP> auth-port 1812 acct-port 1813
key <shared-secret>
NPS is receiving the authentication request, but it is rejecting it with \*\*Reason Code 66\*\*.
Does anyone know what specifically causes \*\*NPS Reason Code 66\*\* when authenticating Cisco IOS/IOS-XE devices against Microsoft NPS?
What should I check next — NPS Network Policy conditions, authentication method (PAP/CHAP/MS-CHAPv2), AD permissions, or something specific on the Cisco side?
Any troubleshooting steps or examples would be appreciated.
Thanks!
Hey everyone,
We are currently in the process of replacing 12 end-of-support MX65/W devices with 12 new MX68s. Along with the MX68 hardware, we purchased 3-year MX68 licenses.
Our org uses the Co-Termination (Co-Term) licensing model. When we added the new 3-year MX68 licenses to the dashboard, our org-wide co-term expiration date pushed out by about 6 months.
Here is the dilemma: Once we decommission and unplug the 12 old MX65s, our active device count drops, but our License Limit for the MX65 tier remains unchanged in the co-term pool. Because co-term calculates burn rate based on total entitlements rather than active hardware, those 12 unused MX65 seats will sit in our pool as "phantom" licenses, artificially inflating our daily burn rate until the whole org expires.
Essentially, we’re burning pool value on legacy hardware sitting in e-waste.
Questions I'm hoping someone can provide some guidance on:
Appreciate any advice or experiences from anyone who has navigated this recently!
I just started replacing my access switches with 9200-L-M's. Everything has been working well for the last month or so. Recently I've had several switches go into a warning with 'Configuration Out of Date' displayed on them. When this happens some of the functions work on the dashboard and some do not. I've been able to run the CLI in the GUI but some commands time out etc. I couldn't even reboot two of the switches remotely. I physically rebooted a couple and the warning went away. Today I had another switch just start doing this.
Suffice to say this is not going to work going forward. I can't go physically reboot these all the time to fix this issue.
Has anyone else run into this? I'm not sure what would cause this to happen intermittently. At first I though maybe something was getting blocked at my firewall but everything appears to be going through ok.
I had to fight with those types of failures for the last few days. Anyone else? My clients are all on Win 11 Pro and using built-in clients. I’m seeing lots of x.x.x.x sent termination request (Peer not responding) – Meraki log and error code 789 in Windows event logs, ID 20227. Those clients all sync Meraki to AD so affected users’ credentials coming from an AD.
To my surprise, nothing helped by physical troubleshooting on the user’s end and most of those cases were resolved by themselves.
I have a Meraki site currently showing a “Disabled gateway” alert, but the MX/firewall is green in Dashboard and all of the switches are also showing green.
What exactly happens when Meraki reports a disabled gateway? Does this mean clients at the site would be unable to reach the Internet, or can Internet connectivity still work while this alert is present?
Just trying to understand what Meraki is actually testing/detecting when it marks a gateway as disabled and what impact I should expect for users.
Anyone else have issues with Radius not working after upgrading MR 31.1.x to MR32.2.4?
Thanks!
Hey folks,
I'm looking for some insight on an issue we're troubleshooting.
We have a stack of five MS150 switches connected to an MS225 core switch. On a random day at around 3:03 PM, the entire stack went down and lost communication with the core.
The odd part is that the core switch reported a Layer 1 UDLD error, indicating the fiber could transmit but not receive data. We checked the fiber and SFPs, and everything appeared to be fine. We're using Cisco SFP+ modules.
On July 18, we upgraded the stack to MS18.1.8. The incident occurred on the 29 july, we collected the console logs and sent them to support. So far, the only explanation we've received is that there may have been a synchronization issue within the switch stack.
We also performed a remote reboot of the stack, which reproduced the same issue. We collected another set of logs and provided those as well. Support has since suggested waiting for a newer firmware release, but we haven't received a definitive root cause.
Has anyone experienced something similar with an MS150 stack or MS225 core? Any recommendations on what else to check?
For reference:
No switching loops detected.
We do see some MAC flapping, but it's related to APs and wireless client roaming, and nothing that should bring down an entire switch stack.
Fiber and transceivers appear healthy on inspection.
I'd appreciate any suggestions or ideas on what to investigate next.