Easy Maintenance

The way in which admins manage the infrastructure at the data center has changed significantly in recent years: Whereas most setups not so long ago were home brewed, automation has asserted itself across the board. That said, some blind spots remain; for example, hardware is not maintained automatically, although it is possible in principle. The network infrastructure is an extensive example; after all, network admins often still painstakingly maintain by hand the hardware of Juniper, Cisco, and other established vendors.

As the setup grows in size, it is increasingly difficult to maintain with manual techniques. Clouds – and in fact all installations intended to scale well horizontally – have specific requirements; one of these is the ability to roll out huge amounts of hardware in a short time. If you then start with manual deployment, you can either look forward to all-nighters or give up straight away.

The good news is that you no longer need to maintain the network infrastructure by hand, because tools for automating data centers are common, affording you plenty of opportunities.

Here, I describe the options you can turn to without worry. The main focus is on Puppet and NetBox. Although NetBox, only recently released, might not focus primarily on automation, it does make an important contribution in terms of efficient data center organization.

The Industry Leader: Puppet

Puppet is by far the most widely used tool on Linux for automation. At least one Puppet module exists for almost every popular application, although many modules vie for the favor of the user in case of major league applications. Classic Puppet modules are divided into two categories: those that come from the community, and those that are officially sanctioned by the vendor, Puppetlabs.

Puppetlabs noted years ago that automating the hardware for network tasks is an issue in genuine DevOps environments. In 2014, the vendor announced a cooperative agreement with several major network companies, including Cisco, Arista, Brocade, and Huawei. Since then, prebuilt Puppet modules have been available for devices by these vendors. Cisco itself offers the Cisco module in its GitHub directory [1]. The other vendors followed suit.

Unconventional Implementation

Because classical network devices are not open platforms, the way Puppet integration is implemented can seem strange at times. In Cisco's case, for example, Puppet integration is available for several of its Nexus series models. The Puppet NX-OS environment, which primarily consists of the Puppet agent, must be installed on the device. Admins of Linux environments can source packages for the Cisco devices directly from Puppet [2].

The setup must include a Puppet master server – serverless mode, which many choose for performance reasons, does not work. The Puppet module by Cisco is mandatory on each master, because it's the only way to set up meaningful configurations. The routine that follows is familiar to experienced Puppet users: The agent running on the device first needs to register with the master, before picking up the configuration stored there and setting up the device accordingly (Figure 1).

Figure 1: Cisco offers comprehensive Puppet support for its NX-OS and IOS devices with specially provided puppet devices.

The feature scope of the Cisco module for Puppet is pretty impressive: It can adapt practically any important configuration option to suit your needs, including classic network parameters such as Border Gateway Protocol (BGP) configurations on routers (e.g., the SNMP configuration) so that the switch can be queried automatically via SNMP in the next step. Of course, basic operations such as assigning individual ports to VLANs or configuring network trunks also work. All in all, Cisco integration for Puppet looks good.

Other Manufacturers on Par

The fact that Puppetlabs cooperates with vendors means that functioning Puppet integration is also available for devices by Huawei, Arista, and Brocade and differs only in details like the setup, which you still need to handle. For example, Network OS by Brocade needs a proprietary Brocade provider on the Puppet master, but no Puppet agent runs on the Brocade switch itself. The agent has to run on a separate host and then connects to the switches remotely to transfer a configuration. This is certainly not elegant, but it serves its purpose.

Puppetlabs and Juniper, at least so far, have not announced any kind of partnership publicly, but this does not detract from the Juniper-provided Puppet for Junos OS. The module for the Puppet master comes with a puppet agent, jpuppet (Figure 2), which can be installed on current Junos OS releases. The rest is known: A corresponding configuration on the puppet master ensures that the agent on the Junos OS device configures the device according to your specifications. More detailed information is available online [3].

Figure 2: A puppet agent for Juniper Junos OS devices.