Meraki

Brash · ‎Jan 7 2026

That's super interesting. I had no idea about either of these 2 gotchas. Good to know!

Brash · ‎Jan 7 2026

Great job everyone! So many fantastic contributions to round out 2025.

Brash · ‎Jan 2 2026

The error messages for Windows built in VPN are usually pretty generic. Ensure that your VPN configuration is set as per the Meraki documentation: https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Configuration_Guides/Client_VPN/Client_VPN_OS_Configuration#Windows In particular, verify that PAP is enabled and the credentials are correct. If this is a new deployment, I'd suggest looking at migrating to AnyConnect/Secure Client VPN which is a superior product and still integrates directly with the Meraki MX

Brash · ‎Jan 2 2026

The information you've provided is enough to point to the ISP as the problem. To provide evidence, you can collect packet captures on the WAN interface to show the latency, retransmits etc. Just ensure you test to multiple Internet endpoints (which are not aggressive in traffic policing) to prove it's not related to a single destination. I've done this before to force an ISP to investigate further to which they eventually found the issue on their side.

Brash · ‎Dec 18 2025

As @Mloraditch said, the more specific policies override the more general ones

Brash · ‎Dec 18 2025

Congratulations to the winners! 🙂🎉

Brash · ‎Dec 4 2025

Great job all! Congratulations to everyone who has contributed this month

Brash · ‎Nov 20 2025

Oh, understood. No, I was not.

Brash · ‎Nov 20 2025

Force refreshing browser wasn't working and the option the change back to the old page wasn't loading 🙁 Thankfully the app was still working. The switches I was looking at were MS125's running 17.2.x firmware. But other non-template networks with the same switches and firmware weren't seeing an issue.

Brash · ‎Nov 20 2025

This is resolved for me this morning. A little disappointed that there was nothing on the status page while the issue was occurring.

Brash · ‎Nov 19 2025

Unsure whether this is just an issue on my shard or across the board but I'm finding that when I click on a switch, I just get a blank page. It seems to be only in networks that are bound to a template. Is anyone else seeing this issue? Shard n1096 for reference.

Brash · ‎Nov 19 2025

This comment is triggering 😅

Brash · ‎Nov 16 2025

Interesting. I'm yet to rollover my cloud monitored switches to 'cloud management - device configuration' but given the steps for transition involves a cloud managed upgrade to 17.15.3+ (see link below), I assumed that the feature was available post transition too. Upgrading Cloud-Monitored Switches to Cloud Management with Device Configuration - Cisco Meraki Documentation

Brash · ‎Nov 13 2025

Correct. It starts being consumed from the day you receive the license key via email, not the day you claim the license into the dashboard.

Brash · ‎Nov 13 2025

For Meraki licenses, they are active from the date at which they are processed. If you received an email with the license, then it is already active from that date. When does a license start to burn (start ticking)? Licenses in the Co-Termination model start consuming time from the date it was processed, not the date they are added to an organization. Waiting to activate a license in a Co-Term dashboard does not delay its activation date. There is no time benefit gained from delaying an activation. https://documentation.meraki.com/Platform_Management/Product_Information/Licensing/Meraki_Licensing_FAQs#Co-Termination_Licensing_FAQs

Brash · ‎Nov 13 2025

Interesting. I thought routed ports were on the road map for Catalyst switches with Meraki managed configuration. I wonder if it actually works on other platforms or has just been enabled for everyone in the GUI.

Brash · ‎Nov 13 2025

I would start by looking at the "Wireless -> Health" and "Assurance" tabs in the dashboard Start high level and dig down into any problems you see there. As @alemabrahao suggested above, opening a support case may also be the better option if you don't have much experience in the dashboard.

Brash · ‎Nov 13 2025

With Meraki, you can use site-to-site NAT translation. It would need to be enabled by support on your organization. https://documentation.meraki.com/MX/Design_and_Configure/Configuration_Guides/Site-to-site_VPN/Using_Site-to-site_VPN_Translation I imagine most vendors would implement something similar for overlapping subnets

Brash · ‎Nov 11 2025

@GIdenJoe 's post is pretty much spot on. IGMP if all in an L2 domain and PIM-SM for multicast that has to move across an L3 domain. Personally, I'd suggest: - Separating all of your multicast equipment onto a separate VLAN('s) from other devices in the network - Adding in a Catalyst 9300 in Meraki configuration mode (assuming that meets your other requirements) and connecting all of your multicast equipment to that. You can then set the IGMP querier on this device thereby limiting the traffic heading up to the MX. The guides @PhilipDAth provided do a very good job at describing Multicast configuration and best practices within the Meraki environment.

Brash · ‎Nov 8 2025

From what you've described, it definitely sounds like a server side firewall or port binding issue.

Brash · ‎Oct 31 2025

As well as the above, you can contact support who can uplift the license type to advanced security at the cost of some of its duration. Eg. They can uplift a 3 year enterprise to advanced but it will be cut down to less than 3 years.

Brash · ‎Oct 16 2025

Chances are that vMX's haven't been added to the new feature yet. I would say the EOL documentation (linked in posts above) will remain the source of truth until/unless it's fully replaced by the dashboard feature

Brash · ‎Sep 26 2025

A bit of a painful situation. I had the same thought as @Ryan_Miles - using the API to create temp networks to assign the MX's too will save a bunch of time. One other thing is you may want to setup a different org to do it in? I'm not sure how many networks an organization can handle before it starts grinding in the dashboard, and you probably don't want to impact the management of your prod networks.

Brash · ‎Sep 25 2025

The weirdest thing about reading this is that devices are showing with APIPA addresses. Even in the event of traffic drops etc, I'd expect devices to keep their DHCP'd IP address. This symptom seems to indicate to me that either: - The link to the client is disconnecting and reconnecting forcing it to request a new IP. - Clients are sending DHCP renews that are not being acknowledged by the DHCP server. The unplugging and plugging of the network cable then triggers a new DHCP request which the server responds to. If the issue is reproducible, does it occur for clients with static up addresses? Additionally what device is the DHCP server in this scenario? Do you see anything in the logs on the DHCP server?

Brash · ‎Sep 21 2025

No, this is not available in the dashboard via GUI or API. If this is a requirement, you might need to investigate 3rd party options to integrate into the guest access workflow

About Brash

Brash

Community Record

Badges