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 and 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.

Troubleshooting Steps

Investigate as deemed necessary.

Triggers

When the MOS score to a specified VoIP server for a specified WAN connection is lower for the specified window of time.

Troubleshooting Steps

Investigate as deemed necessary.

Triggers

When a configured WAN uplink has packet loss that surpasses the configured loss rate over the configured period of time when testing to the configured VoIP server.

Troubleshooting Steps

Investigate as deemed necessary.

Triggers

When a configured WAN uplink has packet latency that surpasses the configured latency over the configured period of time.

Troubleshooting Steps

Investigate as deemed necessary.

Triggers

When a configured WAN uplink has packet loss that surpasses the configured loss rate over the configured period of time.

Troubleshooting Steps

Investigate as deemed necessary.

Triggers

When network usage exceeds the specified data usage over the specified period of time.

Troubleshooting Steps

Investigate the end devices that caused this higher utilization during the period.

Triggers

When the configured WAN connection has been unplugged or is not marked as a valid uplink.

Troubleshooting Steps

If this is not expected, then investigate the WAN connection/s that alerted.

Triggers

When a custom monitored application triggers a threshold/event that is deemed necessary to alert.

Troubleshooting Steps

Begin troubleshooting within application environment.