@PhilipDAth You can also get a 404 for things like a bad key.    https://documentation.meraki.com/zGeneral_Administration/Other_Topics/The_Cisco_Meraki_Dashboard_API#API_Requests   ... View more

You won't be able to forward ESP. I suppose you could try a 1:1 NAT and set the forward rule to ANY... But I haven't tried this so I don't know if it would work, and you're effectively opening the whole box to the Internet, which isn't a great idea really.     Bascially you're going to have ensure you have NAT-T enabled on your VPN links. You won't be able to do this without NAT-T. ... View more

@RCaldicott interesting... I wonder if the PS4's do something silly like store the BSSID of the wireless network they connect to, and then only connect to that BSSID? If that were true then swapping out AP's would certainly give them issues. I don't have a PS4 to test on, but perhaps just deleting the saved wireless network, and then re-adding it would fix it? ... View more

Can you post the exact code you're using? It's hard to diagnose when we don't know exactly what you're sending (redact api keys naturally).   Aslo, this module might make your life easier:   https://github.com/meraki/dashboard-api-python     ... View more

Doesn't exist.   You can either manually pull a csv, one page at a time... Or set up Syslog to export logging to an external server (under Network-wide > General). ... View more

@DeziB75 wrote:   2. Turn of RTP/SRTP. (My consideration is that otherwise the new switches will interfere?) Never this. Disabling STP because you don't understand it is absolutely the wrong move 100% of the time. When it comes to STP the right answer is to understand it, and set things up so they function properly.   If you have unmanaged switches then they will not be running STP today, so there's nothing to "interfere" with. Moreover, all versions of STP can interoperate with each other, so that's still not a concern provided they are set up properly.  Meraki implements Rapid-STP which is the 802.1w standard. There's tons fo good resources on the web for it. You really should consider giving one a read through.   ... View more

https://community.meraki.com/t5/Off-the-Stack/Meraki-Masters-how-can-I-earn-an-invitation/td-p/601   "Top resellers" ... View more

@Darrell Not exactly. It can use multiple IP's for inbound traffic. So you can do DNAT on inbound traffic. What you cannot do is SNAT on outbound traffic.  ... View more

You can clone an Org through the API, so that would be the best way to script it.    https://n231.meraki.com/32673011-Portage/n/iDF-XdNd/manage/support/api_docs#create-a-new-organization-by-cloning-the-addressed-organization     ... View more

I would configure all the VLANs and subnets on the MX, and then just use the MS225 at layer 2. There's no reason to go into Switch > Rounting & DHCP at all.    Configure just the ports on the switch to be access in whatever VLAN they need to be for the clients, and configure a trunk to go to the MX. Also configure a trunk on the MX port that connects to the switch. ... View more

Right, so in the case of VPN to Non-Meraki you can only do "Non-Meraki" VPN. That's not PtMP, and it only supports basic IPsec "stuff". There's no DMVPN or GETVPN or anything else of the sorts.  ... View more

Interesting... I suspect that AutoVPN is not actually a multipoint tunnel on a given hub, but there's actually no way to know for sure, and it behaves like it is so it's questionable if it really matters. ... View more

I got mine today too! I didn't realize the MotM's got stuff. I never read that thread before... That was a pleasant surprise this morning 🙂   Thanks as well to everyone who kudo'd and solutioned my posts! And thanks to @CarolineS for all the work on the forums!  ... View more

https://documentation.meraki.com/MS/Monitoring_and_Reporting/Switch_Port_View     ... View more

That is correct. The uplink port has nothing to so with anything STP whatsoever. ... View more

The uplink port is the port the switch is using to talk to the Meraki cloud. It has nothing to do with up- or down-link within your LAN. ... View more

Haha! Three different people, three different answers. At least two of us are wrong... If not all three 😞 ... View more

I think this actually is detrimental to your network. You are creating a "shortcut" path that is not representative of the path your clients will use. This dedicated VLAN heartbeat cable leaves you wide open to the scenario where your clients lose connectivity to the active MX, but the active MX does not relinquish control to the secondary thereby taking your entire network down. You want VRRP to move over the path your clients actually use.  ... View more

Because the MX NAT's all traffic moving from WAN to LAN this setup will not work. You will break state on your flows as return traffic will appear to come from a different address than what the source was sending to.    As Adam said, you could do this on the LAN side easily enough, but then you have to worry about how does the MX talk to the cloud.   I find this ask very curious. What use case do you have where this is required?  ... View more

That page was not updated due to an oversight I believe. They are aware now that it is outstanding and hopefully it'll get changed soon.   In my experience the issues caused by creating the loop at L2 on devices that do not participate in STP are far more detrimental than having VRRP frames pass through one switch between MXes. I would agree that you don't want your VRRP to take the scenic route through your switch fabric to get to the other MX. But if you have problems getting VRRP through a single switch before the dead timer expires then you really have much bigger problems that you need to be looking at.     ... View more

Very cool. I can see this being quite useful. Nice work! ... View more