Using the official network modules with Ansible 2.0.X

March 13, 2016

About one month ago Ansible released official core modules to work with network equipment. With Ansible 2.1 they will be included in the stable-release. Their functionality is described in the documentation. Different vendors and platforms like Cisco IOS, Cisco NX-OS, Cisco IOS-XR, Juniper JUNOS or Arista EOS are supported.

Typically there are 3 types of modules available per platform. The platform I use in this blog post will be Cisco IOS:

command: Run arbitrary commands on IOS devices.

config: Manage configuration sections.

template: Manage device configurations.

At the moment of writing this post there is a special network branch which includes the new Ansible network modules. The branch is called stable-2.0-network. In this post I want to show how a Cisco-switch can be managed with this new possibilites. My goal is to ensure the basic configuration of the switch (like hostname, logging, ntp, snmp…) with the help of configuration templates. As a templating system jinja2 is used. The ansible playbook ensures that the templates are used for configuring the switch, and writes the config if something changed. As an example I will create a role for common-configurations like the hostname and a role for the logging-configurations.

To get started you have to download and install Ansible with the branch stable-2.0-network:

The common/meta/main.yml of our common-role has the writecfg-role as a dependency. Only if the common-role changes something on the device also the writecfg-role will be called. I use this to ensure that the configuration of the devices only gets written, if there were some changes in the running-configuration.

$ cat roles/common/meta/main.yml---dependencies:-role:writecfg

The common/tasks/main.yml executes a task in which the ios_template module of Ansible is used to ensure that the configuration defined in common.j2 exists on the IOS-device.

Notice that the status of logging is changed and the handler for writing the configuration gets called. Now two logging-servers are configured on your device. If you want to change the logging server you can delete it before adding a new one or execute a cleanup-role at the end of all roles, which deletes all configuration-snippets you dont want to use anymore.
At this point you could also add other roles like ntp, aaa, ssh… be creative. If your templates are cleverly designed it would be enough to change the variables in group-vars/all.yml to the new values. With this method a basic-configuration on all your devices could be ensured very easy.