Plug and Go

Automation Made Easy

Automating switch configuration with Cumulus Linux is easy. Several times already in this article, Ansible has proven to be the tool of choice, and Cumulus Linux is no exception. In most cases, you will want to design your Ansible roles to generate and roll out the two files mentioned above from templates on the switches. Changes to interfaces require an ifreload -a, and changes to frr.conf require a restart of the frr service. Small things like applying the switch license for Cumulus Linux can also be handled very well in Ansible. You can even find prefabricated roles and playbooks online, which you can use as a basis for your own work if in doubt.

Because Cumulus Linux has a real shell and the typical Linux CLI tools, it's the best of all the approaches in this comparison on automation with standard tools. Its practicality extends to being able to define the entire switch configuration in Ansible with host-specific variables – Ansible then takes care of the rest with templates. Unfortunately, you won't find a universally applicable example on the web, partly because Cumulus-based environments vary widely. Attempting to map all eventualities of a free-range routing (FRR) or interface configuration would inevitably lead to the dreaded "YAML shovel," a derogative term referring to the approach of mapping all possible configuration parameters of a file in YAML so that Ansible can subsequently convert it to a configuration file again.

From the admin's point of view, it makes more sense to build local templates – at least for frr.conf and interfaces – that only have the required scope and cover the required functions. In most cases, this process should take no more than a couple of days, if it takes that long at all. The payoff for this overhead is being able to replace broken switches with new switches in next to no time – or, if it's a matter of scaling up, have a fully automated way of rolling out new devices.

Conclusions

All of these providers have ideas for automation in their portfolio – but the ideas could hardly be more different. With Juniper for Junos, Cisco for NXOS devices, and Huawei for its own devices, all of these vendors would love to lock customers into their own product portfolios. Huge suites (e.g., Cisco's ACI) primarily offer software-defined networking and automatically configure the hardware as a side effect, but they are typically oversized, especially for smaller companies. Moreover, they exacerbate vendor lock-in.

In comparison, Ansible is particularly elegant and versatile. Even in infrastructures with hardware from different manufacturers, the tool offers the option of uniform configuration. Once you have defined a format for your settings, you can process it to create playbooks for any vendor.

If you are looking to automate your network hardware, you will want to evaluate Ansible. There is only one problem that Ansible cannot currently solve in a satisfactory manner, at least at the moment: day-zero deployment. Cisco was on the right track with Ignite, and one can only hope that free/libre open source software projects will step up to fill the gap in the future.