Understand the Junos Automation Architecture

0:00Welcome to the content on understanding the Junos automation architecture. What are we really talking about here? We're talking about what's going on under the hood. There are two distinct daemons that control how automation can be done or what can be done within the Junos operating system. There's also services that handle automation from the external world. We're going to talk about all of those. And then another part of our JNCIS journey recommends that we understand at 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. And in this set of videos, we'll actually take a look at what these scripts might look like and how you would go about configuring them. Now I will say this, it is a virtual lab environment using the VEX appliance, and a lot of the times you run into this, you'll see this in a later set of videos on like GRPC and GNMI, where they give you the core functionality to use this box. You'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 fail for one reason or another. So I want to give a little caveat right there that when we're talking about automation, lots of times we're talking about edge features, not core to actual performing routing and switching, but edge features. And these are the types of features that get cut off before they ship the virtualized images out there for lab environments. So take that with a grain of salt. But in this set of videos, we will talk about what you need to know for the JNCIS DevOps exam.

1:40So without further ado, let's talk about the management Jamin, the JSD, JET packages, and all the different scripts that we can build. Let's go.

0:00Let us begin our JNCIS DevOps journey by talking about all of the plumbing that goes into Junos automation. If you're going through the JNCIA, just the JNCIA Junos, you learn about things like the packet forwarding engine and the routing engine, and some of the daemons that make it all work, primarily how to use the CLI to log in and configure the device. When you move into the JNCIA DevOps, it starts talking about how you can write scripts to work with the XML API, and a little bit about the on-box scripts that you can do, like op scripts and commit scripts.

0:39Now that you're in the JNCIS, we're taking a holistic approach. We're looking at the entire automation picture. And that's what the first bullet pointer, the first exam objective is, is to understand the architecture and all of the pieces that exist in the Junos world. There's really broken down into three distinct places. Let me get a good green color here, so this kind of separates my notes. Out here, outside of the box, we live in the external world.

1:11And this is how we, sitting here on our laptop writing scripts, connect in and manage the device through network automation. We're not talking about SSH and CLI. When we talk about this right now, we're talking about strictly network automation stuff. Now it doesn't have to be us on our laptop. It's important to understand a lot of these cases are actually software-defined networking controllers that want to connect into the box, manage the box, configure the box, and have a live stream of health from the box.

1:44So what we see here is when it comes to connecting in and maybe configuring the device, or just checking some operational states, it's going to use something like NetConf and XML, or potentially using REST APIs and REST Comp, although we know Juniper leans heavily towards the XML world. Now, a protocol that was not covered in the JNCIA that lives down here, one thing that you're going to learn in the very next skill is gRPC plus gNMI.

2:15gRPC is the protocol that transports data back and forth. gNMI is the application that generates the data to transport back and forth over gRPC. This is Network Management Interface, NMI. That is another way of saying network automation. And I'll give you a little spoiler right here. This is for streaming telemetry. This is almost always what we're talking about here. When we need a live look at what's going on with, say, interface counters, you'll get that from a software-defined networking controller, right?

2:51I'll log in, I'll click on my switch, I'll click on an interface, and I'll see what's happening on that interface in lifetime. That's coming from gRPC and the gNMI application. Now, that's all I'm going to tell you about it right now, aside from the fact that it doesn't really work on virtualized appliances. If you're in a virtual lab environment, don't expect to get this to work. It'll let you type the commands, and it'll even let you connect in over gRPC, but when you go to request data, it's simply not going to be there. That being said, this is something you should know.

3:23We're giving you a little preview for the skill that's coming next. Now, what about on the box itself? Like, let's say I SSHN, and I'm typing CLI commands, and I know those CLI commands go through the XML API. That's going through the management daemon. When we want to manage the device in a human way using the XML API, basically typing CLI commands, that's going through the management daemon. The management daemon also handles our three scripts.

3:54Remember, we have op scripts, we have commit scripts, and we have event scripts. Remember, the op scripts are basically operational commands, show commands. I have the ability to execute these. I can copy my Python scripts onto the hard drive or the flash drive of this Juniper switch and run those scripts directly on the box. That way, it doesn't require me to keep the Python scripts over here and execute them.

4:24If anything happens to the external environment and I lose those Python scripts, that's the problem. We can keep them directly on the box and run them directly on the box. So the op script is basically running a show command and printing the output to the terminal. The commit script runs before I hit, or runs before a commit takes place. So if I take commit and I press enter, before that commit actually happens and that configuration becomes valid, the commit script can run first and validate it doesn't break any of the constraints or rules or policies that I have on my own.

5:01So we can say, wait, before this commit runs, validate that it doesn't change the configuration in this way. And the event script is reactive in the sense that if a specific event fires on the box, that will automatically trigger the Python script to run. So this could be something like, you know, an SNMP trap fired off. And we wanna run this script so that it notifies us via telegram. That's the type of thing that we can do with event scripts. And these are what's managed by the management daemon.

5:32So it's very much more like the most traditional networking in the sense that you can think of managing it through the CLI or running scripts via the CLI or on specific things that commonly happen via the CLI. Down here, we have the JSD. This is the Junos service daemon. And what this is really all about is we actually build an application, like compiled into an application.

6:03And we want to run that application on the Juniper device. In the same way that GRPC is all about streaming telemetry and streaming live statistics of data, that's kind of the idea when we use JSD. We'll build an application that listens for live streaming data and telemetry and events. And we can then have that application be reactive to those events. For instance, we may see a spike in DDoS traffic and we can have an application detect that via the JSD and react to it, shutting down an interface or something of that nature.

6:44This is a big win because especially in the case of DDoS traffic, externality could be broken. We might not have the ability to get to the external side of things. So we still need some local solution that operates directly on the box and prevents these big issues from happening. That's why we have the JSD. Now these types of applications are not just any old application that you can create. They usually have to be encoded in a very specific Juniper specific package that we call JET.

7:18That's short for the Juniper Extension Toolkit. But luckily you can still use Python to do this. We can write our code in Python and then use the JET Toolkit to compile our application into runnable bytecode that we can then transfer to the Junos operating system and interestingly install it almost the same way you've seen when we installed the Junos operating system. If you've ever done the system software package add type command, you're doing the exact same thing with your own application that you build right here using JET.

7:52So these are three different ways to tackle network automation. Now there's also more things out here in this external ecosystem like Ansible, which the JNCIS wants you to know a lot about and Terraform, which the JNCIS wants you to know a little bit about, but not necessarily use. They really want you to lean into Ansible. These two are kind of competing tools for network automation and network management. Terraform dominates cloud, cloud deployments for DevOps pipelines and everything like that.

8:27Ansible kind of dominate specifically network engineering and network automation, which is why the JNCIS leans in heavily into Ansible. So now that we kind of understand a high level overview of the network architecture, this skill is going to largely focused in on the management daemon and the JSD. We're gonna focus in a lot on these scripts. We're also gonna talk about what you could do with JSD, especially if your lab environment supports it. So without further ado, let's progress on to the next video.

0:00We're going to begin this journey by talking about scripts. Now, like I said, we are here. We're supposed to be talking about the management daemon process, Terraform, and really JSD, which is the JET tools here. But the GM objectives are just to understand them, identify concepts, general features and functionality. It's not configure and implement. But if we scroll down to the scripts section right here, now we move in to describe the concepts, benefits, or operation of automation scripts, and that or operation could be how to actually use them or configure them.

0:41Considering these come under the umbrella of MGD, it makes sense to talk about them now as a combined topic so that we can fully understand how the MGD is working. So let me walk you through a very basic first one. We're going to talk about commit scripts. Remember, commit scripts run right before. If I type the commit command and press enter, commit script will run right before it actually commits the new configuration, validating that we haven't broken something.

1:14So here we have a commit script example. Actually, this is the commit script example right here. It's pretty basic. We actually use built-in functionality that's built in to the Junos operating system using either Junos or LXML. Of course, we know LXML helps us parse XML data. We load the Junos context into a variable called JCS, and then we look for each of the interface descriptions for IFD in the path for each one of these interfaces.

1:47We understand the configuration tree goes from interfaces into an individual interface from there. We're looking for the interface name and the interface description, and our policy says if the description is empty, if there is no description, raise a commit error. This will stop the commit from happening, and it will say the interface with this name is missing a description. So we're enforcing that all of our interfaces have a description, and we validate this whenever somebody comes along and types the commit command.

2:23That's what's happening here. So what do we do next? We need to take this Python script that's on my computer, and we need to get it onto the remote Juniper device. So what I can do is I can use a tool like SecureFX to SCP these stuff in. This really works like an SFTP server, but it's all over port 22. It's all over port SSH. So I'll go into VEX1, and we'll start to navigate where to put it. For a Junos device, we'll first look in VAR, then DB, then we'll go down to the scripts folder, and ah, there they are right there.

3:03There's all the different kinds of scripts we can have. Commit, Event, and Op, as well as SNMP are the big ones that they want you to know about on the Junos boxes. So if I look in commit scripts right here, there's actually some commit scripts that are already here. But I can move my commitment script over by just dragging it on, and now that commit script lives on this Junos device. So now the question becomes, how do I make the box use it? Well, I need to set it as a configuration and tell my Junos device that there is this commit script that it can start using.

3:37So down here, I'll go and log in. We'll increase the font size a little bit. I'll go into edit mode to set the configuration. I'll move into edit system, and then scripts right here. If I type show, we see I've got no configuration. So this is where I want to set my configuration. I'll do set and give it a question mark. The first thing I want to tell it is what language are my scripts using. So I'll say language, and then Python 3.

4:08We'll press enter here. Now when I say show, we can see I've got the first thing set. Now I want to create a commit script that it knows about. We'll say set commit, give it a question mark, and we go, okay, well, where does this commit script live? We specify it by its file and its full path. The full path was far db scripts commit, and then the name of my script, which was commitment.py. It may be in a situation ship.

4:38Got some commitment issues. We got to take it up there. So I'll press enter here. Oh, we got a error statement. Cannot open a single quote forward slash. Perhaps that's because it already knows where to go to look for commit scripts. It has a folder for that. So we'll just call it by name, commitment.py. Ah, it likes that. Give it a show command, and now we say our commit scripts are a language of Python 3, and this is the script that you want to run.

5:09Let's give it a commit and quit. Oh, well, look at that. Now, it didn't print the exact message I expected, but like I said, these virtualized environments are a little, you know, not quite production ready, if I say when it comes to a lot of features like this. But let's see, if I actually exit out of this, let's do exit, and then exit, and we'll say, no, I don't want to, we'll leave these changes uncommitted. Wait, exit with uncommitted changes. Yes, I want to do that.

5:39Do show log messages. Let's see if it actually found and ran the Python script. I got to zoom out a little bit for this and scroll all the way to the bottom of this log. You can see right there, the very bottom of those percentages are roaming, and it should be one of the very last things we see. Okay, so here's where we go. We had a database login event, followed by a commit, followed by the script. Now see right here, the unsigned Python script without checksum is executed right there.

6:10That tells me it found the script and ran it. It was executed. It raised an error, and that's what caused the commit to fail. Now, why didn't it print the full message out to the terminal? Again, I'm probably chalking that up to this is a virtualized new box that's running. It doesn't have the full-fledged feature support that we expect. But it is working on these commit scripts now. So this is kind of the flow for creating a commit script and 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, take a look at it. We've got the sample code provided right here above the video that you're watching. So commit scripts done. Next video, we'll talk about 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 one of my interfaces, I just reverted the commit script we created in the last video so that I can move on to the op script next, which is another fun one. Let's take a look at an op script. This is basically doing show interface. Give me a specific interface that we want to care about. So in this case, again, we're loading the Junos context. And then we're saying, this is basically the print statement. Instead of using print, we do output. So it prints this out to the terminal. And then we specify what is it that we want to query. We're going to use the Junos context specifically with an XPath to parse the configuration down to interfaces, then for a given interface, then find their name. Just a very basic idea that we want to print the interface names. For every interface that lives in the list of interfaces, we will again print using the output method, interface followed by the name of the interface right there, iface.txt. Very basic, but this would be your first step into understanding if 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 secure fx, we can see I, instead of doing my commit sections, will do op scripts right here. And sure enough, there's quite a few op scripts that come baked into this device by default. I'll go ahead and grab my op script, cleverly called op script. I'll drag it over here to the folder. 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 can see the .py file has been brought over. Similar configuration as to the commit script. We'll jump back onto the box right here. We'll go back into, let me zoom in a little bit, we'll go back into edit mode, edit system scripts. If I do show right here, you can see I kept language of Python 3 baked into it. We do have to specify that, that we're using Python and 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. So here I say op, then it wants to know what's the file name. Mine was called op script .py. Hit show. And there it is. There is my op script now in the environment. So I'll commit this configuration. Won't blow up this time because I don't have a commit script to 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, the way Juno's Python scripts have evolved, have gone from kind of a legacy implementation to a newer implementation. Luckily I come prepared for both. Let's try this first. I'll try op script .py. And sure enough, it blows up. It doesn't really understand how 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 too, right here. This time we're using the device class. This is almost identical to what pyez does. And in this case, the device class, we can actually use the device RPC and then pass in RPCs, just like the XML API. In this case, we're going to say get interface information with terse equals true. We know we get the response back in an XML payload. We can leverage XPath to find the physical interface name and then print that interface name out to the terminal, run the script if that's what we want to do. So this is called newop.py. And just for good measure, I've currently loaded it onto the box. And I can show you show system configuration, excuse me, show configuration system, show configuration system scripts. And you can see I've gone ahead and placed that in the operational script section. So if I say now run my operational script 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 physical interface names, just like that. So that right there is how you can create operational scripts. Why is this useful? I mean, all I did was print out interface names. You could have done show interface to yourself. Because you can write useful Python scripts that can run multiple commands, concatenate data together, join data together, or split data apart and print out the key metrics or useful things that you care about. Instead of logging into a box and typing four or five show commands, what if you just ran one script, gleaned all the information out of it that you really care about, and then saw it here on the terminal? You could call this your daily operation script. So you could log into your boxes and run your daily operation script right there and see all of the key things that you care about right there on front. These are operational scripts.

0:00Next up, we have event scripts. And the only thing that this really deviates from that we've done so far is we have to go into the configuration and tell it which specific events should trigger which specific script. So here, there's nothing really special happening here. I'm just importing JCS, the Junos configuration system. I'm going to use the syslog method to log a info message right here that has the message event script triggered just to get it kicked off. Again, virtualized lab environment, lightweight images. There's a non-zero chance that this doesn't work, but here we go. I'm going to move this script, my event script right here, over into the events folder, 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. I got to jump back into my CLI and configure this event script. Here's how to do it. We move into configuration mode, and then we move into event options. This is where we set up events. We create policies that say when certain events trigger, this is what we want to do about it. It's not always just event scripts. We can really set up all sorts of policies surrounding events, but this is a network automation skill, and therefore we're talking about what Python scripts we can run on certain events. So we'll do set event options. We're already in event options. If we give us a question mark, you can see what we're trying to do is we're trying to create a policy. Eventually we'll need both, and that'll make more sense. In fact, let's do it this way. This will actually make more sense. We'll first tell the Judo operating system that there is an event script that exists on this box. We'll tell it by its file name, which was very cleverly event script.py, and it sets this configuration. If you see show, now it knows there is an event script 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 that we're giving this policy, but I want it to know what is the policy about. It's when the interface goes down. We'll say the events that we care about, and if you give it a question mark right here, it doesn't let you really do much probably. In fact, it's kind of hung up here because there's a trillion events on this box, and if it tries to give you a list of every single thing that happens on this box, it'll print for forever. So I'm going to hit control C. Notice with that scroll right there, all of those events, it made zero percent of progress. So really you need to just know what event you want to look for. Look it up in ahead of time. The event that I care about is interface hyphen down. That means the interface is, well, down. So in this case, we'll say, what do we do when the interface is down? We say policy for if down, then hit question mark. We want to execute our event script that we've already configured. I don't have to specify the 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, that's what's going to make this event script kick off. I'll give this a commit and quit, and there we go. So at this point now, when the physical interface goes operationally down, then the event script will kick off and it should trigger something printed to the terminal. So now should one of our interfaces go down, you know, the link gets unplugged or whatever the case is, that will fire the event script to trigger off and print syslog messages to the terminal.

0:00Our final script type to discuss is also the third event-driven script type that we're talking about. This is one that triggers upon an SNMP trap event from a specific OID that you configure, or multiple OIDs that you configure. Now, this can be a little bit of a nuanced script to look at. In this case, when the OID fires off an event, it'll actually perform an SNMP walk to get the information from the SNMP triggered event. There's also the ability to run an SNMP get command to get data from a specific OID event. Right here, we see in the main function, it's going to print out all of the details, including the target, the labels, and the OIDs out to the terminal telling you about this information. Now, naturally, what we would also 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 detail of the event that occurred. But also, there's the ability to pull and get data from these SNMP OID events as well. That being said, I think we all probably agree that NetConf, REST APIs, gRPC, and gNMI are the better solutions. In fact, that's the entire point that it was created, was to replace or overcome the limitations of SNMP some 20-odd years ago. Still, there are many software-defined networking controllers and network management tools that implement SNMP to some degree. And if that's going on in your environment, you can leverage Python SNMP events or SNMP scripts. So just like we've done, we're going to transfer this over. This time, it's going into the SNMP folder, which is currently empty. I'll transfer SNMP basic over, like so, and now it lives on the box. Now, what we need to do is we need to get to the box and configure it to use these SNMP scripts. So I'll go into edit mode, and then I'll go into edit SNMP. There's really only two 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, we're probably asking for the file name. In this case, it was SNMP basic.py. Now, one of the things with SNMP scripts, as well as event scripts, that we also have to give it privilege to, is we have to run Python scripts as a specific user. So when I hit up right here, I can also type in py to autocomplete Python script user. Here, I'm going to type in my own account. So it runs Python scripts under my account, which has privileges to access all portions of the Junos device. I can't stress this enough. You have to do this under the event scripts as well. I glazed over 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 missing a mandatory statement. What OID does this script attach to? Duh, that's a pretty obvious one. If I go right here, after specifying the file name, I can hit question mark, and now we have to attach this to OIDs. So if I say OID here, I'll just grab a sample one coming from this script, like 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 is a really good sign. The configuration now succeeds. So let's take a look at set system scripts real quick and do the show command. First thing, we specify the language of Python 3. We have our op scripts that we can run on demand or ad hoc, and then we have our SNMP scripts, which as we know, are event driven. We specify the file that runs, the OID that it's attached to, and the user that it runs as. Now, like I said, we do the same thing for events, and if you want to look at the event options, event script, you can see I've gone ahead and I put 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 go make sure we do commit and quit, because that was a commit check I did, not a full commit and quit. Now we're committing this configuration and exiting out. So when SNMP gets enabled on this box and configured, and it tracks the right OIDs and does the trap messages and everything, now it has a Python script that it's listening for those events as well, and will execute whenever those SNMP events happen.

0:00Now in this video, I'm really drawing your attention into how JET applications work. Remember, this is the Juniper Extension Toolkit. What's the whole point of this again? This is rapid fire, quick reacting to data, locally on the box. So again, if this is the box right here, and we need a high performance app to be installed into the free BSDR operating system of Juniper, this is running side-by-side with the CLI.

0:33So, okay, let's take one step back, right? Here's your Juniper box, and it doesn't just run Junos, does it? No, it runs free BSD, which looks and feels a lot like Linux and then Junos is an app that runs on top of it. We can also install our JET application to run side-by-side and interact with this Junos device. The primary reason we wanna do this is to enable something like live monitoring and event detection in a high performance nature.

1:09This is usually doing things like live streaming. From the external world, we would use something like gRPC for this, but on this box, we can have it connect into the box directly, and it changed my color to yellow for some reason. We can have it connect into Junos directly and get a live feed of events like interface counters, OSPF flapping, or something like that. And then very importantly, we can have our application react to the live stream event however we want to. It's our application.

1:39We can code it however we want. Do we want it to change the configuration? We can do that. Do we want it to notify us? We can do that. Do we want it to just silently drop it and continue? We can do that. But this is a huge, huge process, and that's why it's not on the exam. Look at it. Right here, we've got a on-device JET application workflow. Are we going to sign this application, meaning the operating system will see it as a signed application and know that it trusts it? This is good for security reasons.

2:11Does the application come from someone that we know or trust? And if not, this really only supports Python apps only. We can configure it as a script and then deploy the application script on Junos, and it will run. But most of the time, we want to actually build and compile an application with signing if we're going down the JET way. This supports C, C++, and Python. But as you can see, the development itself is quite involved. Right here, we have to, on our local environment, right here, here's me, the developer.

2:44I'm on my laptop. I have to download a VM, a Vagrant VM. Vagrant is kind of like a pre-built image application. It helps you stand up development environments very quickly. Developers do this frequently. If they know they're targeting this kind of server over here, and it has XYZ packages, software bundles already installed into it, I can use Vagrant to more or less take a snapshot of that remote server here, and I can use that snapshot to deploy little developer VMs that I can then do my local development inside of.

3:28So here, they've got a Vagrant VM that mimics your Junos environment that you would have to download and install on your local environment and spin it up. Within that, we'll download the software tool chain package. Basically, what are all the prereqs required to build and compile software for Junos? Then you go through the certificate process. Acquire a certificate, build the package, and using the acquired certificate, sign it using the acquired certificate, and then you can go deploy it on a Junos device.

4:02Now, this part right here, these download Vagrant VMs and download SB tool chain, those seem like they're the most involved steps, and you would be right. They do give you a lot of instructions on how to do that, and it walks you through the steps of installing everything you need in your environment. So you can actually see what's pretty interesting in their little JetVM environment. They're actually installing gRPC clients so that they can get a connection on the same box via gRPC and get that live stream of data coming in like that.

4:38So the big takeaway in this video that I wanted you to understand is understanding that JSD and JET are separate from the things that we've been doing up until now. Basically, everything that you've done in your Juniper journey has been some interaction with MGD, whether that's via external applications that are logging in and then performing things like show commands or whatever, or on box with all of the four different kinds of scripts that we've covered up until now.

5:09When it comes to JSD, this is when we start turning our switch or our router more into a computer, and we leverage the free BSD operating system that's running on it and build applications that run alongside Junos and allow two-way communications going on like that. With gRPC, we do have the ability not only to get a stream of data, but also set commands over that gRPC stream.

5:40So our application can be reactive to things like we've noticed a DDoS attack on gig E 000. The app can see that and shut it down if that's what we wanna do. And then perhaps if we still have some form of outbound connectivity, like through the management interface, we can probably send some sort of notification, raise a JIRA ticket, critical event-driven environment, where we can notify our primary network engineers that this event has taken place.

6:12So that's the benefit of building applications for JIT. We have high performance on-box local resolution, local problem-solving resolution detection and prevention on the box itself when we build our own applications.

0:00Now, I think it's kind of interesting that the JNCIS puts a heavy emphasis on Ansible, which is kind of the dominant network automation tool, and not much of an emphasis on Terraform. Terraform is definitely more of a software developer's choice because it's all about building a whole environment, you know, by declaring exactly what it is that you want. You see this a lot in cloud environments where they use Terraform to build something like a fleet of servers with these exact operating systems and these exact configurations, and all of these packages or apps installed into it. And then, by association, servers need networks. 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 VNets in Azure. But now, Terraform has started to work with, you know, our own network devices that we know and love, especially as people have started to kind of shift away from the cloud and have more of a hybrid environment because some things don't make sense in the cloud, like core infrastructure. That's your active directory or your file share, those things that you absolutely have to have. And, you know, it can be cost prohibitive to have everything in the cloud anyways. So if our development environment is in a co-located data center, and we've got racks of equipment right here and here and here, and our developers are down here on their laptops trying to break our infrastructure, they're going to ship the need for new virtual machines and perhaps even new subnets to go along with those virtual machines and the switches that they connect to, the top rack switches or the access switches, whatever, they need to know about these new VLANs. Enter Terraform to help them out. Now, again, and I can'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 they can specify exactly what they want out of their entire environment in this one file called an HCL file. That's not, you know, hydrochloric, whatever. That is HashiCorp language. HashiCorp are 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, but it's not. It's its own thing. Now, here's where it really, you know, becomes magical. This is where it's interesting. You as a network engineer don't specify line for line what configuration it should be setting. Instead, you just kind of declare what the end state of the network should be. Like, I need EVPN VXLAN up and running, you know, via Apstra or something like that. And the cool thing about it is Terraform has these things called providers. Providers serve as a translation layer. Take this HCL file and make it configurations on the switch itself. That's what this provider does. So, right here in the data center world, we have Juniper Apstra as our software-defined networking controller to manage our entire, you know, data center environment, and all the switches are joined to Apstra. So, here we can leverage the Apstra provider to declare what our Apstra environment should look like and what configurations Apstra should push out to all of our 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 runtime or pull from an environment variable. When we scroll down here, the resource is the configuration. That's the thing that we're pushing out to the terminal. We're saying connect to that Apstra environment and then push out this lab blueprint information. The output right here is what is going to be printed out to the terminal, basically confirming what's taken place. Now, again, this is not something that they actually want you to implement for the exam. It's just something that they want you to know that HCL and Terraform are all about declaring what the end network state should be. We call this, well, declarative. And the provider itself is what handles the translation of what 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 architecture in the Juniper environment. Our next major things that we're going to tackle and talk about are going to be all about building and implementing with Ansible. So you better roll up your sleeves and expect to have a fun one there. I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Let's review our first lesson and our first skill in the JNCIS, which is where we start to understand the real big picture of Juniper architecture. An engineer wants to block invalid configurations before they are committed on a Junos device. Which component is responsible for this? I know you immediately went, oh, commit, commit scripts. But I'm asking which process handles commit scripts. Is it MGD, Terraform, GNMI, or JSD?

0:31It's MGD. MGD is the one that manages our Python scripts, event, op, commit, and SNMP. Remember, Terraform is an external configuration management tool, where we declare the instate of the network and it handles the rest. GNMI is network management over gRPC, primarily used for streaming telemetry. And JSD is primarily used for on-box streaming telemetry, which is where we build our own application and run it there.

1:03A developer builds a custom on-box application, speak of the devil, that continuously processes telemetry data and performs real-time analysis. Which architecture is being used? Well, I literally just gave that away. It's not Terraform, it's not MGD, it's not NetConf. That's external as well. This is JSD-based automation. The giveaway here is on-box application, but also telemetry. Both of those things mean JSD. An external monitoring system subscribes to streaming telemetry from a Junos device using gRPC.

1:38Which component is handling the request? And this is another kind of tricky one. JSD, MGD, GNMI over gRPC, or commit scripts? Well, this is an external system, and even though there's telemetry, it's external. JSD is for on-box only, so that one's out. And it's not commit scripts, this has nothing to do commit scripts. Now you might be thinking MGD, but really what we're talking about here is streaming telemetry over gRPC.

2:09That uses the G network management interface over gRPC to implement that. That's the monitoring system and that's the component that we're using. An engineer uses an external tool to define and deploy desired state configurations across multiple devices in a declarative method. Which automation method is being used? It's not the REST API. This is, we're talking about desired state configurations. The REST API would be a targeted configuration pointing to a specific config.

2:43It's not MGD, it's not JSD. Of course, we're talking about Terraform here. So that wraps up what we've learned about Junos architecture and automation.