I have had a complicated relationship with Juniper products throughout my career, and quite frankly, that’s at no fault of Juniper’s. It’s really the fault of the networking profession. Think about every network engineer job posting you’ve come across – what are the requirements, specifically regarding certifications? What is listed in the preferred section?

CCNA. CCNP. CCIE.

And to be fair, those are great certifications. So that’s what we all go for, right? That’s what HR is looking for, after all, and we need to get our foot in the door. So that’s what I certainly did. I got my CCNA.

And then I pretty much never saw a Cisco device again. While working for an MSP, I can only recall two clients that had some Cisco equipment. The rest of the clients were using… well, evertything else. But the big ones ran with Juniper, so in order to service our clients, I had to learn Juniper on the fly.

I loved Juniper – I hated the situation. Why did I waste all that time going for my CCNA when I could have just gone with JNCIA? Configurations on Juniper are so radically different from Cisco that I found myself feeling almost depressed like I wasted 6 months and now have to start over.

But then I uncovered the true power of Juniper – the XML API. I didn’t even realize it at the time that this was network automation in action – the birthplace of network automation. It all started with Juniper.

Let’s take the classic “show interfaces terse” command for example. This is equivalent to “show ip int br” on Cisco devices. You type those commands, you get pretty formatted info back. But under the hood, Junos was designed from the beginning with network automation in mind. Every command you type get translated to an XML RPC request (just like Netconf)…

And every response that comes back is an XML payload that by default gets translated into human-readable text.

And this has what has existed in Juniper’s operating system (JUNOS) for about 20 years now. 20. Years. Juniper has been doing structured data responses and RPC requests for 20 years. All Netconf does, really, is just exposes these RPCs. So you can pipe any command to | display xml rpc and there you have it, send that RPC in over Netconf.

It’s also worth pointing out that you can just as easily pipe the results to JSON.

So then Netconf comes along and exposes this API. So if you know the command line, you can pipe the command to | display xml rpc, you can pipe the result to | display xml, and you can pipe the actual running config to | display xml. In other words, your payloads are easy to create because Junos spits out structured data already.

But wait! There’s more! Juniper created an SDK that abstracts all the hard parts of Netconf and Ncclient away. This library is called PyEZ. Honestly, they could have done a better job with that name. I don’t know what the right name would be, but PyEZ tells me it’s python, and it’s easy, but nothing about Juniper or Networking. However, this blog isn’t about what PyEZ should be named.

PyEZ, being that it is Python, makes programmatically configuring Juniper devices even easier. It can accept your CLI commands like “set” or “delete,” it can accept JSON, it can accept XML, or it can accept the Junos text configuration output.

Beyond that, it works great with Jinja2 templating, too. And all of these are reasons why I wanted to get PyEZ working with Nornir. 

And this is why I am falling in love with Juniper all over again. It was just designed from the get-go to be automated. It’s not only easy thanks to PyEZ, it’s just insanely powerful. But now that nornir_pyez is a thing, concurrent automation with jinja templating and fact gathering…. It’s just pure bliss. And now I’m going wild with the power.

So yeah, I was bitter about having to learn Juniper at first, especially since I didn’t know how to code. But now that I know a thing or two about code?  The floodgates are wide open.

Here is some advanced OSPF config using Jinaj2 templating with loops and conditionals.

Here’s where I configured LACP in the Xe interfaces on vQFX appliances.