- 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.
Uplink IP Address in Conflict with Another Device
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.
Bad IP Assignment Configuration
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.
- 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.
Device(s) VLAN Mismatch
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.
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.
Port(s) VLAN Mismatch
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.
Easing Manual Tasks
Guided VLAN mismatch troubleshooting flow displays switches' current configuration and allows administrators to fix the issue from the troubleshooting panel without needing to navigate to different pages on the dashboard.
Simplifying the Configuration Process
This feature allows configuring all the settings on the alert hub and in some cases, the feature also displays suggested configurations derived from the configuration of the two switches alerting on VLAN mismatch. Users can apply these suggested settings by selecting the Accept suggestion button.
Note: Suggested configurations account for safety and security to make sure the suggested configuration does not cause any disruption for connected devices after applying it. Carefully review the suggestions and make sure it meets your organization’s security requirements.
Dynamic Error Detection
The feature auto detects and warns users if the new configuration is incorrect before saving the new configuration on the widget. The warnings make issue resolution more intuitive.
The logic behind VLAN mismatch troubleshooting flow suggested fix:
Outdated/Unreachable Configuration
Triggers
This alert is shown when a configuration change is made in the dashboard, but the Meraki device can't download that change.
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.
Regulatory Domain Mismatch
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.
Country/Region Mismatch
For more information on how this alert is triggered and how to resolve the issue, refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of the MR Regulatory Domains (Legacy Version) article.
Country Detection Mismatch
For more information on how this alert is triggered and how to resolve the issue, refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of the MR Regulatory Domains (Legacy Version) article.
Manual Country Mismatch
For more information on how this alert is triggered and how to resolve the issue, refer to the "Using Geo-IP to Automatically Update Regulatory Domain" section of the MR Regulatory Domains (Legacy Version) article.
Switch Received High OSPF Routes
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.
Misconfigured Switch
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.
Unconfigured Switch
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).
Switch Not Connected to Stack
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).
AFC missing height configuration
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
AFC request or response unsuccessful
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
Triggers
Troubleshooting Steps
Follow the same steps suggested on the section Meraki Cloud Communication Issues.
Configuration is out of date
Triggers
A stale config that has not/can not update
Troubleshooting Steps
Follow the same steps suggested on the section Meraki Cloud Communication Issues.
Cannot connect to the device via ssh or netconf
This is a Cloud monitoring for Catalyst error.
Triggers
Dashbboard is unable to perform NETCONF operations on the wireless controller through the Meraki tunnel, and the Meraki tunnel interfaces are UP.
Dashbboard is unable to access the wireless controller via SSH through the Meraki tunnel, and the Meraki tunnel interfaces are UP.
Troubleshooting Steps
Contact Meraki support for further troubleshooting.
Device firmware mismatch
Triggers
When software updates (or firmware upgrades) occur, not all of them go smoothly. If a device fails to upgrade, the dashboard will notice the difference in the version set for the device versus what version is actually installed and running.
Troubleshooting Steps
- Wait 30 minutes. Sometimes a firmware download can take a while on a slow connection, and if it fails when the speeds are low it can take even longer.
- Reboot the hardware. This will reset any wait period before trying the software update again.
- If waiting and rebooting the hardware do not resolve the error message, please contact support in the app by opening a case.
Host overflow
Triggers
This alert is triggered if the current number of routed clients exceeds the maximum routable client limit for the specific switch model.
Refer to this section for details on the maximum routable client limit per switch model.
Line VTY configuration issue
This is a Cloud monitoring for Catalyst error.
Triggers
The wireless controller must have 4 unused consecutive VTY slots. These VTY lines will be provisioned and secured for only the dashboard to access the Controller on these lines
