Vendor Lock-In at Cisco

When looking around for signs of how Cisco approaches the topic of automation for its own devices, IT managers may feel excited at first. Cisco's own documentation on automation contains a reference to a day-zero deployment tool. Today, admins usually refer to day-zero deployment as scenarios in which devices are unboxed, bolted into the rack, and automatically given a configuration. "Ignite" was the name of this tool at Cisco. If you look in the manufacturer's documentation, you will find a link to GitHub, but the Ignite repository is marked as "deprecated."

At this point, at the latest, the experienced system administrator may have a sense of foreboding, and rightly so in the case of Cisco. Because today, complete automation at Cisco is based on Cisco Application Centric Infrastructure (ACI), which is actually a software-defined network solution; however, it is also capable of configuring Cisco hardware (Figure 2). For this to work, however, you are looking at some serious capital outlay because Cisco ACI requires controllers in the form of special software, licenses for each connected device, separate licenses if the connection is to span multiple locations, and so on.

Figure 2: Cisco ACI is a comprehensive tool for the data center that also includes network hardware automation.

On top of that, ACI can be dovetailed very closely with software, if desired (e.g., with a cloud tool such as OpenStack). However, a setup built in this way no longer offers the option of switching to a different provider. In a nutshell, Cisco ACI is a dream from the vendor's point of view, for one reason, because it extends vendor lock-in right down to the software level and, for another, because it opens the commercial scope for business with additional licenses that would be inconceivable without a complex and diverse environment like ACI.

If you only want to configure a few switches automatically, you will never need most of ACI's features. However, you will still have to deal with the inherent complexity of ACI and, of course, with the licensing costs for the product.

If you don't want to put yourself through this, you can once again turn to Ansible for help. Various Ansible extensions for Cisco devices with the Internetwork Operating System (IOS) [2] or Nexus operating system (NXOS) [3] are available online, some of which have been integrated into Ansible. Cisco itself even addresses in its own documentation the possibility of automatically configuring its own devices with Ansible. The practical thing is that the modules for both NXOS and IOS devices implement their own functions for certain tasks, unlike those for Juniper devices. In other words, they do not simply pass on Cisco CLI-compatible commands to the devices.

If you want to configure a VLAN, for example, you would use the cisco.nxos.nxos_vlans function. On the one hand, this approach is helpful because most admins will not be as familiar with the CLI syntax of NXOS or IOS as with Ansible parameters. On the other hand, this approach can lead to many admins starting to believe mistakenly that they can handle Cisco devices. A little honesty is therefore advisable when assessing your own capabilities.

Huawei Still Lagging Behind

Huawei's network hardware has not yet reached anywhere near the penetration of Juniper or Cisco, but it is continuously nibbling away at the big players' cake. Unsurprisingly, then, Huawei's automation approach is not so different from that of the big providers. If it were up to the provider, customers would use Agile Controller to control their Huawei-based networks.

At its core, Agile Controller works much like Cisco's ACI controller and can give any machine on the network a meaningful configuration à la day-zero deployment. Once again, however, the software is complex and probably far too extensive for most setups. If you only want to configure a few Huawei switches or routers, Agile Controller is definitely overkill.

The solution, as you may already have guessed, is Ansible yet again. Not only has Huawei explicitly promoted the integration of its own hardware with Ansible in the recent past, but this integration is available today in the form of additional modules for Ansible [4]. In concrete terms, this means you can use Ansible to send commands to a switch, just as you would when using the switch's CLI. Like Juniper, Huawei lags behind in Ansible integration in this respect. You need to learn the Huawei CLI idiom to make any headway with Ansible modules. All told, however, even this overhead for Huawei devices is still less of a task than mastering Agile Controller.

Homegrown: Cumulus Linux

Finally, you can't forget NVIDIA in this comparison. After all, NVIDIA is now also an active provider of network hardware at the data center. The company did not establish this division organically but acquired it externally. If you buy network hardware from NVIDIA, what you get is Mellanox on the hardware side and Cumulus Linux on the software side.

Mellanox has made a name for itself in the community for years as a proponent of "open networking" ideas, and Cumulus, which is basically just Debian GNU/Linux running on Mellanox network devices, follows suit.

Because you are dealing with a normal Linux system on Mellanox hardware, which uses special kernel drivers to control the switch's Application Specific Integrated Circuit (ASIC), all of the familiar tools from other Linux systems are there for you to use. After logging in, you are taken to a Bash shell and can easily check the configurations of the individual ports with tools such as ip. A switch with 48 ports basically looks like a Linux system with a large number of network cards, and because Debian relies on a tried-and-trusted approach to configuring them, /etc/network/interfaces can still be used on a Cumulus system by Mellanox (Figure 3).

Figure 3: Cumulus Linux is based on Debian GNU/Linux and can be managed like any other variety of Linux. Ports are easily configured with /etc/network/interfaces.

You can add /etc/frr/frr.conf if protocols like BGP or Open Shortest Path First (OSPF) are needed. However, a Cumulus-specific CLI tool named net, although well documented, only plays a minor role in automation.