Enter the Source of Truth

So in my last post about The Four Stages of Automation (or was it 5?), we talked a lot about this mythical inventory that just sort of magically produced all the information you’ll need to automate provisioning and configuration of the network. Not surprisingly, it isn’t magic, and of course the inventory doesn’t just appear out of thin air–it comes from the network source of truth.

This will be out of date in about 20 minutes
This will be out of date in about 20 minutes

A source of truth (lowercase) is the definitive data store of what’s installed and configured in a particular network, and in the old days for most companies, the de facto source of network truth was all over the place. Depending on the sort of info you were talking about, it was router and switch configs, spreadsheets, billing databases, ticketing systems, IRR and/or RADB, NMS systems and DNS servers. Basically if you wanted to know what was installed and configured, you went and logged into the router, and when that didn’t help, you logged into a bunch of other things and put all the info in a spreadsheet that quickly became just as unhelpful.

Now that we are focused on automation, we need something better: enter the Source of Truth (SOT). This is a web app and database designed to be the central storehouse of network data, usually with these features at a minimum:

  • Data Center Infrastructure Management (DCIM)
  • IP Address Management (IPAM)
  • API(s) for using the SOT as an inventory for automation

The big idea behind the SOT is to store all the inventory data here, decide on your policy, then use that to generate intended device configurations that you push to the devices, rather than the other way around.

It can of course take some time before you are ready to do this (hence the stages). And the SOT can of course still become inaccurate if stakeholders are not on the same page, but with increased automation comes the option for increased validation–you can set policy on what goes into the SOT just like you can for what goes out to devices.

Demo of netbox - create a login to see example data
Demo of netbox - create a login to see example data

There are many proprietary sources of truth out there, but for any organization that has the skill and wants to keep the flexibility of open source software, netbox and nautobot are the way to go. The bigger question, however, is which one to choose, and I will leave that as an exercise for the reader. Nautobot is actually a fork of netbox, so they are very similar, but have some differences, mainly in the plugins that are included vs. encouraging users to develop their own generally speaking. Both have demo instances, so I highly recommend taking each for a test spin and seeing what you like about each:

In the past I’ve used an older version of netbox so am not as familiar with its capabilities today, and have used nautobot more recently, so will use it as an example here of some of the basic SOT features.

DCIM

Data Center Infrastructure Management includes, but is not limited to:

  • Sites - locations where there is network equipment
  • Racks - where the equipment is physically installed at a site
  • Devices - switches, routers, patch panels, etc.
  • Interfaces - ports associated with each device
  • Circuits - a link connecting two endpoints, typically with A and Z terminations
  • Cables - the physical connections between device components/ports

For example, if you navigate to a site such as LHR in the nautobot demo, you can then see that it has 3 racks, and then if you click on one, you can see a visual depiction of what’s installed in it.

LHR site Rack 101
Sites and Racks in nautobot

If you click on one of the devices, you can drill down into interfaces, which includes IP addresses, media type (copper, fiber transceiver, etc.), connections, and descriptions (if populated).

interfaces

IPAM

IP address management in a source of truth generally involves the following:

  • Create aggregates for supernets assigned by an RIR
  • Create container subnets for regions, sites, or specific services
  • When an address or subnet is assigned to an interface or VLAN in the DCIM, it’s recorded automatically in the IPAM
  • VLAN and VRF assignments are also managed in IPAM

ipam

API and Inventory Generation

To generate inventory for automation templates, you are going to want to query the source of truth via an application programming interface, or API. Nautobot has support for REST API and Swagger as well as GraphQL, and many of the built-in functions accept a GraphQL query as input. For example, a (grossly simplified) GraphQL query for IP address, followed by its output:

Graph QL IfIPQuery GraphQL Output

j2template Which can be applied as Jinja2 variables in a template for the associated interface, and generates text that looks exactly like that of an actual router interface configuration.

Depending on your stage of automation, this can be used for compliance or pushed directly to the router.

interface Ethernet1
 ip address 10.6.192.5/32

Next in the automation series, I’ll probably tackle the job of backing up configs with nautobot, but now I have a hackathon – the theme of which is “Interacting with Sources of Truth” – to attend!