Chapter 1 What is Network Automation?

 A new project has network requirements or changes are required to the network.  An administrator collects the data, possibly from multiple devices, often manually, to assess the current network state to draft the change.  The change might first need to be developed and tested in a non-production environment or an impact assessment might need to be performed if the change is deemed disruptive.  Configuration commands are developed.  Once tested and ready, changes are submitted into a ticketing system and assigned to a network operator.  The operator reviews the change artifacts and implements the change manually by following a series of instructions.  Pre and post-change information is gathered to validate the change. This often takes a substantial amount of time and will be point-in-time information. If things do not go well or mistakes happen, it is often difficult to identify the root cause or confirm the operator followed the correct steps error-free. Problems caused by a change are usually discovered because of an outage. Ideally, network monitoring system alarms are triggered but in a worst-case scenario, it is a user who reports the issue. Manual troubleshooting and problem resolution is necessary as well as manual updates of all relevant and affected documentation. Network automation solves all these problems while drastically reducing the time and effort involved in gathering information, resolving problems, and deploying changes to the network.

Aside from safe, pre-approved changes, the majority of network configuration changes occur after business hours. Several network administrators may be required to perform changes manually at a larger scale or a longer change window may be required by a smaller team. By automating solutions, the organization can dramatically reduce outage windows as well as the operator hours required to implement changes. Changes that previously took hours of execution time can now be performed in seconds.

The drawbacks and problems inherited by the tools such as a console cable, Telnet, SSH sessions, and a keyboard have impeded the progress of modern networks, especially at scale. Putty session copy-paste only goes so far. A lot of Network Management Systems (NMS) have immerged from both hardware vendors and third-party companies trying to fill the need for better network management tools. However, due to the huge number of features an NMS must offer (monitoring, reporting, configuration management, provisioning, capacity, utilization and performance statistics) large NMS systems tend to do a lot of things well but nothing great. Intent-based solutions are only starting to immerge as appliances or software and are only capable of delivering solutions for a single vendor. NMS solutions involve licensing and can become costly as the network scales. Most NMS require training to be fully leveraged and are often underutilized by an organization either due to a lack of the NMS’s ability to provide solutions or the complexity of being able to build solutions in the NMS.

Operational Challenges Many challenges exist with the legacy approach to managing networks either through CLI device-to- device or through complicated, expensive, NMS solutions that still require a great deal of CLI work.

The following is a brief list of key problems inherent to the legacy approach:  No source of truth.

o Networks often lack a source of truth: an authoritative artifact that can be referenced for what

the desired working configuration of a device or set of devices is.