Update 02/03/2023: Keep your eyes peeled for our formal NetBox integration coming soon! We're always creating resources to save you time and effort in getting the most from IP Fabric. We'd recommend reading on to understand the power of NetBox and IP Fabric working in tandem. If you're planning on implementing this in your network, however, reach out to us first so we can let you know when to expect an faster method.
NetBox is an infrastructure resource modeling (IRM) application designed to empower network automation. Initially conceived by the network engineering team at DigitalOcean, NetBox was developed specifically to address the needs of network and infrastructure engineers.
https://docs.netbox.dev/en/stable/
Notably, NetBox is an open-source tool. Everyone has free access to the code and many simple deployment options are offered. For my testing purposes, I decided to use its docker image. It took me about 5 minutes to deploy and get the NetBox ready.
The IP Fabric is the Automated Network Assurance Platform that helps enterprises empower their network and security teams to discover, model, verify and visualize large-scale networks within minutes. Its main goal for any network infrastructure is to regularly capture the current network state. It provides another layer of abstraction for its users to access the network state data and it is vendor-agnostic!
In plain words, the IP Fabric will provide the model for you! And one of its biggest advantages is its standardized and well-documented API. Imagine capturing inventory, routing tables, or security policies from all discovered firewalls in a single request. That's how useful its API can be.
Understanding IP Fabric's API is fairly simple. Every provided data set (inventory, routing information, multicast data, security policies, part numbers, management protocols, and many many more) has its own dynamic documentation that will provide all necessary to build your API request including full payload information, description of all its properties and more. All you need to start your automation journey.
Let's divert the flow a bit and think about the importance of a reliable data model. When we talk about the data model, we mean the dataset that represents the network state.
The need for an accurate data model increases with complexity. Let's consider managing 100 network devices, with a couple of minor changes per month. We keep all the states (routing, switching, policies, ..) in our head, and from time to time we update the spreadsheet and our Visio documentation. Great!
Then what about 1000 network devices with hundreds of minor changes a month managed by a larger team? The previous concept doesn't scale and when an engineer leaves, the knowledge follows. That's why the standardized data model (or it may be called the Source of Truth) should be part of every network team, including operations, development, or architecture.
Now we agree that having an accurate network model is a must to navigate complexity. Then we have two main options to manage it.
1 - Standardize and hastily follow processes around any network change and make sure that everyone updates the CMDB after every change. It can work and it may even scale, but we are still assigning routine work to humans - and we are not good at it!
2 - Automate data management. We know that NetBox is an infrastructure resource modeling (IRM) application, but it doesn't have the discovery mechanism on its own. We still need to provide the data. In the following part, we will use IP Fabric's discovery mechanism and its API to read the network data and move them over to the NetBox with a sample script.
IP Fabric’s lightning-quick intelligent network discovery process empowers you with deep insight into the workings of your network. Baseline every device and path, configuration, and security policy automatically, equipping you and your team with the knowledge and insight to support, maintain, and develop the most complex of networks.
https://ipfabric.io/solution/network-visibility-and-assurance/
As we mentioned before, with IP Fabric you can fully automate the discovery process and have all essential network state data on a silver plate. There are about 2000+ parameters for a single device we can get including the inventory data, IP addresses, VRFs, VLANs, interfaces (standardized/original), routing data, policies, and many more. IP Fabric maintains regular network state updates on its own.
So if there's one API endpoint in IP Fabric to get the device inventory data and a second API endpoint in NetBox to provide data for its inventory. Then it's just two simple requests and the job is done, correct? Technically yes, practically it's not that simple! We need to add a transformation logic.
The schema below depicts the Network infrastructure on the left. IP Fabric captures the data from the existing network over SSH or API (AWS, Azure, NSX, ..) and provides the data over API. Then:
Reading IP Fabric's data is simple, but to create inventory in NetBox, we need to think about the data model differences first. And second, we need to create a proper mapping structure in our code. For example:
IP Fabric's properties should be mapped correctly to create desirable results in the NetBox. Just to mention a few issues we can come into during our implementation phase:
And there can be more, which is the main reason to spend time on planning before execution.
For everyone who is looking for an easy way to start, I have created a sample code to update NetBox with IP Fabric's inventory data. You can find and freely use the repository on GitHub. It consists of a handful of functions to add/remove standard inventory data or to populate the NetBox inventory completely. The prerequisites are:
Good luck and enjoy!
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 schedule a demo with our team: Request a Demo.
Update 02/03/2023: Keep your eyes peeled for our formal NetBox integration coming soon! We're always creating resources to save you time and effort in getting the most from IP Fabric. We'd recommend reading on to understand the power of NetBox and IP Fabric working in tandem. If you're planning on implementing this in your network, however, reach out to us first so we can let you know when to expect an faster method.
NetBox is an infrastructure resource modeling (IRM) application designed to empower network automation. Initially conceived by the network engineering team at DigitalOcean, NetBox was developed specifically to address the needs of network and infrastructure engineers.
https://docs.netbox.dev/en/stable/
Notably, NetBox is an open-source tool. Everyone has free access to the code and many simple deployment options are offered. For my testing purposes, I decided to use its docker image. It took me about 5 minutes to deploy and get the NetBox ready.
The IP Fabric is the Automated Network Assurance Platform that helps enterprises empower their network and security teams to discover, model, verify and visualize large-scale networks within minutes. Its main goal for any network infrastructure is to regularly capture the current network state. It provides another layer of abstraction for its users to access the network state data and it is vendor-agnostic!
In plain words, the IP Fabric will provide the model for you! And one of its biggest advantages is its standardized and well-documented API. Imagine capturing inventory, routing tables, or security policies from all discovered firewalls in a single request. That's how useful its API can be.
Understanding IP Fabric's API is fairly simple. Every provided data set (inventory, routing information, multicast data, security policies, part numbers, management protocols, and many many more) has its own dynamic documentation that will provide all necessary to build your API request including full payload information, description of all its properties and more. All you need to start your automation journey.
Let's divert the flow a bit and think about the importance of a reliable data model. When we talk about the data model, we mean the dataset that represents the network state.
The need for an accurate data model increases with complexity. Let's consider managing 100 network devices, with a couple of minor changes per month. We keep all the states (routing, switching, policies, ..) in our head, and from time to time we update the spreadsheet and our Visio documentation. Great!
Then what about 1000 network devices with hundreds of minor changes a month managed by a larger team? The previous concept doesn't scale and when an engineer leaves, the knowledge follows. That's why the standardized data model (or it may be called the Source of Truth) should be part of every network team, including operations, development, or architecture.
Now we agree that having an accurate network model is a must to navigate complexity. Then we have two main options to manage it.
1 - Standardize and hastily follow processes around any network change and make sure that everyone updates the CMDB after every change. It can work and it may even scale, but we are still assigning routine work to humans - and we are not good at it!
2 - Automate data management. We know that NetBox is an infrastructure resource modeling (IRM) application, but it doesn't have the discovery mechanism on its own. We still need to provide the data. In the following part, we will use IP Fabric's discovery mechanism and its API to read the network data and move them over to the NetBox with a sample script.
IP Fabric’s lightning-quick intelligent network discovery process empowers you with deep insight into the workings of your network. Baseline every device and path, configuration, and security policy automatically, equipping you and your team with the knowledge and insight to support, maintain, and develop the most complex of networks.
https://ipfabric.io/solution/network-visibility-and-assurance/
As we mentioned before, with IP Fabric you can fully automate the discovery process and have all essential network state data on a silver plate. There are about 2000+ parameters for a single device we can get including the inventory data, IP addresses, VRFs, VLANs, interfaces (standardized/original), routing data, policies, and many more. IP Fabric maintains regular network state updates on its own.
So if there's one API endpoint in IP Fabric to get the device inventory data and a second API endpoint in NetBox to provide data for its inventory. Then it's just two simple requests and the job is done, correct? Technically yes, practically it's not that simple! We need to add a transformation logic.
The schema below depicts the Network infrastructure on the left. IP Fabric captures the data from the existing network over SSH or API (AWS, Azure, NSX, ..) and provides the data over API. Then:
Reading IP Fabric's data is simple, but to create inventory in NetBox, we need to think about the data model differences first. And second, we need to create a proper mapping structure in our code. For example:
IP Fabric's properties should be mapped correctly to create desirable results in the NetBox. Just to mention a few issues we can come into during our implementation phase:
And there can be more, which is the main reason to spend time on planning before execution.
For everyone who is looking for an easy way to start, I have created a sample code to update NetBox with IP Fabric's inventory data. You can find and freely use the repository on GitHub. It consists of a handful of functions to add/remove standard inventory data or to populate the NetBox inventory completely. The prerequisites are:
Good luck and enjoy!
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 schedule a demo with our team: Request a Demo.
