Dashboard Alerts - Insight

Triggers

If no root cause for an issue has been found, the alert will show as Performance Degradation.

Troubleshooting Steps

Web App Health goodput or response time data for a particular application and network drops below whatever threshold the user has set (either smart thresholds or manually set).

Triggers

• Goodput on the WAN for passively collected flows per application and network drops below whatever threshold the user has set (either smart thresholds or manually set).
• Uplink usage is less than 80% of the bandwidth defined on SD-WAN & Traffic Shaping.
• Goodput of actively collected ICMP ping data for the alerting uplink drops below 2.5KB.

Troubleshooting Steps

• Check to see if you have configured the bandwidth on SD-WAN & Traffic Shaping.
• Check bandwidth restrictions by referring to Global Bandwidth Limit Considerations.
• Look at the event logs to notice if there are continuous VPN registry changes (Refer to Meraki Auto VPN - Configuration and Troubleshooting).
• Look at the network status on the WAN Health page or the Uplink tab on Appliance status page to check loss and latency reported from ping data.
• Look at the Meraki Insight Web App Health drill down page to check passive goodput.

Triggers

• Goodput on the WAN for passively collected flows per application and network drops below whatever threshold the user has set (either smart thresholds or manually set).
• The flow goes over VPN and there is latency detected on the WAN for this application only. There is a check for other major problems/outages.

Troubleshooting Steps

• Check the WAN Health portfolio in Meraki Insight to see if the overall network is having high latency.
• Check the VPN Status page to see usage information for any bandwidth throttling.

Triggers

• Goodput on the WAN for passively collected flows per application and network drops below whatever threshold the user has set (either smart thresholds or manually set).
• If the uplink usage is greater than 80% (as configured on SD-WAN & Traffic Shaping) then there is high confidence that the application performance is suffering due to the uplink being saturated.

Troubleshooting Steps

• Check to see if you have configured the bandwidth on SD-WAN & Traffic Shaping.
• Check bandwidth restrictions by referring to Global Bandwidth Limit onsiderations.
• Check WAN Health page to see if the given network shows a high usage alert on the availability graph.
• If a certain user is utilizing more than the required bandwidth, refer to Creating and Applying Group Policies to add policies to restrict or limit bandwidth utilized.

Triggers

When there are unexpected numbers of VRRP transition events on the event log for primary and spare MX that can hamper the flows of the application to be interrupted or cause loss. There is also a check to see if the WAN overall is seeing a loss:

• If yes, then this alert is triggered with high confidence that the reason for the issue is due to VRRP transitions and high WAN loss.
• If no, then this alert is triggered with medium confidence that this might only be due to the VRRP transitions.

Troubleshooting Steps

Check the Connection Monitoring for MX by referring to MX VRRP Transitions.

Triggers

• Goodput on the WAN for passively collected flows per application and network drops below whatever threshold the user has set (either smart thresholds or manually set).
• The app configured on Web App Health has a traffic shaping rule with a bandwidth limit applied to it under the SD-WAN & Traffic Shaping.
• Usage of the app is >80% of the configured bandwidth limit as configured by traffic shaping.

Troubleshooting Steps

• Check the traffic shaping rule section under SD-WAN & Traffic Shaping to increase the limit on the bandwidth provided to the application.
• Refer to Traffic and Bandwidth Shaping for more information on limitations that can be applied to application traffic.

Triggers

There is poor performance detected between the SSID and client connection due to suboptimal AP selection. Client devices choose which AP to connect to. Meraki APs cannot force a client to choose a particular AP. 

Troubleshooting Steps

• Try to force the client to re-select a more optimal AP by having the client disassociate and reassociate.
• To learn more about setting to avoid sticky client issues, refer to Wireless Issue Resolution Guide.

Triggers

A MAC flap event is triggered when a MAC address is learned 3 times or more on 2 or more different ports within 10 seconds. Sometimes these events can become noisy due to wireless roaming, which is expected. Due to this noise, it is hard to tell which events are expected vs unexpected. Networks with APs in bridge mode are susceptible to this issue.

It is difficult to separate and identify unexpected events. To solve this problem, Cisco Meraki built a machine-learning algorithm to detect these unexpected events more accurately.

The machine learning algorithm looks at the past 35 days of hourly event counts and creates hourly thresholds for the next 7 days. It monitors the real-time hourly event counts, and if the real-time hourly count breaches the expected threshold, it will create an alert - MAC flap anomaly detected on “SWITCHNAME” from “TIMESTAMP”.

The alert will only resolve itself if the algorithm detects the real-time hourly counts goes below the threshold, which happens at the top of the hour from the time of anomaly detection, otherwise, it will persist.

Troubleshooting Steps

1. Make sure there is no loop in the network. 
2. Follow the High-Density Wi-Fi Deployment Guidelines to make sure the network meets the optimal network criteria. 
3. Sometimes a bad WiFi adapter on a client device can cause frequent connection failure and cause frequent roaming.

Triggers

Large number of clients experiencing issues with the ARP protocol/gateway, gateway timeout, excessive ARP requests.

Troubleshooting Steps

• Check that the gateway is online and reachable.
• Make sure that there is no congestion in the network.

Triggers

A DFS event pattern has been recognized on a channel in use on the wireless network.

Troubleshooting Steps

No manual steps as remediation is a regulated action. APs in a network will switch to the next best channel (disconnecting all clients on DFS channels) as per regulation requirements, which would be a non-DFS channel and then a DFS channel.

Triggers

When the variance in latency between tests for a specified WAN connection is higher than configured during the specified window to the specified VoIP server.

Causes:

• Network congestion on WAN or LAN links causing variable packet delays.

• Packet drops due to buffer or interface congestion.

• Improper QoS configuration leading to lack of prioritization for voice traffic.

• Bandwidth limitations or oversubscription on WAN links.

• Long or inconsistent network delay affecting packet timing.

• Physical layer issues such as faulty cables or duplex mismatches.

• Codec or DSP problems affecting voice packet processing.

• Lack of packet fragmentation/interleaving on low-speed links.

Troubleshooting Steps

• Monitor WAN and Network Health:

  • Check for interface drops, buffer drops, or congestion on devices in the call path.

  • Use Meraki Insight WAN jitter alerts to identify uplink saturation or ISP issues.

  • Verify bandwidth availability and ensure no oversubscription.

• Verify QoS Settings:

  • Confirm voice traffic is prioritized using appropriate queuing and traffic shaping.

  • Adjust traffic shaping rules if bandwidth limits are causing saturation.

• Measure Delay and Jitter:

  • Use Cisco IP SLA or Meraki Insight tools to measure jitter and delay.

  • Ensure one-way delay is below 150 ms and jitter is stable without spikes.

• Check Codec and DSP Configuration:

  • Test calls with different codecs and enable/disable Voice Activity Detection (VAD) to isolate issues.

  • Hard code dial-peers if codec negotiation problems are suspected.

• Inspect Physical Layer:

  • Replace faulty cables, connectors, or SFPs.

  • Verify interface duplex and speed settings are consistent.

• Use Diagnostic Commands and Tools:

  • Use show call active voice on Cisco devices to monitor jitter and packet loss.

  • Review debug logs for call setup and codec negotiation issues.

Triggers

Low VoIP MOS (Mean Opinion Score) in Meraki Insight indicates poor voice call quality as perceived by users, typically caused by network or WAN uplink issues affecting VoIP traffic.

Causes:

• WAN uplink issues such as high latency, jitter, or packet loss impacting voice traffic.

• Network congestion leading to degraded voice packet delivery.

• Traffic shaping or bandwidth limits restricting VoIP traffic throughput.

• ISP or VPN issues causing intermittent connectivity or performance degradation.

• Physical layer problems like faulty cables or interfaces.

• Suboptimal routing or VPN failover events causing packet delay or loss.

Troubleshooting Steps

• Review VoIP Health Metrics:

  • Check MOS, loss, latency, and jitter statistics on the Insight > Monitor > VoIP Health dashboard.

  • Identify uplinks with MOS scores below 3.5, indicating moderate to bad call quality.

• Check WAN Health:

  • Investigate WAN uplinks for packet loss, latency, or jitter issues using the WAN Health page.

  • Look for uplink saturation or high usage that could affect voice traffic.

• Verify Traffic Shaping and Bandwidth Settings:

  • Ensure SD-WAN & Traffic Shaping policies are correctly configured and not limiting VoIP traffic.

  • Adjust bandwidth limits or prioritize voice traffic as needed.

• Inspect Physical Layer:

  • Verify cables, connectors, and SFPs for faults or loose connections.

  • Confirm interface duplex and speed settings are correct.

• Check VPN and ISP Status:

  • Review VPN status and logs for bandwidth throttling or failover events.

  • Contact ISP to confirm no outages or performance issues.

• Use Traceroute and Hop-by-Hop Analysis:

  • Utilize the VoIP Health traceroute tool to analyze each hop to the VoIP server.

  • Identify any hops with high latency or packet loss contributing to low MOS.

• Enable Best Effort Monitoring (BEM) if Needed:

  • If VoIP servers do not respond to ICMP, enable BEM to monitor the nearest hop for performance metrics.

• Client and AP Considerations:

  • Ensure clients are connected to optimal APs to avoid wireless issues affecting VoIP quality.

Triggers

High VoIP Packet Loss in Meraki Insight indicates that a significant portion of voice packets are being lost during transmission, which can severely degrade call quality.

Common Causes:

• Network congestion or link saturation causing dropped packets.

• Duplex mismatch between network devices leading to packet loss.

• Faulty or loose cables and connectors affecting signal integrity.

• Firewall or security devices blocking or filtering VoIP traffic.

• Issues on the ISP side or WAN uplink problems.

• Wireless interference or poor wireless signal quality for VoIP clients.

Troubleshooting Steps

• Identify Packet Loss Location:

  • Use tools like continuous ping, traceroute, or MTR from clients to the VoIP server or public IPs to determine where packet loss begins.

  • Check if packet loss occurs at the wireless access point, switch, router, or WAN uplink.

  • For Cisco Meraki devices, ping the first switch or WAN appliance in the path via the Dashboard (e.g., switch.meraki.com or wired.meraki.com).

• Check Duplex and Speed Settings:

  • Ensure both ends of network links (AP to switch, switch to router) have matching speed and duplex settings.

  • Ideally, set both ends to auto-negotiate to avoid mismatches.

• Inspect Physical Layer:

  • Verify cables are properly seated, undamaged, and correctly terminated.

  • Replace suspect cables and clean ports to eliminate loose connections or debris.

• Monitor WAN Health:

  • Use Meraki Dashboard WAN Health page to check for packet loss, latency, and jitter on WAN uplinks.

  • Confirm no ISP issues or VPN failover events are causing packet loss.

• Review Traffic Shaping and Firewall Rules:

  • Check SD-WAN & Traffic Shaping policies to ensure VoIP traffic is prioritized and not limited.

  • Verify firewall settings are not blocking or filtering VoIP packets.

• Wireless Considerations:

  • If VoIP clients are wireless, check for wireless packet loss or interference.

  • Use Meraki wireless troubleshooting tools to assess AP and client connectivity quality.

• Use Meraki Insight VoIP Health Metrics:

  • Review per-hop loss, latency, and jitter metrics in the VoIP Health dashboard to pinpoint problematic network segments.

Triggers

High WAN Latency in Meraki Insight indicates that the network is experiencing increased delay on the WAN uplink, which can degrade application performance and user experience.

Common Causes:

• ISP or WAN provider issues causing increased latency.

• WAN uplink congestion or saturation leading to delays.

• VPN-related latency when traffic is routed over VPN tunnels.

• Traffic shaping or bandwidth limits restricting throughput and causing latency.

• Network device issues such as VRRP failover events causing temporary latency spikes.

• Suboptimal routing or network path issues between the MX appliance and the destination.

Troubleshooting Steps

• Check WAN Health Metrics:

  • Use the Meraki Dashboard WAN Health page to monitor latency, loss, and jitter on WAN uplinks.

  • Confirm if latency is consistently high or intermittent.

• Verify ISP and Bandwidth Settings:

  • Ensure bandwidth is correctly configured under SD-WAN & Traffic Shaping.

  • Check for any bandwidth restrictions or global limits that might throttle traffic.

  • Review event logs for VPN registry changes or failover events that could impact latency.

• Assess Uplink Saturation:

  • Determine if uplink usage exceeds 80% of configured bandwidth, which can cause latency.

  • If saturation is detected, consider applying group policies to limit bandwidth for heavy users or increase bandwidth allocation.

• Investigate VPN Latency:

  • If traffic is routed over VPN, check the VPN Status page for bandwidth throttling or issues.

  • Compare latency on VPN versus direct WAN paths.

• Review VRRP Warm Spare Failover Events:

  • Frequent VRRP transitions can cause temporary latency spikes.

  • Check MX event logs for VRRP transitions and correlate with latency alerts.

• Evaluate Traffic Shaping Rules:

  • Confirm if traffic shaping rules are limiting bandwidth for affected applications.

  • Adjust limits if necessary to reduce latency impact.

• Check Application Performance:

  • Use Meraki Insight Web App Health to determine if latency is affecting specific applications.

  • Identify if the issue is on the WAN side or related to server or LAN performance.

• Client and Network Path Considerations:

  • For wireless clients, ensure optimal AP selection to avoid suboptimal connections causing latency.

  • Use traceroute or path analysis tools to identify routing issues.

Triggers

High WAN Packet Loss in Meraki Insight indicates that packets are being lost on the WAN uplink, which can severely impact application performance and user experience.

Common Causes:

• ISP or WAN provider issues causing packet drops.

• Physical layer problems such as faulty cables or ports.

• Network congestion or uplink saturation leading to dropped packets.

• Routing issues or faulty network devices along the path.

• VPN or tunneling issues causing packet loss within encrypted tunnels.

• VRRP failover events causing temporary packet loss.

• Traffic shaping or bandwidth limits restricting throughput.

Troubleshooting Steps

• Monitor Packet Loss via Meraki Dashboard:

  • Use the MX WAN Health page under Security & SD-WAN > Monitor > Appliance Status > Uplink to view packet loss graphs sourced from constant ICMP pings.

  • Configure the destination IP for uplink statistics under Security & SD-WAN > Configure > SD-WAN & Traffic Shaping > Uplink statistics to monitor relevant endpoints.

• Isolate Where Packet Loss Occurs:

  • Use tracert (Windows) or traceroute (Linux/macOS) to identify the hop where packet loss begins.

  • Run multiple tests to confirm consistent loss at a particular hop.

  • Use tools like MTR for continuous tracing and percentage loss per hop to pinpoint problematic devices or links.

• Check Physical and Layer 1 Connectivity:

  • Verify cables, ports, and power to devices.

  • Run cable tests if supported.

  • Check device LEDs for error indications.

• Perform Packet Captures:

  • Take simultaneous packet captures on the LAN and WAN interfaces of the MX appliance.

  • Filter for ICMP traffic to verify if packets are forwarded correctly from LAN to WAN.

  • If packets are forwarded correctly, the issue likely lies with the ISP or upstream network.

• Review Bandwidth and Traffic Shaping Settings:

  • Confirm bandwidth settings under SD-WAN & Traffic Shaping are accurate.

  • Check for any global bandwidth limits or traffic shaping rules that might cause packet drops.

• Check for VRRP Failover Events:

  • Frequent VRRP transitions can cause packet loss.

  • Review MX event logs for VRRP transitions and correlate with packet loss timing.

• Test from Multiple Clients and Locations:

  • To rule out client-specific issues, test packet loss from different clients and network segments.

• Engage ISP if Loss is Upstream:

  • If packet loss is confirmed beyond the MX appliance, contact the ISP with evidence from traceroutes and packet captures.

Triggers

Meraki Insight indicates that the network usage on a WAN uplink exceeds a specified threshold, typically 80% or more of the configured bandwidth limit. This can lead to application performance degradation due to uplink saturation.

Causes:

• WAN uplink bandwidth utilization exceeds 80% of the configured limit.

• Bandwidth limits not properly configured in SD-WAN & Traffic Shaping settings.

• Heavy traffic from specific users or applications consuming excessive bandwidth.

• Traffic shaping rules limiting bandwidth for certain applications.

• Network congestion or spikes in traffic usage.

Troubleshooting Steps

• Verify Bandwidth Configuration:

  • Ensure the ISP-provided bandwidth limits are correctly set under Security & SD-WAN > Configure > SD-WAN & Traffic Shaping > Uplink Configuration.
  • Incorrect or missing bandwidth settings can cause inaccurate high usage alerts.

• Check WAN Health Page:

  • Review the WAN Health page in Meraki Dashboard to identify uplinks marked with high usage.
  • Look for usage spikes and patterns over different time windows (e.g., 15 minutes vs. 1 hour) to understand if usage is sustained or intermittent.

• Identify High Bandwidth Consumers:

  • Use the WAN Health metrics to find top clients and top applications consuming bandwidth.
  • Consider applying group policies to limit or shape bandwidth for heavy users or non-critical applications.

• Review Traffic Shaping Rules:

  • Check if traffic shaping rules are applied that might limit bandwidth for certain applications.
  • Adjust limits if necessary under SD-WAN & Traffic Shaping to better accommodate traffic demands.

• Monitor for Network Congestion:

  • Confirm there is no congestion on the LAN or WAN side causing bottlenecks.
  • Investigate any network events or changes that coincide with high usage alerts.

• Consider Uplink Saturation Impact:

  • If uplink usage is consistently above 80%, application performance may degrade.
  • Plan for bandwidth upgrades or implement traffic prioritization to mitigate impact.

• Additional Resources:

  • Refer to the Meraki documentation on Global Bandwidth Limit Considerations and Traffic and Bandwidth Shaping for detailed guidance.

Triggers

Triggered when there is a change detected in the status of a WAN uplink. This can be due to link failures, flapping, or failover events between primary and secondary WAN connections. The alert indicates that the WAN connectivity state has changed, which may impact application performance or network availability.

Troubleshooting Steps

• Verify the Alert in Meraki Dashboard:

  • Check the alert under Network-wide > Event Log to confirm the WAN status change event.

• Check Uplink Status:

  • Navigate to Security & SD-WAN > Appliance Status to view the current status of WAN uplinks.

  • Identify if the primary uplink has failed or if there has been a failover to the secondary uplink.

  • Look for red indicators under the Connectivity section signaling uplink issues.

• Test Connectivity:

  • Ping the next hop IP address (usually the ISP gateway) to verify connectivity.

  • If pings fail, this suggests an ISP or underlay connectivity issue.

• Review Event Logs for Flapping:

  • Look for frequent WAN link up/down events that may indicate instability or flapping.

  • Continuous flapping can cause intermittent connectivity and trigger the alert.

• Check Bandwidth and Traffic Shaping Settings:

  • Ensure bandwidth limits are correctly configured under SD-WAN & Traffic Shaping.

  • Misconfigured bandwidth can cause performance degradation and false alerts.

• Investigate ISP or Physical Layer Issues:

  • Confirm that the ISP connection is stable and there are no outages.

  • Check physical connections, cables, and upstream devices for faults.

• Monitor WAN Health:

  • Use the WAN Health page to monitor latency, packet loss, and overall WAN performance.

  • Identify if the WAN status change correlates with performance degradation.

• Consider VRRP or High Availability Configurations:

  • If using VRRP warm spare, check for excessive VRRP transitions that may cause WAN status changes.

  • Refer to VRRP troubleshooting guides if applicable.

• Engage ISP Support if Needed:

  • If the issue appears to be with the ISP, contact them to investigate link stability or outages.

Triggers

Triggered when a custom monitored web application reaches a threshold or event that warrants an alert. This alert indicates that the monitored application is experiencing performance issues or outages that may affect end-user experience.

Troubleshooting Steps

• Identify the Affected Application:

  • The alert header dynamically shows the name of the application experiencing the issue.

  • Confirm which web application is triggering the alert.

• Begin Troubleshooting Within the Application Environment:

  • Check the application servers and services for any outages or performance degradation.

  • Verify application logs and health status.

• Check Network Conditions:

  • Ensure there is no network congestion affecting the application traffic.

  • Verify WAN uplink health and latency metrics to rule out network-related causes.

• Review Meraki Insight Web App Health Dashboard:

  • Use the Web App Health feature to monitor application performance metrics such as response time and throughput.

  • Check if thresholds are set appropriately or if Smart Thresholds are enabled for automatic adjustments.

• Investigate End-User Experience:

  • Determine if the issue is isolated to specific clients or widespread.

  • Use Meraki Insight to analyze the path from end clients to the MX appliance and from MX to the application server.

• Leverage ThousandEyes Integration (if enabled):

  • Use ThousandEyes to gain deeper visibility into third-party dependencies and network paths affecting the application.

  • Identify if the problem lies within the network, ISP, or the application provider.

• Take Corrective Actions:

  • If the issue is network-related, address WAN health or routing problems.

  • If the issue is application-related, coordinate with application owners or service providers for resolution.

Triggers

Triggered when a tracked application or URL endpoint reaches a threshold indicating that end client devices are starting to experience poor performance or degraded user experience with that application. This alert reflects issues detected along the network path that the application traffic traverses, impacting the end-user experience

Troubleshooting Steps

• Identify the Affected Application or URL Endpoint:

  • Determine which application or URL is triggering the alert to focus troubleshooting efforts.

• Analyze Network Path:

  • Investigate the network path that the application traffic takes from the client device through the MX appliance and WAN uplinks to the application server or cloud service.

  • Look for any network congestion, latency, packet loss, or routing issues that could degrade performance.

• Leverage ThousandEyes Integration:

  • Use the ThousandEyes integration within Meraki Insight to gain enhanced visibility into third-party dependencies and external network paths.

  • ThousandEyes provides active monitoring and synthetic testing to identify whether the problem lies within the local network, ISP, cloud provider, or SaaS application.

• Check WAN and Application Health Metrics:

  • Review WAN health metrics such as latency, packet loss, and jitter.

  • Review application performance metrics including response time and throughput.

• Coordinate with Application Owners or Service Providers:

  • If the issue is outside the local network, collaborate with the application or service provider to resolve the problem.

• Verify Licensing and Firmware Requirements:

  • Ensure the MX device is running firmware version 18.104 or higher and is an MX67 or above model, as these are prerequisites for ThousandEyes integration.

  • Confirm that the appropriate licenses (SD-WAN+, Advanced Security + Meraki Insight) are in place for full functionality.