Where to Start?
You have been tasked with implementing a new network automation solution. You open the documentation: a wiki page that is outdated, and you see a lot of Excel sheets with different versions of the same information. And team members are telling you to just log into the devices to get the information you need.
The network has been built over the years with different architects, engineers, and administrators, each with their own approach to documentation and configuration management. As a result, the network is in a state of chaos, with inconsistent or outdated documentation, configuration drift, and misconfigurations.
What would be the first steps? Building Python scripts? Using Ansible playbooks? Or maybe a new network management platform such as Cisco Meraki? While these are all valid approaches, they often fail to address the root cause of the problem: the lack of a reliable Source of Truth.
What is a Source of Truth?
“Source of Truth” gets thrown around as a sales slogan, and it’s often misunderstood. A Source of Truth is a single, authoritative repository of information that in our context is used to store infrastructure data, such as network devices. For instance, such a repository for network devices would include information like Vendor, Model, Serial Number, Location, and IP Address.
But we already have a Source of Truth, right? We look into Solarwinds or Infoblox to see the current state of our network devices. We can consider these platforms as Sources of Truth, but not as a ‘Single Source of Truth’. A Single Source of Truth could be seen as a single looking glass into the state of your network infrastructure, where it’s synced with all the Sources of Truth that you have in your environment.
Below you will find an illustration of a Single Source of Truth, where it is synced with multiple Sources of Truth, and provides a single view into the state of your network infrastructure.
Having a Single Source of Truth allows you to have a central place where you can view multiple attributes of a device, like we mentioned before, Vendor, Model, Serial Number, Location, and IP Address. So instead of looking into multiple Sources of Truth, you can look into one place to get the information you need.
Why do we need a Source of Truth?
Without a Source of Truth, how would you know the state of your network infrastructure? A logical step is to look at the current state of the network devices, by looking at a monitoring platform, logging on devices or looking at documentation.
But what if the monitoring platform is not up to date, or the documentation is outdated, or the devices are misconfigured? Without a Source of Truth, you are left with uncertainty and risk.
What does a Source of Truth solve?
Many network engineers have experienced the frustration of dealing with inconsistent, outdated documentation, configuration drift or misconfigurations. So what can it solve?
- Inconsistent Documentation: A Source of Truth provides a single, authoritative source of information that can be used to ensure that all documentation is consistent and up-to-date.
- Scattered Information: A Source of Truth consolidates information from multiple sources into a single, centralized repository, making it easier to access and manage.
- Configuration Drift: A Source of Truth helps prevent configuration drift by ensuring that all devices are configured according to a single, authoritative standard.
To put that in perspective: A network engineer looks at an Excel sheet and sees that the IP address is missing to log into a device. The network engineer then looks into the monitoring platform, and sees that the device is being monitored on the incorrect IP address. The network engineer then guesses the correct IP address (based on their experience) and logs into the device and finds that the SNMP configuration is set on the incorrect IP address.
With a Source of Truth, none of that would have been necessary. The network engineer would have looked in one place, found the correct IP address, and logged into the device. No cross-referencing three systems, no guessing, no surprises. The misconfiguration would have surfaced as a discrepancy against the authoritative record, rather than being discovered by accident.
What does a Source of Truth look like?
Instead of starting theoretically, let’s look at some practical examples. There are already tools that can offer a Source of Truth, you can browse to these tools and see what they offer. Have a look at the following tools:
- Nautobot: An open-source network Source of Truth and network automation platform that provides a centralized repository for network data, including devices, configurations, and policies. Link: https://demo.nautobot.com/
- NetBox: Another open-source Source of Truth and network automation platform that offers similar functionality to Nautobot, with a focus on IP address management and data center infrastructure management. Link: https://demo.netbox.dev/
So what information do these tools typically include? Here are some examples you would typically find for network devices:
- Location: The physical or logical location of the device within the network.
- Device Type: The type of device (e.g., router, switch, firewall).
- Vendor: The manufacturer of the device (e.g., Cisco, Juniper, Arista).
- Model: The specific model of the device.
- Serial Number: The unique identifier for the device.
- IP Address: The IP address assigned to the device.
What you see here is a model that can be used to represent network devices in a Source of Truth. This model can be extended to include additional information as needed, such as configuration details, firmware versions, and more.
Conclusion
We started this article in chaos: outdated wikis, conflicting Excel sheets, and configuration drift. We haven’t fixed any of that yet, but we have defined the destination. Before you can move from chaos to order, you need to know what “order” looks like, and that is the Source of Truth.
With the destination defined, Part 2 is where the journey begins. We will discuss how to implement a Source of Truth in an environment with inconsistent or outdated documentation, and the best practices for keeping it reliable over time.