Kicking the tires on the new Ansible Network Modules, Part 2

In the previous blog, I kicked the tires on the ios_command and ios_config Ansible modules. I still had my development environment set up from then, so I decided that I wanted to kick the tires on the ios_template module.

The online documentation currently has several errors, with the module documentation in the same state, which is undesirable. However, after some experimentation, I feel that I can adequately describe what the module does.

You feed the module a candidate configuration for a device, the module will then reach out to the device, pull its current running configuration, compare the running configuration to the candidate configuration, determine what configuration needs to be added to the device based upon the comparison, then add the configuration to the device.

I’ve noted two caveats with this module. First, it will not negate any commands, so if you update your configuration template to remove a swath of configuration, the module will not make those changes. Second, the module isn’t intelligent enough to determine the risk associated with a command, thus it’s unable to take preemptive actions, such as bleeding traffic from a link or device.

With that in mind, let’s get to the playbook.

Here is what my playbook looks like:

In this playbook, the src file – “{{ inventory_hostname }}.candidate_config.txt“, which are referenced, contain the running configuration of each of my devices in inventory, with the exception that I’ve added an access-list called TEST. Given what we know of the module, it will compare the running config to the candidate config, determine that the access-list called TEST is missing from the running config, and attempt to add the access-list to the device.

You can see below that there is an access-list at the tail end of both of the configurations.

Now, if we run the playbook, you can see the results.

That is definitely cool! Though, it’s also definitely lacking from a configuration intent perspective. I’m sure that it will improve with time.

Some colleagues and I have been attempting to solve this configuration intent problem. It’s a difficult problem to solve for, but we have a working code base. Soon, I’ll try to write about configuration intent and how we are approaching the problem.

March 2, 2016

Posted In: Ansible, DevOps, Network DevOps, Network Programmability, Python Tips

Kicking the tires with the new Ansible Network Modules

Ansible recently announced support for multi-vendor network modules, natively within Ansible. There are many examples on the Internet where individuals have taken the initiative to create their own modules to work with their favorite vendor. Some of these examples are Arista supplied modules, NX-OS modules – created by Jason Edelman, NTC, and NAPALM. While these are all good, it’s nice to see that Ansible is taking some initiative to create some native functionality.

These modules aren’t yet in the stable release of Ansible, but they do make an appearance in the development version, so I decided to kick the tires a bit.

First thing I did was set up an development environment using python’s virtualenv.

Next, I verified the version of Ansible that I’m running in my development environment, as well as verifying that I have the new modules available to me.

At the time of this writing. It looks like the online documentation has been updated, which would infer that the new modules may soon be in the stable release.

So, let’s create a sample playbook!

The first thing I did was create an inventory file. I kept it simple and created a file called ‘hosts’

Then I created a secrets.yaml file to store my credentials without having to put them in a playbook. While I won’t share my credentials here, I will share the format that I used. :)

Lastly, I created a sample playbook. I wanted a task that  utilized each module type – (ios|eos|junos|nxos)_(command|template|config). Currently, I have easy access to a couple of IOS devices, so I stuck with using those modules, but I played with each ios_(command|config) module. I plan on spending time and playing with the ios_template module more at a later time.

Here is my sample playbook:

In this playbook, I first import my secrets.yaml variables, which includes my credentials to log into the devices. I then define the ‘provider’ variable. The provider variable allows you to create a host, username, password, and auth_pass key value in a single place and call it as a single variable, rather than defining each individually for each task. It’s a nice little time saver! Finally, I started doing work on the devices themselves.

Here is my playbook run:

As you can see, I was able to successfully execute a ‘show version’, verify that I had no access-list called TEST, create it, then verify that it was indeed created.

I’m thrilled that Ansible is finally getting around to recognizing the benefit of supporting the networking community. It’s a basic start and it will only get better from here! Soon, I’ll post a blog walking through the ios_template module. The documentation on that one looks interesting!

February 29, 2016

Posted In: Ansible, DevOps, Network DevOps, Network Programmability, Python Tips