Chapter 2 Why Automate the Network?

configuration is put in place using the automation engine.

Either method guarantees that all net-new network devices adhere to the golden configuration with little to no effort from operations. Also, by using the new NDLC, a dedicated working branch represents an exact point-in-time in the master branch of when the device was added to the network.

Peripheral changes made to accommodate the new device, for example, the uplinking device, routing tables, or other changes beyond the newly provisioned device itself, are captured in the working branch. The ability to perform side-by-side historical comparisons from before and after the change is available in the TFS history viewer and along with it being automatically provisioned, the new device also comes with automatically generated documentation.

Source Control

The following is another way of looking at source control, in the context of network as code. If only code from the master branch is deployed to the network, the state of the network at any given point-in- time is known. If there are no out of band changes, the entire history and evolution of the network is captured in the master branch history. Controlling this source code is extremely important given the blast radius a problem on the network can have. Locking the master branch, forcing working branches for all changes, implementing strong RBAC, and utilizing pull requests that require outside approvals, are all forms of source control TFS offers.

Version Control

Automated builds give a sense as to the “version” of the network code and device configurations. Using pull requests in TFS, changes from the working branch are merged into the master branch. This can trigger an automated build which captures the network’s state. Data models, templates, playbooks, tasks, documentation and Git commit history are all included as artifacts in a build. Build numbers increment as the network undergoes changes and vice versa. Begin looking at the network like software:

 Initial build 1.0.  Add feature – Netflow on distribution layer, all buildings.  Fix bugs – logic, bad data.  Build 2.0 – Includes Netflow and fixes x,y,z. Branching A Git branching strategy should be adopted and it should be kept simple. Make sure to create working branches for all changes. Also known as feature branches or bug-fix branches, working branches should be limited in scope containing a single change or feature. Within each working branch, use Git to commit changes frequently into the working branch. This allows for distributed development and multiple people to work on the same branch. Keep a high quality golden configuration as the master branch. Use pull requests to merge working branches into the master branch.

A Git branching guide is available here: https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=vsts