One of the most personally intriguing features to me within the Mist platform is the level of programmability that is available. You can accomplish most tasks through the Mist GUI if you wish … from architecting and pushing out configuration templates all the way down to writing queries to sift through the sea of data that enables Marvis. But everything you touch in the GUI can also be addressed through the API and in some cases you can get even richer data when interacting via the API.
I won’t dive into scripting here as that would warrant a much larger topic. But as a few quick examples, I’ve been building Python scripts to streamline interactions with larger queries or sweeping config changes – for example, returning data showing a breakdown of ARP timeouts by SVI, diving into the 5GHz radio configuration across all APs at all sites, or pushing a new set of VLANs across all switches at a subset of locations through an updated YAML file. There’s a lot that you can do here with even just a very rudimentary knowledge of Python. Mist offers a great (and free!) “AI for IT Mist API” course within the Mist portal if you’d like to get started.
Similar to the way that the API framework introduced a new way to interact with our network infrastructure, there have also been updates and enhancements to how we can monitor the network as well. “Standard” protocols like SNMP and syslog have served us decently, but with the sheer number of devices connecting to the network and the increasing criticality of infrastructure uptime there are advantages to using a more responsive and flexible monitoring framework.
Here are the three most common ways to programmatically push and pull data from Mist:
- Webhook – Used for event triggered data, pairs most closely to Syslog and SNMP Traps
- Websocket – Used for streaming data, like device stats, location services, etc, pairs most closely to SNMP Polling
- API Calls – Used for your standard Moves/Adds/Changes/Deletes and Investigation, pairs most closely to CLI work
In this blog post I’ll talk about getting started with Mist’s webhooks. A “webhook” can be thought of as a modern way to receive alerts via a publisher/subscriber model when there is a change of state within your network – it could be something like a switch port coming online, an AP changing channel due to interference, or an anomaly being detected by Marvis.
To see the different alerts, device events, location data and other similar metrics that can be sent by Mist via webhooks, log into your Mist account and then go here: https://api.mist.com/api/v1/docs/Site#webhooks
In the webhooks framework the subscriber must be IP reachable from the publisher as the Mist cloud will be the one initiating the connection, POSTing the data to the target URL that you provide. If you choose to host your subscriber server on-premises you must ensure that firewall permissions have been modified appropriately to allow that incoming connection from Mist.
So as a first step you’ll need to have a URL that can accept the data from Mist. I personally used Pipedream for my lab, a cloud-based service that can stitch together services and trigger additional events when data is received. You can create an account for free at https://www.pipedream.com.
Disclaimer – this walk through is meant to help you dive into the Mist webhooks for ongoing education and for lab usage, this is not meant to give you a “production-ready” webhooks system!
Once you have an account at Pipedream you’ll want to create your first workflow. Use the “HTTP / Webhook” trigger and then select “New Requests,” giving your new workflow an appropriate name. Be sure you enable it using the slider in the top right corner so that it’s listening to new events.
At this point you’ll be given a target URL for your new source within Pipedream. Copy that URL and save it for the Mist side configuration. You can proceed from here to add additional “steps” within the Pipedream workflow if you’d like – you can see below via the icons in the “Steps” column a quick workflow that I built that listens for new data, interacts with the data through a Node.js module, then finally sends a message in Slack.
To enable webhooks for one of your sites within Mist log into the Mist portal and navigate to ORGANIZATION – SITE CONFIGURATION – [SITE] and scroll down to the webhooks section. Enable the webhooks service, name it appropriately, enter the URL for your subscriber server, and finally select the datasets you want to publish from Mist:
NOTE – if you elect to follow along with Pipedream as the subscriber, use caution enabling some of the chattier streams shown above (like location coordinates)! These will push a constant stream of data to your subscriber. These streams provide an excellent level of detail when working with a subscriber built to work with the data, but not so great if you’re using a free membership tier at Pipedream – you’ll hit your daily allotment of invocations in a few minutes, tops.
Once enabled, it shouldn’t be too long before you see new events populating within Pipedream. You can see these events by clicking on your workflow and then monitoring the left hand live view column. Below you can see the events that were triggered when the Mist AI engine updated my site’s RRM configuration at 2:40 AM… and further below that the non wireless interference detected at 10:42 PM when my young son’s monitor was turned on and it wreaked its usual havoc on the 2.4GHz band.
Often you’ll see multiple events bundled in a single POST. For example, a common triplet I saw during testing was “scheduled site RRM” “AP XYZ config changed by RRM” “AP XYZ reconfigured successfully.” You can confirm if there are multiple events in your webhook entry within Pipedream by expanding the fields steps.trigger.event -> body -> events.
Here’s a sample of the underlying data from a single AP event:
Here’s another example from a switch event:
The key/value pairs presented by the webhook can differ depending on the type of event that has been triggered, but because we use a structured data format it’s easy enough to sort through events by filtering for specific keys and values.
I’ve found this framework to be very responsive. There was minimal delay between unplugging an AP in my lab to getting several notifications from Mist – one telling me that a port on the switch had gone down, and another telling me that an AP was unreachable.
For my own “non-commercial just-for-fun” usage I created a simple workflow within Pipedream to alert me via Slack when something changes in my home network:
As a few more purpose-driven examples Mist can use this framework to directly integrate into platforms like ServiceNow to automatically open tickets when anomalies are detected via Marvis Actions, or it could trigger alerts in a location platform when a duress badge is activated, so on and so forth.
So now you can see that it’s pretty easy to get started playing with webhooks. I’ve only scratched the surface in this blog – as you can hopefully see there’s a lot that you can do with this architecture.
Packet Wrangling 