We constantly hear people talking about network automation, now it’s time to understand the most basic components required to create a full IaC ( Infrastructure as code ) pipeline. This article will break down network automation end to end, providing insight into all components of the IaC pipeline. There are four major components to the pipeline which are required, Source of Truth( SoT ), version control, Validation, and automation. Each of these are things that have been used in the network industry for a while but with the modern practice of NetDevOps, we combine them to create the full pipeline.
Source of Truth
The source of truth is our centralized storage of all configuration directives for devices in our infrastructure as code pipeline. This is where all changes are made, it’s our living, breathing, ever-changing source of documentation. We always consider this to be the accurate configuration of a device. In the past, we’ve used Excel spreadsheets, documents, and wiki’s as our sources of truth. While these worked they don’t provide an easy interface to communicate with the other pieces of the IaC pipeline. I have 2 choices I consider when deciding on my SoT, Netbox, and DoltHub. Netbox provides a great SoT as it has components for DCIM, IPAM, Devices, Circuits, etc. It has an easy to use web interface which makes changes easy to initiate and information easy to access.
My other choice for our SoT is great for more advanced pipelines and allows you to have much more control of your data and how it’s stored, enter Dolt. Dolt is a data format and database, it stores data in a SQL database but leverages the power of GIT for version control. As you probably imagined this allows us to combine two aspects of the pipeline. The applications for Dolt are immense and is going to change how our SoT operates in the future.
The next component is version control, just like SoT, this isn’t a new concept or technology. However, the application of using it in networks is, with version control for network configuration you have an exact copy of the network at any point in time. If you leverage tools such as JSNAPy you can even have a snapshot of the network state at that time. With version control every time we make a change to the network we merge the new configs generated to the master branch of our infrastructure as code. This master branch is then an exact copy of all the configurations on devices in the networks. With all configurations in one nice repository we can easily search, view, and see historical changes with comments explaining what the change was for. Using software such as GitLab you can also leverage its merge approval feature to have a “code review” of the proposed configuration changes from a network engineer before it’s implemented into production. This approved merge request can automatically talk to our automation component to generate and push new configurations to the network.
As I mentioned above with Dolt it has built-in versioning so we can combine our SoT and version control components into one. With Dolt you can easily see proposed configuration changes, fork the master branch to make changes, then place a merge request to have the changes implemented into production.
One of the most important components of the infrastructure as code pipeline and NetDevOps is network testing and validation. Unlike in the past where we made changes directly on devices and hoped for the best, we are now constantly testing our changes before and after implementation. This then translates to less downtime and unintended consequences. Utilizing a tool such as Batfish you can analyze your configurations to find errors and validate for the correctness of network configuration functionality. The major benefit to batfish is it does not need any actual network device ( physical or virtual ) to analyze the configurations. You can instantly get notifications of potential errors such as, misconfigured BGP sessions, ACL blocking traffic to unintended hosts, and allowing traffic to unintended hosts.
We also employ network state analysis, we analyze the state of a network before and after intended changes. We do this both in the QA environment and production. For example, before we implement a change to routing configuration we would take snapshots of the routing table, BGP peers, and OSPF adjacencies, and tail the logs for any recent errors about either protocol. The change would then be pushed to the devices and we would take another snapshot of the network state and compare to see if it had the intended consequences we expected. If it did not we can either automatically roll back or notify the engineer.
Finally, we talk about the actual automation part of network automation! This component ties everything we’ve read about up to this point together, it’s the conductor of the IaC orchestra. At NetSyncrio we primarily use Ansible and AWX , Ansible is a low code automation solution, and AWX provides a web interface to manage your Ansible environment. One-piece we didn’t mention yet is templating. Templating takes our device configuration information from our SoT and converts it to vendor-specific syntax. For templating we use Jinga2 to easily generate configuration. Ansible has modules for most major network vendors to easily manage them, and for older legacy systems there are workarounds that can get the job done.
Now Ansible isn’t always the answer, some times we need to accomplish very specific goals and this is where we leverage Python. Python allows us to create a fully customized solution to a specific problem. Since Ansible modules are written in python we can also turn this solution into an Ansible Module to keep things standardized.
Infrastructure as code components in review
As you can see there are many options for how to create your IaC pipeline. There is no cookie-cutter answer but through strategic planning and sticking to the standards of NetDevOps we can craft a solution that’s perfect for you. If you have any questions about this contact us by phone or email to receive your free consultation.