Now that you’ve been introduced to the use of templates within the Dashboard to help automate network configuration, it’s time to start thinking outside the Dashboard. With the help of tools such as webhooks, syslog, and SNMP, you can build custom solutions to trigger automation outside of the Dashboard based on activities and events happening within the Dashboard.

The potential possibilities for automation based on webhooks, syslog, and SNMP are nearly endless due to the widespread adoption of these technologies and their ability to allow easy communication and integration across different platforms. Because of the impossibly wide variety of custom solutions that could be created and used, this book provides only a few brief examples of different ways you can use each technology to trigger some form of outside automation. The specifics of the outside automation and its implementation are left as an exercise for the reader.

Webhooks

Webhooks are possibly the simplest way to implement external automation from the Dashboard. All that is required is a publicly accessible webhook receiver that is able to receive and process webhook messages from the Meraki cloud. As the example in Figure 4-4 shows, automated webhooks contain JSON messages that are both human- and machine-readable and are sent for any alerts that have been configured to generate a webhook on a per-network basis from the Network-wide > Alerts page. Because of the flexibility offered by using JSON messages, there is a huge variety in the way webhook receivers can be implemented. From dedicated monitoring and management systems like SolarWinds, Zendesk, and PagerDuty to more customized solutions like spreadsheets and chatbots, the potential options and possibilities when discussing webhook receivers are nearly as endless as the ways this information can be used after it is received.

Figure 4-4 An Example of Webhook JSON Data Alerting That an AP Came Up

You can use webhooks purely for external logging of alerts or you can use them for automation by configuring the webhook receiver to take additional actions after processing webhooks that meet a defined criteria. Webhooks can be particularly useful for defining more specific alert criteria than what’s available on the Dashboard directly. For example, you could configure a webhook receiver to automatically begin sending alert messages to on-call staff only if multiple sites report a given event within a specified timeframe, such as multiple devices offline across sites or multiple VPN tunnel drops within a few minutes. Or, you could configure a webhook receiver to help enhance change management control by monitoring all configuration changes across all networks but only sending additional alerts through Webex Teams when configuration settings are changed for specific, potentially sensitive networks.

Leave a Reply

Your email address will not be published. Required fields are marked *

Explore More

Template Best Practice Considerations – Automating the Dashboard – Cisco Meraki

When working with templates, there are some general best practices to keep in mind. One of the most important general best practices is to remember that templates are designed to

Sizing It Right – MX and MG Best Practices – Cisco Meraki

When planning and deploying your Auto VPN topology, there are several best practices to keep in mind to ensure optimal performance. The first and most important practice is to ensure

OSPF – MX and MG Best Practices – Cisco Meraki

When working with an existing environment that utilizes OSPF for routing, it’s important to be aware that Meraki’s MX security appliances, at the time of writing, only support a limited