Usually disconnects from the VPN registry servers would show with a different event, compared with site-to-site tunnel drops.   Also disconnects from those registries would not usually affect the actual site-to-site tunnels themselves, so I'm a bit surprised this was the single fix for your issue. ... View more

The VMX in routed mode does not support firewall function at this time. Did you read this?   :   https://documentation.meraki.com/MX/Other_Topics/vMX_NAT_Mode_Use_Cases_and_FAQ ... View more

Whilst this covers only PEAP-MSCHAPv2 (which uses username+pwd for client auth, rather than certs) this doc would be a good starting point for understanding Meraki working with NPS.   https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise You will need to consult NPS documentation for more detail around using cert-based client auth.   Have you considered working with a partner IT company to help you integrate these things?   A good one will have done this before. ... View more

Well - all the cleverest stuff in such deployments is done by either InTune (check Microsoft documentation) or the RADIUS server.   Do you already have a RADIUS setup?   You could consider Cisco ISE, for which this would be a good place to start:   https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/214975-configure-eap-tls-authentication-with-is.html#anc8   Have a read of this to understand the Meraki AP role in the setup:  https://documentation.meraki.com/MR/Encryption_and_Authentication/RADIUS%3A_WPA2-Enterprise_With_EAP-TLS It mainly acts to relay details between the client and RADIUS server and implement the authentication decisions and related stuff arising from the RADIUS server's intervention.   Having separate vendors for the various components of such setups can make it more difficult to implement.    This is why some customers choose to simplify as far as possible;   using Meraki Systems Manager for MDM, with Meraki APs and Cisco ISE for RADIUS.   You still have other vendors for the client OS's + 802.1x supplicants, of course, but it can really help. ... View more

There is a formal feature request in the system for this - I suggest you contact your Meraki account team to have them add your weight to the ask. ... View more

I would have thought you could use InTune to push a WiFi profile with digital certs and config for EAP authentication for full 802.1X with a RADIUS server - that way you end up with WiFi encryption too - not just authentication. ... View more

You'll need to think about your traffic flows.   It's not clear how many Mikrotik sites are involved here, nor how traffic is required to flow between locations with MX appliances, Azure and Mikrotik equipped sites.  One thing you won't be able to do;   connect your MX appliances and your Mikrotik routers to the same VMX and have traffic flow from edge to edge using that common VMX hub as a hairpinning point.  If you want an MX site to talk to a Mikrotik site, you will need a direct non-Meraki VPN tunnel directly between (each of) them. ... View more

If you have just a single MX, you have no onsite servers and all your SVIs (default gateways) are handled by the MX, then I'd say you were fine to link all your switches direct to the MX, reducing hop count etc - in such a setup, there would be no loops to resolve and no advantage from ASIC-powered routing (in a L3 switch).   If you are using warm spare (dual MXs) I'd definitely go with @KarstenI 's recommendation;   aggregate your switches to a stack of two switches, then put resilient links in as per the Recommended Topologies section of the warm spare document that @alemabrahao linked - and use Spanning Tree to resolve loops as needed and 're-open' blocked links when required upon failure. ... View more

Agree they can't both be right.   Using the "Where is it" example as the arbiter, I'm thinking the diagram is right and the test in the table is wrong.    I'm looking into confirming this with the product team. ... View more

Did you see this?   https://documentation.meraki.com/MX/Deployment_Guides/vMX_and_Azure_Route_Server ... View more

There are so many advantages to using VMX (and therefore AutoVPN) over non-Meraki VPN, that it's hard to know where to start.   The most important is likely to be in the resilience offered;   your MXs connect to both VMXs concurrently and you get far better failover capability - particularly if your branches also have dual WAN uplinks.   Given the importance of modern Azure deployments, it really costs in, for most customers. ... View more

This isn't possible with non-Meraki VPN.   Did you consider using vMX in Azure instead?   This would allow all the SD-WAN features, in addition to BGP ... View more

There's no way to do this natively within the Dashboard, that I'm aware of.   You would be able to monitor cellular usage, however, via the API - you could then trigger additional API-based controls, once usage reaches your preferred threshold(s): https://developer.cisco.com/meraki/api-v1/#!get-network-appliance-uplinks-usage-history   Perhaps by progressively stepping up cellular firewall rules, as the limit approaches - maybe ultimately allowing only the most critical / bandwidth thrifty applications?    https://developer.cisco.com/meraki/api-v1/#!update-network-appliance-firewall-cellular-firewall-rules   ... View more

OK, so you could continue to use your L3 switching Core and apply Access Control Lists there, for your BMS separation.   Is there a particular reason why you route between VLANs on your switches, rather than the MX?  There are potential performance advanatages doing that (as it's done in ASIC) - but they tend to only accrue if you have servers located onsite and a decent amount of east-west traffic (particularly between servers in different VLANs).   Increasingly servers tend to be away across a WAN link somewhere, where the uplink capacity is the main bottleneck.   https://documentation.meraki.com/MS/Layer_3_Switching/Configuring_ACLs https://documentation.meraki.com/MS/Other_Topics/Switch_ACL_Operation  ... View more

You don't need to apply an ACL to a specific entity, like a VLAN or SVI, like you do with similar solutions.   Note this from the beginning of the guide: <With Meraki, you only have to define an ACL once in a network and it will be propagated to all switches within that network. Additionally, the default rule for Meraki ACLs is "Permit Any Any">     'Network' in context means a specific Network within the Meraki Dashboard (i.e. it will be applied on all switches, effectively on all ports on those switches.   You therefore just need to get the sources and destinations right, for them to work properly. Note though that it is possible, within any ACL, to choose to specify a source VLAN - but the default is Any   https://documentation.meraki.com/MS/Layer_3_Switching/Configuring_ACLs https://documentation.meraki.com/MS/Other_Topics/Switch_ACL_Operation   ... View more

It's not clear quite what Merki gear you have, but personally I'd recommend the following approach, which matches some of the previous replies: Having separate physical networks for this kind of thing is a dying approach, I would say and for good reasons, that I won;t go into. Provision one common reliable, resilient, performant network for all of your traffic, then apply appropriate logical separation and controls (e.g. rate shaping) for the stuff that needs it (that probably includes BMS).   While there are other approaches, simply using VLANs and firewalling between them is a relatively simple and well understood and scalable approach.   Generally you provide one gateway per site that interconnects the VLANs at Layer-3 and this is where you define the (firewall) rules for what can talk to what.  In a Meraki network, you'd probably be best using an MX appliance as that common gateway.  It would also provide the necessary protection between your Internet uplink - particularly if you use the Advanced Security license. ... View more

Try an auto-refresh plug-in for your preferred browser ... View more

What you won't be able to do is power the phone off the MX;   you'll need a PoE injector ... View more

You will require a quote from a Cisco authorised partner for your license, the SKU will be in the following form: LIC-MS320-48xx-xYR There are three models;   non-PoE (simpoly remove the xx) Low Power (xx=LP) or Full Power (xx=FP)    Then you have the choice of 1, 3 or 5 years licensing, for the last x   (7 or 10 year licences available, but for a model that's already end of sale, that might not be sensible). You must match the license to the model of switch hardware that you have;   you can't for exampe, use a non-PoE license for a PoE switch. ... View more

Email support@meraki.com ... View more

If you statically configure a 2.4 GHz channel properly, it won't move away from there.   Are you sure you haven't just chaned the config to amend the channels which can be chosen by the autochannel mechanism?   I would agree with the previous comment to stick with 1, 6 or 11 btw, whether you do this dynamically or via manual assignment.  Personally I'd stick with auto if you can, because this will take account of transient changes to background channel utilization.  Only go with static if you're finding the sheer number of channel changes actually create more disruption than it's worth.   Also;   assuming you have mainly dual-band devices, turn on band steering, if 2.4 GHz is proportionately over-utilised. https://documentation.meraki.com/MR/Radio_Settings/Band_Steering ... View more

The single uplink would just be for building the stack in the first place.   You'd then create the aggregate link configuration (at both ends), for the addition of your second link.   you don't need an uplink for each individual switch.   https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Ports#Link_Aggregation    ... View more

Something doesn't sound quite right here, if VPNC MXs logically sit between your perimeter firewall and core switches - VPNCs should sit 'off to one side' of one of those two layers  (usually the Core routing, to make things simpler)   If memory serves, EIGRP works layer 2, so I'd expect a VLAN directly between the Core and the firewalls, over which the EIGRP relationship is established.   The VPNC MX might be connected to the same VLAN,  but shouldn't be critical to the flow of that traffic (MX doesn't 'talk EIGRP') Now - I'm not saying the MX and its firmware wasn't directly involved in the issue though - if the problem started when the upgrade happened and was fixed as soon as you rolled back it's hard to argue with that - but I'd maybe look a bit deeper into your architecture.   I'd recommend talking further with Support on that, if needs be - but maybe with your Meraki account TSA too..? ... View more