In every product conversation and demonstration, we are always at pains to point out that we discover and curate an incredible wealth of network data in our platform. That data is then available for you to query and visualise through the Web UI. And we always make the point that the Web UI sits atop an open API which can be accessed from outside the platform. This allows IP Fabric’s unique knowledge of your network to be exposed and integrated into your wider operational ecosystem.

This post covers the different approaches to how this integration is achieved. It highlights the flexibility of IP Fabric’s approach to being able to help answer questions about your network, that in turn takes friction out of your operational processes.

Why integrate?

With its unique discovery and analysis capabilities, IP Fabric is able to give you insight into the functionality of your multi-vendor, multi-domain network. Deep rich data about the relationships and the behaviours of your network devices and connections are exposed and available to be viewed in point-in-time snapshots. Having that data to hand immediately, without having to trawl the network to fetch it yourself, means that manual processes to document and visualise the network are a thing of the past.

But the richness of that pool of data can clearly be of wider benefit than just to the network team looking after the day-to-day operations. Inventory information kept constantly updated will benefit everyone from monitoring teams to procurement and contracts folks; capacity information helps project planners and network designers; security policy information helps IT security teams and so on and so forth.

How do others use that data?

Exposing this data to the wider IT and business folk in a way which is consumable to them can only help smooth their processes. And using a system which can deliver that automatically means they don’t have to come ask the network team for that data all the time! And so we need to consider how to take the data out of the IP Fabric platform and pass it to the people who need it.

In the simplest case, we provide people with access to the platform (perhaps read only) so that they can view the data for themselves. IP Fabric does not require a seat licence, so multiple users can be logged in and viewing data simultaneously at no extra cost. Alternatively, network users could extract the data from tables and diagrams in the system by saving it as CSV or PNG files so it can be emailed across. This may be a quick and dirty way of doing it, but may work well to augment existing process.

Ideally, access to IP Fabric data is automated through API integration, retrieving the data and using it directly in a user’s end system (or vice versa). This means then that the insight that IP Fabric brings is available at the point it is required to be used, rather than having to go through manual intermediate steps to get it there!

Approaches

But how, practically, does that integration work? Let’s look more closely at the approaches we have available to us.

Product

Integrations can be built into the product itself. For example, IP Fabric uses APIs itself to pull data into the platform directly from platforms like the Meraki dashboard or the Checkpoint Gaia Portal. Development work is slated for integrations for the likes of ServiceNow as we enter 2021. The key for these is understanding the use cases.

Direct Product Integration

For example, do we need to understand trigger events and pass data out of the platform in response? Do we send updates to those platforms when there are changes in IP Fabric automatically or do we need some manual intervention? We work with customers and partners to understand those use cases and then they are raised with our development team to build them into the platform. Often, the best way to understand these is to build them using our other mechanisms detailed below, then use those as a basis for specifying the functionality we need in the platform.

Middle Box

This is the most common form of integration in our current use cases as it is the simplest to develop quickly and flexibly. A script or process is built to run on a machine (“Middle Box”) outside the IP Fabric platform which extracts data from IP Fabric, processes it, then interacts with other platforms with updates or events built using that data.

Middle Box integration example

The customers and partners in our community are busy working on exactly these forms of automation and integration, and we have many examples of how this approach is being used:

  • Extracting inventory data from the latest IP Fabric snapshot, comparing it with the data held in NetBox, ServiceNow (as a CMDB), Zabbix and PRTG (for monitoring) and making updates if the user deems appropriate;
  • Taking code version data from the inventory tables, comparing it with the results of CVE searches from the MITRE website, to show where there might be vulnerabilities affecting devices. In this case, we are helping to extend that search further by checking if the device in question is configured with the affected feature to prioritise upgrades;
  • Checking whether devices have been configured with the correct SNMP communities and servers to be able to be managed and monitored using Zabbix;
  • Creating Ansible and Nornir dynamic inventories from live IP Fabric queries in order to ensure that automation scripts run against all the devices, and are grouped appropriately;
  • Offering up a Slack Bot which is able to accept questions from a user, send the queries to the IP Fabric database, then respond with the answers back into the Slack chat.

Webhooks

A recent addition to the IP Fabric platform, webhooks provide a mechanism to trigger events outside the platform. When a snapshot event occurs, or an intent verification rule is recalculated, we send a message containing event information. Typically this will enter a queue on the receiver, from where a handler process will pick it up and process it.

Webhook integration

This enables use cases such as:

  • When a snapshot is completed, analyse the changes in inventory from the previous, then update the monitoring platform, CMDB etc ;
  • Automatically create incident tickets in ServiceNow when an intent rule, or specific path check fails;
  • Building a set of intent verification rules for morning checks. When those rules are run, have the output from them sent to a Slack channel! Enables dynamic reporting on the status of those checks to the network team.

Summary

Using these mechanisms, the possibilities are endless, only limited by your imagination and the ability to develop the solutions. Getting involved in the customer and partner community enables you to lean on the experience of others and share code. It also gives you a path to raising use cases that we can feed into our development process. (For access to some amazing folks, look for our #ipfabric channel in the NetworkToCode Slack system)

Alternatively, we have some amazing partners who are building automation ecosystems around the data and processes in IP Fabric. Contact us for more details!

If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.