Building Network Automation Solutions - September 2017 session

The introductory section of the September 2017 course covered the logistics, selecting the best tool for the job and discussion questions.

Patrick Ogenstad described his network automation journey, from writing firewall rules in Excel to deploying large-scale network automation solutions. As he progressed through the problems he solved on this journey, he also identified the lessons learned, pitfalls and takeaways.

Once you've mastered a tool, it's tempting to use it for every job no matter how suitable it is. Alternatively, there are so many tools out there that it's really hard to select the best one… and then there's the usual dilemma of choosing between open-source and commercial offerings. This section will help you get started - it describes typical challenges, differences between fixed-purpose products, platforms and tools, and gives you some selection guidelines. It also includes a few hints on how to study new tools more effectively.

One of the simple solutions that can increase the reliability of your network is comparing the network state before and after a change.

This case study describes:

• How you could collect and compare network state
• How to collect network state with Ansible and compare it with diff
• How to remove time-dependent information from the network state

NetQ is a tool developed by Cumulus Networks that allow you to validate proper operation of your network (BGP and OSPF adjacencies, LLDP neighbors...), log network state changes, inspect network state at any time in the past, and perform end-to-end path tracing including overlay-to-underlay mapping.

While configuring network devices with OpenConfig sounds really interesting, don't expect to be able to do it any time soon - the vendors are (as usual) very reluctant to add yet another layer of indirection on top of their already-bloated software.

David Barroso decided to fix that problem within NAPALM, and wrote a set of libraries (napalm-yang) that perform translation between OpenConfig (or any other) YANG data model and device configurations.

Most of the intent-based systems are nothing more than a fancy orchestration system with an abstraction layer. This section describes the many levels of abstraction you can implement in such a system, and the data models you would need to do it.

Orchestration systems with an abstraction layer usually use network- and services data models to describe the desired system functionality, and device (or node) data models to describe the target state of the system.

In every such system, someone has to perform the mapping between the high-level and low-level data models, and this section describes how you can do that with Ansible.

Every network automation solution needs an authoritative source of truth. This section describes how you can use IPAM tools (using NetBox as a sample tool to illustrate the concepts) to provide the source of truth for IP address assignments, IP subnet allocation, VLAN numbering, and even shared secrets like RADIUS keys.

Using Ansible device configuration modules to change parts of device configuration seems easy enough (as does replacing the whole device configuration with NAPALM)... but as always, you'll encounter numerous showstoppers and caveats when trying to use them.

This section describes the principles of managing network device configurations, the caveats of using Ansible device configuration modules, and the details of recovering from failures using configuration rollback mechanisms.

GitLab CI is one of the commonly-used networking-focused continuous integration tools due to its agent-based architecture.

In this section Pete Lumbis explained how he uses GitLab CI to test his network automation scripts and device configurations.

The discussion questions for Module#5 included limiting automation user access to network devices and the moment at which you should start adding compliance checks and validations to your network automation solution.

UBS AG started using network automation to speed up the data center deployment process. The project was a huge success and resulted in UBS embracing automation in campus, WAN and remote office network deployments.

In this section Thomas Wacker described the UBS automation journey and how far they got in 2017.

Joe Hlasnik described how his company uses network automation to provision and decomission network services, the benefits of Ansible Tower, and the user interface they developed for their operators.