@Adam There's a drop down on the IPv4 ACL page that let's you change it to IPv6. It looks like this (taken from a 10.14 network):     @Deviant that sounds like bad behavior to me... I'd open a case and get Meraki to explain it. ... View more

@PhilipDAth That's not true at all. heiki's example above shows exactly how that can happen. ... View more

In my experience, @Uberseehandel 's first bullet point:   a 40 MHz wide channel is twice as likely to suffer from interference as a 20 MHz wide channel. The larger channel occupies twice as much of the available spectrum, so twice as likely to suffer from interference. Is your single biggest issue with wider channels. You have to realize that your physical layer, RF spectrum, acts like a hub with clients operating in half-duplex mode. By narrowing your channels you make their communication more efficient and precise with regards to RF spectrum utilization.    I think this is reinforced with the upcoming features being included in 802.11ax with OFDMA that will allow for channels smaller than 20MHz so that more clients can get onto the network at once, more reliably.    Remember, faster wifi doesn't equal better wifi 😉 ... View more

@PhilipDAth Crap. Good point.   I see the easiest way out here (in the topology I put forward) to simply stack the distribution switches. However, between here and Reddit I've read too many stacking horror stories to comfortably move forward with that option...   Unfortunately, there's real problems with the dual attached option as well, as illustrated by @heiki in this thread. If you ever have a failure such that traffic must pass though a Standby MX to reach the Master MX that traffic is dead in the water.          ... View more

 @heiki There's another way you can manipulate this...  When there's a failure, if you were to swap port 25 and 26 on the Root Bridge, then things would start working again. By swapping the ports you are forcing the disconnected switch to break the tie for it's root port in favour of the path through the secondary, and now active, MX. I realize this is likely not useful at all...  But I noticed this in my testing so I thought I'd mention it to you as a last resort to get things working if there was an outage.    @PhilipDAth I am not a fan of a topology where multiple switches uplink to both MX's. I think that introduces the potential for STP to become unstable with a topology that has a mesh of neighbours connected over PtP interfaces.  I get the sense that's one of those things that would work fine... Until it doesn't. Just my thoughts though.   ... View more

@heiki I'd forgotten about this thread! Oddly enough, I've also been revisiting the topic of MS-MX Internet Edge this week and I have a discovery that I think might be related here.   I have observed that when an MX is in standby mode it WILL NOT forward frames that have the destination MAC address set to the address of the VRRP virtual router.This effectively black holes all traffic that is sent to the default gateway.   All other traffic seems to forward normally. You should be able to ping both switches, and the other clients from your client that cannot reach the Internet. At least I could in my testing. If you can't I'd be interested to know that.    Side Note: Meraki does not follow the RFC and uses the physical MAC address of the Primary MX as the MAC address of the virtual router. This means that when the Standby MX becomes Master it responds to the physical MAC of the Primary MX. You can observe this on the clients in the ARP table as the MAC for the GW will be the MAC of the Primary MX, and will not change when you initiate a failover.    **Edit** Meraki actually uses a Meraki OUI based virtual MAC that both MX share.   So, where does this leave us?  Well for me I'm going to change the way I connect this stuff up such that there is never a path to the Active MX that is through the Standby MX. This will eliminate the black holing of traffic that occurs when traffic has to go through the Standby MX. I think that this topology is our best bet going forward:     I will likely open a case on this too since this is incorrect behavior. I'm less concerned about the improper VRRP operation than I am about the Standby MX not forwarding traffic for one specific MAC address. You can't run VRRP with another device anyway so it's not that big a deal that Meraki has played fast and loose with the RFC (there's other things they didn't follow as well). ... View more

I know this isn't the easiest way for everyone, but location can be updated via API. That's really your best option to update en masse. ... View more

@DeannaS Thanks for checking!  I could use a different email address, but it won't be the same as the one I use here. Does that matter? ... View more

@Adam On the "Access control" page the settings only apply to the SSID you have selected in the dropdown. ... View more

Yup, you got it. That's exactly right. ... View more

Let's say you have an SSID called "DunJer's Radical Wifi". Under Wireless --> Configure --> Access Control you then configure that SSID to bridge to VLAN 1 (for example). Next, create a Group Policy under "Network-wide --> Configure --> Group policies" and set up the Content Filtering the way you like. Now on the MX you go to "Security appliance --> Configure --> Addressing & VLANS" and in the Routes section for the VLAN you add the GP to that VLAN.     If you do it this way you bridge each SSID into a different VLAN, and you apply a unique GP to each VLAN giving you the ability to apply policies to each group of users. Every user who connects to "Dunjer's Radical WiFi" is placed into VLAN 1 and will be subject to the content filtering for that VLAN.   Does that help?  ... View more

@PhilipDAth Son of a... I can't believe I've never thought of that. In all the years that I've had to deal with my workplace ALWAYS using the apostrophe in my last name in my email address...    Bad news though here. The form still doesn't take it. Great suggestion though! ... View more

You can do this using Group Policies. Content Filtering rules can be set in a group policy, and you can then apply the GP to the MX VLAN. Naturally, you'll need to have your SSID's in bridge mode set to the appropriate VLAN so the SSID hits the desired GP.      ... View more

Hello,   Please fix your form. It rejects my email address as it has an apostrophe in it. 😞 ... View more

@3ffdot Nothing changes with regards to IP configuration. So you can configure an IP on the WAN port, but for the LAN you still have to set it on the VLAN and then configure your LAN ports as access or trunk accordingly.   To use non-Meraki terminology, I haven't seen a way to configure a LAN port as a routed port. They can only be switchports that you can assign to a VLAN and route via an SVI. ... View more

No, I have two addresses on my No-NAT MX. You still configure the WAN port the way you always would by either leaving it as DHCP no VLAN tagging, or use the local status page to set up a static IP and VLAN tags. From there the "Addressing & VLANS" page you can set up the LAN side of the device. Add your VLANs, configure your ports, and add any needed static routes.    The only difference here now is traffic isn't NAT'd.  ... View more

Does this help?     And then on the MX I have that is doing NAT I have a static route pointing to the No-NAT MX to get reachability to the subnet behind the No-NAT MX.    That's it.  ... View more

@3ffdot I called Meraki and asked them to join the beta. They then set my chosen network to version 15.3 and enabled the feature on that network.      ... View more

Hah! I ask, on what seems like a daily basis, many of those same questions. My comments weren't meant to tell you what to do, they were simply some philosophical design musings. 🙂 ... View more

I have tested this very briefly in my lab and it seems to work well. It does what it advertises and turns the MX into a simple router. I haven't done much comprehensive testing but it does look promising.    If you do have the MX behind another router then this will avoid a double NAT situation (this is actually the topology I have it my lab that I tested with: Inet---MX---MS---NoNAT MX---MS---Client).   IMO if you have a requirement for the features that you listed @Uberseehandel then I would think you should be looking for a solution that has those features as opposed to stacking multiple hardware platforms that each handle parts of your requirements. But of course, YMMV and sometimes we are forced to do things we don't want to do...      ... View more

Just a thought: You can't use AutoVPN between organizations... If you do two Orgs then you have to use non-meraki VPN, and you lose your SD-WAN functionality. ... View more

Haha!  That's kinda funny. Logs full of blocked porn sites from your workstation... I understand why you wouldn't want that history in there. Though it might be fun explaining to the CIO that it was "For Science!" 😉   If this is really a problem then I'd suggest cloning a new network based on your current settings, move the MX over there, do the testing, then move it back and delete the network. Event logs are network specific so if you do your testing in a dummy network that's been deleted there will be no trace of them going forward. ... View more

Generally speaking you want to mark traffic as close to the source as possible. So ideally you have the VoIP device mark it's own traffic, and then you "trust" those markings throughout your network. Failing that, you mark traffic on the ingress switch port the VoIP device is connected to (in your case, your non-Meraki switches).   I'm not clear if you can mark LAN to LAN traffic on an MX using a Traffic Shaping rule. Perhaps someone else can chime in on that part?  If you can you'll find it under Security appliance --> configure --> Traffic shaping and go right to the bottom of the page for traffic shaping rules. Might be easiest to use a layer 7 classification for voice, and then mark it to EF.      ... View more