Disclaimer: i'm still new to Meraki, so if you are going to flame me for not knowing something, remember that i'm upskilling at the moment. Overview of the Topology for the issue listed below     We've had an outage (on our Guest wifi) when the inside interface for the firewall at Data center 1 wentdown, because we didn't have a secondary MX set for the APs at our branch network. -We have 2 MXs, one at each Data center. -Each Data center uses it's own DHCP server for Guest Wifi. -The DHCP servers are on a Catalyst 9300 switch (we've excluded range of IPs). -We've decided to enable the feature in the documentation below, however that turned out to be a disaster. (When we raised this to Meraki TAC, they don't even understand how this feature works, unsurprisingly). Meraki TAC is still trying to figure this out and wanted to see if the community has anything to add. -We enabled the HA for MX concentrators. -DHCP requests has to go through the Inside interface (dedicated for Guest-wifi) to reach the DHCP SVI on the cat9300 switch. -The UI is bugged that when you selected "Re-associate" clients and save the page, then the page reloads that it's still marked as "don't re-associate". -Once you put an ip in the "tunnel health ip" field, try to delete it and save, the ip will show up again upon refresh of the page. (Clearly a bug). -Both DHCP scopes are reachable for the Access points at the branch and we've confirmed that through my personal cell phone wiifi connection and what ip addresss it grabbed. so if DHCP probes are somehow blocked, my cell phone shouldn't be able to get an ip from Guest-wifi. -Once we've enabled that feature, the Guest Wifi at a pilot site kept flapping back and forth between the 2 data centers. Changed VPN connections (8): • The teleworker VPN connection to XXXXXXXXXX's SSID Guest in network Branch XXXXXXXXX is now down. • The teleworker VPN connection to XXXXXXXXXX's SSID Guest in network Branch XXXXXXXXX is now down. • The teleworker VPN connection to XXXXXXXXXX's SSID Guest in network Branch XXXXXXXXX is now up. • The teleworker VPN connection to XXXXXXXXXX's SSID Guest in network Branch XXXXXXXXX is now down. • The teleworker VPN connection to XXXXXXXXXX's SSID Guest in network Branch XXXXXXXXX is now down. • The teleworker VPN connection to XXXXXXXXXX's SSID Guest in network Branch XXXXXXXXX is now up. • The teleworker VPN connection to XXXXXXXXXX's SSID Guest in network Branch XXXXXXXXX is now down. • The teleworker VPN connection to XXXXXXXXXX's SSID Guest in network Branch XXXXXXXXX is now down. -We've received overnight an alert twice a minute from the logs above. -The documentation doesn't mention exactly what is the acceptable use case for this feature. -It doesn't show an example of how those DHCP packets look like and what flags are expected that the DHCP server is going to acknowledge. -We've pointed the tunnel health IP field to the SVI of the DHCP scope on the Catalyst 9300 switch where the primary MX is. (The documentation doesn't say which DHCP server that this need to be pointed at, again no clear use case is defined here). And we changed that to the standby. (The issue persisted) -We didn't see any logs on the firewall inside interface that it was blocking anything. -I ran packet capture on Cat9300 switch (at both datacenters) but i don't see anything coming as a probe. -The ip address that the Tunnel health ip probes are pointing at is excluded from the DHCP scope. -The documentation doesn't even say what the source ip of those probes are going to be when you set an ip address in that field. What are we doing wrong here? how does this feature work? what DHCP options are included in those DHCP probes? -Documentation for the feature i'm talking about: https://documentation.meraki.com/MR/Access_Control/Secondary_MX_Concentrator_for_MR_Teleworker_VPN ... View more

Hi, Disclaimer: This is my first post in the Meraki Community and still picking up on the technology. So please be gentle if you are going to flame me. We've recently experienced an outage for our Guest-Wifi SSID at several branch locations where the Access points connects back to a concentrator over the Cisco SDWAN tunnel to our datacenter where the Meraki concentrator is. Found out that there is a button called "Test connectivity" under the access point portal (wireless -> configure -> Access Control). That helped us isolate that there was a connectivity issue preventing the Access point from broadcasting the SSID. Using that botton helped determine that. Now we are aiming at creating a script that will run such test everyday in the morning and after hours to make sure that all sites are running as they should be. However, looking throught he api documentation, i wasn't able to find anything related to that button (including looking through the forum before posting). Can someone guide me in case i didn't do my due deligience?   ... View more