Back in November, Cumulus Networks unveiled NCLU, an interactive command-line interface for configuring switches running Cumulus Linux. NCLU was made to help networking experts drive Linux without having to learn its intricacies and quirks, and so far, it has been very successful. Network engineers are comfortable configuring devices interactively, so NCLU helps abstract the file-based nature of Linux to smooth out the learning curve.

Since I started working at Cumulus Networks over two years ago, I’ve noticed that most of our customers who are working with us for the first time fall neatly into two categories. The majority of our users are experienced network engineers with very little Linux knowledge, whereas a minority are Linux server power-users who may only know the basics of networking. Most of my colleagues at Cumulus are networking industry veterans who started off in the first category, while I fell into the latter. I’ve always been an automation-first developer who applies web-scale principles to everything I do, meaning that from the first day I started configuring Cumulus Linux, I was doing so with tools like Ansible. With the release of Ansible 2.3, I’m happy to report that Ansible now supports NCLU out of the box.

The old days in Cumulus Linux and Ansible configuration

Since the beginning of Cumulus Linux, the go-to way to use Ansible configuration has been through the use of Jinja templates. Since Cumulus Linux is just Linux, templates worked natively, allowing us to leverage Ansible since day one. Templates allow an operator to write a configuration file with “fill-in-the-blanks” for variables in the automation playbook.

Example of ifupdown2 template
auto eth0
iface eth0 inet dhcp

auto swp1
iface swp1
    address {{devices[ansible.hostname].ip_address}}

When this template is executed, the IP address of swp1 will be automatically pulled from the ansible variables file and then deployed on the device. In most deployments, there are very few differences between configuration files, such as MAC and IP addresses. This means that the same template can be deployed on many devices, leaving the differences up to the variables file.

While templates are very powerful, their greatest limitation is that they can only be specified in a single playbook. Each time a template is applied, it completely overwrites the old one. This means that every possible feature needs to be accounted for in the same template, making them hard to read, write, and maintain.

Nowadays in Cumulus Linux and Ansible configuration

Starting with Ansible 2.3, instead of writing templates for Quagga and ifupdown2, you can now write tasks using the NCLU module.

• name: Configure swp1

 • “add int swp1 address {{devices[ansible.hostname].ip_address}}”

  commit: true
  description: “Ansible - enable swp1”

The advantages of using NCLU instead of templates

First of all, it is possible to put NCLU tasks in multiple playbooks without having them conflict with one another. For example, you can have one playbook for configuring your in-band BGP fabric, and another playbook for deploying the out-of-band bridge, making your playbooks more modular and maintainable.

Secondly, instead of having to learn the underlying Quagga or ifupdown2 syntax, you can use NCLU’s user-friendly syntax, along with all of its error detection and guard rails. If you make a typo in a configuration file, you won’t notice it until you try to reload the file — potentially causing a service interruption. NCLU will catch typos and other dangerous configuration mistakes before they are applied, giving you a chance to fix them before the configuration is committed.

Where to go from here?

If you haven’t tried Cumulus Linux and Ansible yet, or are still using Ansible with templates, we have a demo that shows how to deploy BGP on a virtual environment running Cumulus VX.

If you want to figure out how to translate your playbooks to use the new NCLU syntax, you can reference the official Ansible documentation page for the NCLU module.