Dashboard Alerts - Connectivity Issues
Overview
This document list all the alerts available under "Connectivity Issues" alert category and their triggers and troubleshooting steps. Please refer to network alert hub documentation to learn more.
802.1X failure
Triggers
The "Recent 802.1X Failure" alert will be displayed if the periodic access-request messages sent to the configured RADIUS servers are unreachable, using a timeout period of 10 seconds. For more information 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
-
Please refer to RADIUS Issue Resolution Guide for detailed troubleshooting flow.
VPN problems on SSID
Trigger
If the tunnel connection between MR and MX is not functioning properly the AP will show this alert.
Troubleshooting steps
- Please refer to this documentation for more information on how SSID tunneling works and make sure the upstream firewall is not blocking any of the UDP ports used for the VPN registry.
Unreachable device(s)
Triggers
If a device completely stops reporting to the Meraki cloud, the dashboard alerts that the device is unreachable.
Troubleshooting Steps
- Check if the device is receiving power from its power source
- AC adapter or from a device supplying PoE
- Confirm the color of the power status light on the device
- Make sure the device is not running in dark mode
- Make sure the device is powered on and at least the LED showing amber color
- Usually, if a Meraki device is not connected to the Meraki dashboard but powered on the power LED turns solid amber or red color. It is recommended to refer to the respective device model's installation guide to learn more about the status light.
- If there is no power status light or power status light is amber please refer to device specific troubleshooting guide below
- Confirm the device is establishing a link with the upstream device
- Make sure layer 1 connectivity is healthy
- Check the LED on the Ethernet port is lit or seen as a mesh neighbor
- Check if the device is connected to a working internet connection
- A working internet connection will have access to the IPs, ports, and protocols defined under Help > Firewall info in the dashboard and would be able to successfully pass the connection monitoring test
- If multiple VLANs are in use upstream, test connectivity on the same VLAN
- The device is receiving an IP address from the DHCP server or has a valid static IP properly assigned
- Take a packet capture on an upstream device to see what traffic the device is sending and receiving
- Filtering for the IP address or MAC address of the device and downloading the .pcap file is recommended for larger networks
- If a device has not checked into the dashboard after several minutes since being powered on, but it is associated with a dashboard network and there is other Meraki equipment checking into the dashboard, refer to the device's local status page for the next steps in troubleshooting.
Please reach out to Meraki support to confirm these findings and work through any potential next steps.
Dormant device(s)
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%, its time to 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.
Device(s) has never connected to the Meraki cloud
Trigger
This alert indicates the device in question has, while assigned to the current account, has never checked in with the Meraki Cloud controller. 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
- Check if the device is receiving power from its power source
- AC adapter or from a device supplying PoE
- Confirm the color of the power status light on the device
- Make sure the device is not running in dark mode
- Make sure the device is powered on and at least the LED showing amber color
- Usually, if a Meraki device is not connected to the Meraki dashboard but powered on the power LED turns solid amber or red color. It is recommended to refer to the respective device model's installation guide to learn more about the status light.
- If there is no power status light or power status light is amber please refer to device specific troubleshooting guide below
- Confirm the device is establishing a link with the upstream device
- Make sure layer 1 connectivity is healthy
- Check the LED on the Ethernet port is lit or seen as a mesh neighbor
- Check if the device is connected to a working internet connection
- A working internet connection will have access to the IPs, ports, and protocols defined under Help > Firewall info in the dashboard and would be able to successfully pass the connection monitoring test
- If multiple VLANs are in use upstream, test connectivity on the same VLAN
- The device is receiving an IP address from the DHCP server or has a valid static IP properly assigned
- Take a packet capture on an upstream device to see what traffic the device is sending and receiving
- Filtering for the IP address or MAC address of the device and downloading the .pcap file is recommended for larger networks
- If a device has not checked into the dashboard after several minutes since being powered on, but it is associated with a dashboard network and there is other Meraki equipment checking into the dashboard, refer to the device's local status page for the next steps in troubleshooting.
Please reach out to Meraki support to confirm these findings and work through any potential next steps.
Internet gateway unfound
Triggers
This alert commonly occurs if a Meraki device has no gateway or IP address assigned (and cannot find one automatically with DHCP).
Troubleshooting Steps
- Ensure the device has a working and valid IP address from the DHCP server. If using a static IP, check and make sure this IP address works on a laptop as well. If not, the static IP information is likely incorrect and needs to be updated.
- If the device is not accessible from the dashboard follow the steps outlined here.
Bad internet connection
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 NAT issue." is reported on the device details page in dashboard.
- Devices cannot connect to your network
Troubleshooting Steps
This is generally caused by an upstream firewall not using stateful packet inspection. In this instance, the Meraki device's TCP SYN packet is reaching the cloud. When the cloud responds to the Meraki device with a TCP 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 please try the following:
- 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.
- Verify that your firewall or any other security devices within your network are not modifying the Meraki device's traffic.
- Allow your Meraki devices to bypass your firewall, content filter, proxy server or any other security devices.
- Make sure your firewall is performing stateful packet inspection which allows incoming packets if they are part of an ESTABLISHED connection.
- 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, please review this KB: Firewall Rules for Cloud Connectivity
Cannot find a gateway to the Internet
Triggers
The Meraki device is powered on but 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
- 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 in dashboard and would be able to successfully pass the connection monitoring test
If the network's design is expected to have an MR functioning as a mesh repeater:
- Confirm there is an MR in the same dashboard network that is within wireless range and strong enough of a signal
Poor connectivity to the Meraki cloud
Triggers
When this alert is shown, it 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 SYN packet is reaching the cloud. When the cloud responds to the Meraki device with a TCP 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 please try the following:
- 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.
- Verify that your firewall or any other security devices within your network are not modifying the Meraki device's traffic.
- Allow your Meraki devices to bypass your firewall, content filter, proxy server or any other security devices.
- Make sure your firewall is performing stateful packet inspection which allows incoming packets if they are part of an ESTABLISHED connection.
- 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, please review this KB: Firewall Rules for Cloud Connectivity
Backup cloud connection used
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, but rest assured 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 protocol on the referenced ports to check-in to the cloud.
For more information on configuring your firewall to support the Meraki Cloud, please review this KB: Firewall Rules for Cloud Connectivity
Meraki cloud communication issues
Triggers
When this alert is shown, it 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 SYN packet is reaching the cloud. When the cloud responds to the Meraki device with a TCP 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 please try the following:
- 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.
- Verify that your firewall or any other security devices within your network are not modifying the Meraki device's traffic.
- Allow your Meraki devices to bypass your firewall, content filter, proxy server or any other security devices.
- Make sure your firewall is performing stateful packet inspection which allows incoming packets if they are part of an ESTABLISHED connection.
- 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, please review this KB: Firewall Rules for Cloud Connectivity
Cellular Failover Active
Triggers
Loss of all wired uplinks, which includes but not limited to port down, device DNS/ping failures, etc.
Troubleshooting Steps
- Verify wired connection is up,
- if UP, run connection tests on Appliance status > Tool tab e.g. pings to Internet
- if DOWN, check cable and upstream modem or link
- Contact ISP
VLAN disconnect
Triggers
For VRRP to work properly both switches in the VRRP setup listen to VRRP advertisements on all VLANs configured as layer 3 interface. If switches stop receiving VRRP advertisements on any of these VLANs this alert is triggered.
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 and check which VLAN is missing VRRP advertisement and contact Meraki support to further troubleshoot the issue.
VRRP failover
Triggers
This alert is triggered if the spare device becomes the primary. To learn more about how VRRP works please refer to this document.
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.
Site-to-Site Auto VPN Down
Triggers
This alert is triggered if the Meraki auto VPN connection to a neighboring site is down for more than 5 minutes.
Troubleshooting Steps
-
Please refer to Meraki Auto VPN - Configuration and Troubleshooting for more information on how to troubleshoot auto VPN issues.