What to Automate Next

Many more components remain on the network that still use traditional CLI or NMS methodologies. Using the same processes, technologies, and techniques, go beyond the enterprise campus network and automate the rest of the network’s logical functions. Once the entire enterprise network is automated, the scope can increase to include devices like load-balancers, storage arrays, Windows and Linux servers, and anything else that can be connected using SSH.

Data center

Ansible has supported modules designed for the enterprise data center, including NXOS modules for the Cisco Nexus platforms. Much of the code can be reused from the campus to the data center by refactoring the modules from ios_command and ios_config to nxos_command or nxos_config.

The topology in the data center may be like the campus network, with a core or possibly collapsed core and distribution layer, and an access layer where servers and appliances connect to the network. A whole list of new technologies and features to data models and templates become apparent. vPC, FEX, and storage protocols, such as FC, FCoE, or iSCSI, need to be included in the solution.

WAN

Software-defined WAN (SD-WAN) is one of the trending technologies utilizing appliance NMS-based solutions. Using Ansible and the network automation framework, build our own SD-WAN, migrating our WAN solution to the intent-based automated network management framework.

WANs are perfect candidates for automation. This is because they are often cookie-cutter templates configured device-to-device with only small changes to each making them unique (hostname, management IP, etc.) on the network. There will be some unique data models and templates required for the automated WAN solution. Multiple layers to the WAN exist, including the head-end in the campus and the spokes at each office. Automated coverage can extend to each office’s spokes equipment, and any switching connected behind the spokes. VPN configurations, possible encryption or IPSec configurations, routing and switching, wireless, possibly DHCP and DNS services, and other WAN-specific features and technologies need to be modeled and templated.

Load-balancers

Traditional network devices are not the only devices that can be automated. Load-balancers, particularly F5 devices running BIG-IP, have an extensive library of Ansible modules available to be leveraged. The same principles and approaches can be taken with these devices to automate them as was taken with the network devices. Once the load-balancing configurations are automated, the concept of service-chaining can be introduced into the orchestration of automated playbooks.

Not only can the VRF, VLAN, associated routing, port-channel, and interface configurations be automated now, the organization can also orchestrate the required load-balancer requirements as part of the release and configure the network holistically as a service model approach. Full integration with the organization’s automated software release can be achieved ensuring the network, from Layer 1 – 4, is first deployed as part of a larger automated workflow. After the necessary network and load-balancer components have been automatically deployed, tested, and validated, the workflow can move onto the software release (i.e. set up of the database, permissions, push executable package).