Operations, Intentions, and Source of Truth

Operations

NetDevOps will dramatically change network operations’ role in the organization. A library of canned, automated, Ansible playbooks develops over time. Automated builds and deployments will trigger whenever approved changes are merged into the repository. Operations are often tasked with running the network day-to-day, and incorporating and deploying the changes coming from projects or network engineers. Operations will now learn to develop and use code.

If the deployment, network reconnaissance, and documentation aspects of operations are automated, the operations team can focus on the day-to-day aspects of the network management alongside the new automated tools that gather the information needed to run the network. With that said, the network may still require an NMS for platform health monitoring.

This is because there may be network appliances or controllers that are not good candidates for automation. Or, there may be non-SSH systems on the network that are non-automatable using Ansible.

Intent-based

The human-readable nature of this methodology allows for a true intent-driven model of the network. The configurations are abstracted into the templates, so the focus can be put on the data models. The intent for each device or group of devices can be expressed in a human-readable form.

Idempotent Ansible playbooks- combined with the check mode- can tell exactly if a device’s running configuration matches the intent and if the Ansible playbook would have added code. Utilizing the differential option (--diff) allows the operator to see what differs between the two configurations. It can also be displayed indicating any commands present on the device but missing from intent.

New appliance-based solutions that offer a GUI-driven intent system are available. Drag-and-drop intentions in the GUI are translated to configurations that are automatically pushed to the devices. These new intent-based appliances are the biggest competitor to Ansible network automation. Either purchase and configure the appliance, hoping it does everything advertised, or build an in-house Ansible automation framework.

Source of truth

Every network should have an authoritative artifact identifying what is the correct, intended configuration for each device. The source of truth is a trusted artifact that network engineers and operators can reference with certainty. This can be an IP address, a static route, an ACL, or a configuration command. It can be required when designing new solutions, adding new devices (scaling), troubleshooting problems, or rebuilding a device after failure.

Where is the network’s source of truth? Is it a network management system? Flat files in folders in a network share? A Microsoft SharePoint site? The network device running-configuration itself?

A living source of truth can exist using the new NDLC. It is a rich repository of data models, templates, and Ansible playbooks, which also stores the compiled, intent-based, dynamically generated configuration files for each device. This repository can be used as a reference for all future network designs and troubleshooting. It can also be a single, central, RBAC-controlled, source of truth for the network.

Source of truth means browsing for data models or templates that create the configuration or the compiled output showing the exact device configuration, without ever needing to connect to the device CLI. Other artifacts such as the routing tables or firewall rule lists can also be stored in the source of truth as output from dynamic playbooks. This is not something every network can produce. However, it is indispensable when designing new features, planning future changes, dealing with network failures, or troubleshooting problems.