Languages Supported by the Junos XML API

In this lesson we’re going to be talking about the supported XML API languages.

XSLT

First up, XSLT.

XSLT stands for eXtensible Stylesheet Language Transformations. This language is used exclusively for XML to XML transformations. It is a standards-based language, designed by the World Wide Web Consortium. It is used for on-box scripting, so scripts that you write which are stored physically on your device and then executed against your configuration.

XSLT is used for converting one XML document to another. Think of it this way, your device uses XML in the back end, so you’re using XSLT to take that XML and do some transformations to it. Either change it, add to it, check for the existence of something, remove elements from it.

XSLT has many of the functions of a standard programming language. It gives us if-then type functions, we have the ability to run loops so we can iterate through something. We can find specific nodes in our XML hierarchy.

At a high level, the way XSLT works is that we have some XML input document. Usually this will be your configuration file. Mostly XSLT scripts are used for commit scripts, which are executed on the configuration file at time of commit. Your candidate configuration will be the input document and the XSLT script that you have is run by the XSLT engine. That engine processes the input document and spits out some alternative output document. We see in the above diagram that the output tree is a little different than the input tree. We ran some stylesheet transformations against that input tree.

Let’s take a little look at an example of an XSLT script. In this script, this changes the host name to R1 if the hostname element is found in the system hierarchy, and if no host name is found then the error Missing [edit system hostname] is displayed. Let’s see how this works. First, we have up top a <xsl:choose> statement, with our XSLT this is used in conjunction with a <xsl:when> and <xsl:otherwise> statement.

This is done for multiple conditional tests. When a <xsl:when> test must evaluate to a boolean, which is a true / false, value it can only be two values a one or a zero and it’s true or false. A node set is true only if it is not empty. If we have the hostname section of our hierarchy, but nothing in here, then this would evaluate to false. The <xsl:otherwise> here acts as an else statement, which executes if the above <xsl:choose> evaluates to false. If the hostname exists in our configuration hierarchy then we will change it to R1. If it does not exist then we will display an error. The xnm here in <xnm:error> is an error message that is in the xnm namespace and we have the message node in this error element.

SLAX

SLAX is the same thing as XSLT, just an alternative syntax. It defines exactly the same information, just writing it in a different manner. It too is only used for on-box scripting and was created by Juniper. I would make sure that you are aware of that for your JNCIA-DevOps exam.

It is a pre-processor to XSLT. The way this works is our SLAX script is processed and converted into an XSLT script before being executed. So SLAX and XSLT are essentially the same thing, it’s just a different way of writing XSLT. It can be much easier to read and to write SLAX, it’s really similar syntax and feel to C or C-like languages if you are used to that. Let’s take a look at an example of SLAX.

This script does exactly the same thing as the XSLT example above, just with a whole lot less of writing. Rather than having to open and close every tag as in XSLT, in our SLAX example we see that our tags are opened and closed with braces. We just specify the tag and open it with an open brace and close it with a close brace. That alone makes things a lot easier! Even beyond that, our choose and when statements are changed, we now use an if statement, a conditional that is a little more natural to those who are familiar with other programming languages.

Python

Python is used for both on-box and off-box scripting. That’s something important to know, is that we do have the ability to write python scripts and run them on-box. The PyEZ library is pre-installed in Junos on supported software, so python 2.7 was included for some platforms starting at 18.1 R1.

You don’t really need to remember the software version for the JNCIA-DevOps exam, but this might be important if you’re trying to test this out on your own devices. You will need to be at 18.1 R1 minimum for some devices. For most of the devices, Python 3 was introduced at 19.4 R1, so i’d really recommend getting up to 19.4 r1 so that will include python 3 on-box. This is included for your SRX, EX, QFX, MX, ACX and PTX platforms. Most of the platforms out there!

A quick example of what a python script looks like. Here I’m just going to describe what this is doing briefly, we’re going to take a much deeper dive into python and PyEZ later in the course and go through some examples.

First, at the top of the Pythoin script, after the first 2 lines, we’re importing the Device class from the jnpr.junos library. So, jnpr.junos is the PyEZ library. After we import that Device class, first we have some error handling with our try and except statements.

Next we have some contextual assistance here with the with statement, but really what we’re doing is we’re instantiating the Device class. We are specifying that it is to communicate over serial over the port com4. We are specifying our username and password as well. You would not typically want to specify your password or username in plain text in your scripts, but for this example it gets the point across.

So we are saying this class with these arguments specified will now be referred to as dev, that we will use the dev variable name to refer to that. Finally we are printing dev.facts. The facts is an attribute of this Device class and when we print dev.facts this is the information that we get below.

The facts attribute gives us a lot of information here, and spits it out as a python dictionary. We see here some information whether it has two routing engines, what the home directory is, some information about the status what the model this is. This script was run against an SRX210 device.

Now you might be very eagle-eyed and realize that “wait a minute, 19.4 doesn’t run on an SRX210” and that is absolutely right! This was run as an off-box script, where we connected via serial over com4. If you’re running this as an on-box script, the ‘serial’, ‘port’, ‘username’ and ‘password’ information doesn’t need to be present, you just import the device class and use it with no arguments and it will run on-box. That is because it will execute with the permissions of the user account that has executed the script.

Other languages

The following programming languages we’re going to take a very very brief look at. For the exam, I would recommend being aware that they are available for on-box scripting but you just don’t really need to know any details about them, what they look like or how to actually use them, they’re just not covered in the exam.

First up, Pearl. Pearl is used only for off-box scripting. It executes operational mode commands via the XML API. The module that is available is the Junos device module this is officially supported by Juniper and is downloaded from this link , which also includes some sample scripts.

Next up, Java.

As well Java won’t be covered in this course, but it’s used for off-box scripting. The Juniper library for Java makes working with NETCONF in Java a lot easier. We have our Java class and modules available here. There are four main classes included in the Juniper Java library and that is downloaded from github from the official Juniper repository, and it is the netconf-java repository.

Finally, Ruby.

Ruby is also used for off-box scripting. This might be a little more helpful for you to be aware of since some automation solutions, like Puppet and Chef use ruby on the back-end to be able to script. Ruby might be very helpful if you’re using these configuration automation engines. It also executes operational mode commands via the XML API and you can retrieve, modify and commit configuration changes. The Ruby Gem for Juniper is also found on the juniper github repository.

Finally, to take this theory and watch how it applies to a real device, check out the full lesson video below!