Ansible for Networking Engineers

When facing a long study process, it makes sense to start with “what are we doing”, “why are we doing it” and “how is the material structured”. This section will give you these answers, and a procedure you can use to set up a simple Ansible test environment.

One of the simplest network automation use cases is the automated network generation using unified device templates. We’ll illustrate this concept with a DMVPN deployment case study that runs throughout this webinar and includes data model generation, sample device templates, and configuration deployment with Ansible.

YAML is the data presentation language used extensively by Ansible playbooks and variable files. JSON is the presentation language used between Ansible and external components. It obviously makes sense to be familiar with both, and you’ll have to understand the basics of YAML to write your playbooks.

The second step in any automated service (or infrastructure) deployment should be a well thought-out data model (the first one should be a service definition). This section describes how you can generate a typical data model, or extract it from sample router configurations, and write it as a series of YAML files that can be used by Ansible playbooks.

You might think you’d need a templating tool only when generating device (or service or software) configuration from templates. Not true - Ansible uses Jinja2 extensively, from evaluating expressions to specifying conditions, and finally generating text files from templates. Without understanding Jinja2 you’ll have a hard time understanding even moderately complex Ansible playbooks.

Next step in our case study: after building a data model describing our DMVPN deployment, we’ll create Jinja2 templates that will be used to create device configurations.

Finally it’s time to get our hands dirty and do some real automation work. You’ll learn about Ansible inventory, authentication mechanisms, Ansible modules, and the basics of Ansible playbooks - just enough to generate device configurations from templates or execute simple commands on network devices.

Ready for some headier Ansible stuff? Let’s explore the details of Ansible facts and variables, play and task execution (including error handling), implementing loops, working with files, and using exotic Jinja2 filters.

It’s time to work with real network devices. You’ll learn how to log into network devices, execute commands on them, and get device facts and operational data.

Most network automation projects include gathering of operational data from network devices, be it to check device state before deploying new services, validate service deployment, or generate network maps or reports.

Some network devices can return data in machine-readable formats like XML or JSON, in many cases we still have to dismantle printouts returned by various show commands into data structures. This section describes Ansible fact gathering, working with devices that return data in JSON or XML, and parsing text printouts with TextFSM, Cisco's Genie, and TTP.

After managing read-only access to network devices, let’s change device configurations. We’ll cover simple configuration changes, declarative intent modules, and deploying full-blown configuration files.

You want to reuse excellent bits of your code in multiple projects and package them as ready-to-use libraries, right? Let’s dig deeper into:

• Playbook- and play-level imports (static) and includes (dynamic)
• Building multi-platform playbook
• Looping over included modules (the closest you can get to true loops in Ansible)
• Roles and Collections

Ansible is a powerful tool, but it shouldn’t be used as a generic-purpose programming language, so don’t try to use it as a Swiss Army Chainsaw - complex tasks should be implemented with a real programming language using Ansible callbacks, modules, external components, or (simplest possible option) Jinja2 filters and tests.

Debugging Ansible playbooks and Jinja2 templates and expressions could turn into an excruciating experience. The guidelines and hints you'll get in this section will make your debugging process easier and faster.

Ansible includes low-level network device modules - you have to use a different module for every vendor or operating system. NAPALM provides an abstraction library that gives you a uniform interface to device configurations, operational data, and even fully-automated device state validation… with an easy-to-use set of Ansible modules.

NAPALM includes state validation functionality that compares the actual state of a network device (as retrieved with NAPALM getters) with the desired state defined in a YAML file and reports the discrepancies. The same functionaliy can be used independently or from within an Ansible playbook.

This section contains sample Ansible playbooks. Every subsection has a video explanation, optional writeup in PDF format, and link to the source code.

This case study describes WAN services deployment process including:

• Generating device-focused data model from network-wide infrastructure data model;
• Validating fabric connectivity with LLDP
• Configuring OSPF, BGP and MP-BGP
• Provisioning MPLS/VPN services

This section contains sample Ansible playbooks from ipSpace.net GitHub repositories.

This section contains links to various documents describing how you can build your own network automation lab using either physical or virtual devices.