Dashboard Alerts - Connectivity Issues

Triggers

If the periodic access-request messages sent to the configured RADIUS servers are unreachable, using a timeout period of 10 seconds. Refer to Alert - Recent 802.1X Failure.

With RADIUS testing enabled, all RADIUS servers will be tested by every node at least once per 24 hours regardless of test result. If a RADIUS test fails for a given node, it will be tested again every hour until a passing result occurs. A subsequent pass will mark the server reachable and clear the alert, returning to the 24 hour testing cycle.

Troubleshooting Steps

Refer to RADIUS Issue Resolution Guide for detailed troubleshooting flow. 

Triggers

If the tunnel connection between MR and MX is not functioning properly.

Troubleshooting Steps

Make sure the upstream firewall is not blocking any of the UDP ports used for the VPN registry. Refer to Service set identifier (SSID) Tunneling and Layer 3 Roaming - VPN Concentration documentation for more information.

Triggers

'Unreachable' or 'Has never connected to the Meraki dashboard alerts' are usually triggered due to a problem in the path from the node to the Meraki cloud. Since the node is no longer able to communicate with the Meraki cloud, the dashboard reports it through the alert.

Troubleshooting Steps

1. Check for outages: If an outage is reported on the Meraki Status page, follow its guidance. 
2. Check upstream devices: Verify the status of upstream neighbors; if a Meraki neighbor is offline, perform Suggested actions on it.  
3. Check device power: Confirm the device LED status and try different power sources if needed. Collect packet capture on neighbor to determine root cause. 
4. Access local status page (LSP): Check the device LSP for IP and firewall issues. 
5. Collect Support Data Bundle (SDB): Follow the instructions in the Using the Support Data Bundle documentation to download and save the SDB.  
6. Reboot/Reset Device: Reboot device only if root cause analysis is not needed and network connectivity is urgently required.  
7. Contact support: If further assistance is needed, click the Submit case button.

Triggers

A sensor has not reported to the dashboard for more than a week. 

Troubleshooting Steps

• Check the last reported battery of the sensor that is reporting as 'dormant.' If the battery % is less than 5%, replace the batteries.
  • MT10/12 uses 2 AA batteries.
  • MT20 uses a single AA battery.
• Make sure that the MT sensor is in range of a qualified gateway (MV or MR).
  • The signal strength to the gateway must be >-85 dBm for the sensor to communicate to the gateway. Note that even if the sensor data is not reported, the RSSI will still be recorded if a gateway is able to pick it up.

Triggers

The device never checked in with the Meraki Cloud controller even though it is assigned to the current account. This is common to see straight away after a first-time setup and should be resolved after a few minutes. However, that is not always the case.

Troubleshooting Steps

• Confirm the device is establishing a link with the upstream device through its ethernet port.
• Confirm the color of the status light on the device.
  • Keep in mind if the network is configured for devices to run in dark mode.
• Use the same troubleshooting flow seen on Unreachable device(s).

Triggers

If a Meraki device is having problems contacting the Meraki cloud through your firewall, content filter, or proxy server, you will experience the following issues and alerts on your Meraki network and dashboard:

• Yellow connectivity icon on the devices list page and individual device detail page. 
• Orange bars on the connectivity graph.
• "This device has poor connectivity to the Meraki controller, possibly due to an asymmetric firewall or network address translation (NAT) issue." is reported on the device details page in dashboard.
• Devices cannot connect to your network.

Troubleshooting Steps

This alert is generally caused by an upstream firewall not using stateful packet inspection. In this instance, the Meraki device's TCP synchronize (SYN) packet is reaching the cloud. When the cloud responds to the Meraki device with a TCP synchronize acknowledge (SYN/ACK), it is dropped by the firewall. The Meraki device waiting on the TCP SYN/ACK never receives it. Therefore an acknowledgement TCP ACK from the Meraki device is never sent back to the controller to establish the TCP connection. This is called one-way traffic. 

This issue can also be caused when you have two different routers connected to your LAN segment to route traffic to different networks. In this instance, traffic from remote network enters the LAN from one router's interface and is sent to a LAN device. When the LAN device replies, it sends the reply to the other router's interface. The router receiving the frame discards the packet because it only sees half of the connection.

To isolate and potentially remedy these issues and alerts, try the following: 

1. Move your Meraki device to a different network segment where other devices are working, and then analyze the difference in the path to the internet. 
2. Verify that your firewall or any other security devices within your network are not modifying the Meraki device's traffic.
3. Allow your Meraki devices to bypass your firewall, content filter, proxy server or any other security devices. 
4. Make sure your firewall is performing stateful packet inspection, which allows incoming packets if they are part of an established connection.
5. Make sure you only have a single entry and exit interface on your LAN segment.

For more information on configuring your firewall to support the Meraki Cloud, review Upstream Firewall Rules for Cloud Connectivity.

Triggers

The Meraki device is powered on, but it is not able to use its Ethernet connection or an MR is unable to mesh to another MR in the same dashboard network.

Troubleshooting Steps

If the device is expected to use its ethernet port for connectivity to the internet:

• Confirm the device is establishing a link with the upstream device through its ethernet port.
• Confirm the device is receiving an IP address from the DHCP server or has a valid static IP assigned (see Static IP Assignment on a Cisco Meraki Access Point).
• Connect to a known working network connection with access to the internet.
  • A working internet connection would have access to the IPs, ports, and protocols defined under Help > Firewall Info (Upstream Firewall Rules for Cloud Connectivity) in the dashboard and would be able to successfully pass the connection monitoring test (see Connection Monitoring for WAN Failover)

If the network's design is expected to have an MR functioning as a mesh repeater (see Wireless Mesh Networking - Repeaters), confirm there is an MR in the same dashboard network that is within wireless range and strong enough of a signal.

Triggers

This is due to a wrong configuration on network equipment (typically a firewall or a device performing NAT) that is supposed to let the Meraki device connect to the internet.

Troubleshooting Steps

This is generally caused by an upstream firewall not using stateful packet inspection. In this instance, the Meraki device's TCP synchronize (SYN) packet is reaching the cloud. When the cloud responds to the Meraki device with a TCP synchronize acknowledge (SYN/ACK), it is dropped by the firewall. The Meraki device waiting on the TCP SYN/ACK never receives it. Therefore an acknowledgement TCP ACK from the Meraki device is never sent back to the controller to establish the TCP connection. This is called one-way traffic. 

This issue can also be caused when you have two different routers connected to your LAN segment to route traffic to different networks. In this instance, traffic from remote network enters the LAN from one router's interface and is sent to a LAN device. When the LAN device replies, it sends the reply to the other router's interface. The router receiving the frame discards the packet because it only sees half of the connection.

To isolate and potentially remedy these issues and alerts, try the following: 

1. Move your Meraki device to a different network segment where other devices are working and then analyze the difference in the path to the internet. 
2. Verify that your firewall or any other security devices within your network are not modifying the Meraki device's traffic.
3. Allow your Meraki devices to bypass your firewall, content filter, proxy server or any other security devices. 
4. Make sure your firewall is performing stateful packet inspection which allows incoming packets if they are part of an ESTABLISHED connection.
5. Make sure you only have a single entry and exit interface on your LAN segment.

For more information on configuring your firewall to support the Meraki Cloud, review Upstream Firewall Rules for Cloud Connectivity.

Triggers

The backup cloud connection is used when the primary connection fails. This helps Meraki devices to stay up to date even if there is a problem with the primary connection to the Meraki Cloud servers.

The backup connection can use port 80 or 443. The data is encrypted despite how it is transported.

Troubleshooting Steps

Connecting to the Meraki Cloud is what allows Meraki device to show as online in the Meraki dashboard. For hardware to successfully check in with the Meraki Cloud controller, the following requirements must be met:

• The hardware must have a valid IP assigned. If DHCP does not automatically provide your hardware with an IP address, assign a static IP address to your device. 
• UDP port 7351 must be allowed on any firewalls or devices upstream. The Meraki Go hardware uses the UDP on the referenced ports to check-in to the cloud.

For more information on configuring your firewall to support the Meraki Cloud, review Upstream Firewall Rules for Cloud Connectivity.

Triggers

This is due to a wrong configuration on network equipment (typically a firewall or a device performing NAT) that is supposed to let the Meraki device connect to the internet. This alert may also be phrased as "The Cisco Meraki Cloud is having difficulty communicating with this device".

Troubleshooting Steps

This is generally caused by an upstream firewall not using stateful packet inspection. In this instance, the Meraki device's TCP synchronize (SYN) packet is reaching the cloud. When the cloud responds to the Meraki device with a TCP synchronize acknowledge (SYN/ACK), it is dropped by the firewall. The Meraki device waiting on the TCP SYN/ACK never receives it. Therefore an acknowledgement TCP ACK from the Meraki device is never sent back to the controller to establish the TCP connection. This is called one-way traffic. 

This issue can also be caused when you have two different routers connected to your LAN segment to route traffic to different networks. In this instance, traffic from remote network enters the LAN from one router's interface and is sent to a LAN device. When the LAN device replies, it sends the reply to the other router's interface. The router receiving the frame discards the packet because it only sees half of the connection.

To isolate and potentially remedy these issues and alerts, try the following: 

1. Move your Meraki device to a different network segment where other devices are working and then analyze the difference in the path to the internet. 
2. Verify that your firewall or any other security devices within your network are not modifying the Meraki device's traffic.
3. Allow your Meraki devices to bypass your firewall, content filter, proxy server or any other security devices. 
4. Make sure your firewall is performing stateful packet inspection which allows incoming packets if they are part of an established connection.
5. Make sure you only have a single entry and exit interface on your LAN segment.

For more information on configuring your firewall to support the Meraki Cloud, review Upstream Firewall Rules for Cloud Connectivity.

Triggers

Loss of all wired uplinks, which includes but not limited to port down, device DNS/ping failures, and so on.

Troubleshooting Steps

• Verify the wired connection is up via the port status on the dashboard or via the port status LED on the device.
  • When there is a physical connection up, perform tests via the dashboard under Security & SD-WAN > Monitor > Appliance Status > Tools:
    • Pings can be used to check if the appliance can reach IPs on the internet, local gateway, and so on.
  • When there is no physical connection up:
    • Check the cable connection and power to the modem.
    • Test with new cables or known working cables.
• Contact the ISP.

Triggers

Both switches in the virtual route redundancy protocol (VRRP) setup listen to VRRP advertisements on all VLANs configured as layer 3 interface. This issue happens when a switch fails to receive VRRP advertisements on any of these VLANs.

Troubleshooting Steps

• Check if the ports between the primary and secondary devices are allowing all the VLANs. If not, update the ports to allow all the VLANs. 
• If VLANs are allowed run packet capture on those ports, check which VLAN is missing VRRP advertisement and contact Meraki support to further troubleshoot the issue. 

Triggers

If the spare device becomes the primary device. To learn more about VRRP, refer to MS Warm Spare (VRRP) Overview.

Troubleshooting Steps

• Confirm the primary switch is establishing layer 1 connectivity with the spare switch.
• Make sure VLANs configured as layer 3 interface are allowed between the primary and spare switch.
• Check if the primary switch is functioning properly as per other troubleshooting sections within this article.

Triggers

If the Meraki auto VPN connection to a neighboring site is down for more than 5 minutes. 

Troubleshooting Steps

Refer to Meraki Auto VPN - Configuration and Troubleshooting for more information on how to troubleshoot auto VPN issues. 

Triggers

When 5 client disassociations are detected in a 5 seconds time window.

Troubleshooting Steps

• Check wireless and radio settings.
• Check and troubleshoot affected APs.

Triggers

A radio channel has detected high interference from external sources. Check for sources of 2.4GHz or 5GHz emissions in the immediate vicinity, such as:

• Microwaves
• Cordless phones
• Tablets
• Direct satellite service
• Certain external electrical sources such as power lines, electrical railroad tracks, and power stations
• Wi-Fi cameras
• Baby monitors
• 2-way radios
• Unshielded power or video cables

Troubleshooting Steps

If you are able to effectively isolate the cause(s), then take steps to reduce the interference in your environment.

To identify every device in your environment using the 2.4GHz and 5.0 GHz bandwidths, it will be necessary to check the specifications on every electronic device. Keep in mind that while they may not list the bandwidth, they are using these radio frequencies if they are noted to be "Bluetooth", "Wi-Fi" or "Wireless" devices.

Triggers

Device is not transmitting telemetry data to dashboard.

Troubleshooting Steps

• Check network connectivity and gateway route.
• Check firmware version.
• Check username/password

Triggers

AP can not reach/communicate with the internet

Troubleshooting

• Check the subnet and/or VLAN the AP is on to verify if configured properly and can reach the internet.
• If configured properly, continue troubleshooting at the next hop/gateway to verify path integrity.

Triggers

The AP has stopped communicating with the Wireless LAN controller

Troubleshooting

• Check the subnet and/or VLAN the AP is on to verify if configured properly to communicate with the WLC
• Check path integrity between AP and the WLC
• Check IP/DHCP configuration and options

Triggers

The gRPC connection between the AP and the Sensor Connect application is down.

Troubleshooting

• This is applicable only to networks where the Sensor Connect is enabled.
• Restart the Access Point
• Wait until the LED is turned Green.