No matter how an admin twists and turns, there is no avoiding the fact that automation at the network level makes as much sense as at the server level. Unfortunately, implementing this kind of automation is far more difficult. Juniper, Cisco, and Huawei, for example, have their own ideas and strategies relating to how their devices can best be given a valid configuration automatically. On the other hand, approaches such as Open Networking rely on standard tools because standard interfaces are available on the device side. Another powerful competitor in the network infrastructure automation game is Ansible, which impresses with its diversity when it comes to communicating with devices from any vendor.

Not so long ago, many system administrators viewed the topic of automation with a mixture of indifference and suspicion. The arguments of people who did not want to deal with Ansible, Puppet, and others varied between "automation destroys jobs" and "it is not worth automating that task because it only has to be done once." Fortunately, those days are over, and most admins now view automation in their environments as a basic necessity.

After all, it makes no sense to have expensive IT personnel with amazing skill levels do the same tasks over and over again when they could just as easily be developing useful new products for the enterprise. Claiming that individual jobs only need to be done once proves to be misguided in the vast majority of cases, and you can assume that the job will need to be done at the most inopportune moment – in the context of an outage, when the administrator then has to reconstruct manually something they dreamed up in the dim and distant past under time constraints.

It is quite remarkable, though, that the automation stories of many companies still have some ugly gaps, fundamentally establishing a kind of two-tier society within the confines of a single enterprise. For example, the vast majority of admins today understand why it makes sense to feed servers automatically with an operating system by the Dynamic Host Configuration Protocol (DHCP), a Preboot Execution Environment (PXE), and trivial File Transfer Protocol (TFTP). Anyone who often has to scale their setup will be all too familiar with the problem: It is simply impossible to get a bunch of racks with hundreds of new systems up and productive manually in an acceptable amount of time.

Advocates of automation face more opposition when they look into the hardware required to operate the infrastructure, which does not just mean the ubiquitous server. At a modern data center, it includes switchable sockets and network infrastructure devices such as switches and routers, although the distinction is often blurred in modern environments.

Network Automation Pays Off

More often than not, opposition to automation arises because the admins of an environment do not even realize how much configuration network devices need. For a long time, simple switches were commonplace. Each port was logically assigned to a customer with a virtual local area network (VLAN) tag and isolated from all the others by doing so. Add the necessary settings for Spanning Tree and the configuration was done and dusted. However, if you have ever had to configure a legacy HP ProCurve, you will be aware that this is a tedious task. HP is not a particularly negative example here, it's simply annoying to have to enter dozens, if not hundreds, of commands over a command-line interface (CLI).

On top of that, a simple switch configuration is usually no longer good enough. If you run a scalable setup, you will tend to use the Border Gateway Protocol (BGP) internally. In this case, however, the switches also need to be routers (i.e., they must have the appropriate BGP configuration), which adds another layer of complexity. Moreover, if you run, for example, an Ethernet virtual private network (EVPN) you will need BGP on switches and routers, but on top of this, you will need things such as DHCP relays. After all, EVPN thrives on the idea of splitting up a large network into many Layer 2 segments and then using BGP for the routing between them.

Juniper and Its Expensive On-Board Resources

Juniper has been one of the major players in the networking industry for decades with its numerous switches and routers, but the manufacturer's automation history is not as excellent as some system administrators might like. As is almost always the case with large manufacturers, many roads lead to Rome.

Juniper itself offers a proprietary automation engine in its Junos OS switch and router operating system. It is simply known as "Junos automation" and offers several interfaces to the outside world. Basically, this method is event-based automation; that is, you define "triggers" to match specific events. When the event occurs, the switch performs the action you mapped to the event.

Two different types of scripts, called operational and commit scripts, are called automatically by Junos Automation if you perform certain other configuration steps manually. In common, all script types in Junos Automation are installed by the system administrator in the form of XML, XSLT, or SLAX statements or Python scripts.

I can hear some you groaning here: None of the formats I mentioned are generally regarded in IT circles as being particularly readable or writable – especially because Juno's automation has a loophole. Once a switch is basically up and running, the engine can be quite easily used to automate various things (e.g., debugging). However, if you want to automate the process of deploying a switch or router, you either have to put a huge amount of manual work into the automation engine or – if your coffers are suitably well filled – turn to another product by the vendor: Apstra.

Apstra enables an initial configuration of Juniper devices just out of the box. It comes with a pretty management GUI (Figure 1) and a multitude of practical functions. Under the hood, it admittedly does use the automation features of Junos OS, in part, but you will not notice this. What you do notice is the hole that Apstra tears in your wallet on top of what are typically not exactly low-budget network devices themselves. As usual, there is no hard and fast pricing information on the web, but Apstra is not cheap. The question also arises as to whether it really makes sense to spend a lot of money on complex software, especially for smaller setups, because Ansible is a good alternative.

Figure 1: Apstra is Juniper's acquired approach for completing data center automation.

Ansible Automates Juniper

Most system administrators often don't even associate Ansible with hardware; it tends to be assigned to the "infrastructure" category instead. However, Ansible can now handle devices from many manufacturers more or less perfectly. More or less because not all functions of all devices can be used, although there is a solid foundation of basic functions for the devices from any manufacturer. The example of Juniper makes this clear.

If you take a detailed look at the Ansible modules for Junos devices [1], you will quickly notice many ways to transmit commands directly to the devices. All that you need is a connection between the Ansible host and the switch, along with the login credentials to match.

The Ansible modules also offer several ways to store the configuration on the switches. What they all have in common is that the executing admin needs to be familiar with the CLI syntax of the Junos shell. The developers therefore deliberately decided not to implement any abstractions but to pass the original CLI language through to the system administrator. If you want to automate devices from multiple manufacturers, you might have to build suitable Ansible roles yourself.