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

• 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 (see Packet Capture Overview)
    • 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:

1. Open the clients list by navigating to the client page Network-wide > Monitor > Clients.
2. 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

• If the device has had a working static IP, make sure the IP address is still valid.
• Check if a typo or incorrect value was entered while assigning a static IP. 
• Check if the wrong VLAN tag is used for DHCP.
• Perform packet captures to confirm ARP requests are replied to, from the upstream gateway. 
• Switch to DHCP. The error message can 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. Remember, 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 article). This alert only applies to Meraki Switches. 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 the Switch Settings article.

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 belong to Meraki switches 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. But 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. Please refer to VLAN Mismatch Alerts for Meraki Switches page 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

This alert is shown 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 go away 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, please contact support to begin an investigation of the next steps.

Triggers

This alert is triggered when 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 the MS Layer 3 Switching and Routing article.

Triggers

This alert is triggered if 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 please make sure the physical stack setup matches the dashboard configuration and vice versa. Please refer to Managing Stack Members and Physical Switch Stack Configuration Steps of the "Switch Stacks" article. 

Triggers

This alert is triggered if 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 article).

Triggers

This alert is triggered if 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 article).

Triggers

Height information 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 the database with their location.

Troubleshooting Steps

Complete missing 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 the AFC database it will default to using Low-power mode transmit power thus limiting the coverage from the AP.

Troubleshooting Steps

Check AP communication to gateway and check other APs to ensure not widespread problem

Unable to fetch configuration

Cannot connect to the device via ssh or netconf

 This is a Cloud monitoring for Catalyst error.

Device firmware mismatch