Skip to main content
Cisco Meraki

Dashboard Alerts - Connectivity Issues

  1. Last updated
  2. Save as PDF

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

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
  • 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
  • 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: 

  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, 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

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: 

  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, 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: 

  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, 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 

  1. Back to top
  • Was this article helpful?

Recommended articles

  1. Article type
    Reference
    Stage
    Final
  2. Tags
    This page has no tags.