Automating Junos Administration

Foreword

As someone reading a book on network automation, you’re clearly aware of the benefits of automation, the cost of human mistakes, and the ability of software to perform routine tasks with accuracy, diligence, caution, and reliability. Automation can add robustness and fluidity to your network, prevent outages, and decrease the impact of networking issues and the mean time to resolution.

In my work as the architect and coder of the JUNOS user interface, I’ve preached automation since the early days. We knew automation would be a key differentiator for our customers and wanted to allow application programmers to escape the world of “screen scraping,” where command-line interface (CLI) output designed for readability and human digestion is filtered using regular expressions to extract useful information, a process that is error prone, fragile, and difficult to maintain. If a change is made to the CLI to add a new data item to the output or the format of the output is changed, a regular expression may fail to match correctly, leading to errors that cannot be easily detected.

We built into JUNOS an XML-based API that would allow immediate access to data items in a robust, simple, and future-proof way. XPath expressions can extract specific data values while ignoring new content or changes in the way values are organized. Complex expressions can find precise values such as the remote address of every point-to-point link that has a large MTU and high error rates.

We also knew that automation depended on complete access to the device’s capabilities. If an API allows you to do 80% of what’s needed, but you have to resort to “screen scraping” for the other 20%, the value of the API is greatly diminished. By layering the CLI directly over the API infrastructure, we fully expose all JUNOS configuration and operational output, guarantee each release of JUNOS ships with feature parity between the API and CLI, and reduce our internal cost in maintaining the API.

As customers have deployed our devices in the real world, we’ve seen a great variety in terms of network automation. Every network operator sits somewhere along an automation spectrum, somewhere between a network of hand-maintained devices and a fully automated network. Some have completely committed to automation, using external databases as the “database of record,” enacting policies stating that changing configuration on network devices is a firing offense. But many networks are still maintained by hand, using expensive human resources to make configuration changes and debug networking problems.

Automation efforts are often focused where the benefits matter, principally in situations where the cost of failure is high, the rate of change is high, the complexity is high, or the number of affected devices is large. Such projects are typically key to demonstrating the value of automation, and lead to further automation projects. The “devops” and “netdevops” movements take this approach, starting with the biggest current problems, solving them, and building an identify-solve-test cycle.

Data centers have done a great deal to push automation, using server deployment tools such as Puppet, Chef, Ansible, and Salt. These tools make cookie-cutter servers deployment trivial while allowing customization in uniform, predictable ways. The days where a missing software patch can lead to unique, obscure failures are gone. When changes to your servers are simple and immediate, while changes to your network infrastructure are done by hand, with the associated higher error rates and delays, the value of automation becomes clear.

More recently, the YANG data modeling language (based heavily on the data modeling language we built for JUNOS) has fostered the creation of data models for networking. The IETF is developing YANG data models for many areas, over 160 at last count. In addition, the OpenConfig group is building models focused on the needs of the service provider community. Support for the OpenConfig models is already shipping on networking devices.

It’s clearly not reasonable to expect every network operator to start programming, but by understanding what can be done using automation, people can start to “think like a programmer,” allowing identification of scenarios where automation can be successfully applied. In particular, programmers have a disdain for doing the same thing over and over. We write code instead, allowing the computer to do the work for us. “Lazy like a fox,” I call it.

In this book, you’ll find the concepts and tools needed to help you advance your skill set in automation. Jonathan and Stacy are automation veterans with deep knowledge of this area, and have done a fantastic job of translating their experience onto these pages, helping you build robust automation into your network.

Phil Shafer

Distinguished Engineer,

Juniper Networks

March 2016