Useful tools for automating network devices

Easy Maintenance

Cisco with Chef and Ansible

The neatest Puppet integration is of little help to those who are already using some other kind of automation. Although it is theoretically conceivable to amend the existing Puppet solution, it would require several employees with expertise in both approaches. Fortunately, Puppet is not the only solution that has attracted commercial interest in network component deployment. Chef is also supported by several vendors.

More or less in parallel with the Puppet implementation for Nexus switches, Cisco also offers a Chef Cookbook. For this to work, the NX-OS Chef implementation containing the necessary components [4] needs to be installed on the Linux instances of the target devices. Cisco also provides a matching Chef Cookbook.

Cisco has obviously not invested as much time in the work on the Chef Cookbook as it did on the Puppet module. In terms of functionality, the Chef tool is clearly inferior to its Puppet counterpart. However, the most important parameters on Nexus devices can be controlled without Chef, using the module offered by Cisco.

Cisco even has something to offer for Ansible: Current versions of NX-OS with the NX-API can be controlled via the nxos-ansible module, which is available on GitHub [5]. All Nexus 9000 series devices, as well as selected 3000 series devices, come with the NX-API.

Juniper Keeping Pace

Because the big two of the network scene, Cisco and Juniper, have been in a head-to-head battle for years, it comes as no surprise that Juniper is no slouch when it comes to Chef and Ansible. A separate Junos OS module for Ansible, available in the Ansible Galaxy [6], can be used to modify various configuration parameters. If you opt for Chef instead, you can install the components needed for Chef on your Junos using a matching Cookbook provided by Juniper. The manufacturer provides all of the Chef components online [7].

Cisco and Juniper have taken care to ensure integration with the popular automation frameworks by virtue of their widespread distribution of devices. When it comes to support for Chef and Ansible, no such statement can be made by minor manufacturers of devices, for which you must turn to the vendor and the community for prebuilt solutions.

Devices by the various manufacturers are identical in one respect: The architecture is closed; that is, you face proprietary firmware provided by the device vendor in binary form only and are only allowed to enhance the firmware to the extent permitted by the vendor. For both Cisco and Juniper, you would make no progress with Puppet if the manufacturers did not offer Puppet agents for their environments. Many network architectures follow this classical approach, consequently leading to vendor lock-in.

If you are planning a new scalable setup on a greenfield, you have one distinct advantage in this regard: You can decide against the conventional approach from the outset and in favor of hardware that comes equipped by the manufacturer with software for DevOps environments.

Open Firmware Follows DevOps Principles

Earlier this year, Dell unveiled a networking operating system (OS10) with a Debian-based kernel that can be managed like any normal Linux server (see also the article on OS10 in this issue). Cumulus Linux [8] remains the unchallenged king of the hill for Linux switches: For years, the enterprise has propagated a network infrastructure that can be managed automatically along with other hosts.

Cumulus is also based on Linux at heart and offers the usual configuration interfaces – primarily shell access via SSH. An abstraction layer in the device firmware, dubbed the switch abstraction layer, exposes a normal Netlink interface on the Linux side, and talks with the chipset installed on the switch on the other side.

Typing ip a on the switch shows at least the same number of interfaces as the switch has physical ports (Figure 3). Because Cumulus is Debian-based, virtually any Debian package can be installed on the Cumulus devices.