IP Fabric at Cisco Live!

IP Fabric's GUI provides you with Excel-like tables for filtering and querying data, but sometimes engineers require data to be extracted for more advanced reporting or Power BI dashboards. In this blog, I will demonstrate how to directly connect IP Fabric to Microsoft Excel or Power BI without using CSV exports. This has been simplified into functions stored in template files allowing you to pull any IP Fabric table in seconds!

Documentation and template files are located in the IP Fabric Integrations GitLab.


You must have web API access to the IP Fabric server (default is port 443). If running these queries from Excel in Office 365 or Power BI in the cloud, your IP Fabric instance must be reachable from the public Internet.

Microsoft Excel and Power BI will only allow you to communicate with websites that have valid and trusted SSL certificates. The easiest solution is to install a trusted certificate on the IP Fabric server that has been signed by a CA in your Trusted Root Certification Authorities. If you are unable to create a signed certificate you are also able to use a self-signed cert and install it on your location machine. This must be done for every user/computer that will be running the Power Query and you will not be allowed to run these queries in the Cloud.

Finally, you will also need to have, or create, an API Token. This token will be saved within the file (or the data source on powerbi.com) so sharing is not recommended. We recommend either removing your personal token before sharing the file (or posting the file to a shared cloud space, i.e. SharePoint) or creating a limited read-only account and API token. If you need more information or assistance with read-only accounts and RBAC please reach out to your Solution Architect.


After opening either the Excel or Power BI template file there are two required configurations that must be done prior to accessing data. You may be required to accept some warning messages about communicating with external content prior to being able to continue.

In Excel open the Data Ribbon and click "Queries & Connections" and right-click the IPF_URL query and select edit. This will bring up the Power Query Editor where you are able to input your information. Example configuration:

If you are using Power BI when you open the template file you will be prompted with a pop-up to enter these variables. To access the Power Query Editor simply click "Transform data" in the Queries section of the Home ribbon.

Finally, you should be asked about data source settings prior to connecting, if not then select the Snapshots connection and in the Home ribbon in the Power Query Editor select select Refresh Preview. For the Credentials select Anonymous and for Privacy level either check the Ignore Privacy Levels box or select any level and press save. Once completed you should now see a table of the loaded Snapshots.

Querying IP Fabric Tables

The queryIPF function simplifies the pulling of data with only one required parameter, the API endpoint of the table. This can be located by selecting the Table Description or the ? icon on any of the tables and copying the URL under the API Description. For example, I would like to pull my Inventory > Devices table into Excel.

The reports variable defaults to false, setting to true will include the Intent Checks for the table if any are configured. This will be a new column named colname.severity where severity equals one of the following:

Once configured select Invoke (the epochCols and durationCols can be specified after invoking the function which will be discussed later).

Now we have the Inventory > Devices table loaded. Changing the Properties > Name will change the Excel Worksheet name so it is recommended to update this value. In this example I specified reports=true and we can see the new configReg.severity column.

Finally, click the Home ribbon Close & Load which will update work workbook or to add more tables simply repeat this process for each table you desire! It is really that simple.

Time Columns

Times in IP Fabric are stored in two different formats. When you use the API you will see that an integer is returned unlike when you view it in the GUI. Let's take a look at these formats:

In the Device Inventory, the uptime can be converted into a human-readable format in Excel. Simply change the query by adding a list and the column name.


= queryIPF("https://demo1.us.ipfabric.io/api/v6.1/tables/inventory/devices", true, null, null)


= queryIPF("https://demo1.us.ipfabric.io/api/v6.1/tables/inventory/devices", true, null, {"uptime"})

This then converts 3435180 into 39.18:13:00 (39 days, 18 hours, 13 minutes and 0 seconds.)

Epoch example with the End of Life detail table:

= queryIPF("https://demo1.us.ipfabric.io/api/v6.1/tables/reports/eof/detail", true, {"endSale", "endMaintenance", "endSupport"}, null)


As valuable as contextualized network data is for your engineering teams, we know how insightful it can be also for adjacent teams, leadership, or third parties. Using our IP Fabric-developed Excel and Power BI template files, you can communicate directly with IP Fabric without exporting CSVs, seamlessly leveraging this data for high-level and detailed reports and presentations.

If you found this interesting and want to implement this in your environment, please look at the following quick videos for a visual demonstration and more advanced information. This includes how to work with nested objects and/or lists as well as joining tables. Reach out to your IP Fabric Solution Architect for more information or assistance!

Want to try out IP Fabric yourself? Sign up for our self-guided demo and see what automated assurance could do for your network teams.

Guest post by Shamus McGillicuddy, Vice President of Research at EMA

Data is essential to network automation. Network administrators review network data whenever they must implement a change through a network automation tool. Thus, any network automation strategy must take a rigorous approach to how solutions collect and manage network data. Enterprise Management Associates (EMA) recently explored the importance of data management in new research on data center network automation.

Our survey of 359 technology pros found that 48% of companies have data center network automation solutions that rely at least partially on manual data gathering. In other words, administrators must consult separate systems to find data they need in order to make a change in a network automation tool. 

“We are somewhat manual,” a NetDevOps engineer with a large European government agency told EMA. “We have [a commercial network data repository], but it’s not fit for a purpose, and it’s always out of data. So, engineers revert to using spreadsheets.”

Manual Data Gathering Degrades Network Automation

Nearly 51% of the organizations that rely on manual data gathering told EMA that these manual processes have degraded the effectiveness of their data center network automation solutions. EMA research found that there are three primary negative impacts from network automation that relies on manual data management. 

  1. Automated change takes too long because administrators waste time gathering data manually. Given that network automation is meant to drive operational efficiency, this manual data gathering process defeats the purpose of the technology.
  2. Network teams lack good visibility into whether automated changes were successful. They struggle to verify the state of the network. 
  3. Automation has the potential to introduce security vulnerabilities to the network. These vulnerabilities are traceable to errors made while gathering and inputting data, or administrators might simply fail to properly review security policies. 

Make Data Management the Foundation of Your Automation Strategy

EMA recommends that network data management should be a critical focus of any network automation strategy. The automation toolset should have comprehensive and reliable access to all network data that administrators need to implement automated changes.

“When an engineer has everything they need to execute a change right in front of them, it leads to high-quality work with a quick turnaround time.”

Network automation engineer with a $3 billion retailer.

As much as possible, tool architects should select and implement network automation tools that automate the gathering of all network data that users need for their workflows. This data strategy should provide insight into both network intent and network state. It should start with configuration and inventory data (intent), as well as device metrics and topology, then forwarding and policy behavior (state). This approach allows the network team to establish a true source of truth about the network. 

A Good Source of Truth Makes Network Automation More Powerful

From there, tool architects should think about how they can leverage this source of truth to establish a digital twin of the network, which will allow them to simulate, visualize, and understand how the state of a network matches their intent for the network. EMA research found that 88% of technology pros believe it is useful to have a digital network twin capability in their data center network automation tools. They told EMA that these digital twins are helpful in a variety of ways, including capacity planning, network design, troubleshooting, and threat modeling.

With continuous insight into network intent and network state, a network automation tool can evolve into a network assurance platform. EMA research found that 89% of technology pros believe it is important for data center network automation tools to have integrated network assurance capabilities that allow them to monitor and troubleshoot networks from within the automation tool. Best-in-class companies were more likely to prioritize these capabilities. 

Finally, this visibility must be end-to-end, from the data center out to the network edge. EMA research found that 86% of technology pros believe it is important for data center network automation solutions to be integrated into end-to-end network automation, including the LAN and the WAN. Best-in-class companies were the most likely to say end-to-end extensibility is very important to their data center automation tool strategy. Not only should automation be extensible across the entire network, but the network source of truth should also be global and end-to-end. This will allow network administrators to understand how automated changes to the network can affect application performance, end-user experience, and network security. 

If you want to read the full research report, download it here: The Future of Data Center Automation.

To find out more about how IP Fabric can accelerate your network automation journey, request a tailored demo with our team: Request a Demo.

One of the most challenging issues with a merger and acquisition, or preparing to sell your public IPv4 space, is ensuring the addresses and networks are cleaned from your environment. Using IP Fabric can remove many technical hurdles, because all your important networking information is in a single platform and accessible via a GUI and API.

I’ll be demonstrating reclaiming a private space, but this methodology can be applied to any network you wish.

IPv4 Marketplace 

According to IPv4.Global, a trusted leader in the IPv4 resale marketplace, the January 2022 IPv4 Auction Sales Report had average prices ranging from $48-$54/address, an increase of over $20 per address compared to January 2021. If you were to sell IPv4 addresses at $50/address this could produce $200k for a /20, $800k for a /18, or $3M for a /16, which can easily cover the cost of your IP Fabric solution depending on the size of your network. 

Discovery and Snapshots 

IP Fabric is a snapshot-based platform - it represents your network at a single point in time. The discovery process involves the application finding and logging into your network devices to collect information about how your network is configured. This is a fully automated system and uses information like CDP/LLDP neighbors, ARP, and routing tables to find other connected devices in your network.  IP Fabric then crawls your network in this fashion until all neighbors have been tested.   

One unique characteristic of IP Fabric is that it does not use SNMP to collect information, but rather retrieves data by either Telnet, SSH, or API calls. This provides a more robust collection of data compared to the limited information retrieved by SNMP alone. 

For more information about the discovery process, please see How Discovery Works, Discovery Snapshot, and our Supported Vendors documentation. 

Once discovery is completed and the snapshot is finished with calculations you can view detailed information about your network. Below is an example from a completed discovery: 

Hosts Inventory

One of the data points we collect is a device's ARP table, which allows the application to display all the hosts connected to your networking devices.  In most cases your hosts will not have public IPv4 addresses tied to them, but this is a great place to start your check. However, if you are reclaiming private IP space - like in this example - this will greatly reduce the time needed to audit your network.

The Host IP Address column is filterable based on CIDR notation, and I have found two addresses that fall within our range.  This table shows you valuable information such as the site, device and interface it is connected to, the gateway, MAC address, vendor, and VLAN information.

Managed IP Addresses

IP Fabric classifies IP addresses assigned to a network device as a "Managed IP" and not a host.  This table can be found under Technology > Addressing > Managed IP.  In the above example I have already applied our filter and we now have a list of devices and interfaces that would require a re-IP for a successful reclamation.

NAT Pools

Also located under the Addressing Technology is information about your NAT Rules and Pools. In our environment, I have located two pools which both fall into our IP scope.


One of the most useful features of IP Fabric is that it collects all the routing table entries from all your devices and allows you to search your entire network without requiring a user to log into individual devices to query for this information.

To narrow down our results, I have chosen to create an Advanced Filter.  My first filter is a regex of ^(S|C)$ on the Protocol column which will display all the Connected and Static routes.

My second filter is another regex of ^192.168. to show all routes of interest. This works great for a /8, /16, or /24 networks but if you are trying to reclaim a network not on a classful boundary some post-processing might be easier for filtering your results.  All the data in IP Fabric is available in both an API and CSV export.

Filters can also be grouped so if you are reclaiming a /23 network this can easily be accomplished with a few more steps, as shown above. Filters can also be saved, but let's look at an Intent Verification rule which will make it easier to track your progress. Rules can be created on any technology table.

Once saved and applied you can easily track your reclamation efforts:

Topology Diagramming

One of the best features of IP Fabric is its ability to take your network data and create topology diagrams.  These are fully customizable where you can hide nodes and protocols, move items around, and save views for later use or export to a SVG or PNG.  In the example above I have overlaid our intent rule which can give your team a great visual way to see where your networks are.  I have opened one site (L37) which shows that 2 routers have a Static or Connected route for our network.  If you are interested in learning more about our diagraming, please take a look at our other blogs and YouTube channel.

Other Useful Tables

Here are some other useful tables that can help narrow down where your IP addresses are located and how they are being used in your network.  All of these can be located under the Technology menu.

ACL and Firewalls

Once your IP space has been cleaned and removed from your network it can become a tedious task of checking your access lists and firewall policies.  IP Fabric supports multiple vendors and platforms and extracts these policies into a security data model which you can then search without requiring the knowledge of vendor specific commands.  Just like the Routing table you can also create intent rules using regular expressions to ensure your firewalls and ACL’s have been scrubbed once the space has been removed from the network.  (Extra caution must be considered cleaning up Private IPv4 in security policies to keep your network protected; since our lab only contains private addressing, I have used this as an example instead of a public range.)

In the examples below I have created two Intent Rules in the Security > “Access lists” and “Zone Firewall”.  These use the regex “^192\.168\.” to search for a match in any of the addresses in the Source (Red) or Destination (Yellow) Addresses.  I used red for the source because if you sell the address to another company you want to ensure any open firewalls are closed to external IP’s.

Access List

Zone Firewall

Utilization Reporting

Although IP Fabric is not a full IP Administration system it does collect information from your devices, as seen above, which can be used to discover the least utilized networks to sell.  The Hosts, Managed IP, and Routing tables can be easily pulled via the API or the Python ipfabric SDK to programmatically do calculations against your public IP ranges.  Our Systems Engineering team can help provide example scripts to accomplish this.

On the topic of utilization, perhaps your company needs to purchase new IPv4 space.  Deploying IP Fabric and having several months of snapshot data could be used to satisfy justification requirements for transfers.  According to ARIN’s Number Resource Policy Manual Section 8.5 “organizations may qualify for additional IPv4 address blocks by demonstrating 80% utilization of their currently allocated space” and “details the use of at least 50% of the requested IPv4 block size within 24 months.”


Thanks to its automated collection and its modelling of network behavior, IP Fabric gives you a single, regularly updated view of your entire network addressing.  Whether you want to understand the relationships and overlaps between the networks of two merging organizations or are preparing to sell some public IPv4 address space, that visibility will save you time and money with minimal effort.

This is just one of the many use cases for our market-leading Network Assurance technology!

For more information about the product and its use cases, check out our website https://ipfabric.io/ and other blog posts available at https://ipfabric.io/blog/, or request a demo with our team who can show you how to implement IP Fabric in your network: Request a Demo.

Integrations between platforms and systems are essential to successful toolset management. It brings more value for both platforms that share data if done correctly. For my next integration journey for the IP Fabric, I chose one of the best tools on the market for log management - Splunk. I used Splunk extensively during my years in network operations. Its versatility for data visualization is fantastic. For example, I was detecting DDoS attacks and suspicious routing protocol flaps within areas, all while easily correlating with network changes. Let's break down how to successfully integrate IP Fabric with Splunk.

Prerequisite for successful IP Fabric and Splunk integration

In general, there are two main types of integrations. The first is a one-way integration, where one system sends data to another. Here we use the power of the first platform (collect and manipulate data) to elevate the power of the second platform (ultimate data visualization). This is precisely what we will do to integrate IP Fabric with Splunk.

The second type is a two-way integration, where both systems use data from another and react. The second type requires either an intermediary system (or script) to create the integration logic, or both systems to be compatible.

A prerequisite for the data source (in our case, IP Fabric) is to have standard methods to read the data from the source. IP Fabric's API is brilliant for coders. It offers a full range of operations, and it's very well documented.

A prerequisite for the destination system (Splunk in our case) is understanding standard data formats - which Splunk is great for. With both conditions in place, let's start with the integration example.

Integration summary

Integrate IP Fabric with Splunk
High-Level IP Fabric to Splunk one-way integration

In short, IP Fabric is an Intent-Based Networking technology that serves as the foundation for network programmability, automation, and analytics by delivering critical information required to manage your network operations.

Splunk is the data platform that helps turn data into action for Observability, IT, Security, and more. And that's what we need.

I selected some of the essential metrics that IP Fabric regularly collects:

Then I included a couple of filtered data and intents:

Apart from the intent rules I picked from IP Fabric, 100 more default metrics provide valuable feedback from day 1.

Integration phase 1 - setting environment

First, I deployed IP Fabric, which took me about 30 mins to deploy on VMWare, and I could start the first discovery immediately! The goal was to regularly collect data from our virtual lab network (about 600 devices). The IP Fabric completed the first snapshot in about 18 minutes!

Second, I deployed Splunk with the developer license. I used a temporary license of the REST API Modular Input plugin to read the API data.

Integration phase 2 - provide the data flow

The next step was to configure Splunk to read IP Fabric's API. When I think about the whole integration, the only 'struggle' was to get proper API endpoints with the correct payload from the IP Fabric, which is no struggle at all! We have OpenAPI/Swagger available and dynamic API documentation on almost every page in the tool!

I created the Data Input in the REST API Modular Input plugin for each metric I needed to read in Splunk's GUI.

At the end of my journey, I created a new Dashboard in Splunk and combined all Data Inputs with more filters, for example:

integrate IP Fabric with Splunk
Dashboard in Splunk based on data from IP Fabric

Then I configured regular snapshots in IP Fabric and let Splunk create a trending line for each input in its dashboard.

Integration conclusion

Everything is about data. That's where the power is. With IP Fabric, everyone has a unique opportunity to access any operational data from the network they need quickly and accurately. The only actual limit is one's imagination.

The ultimate goal for any network or security engineer is to use available data efficiently to keep the network up and running and avoid the unexpected - and that's where the IP Fabric's involvements stand out.

More technical questions?

Are looking for more technical details about how to integrate IP Fabric with Splunk? Please contact me directly on LinkedIn or Twitter, as I am more than happy to provide more guidance on my struggles.

If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging on useful topics like the Splunk integration discussed here. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please get in touch - schedule a demo with IP Fabric.

Table of contents

The IP Fabric platform is a very unique and innovative system. It ultimately combines traditional approaches and new ideas, which may generate further misconceptions or simply misunderstandings. After hours or possibly days spent with first-time users of the platform, I decided to explain the most frequent issues or questions raised during the proofs of concept and customer enablement sessions. And here they are.

The concept of discovery

At first, let me discuss the IP Fabric's discovery process for a bit. We clearly cannot move forward until we touch on the core feature of the system, which the discovery process is. IP Fabric's discovery feature maps out the network infrastructure similarly as the network engineer would. What that means is that we only need credentials (or a set of credentials) and a seed device (router, l3 switch, or a firewall) to begin.

If we can log in successfully and read the data from the first device (ARP records, STP, CDP, LLDP, routing protocol sessions, or others), the system should have enough data to decide where to go next to repeat the process. For data gathering, the system only uses SSH (or Telnet) and API requests. The simplified discovery process can be seen in the flow chart below.

The discovery process simplified

Some networks are more accessible than others. We may have issues with the first-time discovery of isolated network segments behind the router that we cannot authenticate to. But most of the first issues we can resolve by analyzing the logs and adjusting the discovery settings.

Once the discovery is complete, the admin can fully enjoy new data every day in the form of Snapshots automatically. Following video describes some of the use cases.

The first snapshot is empty – 0 devices discovered

How is it possible that IP Fabric did not find anything? And that's an excellent question! Fortunately, this is very easy to troubleshoot. Here are viable reasons to think of:

Reason #1 – No Seed IP provided

There's Settings > Discovery Seed in the system, which is optional that appears during the Initial Configuration Wizard. However, if we don't provide any Seed IP, at first, the system will try to connect to its default gateway. If it fails to authenticate to its gateway, it will send a traceroute towards 'dummy' subnets hoping more IP hops will appear along the path as potentially the next starting points.

Now without any Seed IP configures (and without any previous snapshots available), and if IP Fabric fails to authenticate to its first gateway and when there are no other IP hops to test, there's nowhere to go next, and the discovery process stops.

To avoid this, I strongly recommend using at least one or two IP addresses of well-known devices that we safely authenticate to and can use as a starting point for discovering the rest of the network.

Reason #2 – We failed to authenticate/connect to the seed device

Now we provided the Seed IP correctly, we have the username and the password right, and we still don't have anything! How's that possible? Well, fortunately, that's easy to troubleshoot as well. Suppose we still do not have any devices discovered. We very likely couldn't authenticate or successfully initiate SSH connection to the Seed device, and we don't have any other IPs to test. Where to find the Connectivity Report for every snapshot is at following picture:

connectivity report

The platform is fully transparent. Every action, command, or testing is logged and available to the user. The best place to look at is the Connectivity Report. The Connectivity Report serves as a register for all outbound connections attempted with detailed data that either indicate success or failure.

An example of the Connectivity Report output can be seen above. We can clearly observe which IP addresses were tested with an error and what was the main reason.

The most common issue during the first snapshots is the Connection Error or Authentication Error. The Connection Error indicates we were unable to initiate SSH/Telnet connection to the network device, and we didn't have any prompt for username and password. The main reasons are that we are either blocked by a firewall or by the device itself (Access-List or Firewall filter applied).

The Authentication Error indicates that we could initiate a connection and received the prompt for the username and the password. Still, our credentials are incorrect and need to be updated. We need to update our authentication database in Settings > Authentication and retest the discovery.

Reason #3 – Unsupported vendor

To successfully discover any network device and collect the data, we need to make sure that we understand the software. If it's IOS, Junos, or other operating-system among the most common – there are differences in operational commands used and, most notably, the responses provided. The IP Fabric platform has to be as accurate as possible and to ensure 100% accuracy. We need to support the vendor/platform or operating system that we ultimately ingest into our network model.

When IP Fabric successfully authenticates into an unsupported network device, it exits with failure after several attempts to detect any known operating system. The supported network vendor list is growing every release. If your current network equipment is not supported now, it doesn't necessarily mean it will not be in the future. Feel free to contact any IP Fabric representative for more information or request a trial.

Your business relies on IT to deliver services to your customer. But what happens when there is a failure, can you afford downtime?

Whether or not you can afford it, you should ask yourself this question: how to manage network risk to maximise service availability?

In this blog post, we are going to identify some risks you may be facing today, so you can understand better how to tackle them.

1.    Baseline – complete visibility of the network

It is extremely important to have the full picture of your network. You cannot correctly manage devices or infrastructures you do not know about, or only have partial information.

1.1.                 Inventory

The inventory is often used as the source to define the list of devices you will have under maintenance. What happens if a device fails and is not under maintenance?
You will need to order a replacement, which could take days, weeks, or more to arrive before you are able to restore the service. In the best-case scenario, the service is resilient, so only resiliency is affected, but while waiting for the replacement to arrive, you would be in a situation where you cannot afford for anything to fail.
In the worst-case scenario, if the service is not resilient, the service will be unavailable until the replacement of the faulty device.

So, we understand that maintaining an accurate inventory is crucial, but it can be very challenging:

1.2.                 Documentation

We have a very similar problem with the documentation of the network and making sure it stays up to date. Otherwise, you are at risk of not being able to solve efficiently any issue arising on your network. A partially updated diagram could be very misleading for any change preparation or troubleshooting. This could cause unnecessary downtime which can be avoided.

Obviously, you may have processes in place to ensure diagrams and relevant documentation are accurate. But we all know that this is very time consuming, and let’s be honest, there are some more exciting projects you would rather be working on.

2.    Eliminate network inaccuracies

Monitoring tools are there to alert you of an issue, but what happens if there are some anomalies which are not considered as an issue, i.e., no SNMP traps are sent, nor syslog, and you have not experienced any symptoms because the problem is only on a backup link or device.

How do you detect these inaccuracies to fix them before they become service affecting?

2.1.                 MTU Misconfiguration

MTU can be the source of issues when the MTU is not configured consistently, for example, you have a primary path working as expected, but the backup is misconfigured. It means you will only notice the issue once the primary path fails.

It can be difficult to confirm MTU is correctly configured on all your devices: how long would it take you to collect the information for all the interfaces’ MTU, parse that data and analyze it so you know for each link how is the MTU configured on both end?

Having instant access to the links with inconsistent MTU, allows you to be proactive, so you can fix any links which could be causing issue on your network.

2.2.                 BGP neighbors not receiving any prefixes

The second hidden issue I wanted to discuss here, has caused a major downtime in my previous experience: a BGP neighbor with no received-prefixes.

This is the situation we were in, two BGP neighbors to a service provider, but on the backup router, we were not receiving any prefixes. BGP session was still established, so no issue from our monitoring tools, everything “seemed fine”.

And one day, it happened: we lose our primary connection, and here starts our massive downtime. We no longer have access to this service.

We knew the resilient path had been working in the past, but what we didn’t know is that it wasn’t working anymore. How can we detect this so we can resolve similar issues before they cause downtime?

For further information on this point, you can check the following blog post: BGP resiliency and received prefixes | IP Fabric | Network Assurance

Those examples show how you could be facing an issue on your network and be totally unaware of the situation.

3.    Restore services

We want to be proactive as much as possible to avoid any downtime, but there are situations when issues happen. So, we need to be reactive and work efficiently in order to restore the service.

3.1.                 End-to-end path for advanced troubleshooting

Using IP Fabric’s End-to-end path, will very quickly display all devices involved with passing traffic from a source to a destination. IP Fabric doesn’t just look at the network data, it includes firewalls in the path, so you can visualize any policies which may block the traffic.

With such a tool at disposition, it becomes easy to quickly pinpoint the source of the issue without having to connect to any devices, check the logs on different firewalls or spend time finding the latest diagram. Everything is available in one single and dynamic view:

3.2.                 Past representation of your network topology

When you are troubleshooting, you often lack the understanding of how it was working before. It would be very useful to have a view of a previous topology, for example, from the day before. Then, by comparing both topologies, you can observe and quickly identify what has changed:

In the example above, you can see in the previous snapshot, there was only 1 link to the MPLS cloud, the 2nd one in red was not present, but is operational in the latest snapshot.

IP Fabric, as a network assurance platform, shines a torch on all those weaknesses and proactively inform you of potential issues existing in your network.

There is a lot more IP Fabric can help you with. To explore further, join our webinar on the 30th of June at 11am CEST: IP Fabric - FSI Webinar You can get in touch with us through www.ipfabric.io and follow our company’s LinkedIn or Blog, where more content will be emerging.


Today we will go through a quick demonstration of the IP Fabric platform and its main features. The IP Fabric platform is the network management system that helps companies to empower network engineers and teams to discover, verify, and document large scale networks within minutes.

IP Fabric's lightning-quick processes intelligently discover over 3,000 network infrastructure nodes an hour and collect more than 2,000 configurational and operational state data per active network device.

The system then generates a digital model of the entire network with the switching/routing and security logic built-in. Since IP Fabric can identify both known and unknown devices, it eliminates the need for manual inventory processes in the company.

To initiate the IP Fabric platform successfully, it first needs to be installed on VMWare 5.0 or later and have an access to all infrastructure devices via SSH or Telnet with correct credentials.

Of course we can apply additional settings, such as IP subnets to include or exclude from discovery, limit the bandwidth or the number of concurrent sessions during and many other.

Once the discovery is finished we have a complete digital image of the entire network, which we call the snapshot. In every snapshot, we can run end to end path simulations, view all operational data about the network, analyze network topology maps or verify the network’s overal state with the Assurance Engine.

That is all for the introduction, now let’s get started with the demo.

We are currently in the Snapshot management area. We have 4 snapshots loaded in the RAM memory and they are available to be explored immediately. Historical ones are stored on the Hard drive and can be loaded to RAM anytime. We can decide to add more devices to currently active snapshot or reinitiate discovery on selected devices and get the newest data.

We have the Connectivity Report which contains all IPs that the platform interacted with during discovery process, which is great for troubleshooting purposes and it underlines complete transparency that the user has when using the platform.

With our current snapshot, we discovered almost 600 devices and it took us about 10 minutes. We have the list of sites that serve as a logical groups for network devices. The user has full control over the Site Separation mechanism, sites can be based on devices’ location or function, it’s up to administrator to decide.

Now we will examine the inventories. We have full and very detailed visibility into all types of inventories: Devices, Interfaces, End-points or End-Of-Life milestones, which are very important for lifecycle management.

In any inventory or technplogy tables Sorting and Filtering tools are available. For example, in case I want to find all Juniper SRX devices within the inventory, I will fill in the vendor and the platform field and I have results available in seconds.

I can choose which parameters will be visible or change the columns’ order. Any filtered output is easily exportable to a CSV document and can be shared with the team. By the way, all search or filter functions available in graphical user interface are obtainable via API as well, with full documentation available online or in the platform.


Because the platform is the tool not only for viewing static data but also for analyzing behaviour of variety of protocols. Addressing any inconsistent states is very easy. As an example we can explore data for the Maximum Transmission Unit (or MTU) on all links just by few clicks.

I will search for an MTU, where we have all the information available. To discover any issues, we’ll just click on available verficiation and we have results in seconds.

Detecting inconsistent MTUs on all transit links in large scale networks can be a really time consuming to get, there can be tens of thousands links to verify.

After discovery, we only export the data and send it to operations team immediately. This type of proactive network management will help us to decrease the number of network issues in the future.

If we desire to have a visual representation of MTU results in diagrams, we will click on the site button and check for MTU in there.


Similar applies if for any other supported technology. In the platform we can research routing and switching protocols, stacks, clusters, 802.1X, PoE, Quality of service and many many more. The IP Fabric platform is a search engine for any network.

As an example may be OSPF protocol.

We are very quickly seeing all OSPF sessions with all details on the network. By a single click we can tell if there are any sessions down or in transition state and use it for documentation purposes or for troubleshooting.

In addition we can go back in time, switch the snapshot and see historical results, which makes it an amazing tool for root cause analysis.

Assurance Dashboard

Last feature we would like to delve into, before we move on to diagrams, is the IP Fabric’s Assurance Dashboard, where all these verifications are displayed in one place.

IP Fabric is supplied with dozens of predefined network verification checks. These checks can be altered based on your needs, or you can create your custom ones very easily.

There are many focusing on Management protocols, Performance, Stability, Routing and Switching protocols, and we can go on..

All verifications are provided with explainers and all these results can be exported to the Network Analysis Report, which can be generated by the platfrom on demand.


And now the Diagrams. With the IP Fabric, you have full and detailed visibility on a protocol level. There are not only physical links between devices in the topology maps but all relations between devices. If it's OSPF or BGP session, Spanning-Tree or discovery protocols.

All views and layouts can be easily modified or built from the scratch with the amazing View Builder feature. All available in a multivendor environment.

The network devices can be repositioned freely and the layout can be saved for future analysis. And the same diagram appears in the Low-Level design document, which can be also generated by the platform.

What we can quickly explore in terms of layers is Discovery protocols, which can be considered as physical layer mapping, Spanning-Tree or Mac layer and Routing protocols, all separately or together at once in a diagram.

In case we desire, for example, to track a single VLAN in the topology, we will click on any trunk link, select the VLAN number and immediately analyze which ports are in forwarding or blocking state for any particular VLAN or examine where the root bridge is.

The same we can do for any previous snapshot, we may go back in time and analyze any topology from the past!

Now a quick look at routing protocols. In the current topology, we have OSPF and BGP present, apart from that we support all mayor routing protocols including EIGRP, RIP, IS-IS or Label Distribution protocol from the MPLS environment.

By interacting with any link or node we get more detailed data, we can add the cost on OSPF links if we want to and export the topologies.

In addition we are able to visualize connected servers, IP phones or PC or wireless access-points if they are present. Then visualize QoS, Access-Lists or First Hop Redundancy protocols, detect single points of failure or non-redundant links.


Now we will move on to the E2E path testing. The End to End path testing can be essential for root cause analysis, verifying the post-migration state of selected application paths across the network or any ad-hoc testing related to client’s portion of the network. The IP Fabric platform enables seamless and extremenly fast path testing on the created mathematical model.

It takes literally seconds to complete standard end to end simulations for switching, routing and security portion. It is also possible to test end-to-end in MPLS networks based on labels.

So let’s test on our own:

With the path check feature, selected paths can be saved and continuously verified by the platform with every new discovery automatically.


Maintaining network documentation may be a tedious and difficult process, that requires a vast amount of time. Which is the main reason why many companies are necessarily hiring external resources to complete the task.

To simplify the process, IP Fabric platform automates network documentation. There are currently two types of automated documents. The first one is the LLD document, which provides a detailed network overview for each business location, including topology visualization.

The second one is the Network Analysis Report, which will give you an overall report of your network, including network state checks.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

IP Fabric platform can be considered a Swiss Army knife for network engineers, providing one with trustworthy network verifications. One of IP Fabric's functionalities is here to help you continuously check if the network is configured properly or not.

Lets demonstrate this capability on one of the functionalities that would be typically configured by IP Fabric administrator, as it is one of those domain-specific configurations differing in every network — Authentication, Authorization, and Accounting, otherwise known as AAA, or Triple A.

Many individuals who have had to implement AAA on a router or a switch most likely have little knowledge regarding the commands that they copy to the router configuration. Most will simply utilize the AAA configurations from another functioning router or switch. Today, we are going to analyze the best AAA practices and how one can ensure its proper setting with our IP Fabric platform.

For those who are working with a larger network environment, you are most likely using a form of TACACS+ or ACS server running that is specifically designed for the management of logins to your devices. AAA works in unison with TACACS+ to provide efficient management of your logins’ security. In other words, this monitors who is able to log in (Authentication), what that user can do (Authorization), as well as track the commands that are used (Accounting). In the instance of server failure or reachability issues, it is recommended to have a backup local login user name and password that will allow access to your devices.

Best practices

We shall now analyze what is considered the best practices for configuration.

aaa new-model
tacacs server ACS1
address ipv4
tacacs server ACS2
address ipv4
aaa group server tacacs+ ACS
server name ACS1
server name ACS2
aaa authentication login default group ACS local
aaa authentication enable default group ACS enable
aaa authorization config-commands
aaa authorization exec default group ACS local if-authenticated
aaa authorization commands 1 default group ACS if-authenticated
aaa authorization commands 15 default group ACS local if-authenticated
aaa accounting exec default start-stop group ACS
aaa accounting commands 1 default start-stop group ACS
aaa accounting commands 15 default start-stop group ACS

Upon dissecting this model by line, we have:

aaa new-model

This new-model essentially turns on the AAA functionality on the network device.

tacacs server <name>

This addresses the setup of the TACACS server details, such as the IP address, shared key, and all other optional details.

aaa group server tacacs+ <group_name>

This is intended for the grouping of specific servers into logical groups.

aaa authentication login default group ACS local

Here, we define how the device is authenticating the users who attempt to log into the device. First, there is the default authentication method with group of TACACS+ servers named “ACS”. Then, if it is unreachable, we shall implement the locally configured user account list.

aaa authentication enable default group ACS enable

This component explains that, for enable mode, the default authentication method with group of TACACS+ servers named “ACS” should be utilized.

aaa authorization config-commands

This is regarding our goal to authorize each command that is being issued to the device.

aaa authorization exec default group ACS local if-authenticated

This sets up the device and places the user directly into enable mode, upon his authentication (the if-authenticated keyword).

aaa authorization commands 1 default group ACS if-authenticated

In this command, we are authorizing the level 1 user commands, which is similar to the non-enable mode.

aaa authorization commands 15 default group ACS local if-authenticated

Here, we are providing authorization for level 15 users against TACACS+. If TACACS+ is unavailable, then the local user account is used, instead. Upon authentication, the user will immediately be placed into exec/enable mode.

aaa accounting exec default start-stop group ACS

The logging in and access into the device is ensured by AAA Accounting

aaa accounting commands 1 default start-stop group ACS

This provides the tracking of user activity on a given device for privilege 1 commands.

aaa accounting commands 15 default start-stop group ACS

This provides the tracking of user activity on a given device for privilege 15 commands.

This provides tracking of user activity on a device, even if they have just logged in.

As you can see from this basic configuration, there is significant variability, resulting in complications of the verification of the proper function. This worsens with regular network operations, when the connectivity to the TACACS server fails, requiring a troubleshoot to determine the error. In such a situation, one would usually remove the TACACS configuration in attempt to resolve the issue. However, during the troubleshoot, it is common to forget about this change and leave the network open with local authentication or, perhaps, no authentication, whatsoever. Luckily, IP Fabric offers the newly released AAA verification, which can be used for the verification of the real live AAA settings.

AAA intent network verification tables
AAA intent verification tables

Although our platform includes a few “out of the box” reports, we highly recommend adjusting these default reports in color with your custom verification checks, since the AAA settings differ between various companies. We recommend that you observe and spend time on the following:


Let us assume that we want to set up the verification report for the Authentication methods to verify this:

Which would be equivalent of the following piece of configuration

aaa authentication login default group ABACS localaaa authentication enable default group ABACS enable

It is generally recommended to have a single detection for all issues on the particular AAA method and to reveal the issue count on the dashboard.

This can be configured in the following manner:

For a more detailed overview of how to set this up, view the video below:

AAA Authentication catch-all-errors rule setting
AAA Authentication catch-all-errors rule setting

Proceed to colorize the columns with specific details to green or orange, so that you will immediately see what is wrong from the dashboard counter created previously. In our case, we would need to setup additional rules as follows:

AAA Authentication Secondary method would look like this:

Secondary method verification for AAA Authentication tab
Secondary method verification for AAA Authentication tab

This will ensure the setup of the Authentication on all devices in the network. In regards to the remaining tabs (servers, lines, authorization, and accounting), you may follow the same logic to create similar specific rules that will configure IP Fabric to verify your specific AAA needs consistently in a matter of seconds.

In similar way, you can implement your custom verifications for any data table present in the system, to get complex view on your own network setting consistency!

If you have found this article resourceful, please follow our company’s LinkedIn or Blog, where there will be more content emerging. Furthermore, if you would like to test our platform to observe how it can assist you in more efficiently managing your network, please write us through our web page www.ipfabric.io

The wait is over, IP Fabric v3.0 is HERE! 🎉🙌

Quite often, when a company pushes out an update, it’s more about their developers squishing a few bugs than actually giving you shiny new toys - I mean, features.

This is not one of those updates.

In our quest to help you empower your network engineers, we’re rolling out an update that expands our platform’s capabilities in unprecedented ways.

In this update, we’re adding Network History functionalities that allow you to display the network state from any point in the past and compare it to the current state. This will enable you to do things like work on the platform while the discovery process is running, export any snapshot you’d like, and more!

Let’s go over the shiny new toys you’re getting in a little more detail so you can take full advantage of our platform.

Snapshots 📸

Of all of our platform’s new features, this is the one we’re most excited about.

Unlike in previous versions where you could only see the latest network snapshot, our v3.0 update allows you to pull up any previous snapshots so that you can see how the network performed before. This new capability extends to all aspects of the platform, including technology verification tables and diagrams.

Thanks to IP Fabric’s newest update, you can now pre-load and instantly switch between up to five snapshots.

Now, instead of going through a lot of effort trying to figure out what changed in your network over the weekend, you can have an answer instantly.

Snapshots in End-to-End view

Always-Available Platform 💻

Your days of waiting for IP Fabric’s platform to finish an operation before allowing you to use its other features are over.

The system now allows you to use all of IP Fabric’s features while simultaneously running other processes (like a network discovery), saving you even more time.

Platform snapshot availability during running discovery
Platform snapshot availability during running discovery

Include Additional Devices

When the platform encounters a device that it isn’t able to log into, whether it’s due to misconfigured passwords, missing access control lists (ACL), or any other reasons that may arise, it no longer needs to scrap the current discovery process and start over again from scratch.

This update allows you to “discover” the missing devices manually by adding details like the username, password, IP address, or other pieces of information into the platform, saving you loads of time previously spent restarting discovery processes.

Adding new devices to already finished discovery
Adding new devices to already finished discovery

On-Demand Device Data Refresh 🔄

Thanks to the update, IP Fabric now allows you to run targeted partial discoveries on select devices. This can be useful in all sorts of scenarios. For example, if you’re using IP Fabric as part of the change management process.

In this scenario, to run a targeted discovery, select the devices affected by the network change. The process will automatically update their state data, saving you time and effort.

On demand data refresh for a site with changed network configuration
On demand data refresh for a site with changed network configuration

Snapshot Management 📁

IP Fabric v3.0 comes with a snapshot management tool. That allows users to do all sorts of things with their network snapshots, including:

Demonstration of snapshot renaming, commenting, locking and downloading of the network snapshot data
Demonstration of snapshot renaming, commenting, locking and downloading of the network snapshot data

Additional Improvements


We’ve continued to improve our platform’s network discovery process, including improved platform detection.

Diagram Performance

Diagrams load even more quickly than before, especially in large network environments.

For those who want to take our platform’s automation to the next level, we’ve published our platform’s API documentation here.

Other various improvements and fixes that we haven’t outlined here can be found in the release notes here.

Interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting? Contact us through our websiterequest a demo, or follow this blog.

Today, it is our pleasure to announce new version of our IP Fabric platform. Version 2.4 is in a general availability release that extends our product capability in technologies usually found in datacenter and network edge environments, namely VXLANs and Multi-protocol BGP address families.

Features — Protocols and Technology Support


For customers using Virtual eXtensible LAN overlays in their datacenters, we are adding support for this technology in both Diagrams and Technology Tables. The platform provides with information about Virtual Tunnel Endpoints (VTEP) in the network, their peers, configured interfaces and VXLAN VNI.

VXLAN Topology in Diagrams

Flow export

To support traffic recording efforts of our clients we are introducing support for global Flow Exporter overview and configuration verification. Regardless if the technology used is NetFlow, Flexible NetFlow, IPFIX or sFlow, we now provide you with detailed overview of the devices configured for traffic exporting. Additional details provide information about all the configured collectors and interfaces used for exporting traffic to them.

Flow Export Overview with drill-down details

Simple Network Management Protocol

Although the Simple Network Management Protocol is one of the oldest network protocols, it is still widely used in network management for network monitoring. However, there are some risks associated with use of this protocol. First, when this protocol was created in 1980's, the idea was, that it will be used also for network configuration and second, there are well known community names for both read-only and read-write access to the devices. Last issue is, that except the last version of the protocol — version 3, there is no way to ensure authentication and privacy of the messages. Our tool can help you to improve the security of your network in couple ways — within seconds you can identify devices that are still using well-known public/private communities, find the devices that are using some non-standard communities and get rid of legacy SNMP protocol versions 1 and 2 completely, replacing it with SNMPv3. Of course, if you are using SNMP traps, we provide you with overview of all the SNMP Trap hosts configured on your gear as well.

Global SNMP community verification


All devices are generating amount of logging messages that can be stored locally on the device or, ideally sent to a central syslog servers or SIEM systems for correlation of events. Our tool again arms you with a visibility into what syslog servers are configured and where, so you can easily clean up the legacy servers configurations and ensure that the proper servers are in place, so that you don't miss any message your device wants to tell you.

Syslog server IP verification

Further improvements

We have worked hard on network discovery, where we improved detection of various platforms. The Diagrams now load much faster then ever before, especially in big network environments. Last, but not least, we now support BGP address families, where we provide with a new Technology table with all address family sessions configured along with their state.

For those interested in serious automation with our platform, we have published documentation of our platforms' API. You can find it here.

If you’re interested in learning more about how IP Fabric’s platform can help you with analytics or intended network behavior reporting, contact us through our website, request a demo, follow this blog or sign up for our webinars.

We're Hiring!
Join the Team and be part of the Future of Network Automation
Available Positions
IP Fabric, Inc.
115 BROADWAY, 5th Floor
NEW YORK NY, 10006
United States
This is a block of text. Double-click this text to edit it.
Phone : +1 (914) 752-2991
Email : [email protected]
IP Fabric s.r.o.
Kateřinská 466/40
Praha 2 - Nové Město, 120 00
Czech Republic
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
Email : [email protected]
IP Fabric UK Limited
Gateley Legal, 1 Paternoster Square, London,
England EC4M 7DX
This is a block of text. Double-click this text to edit it.
Phone : +420 720 022 997
Email : [email protected]ric.io
IP Fabric, Inc. © 2023 All Rights Reserved