I see that. However, almost every AP that has come back now shows this.     This means UDP 7351 is not working and it's using HTTP/HTTPS. More info HERE. ... View more

Something like that would make me suspicious that an upstream NAT rule or something changed preventing one subnet from working while another is ok. ... View more

For that many devices to all go unreachable at the same time I'd say it has to be an upstream issue. Were any changes made on the switches or upstream layer 3 devices or firewall(s)?   Also, I took a quick look at the Support case and your dashboard. I noticed from an online AP I can ping the mgmt IP of the APs showing as offline. So, to your point they are still up & functioning, but not communicating with dashboard.    Doing factory resets seems likely pointless to me as 120 devices don't all go bad at the same time. I'd focus on upstream troubleshooting (firewall logs, etc). ... View more

Ha, no worries. The call doesn't say changelog in it so the search function isn't catching it on that keyword. ... View more

The downtilt omni creates a donut like coverage with more bias towards pushing the signal downwards than the standard omni panel.   Coverage patterns can be found in the datasheets.   C5 D5   General guidance is to use the downtilt for mounting heights between 8-25 feet. And generally this would mean the antenna is mounted parallel to the floor (pointing down). You could mount the antenna parallel to a wall understanding that you'll be sending a lot of signal up & down.   You don't often see an internal antenna AP mounted on a wall for the same reason. It's shooting a lot of the signal into the ceiling and floor instead of outward to clients below. ... View more

Is there any specific reason for statics on the switches?   And no, you shouldn't need to reboot anything.   For the APs. Either change the switchport connected to them to use the new mgmt VLAN as the native. Or, change the VLAN tag for the AP itself.     So for example, if the new mgmt VLAN is 700. Either change the switchport connected to the AP to be trunk native 700 and do nothing on the AP.   If instead the native on the switchport is something else let's say 100 then you'd want to type in 700 on the APs IP config. I commonly see folks specifying a tag on the AP IP config when it's the native on the switchport and that's an invalid config and you'll see errors in dashboard. ... View more

I assume the crowd here will offer some good creative ways to approach this. My initial thought would be this. And, if someone spots something off in my logic chime in. It's nearing end of the workday for me and my mental acuity could be fading.   Change all APs and Switches to DHCP. Assuming DHCP is available on VLAN 1 they will pull IPs and still be reachable. Create new mgmt VLAN(s) on MX. Not sure if you intend to use one subnet per device type or simply a new mgmt VLAN ID for all things infrastructure related. If APs are to have statics change the IP config to use the new mgmt VLAN. Assumes it's allowed on the ports down to APs as well as the ports between the MX and Switch(es). Assuming links from MX to Switch(es) are trunks allowing all VLANs change mgmt IP of switches to use the new mgmt VLAN. Basically the idea is start from the edge moving inward and having a safety net of DHCP in case anything go sideways.  ... View more

25 ft ceiling and devices will be a few feet off the ground presumably in hands when folks are sitting or standing. I think MR44s would be fine. ... View more

I've been testing a tighter ruleset for my CA enabled MVs. It appears allowing 443 to *.vision.meraki.com is working (in addition to the other cloud destinations needed for mgmt, streaming proxy, etc).   They appear to also need port 80 to 142.250.0.0/15 which must be part of the broader port 80 to any suggested rule. ... View more

While I've never actually utilized the service myself it's called Meraki Now. On that pdf it mentions using the Service Availability Matrix for more info. That site requires a CCO login. Once in you can search on your address and product family and it shows the available services. As a quick test I searched my home address and Meraki MX and it shows results like this.   ... View more

Well, #1 I work here 😉 And #2 I've helped deploy tens of thousands of MXs over the past decade for the largest customers Meraki has. So, yes it works 😉   I suppose the main takeaway from this thread if that having a spoke point to at least 2 hubs for redundancy is ideal. That could be a MX HA pair in one DC, but that means the DC is the single point of failure. So, typically you're hubs would live in 2 or more DCs for physical diversity.    The regional based hub design as shown HERE works fine. And, in that specific diagram each spoke does point to 2 hubs. So, it has the redundancy piece covered.  ... View more

It’s being fixed now ... View more

I think there's an error in the notes. Checking with PM for correction. ... View more

All supported transceivers are listed here https://documentation.meraki.com/General_Administration/Cross-Platform_Content/SFP_and_Stacking_Accessories ... View more

I think I might have found your Support case. What VLAN specifically are you having DHCP problems on? If I'm looking at the correct dashboard I see 22 interfaces on the MS425 and 22 interfaces on the MX95. Which I also don't understand. Is the 425 is the L3 gateway there should only then be a transit VLAN to the MX. I see pretty much all the same VLANs/subnets on both the switch and MX? ... View more

If your VLANs are extended from the 225s to the 425 there'd be no need for DHCP helpers anywhere. You should open a Support case so they can see the config and better assist you.  ... View more

You should review the note on MV Camera DNS here ... View more