Home > General Administration > Cross-Platform Content > Alerts and Notifications

Alerts and Notifications

Overview

There are a number of options available in the Meraki dashboard for email alerts to be sent when certain network or device events occur. This article outlines which options are available for each product, as well as additional considerations when using network alerts and organization-wide notifications throughout the dashboard

Configuring Network Alerts

Network alerts can be configured in the dashboard under Network-wide > Configure > Alerts.

Network alerts can be configured by specifying the Default recipients for all selected alerts, and by configuring additional recipients on a per-alert basis. There are two options to denote who will receive email alerts:

  • All network admins
    This will send email alerts to both Full and Read-only network admins. This does not include any of the Organization admins.
  • Other email addresses
    This allows for a custom list of recipients, where email alerts will go to all email addresses listed. To specify other email addresses, type an email address into the Default recipients field and hit enter.

The following screenshot shows an example of network alerts configuration on a combined network:

Network-wide Alerts

The following alerts can be configured on multiple Cisco Meraki products:

  • Configuration settings are changed
    Available on all platforms, sends an email if any configuration change is made in the dashboard.
  • A VPN connection comes up or goes down
    Available on both the MR and MX platform, sends an email if a configured VPN tunnel goes up or down.
    Note that for MX, only AutoVPN connections are monitored for alerts. The connectivity status of Non-Meraki Site-to-Site VPN is not monitored because it cannot be monitored from both sides of the tunnel.
  • A rogue AP is detected
    Sends an alert if a rogue AP is detected on the network.
  • Network usage exceeds (x) KB/MB/GB/TB in 20 minutes/4 hours/1 day
    Sends an alert if the specified amount of data is seen on the network for the specified timeframe.

clipboard_e5f033fcb00e50702db7165381afd395e.png

MR Alerts

Alerts can be configured for the following MR access point events:

  • A gateway goes offline for (x) minutes
    Sends an email if any gateway AP is unreachable from the dashboard for the configured number of minutes. Please note that the AP may still be functioning, this only indicates that it is unable to contact the dashboard.
  • A repeater goes offline for (x) minutes
    Sends an email if any repeater AP is unreachable from the dashboard for the configured number of minutes.
  • A gateway becomes a repeater
    Sends an email if a gateway AP loses its link to the network, and comes online as a repeater.
    For more information on this behavior, please refer to our documentation regarding Gateway vs. Repeater APs.

 

Additional alerts can be configured to maintain visibility on wireless Bluetooth clients:

Detected devices will be displayed in the Wireless > Monitor > Bluetooth clients page. The name of the Bluetooth client can also be edited for easier tracking. Email alerts can be enabled to trigger when the device becomes visible by the access point and when the device is no longer visible.

 

clipboard_e01daee14ec0b7b078ad6b17800c48c3c.png

 

MX Alerts

Alerts can be configured for the following MX security appliance events:

  • A security appliance goes offline for (x) minutes
    Sends an email if the MX is unreachable from the dashboard for the configured number of minutes. Please note that the MX may still be functioning, this only indicates that it is unable to contact the dashboard.
  • The primary uplink status changes
    Sends an email if the status of the primary uplink changes, which could be a failover event or downed link.
  • The DHCP lease pool is exhausted
    Indicates that the MX has run out of available IPs in one or more of its configured DHCP scopes, and is unable to provide an IP address to a requesting client.
  • An IP conflict is detected
    Sends an email if the MX has observed traffic from multiple MAC addresses, using the same IP address.
    Note: Due to the nature of certain device types, this event may occur as a result of normal network behavior. For a common example, please refer to our documentation regarding IP Conflicts Triggered by iOS Devices.
  • Cellular connection state changes
    Sends an email if the appliance establishes or loses its connection to the cellular network.
  • A rogue DHCP server is detected
    Sends an email if the MX observes multiple MAC addresses responding to DHCP Discover or DHCP Request messages. This can occur if a DHCP relay server is configured on a VLAN where the MX is configured to respond to DHCP.
    For more information, please refer to our documentation regarding DHCP configuration in the dashboard.
  • A warm spare failover occurs
    Sends an email if the primary MX of a High Availability pair fails over to the spare, or vice versa.
    For more information, please refer to our documentation regarding Troubleshooting MX Warm Spare.
  • Malware is blocked

       This alert will be triggered when a malicious file download is blocked.

  • Malware is downloaded

       This alert will be triggered when a file previously downloaded on your network is determined to be malicious in retrospect.

  • Clients connect or disconnect from the LAN
    Sends an email if select clients connect or disconnect from the LAN, as observed by the MX.

Wireless MX/Z-series Alerts

The following additional alert is available for wireless MX devices or the Z-series teleworker gateway:

  • A rogue AP is detected
    Sends an alert if a rogue AP is detected on the network

MS Alerts

Alerts can be configured for the following MS switch events:

  • A switch goes offline for (x) minutes
    Sends an email if a switch is unreachable from the dashboard for the configured number of minutes. Please note that the switch may still be functioning, this only indicates that it is unable to contact the dashboard.
  • A new DHCP server is detected on the network
    Sends an email if a DHCP Offer, ACK, or NACK message from a new MAC address (not seen in the last month) is observed by the switch.
  • Any/specific port(s) goes down for more than (x) minutes
    Sends an email if the switch port(s) specified goes down for more than the configured number of minutes.
  • Any/specific port(s) detects a cable error
    Sends an email if the switch port(s) specified detects an issue with the connected cable.
  • Any/specific port(s) changes link speed
    Sends an email if the switch port(s) specified renegotiates or fails over to another link speed.
  • A power supply goes down
    Sends an email if one of the removable power supplies on the MS fails.
  • A redundant power supply is powering a switch
    This alert will be triggered if redundant (not modular) power supplies are providing power to a switch.
  • Unidirectional link detection (UDLD) errors exist on a port
    This alert will be triggered if UDLD errors are seen on a switch port.
  • A switch is operating at critical temperature
    This alert will be triggered if a switch detects that it is operating at critical temperature. Critical temperature is a serious scenario requiring serious consideration of the operating environment of the switch. This alert is supported for the MS120 series, MS220-24P, MS210 series, MS225 series, MS250 series, MS320 series, MS350 series, MS410 series, and MS425 series.

 

The Switch > Monitor > DHCP Servers page displays information about any DHCP Servers seen by Meraki Switches on the LAN. From this page, Administrators can configure Email Alerts.

The Email Alerts dropdown menu can be used to enable Email Alerts to be sent to Administrators when a switch detects a new DHCP server on the network. This can also be configured from the Network-wide > Configure > Alerts page, under the Switch heading

SM Alerts

System Manager offers a number of advanced alert options, unique from the rest of the Meraki product line.

Several alerts can be configured to inform you and other network administrators of modifications made to your Systems Manager network. On a standalone Systems Manager network, these can be configured under Systems Manager > Configure > Alerts. In a combined network, all alerts are configured under Network-wide > Configure > Alerts and administration.

  • Software Alerts

Checking this option will enable the Meraki cloud to send a nightly email to the network administrators listed in the “Delivery Settings” section regarding Systems Manager clients that have software installed matching the listed regular expression*.

*The expression field must be a valid POSIX regular expression, and the search is performed case insensitive. For example, if you want to receive a complete list of all software installed in the last day, you would enter ".*" (without quotes). If instead you wanted to be alerted when Starcraft or Warcraft is installed, you would enter "starcraft|warcraft" (without quotes).

  • Connectivity Alerts

Checking this option will enable the Meraki cloud to send an email* whenever a client device with a specific tag stops checking-in for more than the determined time threshold. This will alert an administrator of any abnormal client outage.

*You will also receive an email when the client comes back online.
Client tags can be set by clicking on a client from the Monitor > Clients tab, clicking edit, and then editing the tags field. Please see Tagging Devices for more information.

  • Geofencing Alerts

This section gives you the option to enable the Meraki cloud to send an e-mail whenever a client device violates a geofencing policy. You can also check the option to have an e-mail sent when a client re-enters their geofencing region after violating a geofencing policy.

  • Enrollment Alerts

Checking this option will enable the Meraki cloud to send an email when a client device enrolls in a network. This will alert an administrator when a device is added to a network.

  • Mobile Device Management

If a client device managed by Systems Manager has its Meraki Management profile removed, checking this option will allow the MCC to send an email to the network administrators listed in the “Delivery Settings” section.

It is very important to ensure that your managed devices retain the Meraki management profile, as this is the way your client devices check in to the Meraki cloud.

For iOS devices, there is currently no way to password-protect the management profile from being deleted. From the end user perspective, removing the management profile will result in the possible loss of wireless connectivity, apps, and any enhancements gained from being managed by a Systems Manager network.

  • Delivery Settings

There are three options for selecting the recipient of an e-mail alert. E-mail alerts can be sent to a network owner, all network owners, or a specified e-mail list*.

*The "Other e-mail addresses" option will accept one email per line.

MV Alerts

Alerts can be configured for the following MV camera event:

  • A camera goes offline for (x) minutes
    Sends an email if a camera is unreachable from the dashboard for the configured number of minutes. Please note that the camera may still be functioning, this only indicates that it is unable to contact the dashboard.

 

 

MV motion alerts

Node > Settings > Motion Alerts + alerts page

clipboard_e5278f76a82a13d5dfb532e027c19e03b.png

Custom alert recipients can be configured on the general alerts settings page (Network Wide > Alerts > Camera)

Meraki Insight

To help with proactively monitoring and troubleshooting issues, Web App Health provides the ability to configure email alerts. Configuring an email alert is a two-step process.

 

First, navigate to Insight > Web App Health and scroll to the bottom of the page. At the bottom of the list of applications, select the Manage alerts option, which is listed as shown in the figure below.

 

WebAppAlert1.png

 

Second, click on Manage alerts to open a pop-up window, where alerts can be managed on a per-application basis.

 

WebAppAlert2.png

 

Alerts will be triggered (send an email) if an application is performing "poorly" (as defined by the threshold levels you've set for each application) either on a network side (LAN/WAN) or a server-side (hosting resource). The email will also include information about which side is experiencing poor performance, and will include a link to your dashboard, where you can learn more about the issue.

 

Note: Keep in mind that thresholds play a significant role in alerting. It is highly recommended to set thresholds (i.e. Per-Flow Goodput and Response Time) properly in order to receive actionable Alerts to take proactive measures.

Alerting Capabilities

  • Currently, all recipients will receive the same alerts. Alerts cannot be set on a per-recipient or per-application basis.

  • Recipients can either be written in manually or, for convenience, can be selected from a list of organization-level admins. Accounts in the pre-populated list include users with organization-level read-only or full access.

  • Applications can be selected individually, or multiple applications can be selected at once.  

 

Features of Alerts

  • Receive a clear indication of an issue when it occurs, and understand at a glance, before using the dashboard, whether it is an application or network level issue. Alerts include the application name and network that is having an issue

  • Web app email alerts are smart enough to recognize "flapping" alerts (quickly and repeatedly crossing an acceptable threshold) and send an alert at staggered time intervals (every 30 mins)

  • Alerts also include notifications when the issue is resolved

 

Additional Alerting Considerations

All network alerts will be sourced from the same email address. To ensure that alerts are not being lost to a spam filter, please be sure to add alerts-noreply@meraki.com as a trusted email source

 

Webhooks

Meraki Webhooks are a powerful and lightweight way to subscribe to alerts sent from the Meraki Cloud if an event takes place that sets off a configured dashboard alert. They include a JSON formatted message and are sent to a unique URL where they can be processed, stored or used to trigger powerful automations. This solution provides you with a rapid way to setup a hosted service capable of receiving and storing any webhook alert data.

webhooks1.png

webhooks2.png

Webhooks support all configurable alert types available in the dashboard under Network-wide > Configure > Alerts. This includes a variety of alerts for all product types that you own or operate. The webhooks architecture consists of the Meraki cloud and a cloud-accessible HTTP or HTTPS receiver (server). There are a variety of standalone cloud webhook services (e.g. hook.io, Zapier, etc.) that are able to receive and/or forward webhooks.

Webhooks Dashboard Setup

To configure Webhooks on the Meraki dashboard, navigate to Network-Wide > Configure > Alerts.  On the Alerts page, you will see a section for Webhooks.  From here, click on Add an HTTP server, and configure the server URLs as shown below.  

 

clipboard_ed5c98ae37ba58b5e0540eb9512d063f1.png

 

Now that the HTTP servers are specified for Webhooks alerts, the servers need to be specified as recipients for Dashboard alerts.

 

clipboard_e5c28aa671a3ae0aa4a642284658cd556.png

 

Zapier and Built.io are tools that can be used to integrate and automate API applications.  Either can be used for the setup of Meraki dashboard Webhooks.

For more information about setting up and using Webhooks, please visit https://developer.cisco.com/meraki/webhooks/

 

SNMP Configuration

Simple Network Management Protocol (SNMP) allows network administrators to query devices for various types of information.  Meraki allows SNMP polling to gather information either from the dashboard or directly from Meraki devices themselves, including MR access points, MS switches, and MX security appliances. Third party network monitoring tools can use SNMP to monitor certain parameters on Meraki devices.

SNMP Device Information

The following information below can be polled from the Meraki dashboard

  • Device MAC address

  • Device Serial number

  • Device Name

  • Device Status (Online or Offline)

  • Device Last Contacted - Date and Time

  • Mesh Status (Gateway or Repeater)

  • Public IP Address

  • Product Code (e.g. MR18-HW)

  • Product Description (e.g. Meraki Cloud-controller 802.11n AP)

  • Name of the Network that the device resides in (Dashboard Network)

  • Packets/Bytes In/Out on each physical interface

Standard MIB support

SNMP servers use a Management Information Base, or MIB, which is a database of SNMP Object Identifiers, or OIDs.  OIDs identify the managed objects that inform the SNMP server on what values to poll from the device.

 

The Meraki dashboard and Meraki SNMP capable devices support the following standard MIBs:

  • SNMPv2-MIB .1.3.6.1.2.1.1

  • IF-MIB .1.3.6.1.2.1

Meraki Proprietary MIB


The Meraki dashboard has its own proprietary MIB to allow SNMP servers to pull data and information from the Meraki dashboard.  This MIB document can be located and downloaded from the dashboard under Organization >Configure > Settings > SNMP.  The Meraki Cloud MIB cannot be used to poll information from Meraki devices directly, as it is designed strictly for Dashboard information.

Configuration Options

Dashboard SNMP Polling

The Meraki dashboard can be configured for SNMP polling under Organization > Configure > Settings > SNMP.  Here you see two options for SNMP configuration which is SNMP Version 2C and Version 3. Once SNMP has been enabled you will be able to send the SNMP requests to the host that is defined directly under the enable setting. The community string and a sample command to extract information via SNMP requests are then displayed as well.

NOTE: There are three versions available for configuration for SNMP.  These versions are: Version 1, Version 2c, and Version 3

  • Versions 1 and 2c allow for a simple community string to be defined. This string will be used between the SNMP server and reporting devices to validate the connection
  • Version 3 includes authentication and encryption for added security. Version 3 requires that a username and password be defined

 

 

IP restrictions can be configured to restrict SNMP access to particular sources. SNMP versions 1 and 2 send the community string in clear text, so IP restrictions would be useful to prevent unauthorized SNMP access if the community string is intercepted or learned by another party.

Local Device SNMP Polling

Individual Meraki devices can also be polled locally. In this scenario the SNMP traffic would stay within the local network and each device would need to be polled from the network management system. These settings can be found under Network-wide > Configure > General > SNMP:

 

 

SNMP Traps

By default, SNMP traps are not enabled on the Meraki dashboard. To have SNMP traps enabled for your dashboard organization, please contact Meraki Support. However, we recommend considering using webhooks instead of SNMP traps if your network environment allows for it, as webhooks have greater coverage and do not require activation.

SNMP traps are proactive SNMP messages that are sent out when specific networking events take place.  SNMP traps are very useful for real-time alerting for your networking environment. SNMP traps can be configured to be sent from the Meraki cloud. SNMP traps are closely related to the possible Alerts that can be configured for your network. SNMP traps use SHA1 for authentication and AES for privacy.

 

Once enabled for your organization, you will see that SNMP Traps can be configured under Network-Wide > Configure > Alerts. The SNMP Traps section will be set to Disabled once initially enabled by Meraki Support. Again, you will have the option to enable SNMP Version 2c or Version 3.

 

In the example below, the SNMP Access level is set to V3 (username/password).  Specify a valid SNMP user by clicking on Add an SNMP user. Input the desired username and password that is also configured on the SNMP server. Once that is done, enter in the Receiving server IP address, which will need to be a public IP address. It is best practice to configure the receiving server ports with either UDP port 161 or 162, as these are the default ports SNMP servers listen on.  

 

 

If the SNMP server is behind a NAT device, a port forwarding rule will need to be configured to allow the SNMP traffic through. This due to the nature of the SNMP traps being sent from the Meraki cloud controller.  Be sure to specify the correct LAN IP address of the SNMP server, as well as the UDP ports it is listening on.  

Defining SNMP Traps to be Sent

SNMP traps are closely tied to the alerts that can be configured under Network-Wide > Configure > Alerts.  In order for SNMP traps to be generated, SNMP must be configured as a recipient for the alert to generate the SNMP trap.  Either SNMP can be input as a default recipient so all enabled alerts generate a trap, or SNMP can be configured on a per alert basis.

Screen Shot 2019-07-15 at 5.27.34 PM.png

 

Once SNMP traps are enabled and configured to send, alerts that trigger SNMP traps to be sent must be enabled and set up appropriately.  Below is a list of SNMP traps, and their respective dashboard alerts.

 

SNMP Trap Sent

Meraki Dashboard Alert

Alert Category

Settings Changed

Configuration settings are changed

Network-Wide

VPN Connectivity Change

A VPN connection comes up or goes down

Network-Wide

Foreign AP Detected

A rogue AP is detected

Network-Wide

Device Goes Down/Device Comes Online

A gateway goes offline

Wireless

Device Goes Down/Device Comes Online

A repeater goes offline

Wireless

Gateway to Repeater

A gateway becomes a repeater

Wireless

Device Goes Down/Device Comes Online

A security appliance goes offline

Security Appliance

Uplink Status Changed

Primary uplink status changes

Security Appliance

No DHCP leases

The DHCP lease pool is exhausted

Security Appliance

IP Conflict

An IP conflict is detected

Security Appliance

Cellular Network Up/Cellular Network Down

Cellular connection state changes

Security Appliance

Rogue DHCP Server

A rogue DHCP is detected

Security Appliance

Warm Spare Failover Detected

A warm spare failover occurs

Security Appliance

Malware Blocked

Malware is blocked

Security Appliance

Malware Detected

Malware is downloaded

Security Appliance

Device Goes Down/Device Comes Online

A switch goes offline

Switch

New DHCP Server Alert

A new DHCP server is detected on the network

Switch

Port Disconnected/Port Connected

Any port goes down

Switch

Port Cable Error

Any port detects a cable error

Switch

Port Speed Change

Any port changes link speed

Switch

Power Supply Down/Power Supply Up

A power supply goes down

Switch

Redundant Power Supply Backup/Redundant Power Supply Back to Primary

A redundant power supply is powering a switch

Switch

UDLD Error

Unidirectional link detection (UDLD) errors exist on a port

Switch

Critical Temperature

A switch is operating at critical temperature

Switch

Device Goes Down/Device Comes Online

A camera goes offline

Camera

 

SNMP traps cannot be sent for any Systems Manager alerts. If a trap and its associated alert is not listed above, Meraki devices do not send traps for it.  

 

Also note that if devices go down and are not communicating with the dashboard, the trap will be sent after the specified amount of time configured for the alert.  

 

Last modified

Tags

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 8493

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community