When it comes to network automation we can’t forget about the real foundation – the single source of truth. What would we do without it? You can have the best automation scripts possible, but without a complete database of your network equipment, they might be inefficient. Having one place where you have a full list of your equipment is a good foundation for automating your network
In this article, I want to share my point of view on the methods that allow us to gather a list of network devices, that we can further utilize for network automation. It’s based on my knowledge and experience, so keep in mind, that there are also other methods available besides those presented below.
Before we take a look at that, first let’s clarify what actually means a single source of truth.
What is a single source of truth?
For me, it’s a place where I can get a complete list of network devices. The more details I can get about particular devices, the better. The absolute minimum is a hostname and IP address. Based on that, I can build a list of network devices, that can serve my automation scripts.
There is one more important attribute to have in the single source of truth – device OS. It’s essential if you have a multivendor network environment. CLIs are different between vendors. Even the same vendor can have multiple OS’es with differences in CLI. Cisco is a good example of that. We have various versions of Cisco IOS and also Cisco NX-OS. Nokia also has its SR OS and SR Linux. To be able to automate the network efficiently, we have to distinguish what OS is on which device.
Now, we know what we’re looking for. It’s time to take a glance at what methods we can use to build our single source of truth.
Ready? Let’s dive in!
In my personal opinion, no. 1 when it comes to storing information about network devices. There are plenty of them on the market, both with free and paid licenses. The features of each IPAM are different, but the core functionality is similar. You can add subnets to the database, and it helps you to track information about particular hosts. Often you can put information such as:
- physical location
- serial number
This gives you a clearance about what’s hiding behind a particular IP address. Some IPAM systems give you also the ability to add a custom column, so you can store even more important data there.
Most systems also scan added networks, which gives you an overview of devices that are reachable, but also highlights those not responding.
Because we can store so much valuable data in the IPAM, for me, it’s the best method of building a single source of truth. A lot of IPAMs offer REST API interfaces, which is invaluable for network automation. With just one call, you can gather a list of network devices from a particular vendor, physical location, or with a specific OS.
Not all network companies have their own IPAM systems, so this method could be unavailable for you. Some companies have it, but they are not up to date, because some administrators are not always updating documentation after making changes in the network (not blaming anyone, it’s me also). In such situations, you may not want to use IPAM to build a single source of truth. In the next section, I’ll show you another method to get an up-to-date list of network devices.
We, the network administrators are often using services that make our lives easier. Can you imagine being an administrator of a large network (1000+ devices) without a AAA service? I absolutely do not!
Those services often have a configuration file with a list of network devices. That’s what we’re looking for! It’s not a perfect solution, but those files are often up-to-date because if something is missing in the file, the network device won’t work with that service. A couple of years ago, I used a freeRADIUS configuration file for building a list of network devices, because it was the most reliable list.
But what if you don’t have IPAM or such a service in your network? Maybe you’re administrating a small network with several/dozen network devices. In such a scenario, a basic file with a list of network devices may fit you.
It’s not a bad idea to keep track of your network devices in a text file unless your network is small and is not constantly changing. There are many formats that you can use to store data in a text file – XML, CSV, JSON, YAML, or your custom one.
I personally use YAML whenever I can. Sometimes I’m forced to use JSON, and I’m also OK with that. Generally, a good practice is to use standard formats, because they are well-known by other engineers, and there are already written libraries for many programming languages. In the network automation realm, YAML and JSON lead the way. Sometimes you might encounter an XML, but it’s considered as obsolete.
The last section is about high-end network systems, which also can be used to build a single source of truth. Those are often offered by the network equipment vendors, to manage their devices. Let’s take a look a the examples:
Those systems have a list of network devices added to them. We can use it for our automation purposes. The huge advantage is, often they store a lot of information about added devices, so we can use this data. However, there are also disadvantages. Enterprise-grade systems often are vendor or OS-specific. It means, that you can’t add for example Dell switch to the Cisco SD-WAN system. If you have a homogeneous network, it may work for you, but with multiple vendors, it can be nearly impossible to add all of the devices into one system. What’s also worth mentioning is, if you have such a system, do you still need to write your own scripts? They often offer some kind of automation, and in many cases, that should be enough.
The more accurate data you have, the more efficient your automation will be. It’s as simple as that. If your single source of truth that’s outdated, your scripts won’t reach all of your devices, or they might configure them incorrectly. That’s why it’s essential to have a reliable source. It can save you a lot of stress, frustration, and man-hours.
Do you already have such a source, or you don’t, and you even don’t know where to start? Don’t worry, in the next article, I’ll cover methods that will help you to build a reliable data source.