Chapter 2 Why Automate the Network?

"The remains of the old must be decently laid away; the path of the new prepared. That is the difference between Revolution and Progress."

- Henry Ford

The time for change has arrived. Enterprise networks have outgrown and outpaced the ability to effectively manage and maintain themselves using traditional tools. Historically, network management meant manually gathering point-in-time information from, or making configuration changes to, individual devices. Networks are often designed using a configuration command-driven approach, as opposed to a data-driven approach. Staff manually execute commands at the CLI to gather information or perform changes. Information is often regathered to confirm the state of the network after changes are made. The ongoing creation and maintenance of network documentation is also performed manually. Hours of effort is required to make changes, often repeating the same commands only on different devices. Inevitably, troubleshooting is required because of errors made using the manual methodology. Network automation solves all these problems.

Scale The size and scale of the modern network has grown exponentially to accommodate the needs of organizations. Networks that started out as a few switches and a router are now large-scale enterprise networks. While logical networks evolve and grow, the tools used to manage physical devices remains stagnant. On the campus we now see VoIP phones, wireless access points, IoT, security cameras, print fleets, desktop fleets and meeting room equipment. In the data centers large physical and virtual footprints are not uncommon. World-wide WANs, with switching and routing in each remote office, is now common place. The device boom has not slowed with even more devices being added to networks without the appropriate centralized, automated, management solutions available.

Network management starts with the console cable and a local CLI. Remote access to the CLI over a management IP address must be enabled by the administrator. Now imagine network technicians still needing to go to the physical console of every device to manage it. It sounds unreasonable, but only remote access to the CLI has been centralized. The same methodology of logging into the CLI to manage the device is followed as if the operator is virtually at the console. In fact, these remote connections are known as virtual teletype, or VTY, lines. At the scale of today’s networks, connecting to the CLI of every device to manage the enterprise is simply unachievable. Even with a large capable network operations team, everyone is going to operate, configure, and manage each device their own way. This leads to configuration drift and a lack of consistency at scale.

Automated solutions scale with the network as device configurations are templated. Small, feature specific, modular templates ensures each device is standardized. When new feature requirements arise, the configuration commands are templated and released at scale, updating the network standards uniformly. Unique, device-specific, meaningful information is modeled in a data dictionary. This dictionary holds all the variables used to compile a unique configuration for each device. Code can be written modularly to match the topology of the network. By creating playbooks specific to the environment, such as campus, data center, WAN, or cloud, Ansible playbooks ensure code simplicity, readability and development flexibility.