Just to be clear;    with MR76 you could use different antenna types, to provide different coverage areas for 2.4 GHz and 5 GHz, because each radio has its own pair of antenna posts.   That is a fairly unusual requirement though - but I have seen it, occasionally with (say) wireless mesh;  directional antenna on one radio (2 posts), in one band, for the backhaul, with (say) ANT-20s for local clients on the other radio.  In that case the client connectivity would, essentially be in a single band only.   This differs markedly from MR86, where all 4 posts are connected to BOTH radios;   for which the connected antennas must be dual-band and must cover the same area. ... View more

Inderdeep is right;  you will need to purchase separately. Available options listed under Antenna in the Specifications section of the datasheet: https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR76_Datasheet   The obvious starting point would be two sets of MA-ANT-20 (they are purchased in pairs), but that would deliver omni-directional coverage, in both 2.4 GHz and 5 GHz bands.   You may be looking for something more tailored / derectional for your specific coverage needs. ... View more

There's no way to tell, given just this information, whether the MT is faulty or not.   I would try moving some of your MT11s around, if you can and see how things change (or not) between sensor and environment.  In particular, if you have another one providing the kind of values you expect, could you deploy it, for a short time, alongside the existing one, to see how their results compare?   I've found that humidity changes quite a lot, in relatively short periods of time, in some environments. ... View more

You need to speak with Meraki Support on this one - did you raise a case with them? ... View more

I'd recommend you contact Meraki Support - look under Help > Get help in the Dashboard   https://documentation.meraki.com/General_Administration/Support/Contacting_Support ... View more

The Dashboard API functionality for MT sensors is in beta and will need enabling in your Dashboard Organization.  Can I suggest you reach out to your Meraki account team to gain access?  PM me if you have trouble… ... View more

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