Chapter 1 What is Network Automation?

o A working branch per change is created. Developers perform Git commits often within a

working branch. o Approved pull requests are used to merge tested code from working branches into the

master branch.  Version control is established on information gathering Ansible playbooks:

o In concert with the branching strategy version control becomes apparent. o As Ansible playbooks are refactored over time TFS will contain the change and version

history. o In addition to Ansible development skills, operators start to familiarize themselves with

Git.  Playbook library:

o Network engineers can work with the network operations team to find the most common

manual commands used for network reconnaissance. o These commands are transformed into automated playbooks that operations can start

using to troubleshoot or gather information from the network. o Working playbooks are easily cloned, refactored, and added to the library by operators or

engineers. Building on these principals, the organization starts to gradually embrace network automation without risk. The power unlocked will become evident immediately and the organization can start considering a wider scale adoption and automating changes to the network. Chapter 6 contains more details and concrete examples that can be used on the network today.

There is always risk associated with making changes to the network. Despite the best designs and architectures some changes are disruptive, and outages cannot be avoided. Networks also have the largest blast radius in the enterprise. The scope of change impact increases the closer to the network core changes are made. For example, an entire building can be isolated from the network if changes cause an outage at the distribution layer. If the network is down, almost every other aspect of the organization is impacted in some way. Uptime is of the utmost importance to an organization because of the business impact network downtime can cause. These factors can lead to an extremely risk adverse view of network operations. The less change the better.

The biggest challenge in network automation is an organization’s willingness to adopt it. Despite obvious benefits, which become clear throughout this book, there can be a lot of resistance to this type of revolutionary change, particularly regarding changes to the network. This mindset is also at odds with the modern pressures and business demands of the network to be, ironically, constantly changing. Network automation is in fact a safer and more reliable approach, partly because it all but eliminates manual error.

Making one-time, tactical configuration changes is a great place to move from automating network reconnaissance to automating changes to the network. A one-time change to the network or a tactical configuration change is something that will be done once and is throw away work. These are often tedious jobs when performed manually at scale. Oversites in design may be found in production leading to required corrections. Perhaps legacy code has become deprecated and needs to be replaced. Maybe standards or conventions were not followed leading to a non-golden configuration. Net-new requirements, for example a new Dynamic Host Configuration Protocol (DHCP) server, will frequently arise during normal day-to-day operations. Every organization is different, and each network is going to have unique requirements and challenges. Here are some opportunities for tactical, one-time changes that can be automated: