I'm not sure, off the top of my head, but I would say it's one to raise as a case with Meraki Support. ... View more

Actually, subnet translation might work on non-Meraki VPN, but it's not supported.   I had a customer try this, a few years back, despite it not being officiallly supported - and it apparently worked.   I discovered later that they'd stopped using the feature, but without any feedback, unfortunately.   As someone else asked, it would be good to understand the use case. ... View more

So - you want to split tunnel all of your Internet-bound traffic EXCEPT O365?    I'm rather surprised by that - it's the opposite of what most people ask for. The only way to achieve this is to leave the default route box unchecked, when you choose your spokes, then make your O365 traffic VPN, rather than Internet traffic - by advertising the relevant IPs and subnets for O365, from your hub site, towards your dependent spokes.    As @PhilipDAth has said previously in this thread, it's painful, but possible.   Bear in mind you would manually need to keep the advertisements in sync with any changes made at the Microsoft end.  It's this 'automatically keeping up with MS' functionality which is key to the smart exceptions feature we created. ... View more

Even better, thank you!  😁    Learn a new thing every day... ... View more

You should really create a new post for this separate enquiry...   Leaving that aside - you use the term 'aggregate';  MX does not support link aggregation (802.3ad / LACP or similar).   With MX you provide a separate WAN (Internet) uplink to each of WAN1 and WAN2 ports and the MX can make use of both links simultaneously, by allocating different sessions to different links, based upon preference and performance criteria you configure.  so;   don't configure any link aggregation on your switches, for connection to the MXs. Each of your MXs should be connected to both switches, on the LAN side, for resilience (your diagram shows only one such link per MX).  Note however that MX does not participate in spanning tree, but will forward STP BPDUs, to allow your switches to resolve the physical loops that will create.  So;  configure STP on the switches to match the desired topology (e.g. bridge priority).    Provided you do this properly and use different VLANs for WAN1, WAN2 and LAN-side VLANs, you should not get into STP-related problems. ... View more

If you don't want your APs to have this built-in resilience, you should raise a case with the Meraki Support team, requesting that mesh be disabled, for the Network.   Given that the mesh gateway AP must be nearby, wouldn't both of them use the same Internet link anyway? ... View more

Although you could connect WAN1 and WAN2 of your MX via the same uplink - in which case they would each have an IP in the same subnet - you would normally connect different links to each of WAN1 and WAN2.   They would then have their IPs in different subnets.   In the Flow preferences for Internet traffic you would add a preference, for the source 'your Guest VLAN', to route that traffic via either WAN1 or WAN2.  That traffic will be NAT'ed behind the IP address of the chosen interface. ... View more

You're seeing this because the Access Point hasn't been able to establish a connection to Dashboard over the wired ethernet link, to which it is connected.   It would seem it is receiving power though;   it has instead established a wireless mesh uplink using a nearby wired Meraki AP.   First thing would probably be to check the cabling on all the ethernet pairs.  Also the configuration of the switch, to which it's connected;  I would configure the uplink as an 802.1Q trunk, with native VLAN 1, over which you should provide DHCP, to deliver an appropriate IP and DNS configuration to allow the AP to reach the Meraki Dashboard.   Remember too - your license allows you to contact Meraki Support, if you need to:  options are available, within Help > Get help at the top right of Dashboard. ... View more

I think you need to use this call.   You have to have the device serial number, for the one you are after:   https://developer.cisco.com/meraki/api-v1/#!get-device   ... View more

Most WiFi users will find that the 2.4 GHz band is much busier than 5 GHz.    If this is the case, it will be better all around, for those clients which can use either 5 GHz or 2.4 GHz to use the former, instead of the latter.  Dual band leaves the decision up to the client, as to what it prefers.   Sometimes clients left entirely to their own devices make 'selfish' choices to join 2.4 GHz, perhaps because it has slightly higher signal strength (the frequency generally allows it to penetrate better).   The problem is they often take no account of the fact that that band might be overloaded.   Hence band steering encourages dual-band clients to go for 5 GHz more often, so would generally be preferred.   https://documentation.meraki.com/MR/Radio_Settings/Band_Steering_Overview   Note this, from that doc:   " If certain wireless clients are unable to detect the wireless network they may be using passive scanning. In these cases configure the network to use  Dual band operation,   not Dual band operation with Band Steering ."   ... View more

Both tunnels will be created - and could actively carry traffic concurrently, depending on what resources are accessed and how they are advertised by the Hubs. Failover between the tunnels will be automatic, should one drop;  the failover time will be dependent on the nature of the failure.   Whether this is disruptive to your applications will also likely depend, to a decent degree, on how sensitive the applications are to brief loss of comms. A trial / Proof of Concept is usually recommended, with your specific blend of factors. ... View more

Z3 does indeed support just a single uplink, but can form multiple tunnels over that single link - usually to different destinations (typically MX Hubs, in some form of Data Centre).   As Z3 is designed for home office use cases, I would suggest keeping this count very small - maybe 2 or 3 tunnels, but no more. The documentation you quote around concurrently active tunnels across both uplinks relates specifically to MX (all models of which can support dual uplinks)   Note that the warm spare device option referred to in @olvs earlier reply, could apply to the MXs in your Data Centre, but not to Z3 (no warm spare option for Z3).    Such a setup would involve a single tunnel per remote Z3, to the active MX.   If the active MX failed, a new tunnel would be automatically built, to the standby - but traffic would be interrupted, while this happens. It is possible to have active - active DC AutoVPN / SD-WAN designs, but that wouldn't rely solely on the Warm spare function - more on this here:   https://documentation.meraki.com/MX/Deployment_Guides/Datacenter_Redundancy_(DC-DC_Failover)_Deployment_Guide ... View more

https://documentation.meraki.com/MR/Encryption_and_Authentication/Meraki_Local_Authentication_-_MR_802.1X ... View more

That sounds like a good plan, in principle, but sub MR86 instead of MR84, for currency.   Either way, you will need antennas with them.   How would you uplink them to the network?   Wired connection is definitely preferable. You could mesh them though, if cabling is not possible and if an existing gateway (wired) MR is near enough.   Your choice of antennas may well have an effect on that - MR84/6 is dual-band, with the 4 antenna posts serving both 2.4 GHz and 5 GHz, so you can't have one antenna optimised for mesh uplink and one serving the clients.   (You could do that with MR74/6 where each radio has its own pair of antenna posts, but those AP models arent so powerful, for the qty of users here) I would look at the ANT-20 first (qty 2 = 4 antennas) and check you'll get good mesh uplink, without the need for directional antennas.  If you have to go directional, your coverage within the tent will likely suffer - unless your directional antenna is placed to have both the clients and the gateway AP in the direction of signal travel.   The APs would be mounted with the antennas pointing straight up and straight down - probably pole mounted, out of reach of people in the tent itself. ... View more

You should know which version of the API output is being generated - It's a while since I set mine up but, when you create a post URL (destination for the output) the API version is selectable, via a dropdown. If you see only v1 or v2, I suspect you don't meet the pre-requisites for the Beta.  Beyond just having MR Access Points, this is down to firmware: Firmware   R26   for WiFi observations Firmware   R27.5   for BLE observations One of the major advances with v3 is that it consolidates observations to a single POST (and location) per network, rather then getting different values, at slightly different times, from different APs. This info and more is available here: https://developer.cisco.com/meraki/scanning-api/#!overview/requirements   Note that for AP models which pre-date 11AC Wave 2, r27 and subsequent firmware verions are not supported.   Some more info in this area here:   https://documentation.meraki.com/General_Administration/Firmware_Upgrades/MR_Mixed_Firmware_Networks   ... View more

I'd need to check but, I suspect you are right that they use different algorithms;   v3 of the scanning API is in beta. ... View more

To my knowledge, there's no way to remove the firewall function from the MR traffic processing chain.   I'm guessing the SSID in question may be configured in NAT mode (because the default Destination:Local LAN is a deny - that mode is designed for Guest users)   You can, of course, set that to Allow but, if you want to use the most 'natural' setup, you would use bridge mode, for the SSID (configured under Wireless > Acess control).  For 'Dry' you definitely don't want the clients behind a NAT. As the question relates to MR Access Points, I'd suggest this thread be moved to Wireless LAN ... View more

Have you built VPN between the sites or are you exposing the server(s) via port forwarding / NAT?   https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX ... View more