Software Defined Juniper – Scripting Junos with Python

In the future world of the Software Defined Network, what will our jobs look like? Will we network engineers all be programmers (I don’t think so), or out of a job (unlikely)? One thing is clear though, as I mentioned before, our jobs are going to change with time, and the way we configure networks will be transformed from how it is now – at least in those environments fortunate enough to be able to deploy a wide-ranging SDN solution of some kind.

If the programming part is scaring you, Juniper’s Jeremy Schulman (@nwkautomaniac) thinks he has an approach that might bridge the gap between hard core programming geekery and the rest of us.

Python for Non-Programmers

Jeremy has recently started publishing a series of posts entitled Python for Non-Programmers. Jeremy’s thought process – and I hope I’m representing it appropriately here – is that while we aren’t all “real” programmers, most of us can probably knock up a little bit of code (think about shell scripts and similar), so what we need is some way to give the majority of us who have limited programming chops the ability to use code to interact with network devices.

To that end, Jeremy has been noodling around and has created a Python library that will act as a kind of middle man between the idiot at the keyboard and the device itself; something to abstract (Bingo!) the complexities of talking to a network device into something a little simpler for us script kiddies. Jeremy has created a Python library that he’s publishing via Github, and says it’s targeted at two groups of users:

1. Non-Programmers, who can use “Python as a Power Shell”
2. Programmers, who will find the system open and extensible

Laudable aims; I wonder if he can succeed?

Puppet for Junos

I met Jeremy last year when he presented to Networking Field Day 5 about Puppet for Junos. The concept of Puppet initially excited me, because I could see the potential power of automation as part of a larger service chaining process. But my initial reaction was, ok, so this can configure access ports, but what about everything else we want to configure? And sadly it looks like this is the limitation. Puppet (and I guess, Chef also) has the potential to be a great provisioning tool, and it’s one familiar to the existing DevOps teams so will be welcomed with reasonably open arms. However, that’s as far as it goes; Puppet isn’t a monitoring tool, and it doesn’t seem to offer programmability beyond some fairly simple interface parameters right now. Check out the Puppet Netdev library on Github – this is what Jeremy was presenting, albeit somewhat developed since then, but essentially it’s configuring access ports, trunk ports and LAGs.

Junos EZ Library

The EZ Library (I’m not sure if it’s going to keep that name) acts as a layer of middleware between you and the complexity of talking to a Juniper device. The beauty of abstraction of course is that ultimately, the same code could be made to work with any network device, not just Junos. The point is that the libraries make it simple to query a device and extract information or configure the device. Unlike the Puppet-Netdev libraries, this is already a far more broad-reaching library that I believe addresses two main areas:

1. Monitoring
2. Configuration

When I spoke to Jeremy he talked about there being two databases in play in every device:

1. Configuration database
2. Run state (Operational) database

The libraries being discussed here offer access to both databases in a way that seems remarkably simple.

I Am Not a Python Programmer

I am a Perl programmer, not Python. While I have managed to avoid programming Python so far, the basic syntax seems pretty simple. After getting the relevant libraries and supporting elements installed (more on that in a post to come), running a quick test script against my Juniper EX3200 was successful. 20 minutes later I had a basic interface status script running, and 20 minutes after that I had managed to expand the existing code to include more information so that I could product a report I wanted for my home web site. So far I’ve only tapped the run state database side of things, but as Jeremy points out in his second post, the best way to start is with read-only operations, then move to the write operations once you’re more comfortable with how things work!

Coming Soon

I am going to share a few posts on this topic, because it’s one I’m very interested in. So coming soon, at the very least, are posts covering:

• Preparing an Ubuntu server system with the appropriate requirements to run the Junos EZ Python libraries
• Reading interface status, and expanding the view to include more information.

I’m hoping to play with configuration shortly, which I’m sure will end up being another post.

Do I Look Bovvered?

You should. This is some cool stuff and gives one possible insight into how networking could look in the future, as well as how much better we could query our devices without needing to log into the CLI directly. Looking just at the monitoring side of things, I can easily see how a relatively simple web front end to these libraries could quickly allow a user to generate customized reports on device data. This is something in a very early stage of development, but already it’s clear that the level of abstraction coded in these libraries opens up a programmable network even to those of us who see the daylight once in a while. This isn’t real-time flow programming mind you – there are other protocols better at that – but as part of the provisioning service chain and monitoring systems, this might actually be a nice middle ground. Watch this space, and maybe try out the libraries – it’s a giddy kind of fun when it works!