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.