Dashboard Alerts - Device Health
Overview
This document list all the alerts available under "Device Health" alert category and their triggers and troubleshooting steps. Please refer to network alert hub documentation to learn more.
Power supply offline
Triggers
The alert is triggered if one of the power supplies of the switch is connected but offline or not powered on.
Troubleshooting Steps
-
Make sure both power supplies are receiving power. Check the power outlet to make sure it is providing power.
-
Try reseating the power supply and reboot the device.
- If the issue persists, contact Cisco Meraki support for further troubleshooting steps.
Redundant power system down
Triggers
The alert is triggered if the redundant power system is connected but offline or powered off.
Troubleshooting Steps
- Make sure the redundant power supply is receiving power. Check the power outlet to make sure it is providing power.
- Reseat the connection between the redundant power supply and the switch. Reboot the switch.
- If the issue persists, contact Cisco Meraki support for further troubleshooting steps.
Switch using backup power
Triggers
The alert is triggered when the switch is not using the connected redundant power supply.
Troubleshooting Steps
- Make sure the redundant power supply is receiving power. Check the power outlet to make sure it is providing power.
- Reseat the connection between the redundant power supply and the switch. Reboot the switch.
- If the issue persists, contact Cisco Meraki support for further troubleshooting steps.
Fan failure
Triggers
The alert is triggered if one or more fans are connected but not functioning properly.
Troubleshooting Steps
- Try reseating the fans and reboot the device.
- If the issue persists, contact Cisco Meraki support for further troubleshooting steps.
STP Topology Changes
Triggers
STP change alerts are created whenever a high or very high rate of STP topology change notifications (TCNs) are detected or received on a switch port. TCNs are triggered when a switch detects changes in the topology.
Troubleshooting Steps
While we are working on creating proper troubleshooting steps for this alert here is some useful information.
Historical STP topology changes can be found on the port connectivity bar.
It is important to know that a Cisco Meraki switch port alerts for STP topology change only when it receives TCN BPDUs.
Some of the common root causes of STP topology changes are as follows:
- Port flaps between 2 switches. It can happen if the cable is faulty.
- Delay in sending or receiving BPDUs due to high CPU usage or packet loss.
- STP BPDU conflicts when multiple BPDUs are received within a small window that identifies different sending ports.
This section mentions only a few events as the root cause of the topology change notification, but there can be other root causes. Please work with Cisco Meraki support if you cannot determine the root cause.
CRC Errors Detected
Learn more with this free online training course on the Meraki Learning Hub:
Triggers
There are 2 types of CRC errors:
High CRC errors: A port is sending or receiving a high amount (greater than 100 hits/hour or greater than 1% of traffic) of CRC align errors.
Very high CRC errors: A port is sending or receiving a high amount (greater than 1000 hits/hour or greater than 10% of traffic) of CRC align errors.
Guided Troubleshooting Flow
This feature is designed to reduce troubleshooting effort, make issue resolution more intuitive, and save more time for our customers. Guided CRC troubleshooting flow automates and outlines suggested action items (refer to flow diagram and the short video below) to be performed to resolve CRC error alerts. This tool is designed to help network administrators efficiently and effectively identify the root cause of the CRC error on switch ports and resolve it.
|
|
|
| Configuration Mismatch issue | Cable and other issues |
 |
 |
Note:
-
This feature is in BETA so to report any issues please use the “Give feedback about this alert” located inside the troubleshooting side panel.
Troubleshooting Steps
- Verify there is no duplex configuration mismatch between two neighboring ports.
- Run cable test to verify the cable is healthy or not.
- Verify the switch port is healthy by connecting the end device with the same cable to a known working port. If the issue does not persist then the original switch port is possibly faulty, please contact Meraki support, if persists, move to the next troubleshooting step.
- Verify the end device is healthy by connecting it to the original port using a known working cable bypassing any patch panels. If the issue persists then the end device's NIC card is possibly faulty, if not, move to the next troubleshooting step.
- Verify the copper/fiber transceiver is healthy by installing a known working transceiver on the port. If the issue does not persist then the original copper/fiber transceiver is possibly faulty, if the issue persists, move to the next troubleshooting step.
- If the issue persists after attempting the above steps then the patch panel is possibly faulty or there is electromagnetic interference near the cable.
Beacon Miss
Triggers:
A beacon is a wireless LAN packet that signals the availability and presence of the wireless device. Clients may disassociate or roam to another AP when they miss eight consecutive beacons.
Troubleshooting Steps:
-
Check AP functionality and wiring
-
Check client Wifi device operating correctly
-
Check client wireless drivers
-
Check for environment radio interference
Access point is running in low power mode
Triggers:
AP did not negotiate sufficient PoE parameters for full power operation
Troubleshooting Steps:
Check AP PoE needs and switch specs to make sure switch is providing required PoE level, also check cabling to make sure not running beyond PoE length standards for protocol.
Ethernet Collisions Detected
Triggers:
This alert is triggered on a port if the port is detecting a high amount (greater than 10% of transmitted traffic) of collisions.
Troubleshooting Steps:
Do layer 1 physical inspection of cable, speed/duplex check, and path assessment from switch to client to check for anomalies
Packet Fragments Detected
Triggers:
This alert is triggered on a port if the port is sending or receiving a high amount (greater than 1000 hits/hour or greater than 10% of traffic) of fragments.
Troubleshooting Steps:
Do layer 1 physical inspection of cable and path assessment from switch to client to check for anomalies
Jabbers Errors Detected
Triggers:
This alert is triggered on a port if the port is sending or receiving a high amount (greater than 1000 hits/hour) of Jabbers.
Troubleshooting Steps:
Do layer 1 physical inspection of cable and path assessment from switch to client to check for anomalies
Oversized or Undersized Packets Detected
Triggers:
This alert is triggered on a port if the port is sending or receiving a high amount (greater than 10% of traffic) of Oversized or Undersized packets.
Troubleshooting Steps:
Check network MTU settings to make sure consistent throughout path
SecurePort Authentication (In progress, Failure, Timeout)
Triggers:
Various stages of SecurePort Authentication
Troubleshooting Steps:
Troubleshoot based on stage of alert, check that LLDP is enabled on network and MR/MS running minimum required firmware
BPDU guard activated, STP discarding packets
Triggers:
When a BPDU Guard enabled port receives a BPDU from the connected device, the port is disabled and its state is changed to Errdisable state. The switch will also start discarding packets received on the port
Troubleshooting Steps:
Remove the offending device sending the BPDU and check topology configuration
Stopped receiving BPDUs with loop guard enabled
Triggers:
If a non-designated port with Loop Guard enabled stops receiving BPDUs, it will transition into a loop-inconsistent blocking state. In this state, the port will still process BPDUs but will not learn MAC addresses or forward traffic, thereby preventing a loop from forming.
Troubleshooting Steps:
Check switch topology and STP configuration
Root guard activated, STP discarding packets
Triggers:
Root guard is a feature in Spanning Tree Protocol (STP) that prevents a switch port from becoming a root port if it receives superior Bridge Protocol Data Units (BPDUs) from another switch. When root guard is enabled on a port, it discards incoming BPDUs from switches that claim to be the root bridge.
Troubleshooting Steps:
Check switch topology, STP configuration, specifically root bridge settings
Cloud archive upload failure
Triggers:
MV devices having issues uploading to cloud
Troubleshooting Steps:
Check network settings for MV, also check firewall settings
Potential Hardware Problem
Triggers:
The error message, "Potential hardware problem detected. Please contact support." is presented when the camera cannot mount its storage.
Troubleshooting Steps:
Please open a support case.
Potential ntp problem
Triggers:
Issues reaching/talking to NTP servers
Troubleshooting Steps:
Check network settings, DHCP options, ping NTP servers
-
Confirm an NTP server is configured on the switch in the running configuration (ntp server {address}).
-
Confirm the NTP server is accessible. Additional troubleshooting steps are available in the NTP Troubleshooting and Debugging Guide.
One or more members of this stack are unhealthy
Triggers:
A member of a switch stack has experienced an anomaly that indicates an unhealthy status
Troubleshooting Steps:
Determine which stack member is alerting and troubleshoot deeper or replace.
Port not forwarding traffic due to access policy
Triggers:
A configured access policy is limiting or denying traffic
Troubleshooting Steps:
Check access policies and configure as needed
Sensor tampering
Triggers:
When an MT20 detects a tamper state
Troubleshooting Steps:
If your sensor is alerting for Device Tampering, ensure that:
-
You are using the included magnet bar
-
The gap between the MT20 and the magnet bar does not fall below 5 millimeters (0.5 cm)
Note that this can also trigger when an unknown magnet strength is detected potentially indicating physical tampering.
NETCONF process is in an abnormal state
Triggers:
Netconf-yang process has experienced an anomaly
Troubleshooting Steps:
-
Netconf is a protocol used within the encrypted tunnel to communicate between the switch and cloud.
-
If this error appears, additional information may be provided in the syslog (show log) of the switch regarding resolution steps.
-
After resolving based on any log information shown, the Netconf process should be restarted (no netconf-yang; netconf-yang in the running configuration).
-
Any other processes requiring Netconf will be unavailable while Netconf restarts.
-
-
The error may take up to an hour to resolve in Dashboard following the process restart.
PoE port was denied power
Triggers:
This alert is triggered on a port if the port is waiting for power
Troubleshooting Steps:
May indicate that currently there is not enough available power for the port and connected device.
PoE overload
Triggers:
This alert is triggered when a connected device is consuming more power than the maximum limit configured or specified in the 802.3at/af standards
Troubleshooting Steps:
Check support PoE standards of switch and over PoE budget in use
Detected an unsupported cable type
Triggers:
Incorrect probe connected to Sensor
Troubleshooting Steps:
Check probe, replace if necessary with correct probe
Device reboots
Triggers:
Dashboard detected large number of uninitiated reboots
Troubleshooting Steps:
Check for power issues, possibly make sure a UPS or power conditioner is present
Device rebooted due to no_xmit_mon
Triggers:
Can’t transmit packets for a 1 minute. mon0, mon1, and mon2 are specific interfaces on a device. These interfaces relate to radios on the device. For example, no_xmit_mon0 means that we rebooted because we could not transmit on the "mon" (monitor) interface of radio 0. We reboot in this case, because it is likely that the Virtual AP interfaces (such as apr0v0, apr0v1,for SSIDs 1 and 2) were also unable to transmit.
Troubleshooting Steps:
Indicates issues with monitoring interfaces on radios, check AP health and troubleshoot as necessary
Device panic reboots
Triggers:
Device reboots have reached a level that is extremely critical to the operation of the platform.
Troubleshooting Steps:
This could be due to a failing power supply or a configuration issue on the network like a loop with an unmanaged switch.
1 Gigabit link failed, speed downshifted
Triggers:
Ethernet negotiation failed for 1000Base-T,
Troubleshooting Steps:
Check cable and auto negotiation settings
Received BPDUs from multiple senders
Triggers:
This alert is triggered at the port level when the following conditions are met for a switch port:
-
The port is in RSTP (not legacy STP) mode
-
The port is full duplex
-
Multiple BPDUs are received within a small window that identify different sending ports
-
The port link state has not changed between receiving such BPDUs
Probe disconnected
Triggers:
Temperature probe from MT11 is disconnected.
Troubleshooting Steps:
Ensure the probe connection is secure and remains dry. Reconnect the cable to clear the alert. If the alert persists, contact Meraki Support.
UDLD TX/RX loop detection
Triggers:
This error state usually only exists if one fiber of the pair no longer transmits due to optics error or cable error.
Troubleshooting Steps:
Check replace fiber interconnect and or SFP
UDLD neighbor mismatch detection
Triggers:
This condition is present when Port-A on Switch-A receives a frame from a port other than that with which it already formed a UDLD bi-directional relationship.
Troubleshooting Steps:
Since UDLD errors indicate physical layer faults, it is appropriate to troubleshoot at the physical layer. When UDLD error messages are encountered, consider these questions:
-
Does the error persist if the Small Form-Factor Pluggable Transceiver (SFP) is replaced?
-
Does the error persist if the cable is replaced?
-
Does the error persist if the connection is moved to a different physical port on the switch?
UDLD unidirectional link detection
Triggers:
A port should receive its own device and port ID information from its neighbor if the link is bi-directional. If a port does not receive information about its own device and port ID from its neighbor, the link is considered to be unidirectional. This can occur when the link is up on both sides, but one side is not receiving packets, or when wiring mistakes occur, causing the transmit and receive wires to not be connected to the same ports on both ends of a link.
Troubleshooting Steps:
UDLD frames can be confirmed by taking a packet capture on each end of the link to ensure that they’re being sent/received:
-
Dashboard Capture Filter - ether host 01:00:0c:cc:cc:cc
-
Wireshark Display Filter - udld
Water leak cable disconnected
Triggers:
Water leak cable from MT12 is disconnected
Troubleshooting Steps:
Ensure the probe connection is secure and remains dry. Reconnect the cable to clear the alert. If the alert persists, contact Meraki Support.
Water leak cable connected
Triggers:
Water leak cable from MT12 is connected.
Troubleshooting Steps:
Informational alert only. No troubleshooting required.
WLC redundancy has member in active recovery
Triggers:
This alert is triggered if an HA SSO wireless controller chassis is in recovery mode.
Troubleshooting Steps:
Please refer to Monitoring Catalyst Wireless 9800 Controllers to learn how to remediate this error.
WLC redundancy has member in standby recovery
Triggers:
This alert is triggered if an HA SSO wireless controller chassis is in recovery mode.
Troubleshooting Steps:
Please refer to Monitoring Catalyst Wireless 9800 Controllers to learn how to remediate this error.
WLC redundancy standby member offline
Triggers:
This alert is triggered if the standby HA SSO wireless controller chassis is NOT in STANDBY HOT state.
Troubleshooting Steps:
Please refer to Monitoring Catalyst Wireless 9800 Controllers to learn how to remediate this error.
WLC redundancy failover occurred in past day
Triggers:
This alert is triggered when the an HA SSO wireless controller chassis failover has occurred in the last 24 hours.
Troubleshooting Steps:
Please refer to Monitoring Catalyst Wireless 9800 Controllers to learn how to remediate this error.