Thank you for getting that addressed. The KB still says that "All MV models are supported." https://documentation.meraki.com/MV/Initial_Configuration/MV_Cloud_Archive And the FAQ says "You also have the option of using Cloud Archive on select cameras for continuous 24/7 recording " [emphasis mine]. https://documentation.meraki.com/MV/MV_Smart_Camera_FAQ Those two statements appear to be conflicting, or at least confusing to me. Are there some MV models that don't support Cloud Archive? ... View more

And I just noticed that the MV13 is missing from the list of resolutions in the FAQ. https://documentation.meraki.com/MV/MV_Smart_Camera_FAQ#MV_Cloud_Archive_FAQs ... View more

Adding to the confusion about whether all cameras are supported, the FAQ says "You also have the option of using Cloud Archive on select cameras for continuous 24/7 recording " [emphasis mine]. https://documentation.meraki.com/MV/MV_Smart_Camera_FAQ ... View more

This might be a comboport issue, depending on the MX model. If you lookup the MX model the installation guide should make it clear which ports to use when mixing SFP and copper uplinks. ... View more

I recommend Cloudlare as a WAF for its ease of use, security and cost effectiveness. Whether you go with Cloudflare or another SaaS-based WAF, you would setup your MX to only allow HTTPS ingress from the vendors IP ranges. Another option that might work in some cases, in conjunction with or in place of VPN-solutions, is to allowlist IP ranges from remote sites with static IPs on the MX. In this case, the traffic is still flowing directly over the internet but the data is encrypted and it can only originate from specific locations. ... View more

This is not from Cisco Meraki, but I would look at this article: https://cyber-fi.net/index.php/2022/03/13/how-to-connect-the-meraki-mx-to-ms-switches/ ... View more

For more HA design approaches, please see @KarstenI's excellent article. ... View more

Usually some degree of overlap is part of a Wi-Fi design to allow for roaming. Hiring a Wi-Fi consultant is the best way to tune radio settings. If there's no budget a business case for hiring specialists, you can start with Meraki's RF Spectrum tool to assess the perceived dBm values from each of the APs.  Also, some devices, such as Windows computers with Intel chipsets, allow controlling their roaming aggressiveness (from Device Manager) so that they will more quickly switch to APs with better signal strength. ... View more

I'd expect 300-500mbps, at least for a single client on 5 GHz. The actual number is influenced by all sorts of things including RF interference, channel size, device type/chipset, device drivers/OS, device config (inc. power saving, as mentioned by @PhilipDAth) exact positioning/angle of the device to the AP, AP mounting, AP radio config, number of clients connecting/using the SSID/AP, etc. You may want to test the bandwidth with multiple similar, ideally identical, devices at the same time to see if this might be a client-related limitation. Out of curiosity, is there a reason why speeds of over 300mbps+ per wireless client are important to your organization? Video streaming maxes out at 20-30mbps. ... View more

Is Static NAT configured on the MX? Meraki calls this 1:1 NAT. If so, the inbound traffic should maintain the source IP address. https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX ... View more

Also, I would try adding outbound firewall rules on the MX. That should prevent an actual attack and may cause the logging of such attempts to stop, depending on how logging and alerting is configured. ... View more

The FTD platform allows GeoBlocking/GeoAllow and IP firewall rules for VPN access. Why not add the rules to the FTD? ... View more

If it's a 24x7 environment then testing ahead of time and performing a staged migration is your best bet. If you engage (or are working with) a wireless consultant, they can help you plan the the least disruptive migration plan, possibly using extra un-mounted APs (from either vendor) temporarily in the middle of the migration. ... View more

Planning for a co-existence between AP vendors depends on the Wi-Fi authentication type and network design. If the APs can share a VLAN during a staged migration, there should be no impact to production as long as you confirm that authentication/roaming works between both sets of devices. You can setup at least one test Meraki AP and one Extreme AP in roughly the same area to test roaming between them. ... View more

Please let us know what you find. ... View more

This is from the official documentation on the MS130. https://documentation.meraki.com/MS/MS_Overview_and_Specifications/MS130_Datasheet   Port LED is off if: "Port is operating at less than full speed. For example: 10/100M on a 1GE port 100M/1GE on 2.5GE ports 1G on SFP+ ports" ... View more

So now if we want to plug in a 100mbps device and see an LED indicator, we will need to buy a 200/300 series switch (since the MS130 only turns on the LED at full port speed). This seems like a downgrade in usability. ... View more

I built a stack of four MS355s today. I mounted and cabled them based on the order of their serial numbers. This turned out (not surprisingly) to be the same order as the MAC addresses. After I built the stack, the Switch Stack Overview page showed them in the reverse order. I opened up a ticket and was advised that there's no way to change this, but that renaming the switches (from the MAC address) should be done anyways. Later, after renaming the switches, they did end up showing up in the correct order in the Overview page. So, I wonder if they are sorted the wrong way only when they do not have a name set. The IP address order is currently the same as serial/MAC/physical order, and it was almost certainly the same when I created the stack; so I don't think that the IP address plays a role. In any case, it would improve the deployment experience if this could be fixed or at least answered by a KB. I also noticed that blinking the switches didn't work for one of the four switches. This was only tested when they were in a stack. ... View more

Yes, the MSP proposed a design that causes problems firmware updates are applied to a single Meraki switch stack serving an ESXi cluster.    So you need to buy 1-2 switches for ESXi or re-architect the virtualization solution. ... View more

And maybe links to relevant KBs. ... View more

And see this excellent blog post from @KarstenI: https://cyber-fi.net/index.php/2022/03/13/how-to-connect-the-meraki-mx-to-ms-switches/ ... View more

I know that at least as of a few months ago there was official Meraki documentation in a single page on expected failure times for different Meraki devices, although this may have just been switches. But, I can't seem to find this so I suspect that it has been silently removed. I'd prefer to be wrong about it being removed. ... View more

What switch are you connecting the MS250-24? As long is it also supports it, that will work. A better solution for shorter cables is passive twinax, which is supported by Meraki (at least if purchased from Meraki). Again, either option will work as long as the cables/transceivers are compatible with both switches. Somewhat related to this, there's a Meraki compatible module, the MA-SFP-10GB-LRM, which is specifically designed for short runs. And it can also operate with single mode fiber or multimode fiber. ... View more