You’ve been hearing about the Cisco Meraki APIs and all they can do. Maybe you’ve even started learning and have already been using the APIs but you still aren’t sure about everything you can do with them. It is a fact that Systems Administrators and Network Engineers who manage Meraki can benefit enormously from the potential that the Cisco Meraki APIs possess.
Here we’re going to take a look at some interesting use cases and some concrete examples to see exactly how we can leverage them.
There’s plenty of use cases with the APIs but we’re going to focus on some of the most useful and common ones: the use cases that could be applicable to everyone, regardless of network and infrastructure type.
Note: Some great use cases are already covered on the Cisco DevNet code exchange, so I would definitely take a look there too. The exchange is a great place to start seeing excellent examples of scripting written by real professionals.
The Meraki API allows you to draw in plenty of information from the dashboard using GET API calls. Although the native Meraki dashboard does a great job of providing a variety of reports, these are often restricted to certain time frames and sets of information. Using the Dashboard API instead allows engineers to get much more flexible and creative in how they create reports.
Whether you need this information to present to your team, your manager or your customers, being able to get exactly what you need can be a big help. If you can manage to learn a little bit of data visualization with Python too, then you’re all set to automate a task that might otherwise cost you a lot of time.
This use case really shines when the Meraki dashboard does not natively support the kind of reports you’re looking to create. In these scenarios, the APIs a great option to read information from the dashboard to create those reports.
Some examples would be these scripts to Get clients for a certain device or List clients for an entire organization. The latter even creates the CSV file for you so simply running the script creates the report with all the information in an organized manner.
Unless you’re working with the Meraki templates, you know how much of a task it can be to make a single change across all of your sites. Want to simply add a firewall rule or an SSID to 300 networks? There goes your day.
By using the APIs, these cumbersome and mundane operations can be completely automated. Learning once to harness the APIs for these types of changes could eventually save you countless hours, especially if you find yourself having to make these changes often. The ability to push out changes at scale also enables users to ensure a much greater level of control and standardization across their Meraki sites. This is of course due to the advantages that automation brings over manual work, where human error can often cause bigger problems later on.
Check out the Meraki API endpoints to see all the changes you can make at the network level. This type of automation isn’t restricted to changes however, and can also be used to provision large numbers of new networks and devices during the setup phase.
Are you looking to write more complex, rule-based, scripts that perform certain tasks based on the current state of your Meraki networks? You can combine the functionality of Meraki’s configuration and reporting capabilities to do so!
Let’s imagine that you’ve got clients within your infrastructure that are abusing the network and using way too much bandwidth. You could think of isolating these on the Meraki dashboard, however finding them one at a time is quite tedious.
Instead, you could write a script that uses the read API calls to draw in all of the information for your clients.hen, relate that information to make a write call that places any client above a certain usage onto a certain group policy.
This will ensure you don’t have to keep finding abusers manually, while also offering you a tool you can use at regular intervals to ensure abusers are being dealt with.
Changing configurations across many networks with the Meraki dashboard is an easy thing to do… when you are just managing one organization. But what about those engineers who manage multiple organizations? What about service providers that manage tons of organizations?
The Meraki dashboard can be quite powerless when it comes to making changes across multiple organizations. On the other hand, the APIs are perfect for these types of use cases!
Some great examples would include standardizing alert settings for all networks in all organizations you are managing.
Now, some settings exist only at the organization level. For instance, within the Meraki dashboard you can set the firmware schedules for an entire organization, but having to manage firmwares across many organizations can be a massive challenge for admins, especially as Meraki updates their firmwares quite frequently.
This script I wrote allows you to automate firmware scheduling and versions for all organizations on which you have write access. This script I wrote allows you to automate firmware scheduling and versions for all organizations on which you have write access.
There are many such changes that you can make at the organization level. Adding or removing administrators at scale would be a great example of another very common use case.
Another use case can be using the APIs to copy sets of information from one network in an organization to another network in a different organization.
Let’s say I’ve got a network with tons of firewall rules configured and want similar rules on the other network. Instead of copying these manually I can write a script that copies them all at the same time automatically. Pretty useful, don’t you think?
Anything to do with moving Meraki devices or networks to different organizations is best done with the API.
Whether you’re combining multiple organizations into one or splitting an organization, scripting the process will minimize human error and ensure that all configurations are copied over as efficiently as possible.
In most cases, users want to migrate their entire network (including devices) into a different organization. Because Meraki devices lose their configuration when removed from a network and an organization, there really isn’t an intelligent way to do this within the native Meraki dashboard. Unfortunately, there’s also no way to copy configurations for a network from one organization to another.
This is where you can get started using the APIs available at the device level – which can be used to read and change specific device configurations. Automating this entire operation is the only way to ensure that network downtime is minimized.
You can find some examples in the Cisco DevNet Exchange link. The scripts for copying networks, copying device configurations and moving devices can be combined to do this process as quickly as possible. I personally wrote some additional functions to help verify these migration processes by comparing network and device configurations that can be found here.
Sometimes you need to completely redesign the way your entire organization is structured. This could be due to changes in management, security regulations, team size or simply be a strategic decision to manage your networks more efficiently. Although migration between organizations is one form of this, there’s definitely other ways that engineers may seek to restructure their Meraki infrastructure.
Let’s say you’ve been working with the Meraki templates but over time they simply do not meet your use cases and are becoming a limitation. For instance, you could have a thousand networks all bound to a single template and want to unbind some of them so you can make a certain configuration change on that subset of networks.
Using the principles of condition based changes we discussed above, with Python you can write code that unbinds any network in your fleet that is bound to a template based on a certain condition. Then, you can also push out a configuration to that network right after it is unbound, so you are able to accomplish both tasks simultaneously.
This could be a very slow and boring task if done manually on the Meraki dashboard. But thanks to the APIs it doesn’t have to be.
If you’ve ever dreaded going through each configuration page, network by network, to ensure the right parameters are in place, then the APIs could be a game changer for you.
As you may know by now, there is no simple way within Meraki to ensure that your networks match the security regulations your company has defined. Although networks can be compared, what if you want to make sure that every single network in your fleet has a certain firewall rule or content filtering policy in place?
Rather than mindlessly scrolling through the entire scope of the dashboard, you can save yourself a ton of time and energy by making a relatively simple script that loops through every network and checks if it contains a specific configuration.
For example, you could use this API call to read the configurations you have for a certain port, and simply compare that to a text string to ensure that the correct configurations are present in each network. You can also do this for your entire security posture if you’re advanced enough.
This is definitely worth the investment as you simply have to run the same script each time you need to audit your networks! Although it seems like a daunting task at first, in the long run it could not only save you hours but give you the ability to create reports based on those audits and deliver results far more quickly.
Monitoring is certainly one of the areas where the Meraki dashboard has some missing features. Although the monitoring tools integrated in the dashboard work very well, there are often unique cases based on each infrastructure that would warrant a separate monitoring system. Perhaps you want to see the Site-to-Site VPN status for all of your sites, or you want to monitor the status of all your WANS (as we know Meraki doesn’t send an alert when a second WAN drops).
Being able to monitor failovers, statuses and traffic from a higher level is easily doable with the Meraki API. Indeed, creating your own monitoring scripts allow you to pull information much faster but also allow you to visualize information that otherwise may not be easily accessible on the dashboard. Many companies already offer additional monitoring capabilities for Meraki that are built on the APIs. These can be found on the Meraki marketplace.
The more difficult piece of this puzzle will be building the appropriate visuals and alerting system. Creating a dashboard means configuring not only the Meraki APIs but having to deal with databases, servers and UI as well.
If you’re smart about it, you can use the APIs to overcome the greatest hurdle every brand new Meraki organization faces: Deployment.
Unless it’s a one or two network organization, the provisioning phase can be a major challenge for Network Engineers, especially when they are new to Meraki.
Even for integrators who’ve been deploying Meraki organizations regularly, the deployment process can be a very cumbersome one that involves many repetitive tasks. By taking advantage of the API you can skip through most of the boring stuff. There’s a few ways you can do this.
Either you can use “create network” calls to initialize networks and/or you can use a stored JSON of configurations to push out settings that you know will be the same regardless of the network or organization.
You can also get creative and read whatever data you’d like to provision from a CSV file as that allows you the most flexibility. This is exactly what we did in the last episode of our 9-day Meraki API course.
Whatever path you choose, there’s no doubt the Meraki APIs will make your deployment easier if you use them correctly.
While this use case may not be quite mainstream, it is a great example of how you can use the APIs of different technologies to accelerate more complex tasks.
Meraki vMXs are a virtual version of a security network appliance which is completely hosted in the Cloud. At the time of writing this use case, Cisco Meraki vMXs are supported in AWS, Azure, Google Cloud Platform, Alibaba Cloud and Cisco NFVIs.
As for any other deployment operations, running this task at scale through the use of APIs can help you save some time and minimize the risk of errors.
In the video below, we provide a step by step guide on how you can automate the deployment of your vMXs to the AWS Cloud using APIs.
We’ve only just scratched the surface of what’s possible with the Cisco Meraki APIs. We’ve focused quite a bit on the potential of the Dashboard API, which is definitely the most powerful. The Dashboard API is definitely great for Network Engineers and Sys Admins working on the IT side of things, but there are however a host of other types of API endpoints which are meant more for business outcomes.
Meraki has adopted an API first strategy for a long time and this has opened the door for more and more ecosystem partners. They regularly publish new endpoints so the possibilities keep on growing. You can check out our article on Meraki API updates and releases to learn more about all that is new in the world of Meraki APIs
The MV Sense API opens up a whole new realm of possibilities with analytics based on information drawn for Meraki Cameras. Great Examples of this include the work done by Meraki ecosystem partners WaitTime and Everyangle. The technology available through the APIs and the Meraki MV devices has created the opportunity for companies to manage crowds far better.
The Captive Portal API is another great tool provided by Meraki which enables users to build customized splash pages and offer more flexible login solutions for their Wi-Fi.
The native Meraki dashboard does offer some functionality for being able to configure splash pages but doesn’t cover all use cases and doesn’t really allow users to get very creative with how their pages are displayed.
Advanced authentication methods, more detailed quality of service and the ability to collect more data are just a few of the additional features that a Captive Portal solution like Boundless Guest can provide.
Get a deep understanding of how to automate low-value and redundant network operations using the Meraki APIs.