Backing up configs with the Ansible NCLU module

----
Backing up configs with the Ansible NCLU module
// Cumulus Networks Blog

With the release of Ansible 2.3 the Cumulus Linux NCLU module is now part of Ansible core. This means when you `apt-get install ansible`, you get the NCLU module pre-installed! This blog post will focus on using the NCLU module to backup and restore configs on Cumulus Linux. To read more about the NCLU module from its creator, Barry Peddycord, click here.

The consulting team uses Ansible very frequently when helping customers fully automate their data centers. A lot of our playbooks use the Ansible template module because it is very efficient and idempotent, and Cumulus Linux has been built with very robust reload capabilities for both networking and Quagga/FRR. This reload capability allows the box to perform a diff on either `etc/network/interfaces` or `etc/quagga/Quagga.conf` so when a flat-file is overridden with the template module, only the "diff" (or difference) is applied. This means if swp1-10 were already working and we added configuration for swp11-20, an ifreload will only add the additional config and be non-disruptive for swp1-10. This reload capability is imperative to data centers and our customers couldn't live without it.

However, many customers also want to build configs with NCLU (or the net commands) when they are first introduced to Cumulus Linux. Instead of starting from a flat-file and templating it out, they are going command by command as they learn Cumulus Linux. It is still fairly easy to build a configuration with NCLU, then pull the rendered configuration with the `net show config files` command and build a template out of it.

That being said, I wanted to provide an alternate method of backing up and restoring configs in a very simple playbook that does not require templating or configuration of flat-files. Check out the following Github repo: https://github.com/seanx820/ansible_nclu

There is a README.MD on the Github page but I will explain here in brevity what I am trying to accomplish. The pull_nclu.yml file will grab all the net commands from the Cumulus Linux switch(es) and store it locally on the server that ran the playbook. It literally just connects to the Cumulus Linux switch(es) and grabs a `net show config commands` and stores it locally. The push_nclu.yml playbook will then re-push these net commands to the Cumulus LInux switch(es) line per line, but in a idempotent way. This means if the configuration that is being applied is already configured it will skip it let you know it is already configured.

There are advantages and things to consider vs templating in my opinion and I will quickly go over some:

Advantages of the NCLU module backup method:

• The NCLU module is literally typing what a user would type to configure the box. This means it is very easy for someone to figure out what the playbook is doing, and troubleshoot any issues.
• The playbooks provided are so simple only a rudimentary understanding of how Ansible works is required
• The NCLU module is still idempotent, so we are not just firing commands off, it knows if something is already configured.
• No knowledge of Jinja2 or other templating mechanism needed. These playbooks are simply replaying commands in a smart and logical matter.

Things to consider with the NCLU module backup method:

• Speed! This method literally replays each net command line by line back to the box. This will always be inherently slower than just overwriting a couple flat-files and performing an ifreload and a systemctl reload quagga.service. Configuring Cumulus Linux just with templates can require just four Ansible tasks, vs NCLU which can literally be hundreds of lines of net commands. Does it matter? Maybe? Depends on the situation and how you are using Ansible.
• Config Management: While the NCLU module is idempotent, unless you perform a `net del all` and reset the config, you don't know if another user or program has configured the box in addition to you. Meaning if your config never configured swp10 but someone else did, this method would have no concept of swp10 being configured. All the commands you configured will be restored correctly but their is no concept of an end-state for the box holistically. With templates we know the entire config, not just the part we configured (because we are literally overwriting the entire configuration every time and doing a diff).

There you have it! I always like to think adoption of network automation by network engineers in 3 stages: crawl, walk and run. I see this method somewhere under the crawl and walk stages. I find myself using it during network POCs (proof of concept) labs and teaching Ansible to first-timers. Let me know what you think in the comments below.

The post Backing up configs with the Ansible NCLU module appeared first on Cumulus Networks Blog.

----

Read in my feedly

Sent from my iPhone