Meraki

Brash

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

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

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

Brash

Yes, as @alemabrahao stated, it's certainly possible to port forward to another device in your network. As with anything, it's best to try to lock down any port forwards to only allow traffic from specific public IP addresses.

Brash

Default everywhere. A bit over 'over-spec', good design and getting rid of traditional VOIP goes a long way to making everyone's life just a little easier 😆

Brash

For windows update, I'd suggest using other measures to manage distribution and load. Eg. - Use update rings or update windows - Use a local update server or built in delivery optimization That said, to answer your question, you can't achieve exactly what you're after. You can apply traffic shaping rules targeting your clients (using group policies) and applying to Windows update traffic, however you can only set CoS or QoS lablels. You cannot use it to set WAN priority (essentially upstream bandwidth allocation) Otherwise you can use traffic shaping rules to set the WAN priority but you cannot split this out per application. I highly recommend looking at the Meraki docs on Traffic Shaping, CoS, QoS and priority. There's also a bit of a summary in this post: Re: Prioritizing Traffic within Meraki Full Stack - The Meraki Community

Brash

L3 firewall rules are what you need to setup. You will want to deny rules for your WiFi clients to prevent them communicating with your other clients. You can apply these rules on the MX, or on the MR SSID. Where you apply these will change how clients can talk to each other. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Using_Layer_3_Firewall_Rules One thing to note is that L3 rules on the MX don't impact site to site VPN destined traffic. You would instead need to use site to site VPN firewall rules https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Firewall_Rule_Behavior

Brash · Re: New MX 19.1.11 stable firmware: stability fixes for MX75 & MX85 and IPS...

I don't know whether it's on purpose or not, but I love the tracking numbers against the issues! Also this one is notable: Bug fixes - limited platform fixes Stability improvements for MX75 and MX85 appliances. (MX-34321)

Brash

Adding to what's been said above, while it's added to someone else's Meraki network, you cannot add it to your own. Your options are: - Have you friend recover their account and release the device - Have the service provider release the device

Brash

As stated above, typically this info isn't shared publicly as releases can end up being delayed for a variety of reasons. However, I suggest checking with your account manager if it's a specific feature you're waiting for. They can often give a rough framing of when it may be released.

Brash

My understanding from the doc is that this sets the source interface for the cloud communication: To resolve DNS names and communicate with the Meraki Dashboard, the Catalyst switch will need the following configuration. "internet bound" vlan configured as http client source-interface https://documentation.meraki.com/MS/Cloud_Management_with_IOS_XE/Migration_from_CLI-managed_Catalyst_Switches_to_Meraki-managed_Mode#Step_2:_Initiate_Registration_with_the_Cloud That said, I haven't tested it myself so I can't say 100%.

Brash

Circling back on this one, I worked with the US support team (shoutout to Caleb) who helped confirm the following. As @RWelch pointed out, Catalyst switches do have the caveat about IGMP snooping also enabling querier functionality. This I had read but figured wasn't applicable as I didn't have any L3 interfaces on the C9300. As it turned out the management IP address of the C9300 is applicable, and because it was a lower IP address than that of the SVI on the MS225 stack (even though it's a different VLAN), the C9300 Mgmt IP won the IGMP querier election. We resolved this by creating an SVI on the C9300 (in the VLAN that the multicast traffic is coming from), enabling IGMP querier on it but setting its IP address high than that of the SVI on the MS225. After setting that and waiting for the IGMP querier election to occur (260 seconds?) the MS225 SVI won and took over as querier and multicast stopped being sent up to the C9300.

Brash

As said above, the most likely cause is cabling If you've got a long cable run or are going through a patch, try connecting the WAP directly to the switch with a short patch cable and see what the speed shows as. I've also seen this occur on a couple of AP's before they've eventually failed (MR45's for reference).

Brash · ‎Sep 2 2025

You shouldn't need bonjour forwarding if the devices are on the same L2 network. Have you got any firewall settings on the SSID blocking local connections or block local LAN? It's likely the windows laptop works because it's using Miracast which is a "Wi-Fi Direct" technology and doesn't require both devices on the same network.

Brash · ‎Sep 2 2025

Make sure your firmware is up to date and regulatory settings are correct. If it's still missing after that, contact support who can follow it up internally.

Brash · ‎Sep 2 2025

As has been said above, don't use WEP. Definitely switch to WPA. Other than that, check rate limiting on the SSID, and on any upstream, equipment. If you've got a Meraki full stack environment, I suggest engaging support to check for configuration which may impact the performance.

Brash · ‎Aug 26 2025

There's no way to remove certain data from the page but as said above, you can disable the local status page.

Brash · ‎Aug 21 2025

Happy birthday to the community and a big milestone. Thanks to all of the contributors and team who run the community!

Brash · ‎Aug 20 2025

Also, the MS150 looks and feels nicer... so there's that too... 😉

Brash · ‎Aug 20 2025

@jasonm2025 I feel your pain. We purchased some MX75's not long after release for some of our most critical sites. We've had multiple panics/reboots and have RMA'd 4 units. The latest recommendation was to upgrade to the 19.1.x train but I hadn't been able to as it hadn't been under stable release. Frustratingly, a 3-5 minute downtime for the site while the MX crashes and reboots is less risky than the possibility of introducing further issues by moving away from the stable release train. Now that 19.1.x is the stable release, we'll be upgrading very soon and hopefully should see some stability. That said, whilst frustrating, I'll take a crash/reboot any day over some of the other issues I've been dealing with on some other products from other vendors.

Brash · ‎Aug 19 2025

I have 30 odd sites with MS225's now upgraded to 17.2.2 and so far, so good. I'm guessing (and hopeful) that they are niche issues that requires some specific circumstances to hit.

Brash · ‎Aug 19 2025

I honestly kind of wish the industry as a whole would get rid of L2TP client VPN. It seems to be this half-supported technology that some companies have phased out and others have left but don't really pay too much attention to. ^ Not just speaking of Meraki on this on - I'm finding other vendors have unofficially given up on it.

Brash · ‎Aug 19 2025

The behaviour you're seeing certainly isn't expected if you're physically removing the WAN 1 cable. It should failover very quickly (usually 1-2 ping drops). I have this setup at many sites, and it works relatively flawlessly. Given the responses above, it sounds like you've done quite a bit of testing already. I suggest opening a support case.

Brash · ‎Aug 19 2025

All of the above is correct. One additional note of clarification. The "Routing & DHCP" page is used for creating Layer 3 interfaces on your switch (SVI's). If you're looking to create a VLAN interface (in traditional Cisco speak), you would use this page and click "Add Interface".

Brash · ‎Aug 13 2025

As said above, there's a separate section for site-to-site vpn rules that can be used to block spoke to spoke communication.

About Brash

Brash

Community Record

Badges