Network automation with PRTG & IP Fabric: do more with less

If I asked you to name a technology that’s vital to today’s “connected everything” world, but originated in the 1940’s, I bet not many of you would respond with “APIs”. Although the term Application Program (without the -ing suffix) Interface wasn’t coined until 1968, the concept of sharing data between computer programs originated with the development of a modular software library for the EDSAC computer in the late 1940s.

Over the ensuing decades, APIs continued to evolve. As did their somewhat abstract definition. Different programming languages tended to describe the function and use of their APIs in different ways. However, they all had one thing in common: the API was exclusively of interest to the programmers’ developing systems and applications in the particular language.

That all changed in the early 2000’s when Roy Fielding outlined his ideas for a network-based API he referred to as Representational State Transfer, or REST API. In one of those “perfect storm” moments that occasionally occur in the tech world, the REST API was conceived just as the internet began to take off as a commercial tool. Within months Salesforce, eBay and Amazon had all enabled their rapidly developing platforms with XML based REST APIs, allowing data to be accessed directly by tech savvy users, and not just developers.

Today, most of the services we rely on in our personal and work lives, be it your favorite social media platform or your company CRM system, include a REST API to facilitate the sharing of data. Of course, PRTG is no exception. You’ll have seen in previous blog posts how PRTG’s native REST Custom Sensor can be used to extract data from external systems and display it in sensor channels and on maps.

But PRTG also features its own REST API that can be used to interact with objects being monitored. Strictly speaking, PRTG features two REST APIs, as we’re currently developing a new enhanced API with some cool new features. Both the original API and the new 2.0 version are available in parallel and will be for the foreseeable future.

Quite a lot! During a recent Paessler Alliances event, Daren Fulwell from IP Fabric, showcased how APIs can be used to automate network administration tasks such as adding new devices to PRTG, creating tickets in ServiceNow for devices that aren’t properly configured, and writing to Webex Teams channels to keep all parties informed. A recording of that session can be found here. For the rest of this article, I’ll be describing Daren’s use case and the tools he used to automate his processes.

We’ve already written a couple of articles about IP Fabric, so I won’t go into too much detail here. Suffice to say it’s a network assurance and intent verification platform, whose purpose is to make sure your network is behaving as intended. One of the ways it does this is by taking periodic “snapshots” of the network and comparing them and identifying any changes that are detected between snapshots. As IP Fabric is designed around an API, almost every function and feature can be accessed using that API. This makes it extremely easy to retrieve data from the system and share that data with other tools.

The scenario described in the linked video is a simple one, but one that regularly causes problems for network admins – adding new devices to their network.

World-renowned “widget” manufacturer (does anyone even know what a widget is?), 35 Group, are commissioning a new production facility. Being sensible types, they obviously use PRTG to monitor their network and here we can see the existing infrastructure consists of three sites, and an empty “placeholder” device group for the new production facility:

Their network installation team have been to the site and installed some new switches, routers, and firewalls, which are detected when IP Fabric next takes a scheduled network snapshot:

But there’s a problem. IP Fabric’s “Intent Verification” checks have spotted that some of the new devices don’t have properly configured SNMP Community Strings, meaning that PRTG won’t be able to monitor them.

Identifying that the problem exists is useful but is only part of the story. The network admin still needs to fix the issue. Of course, (s)he could manually take a note of the wrongly configured devices, contact the installation team and task them with correcting the error. But that could be time consuming, laborious, and prone to further mistakes. Instead, with API based systems such as IP Fabric, PRTG and ServiceNow, the entire remediation process can be automated. To demonstrate this, Daren wrote a rather cool Python script that shows just how this might work.

Here we can see the script in action:

What it does is:

• Compares the two IP Fabric snapshots and identifies any changes – in this case, nine new devices were discovered.
• Validates the SNMP Community String of those devices – some are OK, some not.
• Calls the PRTG API and adds the new devices, pausing those with bad Community Strings and starting auto-discovery of those with properly configured SNMP
• Adds the new devices to ServiceNow’s CMDB
• Creates and incident ticket in ServiceNow, to get the bad Community Strings changed
• Writes several information messages to a Webex Teams channel to keep everyone informed.

Here we can see that the new devices have been added to PRTG, and those with properly configured SNMP settings have started their auto-discovery process, while the rest remain paused until the SNMP config problem has been fixed:

This is just one example, designed to showcase a rather specific use-case. But it serves to highlight the power and flexibility of API enabled platforms. With the correctly chosen tool set, some careful planning and a little creativity, system admins can automate many of their repetitive, tedious, and error prone – but nonetheless essential – everyday tasks. Giving themselves more time to concentrate on more interesting and rewarding activities, such as finding cool new uses for PRTG.