Ooooh! Sorry, I think I misunderstood.    You have LTE connected to WAN1?  So you have an LTE router of some kind? Not a USB modem?   If you're using an LTE router/modem connected via Ethernet to WAN1 then you can't do what you want. Sorry 😞 ... View more

On the firewall page there's a section for LTE specific rules that only apply when the MX is on cell. You can block your guest networks from using the LTE there. ... View more

I got mine too. Thanks @CarolineS! ... View more

I have run into SFP's that don't work (I'm looking at you Alcatel 1Gbase-T SFPs), but for the most part they work just fine. ... View more

I'm with @MacuserJim on this one. AMP has had weird behavior on older versions, but up in Wired14 it seems to be much better. I would assume if you're talked to support they would have suggested you move to Wired14 if you haven't already done so... ... View more

@CameronMoody Great post! Thank you very much for the clarification.   @CameronMoody wrote:   The design on willette.works is not an official Meraki design and is not recommended.     I'm also very glad to see that. I'm not a fan of that configuration at all.  ... View more

Yeh that's a nasty little gotcha. I hadn't seen that mentioned anywhere else yet. Good to know. ... View more

OK, so the documentation is correct in that you cannot take an AP directly out of the box and convert it to survey mode. I just tried that and it I cannot get to the local status page at all.   https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Conducting_Site_Surveys_with_MR_Access_Points#Configuring_a_Survey_SSID   I can see a way around this possibly as Meraki will give you a 30 day grace period for licensing... So if you add a new AP to a network, ensure it's all connected to the dashboard and all, you'll then have 30 days to convert it to survey mode before it goes offline. Once it's in survey mode it should continue to operate as long as you leave it in survey mode.   But, that's just a guess.  ... View more

Call support.    if this box has done this then personally I'd never trust it again and would want it RMA'd. I wouldn't be interested in any hackey fix that may or may not actually solve whatever the real problem is.  ... View more

@RandyM wrote: While certainly the dashboard ought to expose the LLDP/CDP data, you can get at it via API.   https://dashboard.meraki.com/api_docs#list-lldp-and-cdp-information-for-a-device Does that work on MXes? I always assumed it didn't... I guess I should have tried. ... View more

I have no idea why Meraki does a lot of the things the way they do them 😉   I suspect this has a history somewhere in the evolution of networks in that originally there were no "combined" networks and each device type was standalone. When they created combined networks stuff like the clients page had to show some point of view...  And indeed some of it shows all points of view simultaneously (like the traffic graph).     ... View more

In the Site-to-site VPN settings, is the Client VPN subnet set to Yes for "Use VPN"?   ... View more

There is no way to see this on an MX.   Please click the actual "Make a wish" button, these forums are not a substitute replacement for that. This one, along with other basic port level statistics, are something I would like to see.  ... View more

Nope, no impact. ... View more

Yup, this should work. If you have multiple routes to the same destination they are used in the following order:   https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior#Route_Priority   So in your case a static that routes traffic over the VPN will take precedence over the non-meraki VPN learned route. The last point to make here is that you should use the "Active" field in the MPLS static route so the route is withdrawn when connectivity to the next hop fails. This will help detect a failure in the MPLS cloud (as opposed to a direct loss of link on the interface) and fail the traffic to the non-Meraki VPN properly. ... View more

^^  What he said 🙂 ... View more

Try swapping the fibres around. ... View more

Yeh classic case of finance not understanding IT and making a poor, one-sided decision 😞   You could add NAT rules, to pass traffic through, but that's a huge pain in the ass to do inside your own network.    There's a feature in beta called No-NAT. That allows you to use the MX more as a router by disabling NAT on specified traffic. It might be your best option here. But... Beta... ... View more

To be fair, people have been getting by with SNMP traps as an alerting mechanism for many years. Though I completely agree that a more modern, reliable, mechanism would be more desirable.   IMO Meraki is a really great MSP platform, but like any offering from any other vendor, it's not perfect and you have to work with what you're given.   Good luck! ... View more

I think the unfortunate truth is that most people just use the Dashboard for everything. The API is good for many things, but it's not complete so you can't do everything through it. And as far as proactive monitoring goes the API only offers a on demand status that needs to be pulled. There's nothing like a websocket that can push an event to you. You have to fall back to an SNMP trap or email for that kind of functionality.      ... View more

I don't have a good answer for you, but I can suggest create.meraki.io to explore what other people have done with the Meraki API. Specifically, it sounds like this section might be of interest to you:   https://create.meraki.io/msp-trail-map/     ... View more