If you’ve looked at Network Automation at all, you’ve most likely heard that the first step in your automation journey is to have a Network Source of Truth and that NetBox is the best solution out there for that.

Let’s look at why there’s so much consensus in the industry about using NetBox and how it enables you to build the foundation layer of your automation pipeline.

Reality, however, isn’t always so straightforward:

A Source of Truth (SoT) is the authoritative system for a specific data domain. When multiple systems disagree about the same data, the SoT determines which value is correct. All other systems either query the SoT or synchronise from it via API. This is a fundamental point often overlooked: Source of Truth doesn’t mean “one database for everything.” It means clear authority boundaries for different data domains.

Multiple SoTs are normal and expected. In practice, you’ll have different authoritative systems for different types of data. This is perfectly fine, and often unavoidable, so long as the data held in each system is different and only one system is in charge of updating each given data type.

Undoubtedly, having appropriate and up-to-date documentation is one of the biggest challenges organisations face nowadays. Some organisations do manage to build some good documentation in the beginning. However, as time goes by new changes are made but the documentation never gets updated as other (revenue-generating) projects take priority leading to unuseful documentation.

So what do we do you may ask? The solution lies in treating the documentation in a similar fashion to the configuration of devices, that is, automating it.

Pynetbox is a Python API client library for Netbox. In other words, it’s a library that does all the heavy lifting for us when dealing with the Netbox API. It saves us from crafting our API calls using the Python Requests library or the like¹.

Where I see it especially useful is when it comes to how easy it makes it to search, update or delete existing data. Once you understand its structure (hopefully by the end of reading this post you will), you find it intuitive and easy to get useful work done quickly.

In this post, I’m going to walk you through the installation of the dockerized version of Netbox from the very beginning until having a working instance, exploring its REST API using Insomnia (similar to Postman but with support for SOCKS proxy), and finally using Python to make API calls.

In this post, I’m going to walk you through how to set up an environment that can be used for testing what’s been called these days “Cloud Native Data Centers”, including underlay/overlay protocols, network automation scripts, zero-touch provisioning, monitoring, observability amongst many other things.

In order to build this, we’re going to use Vagrant combined with Libvirt, which uses KVM as the hypervisor. I’ve chosen Libvirt over Virtualbox due to its better scalability and portability beyond running some small tests in your home PC¹. You don’t normally see Virtualbox in Linux servers, but you do see KVM.

The great think about Vagrant is that it uses text files to describe the entire network topology, this allows us to use git for version control and to automate the creation of the test environment - no need to waste time pointing and clicking in a GUI.

There’s a bit of a learning curve understanding the text file that Vagrant uses to describe the topology (called Vagrantfile). Hopefully, after you read this blog post, you will be able to create you own topologies without any issues.