Truth is subjective, at least in the networking world. A switch may have one IP address assigned to it and have a completely different IP address in the IP address management (IPAM) spreadsheet. Perhaps you think a router is located in the third rack from the end in a specific data center row when it has, in fact, been relocated two moves ago. And we won’t even talk about updating hostnames for devices.
The fact is that our version of the truth of a network is only as real as the documentation. If it is inconsistent with reality, we’re working from a known untruthful state. If reality is several steps out of date with a dusty old binder full of bad information, we’re going to find ourselves failing the hit by a bus test. But where can we store that information and keep it up-to-date?
A variety of tools have been created over the years to try and serve as a database for this source of network truth. Some have been successful and several more have not. One of the things that have caused some of those unsuccessful tools to slide off of the rails was their attempt to be a single source of functionality instead of a single source of truth. Maybe they started out as a documentation hub. But then they quickly turned into a DNS server, DHCP server, or even a full-blown network monitoring solution. And once you fly past your intended goal of doing one thing really well you start forgetting why you were created in the first place.
Defining the Limits of Truth
If you’re in networking, hopefully, you’ve heard of NetBox. This little tool was masterminded by Jeremy Stretch when he worked at Digital Ocean. The idea was simple. It needed to fill the network documentation need of the company. It needed to house IPAM information, device-specific info, credentials, rack locations, and more. In essence, it needed to serve as the single source of truth for a large organization. Stretch has since made NetBox available for use by the rest of the community. He now works for Network to Code and maintains NetBox while he helps with the automation side of things for them.
Here he is presenting during Networking Field Day 21 last year:
Firstly, I love that he is very upfront about what NetBox isn’t. This is not a one-stop-shop for your DNS, DHCP, or monitoring needs. This tool is built to be a source of truth for other programs. Why is that important? Remember how I told you earlier that networking truth was often subjective? It is only that way if you don’t have one place to pull from. NetBox makes your network truth objective.
How can it do this? It offers API access that can let programs like Ansible or Puppet pull the data and create the declarative configuration on devices. The system automatically configures devices based on where they are supposed to be and how they need to be configured. New top-of-rack switch installed? Enter the data into NetBox and use Ansible to program the switch when it comes online. Need to configure a new interface on a router? Program the interface IP information and let the automation tooling do the rest.
Now, one of the biggest complaints I get from people is that it’s hard to do this multistep process. Why not just SSH to the system and set the information yourself? It’s quicker, right? Quicker doesn’t always mean better though. In this case, making changes outside of a tool like NetBox could lead to problems down the road. What if you incorrectly configure the interface mask? What if you program it and find that the address was taken so you increment by one to fix the issue. What if you forget to document all of those modifications? The network truth becomes subjective again because you no longer have a single source of truth.
Network automation needs a consistent source of truth that is always correct. If you don’t have that, you’re building a fragile framework on top of shifting sands. It won’t take long before everything crumbles down around your ears. Something as simple as figuring out how to document MAC addresses is hard when there are several different formats to store them. Having one consistent database that you update when changes need to be made means that those changes are implemented without being inconsistent.
Bringing It All Together
NetBox solves a huge problem I used to have in my VAR networks. I made changes and nothing got updated. Or worse, still, someone else made changes and I couldn’t figure out why or when. By creating a source of truth and ensuring that we use it to program our network, we’re never out of sync with the documentation. I know a few laggard network admins are going to complain about doing the extra work to use NetBox as the database for information and having tools program from that source of truth. However, if you don’t do a little extra work up front, you’ll find yourself doing lots of extra work when things fall apart.
For more information on NetBox and the rest of the Network to Code automation solutions, make sure you visit their website at https://www.networktocode.com
Nice summary of NetBox and the concept of Source of Truth Tom!
I’d suggest that as you get further along the path of network automation towards Intent-Based Networking you actually need two “sources of truth”:
one to express the intent – “This is how I want my network to look” – and this is where NetBox would sit, representing the desired state of the network to act as a source of configuration data and policy information for your automation; and
one to show the current state of the network – “This is what my network looks like now” – where a product like IP Fabric excels.
Once you have these two – a Source of Intended Truth and Source of Observed Truth if you like – you can diff the two and determine how to fix the drift between them. And then you have an Intent-Based Network without the marketing BS 🙂