Pull My Strings, I’m Your Puppet: Juniper Bringing DevOps to Networking

The buzzword in the industry of late is DevOps. It is one that I hope isn’t tarnished by the marketing machine where buzzwords go to die. DevOps is the shift in the paradigm of network and infrastructure management. Centralized infrastructure that is transparent to the administrator and end-user, IaaS, cloud – whatever you want to label it – has been the catalyst in DevOps automation. This push has made us step back and look at not what we do per se, but how we do it.

The Venn diagram above shows what DevOps is and can assist with. The framework can ensure quality assurance of code and change. It can improve development of software engineering by opening APIs to be leveraged all while technology operations automates and actually engineers solutions.

Now, I am far from someone who works on a scale that requires DevOps, but this is a framework that can scale. Network engineering no longer should be mundane tasks like conf, set interfaces fe-0/0/0 unit o family inet address How does mindless CLI work translate to efficiently spent time ? What if you need to change 300 devices? What if you are writing it by hand? An error-prone waste of time.

Puppet by PuppetLabs allows system engineers to automate tasks across their environment. By collecting facts, a Puppet server can learn, and automated manifests can be enabled to perform tasks. Deploy a VM there, set interface & port channel settings and descriptions in a workflow. One click accomplishes many tasks, and it’s possible across many platforms or devices. This beats jumping around and spending time in a screen you’ve been in 4,000 times before.

Juniper today announced Puppet support for their 12.2R3,5 JUNOS code. This is compatible with EX4200, EX4550, and QFX3500 switches. These are top end switches, but this start is directly aimed at their DC and enterprise devices. Initially, the manifest interactions offered are interface, layer 2 interface, vlan, port aggregation groups, and device names. This definitely shows the direction of what Derick Winkworth (Cloudtoad) and his team showed at NFD4. More importantly, it shows the ground that has been made.

What follows in an example of an interface manifest that is sent from the Puppet server to the Puppet NetDev module through JUNOS to the netconf. The image below shows the transaction between devices.

node "ex.ciscoinferno.net" {

    netdev_device { $hostname: }

    netdev_interface { "ge-0/0/19":
        description => "connected to old hub",
        speed => 100m,
        duplex => full


The configuration generated from the above example pushed to a device would look like this:

anthony@ex.ciscoinferno.net> show configuration interfaces ge-0/0/19
description "connected to old device";
ether-options {
    link-mode full-duplex;
    speed {

Getting the point? It’s much easier to send a task than sit and type those commands manually. Add this to a workflow – say for a VM deployment or new server rack – and you are no longer a monkey typing commands, but an engineer who is optimizing and scaling.

At this stage, Puppet commands exist for interface, L2 interface,VLAN, LAG groups, and device names. Albeit a small family of devices and limited functionality at this stage, Juniper has taken a great step into a larger world. This is one of the first announcements where I got rather excited. Kurt Bales skyped me the same time I opened the link, and we both agreed “Nerd Boner”. Now I don’t profess to be a DevOps programming god, nor can I lead you out of the broccoli forest of despair, but I do believe that in time, with steps forward such as Juniper’s announcement, together as an industry we can step towards the light. Heck, one day we might get to the top of the hill and see the valley of IT utopia below. Until then, we must fight our way through the broccoli.

Read more 
Automate Network Configuration with Puppet for Junos OS
Puppet for JUNOS Administration Guide


  1. Sean Walberg says

    I’m a network guy turned software developer (for the time being, at least :) ) and we love Puppet and Chef. Network devices and VM provisioning are the natural extensions of the “configuration as code” movement.

    The bigger advantage that this provides is that if someone goes in and makes a manual change, it’s changed back the next time Puppet runs. So no more phantom duplex changes, etc. And since you’re checking the configuration files into source control, you have a searchable changelog of who did what.

    • Glen Turner says

      Actually, that “restore to configured state” feature of Puppet is nothing short of dangerous. Consider a link where you’ve dropped the light on so that it can be repaired in a eye-safe way. Although there are strong parallels between sysadmin and network engineering the two are not exactly identical. One of the differences is that the router is the canonical source for interface state, even if it’s not the canonical source for interface addressing, routing or management configuration.

      If you are altering the duplex of an interface, then you are doing it wrong. That’s an automatically configuring item, if it fails to automatically configure then shutdown the link. These days a failed NWay indicates a cabling fault or a sysadmin who needs to be whacked with the clue-by-four. As far as sysadmins go they are allowed two settings for ethernet interfaces: automatic or 10Base-T. Anything else requires per-item handling by the network engineering staff, which is exactly the sort of unscalable nonsense DevOps avoids.

Leave a Reply

Your email address will not be published. Required fields are marked *