Does anyone have a list of all the support-enabled features you can have enabled via a case with Meraki? Personally I have the following enabled:   2.4ghz-only SSIDs Disable MX flow_start and flow_stop syslog messages Firewall objects Inbound L3 firewall rules Disable wifi mesh   Some of these items caused me to spend many cycles trying to figure out what was wrong, or, how to do what I wanted. It'd be nice if there was a list of all the things support can enable for you so you don't end up spending time trying to figure it out. ... View more

Has anyone played with the no NAT functionality in MX 15? I'm playing with a few different topologies and currently I want to run without the MX doing NAT. The topology is:   Internet --- Firepower 1010 --- MX67 --- Clients   I want the Firepower 1010 to see the real IP addresses of the clients. The Firepower will also handle all NAT duties to/from the Internet. All my clients and services are behind the MX67, there's only a small /30 between the MX and the Firepower. Thus, I need to poke holes in the firewall of the MX to allow for incoming services to work. Previously, with NAT mode, I'd just configure the port forwarding rule on the Firewall page and everything works. However, once the NAT exceptions are enabled the port forwards don't work (as expected), thus I need to poke a hole in the Inbound firewall to allow the traffic to hit the relevant ports on the relevant IP addresses. However, there is no inbound firewall configuration options available. The only thing I see in the Dashboard are the regular outbound firewall rules. The only way I can get the inbound firewall rules to appear is by using passthrough mode, but that has other limitations I'd prefer to avoid.   Am I missing something basic? It seems like no NAT needs to expose inbound firewall rule configurations. Otherwise, it's impossible to host any services behind the MX. ... View more

I'm just starting to play around with the API. My user has full access to the org and also the network I'm playing with. I'm just tinkering for now making API requests via curl on the command line of my Mac. If I make the request against "api.meraki.com" I get a 404 and no data is returned. If I change it to the shard I'm on "n###.meraki.com" I get a 200 OK and the data I'm expecting. So, from this I assume my API key is valid. Why doesn't the request work on api.meraki.com, but does when I point it at the specific shard?   Works:   curl -X GET \ --url 'https://n456.meraki.com/api/v0/organizations' \ -H 'X-Cisco-Meraki-API-Key: foo'\ -H 'Accept: application/json'     Doesn't work:   curl -v -X GET \ --url 'https://api.meraki.com/api/v0/organizations' \ -H 'X-Cisco-Meraki-API-Key: foo'\ -H 'Accept: application/json'     ... View more

MR access points are supposed to use proxy-arp to respond to ARP requests on behalf of connected clients. However, I've noticed that my MR42s are NOT proxy-arp responding to ARP requests from my MX67. Specifically, an ARP requests from the MX67 are forwarded to the end client, needlessly wasting airtime. Given that the MX67 ARPs for all connected clients every 15 seconds this is generating a lot of ARP requests over the air. Is anyone else seeing the same thing? There's basically two scenarios:   Scenario 1: MX sends client-status ARP request for a host connected behind MR42. The MR42 receives this ARP request and forwards it to the end client in question. The client responds and the MR forwards this response to the MX. This is wasting airtime.   Scenario 2: Another host on the network sends an ARP request for the same host connected behind MR42. The MR42 receives this ARP request and immediately responds (proxy-arp) without forwarding it to the end client, as expected. This saves airtime.   My MX is on 14.50. The MR42 is on 26.7. This happens with numerous clients and doesn't appear to be client-specific. Running Wireshark on a 2018 Macbook Pro 15'' shows the ARP requests from the MX, but no ARP requests from any other devices. Interestingly, this only happens on ARP requests from the MX. If I swap the MX for my Cisco Firepower1010, configured with the same LAN IPs, etc, the MR correctly sends proxy-arp responses. ... View more

I was hoping I could get some input into what I might loose from a traffic analytics perspective if I remove the MX from my full stack environment. Right now I have an MX67, several MS120-8 switches, and a few MR42 APs. I'm considering dumping the MX67 for a Firepower1010 for the increased performance and IPv6 capabilities. If I remove the MX67, will I be missing out on some traffic analytics? Or, will the MS and MRs fill in the gaps? ... View more