Dashboard Alerts - Configuration Issues
Overview
These are the Configuration Issues alerts, their triggers, and troubleshooting steps indicated by the alerts. Please refer to the Alerts article to learn more.
Misconfigured DNS
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.
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.
- Take a packet capture on an upstream device to see what traffic the device is sending and receiving (see Packet Capture Overview)
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
CCD found unexpected config change
Triggers
CCD stands for Config Change Detector, which is the system used to differentiate between good config changes (user initiated by clicking Save) from bad config changes (code changing config). There are expected code generated changes, such as scheduling turning on/off an SSID or port, but for the most part code should not be causing changes to configs. There is more behind the scenes, options can be whitelisted to bypass CCD, but these are typically new, unreleased or gated features.
Troubleshooting Steps
-
Encourage the customer to not press the Save button. This will prevent the code generated change from going through. (MS-1686 has an example of what could happen)
-
Find the relevant CCD error(s)
-
Run custom query 9878. You’ll need the node_id which can be found on the admin tab of the affected node.
-
Look for a recent entry that matches your network and node, note the same muleable_id may appear multiple times as the query is looking for any in the last day.
-
Take the muleable_id and append it in place of <muleable_id> in the URL: https://dashboard.meraki.com/mule/muleables/unexpected_config_changes#id=<muleable_id>
-
-
Mule with the data collected from step 2.3.
Unable to fetch configuration
Triggers
Configuration is out of date
Triggers
A stale config that has not/can not update
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.
Invalid config
Triggers
Invalid configs are detected by the Config Validator, a system that detects if a blank value or otherwise inappropriate value is generated for a config option; for example, IPv4 value is expected for a given config option but it was passed an IPv6 value instead. This should help to prevent situations such as DASH-8100.
Troubleshooting Steps
-
Check for validation problems under the Admin tab of the node (Config fetch failed reason) and consult Configuration Fetch Validation and Troubleshooting if present.
-
Check for badly written ECOs. This is the primary cause of invalid config alerts per Eng.
-
Find the relevant App Error(s)
-
Run custom query 9994 using the affected node's MAC address.
-
Take the muleable_id and append it in place of <muleable_id> in the URL below:
-
-
https://dashboard.meraki.com/mule/mu...app_errors#id=<muleable_id>
-
If there are no ECOs, or all ECOs are appropriately formatted, Mule it.
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
Troubleshooting Steps
Please refer to Troubleshooting dashboard connectivity to Catalyst 9800 wireless controllers to learn how to remediate this error.
SISF based device tracking not enabled
Triggers
SISF-Based device tracking is disabled by default.
Troubleshooting Steps
You can enable it by defining a device tracking policy and attaching the policy to a specific target.
Safe mode active
Triggers:
This alert is triggered when the “Enable Safe Mode” option is enabled on the local status page.
Troubleshooting Steps:
This feature is used to help enable troubleshooting the device and should be turned off when finished.
Missing config options
Triggers
The system is currently blocking serving the bad config to this device. Missing required fields for a proper config
Troubleshooting Steps
Check and validate all required port config fields.
Device is running an unsupported firmware version
Triggers
Device is running a firmware version that is no longer supported
Troubleshooting Steps
Update firmware to a supported level
Device's gateway mismatch
Triggers
When a device’s gateway does not match the majority of other devices on the network
Troubleshooting Steps
Check and validate gateways settings
Radar detected
Triggers
This is a DFS event and it has detected RADAR in the environment
Troubleshooting Steps
DFS should hop off the channel and select a non radar sharing channel, you can also manually exclude those channels identified so as not to have an issue in the future
Unknown config options
Triggers
These errors will appear as an alert on the device (just like invalid config). The details of the error will indicate which fields were not in the config inventory.
Troubleshooting Steps
VLAN prefix shortage occurred
Triggers
Will be triggered when Prefix Starvation occurs, when the MX detects it does not have enough prefixes from a given WAN or manual configuration to assign a /64 prefix to each IPv6 enabled VLAN
Troubleshooting Steps
Check and validate IPv6 settings
MX is over recommended tunnels
Triggers:
More tunnels have been defined than is recommended for the model
Troubleshooting Steps
See sizing guide to check recommendations https://documentation.meraki.com/MX/MX_Sizing_Information/MX_Sizing_Principles
Apple MDM APNS certificate may have expired
Triggers
Apple MDM certificate needs attention
Troubleshooting Steps
-
Download Meraki CSR file from Organization > MDM page.
-
Log in to Apple's Push Notification Portal with the same Apple ID used to create the current push certificate.
Note: If the Apple ID is not known, review the Apple ID is unknown section below. Not using the original Apple ID (and therefore the original Apple Push certificate) would result in losing management of the previously enrolled devices. -
Find the expiring certificate, and select Renew (do not revoke expiring certificate, nor create a new certificate).
-
Upload CSR downloaded as per Step #1.
-
Download renewed certificate from Apple, and upload into Dashboard.
-
Enter/Confirm Apple ID used to log-in to Apple's push notification portal (highly recommended).
https://documentation.meraki.com/SM/Device_Enrollment/Apple_MDM_Push_Certificate
Apple MDM APNS certificate has expired
Triggers
Apple MDM certificate needs attention
Troubleshooting Steps
-
Download Meraki CSR file from Organization > MDM page.
-
Log in to Apple's Push Notification Portal with the same Apple ID used to create the current push certificate.
Note: If the Apple ID is not known, review the Apple ID is unknown section below. Not using the original Apple ID (and therefore the original Apple Push certificate) would result in losing management of the previously enrolled devices. -
Find the expiring certificate, and select Renew (do not revoke expiring certificate, nor create a new certificate).
-
Upload CSR downloaded as per Step #1.
-
Download renewed certificate from Apple, and upload into Dashboard.
-
Enter/Confirm Apple ID used to log-in to Apple's push notification portal (highly recommended).
https://documentation.meraki.com/SM/Device_Enrollment/Apple_MDM_Push_Certificate
Apple MDM APNS certificate will expire soon
Triggers
Apple MDM certificate needs attention
Troubleshooting Steps
-
Download Meraki CSR file from Organization > MDM page.
-
Log in to Apple's Push Notification Portal with the same Apple ID used to create the current push certificate.
Note: If the Apple ID is not known, review the Apple ID is unknown section below. Not using the original Apple ID (and therefore the original Apple Push certificate) would result in losing management of the previously enrolled devices. -
Find the expiring certificate, and select Renew (do not revoke expiring certificate, nor create a new certificate).
-
Upload CSR downloaded as per Step #1.
-
Download renewed certificate from Apple, and upload into Dashboard.
-
Enter/Confirm Apple ID used to log-in to Apple's push notification portal (highly recommended).
https://documentation.meraki.com/SM/Device_Enrollment/Apple_MDM_Push_Certificate
No IMEI detected
Triggers
Systems manager uses a variety of uniquely identifying values from clients to attempt to determine a device's hardware identity for pairing against it's Systems Manager identity during enrollments or re-enrollments. On mobile devices, this is usually the IMEI (International Mobile station Equipment Identity). This alert triggers when a device’s IMEI cannot be detected.
Troubleshooting Steps
It's recommended to contact the manufacturer or reseller of the device, as a missing IMEI will impact the device's ability to connect to the cellular grid.
Duplicate IMEI detected
Triggers
If Dashboard detects a collision of these values for enrolled or enrolling devices, an alert may be displayed with a link to filter the Clients list down to those devices which are suspect. These values are important for both SM and other software; on mobile devices, these values can affect the device's ability to connect to the cellular grid.
No device identifier detected
Triggers
Systems manager uses a variety of uniquely identifying values from clients to attempt to determine a device's hardware identity for pairing against it's Systems Manager identity during enrollments or re-enrollments. On desktop machines, this is usually the BIOS UUID (Universally Unique Identifier). On mobile devices, this is usually the IMEI (International Mobile station Equipment Identity). This alert triggers when a device’s UUID or IMEI cannot be detected.
Troubleshooting Steps
It's recommended to contact the manufacturer or reseller of the device, as a missing IMEI or UUID will impact the device's ability to connect to the cellular grid.
Duplicate device identifier detected
Triggers
If Dashboard detects a collision of these values for enrolled or enrolling devices, an alert may be displayed with a link to filter the Clients list down to those devices which are suspect. These values are important for both SM and other software; on mobile devices, these values can affect the device's ability to connect to the cellular grid.
WPA3 warning
Triggers
Troubleshooting Steps
Endpoint management - Enrollment Auth Disabled
Triggers
Enrollment Authentication is disabled
Troubleshooting Steps
https://documentation.meraki.com/SM/Device_Enrollment/SM_Enrollment_Authentication
Organization Self Signed SCEP certificate has expired
Triggers
Troubleshooting Steps
To renew your Self Signed SCEP CA Certificate you will simply need to download the CSR file available on the dashboard under Organization > MDM > SCEP CA Certificate Configuration. Once downloaded, you can sign the certificate with your Certificate Authority and re-upload it to the Dashboard. You will see an alert on Dashboard to renew your custom Third Party Signed SCEP cert if it is set to expire soon.
Organization Self Signed SCEP certificate will expire soon
Triggers
Troubleshooting Steps
To renew your Self Signed SCEP CA Certificate you will simply need to download the CSR file available on the dashboard under Organization > MDM > SCEP CA Certificate Configuration. Once downloaded, you can sign the certificate with your Certificate Authority and re-upload it to the Dashboard. You will see an alert on Dashboard to renew your custom Third Party Signed SCEP cert if it is set to expire soon.