Dashboard Alerts - Configuration Issues

Triggers

Meraki devices rely on DNS to resolve dashboard URLs. If a device reports issues with its DNS configuration, typically the device is not receiving responses to DNS requests. This alert may also be phrased as "DNS is Misconfigured."

Troubleshooting Steps

To find the source of the issue, check:

• Firewall rules blocking traffic to or from the DNS servers being used or traffic to UDP port 53.
• Routing traffic to or from the DNS servers.
• Invalid responses back from the DNS server.
  • Take a packet capture on an upstream device to see what traffic the device is sending and receiving.
  • For larger networks, filter for the device's IP address or MAC address and download the .pcap file.

If there are no firewall rules blocking DNS traffic and there aren't issues with routing traffic, try working around the issue by changing the DNS servers to a working public resolver on the DHCP server. Have the Meraki devices request another IP or set the IP manually, and set the DNS servers to a known working public resolver.

Triggers

This alert means that another device in the network is also using the same IP address as the Meraki device. 

Troubleshooting Steps

To resolve this problem, ensure all devices have unique IP addresses in a network. The Network-wide > Monitor > Clients list may help pinpoint the duplicate IP addresses in use:

• Open the clients list by navigating to the client page Network-wide > Monitor > Clients.
• Find a client with an IP address that matches the one shown in the alert.

Both devices—the device showing the alert and the other device using the same IP address—will struggle to reach the internet until this problem is resolved.

Triggers

This alert means a bad static IP or an incorrect VLAN tag with DHCP is being assigned to the Meraki device. Typically, network hardware will simply not work if you assign a bad IP address to it. Meraki devices, however, will automatically switch back to DHCP (automatic IP assignment) so that it can check in to the cloud and alert you about the problem if at all possible.

Troubleshooting Steps

• Make sure that the Gateway you have entered is correct and online.
• If the device has had a working static IP, make sure the IP address is still valid.
• Verify if the IP, Subnet mask and Gateway are correct for the subnet to which the AP is attached. Make sure there are no extra spaces in your settings (including leading, trailing, or between characters).
• The Primary DNS is valid and reachable (we recommend using Google Public DNS at 8.8.8.8 and 8.8.4.4).
• Check if the wrong VLAN tag is used for DHCP.
• Check the local status page - often times the local status page gives more detailed error output to help resolve the problems during troubleshooting.
• Perform packet captures to confirm ARP requests are replied to, from the upstream gateway.
• Reboot the hardware - sometimes the MAC address for the internet port can get stuck on network hardware and clear out after a set period of time. Rebooting network equipment helps speed up this process.
• Switch to DHCP. The error message will only be displayed if the Meraki device has found another working IP address. If you switch the IP assignment to DHCP instead of static IP, the device will use the current addressing. The error will go away over time. You should only specify a VLAN tag if you know what it should be. 

Triggers

A management VLAN mismatch triggers this alert. This is when there is a mismatch between operational, configured, and global management VLAN ID (see Switch Settings). This alert may also be phrased as "The device is using a DHCP IP address from VLAN X instead of using configured VLAN Y."

Troubleshooting Steps

• Make sure the device is not using a VLAN different from what is configured for its management interface. 
• Make sure the device management VLAN is not configured with a different VLAN from what is configured under Switching > Configure > Switch settings. For more information, refer to Switch Settings.

Triggers

This feature utilizes Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP) packets from the past 3 hours to determine which switch ports are connected. If any two connected switch ports belonging to Meraki switches are in the same dashboard organization, the switch port VLAN configurations are compared.

Usually, a VLAN mismatch occurs:

• After connecting a switch that is not pre-configured to the existing Meraki switch infrastructure.
• When a network administrator changes the port VLAN settings.

If any mismatch is found in native, allowed, or access VLANs, both switches will display device-level alerts in the dashboard. The switches will continue displaying the alert until the VLAN mismatch is resolved. The alert hub will display only one alert for VLAN mismatch between two switches.

Currently, VLAN mismatch detection is supported on Meraki switches in the same organization. VLAN mismatch detection is not supported for other Meraki devices (MR, MX, and others) and non-Meraki devices.

Troubleshooting Steps

Make sure both ports allow the same VLANs. Refer to VLAN Mismatch Alerts for Meraki Switches to learn more about how to correct a VLAN mismatch error.

Guided Troubleshooting Flow

VLAN mismatch troubleshooting flow reduces time to resolution for our customers by easing manual tasks, simplifying the configuration process, and dynamically detecting errors. 

Triggers

When a configuration change is made in the dashboard, but the Meraki device can't download that change. This alert may also be phrased as "Configuration is out of date".

Troubleshooting Steps

Before contacting support, try these options:

• Give the alert at least 5 minutes to resolve naturally. In this time, check to see if any changes to the network are taking hold. For example, change the password on an SSID and see if a phone can associate with the new password (refer to Access Control).
• Try rebooting the device. In some cases, this can resolve a configuration fetch issue.
• If possible, try a different connection to the internet to rule out an upstream network problem.

If the above fails, open a support case for further assistance.

Triggers

Access points have their regulatory body set when they are ordered. As an example, an access point (AP) purchased in the US will have the regulatory domain of the Federal Communications Commission (FCC), dictating which channels can be used on the device.

Troubleshooting Steps

• Be sure the public IP and the order region of the access point match. Check if the management traffic uses a VPN to another country. As a test, avoid using that VPN and see if the problem is resolved.
• If the above options are not possible, contact support to begin an investigation on the next steps.

Triggers

Refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of MR Regulatory Domains (Legacy Version).

Troubleshooting Steps

Refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of MR Regulatory Domains (Legacy Version).

Triggers

Refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of MR Regulatory Domains (Legacy Version).

Troubleshooting Steps

Refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of MR Regulatory Domains (Legacy Version).

Triggers

Refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of MR Regulatory Domains (Legacy Version).

Troubleshooting Steps

Refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of MR Regulatory Domains (Legacy Version).

Triggers

The count of dynamically learned routes crosses the limit a switch can support.

Troubleshooting Steps

Make sure the count of routes advertised by the Open Shortest Path First (OSPF) neighbors is within the limit of the Cisco Meraki switch. For more information on the number of routes supported by Cisco Meraki switches, refer to the "Supported Models "section of MS Layer 3 Switching and Routing.

Triggers

A switch is part of a stack configuration, but that stack configuration does not match what is actually physically connected.

Troubleshooting Steps

If the dashboard stack configuration is correct, make sure the physical stack setup matches the dashboard configuration and vice versa. Refer to Managing Stack Members and Physical Switch Stack Configuration Steps.

Triggers

A switch has been physically made part of a stack, but the stack has not been configured in the dashboard.

Troubleshooting Steps

If the physical stack is correct, make sure the dashboard stack configuration matches the physical setup (see Switch Stacks).

Triggers

A switch is part of a stack configuration but is not physically part of the stack.

Troubleshooting Steps

Make sure the physical stack matches the dashboard stack configuration (see Switch Stacks).

Triggers

The height information is missing in the AFC database where an AP is installed. This information is needed as the criteria for higher transmit power limits are heavily dependent on the location of the APs and it will be a requirement for the APs to check in to the database with their location.

Troubleshooting Steps

Complete missing height information.

Triggers

Attempts to request information from the AFC database were unsuccessful or a response was not received. If an AP is not able to check in with the AFC database, it will default to using low-power mode transmit power thus limiting the coverage from the AP.

Troubleshooting Steps

Check the AP communication to gateway and check other APs to ensure it is not widespread problem.

Unable to Fetch Configuration

Cannot Connect to the Device via SSH or NETCONF

Device Firmware Mismatch