Given that OSPF, in the world of MX, is really only useful for Data Centres, I'm surprised you have enough of them to need to automate the setup.   As suggested elsewhere, I'd suggest you enable VLANs, even if you only actively use one. ... View more

I would suggest that using the Dashboard API is a much better way to get this kind of information, moving forward.   I doubt there will ever be any additional information made available through the SNMP MIB.   https://documentation.meraki.com/General_Administration/Other_Topics/The_Cisco_Meraki_Dashboard_API   This particular tool might really help:   uses the API to pull data (including about Meraki APs) into Google sheets:   https://developer.cisco.com/meraki/build/meraki-dashboard-reports-with-google-sheets/    ... View more

I don't see the RADIUS server returning the Tunnel-Password..? This is what the AP needs, to attempt to match with the (same) PSK being used by the client.   I take it you have been using https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_with_RADIUS_Authentication#FreeRADIUS_Configuration ... View more

I can certainly see how it would be useful to you.    I would suggest you contact your Meraki account team, to request this request be raised on the team officially.   If you haven't already, please 'Make a wish' for this - and be sure to include your use case details;   it would be useful for other MSPs, looking after numerous Orgs too, no doubt.   If you can demonstrate the applicability to many users, a wish always has a better chance of being picked up. ... View more

OK - so your AD server is within the subnet for the VPN ✔️ I would initially try turning VPN participation on for the Default VLAN 192.168.128.0 You'll need to add this subnet to the permitted list for the tunnel in Azure, to match. Then run a packet capture on the Site-to-Site VPN interface of your MX, while you initiate your VPN Client session - filter for your AD server IP 172.16.1.4 if you wish.   If you see the query bound for your server, chances are it must be sourced from 192.168.128.1 (assuming this remains the IP for the MX in that subnet) If this works, you will need to look at your VPN firewall rules, to check they still meet your needs (hint:  you have no deny rule, currently) ... View more

I don't believe there's an endpoint for that, specifically. Surely using a Dashboard Template would be the easiest approach to this? Or you could use a combination of the two;  apply a Template   (POST /networks/{networkId}/bind) then use PUT /networks/{networkId}/appliance/vlans/{vlanId}  This single call allows changes to both IP and DHCP ... View more

Puede usar ambas antenas en el mismo MR66, pero debe asegurarse de que coincidan en la misma radio. Conecte ambas colas del ANT-25 en los postes de la antena en el mismo extremo del MR66 Conecte ambas antenas ANT-20 a los postes de antena en el otro extremo del MR66 Como ambas antenas son de doble banda (funcionarán en 2.4 o 5 GHz), deberá elegir con cuidado: ANT-25 es una antena direccional: apúntela hacia donde desee cobertura. ¿Quieres que la cobertura sea de 2,4 GHz o 5 GHz? ANT-20 es omnidireccional (funciona en todas las direcciones) Lo que es más adecuado depende de su entorno; dónde está colocando el AP (y ANT-25) y dónde necesita brindar cobertura. ... View more

OK, so the MX is clearly using a source IP address for the lookup, from a VLAN that isn't currently permitted in the VPN;   it's NATing to it's public IP and sending directly to the Internet (where it's blackholed). Check that the destination IP address for the AD server lies within the VPN routing. Assuming it already is, what I would do is allow all your VLANs access to the VPN, temporarily, then re-run the packet capture on the VPN interface, to check it's being sent via that path - you'll then also be able to see the source being used. You can then remove the other VLANs from the VPN and, if you need to, write some VPN firewall rules to (just) allow your MX to query the AD server and no other comms with that VLAN, if you need to. ... View more

First run pcaps across the different interfaces, filtered for the target AD server IP address, to establish the source and path. ... View more

You know you can't use the devices without licensing though, right...? ... View more

I don't believe there's an endpoint that lists this, currently. Given that the 'free 100' and legacy versions of SM are no longer available to new users (and this has been the case for some years) my guess is this may never be built. Can you tell me more about the use case? ... View more

I queried the detail I sent over yesterday, internally - and will be requesting updates to our documentation;   apparently it is supported for the AD server to also be reachable via VPN - and I've now seen a functioning MX set up this way.  Dashboard validates that the configured destination server is within a valid range (a configured subnet or a remote subnet on the VPN) when you configure it.   Apologies for the misinformation. This still leaves me wondering about the source IP;  I suspect the highest VLAN is used, which maybe changes the way you filter, on any packet captures?   Is it included in the VPN config...? ... View more

Have you been referring to the Client VPN documentation for this? https://documentation.meraki.com/MX/Client_VPN/Client_VPN_Overview Within the Active Directory section: Server IP: The IP address of an Active Directory server on the MX LAN.  [my bold italics] This is expanded on, in the Traffic Flow section of the more detailed AD integration section here https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Configuring_Active_Directory_with_MX_Security_Appliances#Integrating_with_Client_VPN   The MX, from its LAN IP, queries the Global Catalog over TCP port 3268 (encrypted using TLS) to the AD server configured in Dashboard.   [again, my bold italics] The AD server needs to be reachable on the local LAN. ... View more

Run some packet captures on your MX, to check the source address being used for the auth - my guess is it may be from a different subnet than you’re expecting (& from that of your AP) ... View more

Supported Client VPN authentication methods are all configured from within the Client VPN screen itself, not from Security & SD-WAN > Active Directory   (that area allows AD auth for LAN-attached clients)   You need to look to follow this:   https://documentation.meraki.com/MX/Client_VPN/Client_VPN_Overview#Active_Directory ... View more

I must admit, it's been a while since I sold Nexus, but I remember that being a thing - which is why I mentioned larger buffers specifically.  Not sure how that pans out in the current Nexus range... ... View more

I personally would recommend looking at Nexus Data Centre switches, with larger buffers. Most decent enterprise switches will run a lightly loaded iSCSI / NFS SAN OK - particularly if you ensure the SAN itself has a higher capacity uplink than the hosts it is serving, but bear in mind that, when you start to over-subscribe target ports (e.g. multiple servers writing to the same SAN port) buffers overflow quickly and packets are dropped.   SAN protocols generally behave poorly with even fairly low levels of packet drops. Of course, DC switches tend to be more expensive, so 'you pays your money and takes your choice' ... View more

Are you sure you're not looking at an MX68CW, @MerakiNorway ? The MX67C does not support WiFi   (C stands for cellular) The MX68CW supports both cellular and WiFi.   (W stands for WiFI).   Because the antennas fitted to 68CW serve both Cellular and WiFI and Meraki have to ensure customers stick to WiFi power rules, the antennas are fixed. For the MX67C, however, you can unscrew the antennas that ship with the unit and replace with cellular antenna with RP-SMA connector(s).   If the antenna + cable combination you use allows you to get a better mobile data uplink, that's great, but Meraki will not support such a configuration. ... View more

Great point about the X models, @PhilipDAth  With the latest firmware (4.8) 2nd-gen cameras now support low-latency HLS;  a couple of seconds delay now only;  makes near real-time applications (like reception allowing door release, based upon who's visible) much more feasible.   https://community.meraki.com/t5/Feature-Announcements/MV-Low-Latency-HLS-Now-Available-in-4-8/ba-p/99552 ... View more

Thanks for the top-up on that one @PhilipDAth 😁 ... View more

Found this thread whilst looking for something else.   This feature is now available with SD-WAN+ license.   Note the other pre-req's in the documentation:   https://documentation.meraki.com/MX/Site-to-site_VPN/VPN_Full-Tunnel_Exclusion_(Application_and_IP%2F%2FURL_Based_Local_Internet_Breakout)   ... View more

Optical zoom is supported by the MV22 indoor camera and the MV72 outdoor camera.   The camera itself will be fixed in your chosen position, at install time, so while you can zoom in and out 'straight ahead', you won't be able to optically zoom in on a particular location, like you would with a PTZ camera.   You can digitally zoom in on a particular part of the field of view though. More importantly, having a fixed field of view allows for a number of powerful features which PTZ cannot cater for;  the ability to reliably detect motion, for example - to quickly find and distinguish between historic events.   You're also always sure of having coverage of the area you are interested in, at any one point in time.  (no good having a PTZ if it's pointed the other way from the activity you want to look back on).  No PTZ = far fewer moving parts = fewer camera failures too.   Having the right blend of cameras usually removes the need for PTZ.   You may also be interested in the MV32 fisheye camera, which provides 'digital PTZ'.   This allows you to cover 360 degrees, from a ceiling, but focus back in on the area of interest, after the event, with the footage 'de-warped' from its original fisheye type view.   No optical zoom with a fisheye though, of course.   I think maybe you should research the general Meraki approach to security cameras too - Meraki needs no NVRs..!  Meraki simplicity = MV cameras + the Meraki Dashboard & nothing else to buy or manage.    https://meraki.cisco.com/products/smart-cameras/ Ultimately, I'd recommend getting in touch with your Meraki rep or Cisco partner to maybe free trial some cameras for your use cases.   You can access these via 'Get a demo' on the webpage above. ... View more

You may want to take a look at the variety of options for applying Meraki Group Policies, here:  (RADIUS is particularly powerful, for use with Access Points):   https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies#Applying_Group_Policies   For MX, most people find applying Group Policy by VLAN the best way:   https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Creating_and_Applying_Group_Policies#By_VLAN   I think you will need to switch to VLANs, rather than Single LAN though, first   ... View more

How does this manifest? - right now I can see the options you mention, in a sample Organization... What is the latest you have heard from Meraki Support? ... View more