Chapter 2 Why Automate the Network?
For diagrams, tables, or exact code formatting, .
headaches related to deploying configurations to the network. Deployment time is drastically reduced when using Ansible playbooks while quality and accuracy significantly increases.
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, 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 can be automated, it will allow the operations team to focus on the day-to-day aspects of the network management along with new automated tools used to gather the information needed to run the network. With that said, the network may still have the need of an NMS for platform health monitoring. 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 focus can be put on the data models. Intent for each device or group of devices can be expressed in a human-readable form. Idempotent Ansible playbooks combined with check mode can tell exactly if a device’s running-configuration matches 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 and can also be displayed indicating any commands present on the device but missing from intent.
New appliance-based solutions are available that offer a GUI-driven intent system. 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. 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 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?
Using the new NDLC, a living source of truth in TFS exists. A rich repository containing data models, templates, and Ansible playbooks which also stores the compiled, intent-based, dynamically generated configuration files for each device. TFS is a single, central, RBAC controlled, source of truth for the network. TFS repository can be used as a reference for all future network designs and troubleshooting.
