Introducing the Junos Automation Architecture
Let's understand the big picture for automation on Juniper devices.
MGD vs JSD vs Other D's
First, let's describe the different automation daemons on Junos and what kinds of workloads they service.
External Client
↓
gNMI (gRPC service)
↓
┌───────────────┐
│ Junos OS │
│ │
│ mgd ←→ config/state
│ │
│ other daemons│
│ │
│ JSD (optional apps)
└───────────────┘Knowledge Check
Which protocol is used for streaming telemetry in Junos automation?
Commit Scripts
Let's create a script that runs right before a commit operation.
# /var/db/scripts/commit/require_description.py
from junos import Junos_Configuration
from junos import Junos_Context
from lxml import etree
jcs = Junos_Context()
for ifd in jcs.xpath("interfaces/interface"):
name = ifd.findtext("name")
desc = ifd.find("description")
if desc is None:
jcs.emit_error(f"Interface {name} is missing a description")Knowledge Check
What is the primary function of a commit script in Junos automation?
Op Scripts
Let's create a script that we can run ad-hoc from privileged mode.
#!/usr/bin/env python3
from jnpr.junos import Device
def main():
with Device() as dev:
rsp = dev.rpc.get_interface_information(terse=True)
print("=== Interface Summary ===")
for name in rsp.xpath(".//physical-interface/name"):
if name.text:
print(f"Interface: {name.text}")
if __name__ == "__main__":
main()Knowledge Check
What is the primary advantage of using operational scripts in Junos devices?
Event Scripts
Let's create a script that is triggered by Junos events.
#!/usr/bin/env python3
import jcs
jcs.syslog("user.info", "Event script triggered")Knowledge Check
What is the purpose of configuring event scripts in Junos?
SNMP Scripts
Let's create a script that is fired by SNMP events.
#!/usr/bin/env python3
# /var/db/scripts/op/snmp_basic.py
"""
Basic on-box Junos SNMP op script.
Edit COMMUNITY, TARGET, and OIDS below for your environment.
"""
import subprocess
from junos import Junos_Context
jcs = Junos_Context()
# --- Update these for your environment ---
COMMUNITY = "public"
TARGET = "127.0.0.1"
OIDS = [
("sysName", "1.3.6.1.2.1.1.5.0"),
("sysDescr", "1.3.6.1.2.1.1.1.0"),
("sysUpTime", "1.3.6.1.2.1.1.3.0"),
]
# Optional walk. Set to an OID string to enable, or None to skip.
WALK_OID = None
def run_snmp_get(oid):
cmd = ["snmpget", "-v2c", "-c", COMMUNITY, TARGET, oid]
result = subprocess.run(cmd, capture_output=True, text=True)
if result.returncode != 0:
err = result.stderr.strip() or result.stdout.strip() or "unknown error"
return None, err
return result.stdout.strip(), None
def run_snmp_walk(base_oid):
cmd = ["snmpwalk", "-v2c", "-c", COMMUNITY, TARGET, base_oid]
result = subprocess.run(cmd, capture_output=True, text=True)
if result.returncode != 0:
err = result.stderr.strip() or result.stdout.strip() or "unknown error"
return None, err
return result.stdout.strip().splitlines(), None
def main():
jcs.output("=== On-box SNMP check ===")
jcs.output(f"Target: {TARGET}")
for label, oid in OIDS:
value, err = run_snmp_get(oid)
if err:
jcs.output(f"{label} ({oid}) -> ERROR: {err}")
else:
jcs.output(f"{label} -> {value}")
if WALK_OID:
jcs.output(f"=== SNMP walk {WALK_OID} ===")
rows, err = run_snmp_walk(WALK_OID)
if err:
jcs.output(f"walk ERROR: {err}")
elif not rows:
jcs.output("walk returned no rows")
else:
for row in rows:
jcs.output(row)
if __name__ == "__main__":
main()
Knowledge Check
What is the primary purpose of configuring SNMP scripts in the Junos Automation Architecture?
JECT Packages
Let's talk about what it would be like to develop an on-box application to handle and react to telemetry streams.
JET Application Development Workflow: https://www.juniper.net/documentation/us/en/software/junos/jet-developer/topics/topic-map/jet-on-device-applications.html
#!/usr/bin/env python3
import time
def main():
print("Hello from packaged JET app")
print("Sleeping for 5 seconds...")
time.sleep(5)
print("Done")
if __name__ == "__main__":
main()Knowledge Check
What is the primary purpose of developing a JET application on a Juniper device?
Terraform
Let's briefly talk about Terraform, a tool that can be used to declare what your desired state of the network should look like when it is done configuring devices.
terraform {
required_providers {
apstra = {
source = "Juniper/apstra"
version = ">= 0.60.0"
}
}
}
provider "apstra" {
url = var.apstra_url
username = var.apstra_username
password = var.apstra_password
tls_validation_disabled = true
}
variable "apstra_url" {
type = string
description = "Apstra server URL"
}
variable "apstra_username" {
type = string
description = "Apstra username"
}
variable "apstra_password" {
type = string
sensitive = true
description = "Apstra password"
}
resource "apstra_datacenter_blueprint" "lab_bp" {
name = "jncis-devops-lab-blueprint"
}
output "blueprint_id" {
value = apstra_datacenter_blueprint.lab_bp.id
}Knowledge Check
What is the primary purpose of Terraform in network automation?
CHALLENGE
Let's refresh what we've learned about Junos Automation components.
1. An engineer wants to block invalid configurations before they are committed on a Junos device.
Knowledge Check
Which component is responsible for this?
2. A developer builds a custom on-box application that continuously processes telemetry data and performs real-time analysis.
Knowledge Check
Which architecture is being used?
3. An external monitoring system subscribes to streaming telemetry data from a Junos device using gRPC.
Knowledge Check
Which component is handling the requests?
4. An engineer uses an external tool to define and deploy desired-state configurations across multiple devices in a declarative method.
Knowledge Check
Which automation method is being used?
View Transcript
Introducing the Junos Automation Architecture
0:00Welcome to the content on understanding the Junos automation architecture.
0:05What are we really talking about here?
0:07We're talking about what's going on under the hood.
0:10There are two distinct daemons that control how automation can be
0:15done or what can be done within the Junos operating system.
0:19There's also services that handle automation from the external world.
0:23We're going to talk about all of those.
0:25And then another part of our JNCIS journey recommends that we understand
0:29at least the basics of the management daemon scripts in the JNCIS.
0:34We learned a little bit about these commit scripts, op scripts, and so on.
0:38And in this set of videos, we'll actually take a look at what these
0:41scripts might look like and how you would go about configuring them.
0:45Now I will say this, it is a virtual lab environment using the VEX
0:49appliance, and a lot of the times you run into this, you'll see this in a
0:53later set of videos on like GRPC and GNMI, where they give you the core
0:58functionality to use this box.
1:01You'll type the commands, you'll type commit, and it will accept it.
1:05But when it comes time to actually use the automation framework, it may
1:09fail for one reason or another.
1:11So I want to give a little caveat right there that when we're talking
1:15about automation, lots of times we're talking about edge features, not
1:19core to actual performing routing and switching, but edge features.
1:24And these are the types of features that get cut off before they ship
1:27the virtualized images out there for lab environments.
1:30So take that with a grain of salt.
1:33But in this set of videos, we will talk about what you need to know for
1:37the JNCIS DevOps exam.
1:40So without further ado, let's talk about the management Jamin, the JSD,
1:45JET packages, and all the different scripts that we can build.
1:49Let's go.
MGD vs JSD vs Other D's
0:00Let us begin our JNCIS DevOps journey
0:03by talking about all of the plumbing
0:06that goes into Junos automation.
0:09If you're going through the JNCIA,
0:11just the JNCIA Junos,
0:13you learn about things like the packet forwarding engine
0:16and the routing engine,
0:17and some of the daemons that make it all work,
0:20primarily how to use the CLI
0:22to log in and configure the device.
0:24When you move into the JNCIA DevOps,
0:27it starts talking about how you can write scripts
0:31to work with the XML API,
0:33and a little bit about the on-box scripts that you can do,
0:37like op scripts and commit scripts.
0:39Now that you're in the JNCIS,
0:41we're taking a holistic approach.
0:43We're looking at the entire automation picture.
0:46And that's what the first bullet pointer,
0:48the first exam objective is,
0:51is to understand the architecture
0:53and all of the pieces that exist in the Junos world.
0:57There's really broken down into three distinct places.
1:02Let me get a good green color here,
1:05so this kind of separates my notes.
1:07Out here, outside of the box,
1:09we live in the external world.
1:11And this is how we,
1:12sitting here on our laptop writing scripts,
1:16connect in and manage the device through network automation.
1:20We're not talking about SSH and CLI.
1:23When we talk about this right now,
1:24we're talking about strictly network automation stuff.
1:27Now it doesn't have to be us on our laptop.
1:29It's important to understand a lot of these cases
1:32are actually software-defined networking controllers
1:36that want to connect into the box,
1:38manage the box, configure the box,
1:40and have a live stream of health from the box.
1:44So what we see here is when it comes to connecting in
1:48and maybe configuring the device,
1:51or just checking some operational states,
1:54it's going to use something like NetConf and XML,
1:58or potentially using REST APIs and REST Comp,
2:01although we know Juniper leans heavily
2:03towards the XML world.
2:05Now, a protocol that was not covered
2:07in the JNCIA that lives down here,
2:09one thing that you're going to learn in the very next skill
2:12is gRPC plus gNMI.
2:15gRPC is the protocol that transports data back and forth.
2:21gNMI is the application that generates the data
2:25to transport back and forth over gRPC.
2:27This is Network Management Interface, NMI.
2:31That is another way of saying network automation.
2:33And I'll give you a little spoiler right here.
2:35This is for streaming telemetry.
2:38This is almost always what we're talking about here.
2:41When we need a live look
2:43at what's going on with, say, interface counters,
2:46you'll get that from a software-defined
2:48networking controller, right?
2:51I'll log in, I'll click on my switch,
2:52I'll click on an interface,
2:53and I'll see what's happening
2:54on that interface in lifetime.
2:55That's coming from gRPC and the gNMI application.
3:00Now, that's all I'm going to tell you about it right now,
3:02aside from the fact that it doesn't really work
3:06on virtualized appliances.
3:08If you're in a virtual lab environment,
3:10don't expect to get this to work.
3:12It'll let you type the commands,
3:13and it'll even let you connect in over gRPC,
3:16but when you go to request data,
3:17it's simply not going to be there.
3:19That being said, this is something you should know.
3:23We're giving you a little preview
3:24for the skill that's coming next.
3:26Now, what about on the box itself?
3:30Like, let's say I SSHN, and I'm typing CLI commands,
3:33and I know those CLI commands go through the XML API.
3:37That's going through the management daemon.
3:40When we want to manage the device in a human way
3:43using the XML API, basically typing CLI commands,
3:48that's going through the management daemon.
3:50The management daemon also handles our three scripts.
3:54Remember, we have op scripts, we have commit scripts,
3:59and we have event scripts.
4:03Remember, the op scripts are basically
4:05operational commands, show commands.
4:07I have the ability to execute these.
4:09I can copy my Python scripts onto the hard drive
4:13or the flash drive of this Juniper switch
4:16and run those scripts directly on the box.
4:19That way, it doesn't require me
4:21to keep the Python scripts over here and execute them.
4:24If anything happens to the external environment
4:26and I lose those Python scripts, that's the problem.
4:30We can keep them directly on the box
4:31and run them directly on the box.
4:33So the op script is basically running a show command
4:36and printing the output to the terminal.
4:38The commit script runs before I hit,
4:41or runs before a commit takes place.
4:44So if I take commit and I press enter,
4:47before that commit actually happens
4:49and that configuration becomes valid,
4:52the commit script can run first
4:54and validate it doesn't break any of the constraints
4:57or rules or policies that I have on my own.
5:01So we can say, wait, before this commit runs,
5:03validate that it doesn't change
5:05the configuration in this way.
5:07And the event script is reactive in the sense
5:10that if a specific event fires on the box,
5:13that will automatically trigger the Python script to run.
5:17So this could be something like,
5:19you know, an SNMP trap fired off.
5:22And we wanna run this script
5:24so that it notifies us via telegram.
5:26That's the type of thing that we can do with event scripts.
5:30And these are what's managed by the management daemon.
5:32So it's very much more like
5:34the most traditional networking in the sense
5:37that you can think of managing it through the CLI
5:40or running scripts via the CLI
5:44or on specific things that commonly happen via the CLI.
5:48Down here, we have the JSD.
5:52This is the Junos service daemon.
5:55And what this is really all about
5:57is we actually build an application,
6:00like compiled into an application.
6:03And we want to run that application on the Juniper device.
6:08In the same way that GRPC is all about streaming telemetry
6:12and streaming live statistics of data,
6:15that's kind of the idea when we use JSD.
6:18We'll build an application that listens
6:21for live streaming data and telemetry and events.
6:25And we can then have that application
6:28be reactive to those events.
6:30For instance, we may see a spike in DDoS traffic
6:34and we can have an application detect that
6:37via the JSD and react to it,
6:40shutting down an interface or something of that nature.
6:44This is a big win because especially
6:47in the case of DDoS traffic, externality could be broken.
6:51We might not have the ability
6:53to get to the external side of things.
6:55So we still need some local solution
6:58that operates directly on the box
7:00and prevents these big issues from happening.
7:03That's why we have the JSD.
7:05Now these types of applications
7:07are not just any old application that you can create.
7:10They usually have to be encoded
7:12in a very specific Juniper specific package
7:15that we call JET.
7:18That's short for the Juniper Extension Toolkit.
7:22But luckily you can still use Python to do this.
7:24We can write our code in Python
7:26and then use the JET Toolkit to compile our application
7:31into runnable bytecode that we can then transfer
7:34to the Junos operating system
7:36and interestingly install it almost the same way
7:40you've seen when we installed the Junos operating system.
7:42If you've ever done the system software package
7:45add type command, you're doing the exact same thing
7:49with your own application that you build
7:51right here using JET.
7:52So these are three different ways
7:55to tackle network automation.
7:57Now there's also more things out here
7:59in this external ecosystem like Ansible,
8:03which the JNCIS wants you to know a lot about
8:06and Terraform, which the JNCIS wants you to know
8:10a little bit about, but not necessarily use.
8:12They really want you to lean into Ansible.
8:14These two are kind of competing tools
8:17for network automation and network management.
8:20Terraform dominates cloud,
8:23cloud deployments for DevOps pipelines
8:25and everything like that.
8:27Ansible kind of dominate specifically network engineering
8:30and network automation,
8:31which is why the JNCIS leans in heavily into Ansible.
8:35So now that we kind of understand a high level overview
8:38of the network architecture,
8:40this skill is going to largely focused in
8:43on the management daemon and the JSD.
8:46We're gonna focus in a lot on these scripts.
8:49We're also gonna talk about what you could do with JSD,
8:52especially if your lab environment supports it.
8:56So without further ado, let's progress on to the next video.
Commit Scripts
0:00We're going to begin this journey by talking about scripts.
0:03Now, like I said, we are here.
0:06We're supposed to be talking about the management daemon process,
0:09Terraform, and really JSD, which is the JET tools here.
0:13But the GM objectives are just to understand them,
0:17identify concepts, general features and functionality.
0:20It's not configure and implement.
0:23But if we scroll down to the scripts section right here,
0:29now we move in to describe the concepts, benefits,
0:31or operation of automation scripts,
0:35and that or operation could be how to actually use them or configure them.
0:41Considering these come under the umbrella of MGD,
0:45it makes sense to talk about them now as a combined topic
0:50so that we can fully understand how the MGD is working.
0:55So let me walk you through a very basic first one.
0:58We're going to talk about commit scripts.
1:00Remember, commit scripts run right before.
1:03If I type the commit command and press enter,
1:06commit script will run right before it actually commits the new configuration,
1:12validating that we haven't broken something.
1:14So here we have a commit script example.
1:17Actually, this is the commit script example right here.
1:19It's pretty basic.
1:21We actually use built-in functionality that's built in to the Junos operating system
1:27using either Junos or LXML.
1:29Of course, we know LXML helps us parse XML data.
1:34We load the Junos context into a variable called JCS,
1:39and then we look for each of the interface descriptions for IFD
1:45in the path for each one of these interfaces.
1:47We understand the configuration tree goes from interfaces
1:51into an individual interface from there.
1:54We're looking for the interface name and the interface description,
1:58and our policy says if the description is empty,
2:02if there is no description, raise a commit error.
2:06This will stop the commit from happening,
2:09and it will say the interface with this name is missing a description.
2:14So we're enforcing that all of our interfaces have a description,
2:19and we validate this whenever somebody comes along and types the commit command.
2:23That's what's happening here.
2:25So what do we do next?
2:27We need to take this Python script that's on my computer,
2:30and we need to get it onto the remote Juniper device.
2:35So what I can do is I can use a tool like SecureFX to SCP these stuff in.
2:41This really works like an SFTP server, but it's all over port 22.
2:45It's all over port SSH.
2:46So I'll go into VEX1, and we'll start to navigate where to put it.
2:51For a Junos device, we'll first look in VAR,
2:57then DB, then we'll go down to the scripts folder,
3:01and ah, there they are right there.
3:03There's all the different kinds of scripts we can have.
3:06Commit, Event, and Op, as well as SNMP are the big ones
3:11that they want you to know about on the Junos boxes.
3:14So if I look in commit scripts right here,
3:16there's actually some commit scripts that are already here.
3:19But I can move my commitment script over by just dragging it on,
3:23and now that commit script lives on this Junos device.
3:27So now the question becomes, how do I make the box use it?
3:30Well, I need to set it as a configuration and tell my Junos device
3:34that there is this commit script that it can start using.
3:37So down here, I'll go and log in.
3:39We'll increase the font size a little bit.
3:42I'll go into edit mode to set the configuration.
3:45I'll move into edit system, and then scripts right here.
3:52If I type show, we see I've got no configuration.
3:56So this is where I want to set my configuration.
3:58I'll do set and give it a question mark.
4:00The first thing I want to tell it is what language are my scripts using.
4:04So I'll say language, and then Python 3.
4:08We'll press enter here.
4:09Now when I say show, we can see I've got the first thing set.
4:12Now I want to create a commit script that it knows about.
4:16We'll say set commit, give it a question mark,
4:19and we go, okay, well, where does this commit script live?
4:22We specify it by its file and its full path.
4:26The full path was far db scripts commit,
4:31and then the name of my script, which was commitment.py.
4:36It may be in a situation ship.
4:38Got some commitment issues.
4:40We got to take it up there.
4:41So I'll press enter here.
4:42Oh, we got a error statement.
4:44Cannot open a single quote forward slash.
4:49Perhaps that's because it already knows where to go to look for commit scripts.
4:55It has a folder for that.
4:57So we'll just call it by name, commitment.py.
5:00Ah, it likes that.
5:02Give it a show command, and now we say our commit scripts are a language of Python 3,
5:07and this is the script that you want to run.
5:09Let's give it a commit and quit.
5:11Oh, well, look at that.
5:13Now, it didn't print the exact message I expected,
5:15but like I said, these virtualized environments are a little,
5:20you know, not quite production ready,
5:23if I say when it comes to a lot of features like this.
5:28But let's see, if I actually exit out of this,
5:30let's do exit, and then exit,
5:34and we'll say, no, I don't want to,
5:36we'll leave these changes uncommitted.
5:37Wait, exit with uncommitted changes.
5:38Yes, I want to do that.
5:39Do show log messages.
5:42Let's see if it actually found and ran the Python script.
5:45I got to zoom out a little bit for this
5:47and scroll all the way to the bottom of this log.
5:49You can see right there,
5:51the very bottom of those percentages are roaming,
5:53and it should be one of the very last things we see.
5:55Okay, so here's where we go.
5:58We had a database login event,
6:00followed by a commit, followed by the script.
6:04Now see right here, the unsigned Python script
6:06without checksum is executed right there.
6:10That tells me it found the script and ran it.
6:14It was executed.
6:16It raised an error,
6:18and that's what caused the commit to fail.
6:20Now, why didn't it print the full message
6:22out to the terminal?
6:23Again, I'm probably chalking that up
6:25to this is a virtualized new box that's running.
6:29It doesn't have the full-fledged feature support
6:32that we expect.
6:33But it is working on these commit scripts now.
6:37So this is kind of the flow for creating a commit script
6:40and seeing how we can leverage it right out of the gate.
6:43Now, if you want to take a careful look at the script again,
6:46take a look at it.
6:47We've got the sample code provided right here
6:50above the video that you're watching.
6:52So commit scripts done.
6:54Next video, we'll talk about op scripts.
Op Scripts
0:00Now, just so it doesn't hang us up and I have to go in and set a description for every single
0:04one of my interfaces, I just reverted the commit script we created in the last video
0:10so that I can move on to the op script next, which is another fun one.
0:15Let's take a look at an op script. This is basically doing show interface. Give me a
0:20specific interface that we want to care about. So in this case, again, we're loading the Junos
0:25context. And then we're saying, this is basically the print statement. Instead of using print,
0:31we do output. So it prints this out to the terminal. And then we specify what is it that
0:36we want to query. We're going to use the Junos context specifically with an XPath to parse the
0:42configuration down to interfaces, then for a given interface, then find their name. Just a very basic
0:49idea that we want to print the interface names. For every interface that lives in the list of
0:55interfaces, we will again print using the output method, interface followed by the name of the
1:01interface right there, iface.txt. Very basic, but this would be your first step into understanding
1:08if this is working. Again, lab environment, lightweight appliances, not fully feature rich.
1:14This may not work, but we'll give it a try. Bringing back this terminal here again for
1:20secure fx, we can see I, instead of doing my commit sections, will do op scripts right here.
1:28And sure enough, there's quite a few op scripts that come baked into this device by default.
1:34I'll go ahead and grab my op script, cleverly called op script. I'll drag it over here to the
1:39folder. If it'll let me, hang on, I got to get a little better sizing here to find an empty space.
1:44I'll grab op script one more time, drag it over here to the folder. And now the op script, you
1:50can see the .py file has been brought over. Similar configuration as to the commit script.
1:57We'll jump back onto the box right here. We'll go back into, let me zoom in a little bit,
2:02we'll go back into edit mode, edit system scripts. If I do show right here, you can see
2:09I kept language of Python 3 baked into it. We do have to specify that, that we're using Python
2:15and not something like slacks, which was a legacy language used on Juno's devices.
2:21So from here, I'll do set, hit question mark. We've already got, we're in the script section.
2:26So here I say op, then it wants to know what's the file name. Mine was called op script .py.
2:34Hit show. And there it is. There is my op script now in the environment.
2:39So I'll commit this configuration. Won't blow up this time because I don't have a commit script
2:44to blow it up. There it goes. Commit succeeds. And then I'll exit out of configuration mode.
2:51Let's do one more exit. And this may or may not work. Why? Because really the Juno's,
2:59the way Juno's Python scripts have evolved, have gone from kind of a legacy implementation
3:05to a newer implementation. Luckily I come prepared for both. Let's try this first.
3:10I'll try op script .py. And sure enough, it blows up. It doesn't really understand
3:16how we're using or importing JCS because that was kind of an older implementation.
3:22Now we can actually use the Juniper library that's much closer to pyez. And I have a script for that
3:28too, right here. This time we're using the device class. This is almost identical to what pyez does.
3:36And in this case, the device class, we can actually use the device RPC and then pass in RPCs,
3:43just like the XML API. In this case, we're going to say get interface information with terse equals
3:49true. We know we get the response back in an XML payload. We can leverage XPath to find the
3:56physical interface name and then print that interface name out to the terminal, run the
4:02script if that's what we want to do. So this is called newop.py. And just for good measure,
4:08I've currently loaded it onto the box. And I can show you show system configuration,
4:15excuse me, show configuration system, show configuration system scripts. And you can see
4:23I've gone ahead and placed that in the operational script section. So if I say now run my operational
4:31script by saying op, then newop.py, press enter. The fact that you don't get a response immediately
4:40is actually a really good sign that means it's working. There it is right there. There's those
4:45physical interface names, just like that. So that right there is how you can create operational
4:52scripts. Why is this useful? I mean, all I did was print out interface names. You could have done
4:56show interface to yourself. Because you can write useful Python scripts that can run multiple
5:03commands, concatenate data together, join data together, or split data apart and print out the
5:10key metrics or useful things that you care about. Instead of logging into a box and typing four or
5:16five show commands, what if you just ran one script, gleaned all the information out of it
5:22that you really care about, and then saw it here on the terminal? You could call this your daily
5:28operation script. So you could log into your boxes and run your daily operation script right there
5:34and see all of the key things that you care about right there on front. These are operational scripts.
Event Scripts
0:00Next up, we have event scripts. And the only thing that this really deviates from that we've done
0:05so far is we have to go into the configuration and tell it which specific events should trigger
0:11which specific script. So here, there's nothing really special happening here. I'm just importing
0:17JCS, the Junos configuration system. I'm going to use the syslog method to log a info message
0:25right here that has the message event script triggered just to get it kicked off. Again,
0:31virtualized lab environment, lightweight images. There's a non-zero chance that this doesn't work,
0:37but here we go. I'm going to move this script, my event script right here, over into the events
0:44folder, which again is var db scripts, and then the type of script that you care about.
0:49So I'll move the event script over just like that. And sure enough, that event script now lives there.
0:55I got to jump back into my CLI and configure this event script. Here's how to do it.
1:00We move into configuration mode, and then we move into event options. This is where we set up
1:06events. We create policies that say when certain events trigger, this is what we want to do about
1:13it. It's not always just event scripts. We can really set up all sorts of policies surrounding
1:18events, but this is a network automation skill, and therefore we're talking about what Python
1:23scripts we can run on certain events. So we'll do set event options. We're already in event
1:31options. If we give us a question mark, you can see what we're trying to do is we're trying to
1:34create a policy. Eventually we'll need both, and that'll make more sense. In fact, let's do it this
1:41way. This will actually make more sense. We'll first tell the Judo operating system that there
1:46is an event script that exists on this box. We'll tell it by its file name, which was very cleverly
1:51event script.py, and it sets this configuration. If you see show, now it knows there is an event
1:57script named event script.py. Now we'll create a policy that uses that event script. Now we'll say
2:05policy, and we'll call this something like if, I don't know, down. This is just an arbitrary name
2:14that we're giving this policy, but I want it to know what is the policy about. It's when the
2:19interface goes down. We'll say the events that we care about, and if you give it a question mark
2:24right here, it doesn't let you really do much probably. In fact, it's kind of hung up here
2:28because there's a trillion events on this box, and if it tries to give you a list of every single
2:34thing that happens on this box, it'll print for forever. So I'm going to hit control C. Notice
2:39with that scroll right there, all of those events, it made zero percent of progress. So really you
2:46need to just know what event you want to look for. Look it up in ahead of time. The event that
2:51I care about is interface hyphen down. That means the interface is, well, down. So in this case,
2:59we'll say, what do we do when the interface is down? We say policy for if down, then hit question
3:07mark. We want to execute our event script that we've already configured. I don't have to specify
3:13the file command right here. I can just say event script dot py. Now when I say show, this is what
3:21the full configuration looks like. So when an interface goes down, when the event triggers it,
3:27that's what's going to make this event script kick off. I'll give this a commit and quit,
3:35and there we go. So at this point now, when the physical interface goes operationally down,
3:42then the event script will kick off and it should trigger something printed to the terminal.
3:48So now should one of our interfaces go down, you know, the link gets unplugged or whatever the
3:53case is, that will fire the event script to trigger off and print syslog messages to the terminal.
SNMP Scripts
0:00Our final script type to discuss is also the third event-driven script type that we're talking about.
0:07This is one that triggers upon an SNMP trap event from a specific OID that you configure,
0:14or multiple OIDs that you configure. Now, this can be a little bit of a nuanced
0:20script to look at. In this case, when the OID fires off an event, it'll actually perform an
0:26SNMP walk to get the information from the SNMP triggered event. There's also the ability to run
0:33an SNMP get command to get data from a specific OID event. Right here, we see in the main function,
0:40it's going to print out all of the details, including the target, the labels, and the OIDs
0:46out to the terminal telling you about this information. Now, naturally, what we would
0:50also do with this, with SNMP events, is we would probably set up some sort of notification system.
0:56I mean, that's really the whole point of SNMP is a trap to fire off and then let somebody know the
1:02detail of the event that occurred. But also, there's the ability to pull and get data from these SNMP
1:08OID events as well. That being said, I think we all probably agree that NetConf, REST APIs,
1:17gRPC, and gNMI are the better solutions. In fact, that's the entire point that it was created,
1:23was to replace or overcome the limitations of SNMP some 20-odd years ago. Still, there are many
1:31software-defined networking controllers and network management tools that implement SNMP
1:37to some degree. And if that's going on in your environment, you can leverage Python SNMP events
1:44or SNMP scripts. So just like we've done, we're going to transfer this over. This time, it's going
1:49into the SNMP folder, which is currently empty. I'll transfer SNMP basic over, like so, and now it
1:57lives on the box. Now, what we need to do is we need to get to the box and configure it to use
2:02these SNMP scripts. So I'll go into edit mode, and then I'll go into edit SNMP. There's really only
2:08two commands that we have to do here. I'll do set script. Wait, not under SNMP. I got this
2:16backwards for one second. We're going to go into set system scripts SNMP. And what comes next,
2:22we're probably asking for the file name. In this case, it was SNMP basic.py. Now, one of the things
2:31with SNMP scripts, as well as event scripts, that we also have to give it privilege to,
2:37is we have to run Python scripts as a specific user. So when I hit up right here, I can also type
2:44in py to autocomplete Python script user. Here, I'm going to type in my own account. So it runs
2:51Python scripts under my account, which has privileges to access all portions of the Junos
2:58device. I can't stress this enough. You have to do this under the event scripts as well. I glazed
3:06over that in the last video, but now I'm talking about it, and I want to make sure you get it.
3:11At this point, all that's left is a good old commit and quit. Nope, wait, it's not. It's
3:17missing a mandatory statement. What OID does this script attach to? Duh, that's a pretty obvious
3:22one. If I go right here, after specifying the file name, I can hit question mark, and now we have to
3:28attach this to OIDs. So if I say OID here, I'll just grab a sample one coming from this script,
3:35like the system name, copy and paste right there, and press enter. Now we've got the OID.
3:44Let's give it a commit check to make sure this now validates. The fact that it hasn't blown up yet
3:50is a really good sign. The configuration now succeeds. So let's take a look at set system
3:55scripts real quick and do the show command. First thing, we specify the language of Python 3.
4:00We have our op scripts that we can run on demand or ad hoc, and then we have our SNMP scripts,
4:06which as we know, are event driven. We specify the file that runs, the OID that it's attached to,
4:13and the user that it runs as. Now, like I said, we do the same thing for events,
4:18and if you want to look at the event options, event script, you can see I've gone ahead and I
4:23put the Python script user right after the file on that one as well, so that it works.
4:29So now that we have this configured, oh, wait, wait, wait, nope, nope, nope, nope. Let's just
4:34go make sure we do commit and quit, because that was a commit check I did, not a full
4:38commit and quit. Now we're committing this configuration and exiting out. So when SNMP
4:43gets enabled on this box and configured, and it tracks the right OIDs and does the trap messages
4:49and everything, now it has a Python script that it's listening for those events as well,
4:55and will execute whenever those SNMP events happen.
JECT Packages
0:00Now in this video, I'm really drawing your attention
0:02into how JET applications work.
0:05Remember, this is the Juniper Extension Toolkit.
0:09What's the whole point of this again?
0:11This is rapid fire, quick reacting to data,
0:15locally on the box.
0:17So again, if this is the box right here,
0:20and we need a high performance app
0:24to be installed into the free BSDR operating system
0:29of Juniper, this is running side-by-side with the CLI.
0:33So, okay, let's take one step back, right?
0:36Here's your Juniper box,
0:37and it doesn't just run Junos, does it?
0:40No, it runs free BSD, which looks and feels a lot like Linux
0:44and then Junos is an app that runs on top of it.
0:48We can also install our JET application to run side-by-side
0:54and interact with this Junos device.
0:56The primary reason we wanna do this
0:59is to enable something like live monitoring
1:04and event detection in a high performance nature.
1:09This is usually doing things like live streaming.
1:12From the external world,
1:13we would use something like gRPC for this,
1:16but on this box, we can have it connect
1:19into the box directly,
1:20and it changed my color to yellow for some reason.
1:23We can have it connect into Junos directly
1:25and get a live feed of events like interface counters,
1:29OSPF flapping, or something like that.
1:31And then very importantly,
1:33we can have our application react to the live stream event
1:37however we want to.
1:38It's our application.
1:39We can code it however we want.
1:40Do we want it to change the configuration?
1:42We can do that.
1:43Do we want it to notify us?
1:44We can do that.
1:45Do we want it to just silently drop it and continue?
1:47We can do that.
1:48But this is a huge, huge process,
1:50and that's why it's not on the exam.
1:53Look at it.
1:54Right here, we've got a on-device JET application workflow.
1:59Are we going to sign this application,
2:01meaning the operating system will see it
2:04as a signed application and know that it trusts it?
2:08This is good for security reasons.
2:11Does the application come from someone
2:12that we know or trust?
2:13And if not, this really only supports Python apps only.
2:18We can configure it as a script
2:20and then deploy the application script on Junos,
2:23and it will run.
2:24But most of the time, we want to actually build
2:27and compile an application with signing
2:30if we're going down the JET way.
2:32This supports C, C++, and Python.
2:36But as you can see, the development itself
2:38is quite involved.
2:39Right here, we have to, on our local environment,
2:42right here, here's me, the developer.
2:44I'm on my laptop.
2:46I have to download a VM, a Vagrant VM.
2:50Vagrant is kind of like a pre-built image application.
2:54It helps you stand up development environments very quickly.
2:58Developers do this frequently.
3:00If they know they're targeting this kind of server
3:03over here, and it has XYZ packages,
3:08software bundles already installed into it,
3:12I can use Vagrant to more or less take a snapshot
3:16of that remote server here,
3:20and I can use that snapshot to deploy little developer VMs
3:25that I can then do my local development inside of.
3:28So here, they've got a Vagrant VM
3:30that mimics your Junos environment
3:33that you would have to download and install
3:35on your local environment and spin it up.
3:38Within that, we'll download
3:39the software tool chain package.
3:42Basically, what are all the prereqs required
3:44to build and compile software for Junos?
3:47Then you go through the certificate process.
3:50Acquire a certificate, build the package,
3:53and using the acquired certificate,
3:56sign it using the acquired certificate,
3:58and then you can go deploy it on a Junos device.
4:02Now, this part right here, these download Vagrant VMs
4:05and download SB tool chain,
4:08those seem like they're the most involved steps,
4:10and you would be right.
4:11They do give you a lot of instructions on how to do that,
4:16and it walks you through the steps
4:18of installing everything you need in your environment.
4:22So you can actually see what's pretty interesting
4:24in their little JetVM environment.
4:27They're actually installing gRPC clients
4:30so that they can get a connection on the same box via gRPC
4:35and get that live stream of data coming in like that.
4:38So the big takeaway in this video
4:40that I wanted you to understand
4:42is understanding that JSD and JET are separate
4:48from the things that we've been doing up until now.
4:51Basically, everything that you've done
4:53in your Juniper journey has been some interaction with MGD,
4:57whether that's via external applications
4:59that are logging in and then performing things
5:02like show commands or whatever,
5:04or on box with all of the four different kinds of scripts
5:07that we've covered up until now.
5:09When it comes to JSD,
5:11this is when we start turning our switch
5:14or our router more into a computer,
5:17and we leverage the free BSD operating system
5:21that's running on it and build applications
5:24that run alongside Junos
5:28and allow two-way communications going on like that.
5:31With gRPC, we do have the ability
5:34not only to get a stream of data,
5:36but also set commands over that gRPC stream.
5:40So our application can be reactive to things
5:43like we've noticed a DDoS attack on gig E 000.
5:48The app can see that and shut it down
5:51if that's what we wanna do.
5:52And then perhaps if we still have some form
5:55of outbound connectivity,
5:56like through the management interface,
5:58we can probably send some sort of notification,
6:01raise a JIRA ticket, critical event-driven environment,
6:06where we can notify our primary network engineers
6:09that this event has taken place.
6:12So that's the benefit of building applications for JIT.
6:16We have high performance on-box local resolution,
6:21local problem-solving resolution detection
6:24and prevention on the box itself
6:27when we build our own applications.
Terraform
0:00Now, I think it's kind of interesting that the JNCIS puts a heavy emphasis on Ansible,
0:05which is kind of the dominant network automation tool, and not much of an emphasis on Terraform.
0:13Terraform is definitely more of a software developer's choice because it's all about
0:19building a whole environment, you know, by declaring exactly what it is that you want.
0:25You see this a lot in cloud environments where they use Terraform to build something like a
0:32fleet of servers with these exact operating systems and these exact configurations,
0:37and all of these packages or apps installed into it. And then, by association, servers need
0:43networks. So after time, they've built Terraform to extend to network devices to support it.
0:50Again, this is largely used in the cloud. You do see it for things like deploying VPSs in AWS or
0:56VNets in Azure. But now, Terraform has started to work with, you know, our own network devices that
1:03we know and love, especially as people have started to kind of shift away from the cloud
1:08and have more of a hybrid environment because some things don't make sense in the cloud,
1:12like core infrastructure. That's your active directory or your file share, those things that
1:18you absolutely have to have. And, you know, it can be cost prohibitive to have everything
1:24in the cloud anyways. So if our development environment is in a co-located data center,
1:31and we've got racks of equipment right here and here and here, and our developers are down here
1:36on their laptops trying to break our infrastructure, they're going to ship the need for new
1:43virtual machines and perhaps even new subnets to go along with those virtual machines and the
1:49switches that they connect to, the top rack switches or the access switches, whatever,
1:53they need to know about these new VLANs. Enter Terraform to help them out. Now, again, and I
2:00can't stress this enough, you'll see network engineers lean towards Ansible first, whereas
2:05Terraform is really, really popular among software developers. The whole idea with Terraform is that
2:12they can specify exactly what they want out of their entire environment in this one file called
2:20an HCL file. That's not, you know, hydrochloric, whatever. That is HashiCorp language. HashiCorp
2:30are the people who created Terraform, and they created their own language, HashiCorp language.
2:36Thus, files are called HCL. It does kind of look like JSON or kind of look like a Python dictionary,
2:44but it's not. It's its own thing. Now, here's where it really, you know, becomes magical. This
2:49is where it's interesting. You as a network engineer don't specify line for line what
2:55configuration it should be setting. Instead, you just kind of declare what the end state of the
3:01network should be. Like, I need EVPN VXLAN up and running, you know, via Apstra or something like
3:08that. And the cool thing about it is Terraform has these things called providers. Providers serve as
3:15a translation layer. Take this HCL file and make it configurations on the switch itself. That's what
3:23this provider does. So, right here in the data center world, we have Juniper Apstra as our
3:29software-defined networking controller to manage our entire, you know, data center environment, and
3:34all the switches are joined to Apstra. So, here we can leverage the Apstra provider to declare what
3:40our Apstra environment should look like and what configurations Apstra should push out to all of
3:46our data center switches. We customize the Apstra provider by giving it a URL, a username, and a
3:52password to connect to Apstra on. Then we can also say variables right here that we want to run at
3:59runtime or pull from an environment variable. When we scroll down here, the resource is the
4:06configuration. That's the thing that we're pushing out to the terminal. We're saying connect to that
4:13Apstra environment and then push out this lab blueprint information. The output right here is
4:21what is going to be printed out to the terminal, basically confirming what's taken place. Now, again,
4:28this is not something that they actually want you to implement for the exam. It's just something that
4:33they want you to know that HCL and Terraform are all about declaring what the end network state
4:40should be. We call this, well, declarative. And the provider itself is what handles the translation of
4:50what we declared into making it official set commands and configuration commands.
4:56So this has been the basics of Terraform and really understanding the network automation
5:01architecture in the Juniper environment. Our next major things that we're going to tackle and talk
5:07about are going to be all about building and implementing with Ansible. So you better roll
5:11up your sleeves and expect to have a fun one there. I hope this has been informative for you,
5:15and I'd like to thank you for viewing.
CHALLENGE
0:00Let's review our first lesson and our first skill
0:03in the JNCIS, which is where we start to understand
0:06the real big picture of Juniper architecture.
0:10An engineer wants to block invalid configurations
0:13before they are committed on a Junos device.
0:16Which component is responsible for this?
0:18I know you immediately went, oh, commit, commit scripts.
0:22But I'm asking which process handles commit scripts.
0:25Is it MGD, Terraform, GNMI, or JSD?
0:31It's MGD.
0:32MGD is the one that manages our Python scripts,
0:36event, op, commit, and SNMP.
0:39Remember, Terraform is an external
0:42configuration management tool,
0:43where we declare the instate of the network
0:46and it handles the rest.
0:47GNMI is network management over gRPC,
0:51primarily used for streaming telemetry.
0:55And JSD is primarily used for on-box streaming telemetry,
0:59which is where we build our own application
1:01and run it there.
1:03A developer builds a custom on-box application,
1:05speak of the devil, that continuously processes
1:08telemetry data and performs real-time analysis.
1:11Which architecture is being used?
1:13Well, I literally just gave that away.
1:15It's not Terraform, it's not MGD, it's not NetConf.
1:18That's external as well.
1:19This is JSD-based automation.
1:22The giveaway here is on-box application,
1:25but also telemetry.
1:27Both of those things mean JSD.
1:31An external monitoring system subscribes
1:33to streaming telemetry from a Junos device using gRPC.
1:38Which component is handling the request?
1:41And this is another kind of tricky one.
1:43JSD, MGD, GNMI over gRPC, or commit scripts?
1:49Well, this is an external system,
1:53and even though there's telemetry, it's external.
1:54JSD is for on-box only, so that one's out.
1:57And it's not commit scripts,
1:58this has nothing to do commit scripts.
2:00Now you might be thinking MGD,
2:03but really what we're talking about here
2:05is streaming telemetry over gRPC.
2:09That uses the G network management interface
2:13over gRPC to implement that.
2:16That's the monitoring system
2:17and that's the component that we're using.
2:20An engineer uses an external tool
2:23to define and deploy desired state configurations
2:27across multiple devices in a declarative method.
2:31Which automation method is being used?
2:33It's not the REST API.
2:35This is, we're talking about desired state configurations.
2:38The REST API would be a targeted configuration
2:41pointing to a specific config.
2:43It's not MGD, it's not JSD.
2:46Of course, we're talking about Terraform here.
2:48So that wraps up what we've learned
2:50about Junos architecture and automation.
Team training path
Turn this skill into assignable team training
This free skill is a preview of the courses your team can assign, track, and report on with CBT Nuggets.
$708
seat / year