How to automate your network using

Ansible and Napalm Part 1

https://www.agileintegratedsolutions.com/how-to-automate-your-network-using-
ansible-and-napalm-part-1/

In the New Era of SDN and NFV and the push towards network programmability and
automation, the usual method of deploying new changes on the network and
validating the network state after this change will not scale. The way we interact with
the network needs to be more dynamic and agile, hence we need to use the same
DevOps tools that the sysadmin have been using to manage the infrastructure and
scale their operation. In this series of articles, we are going to discuss how to use
Ansible and NAPALM to automate network provisioning and validation. we will
outline how Ansible can be used to perform the following main tasks.
Generating router configuration from templates.
Deploying Configuration on different Network OS and platforms.
pre and post validation after a network deployment or change.
Deploying new services (Internet Access or L3VPN) and validating that the
service is deployed correctly.
In the first article, we will outline what is Ansible and the role of NAPALM in network
automation how they can be combined in order to deliver a simple but powerful
network automation for a multi-vendor environment.

What is Ansible?
Ansible in its core is an IT Automation tool which is used mainly to configure IT
infrastructure (Bare Metal servers or virtual machines and even containers), deploy
software on those systems and perform workflow orchestration for the applications
running over the infrastructure. It is part of the Continuous Configuration
Automation tools like Puppet, Chef, and SaltStack which aims to simplify the
management of IT infrastructure and data Centers through an Infrastructure as a
code framework by defining the state of the infrastructure in human readable
definition files.    Ansible is considered a very easy and scalable solution compared
to puppet and Chef since it doesn’t rely on any agent (agentless) that should be
deployed on the remotely managed system. it uses a PUSH model where the Ansible
Server node sends the required changes to the remote system, this is different from
the approach used by other tools like Puppet or Chef which utilize an agent that
must be installed on the remotely managed device that PULL the changes required
from the Master server.   The below diagram outlines a high-level setup that is used
by Ansible to manage a typical IT infrastructure.

Where is the Network!!

As stated earlier Ansible started as an IT automation framework to manage servers
(the operating system and the applications running on these servers), then it started
to support Networking hardware (especially DC switches). At the early stages,
Ansible was just treating the Network nodes like server and managing them via SSH,
so the Ansible server should login into the managed network nodes and run the CLI
commands on them and report the output.   The below diagram outlines the early
stages of Ansible interaction with networking nodes

When you are running Linux as your OS on your DC Switches (Like the case of
Cumulus Linux) you can treat your network nodes similar to your servers and
execute the same playbooks and workflows to maange them. This is one of the main
drivers for adoption of Whitboxes and the use of Linux OS as your Network OS.
This approach has many problems since the output from the devices was
unstructured thus Ansible only provides text output from the managed devices and
we had to use again screen scraping and regular expressions to transform the
output to valid data structures that Ansible can use and work with. Different Ansible
modules like ntc-ansible (that uses TextFSM to parse the output) is used to have a
more programmatic approach to do the screen scraping, however, this was still very
tedious.
As the networking vendors started to support APIs interfaces for their Networking
OS (like NETCONF for JunOS, NXAPI for NX-OS or eAPI for Arista), Ansible started to
support these API interfaces to communicate with the networking devices in order
to return structured data that can be easily parsed into Ansible. So Ansible would
translate XML or JSON data returned as the output from the executed commands
into valid Data structures that can then be used by Ansible as facts or variables to
control the execution of the playbooks. the below diagram outlines the approach
that is used now by Ansible to communicate with networking devices.

Ansible uses a very similar approach to represent a common interface to deal with
different networking hardware so it uses the following most common modules to
manage networking nodes.
XXX_facts (ios_facts, junos_facts, iosxr_facts) to gather system level
information like serial number, device models from the nodes.
XXX_command (ios_command, junos_command) to run commands on the
managed node and report the output.
 XXX_config (iosxr_config, junos_config) to load configuration files or
commands to the managed nodes.
With this still, every network node returns different output (even if structured in XML
or JSON) and we have to deal with this differences especially in the returned output
from the nodes. The below output illustrates the difference in the output returned
from JunOS and IOS-XR when requesting the same data (show bgp summary).

Finally, for some networking equipment (like NX-OS or Junos) further modules are
available that are more abstracted in terms of configuring the network devices. So
instead of using the default XXX_config module and type the exact configuration
commands to describe the required configuration that need to be implemented,
new declarative modules are present that just take the variables that you want (like
enable interface, configure VLAN) and they transform these high-level commands
into device-specific commands that can is sent to the device.

So, Why use Ansible and not python?

Many might argue that whatever Ansible can do, a python script can do and this is
true. however, Ansible has many advantages over python for managing networking
nodes
 Ansible abstracts many of the difficult python operations in very simple
modules (like creating files, directories, starting NETCONF or SSH sessions).
Ansible handles error conditions and provides very simple knobs to control
playbook execution when you encounter errors.
Ansible seamlessly transforms XML or JSON data into python native data
structures (lists and dicts) without dealing with python libraries like lxml or
JSON to decode these data.
When you start running on a large scale, your python scripts need to be multi-
threaded in order to execute multiple tasks concurrently on multiple devices,
however, Ansible is multi-threaded by nature.
As a conclusion, Ansible is a complete framework that uses python in its core,
however it abstracts all the complexity of python to the user and provides easy to
use modules to get the job done in the easiest way, thus it lets you concentrate on
the important tasks (like configuring nodes or getting output from managed nodes)
rather than figuring out how to perform a complex operation in python.  However,
in order to extend Ansible and implement complex data transformation and
manipulation you will need to know python and write python code, nevertheless,
70%-80% of the common tasks in networking can be executed with no python code
at all.

What is NAPALM?
As we discussed above, the default Ansible modules to interact with different
vendors hardware require different format (junos_command, ios_command) and
provide a varying output with a different data structure. So even though that Ansible
utilizes the Vendor API to communicate with the target device, in a multivendor
environment we need to interact with each API separately in order to manage and
get output from these devices, this is the area which NAPALM solves.   NAPALM
(which stands for Network Automation and Programmability Abstraction Layer with
Multivendor support) tries to deliver a common API to manage different vendor OS,
it is a python library that utilizes existing python libraries for each vendor (like
Juniper Pyez) to communicate with each vendor however, it abstracts these different
libraries into a command API libraries which based on the device OS being managed
triggers the correct API call to the target node.
NAPALM is integrated with Ansible and it provides different NAPALM modules to
interact with different vendor equipment, below is the most common NAPALM
Ansible modules.
napalm_get_facts, this is used to get different output from the devices and
return a common data structure.
 napalm_install_config, this load the configuration into the managed nodes.
The below diagram outlines the interactions between Ansible and NAPALM in a
Multi-Vendor Setup.

Further NAPALM emulates operation like compare Config and commit Config which
is not available natively by some Networking OS like Cisco-IOS. Thus, it delivers a
common API to interact with different vendors Network OS.   The below diagram
outlines the output of the same operation (get_bgp_neigbors) on both a JunOS and
IOS-XR device and returned output, which clearly outlines the benefit of having a
command API for interacting with the different Vendor equipment.
In the next article, we will build a sample topology and illustrate how we can
generate the configuration using Ansible and JINJA2 templates, and how to push the
configuration to the managed nodes using NAPALM.
 

References
Ansible Networking Modules
http://docs.ansible.com/ansible/latest/list_of_network_modules.html
NAPALM Documentation
https://napalm.readthedocs.io/en/latest/index.html
NAPALM Ansible
https://napalm.readthedocs.io/en/latest/integrations/ansible/modules/index.html
NAPALM Supported Devices
https://napalm.readthedocs.io/en/latest/support/index.html