Juniper JET and REST APIs

In this lesson we’re going to be covering four different tools. The JET and REST APIs, JSNAPy and ZTP.

These are the Junos Extension Toolkit or JET API, the REpresentational State Transfer API, JSNAPy for taking operational and configuration snapshots, and ZTP or Zero Touch Provisioning.

REST API

Let’s go ahead and jump right on in with REST. What exactly is REST anyway?

I mentioned it is an acronym that stands for Representational State Transfer. It is a very common API architecture out on the internet. Many services out there, many of your favorite websites, use a REST style API in order for you to be able to access resources on those websites. REST APIs typically uses HTTP and HTTPS for transport, and no session state is stored on the server hosting the API. Each query is independent.

To explain more, let’s dive more into the name REST. REpresentational State Transfer. This is saying that all representational state is transferred with each all. State would be recalling or remembering your user session or your credentials, or what you have done so far on that website, of where you currently are in your session, the state of your session. REST architecture is created such that every individual query is independent and that the state does not reside on the server, but rather on the client. All information needed to process an individual query is sent with that query. The server does not need to know that you are sending an additional query in regards to your existing session, it doesn’t need to know that you’ve logged in already, the way it will know this is because you are sending some sort of authentication token and all the other information needed in order for it to process your query included in your REST API call.

REST commonly uses GET and POST HTTP verbs, which we’ll be talking about that more later in the course when we go a little further into the REST API and what these different http operations are.

This is really excellent though, because it allows for quick prototyping using very simple tools like cURL. cURL can be used to initiate a very quick GET or POST query to your REST API to be able to test what sort of responses you’ll get back and see if you’re actually getting the information that you want. For Junos specifically, it has the ability to execute RPCs, or Remote Procedure Calls. Now, it will only execute a single RPC at a time with the GET requests, however with a post query it can execute multiple RPCs.

The REST API is currently supported on the Juniper M, MX, T, PTX, and SRX platforms, I would make sure that you are aware of that for the JNCIA-DevOps exam.

The REST API provides an HTTP or HTTPS based interface, you can enable either. We also have the option to enable a GUI API explorer, that is a Graphical User Interface. When you enable the API explorer on your Junos device, it actually hosts a website that you can go to by navigating to your device’s IP address in a web browser and will give you an interface for exploring the REST API. This allows you to easily execute these calls and see what the output is, so you can save those calls and use them in your applications that you’re scripting, so prototyping is even faster.

The REST API for Junos is explored in much more depth later in the JNCIA-DevOps course, definitely take a look if you’re interested!

Junos Extension Toolkit (JET)

Let’s move on to the Junos Extension Toolkit. First, what is JET?

JET is handled by a totally different process on our device than other APIs. As we saw previously, in our automation stack diagram, most of our automation is hosted by the mgd process and done through the XML API. We also have some automation capability through the SNMPd process and the SNMP polling engine that we have to be able to gather information from our device.

The JET API is handled through the jsd process. The jsd process actually sidesteps mgd entirely. We are no longer using the XML API that is running on top of the mgd process, we are using the JET API. This uses gRPC as our transport protocol to communicate with the jsd, and it uses the MQTT protocol for messages to communicate with our notification broker to get information from our event daemon.

The JET API allows for very quick configuration changes, because it can interface with the ephemeral database we can do upwards of 1000s of changes per second. Now, the JET API exposes internal APIs for automation and gives a consistent look and feel to them. The diagram above is intended to illustrate how our communication methods, the jsd request response and notification broker. The jsd request response and that occurs over gRPC, and it’s the jsd process that’s communicating with our individual daemons, our rpd and our dcd, dfwd, eventd and others. These are the individual processes and daemons running on our device and that the jsd is interfacing with directly, rather than going through the mgd.

Some of the features of JET are that it enables third-party applications to run on-box. Systems like Puppet and Chef agents we had mentioned in a previous lesson wouldn’t exist without the JET API. Puppet and Chef both require having an agent installed on the box in order for them to be able to function, they’re both written in ruby and both interface with our device outside of the mgd.

The jsd supports Python and C or C++ applications on-box natively, whereas Puppet and Chef end up including a ruby interpreter with their agents so they are able to be run. The jsd and MQTT notification broker are separate services, on different TCP ports, so our notification messages or our message queue is going to be occurring over a separate connection, on a separate TCP port, running through a separate service on our box than our jsd.

So that’s really about as far as we’re going to go into JET during this course. You don’t really need to know much about it for the JNCIA-DevOps, really just that allows for fast programmatic changes, it enables third-party applications to run on the box, it has native support for Python and C or C++ and that the jsd and MQTT run in separate services which listen on separate TCP ports. These are the primary items that I want you to remember for the exam about JET.

JSNAPy

JSNAPy is the Python version of JSNAP. JSNAP is a tool that allows us to take snapshots of configuration and operational information on our device and compare them either between a previous snapshot, or to just some set of rules that we define.

For predefined rules, this would be a workflow called snap check, whereas comparing against previous snapshots this would be a workflow called snap snap check. You may see that in your exam at some point, where it’s asking “if you have a workflow of snap check what does that involve?” or “if you’re using predefined rules, which workflow would you be using?” The answer would be snap check, or snap snap check.

As far as what this workflow looks like, take a look at the diagram above. We’re using PyEZ with JSNAPy in order to take a snapshot, in this case BGP, OSPF and interface information. We are doing some change, so we’re in a maintenance window and we are doing some configuration changes to our device, or many devices. We are taking the pre-snap first, doing our maintenance and then taking a post snap, which occurs through PyEZ using JSNAPy, and comparing it against our pre-snap or against a defined set of rules.

If we want to make sure that our new snap actually just follows a set of rules, for example if we want to make sure we now have 5 BGP neighbors instead of 4, or that we have a specific OSPF neighbor or a specific subnet configured on each of our interfaces. All of these test cases are possible with JSNAPy.

JSNAPy can also save results to a database, so that it’s referenceable later and have for a audit of your configuration changes to really show and have documentable proof that your change was indeed successful. How awesome would that be, right? I’m sure you as a network engineer or administrator have encountered where you made some change to the network and couple days later something happens and they say “oh it’s your change, you you guys changed something and caused the problem”. Well, with this you would be able to document and show for sure that your change was successful and it had the effect that you were looking for it to have.

Zero Touch Provisioning

Finally, let’s move on to the last tool here of Zero Touch Provisioning, or ZTP. ZTP allows for the provisioning of Juniper devices with zero configuration touches. Well you actually need to physically touch it at least once, right, to go ahead and plug it in. Though ZTP can fully configure our device without us having to go to the console and input any commands.

ZTP does this through DHCP options. The DHCP offer sent by a DHCP server includes some options which provides information of the location of configuration files and software upgrade files that are available and where to go find them. So we have the workflow up here. First up, unbox and connect the switch and power it on. When the device first powers on, it’s going to have the factory default configuration to go reach out to DHCP and be a DHCP client to obtain IP address information from some DHCP server on the same broadcast domain.

On the DHCP server is where a lot of our ZTP configuration happens. It is where we have the DHCP options set that give us the image name config file name, and the location of these files. Now, there is some logic you can put into ZTP, so that based upon your device’s model or MAC address that you can have it download a specific configuration or image file, though we’re not really worried about that in JNCIA-DevOps. We just need to know that ZTP exists and the high-level of how it works.

Back on to step three above, here the DHCP server responds with a DHCP offer including an IP address along with the image name, config file name and location of these files. So, our switch can communicate on the network now because it has an IP address and likely a gateway, and it has the information as to what the name is of the software image that it should download and the name of the configuration file and what server to go look for these on.

The server that it can download this information from is an FTP, TFTP or HTTP server. Once our device is able to communicate on the network, the device downloads the image file and also the config file from the location indicated in the DHCP offer. It compares the running software version with the version of the downloaded software and sees if they’re different, if they’re the same it doesn’t install it, so it doesn’t have to go through the whole reboot process to install the image. If it is different, it will install the downloaded software and reboot.

Now, after it’s done with step 5, whether it needed to reboot or not it will go on to step six and the device commits the downloaded configuration and then it stops the ZTP process.