One of my subscribers sent me this question after watching the second part of Network Automation Tools webinar (or maybe it was Elisa Jasinska's presentation in the Data Center course):

Elisa mentions that for a given piece of data, there should be “one source of truth”. It gets a bit muddled when you have an IPAM tool and Git source control simultaneously. It is not hard to imagine scenarios where these get out of sync especially if you consider multi-operator scenarios.

Confused? He provided a simple scenario:

If you are using Git to source control device configurations, these configurations contain information that is also in the IPAM DB. Alternately, if you kept IP/Device information in source files which are managed with Git, this would not be an issue – but that is a somewhat less friendly means of accessing the data.

As Elisa explained:

• There should be a single source of truth for any type of data;
• The data should be easily consumable (preferably through an easy-to-use API).

Relying on device configurations to store device names, SNMP community strings, router IP addresses, and IP subnets somewhat satisfies the first requirement (if we ignore the need for unique key and referential integrity constraints), but falls far short of satisfying the second one. You could use something like the F script to continuously extract data from device configurations and compile it into a database, but it’s much better to admit defeat and reverse the process:

• IPAM data is the single source of truth for device names, interface addresses and subnets;
• Auxiliary data needed to configure network devices (syslog servers, NTP servers, SNMP communities) are in a YAML file or simple object-oriented database (more about this topic in a follow-up post);
• Device configuration templates are managed by a source control tool like Git;
• Device configurations are generated from templates and IPAM+YAML data;
• While you’re collecting device configurations and keeping track of changes in another Git repository, that’s just a safeguard and a convenient method of identifying out-of-process changes made directly on the devices.

You might have noticed that I haven’t mentioned a single unicorn-based SDN or automation tool – no technology will save the day until you realize you have to change the process.

We’ll talk more about data models, building device configurations and deploying them, and validating input data and deployed configurations in the Building Network Automation Solutions online course. All you have to do to be part of that discussion is to register.