Network automation relies on a data repository to create network configurations and drive network validation tests. This repository has become known as a network source of truth (NSoT). The objective is to better control network configurations and validate that the network is configured and performing as desired, with the end result of improved support for the communication applications, which need that network to perform well. Let’s look at what goes into an NSoT and how it’s different from a configuration management data base (CMDB).
What is a Network Source of Truth (NSoT)?
A network source of truth is the centralized repository for data used by network automation tools to drive the configuration and management of your network. It contains configuration data like IP addresses, VLAN to subnet mapping, VXLAN configuration, interface configuration, network device adjacencies, and routing protocol parameters. Think of it as a consolidated data storage system for all the network’s configuration parameters.
Isn’t an NSoT simply another name for a configuration management database (CMDB)? Not really. The CMDB contains information about managing the network assets and their configurations. It includes life cycle management data like licenses, end-of-life dates, service contracts, and contact information. It is also a repository for change management information—when a change was made, what was the change, and links to incident management systems. In short, it’s a reflection of the network’s current state of operation and its history of changes.
Why Do You Need an NSoT?
The short answer for why you need an NSoT: You’ll want to know if the network’s operating configuration is different than what you intended.
The network itself can only tell you its current state, not whether it is configured and operating as you intended. For example, if half of a redundant configuration is operational, there won’t be an outage, but the networks resilience has been compromised. Here’s where the NSoT–which is independent of the network–comes in. By comparing the intended state with the current state, you can identify deviations to the intended state, and take steps to remediate them.
Combining the NSoT with automation creates a powerful tool for building, maintaining, and validating network configurations. The automation systems use data from the NSoT to create device configurations and load them into the network devices. Some automation systems can then identify differences between the generated configurations and the network device configurations, perhaps due to someone making manual changes. This is known as configuration drift, where the on-device configuration has drifted from the desired state. Once drift is identified, the manual change can be incorporated into the NSoT or it can be reverted if it was an authorized change. The same data can also drive a network validation phase—checking that the network is functioning as desired.
The core idea is that the data within the NSoT drives the automation system to accurately and quickly roll out changes to the network. Your transition from managing individual device configurations to managing the network as a system. It fundamentally changes our network configuration approach from treating network equipment as pets to treating them as cattle (see:
Resilient UC Infrastructure: Is It a Pet or Cattle?)
An added benefit less frequently highlighted is the ability to know what configuration elements to decommission when an application or service is discontinued. The NSoT tracks configuration items like IP addresses, routing neighbors, firewall rules, and switch interfaces, while the physical and virtual elements (compute, storage, VMs) are tracked by the CMDB. The combination of NSoT and CMDB allows the IT organization to decommission the physical/virtual infrastructure (CMDB) and remove the configuration items that supported this infrastructure (NSoT). A good example is removing old firewall rules and switch interface configuration when a server is decommissioned.
Creating a Network Source of Truth
Many of you are now probably thinking, “I don’t have a network source of truth. I have one source for different data, such as one for IP addressing, another for VLAN/subnet allocation, another for routing neighbors.” That isn’t a problem as long as there is only one source for each type of data that the NSoT needs. As an example, an IP address management system may be the authoritative source of address block allocations, while device inventory information could come from a CMDB. API interfaces make it easy to import data like this. The key is to identify the authoritative source for each type of data.
To set up your NSoT, you can choose from a variety of open-source systems (NetBox, NSoT, Nautobot, Ansible) and commercial systems (Gluware, Itential) and products by network equipment vendors. If you’re just getting started with automation, you should seriously consider working with a consultant who has done it before and can help guide the process.
Populating the NSoT is the next challenge. IP addressing is well supported across a wide variety of tools. Other data depends on the tool’s capabilities. You should expect to spend some time identifying the authoritative source of each data type and the best method for importing it. Don’t be surprised if you find multiple sources for some data types . You’ll need to resolve conflicts between the multiple sources and identify a single authoritative source. Note that other process may need to change to support that single source. In fact, you’ll often find that you need a mechanism to automatically synchronize data from its authoritative source into the NSoT. Once the authoritative sources have been identified, the network automation systems can then use the NSoT as a conduit for a variety of data sources – a central clearinghouse for network data.
Using a NSoT
It takes some experience to get the data model right. You’ll need to identify the level of data in your model. Conceptually, it would be easy to start with the same data definition process you’d use for per-device network design in which you specify each interface and IP address. Combining automation with the NSoT supports building a data model in which you identify the subnet/VLAN to use for each network segment and let the automation system choose the IP addresses to use for each device on that subnet. Suddenly, you’re working at a higher level and letting the automation handle the low-level address allocations. Take that to another level and consider a system in which you specify an address block for a full data center pod, and the automation system automatically identifies the subnets, masks, and specific IP addresses for the entire pod. Now you’re doing system-level networking.
Then use the NSoT to drive network validation after each change. Instead of crossing your fingers on each change, develop network tests to validate the expected state after the change is applied. If the validation fails, the change is rolled back. This process would ideally be used in pre-change simulations as part of a continuous integration/continuous deployment (CI/CD) process.
Summary
The NSoT is critical to successfully implementing network automation. The goal of automation is to make network configurations more consistent, automate the deployment of those configurations, validate that the desired end-state exists, and to facilitate removal of old configurations when systems are decommissioned. The goal is to create a consistently performing network upon which your business applications can depend.
You can extend the NSoT into a single source of truth (SSoT) for each application with the goal of eventually covering all of IT (or its most important elements). This could be a very challenging task, so it’s a good idea to start with small applications. The eventual goal is for the automation system to support a self-service infrastructure and a more agile business.
