Meraki SD-WAN already allows IT admins to very quickly identify how WAN links are performing as well as isolate the root cause of web application degradation to the LAN, WAN, or application server. This is based on real traffic being passed by networks and users.   This new capability further validates and adds confidence to findings from web app health and WAN health with information from ThousandEyes which is independent of traffic passed by networks and users.   In summary, this functionality will provide you with further data to help answer "are my network issues part of an ISP outage?"   Learn more by referring to the Internet Outages KB article.    ... View more

    List all organization-wide alert configurations - GET/organizations/{organizationId}/alerts/profiles Create an organization-wide alert configuration - POST/organizations/{organizationId}/alerts/profiles Update an organization-wide alert config - PUT/organizations/{organizationId}/alerts/profiles/{alertConfigId} Removes an organization-wide alert config - DELETE/organizations/{organizationId}/alerts/profiles/{alertConfigId}   For more information on the above, please visit your Meraki dashboard --> Help --> API docs-->Alert configs  ... View more

Several UI and Backend improvements have been made to include more details for recommendations, links to take users to the relevant dashboard or KB articles, and increased timestamps to retain alerts for a longer duration on the dashboard.       For more information on how to enable the feature please refer to the Root Cause Analysis KB article. The root causes, its triggers, and the recommended next steps can be found on Dashboard Alerts - Insight KB article ... View more

What can I expect? Customers receive an alert notifying them of a problem in the given domains, LAN WAN and Server The email will have a link that will take them to the troubleshooting page of the given network and application and showcase a banner stating the root cause if one has been found.  By clicking the ‘see recommendations’ on the banner, a slide-out panel will open providing details of the issue including: The root cause of the issue The alert generated stating the app problem The confidence in the root cause The evidence that triggered the alert Impact on clients Recommended next steps     Note: The RCA will only run for WAN associated performance issues (for now)  Alerts for the application of interest must be enabled under "Manage Alert" on the Web App Health page in order to receive the RCA.    For more information on how to enable the feature please refer to the Root Cause Analysis KB article. The root causes, its triggers, and the recommended next steps can be found on Dashboard Alerts - Insight KB article ... View more

The new Alert Management page is the portal to manage and configure all your alerts for both email and webhooks. At a glance it will show the status, type of alert configure, the alert description, recipient of the alert, and actions you can take to disable, enable or delete the alert.       The 'Add Alert' Option walks the user through the guided config of selecting  Networks based on tags: New and existing  Type of alert:  WAN: uplink status, packet loss, latency, and uplink BW VoIP: MOS, Jitter, and latency  Recipient: email or webhook     Use cases: Flexible in configuring the alerts that match each networks SLA/SLO Be proactive by lowering the threshold to be alerted so they can catch critical outages before it happens React quickly with webhooks(org-wide and per alert) that can be integrated with third-party tools to trigger and notify the right team on time   For more information on the feature and its capabilities, please refer to the KB article.   ... View more

More information on the endpoints can be found on your Meraki dashboard under Help--> API docs   ... View more

Each WAN and VoIP Alert setup will go through a configuration wizard to identify the networks they want to be alerted to and the type of alert associated with it. Use Case: With each type of alert, the customer can choose the Service level thresholds for loss latency and utilization or MOS and be alerted accordingly. This will help them keep their SLA’s/SLO’s at check for each network Use case: Alerts can also be proactive. They can set values to be lower than expected and be alerted of an issue as they get closer to the identified Performance degradation level.      This feature is currently in beta and will be made available under MI and SD-WAN+ licenses. For more information please refer to the KB article  ... View more

  WAN and VoIP: Dates back to 21 days with a minimum window of 15 minutes Web App: Dates back to 21 days with a minimum window of 15 minutes over 1 week only Use cases: Greater visibility into granular details of an issue Analyze trends such as loss or latency that range over a week Look into specific time periods independent of when the issue is reported Things to keep in mind: Time zone notations are not available. The default Time zone will sync up to the user's browser accessing the MI page. Cannot currently choose arbitrary date values outside of the standard 00, 15, 30, 45 Disabled typing into the ‘start’ and ‘end’ date box. ... View more

VoIP On-Prem    As the name suggests, VoIP health will now have the capability to monitor VoIP servers with Private IP addresses in DC’s that are accessible over VPN.    You can add the private IP address using the “Configure VoIP servers” option and once saved the VoIP stats to the given VoIP server will be monitored. The “Private IP” field can be selected from the dropdown box under Interface, to view VoIP stats for On-Prem or private IP address server.     Best Effort Monitoring   There are some VoIP servers that do not allow or drop the ICMP pings used to monitor VoIP services such as MOS, loss, latency, and jitter. However, as VoIP services are critical and hard to identify the exact issue, we have integrated the Best Effort monitoring to VoIP Health to give a “nearest” best estimation on VoIP performance for a given link. This tool will measure the performance of the “nearest hop” that responds to ICMP. By enabling 'Ping Nearest Hop' under the Configure VoIP server option, the MX will start pinging to the nearest best available hop to the configured VoIP server and show the MOS, loss latency, and jitter stats to it. By enabling this, the process of elimination of faulty hops becomes easy and hence reducing the Mean Time Resolution for the problem at hand.         For more information on how to enable VoIP On-Prem and Best Effort Monitoring and the working of each component, please refer to the KB Article.   This will require no firmware upgrade and organizations with SDW+ or MI license can use this feature. ... View more