I'd actually recommend the customer looks at using Meraki Cloud Archive, if they need to store their footage for longer.   With RTSP, you lose all the ease-of-use from having motion detection, people/vehicle counting detail / metadata available through the dashboard.   If you simply store video, in an external system, how easy is it to find the specific clips you need?   You're back to to the old days of watching hours of footage...   Cloud Archive provides all the Meraki MV ease-of-use, but with footage securely stored in the cloud.   https://meraki.cisco.com/product-collateral/mv-cloud-archive-datasheet/?file https://documentation.meraki.com/MV/Initial_Configuration/MV_Cloud_Archive ... View more

Secure traffic processing really happens on the local MX, where clients are connected - you will get limited protection, if you're relying on just the VPN Hub to (Advanced Security) process the traffic.   You most likely need Adv Sec for the Spoke.   This is one reason why we simplify everything to the same license level, per Org. ... View more

Check your band selection config, for those SSIDs.   (Wireless > Access control)    If they are set to 'Dual band operation with Band Steering' try 'Dual band operation (2.4 GHz and 5 GHz)'.   Some devices use passive scanning, which can cause issues like this  (see the end of this doc:  https://documentation.meraki.com/MR/Radio_Settings/Band_Steering_Overview ) ... View more

Just one thing to add to this;   there's only an implicit allow if the packet is received on a LAN interface.  If it's on a WAN / Internet port (with no matching outbound session), it hits an implicit deny - of course! ... 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

I would try to think of your traffic flows, in such cases.    You normally look to route in a Layer-3 switch when the routing process is the potential bottleneck for your applications, because a layer-3 switch generally does this  at wire speed in silicon .  Do you have any servers, hosted on the site in question?   If not and you're going to access all your applications across the WAN, probably with much lower bandwidth and routed through the MX anyway - then I don't see that routing on your switching buys you very much (the latency for one ethernet patch cord???). If you do have local stuff you access, is that definitely inter-VLAN traffic?  If not, then again you don't lose anything.   If it is inter-VLAN, is the application latency / throughput sensitive?   Hopefully you see where I'm going with that...   The Meraki approach is about simplicity and generally I think keeping Layer-3 to the MX is simpler, so stick with it, if there's no unacceptable downside to doing so. ... View more

And don't forget - you can use packet captures;    https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Packet_Capture_Overview#MS_-_Switches ... View more

While you cannot download any raw configuration file, as others have already said - you can access details of your Dashboard configuration via API and use the API to reconfigure your Dashboard setup, hence providing an avenue for a kind of backup and restore.   Appropriate scripts can be created, customised to what you need.  Such a script and others are available online and GitHub is a great place to start.  Maybe have a look at this one first:   https://github.com/meraki/automation-scripts/tree/master/backup_configs   Loads more resources around Meraki APIs are available here:  https://developer.cisco.com/meraki/  ... View more

It's in the Datasheets, under Data Logging.  This example is for MT10 https://documentation.meraki.com/MT/MT_Datasheets/MT10_Datasheet_-_Temperature_and_Humidity#Technical_Specifications   ... View more

I'd be interested to hear what you would lose in VPNC mode, which you need? ... View more

It looks like you're putting the MX in question in a Data Centre?   Have you considered using one-armed VPN Concentrator mode? ... View more

Actually - I realise I partially misinterpreted what you said;   you are not trying to terminate the VPN tunnels via the LAN interface (though what I said about that holds true)   Only the IP addresses physically assigned to the MX WAN ports and/or the public IPs that they NAT behind are considered, when forming tunnels.   VPN tunnels are formed based upon the public IP addresses of the MXs at each end.    If both MXs break out via the same Public IP, they form their tunnel between the physical IPs.   If they have different Public IPs, they form between the two public IPs.   Your MPLS network will need to be able to break out to the Internet, as I mentioned in my previous reply.   ... View more

@CptnCrnch nailed it.   Remember too - if you need to be more granular about who can access what, across a VPN tunnel - down to devices within the VLANs at either end - you can also configure VPN firewall rules:   https://documentation.meraki.com/MX/Site-to-site_VPN/Site-to-site_VPN_Settings#VPN_Firewall_Rules These are configured separately from general inter-VLAN/Internet firewall rules.   Look under Security & SD-WAN > Configure > Site-to-site VPN ... View more

Remember that the config you apply is applied 'to the dashboard', which then pushes it down to the device, once the two have trusted comms.   You will indeed need to make sure that whatever is upstream of the MX, by way of NAT (your 5G router) and firewall rules enables / allows those comms.   Dashboard advises you what you need to permit, under Help > Firewall info.   If you're uplink comes via a mobile network, beware of the use of carrier grade NAT, by your mobile network provider, if you need to get VPN working to your MX. ... View more

If splash page is your particular ask, then this will apply:   https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Splash_Page#MX_Splash_Page_Options   I see you found that already, in Dashboard -  and that the multi-client recommendation puts it out for you  (😕).   It's worth knowing that the authorisation, on that basis - if you did adopt it - is an on/off switch.   Assuming the VLANs on your site are all routed by your MX, by default authenticated clients would be able to access all those.   You could limit any access between them (and to the Internet, of course) using the MX Firewall features.   Note that, if you're also using VPN, you would need to control any access to remote subnets over VPN tunnels separately, using VPN firewall rules under Security & SD-WAN > Configure > Site-to-site VPN ... View more

This is the document you're after, I think:  https://documentation.meraki.com/MX/Access_Control_and_Splash_Page/MX_Access_Policies_(802.1X)   This is the first line of the overview, which outlines the supported platforms:    "MX64/65(W) and MX67/68(C/W) and Security Appliances as well as Z3(C) Teleworker Gateways support port-based access policies using 802.1X. This feature can be leveraged for deployments where extra authentication is desired for devices that are connecting to the MX." I would add that access policies for MX/Z3 do not offer the same flexibility as for MS switches.  If you have sophisticated needs (which tends to come with the client density which would also drive a need for the extra LAN ports), I would recommend choosing 'smaller' MX (e.g. MC67) and pair it with dedicated MS switches, rather than going for (say) an MX68. ... View more

I have had this happen, in the past, on maybe two occasions, where this fix has worked (and maybe on different cameras, I think) - it certainly hasn't been something I've needed to apply regularly.  If you get regular recurrences, I would raise a case with the Support team and mention what you've had and what you've done. ... View more

Giving access to lots of information actually often makes customers' working lives much more complex.   If you have an issue, your license allows you to contact Meraki Support - let them worry about the complexity of (for example) When does CPU utilisation become excessive?   Meraki is pretty obsessive about making technology as simple as possible.   (BTW - if you haven't found it before, Meraki makes available an overall MX appliance utilisation number, under Organization > Summary report) ... View more

Correct - MI runs on the MX appliance 'near' the client, not on vMX. ... View more

Hmmm - I'd never tried it on MR FW before.   It seems Network Objects applies to MX only.  Could I suggest people 'Make a wish' for Network Objects on MR too..? ... View more

You mentioned vMX in your Title;   you can't run MI on vMX. Remember that MI works by sitting on the boundary between the HTTP client's LAN and that site's WAN link. The vMX sits at the opposite end of the HTTP connection - adjacent to the server. See "Where should I enable Meraki Insight?" here:    https://documentation.meraki.com/MI/Meraki_Insight_Introduction ... View more

Using Network Objects may help you:   https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Network_Objects_Configuration_Guide ... View more