Jumpstart Juniper—Automation

0:00 even as wired and wireless devices sort the network Edge today's business critical Services require more

0:06 predictable reliable and measurable networks users demand a seamless personalized experience based on user

0:12 type and location it's no longer enough to Simply keep the network up and running it's about ensuring a great

0:19 experience across the network for every user and network device addressing problems before clients are even aware

0:25 of them how is this accomplished with an AI driven Enterprise only from juniper

0:30 Mist Juniper Mist transforms the network experience and simplifies operations with artificial intelligence while

0:37 delivering on strategic initiatives with virtual Bluetooth location-based services and Analytics now you can

0:44 report when users or devices are unhappy or analyze traffic patterns through a retail store alerting shoppers with

0:50 location-based special offers in real time all network data is ingested into the missed AI engine for continuous

0:57 learning and Improvement and Marvis the virtual Network assistant is the Alexa for it teams Marvis helps keep the

1:04 network running seamlessly and simplifies troubleshooting with recommended or self-driving actions across the WLAN Lan Wan and security

1:12 domains this is true AI driven Enterprise for Wired and wireless networks Juniper mist

1:19 is leading a new era of I.T that uses AI to save time and money deliver unprecedented scale and provide

1:26 unparalleled user experiences let us know when you have 15 minutes to learn more

1:33 welcome to the jumpstart Juniper video junos automation where we are going to

1:39 go over automation on a Juno's platform let's first start with an overview of

1:46 junos automation why automate there are many reasons to

1:52 automate uh one of them is to eliminate errors as we automate we can find the

1:59 right way to configure up the devices so that they function properly and do them

2:06 over and over again if you have more than one or two devices think about how much time it takes to to

2:14 configure test and verify that a configuration is valid on a device and

2:22 then multiply that by the number of devices you have so this could save you

2:27 lots of time and we know that time is money and so automation could save you

2:32 time and money it enforces consistency across your network you can have all the same

2:40 configurations on all the same devices that you might want across your your network it can also improve security

2:47 because we can gather more data points across the network and correlate them

2:53 quicker and then be able to make changes to our Network way faster than any one person ever

3:00 could this would really help save a lot of time on the administrator's part

3:05 so just an overview here of the junos automation stack we see that we have a

3:12 lot of information here on the screen and it might be a little bit overwhelming but as we go up this this diagram the

3:21 the work gets easier for you so if you're just starting out and you're trying to learn how to automate things

3:28 you want to look at the top of the stack here I like ansible and then learn how

3:34 to use some of their playbooks to create different things for the automation that you want if you're a little bit of a

3:42 developer and already you're comfortable with with programming you can maybe look

3:47 at python Juniper has created a python Library called pie easy to help you

3:54 connect to uh General Juno's devices without a lot of extra code needing to

4:01 be written if you're a seasoned programmer Juniper offers you a whole set of apis that hook

4:10 right to the main processes the Juniper Engineers have the same exact access to

4:16 so that you can write applications just like the junos engineers can

4:21 junos has two main processes that control it junos itself controls the

4:28 routing engine and the packet forwarding engine so the two processes are the Jet

4:35 Services Damon and the Jet Services Damon uh is there for more advanced

4:43 programmers to make actual on or off box applications

4:48 there's also a management Daemon the MGD process and this is what's more commonly

4:55 used to automate junos and this process has the entire CLI built into it so that

5:02 you can automate the Juno's Appliance to do what you would like it to do

5:10 so the MGD manages uh a few pieces here manages the CLI it manages net comp and

5:18 it manages the rest API connections so as you configure any one of these

5:23 they're all going down to the the management Daemon to go ahead and make

5:29 the actual process changes on the junos device the Jet Services process

5:36 allows a common look and feel for all the apis whether you're going to create

5:42 an on box uh development of an application maybe

5:48 you want to set up a new application that creates a new operational mode

5:54 command that brings back information about applications that you want or

5:59 maybe you want to write an offbox application to control this device and

6:05 maybe more devices at the same time you can run you can do this with with the

6:10 Jet Services process the jsd process and the MGD process they

6:17 do all the work but the legs layer up are the apis and

6:23 the apis are those things that tell the processes what to do

6:29 and so we have a bunch of different apis here we have the jet API and the XML API

6:36 that give instructions down to the processes to make changes or to collect

6:44 information now we are going to be using the XML API

6:49 almost exclusively in this video to make changes through the management process

6:55 into the junos operating system the generals XML API Library contains over

7:01 37 000 rpcs within it these rpcs are used to control both

7:09 configuration mode and operational mode commands to be able to see these

7:14 commands you could type in after your CLI command pipe display XML RPC and you

7:23 will find all the RPC commands this way this is a great way for you to test and

7:28 to find uh how are these are these different eight these different API

7:34 calls work and uh you can also then make either on

7:40 box automations or you can make offbox automation using a web browser and be

7:47 able to collect operational mode data or be able to change the configuration from

7:53 your own web application the jet API has two pieces has the Jet

7:59 Services API and the Jet notification API the Jet Services API is what is what we

8:06 use to have access to the control plane on a device and the management interface

8:12 so this is how we would manipulate uh all commands on the device whether they

8:18 be operational or configuration mode commands the jet notification API lets

8:25 us Set uh events up and if that event happens we will get a notification that

8:32 that event was triggered on the device and so we have these two jet API

8:38 services when you have a remote application that needs to communicate with junos you need

8:44 to have a connector to do this and junos

8:49 has a few connectors for XML we have the netcomf connector and the rest API

8:57 for jet API we have the grpc and the mqtt connectors to be able to send

9:05 requests and to receive data back from the device

9:11 netconf is an iets standard so multiple vendors use this for their

9:17 equipment netconf carries automation data for a variety of

9:23 programming language and scripting languages netconf can tell the difference between

9:29 operational mode commands configuration mode commands and just messages that are

9:34 going through there net comp was created specifically for networking equipment to

9:40 automate it netcomp is a great tool for remote

9:45 procedure calls for your equipment the rest API is an API that uses

9:54 typically HTTP or https to communicate with a server there's no state that is

10:02 stored on the server so each query is independent and must be able to be

10:08 authenticated and logged in to be able to work if you're using uh python to use a rest

10:16 API we can use Simple tools like curl inside of there for prototyping and debugging but python also has a library

10:25 now that's included so that it works with the rest apis natively the jweb is

10:33 a web interface for Juno's devices and it uses this rest API to send and

10:40 receive all requests and information back from the Juno process daemons

10:50 TT are used for the jet applications the jsd uses the RPC to talk to jsd and

10:59 to make configuration changes and to collect data now the mqtt is a notification broker

11:07 that sends Telemetry data back to the jet application that is listening for it

11:16 which API is right for you well that depends on what type of application you're going to be making

11:22 depends on your programming abilities it depends on what you are trying to

11:27 accomplish if you're trying to get something up and running quickly then you might want to

11:33 run something that's already built in if you're starting from scratch then you might want to maybe use the jet uh apis

11:41 with the grpc and mqtt if you're building a web application it might just

11:48 be easier just to make everything in rest and go with that so that brings us to the top of our stack

11:55 here at the top of our stack we have our programming languages that we can use

12:02 here we have our jet applications we have our python we have our Ruby and we

12:07 have our rest applications that are there and then on top of that we have tools that are pre-built for us namely

12:14 ansible salt and puppet and Chef these tools are already pre-built and you

12:21 don't need any programming skills to run those you just need to know how to write

12:27 some scripts within their languages to be able to automate many of the tasks

12:32 that you want to do there are many ways to interact with the

12:37 junos here we see just a list of tools that we have that we can use to interact

12:44 with junos each one has its has its pros and its cons and it all depends upon the type of

12:52 application and the type of automation that you are trying to accomplish for

12:57 your setup and for your network the next agenda item is on box

13:03 automation unbox automation on a Juno's device

13:09 has four different types of scripts that you can write the first one is a commit script the

13:16 commit script runs anytime that you run a commit and in this way we can ensure

13:22 business rules are established inside the configuration an opscript is initiated by an operator

13:30 on the device in operation mode and can help with troubleshooting can help

13:36 understand what's going on and even help with configuration an event script happens when something

13:44 happens on the device and you want to run uh some process after that this can

13:52 also help repair a network outage if we are able to program that in

13:59 in an SNMP script allows us to process object identifiers that are not

14:05 supported by Juno's natively

14:11 so Juno's commit scripts these are committed again whenever a com you

14:17 commit your configuration and we use these to enforce business rules so

14:22 commit script violations can generate and display custom warning messages we

14:28 can generate syslog messages we can change configuration to conform to the

14:33 the way that our business rules are and we can even halt the commit operation

14:40 here we're going to go over the standard commit model here we have our candida configuration and when we go to commit

14:47 that we're going to copy that into a checkout configuration and when we have that

14:55 checkout configuration we're going to have the management Daemon run any of

15:00 the validations against it and this would include our scripts that we might write and then if there there's no errors

15:08 we're going to go ahead and set send our checkout configuration and that will

15:13 then become the committed configuration on the junos device here we're going to create a commit

15:21 script for an example and in this commit script we want to have make sure that we

15:27 always have management access to the device and that somebody cannot delete parts of that so that we lose access to

15:34 it and so the first thing we want to do is make sure SSH is enabled we then want to make sure that we have a user named

15:42 jnpr since that's going to be our management user and then each device has

15:47 an IP address configured on the fxp management interface so that we can communicate with it so how do we create

15:54 this commit script here we have our script that we are

16:00 going to create and let's go through it really quick first we need to import some python

16:06 modules to be able to work with the Juno's operating system so this first one we have here contains that post uh

16:13 candidate configuration and so that's what we need so we can we can look at it and see if the right information is in

16:20 there the next piece import JCS contains all of the error messages that come back

16:27 from the commit script so that we know if we have an error and be able to work

16:32 with that and then we have down at the bottom we

16:38 have this if underscore underscore name this just ensures that the script can be

16:43 run as an independent independent module and not have to be part of another uh

16:50 program or another script so the first thing we're going to do is

16:55 we're going to take our Juno's configuration and we're going to move that into a variable called root

17:01 and then what we're going to do is we're going to go and look through root and we're going to search for the X path in

17:08 there to see if under there we have system Services SSH enabled

17:13 and we're going to use this if not command so if we if not

17:18 enabled then we're going to go ahead and say look SSH must be enabled and we'll

17:24 put that error message out and see that jcs.emit underscore error

17:30 is part of that import JCS from above then we're going to go once we have we

17:37 we know that we have our SSH we're going to go down to the next one and we're going to look for the username jnpr and

17:46 so we're going to use that same if not statement and if it is not there then we

17:51 are going to write an error message to the screen saying the jnpr user account must be created

17:58 and then on the fourth one here we're going to look for the IP address on fxp0

18:06 and just make sure the IP address is there now this script is very simple it

18:11 doesn't make sure that uh the the IP address is in the right subnet it

18:18 doesn't make sure that the password for jnpr is correct it just is checking to

18:25 make sure those items are actually in the configuration so we could go and we could write a more complex script to do

18:33 more testing and and create things to make sure that the uh configuration is

18:40 even more correct than what we have here so when we go ahead and create this

18:47 commit script it just because we have a script doesn't mean that it is a commit

18:53 script the commit scripts have to be in a specific directory on the junos device

19:01 and so we need to copy that into the VAR DB scripts uh commit folder

19:08 so that we can run those we also need to set the Python language since we wrote

19:15 Our script in Python there's a couple other languages there's XLT and there's slacks that you could

19:22 write these in but the preferred language now is python uh moving forward

19:27 just because of the many libraries and how common it is in the in in the

19:34 workplace now and so then once we have the uh language

19:39 set we have the uh commit script com copied over into the right location we

19:46 have to set that up and enable the script so set file commit script dot p y

19:52 or for python so that the junos knows that it's there and that we want to use

19:57 that and then once we have done that we can actually do our commit and so we do our

20:04 commit and we see oh we have an error the jnpr user account must be created so

20:09 we don't have that in our configuration and it found that and gave us an error and then it stopped the the commit

20:16 altogether and failed our commit so this is how you can use a commit script to

20:23 make sure that either you're conforming to your business rules or you're conforming to a uh a minimum set of

20:32 standards and be able to help make working with junos a smoother process obscripts can be executed by a user

20:41 who's on the CLI they can be executed when somebody logs in or they can be

20:46 executed as part of another script there's a lot of things that operational scripts can do and these app scripts one

20:54 of them is that we can run a command or a set of commands and bring that back

21:00 maybe to troubleshoot we say look we need to run these four commands we can

21:05 make one uh script to run that runs those four commands and brings back the information but maybe that information

21:12 is too much information right it's got pages and pages and we only need little bits out of that output we can actually

21:20 do that too we can go out and run these commands grab just a little piece of

21:25 information back from each one of those commands and then put them together in a

21:30 report that we can have as as a single report that comes back another thing we

21:36 can do is we can do some configuration with opscripts and we can make sure that

21:41 we when we run the script it would ask questions on the screen and as the user

21:47 inputs information it would go ahead and configure those pieces this helps us

21:52 maintain our configurations the way we want and makes it so the user doesn't need to know junos as well as they might

22:00 need to and we can also monitor devices status and the general operating scripts that

22:08 now work with warning parameters we can get all that information back when we create the Ops script it's very similar

22:15 to the commit script but here we see we're going to import from the device so

22:22 before we were trying to import the configuration and so we're not going to import that anymore we're going to

22:28 import this device from the jnpr.ginos which is the pi from the pi

22:35 easy Library and when we do when we pull in this device we basically pull in a connection

22:42 to the device that we're on we don't need a password or a username we're

22:48 going to assume the authentication of the user who's logged into the device

22:54 who's running the script can we import this device this connection to the

22:59 device and then we want to make sure this runs as an independent module again so we have this if name again

23:06 and then we're going to connect to this device with with called Dev and so again

23:13 we don't need a host name or a password there and then what we'll do is we're going to print out the facts from this

23:20 device so this Dev object gets all the information back and then we want to

23:27 just print out the facts from that object or from the information that comes back

23:36 the app script is very similar to the commit script in that we have to do some

23:41 things to make sure that it's available to be able to run the first thing we need to do is we need

23:47 to be able to make sure we put it into the right directory again but in this case we're going to put it into the op

23:54 directory under script so VAR DB scripts up once we got it in there we're going to

24:01 then tell the system that is there so set system scripts opt file get fax dot

24:08 Pi just like we did before and then we're going to do show system

24:13 scripts we can see that that we have one there that it's ready to go and now we

24:18 can commit and quit that once we have that done we are ready to run this script

24:25 so let's see how we run this so here we go and run the script we just type op for our operational script and the name

24:32 of that file get underscore facts.pi that's the one we moved into that directory and then we see the output

24:39 that comes back we get all the facts about the device right we see

24:44 um who we see who's logged in we see the the routing engines we see the version

24:51 of code we're running so it just pulls back a whole bunch of facts about that device that we are logged into this is

24:59 how we can get in and run those operational scripts the Juno's event

25:04 model allows us to raise events from the

25:09 different uh demons that are running on the device and then we can take those events and we

25:16 can run them through a policy to look for certain events and then have actions

25:22 that we may run with those the event processor is called event D on

25:28 the junos devices and it when when events come in it will hand them over to

25:34 policies to see if there is something that matches so you definitely don't want to get all

25:40 your events mixed up an event is as something that happens on the system

25:45 then it gets identified by an event tag and the attributes that it has and then

25:51 it can be used by an event policy an event policy is a way to control how the

25:58 router Router reacts when an event happens event responses can execute operational

26:05 mode commands to make configuration changes can execute operational scripts

26:10 can even do other event scripts it can upload files it can raise SNMP traps or

26:18 it can just ignore the event altogether event responses can be defined in the

26:23 Juno's configuration or within the event scripts themselves event scripts allow

26:29 you to Define more complex Logic for handling events than what junos has in

26:34 it natively we need to determine the events and the attributes of those events to be able to write these

26:40 policies if we look at our default syslaw's message we can see here we have

26:46 an SNMP trap where the interface went down and we can see a little bit

26:52 information about that the interface name the status if admin status is up the

27:00 operational status is down but these are not the attributes that we need to write

27:05 our policies with so what we need to do is we need to make sure enter our configuration mode under our system

27:12 syslog that we have this structured data command placed so that our logs are in a

27:20 more structured format to give us the attributes we need for our event Scripts and so you'll see here we

27:28 have the same SNMP trap link is down but now you'll see we have this admin status

27:34 is is down and this admin status is what we need to work with for our event

27:42 Scripts now to find out how to look into these

27:47 and find out the things we need there is a website that Juniper has at

27:53 apps.juniper.net syslog explore and this will help us find all those attributes

27:59 that we need so we can write the event Scripts so here's our event policy

28:06 when we have an event policy we have a bunch of match criteria and in those

28:12 match criteria we have to match on all the criteria before we will do the

28:17 action so in this instance we have different

28:23 events that's going to show up and we need to have both of those events in

28:28 this instance show up to do that we can even do event conditions where

28:33 within such an amount of time these events have to happen so maybe here

28:38 event one and two has to happen and then within so many seconds events three and four have to happen also

28:46 but not have events five and six happen so you can write some very complex

28:52 matching criteria on these events you then have the actions you can take

28:58 you can change configuration you can ignore it you can raise a trap uh you

29:04 can do an event script and get that event script then to run

29:10 so these are this is how you'll set up your event policy under the event options uh hierarchy inside the

29:18 configuration mode just like the other types of scripts you need to enable these scripts so that they can work so

29:25 the first thing we need to do is if we have an event script we need to copy it to the VAR DB scripts event directory

29:33 and then we need to make sure that python is enabled as the language if that's the language we built the script

29:39 in then we need to enable that script so you'll go in and do the set file and

29:45 give it the file name inside the configuration just like we've done before but this time it's under the

29:50 event Scripts and then there's something a little different here and that is that we have

29:57 to give this event script a username and that username needs to have the rights

30:03 to do all the options that are in the script that's going to run and so we'll

30:09 give it a username here and let it log in individually

30:15 the last type of script is the SNMP script and what this allows us to do is

30:20 basically make uh custom mibs for our SNMP so we can map unused oids to scripts and

30:30 that way we can then act upon those and do different things um with those oid numbers that come in

30:38 now this can be written in slacks X SLT or in Python we know that we have to put

30:45 our scripts in an appropriate location to get them to work we can put them onto a flash storage

30:53 that is not our main drive on the device to do that we would put a command in

31:00 saying set system scripts load scripts from Flash now the the scripts can either be in the

31:10 hard drive or they can be on the flash storage but they can't be in a mix they have to be on one or the other

31:16 and if they're on the flash storage they have to be in a directory structure called config scripts and then the

31:22 commit op event or SNMP scripts in this way we can have all of our configuration

31:28 scripts on a separate storage device if we would like

31:34 yeah now we will have an unbox scripting demo in this demo you'll see how an opscript

31:40 can be used to easily make a configurations changed without having to get into configuration mode

31:48 this means someone without extensive training could make changes with an opscript and need not understand the

31:54 whole junos hierarchy or how it actually works the opscript can be as complex or

32:01 easy as it might need be needed so if you're concerned that a user might

32:07 not remember everything that might be added those checks can be made inside of the opscript for that in this demo

32:14 though we'll keep it simple and we're just going to show you how an opt strip can be used to easily disable disable an

32:21 interface so here you see a pre-built opscript

32:26 that we've created for you and this was created in the genie application

32:32 environment when you're doing your own development of scripting you want a tool

32:37 that will be aware of the different structures that are required by the programming language

32:43 what the spacing requirements are especially if you're working with data structures such as Json or yaml

32:51 and Genie is an open source tool that you could use

32:56 now for our opscript we're going to be accessing the Box we're going to be

33:03 changing the config and we'd like to know if there's any errors so that we've gone to the Juniper High

33:11 easy High easy library and we've downloaded code that is going to be used

33:17 in this particular application and we pre-loaded it into memory

33:23 so it's ready for us to use this is what the from June jnpr. junos

33:31 library is and we can import certain code modules here we have the device code module

33:38 that's for connecting to devices and then we have the config module and

33:44 that's used for making changes on Juno's devices and then we have the exception module

33:50 that we're going to pull in and which will tell us if we have any problems or

33:56 errors when executing the code and we're going to pull in the JCS and system

34:01 modules also that helps us select information from the use user with

34:07 screen interaction and this allows us to present exit codes for things that might go wrong

34:16 a few things that we have installed here we have uh when we start our application we have a message letting the user know

34:25 the purpose of the script and we're going to ask the user to enter in the

34:31 interface that they want to have disabled and so this is an input stream that so

34:37 people see this message on the screen and will be able to enter an interface

34:42 and it'll store it in the variable interface now we'll also check to make sure they

34:49 put in a interface it's a valid interface now just that this is a simple

34:55 check to make sure they entered something in we could actually write that out to make it a better check to

35:02 make sure they only do it to appropriate interface one that's valid and part of

35:07 the device now we're then we're going to set that

35:13 interface to be disabled and we're going to do that through an XML

35:19 script and so we're going to drill down to our interface and we're going to replace the interface name with whatever

35:25 they entered up there and then we're going to set the interface to be disabled through our configuration here

35:33 now with that done we're going to define a device that we need to connect to

35:38 we'll open that connection to that device then we're going to make changes

35:43 in that process we want to make sure we don't have any errors so we're going to set up a try and accept block to or

35:53 basically we'll stay in this Loop and try and if any errors come out those errors can be reported

36:00 so at this point in time we're going to set up the set up an exclusive

36:05 connection to our candidate configuration we're then going to

36:10 implement the code change through the load and it's going to come from the

36:16 config.xml file that we created up there and then we're going to commit that and

36:23 if there's any problems this will show up as an exception and that would print out on the screen

36:29 otherwise we'll close out the connection and our work is done

36:34 so now that our work is done in the writing the script let's see what it takes to execute that

36:41 script first of all we need to copy that to the junos device

36:46 using SCP or FTP and it needs to be in the VAR DB scripts

36:52 directory so let's check to make sure it's there so I'm going to

36:57 type file list and it's in the VAR slash DB slash script

37:05 scripts slash Ops directory

37:10 and then we see we do see our have our disabled interface file there

37:16 so we have the file there and if we want to look at that we could do a file show

37:21 and look at that file and here you see we have the script that

37:28 we wrote earlier and so it's the right script and it's in the right place so now what we need to

37:34 do now is we need to go into edit into configuration mode we want to do a show

37:39 system Scripts and we don't have any kissing configured

37:44 there so we need to do two things first we need to set system Scripts language

37:52 to be python so it knows to execute the scripts with

37:57 the python interpreter then we need to do set system Scripts

38:03 um op file and then the file name would be the

38:11 disable interface

38:17 Dot py with that done we can go and commit

38:23 and so now when we return to our operational mode we should be able to run that before we run it let's go ahead

38:31 and look at show system commit so we can see all the commits that have been through the CLI

38:38 and so the next thing we're going to do is show interfaces ge003 ters and we see that that

38:45 interface is up and working and so the next thing we're going to do is we're going to go run our obscript

38:51 opt disable py comes back and gives me my introduction and says

38:59 which interface do I want so I'll put in ge-03

39:06 and it says loading and committing the configuration changes so now it's done

39:12 so now if we go back and look at that interface it's down

39:18 and we do and I should do our show system commit we can see we have one done via NETCOM

39:26 comp so I can see that it was wasn't made by the CLI so the Off Script is up

39:32 and working and that's our demo our next agenda is off box automation

39:38 netcomf is used for many offbox connections there's other ones we've

39:43 talked about but we want to cover netconf since the majority of remote

39:50 connections to the junos devices will be through netcomf

39:56 so netcomp secures a communication between a server and a junos device

40:03 and allows us to send information receive information and authenticate all

40:08 that information in between this allows us to orchestrate our

40:15 networks from a local server so that we can control all the devices on our

40:22 Network netconf has four protocol layers they

40:28 are content operations messages and transport transport can use SSH SSL TLS or rest

40:39 in junos it uses SSH primarily to communicate

40:46 the messages layer communicates between the netcomp server

40:51 and the client now the RPC will encapsulate all the remote procedure

40:58 calls to the netcomp server the RPC reply will encapsulate all the remote

41:04 procedure called replies from the netcomp server back to the client and

41:09 then a notification is a one-way message that is used to subscribe to a stream of

41:15 data that can get published on the server for the client to watch and to

41:20 listen for the operations layer is very Centric to

41:26 network devices if you can see there on the left we have git config edit config copy config delete config

41:35 um so you can see that this is made to work with a device with a configuration

41:41 we can lock unlock the configuration we can use git to get different information

41:48 from the device uh and then we have closed session kill

41:53 session and these are used to manage the session so each one of these might have more

42:00 information like for the uh config ones we might have different options like

42:06 whether we're going to merge or overwrite the config the content layer contains the rpcs and configuration data

42:14 they get sent to a netcomp server the NETCOM server must have a set of apis

42:21 there to accept these rpcs and to run those junos has two that has the XML API

42:29 and a Yang API the XML API is what we are going to be

42:36 using what's nice about a lot of this is passive transport layer messages

42:41 operations and content are all in clear meaning they're not encrypted so it's a

42:48 lot easier to follow and keep track of what is happening in these sessions as

42:53 we are trying to create them so you need to configure junos to accept

43:00 netcomf and this is under the system services so we do under system Services

43:06 we do this set net comp SSH so that we can have SSH sessions carry the netconf

43:13 to us and then you can start a NETCOM session by just typing in netcomf at the CLI

43:21 command we can go ahead and see the permissions used during that we we go ahead and see

43:28 that we're logged in as lab and that's a class J super user

43:34 we see the com compatibilities or options the netcomp server supports

43:40 and we have a session ID for this netconf and then we have a terminal

43:47 signal letting us know that we can go ahead and add some net comp rpcs to this

43:54 session at this point we will now have a netconf demo in this

44:01 demo we're going to see an interactive net comp session in action so so we can

44:09 see how to take our PCS that we can learn from the device and get the XML returned for an output

44:17 if you're connecting to a Juno's device using netcomf it's good to understand the information that's submitted and the

44:24 information that's returned so that you can properly process it so we're going to take a moment to look

44:31 at netconf and see what we can do with it with the junos device

44:37 so we're going to start off with an SRX device and we're going to look at a couple commands we're going to do a show

44:46 interfaces ters at g001 interface

44:53 and what we're going to do is we're going to do a display XML

44:59 and what this command does is it's going out to the server

45:04 getting the information and returning the data so this is the returned data what called

45:12 this data was the RPC and we get we can see the RPC commands

45:20 that was used to submit this information what we can do is we can copy that RPC

45:27 information which was submitted by the CLI to the XML API

45:33 and I can then start a net comp session so to start netconf I can do a question

45:39 mark and netconf is not there it is a hidden command so you can just type it

45:45 in so we get type that and get an international interactive connection to netconf and so then what I'm going to do

45:52 is I'm going to copy that RPC information in and so now look I get the information

45:59 back that I got back up here so when I submitted that command with

46:09 XML so you can see how netcomf interacts

46:14 with the system and you can go in and play around you can take any command and

46:21 look at the XML and look at the RPC and then you can cut and paste those rpcs

46:27 into netcomf and get the same results when you're completed with the netcomp interactive session you can use Ctrl D

46:35 to get out text agenda item is ansible

46:40 okay ansible is an open source management

46:45 tool that accelerates the the deployment of our infrastructure it was originally

46:53 created for cloud and compute modules it's been expanded now to include

46:58 networking devices also as well provides an independent operation meaning that it

47:07 only changes the things that need to be changed you write it and as the script

47:13 and say this is how I want the device to be this is the state I wanted to be in if the device is already in that state

47:20 nothing gets changed if the device is not in that state then you'll go through and change it if you've already ran it

47:27 once and then something changes and you run it again it will change it back to the state that it was in

47:32 ansible can be used with your git servers your Jenkins servers and your ansible servers to create a devops model

47:40 for your configurations so that no matter what happens you're prepared to

47:45 deploy the latest configuration to your devices normal ansible operation is when

47:52 we send the python modules over to the servers that we're trying to modify the

48:01 servers actually run those python modules right on them using their own python scripting language that's built

48:08 onto them and then they will just delete those once they are done with those so

48:14 when we go to run these uh they run on the device now Juno's used to not run

48:22 python on the device itself and so we couldn't do that and so when we work

48:27 with junos ansible what it does is it actually runs the python script on the

48:35 device itself and uses netconf to through the apis to work with the XML

48:42 API to make the changes on the Juno's devices and so these are the two different ways

48:49 that ansible will work uh one with systems where they get copied over and the other one with junos were the the

48:56 actual python modules run on a server and use netconf to communicate using

49:03 ansible you do not need to be a programmer and that is because of the

49:09 modules that are created for ansible there are two different types of modules

49:16 that ansible can use for junos there's the ansible module library and this is

49:22 officially supported by ansible and is created by ansible and the community it

49:29 ships with ansible it comes with a supported in ansible Tower which is an

49:34 online subscription base to ansible's law and it's free as long as you have less than 10 hosts

49:41 but it relies on the NCC client in the python library to connect to the devices

49:47 to communicate with them the other library is the ansible Galaxy

49:52 and this is the modules that we've been playing with with juniper Dodge Uno's role these roles are pieces of re

50:00 reusable code for ansible that perform a common task

50:06 this is supported by Juniper and by the community and it is it takes a separate

50:12 installation to put these on your ansible and this relies on Juno's pie

50:17 easy to operate here is a list of the modules in the ansible library and the

50:23 ansible Galaxy library for the Juniper Dot junos rule roles

50:29 but as you see the ones in the ansible library and the ones in the ansible

50:34 Galaxy Library are very similar and do a lot of the same things the ansible

50:41 library is maintained entirely by ansible you there's a link down the bottom that shows all the modules that

50:48 work with junos but the ansible Galaxy ones are updated

50:54 and maintained by a juniper and so as Juniper grows their pie easy Library

51:01 this Library will grow and be more up to date probably than the ansible library

51:08 but you'll need to decide which Library you want to use for yourself

51:15 so let's talk about building up an ansible environment the first thing we need is we're going to need a control

51:20 server to run ansible on now this can be either Linux it can be Mac OS X or it

51:28 can be BSD and so you can pick which one you want to run there you do need to have Python

51:35 3 8 or greater and then you can go and install the latest ansible version by

51:43 going to this guide and finding out which version you want to to download or

51:49 we can use pip and do pip install ansible and install that right into our

51:55 python uh structure and then what we need to do is we need

52:00 to install the pi easy libraries and the jxml libraries

52:07 and so here's two more commands the PIP install Juno's e-z-n-c does the pie easy

52:15 and pip install j XML e a s e we'll go

52:21 ahead and install uh the XML to work with junos

52:26 and then we need to install the ansible Galaxy roll so we can do ansible Galaxy

52:33 install Juniper Dot junos and then we need to make sure we have netconf configured on the junos device

52:40 underneath of the system services and make sure that netconf is running SSH

52:48 and then you have you can have your environment set up the next thing you'll need to do is create an inventory file

52:55 this inventory file lists all the hosts that you're going to manage with ansible

53:01 and as you see over in the list here uh the default file is in the ETC ansible

53:08 hosts file and we see we have a vmx1 and a vmx2 and we can have as many devices

53:15 as we want there these devices need to be able to resolve to an IP address so

53:21 if you're going to set it up this way you're going to need a a DNS entry for

53:28 vmx1 and for vmx2 so that they will resolve to a IP address but then as you

53:36 see down below here we have a group called vmx underscore devices and it's

53:42 in the brackets and then we put the devices that we want in that group now you can have as many as you want in the

53:47 group we only have the two devices there so that's why there's two there but you can have as many groups as you want and

53:54 and so depends on how you want to set that up you might have a hundred devices

53:59 and 10 different groups that you're trying to manage the different things with it just helps us be able to make a

54:07 single call and it'll call each device inside of that group

54:12 ansible templates they're yaml documents so you need to understand how yaml works

54:18 yaml it's case sensitive and it uses spaces uh for the structure so we don't

54:26 want to use tabs we want to use spaces and it's a two spaces and so we need to

54:31 make sure we always have the spaces right or yaml might misinterpret how the

54:36 file is actually there a yaml document always starts with three dashes at the top and you can always

54:44 make comments with the pound sign so strings do not need quotes unless

54:50 they include special characters within their their structure and we need to

54:56 look at how we map things and how sequences work within the documents

55:04 yaml mappings are sets of key value Pairs and they consist of a name

55:10 followed by a colon and then a space and then the value that you want to tie to

55:16 that so there must be a space after this colon to make it work here's some examples like name space colon space Bob

55:24 height space colon space six foot these are the key value pair so when I look up

55:31 name I'm going to find Bob and when I look up height I'm going to find six foot yaml sequences are more of a list or an

55:39 array of data and the sequence items start with a dash so there must be a

55:45 space after that Dash so here's our example Dash space Apple Dash base

55:50 orange Dash space banana and in that we

55:55 are making a list that we can call if we need to inside of an ansible Playbook

56:05 all right let's go ahead and make our first playbook for ansible and we're

56:11 going to actually name it first underscore playbook.yaml because it's a yaml file and you'll see we have our

56:18 three dashes there at the top that says that hey this is a yaml file and then we

56:24 have some other code in here so let's go through this code real quick this code is what we would consider a

56:31 play and it's a grouping of the tasks that a host is going to perform now this

56:40 Playbook just has a single play in it on a single host but you can make multiple

56:46 plays on multiple hosts in a single file so let's go ahead and look at this one

56:54 here so we have our play name which is first

57:00 play and we have our host file entry this is

57:05 the host that this play is going to run against is vmx-1 now remember we have to

57:12 have vmx-1 in that hosts file so that we can

57:18 resolve the name to an IP address and make that work

57:24 we also show here that we are going to be using the ansible Galaxy libraries

57:31 that are created and supported by Juniper so we have the Juniper dot junos

57:38 there uh underneath the rolls so they're just telling us which libraries are we

57:44 going to use then we have this vars prompt section

57:49 this vars prompt section is basically variables that are going to go out and

57:56 display on the screen so that you can have user input from the screen as this

58:03 play runs so here we have a name called username so the username is our variable

58:10 name the prompt is username that's what's going to display on the screen and then we have private as no meaning

58:19 that we're going to see what we type on the screen the next one is we have device password

58:25 and that's again the variable name we have prompt is device password so device

58:32 under space password is what we're going to see on the screen when it runs and then private is yes meaning we're not

58:39 going to see anything on the screen as we type in the password

58:45 we then come down once we have that we have our tasks and here we have two

58:51 tasks the first task is going to go over to uh the device the vmx1 device and

58:58 it's going to ask for the um facts for the device basically a

59:05 bunch of information about the device and add a username and password and send

59:10 those over to the device and so here we have our user and see inside there we

59:16 have the username and the double brackets and we have the device password and the double brackets because those

59:21 are variables that we got from the vars prompt section of the code

59:28 and then once we get that information we're going to put that into a register

59:33 called Juno's facts and then down here on the debug on the message we're going

59:39 to display that on the screen and so this is our very first ansible Playbook

59:46 that we have well now that we've let's go ahead and run this Playbook and so we do ansible

59:53 Dash Playbook first underscore playbook.yaml if he pops up and says hey what is the

59:59 name we say lab what is the device password it's lab one two three but that

1:00:06 should not have shown up in the way that we had that uh typed in if you'd have

1:00:12 said no it wasn't private then you'd see it just like that then the first play begins and the first

1:00:19 play says okay the only one the only device I'm going out against is vmx1 and

1:00:24 that first task there says oh yeah I can I can talk to vmx1 and have opened up a

1:00:31 connection and then the next task there is to print those Juno's facts so the first task went out got the information

1:00:37 this next one's going to print it and so you see a bunch of information there basically XML format showing all the

1:00:45 different information that it's getting back from the vmx one device so we've

1:00:53 completed two tasks that says they're down at the bottom but we didn't make any changes on any of the hosts that we

1:00:59 have and so our changed is zero let's take another a look at another playbook

1:01:05 in this Playbook we're going to use a group to define the hosts that we put

1:01:12 into the host file that we showed we're also going to use a new module called

1:01:18 Juniper Juno's command and this will allow us to type actual commands right

1:01:23 into the yaml Playbook here to be able to run a command and then we will grab

1:01:30 the output from that command and bring it back and put it into a register and then we were going to use the debug

1:01:37 module to display that register so that we can see the output

1:01:42 here we have our hosts and we have our vmx devices and again remember that had vmx1 and vmx2 in there

1:01:50 we also have our Juniper Juno's command line here saying that this is the module

1:01:57 that we're going to use and that module we're going to use is going to take a command so here's show

1:02:05 interfaces ge000 or 1 and have it be terse

1:02:12 and show that output we're going to take that output and stick that into the CMD

1:02:18 output file or or register and then what we're going to do is we're going to take

1:02:24 that into the debug module here and display that information that came back

1:02:30 from our junos device so let's see let's run this and see what

1:02:37 it looks like so here we have our ansible Playbook command again and we're going to say

1:02:44 um we're gonna say retrieve interface state yaml which is the name of our Playbook

1:02:50 and it asks us for our username and password again and then it's gonna show

1:02:57 us that it's going out to vmx1 and vmx2 and that they both replied

1:03:02 and then it's going to print the results it gets back from vmx1 and vmx2 and so

1:03:09 here you see the requested output that comes back uh to our our screen and is

1:03:16 displayed and so we can see we have ge000 ge001 and they are both up and

1:03:23 running so we get to see all that information we also did see down here in the in the

1:03:29 recap in the play recap that vmx1 had two tasks and vmx2 had two tasks and

1:03:36 completed both of those ansible has a module called the Juniper

1:03:44 Juno's config and this little module allows us to retrieve our configurations from a

1:03:50 device load configurations onto that device we can roll back configurations we can commit configurations we can put

1:03:58 exclusive locks on the configuration and private mode locks on the configuration

1:04:04 we can use XML we can do set commands text or Json format config information

1:04:12 uh and so we have extensive documentation available at read the

1:04:18 docs.io down here at the bottom there's a lot of things we can do on that load

1:04:23 configuration we can load either just a merge or we can load override you can do

1:04:29 both the types of loads on this all right so here we have another

1:04:34 Playbook that uses that retrieve configuration module that we just talked about on the last slide

1:04:40 here we're gonna go to vmx1 again just to the one device and what we want to do

1:04:46 is we want to use this Juniper Juno's config module to actually grab the

1:04:52 configuration and bring it back and put it into our register

1:04:57 but we don't want the entire configuration so what we want to do is use this filter parameter to only get

1:05:04 back the interface configuration hierarchy and so if you look over here

1:05:10 on the right hand side we have the we're using the Juniper Juno's config module

1:05:18 and we say retrieve committed so this is our active configuration from our our

1:05:25 devices and we're going to filter on the interface hierarchy and so again this is

1:05:32 the configuration the active configuration and we're going to get the interfaces hierarchy to come into there

1:05:40 and then what we're going to do is we're going to take and put that into this register called response and then down

1:05:47 here in the debug we will call that response dot config underscore lines and

1:05:53 display those so this is our Playbook we have let's go

1:05:58 ahead and see what it looks like when it runs so we run the Playbook

1:06:04 ansibleplaybookconfig dot get yaml we log in with our lab in lab one two three

1:06:11 again and this time we're just going to go out to vmx1 and we see that we connect there

1:06:17 on the task and the next task is we print out the information from the

1:06:22 configuration from just the interfaces command and you'll see here that we have

1:06:29 the interfaces uh configurations come back and so that makes it

1:06:38 um and so we see that this is a great way

1:06:44 to go ahead and grab the configuration we see down here in the play recap again

1:06:50 that we've completed two tasks we went out and retrieved the committed

1:06:56 configuration and then we displayed the committed configuration

1:07:04 okay here's our ansible demo but before we get started I just want to

1:07:10 bring up a fact that you're not going to start working with ansible by just

1:07:17 opening up a text editor and starting to build documents for ansible

1:07:22 there's a lot of examples out on the internet that you can go start from and bring those in from you might as well

1:07:29 use those instead of starting from scratch so don't be afraid to go out and do a search and find a script that's

1:07:37 already doing what you want it to do so that you can bring that in and have a

1:07:43 starting point to start from you can then modify it expand that into whatever

1:07:48 you want it to do in this demo we're going to go in and

1:07:56 use a single Playbook so there's one play but there's four tasks within this

1:08:01 play that will be execute against two machines and in here we're going to demonstrate some of the ansible Galaxy

1:08:09 modules that are download as part as juniper.junos so you're going to see

1:08:15 working with juniper underscore junos underscore

1:08:20 facts that Juniper underscore RPC the Juniper underscore junos config

1:08:29 and here we can only read a config and we're going to change the config so

1:08:36 we're going to see some good examples in this demo here's our ansible Playbook It's

1:08:44 contained within a file called ansible Dash demo.yaml and we can see that it's

1:08:49 a yaml file because we have the three dashes right at the top that designates that

1:08:55 and then next we have a sequence number which is a dash on the and we right

1:09:01 before the name called ansible demo play is the name of our play

1:09:07 there's only one play but we have four tasks in here

1:09:12 but it's important to note that as a yaml file the hierarchy is defined by

1:09:18 spaces so you'll notice that you have two spaces indented

1:09:24 below the name and then you have two more for four spaces under the rolls or

1:09:32 the Juniper dot junos hierarchy so sub-hierarchies are more spaces and

1:09:39 if you had to go further these six spaces and that indentation needs to be there

1:09:45 so after the name we have hosts and the host entry is a vmx devices

1:09:52 and the question is what are those devices what do they Translate to

1:09:58 and so what happens is this represents an entry in a file and what is this file

1:10:05 well when I run the ansible Playbook if I use a dash I I can name whatever file

1:10:12 I want and this would be an entry in that file if I don't add an add an entry

1:10:18 with a dash i then by default it's going to go to the Etsy ansible host

1:10:25 file and when we look at that file we can see that we have we have a vmx1 in

1:10:32 these hosts and then we also have a group that we can have

1:10:39 then we can tell it's a group by the braces and the group name is vmx devices

1:10:47 so what we saw in the Playbook is that the vmx underscore devices and it

1:10:53 represents vmx1 and vmx2 and so when we use the one group name

1:11:01 we're going to play We're going to run the Playbook against both of those devices that we had there

1:11:07 and there can be more than two hosts in this group we could have many different groups and many different hosts within

1:11:13 the group a key point though these names they need

1:11:18 to be resolvable to an IP address so where does that come from so and this

1:11:24 one come from you know our our localhost file and we here we see that we have we have

1:11:32 vmx1 and vmx2 have resolved to an actual IP addresses within our

1:11:40 name host file so the next thing we need to do is look

1:11:45 at the roles and we see it represents juniper.junos

1:11:51 and that means we're going to use those modules that came from the ansible Galaxy

1:11:57 juniper.junos modules that were downloaded from them

1:12:03 the next one is a connection which is local and what the connection local means is that the Playbook will execute

1:12:11 locally so we'll make a connection to the device run the code

1:12:16 and but we're not going to copy the python module down to the device itself

1:12:22 we're going to run it on the local machine and then gather facts equals no

1:12:28 because when ansible starts up it wants to connect to the device to retrieve basic information about the device and

1:12:35 display as part of the output but we're going to be doing that anyways and so we

1:12:41 don't need to do that as part of ansible here now the next section we have is vars

1:12:46 underscore prompt and this gives us an opportunity to set

1:12:51 up our prompts and what we might want information to be entered into As We Run

1:12:58 The Playbook and then we can use that information in the Playbook so here's

1:13:04 one of the things that's being asked as username and so we'll be prompt for username

1:13:10 and then the value or the variable is username The Prompt that's going to show

1:13:16 up is username and we'll see that on the screen here the private of no means that we're not

1:13:23 going to you'll see when we type it in now the next one is for the password so

1:13:29 we have this device password which is the variable The Prompt will show device

1:13:34 password on the screen so that they'll know what to type in there and then the

1:13:40 keyword is private means that what they type in will not be displayed on the screen

1:13:47 this brings us to our tasks these are the different things we plan to do with

1:13:53 this playbook for this play we have four different tasks we're going to do our

1:13:58 first one is to get Juno's device information now to do that what gets us

1:14:06 this information is this is this Juniper Juno's facts from the ansible Galaxy

1:14:13 module that we downloaded and when ansible connects to a device

1:14:19 and connects to connects to device and executes that it will get the system information and bring it back and store

1:14:26 it back into a register called junos facts

1:14:33 now how did it connect to the device you will see here we have the username and the device password well those are those

1:14:40 variables that we used in the prompts and we asked them to type that in and it

1:14:47 stored it that stored it in the username and device password variables that we're

1:14:54 using down below and so we can call those down below

1:14:59 notice as a variable username is encased in two braces on each side plus quotes

1:15:07 same with the password so these are going to be passed to the

1:15:12 device when this task is run and then the information that's restored will be

1:15:17 returned to Juno's faults and then by using the ansible debug

1:15:22 capabilities we can drill into that variable to junost.fax and look for

1:15:29 facts to the version and then we can extract the version of

1:15:36 the code on the device now the question is how do we know that

1:15:41 that's there that's built into that that's where the documentation comes

1:15:46 into play we really need to be able to have that documentation and be able to read that

1:15:52 we're going to need to be able to look those up and to be able to find those and find out how to use them

1:15:58 so that's our first task our second task here's what we want to

1:16:04 do is show the versatility of ansible so we're going to do it a little bit differently so we're going to look for the version

1:16:11 number from the execution of an RPC call so to be able to execute this we're

1:16:17 going to use another module called Juniper junos RPC again this is still

1:16:24 from the ansible Galaxy download and so then the RPC we're going to feed it to

1:16:30 our PCS we're going to say git software information and just like before we're going to send

1:16:40 this command over to the device and we'll give them the username and password through those variables

1:16:47 remember both of these tasks will be run twice once against vmx1 and once against

1:16:53 vmx2 because of our use of the group and then the results will come back into

1:16:59 a register called RPC underscore response and then when I want the the results to

1:17:06 be printed I go into the debug capabilities and under that I put the RPC response I

1:17:14 can drill down the hierarchy and look for parsed output and I want the

1:17:21 software information Juno's version and then I'll receive that version

1:17:26 number and display it on the screen the next task we're going to do is going

1:17:33 to be to going to extract whatever I'm going to configure in the services configuration

1:17:39 and this is where we configure things such as SSH telnet or web access into a

1:17:46 device so I want to be able to see what we have there so we want to be able to bring that in

1:17:53 and look that and be able to print that out so we go into the Juniper underscore junos config module

1:18:01 again we're going to give the username and password and we're going to see the active

1:18:08 configuration and so that's the committed configuration there and then we're going to filter under

1:18:15 system Services hierarchy inside of junos and I just

1:18:21 want to retrieve that so we'll put this filter in there to get just that piece if I didn't put the filter in there I

1:18:28 would get the entire configuration from this committed when I retrieve that it'll take the whole configuration in

1:18:35 then I'm going to store that into the git comp response register and then I'm

1:18:42 going to go ahead and print out those config lines that I got back and our last task that we're going to do

1:18:49 we're going to configure we're going to modify the login Banner

1:18:55 so we're going to actually change the configuration

1:19:00 and so we're still going to do that under the Juniper underscore junos config

1:19:06 or still give it the username and password so we can connect but now we're gonna do is we're going to

1:19:15 load this execute a set command

1:19:20 and so our format is going to be as a set command we when we config we wanted

1:19:26 to have an exclusive lock and we want to commit our work so we set that to true and so our actual command will be set

1:19:34 system login message and this will be different than the normal one that we have

1:19:41 and then once we're done we want to save that to a register and that way we can take a

1:19:48 look and then we can see the difference we can see the difference between the old line and the new line with this

1:19:56 Command right here and so that completes the task portion of this and that's our ansible Playbook

1:20:04 so the last thing to do here is just to run the Playbook so let's go into our

1:20:10 command line and type in ansible Dash Playbook and then we're going to put in the

1:20:15 ansible Playbook here's the ansible dash demo.yaml and then if we had if we didn't have the

1:20:25 host file we would need to add a file in here for an inventory file so we could

1:20:31 put the dash i and type in an alternate inventory file but we don't need that

1:20:36 we're going to use our normal one and so we'll go ahead and hit enter and it asks for our username we go ahead

1:20:44 and put our username ask for our password and we type that in and now it's going to go and run those

1:20:50 tasks against the two different mxs there'll be output that comes out from

1:20:57 each of the tasks and displays on the screen parts from those debug commands

1:21:02 that we asked it to put out onto the screens so we need to wait just a few more seconds for that to wrap up and complete

1:21:09 those tasks and so now all the tasks are completed so let's go back and take a look at this

1:21:17 so the first thing we can see here is that it it we got the verse task one

1:21:23 against vmx1 and vmx2 and then it came back with the version information from both of those from the

1:21:31 junos facts facts dot version and so we see that that came from vmx1

1:21:37 and vmx2 and they both completed successfully the next one was the issue the RPC command

1:21:45 to do the same thing and so we see again it came back with the RPC response and

1:21:53 we have the same 18.1 on both of the vmx

1:21:58 so this was just two ways to get the same results and then we wanted to read the services configuration

1:22:04 so notice here that vmx 2 and vmx1

1:22:09 and it it swapped them so here we see one two one two

1:22:15 reason for that is that ansible sends out all the tasks to all the machines

1:22:20 inside the group at one time and whoever responds back first it will get entered

1:22:26 in there so it doesn't matter which one comes back first or which one comes back second if we had three they could all be

1:22:32 in different orders each time we run it doesn't matter here we look at our services and we see

1:22:39 that we see we have SSH and we allow root login allowed we also have net comp

1:22:46 you'll notice that vmx1 printed its services first but you'll see vmx2 came

1:22:51 in first it doesn't matter it's going to print the order in which they come in no matter who responds first

1:22:57 we can see what other configurations are and so to make the changes we'll see

1:23:03 that down here we'll see that the change went on vmx2 and vmx1

1:23:09 and we gave it a new Banner so we look at the difference

1:23:15 and so yes those that line was added with the little plus there

1:23:20 and so that we can see everything that happened on that so now when we look we can say okay look

1:23:27 at the play recap okay and then you look over and it tells how many tasks eight

1:23:33 tasks were completed and we have those eight because we had the four of them but in there we got information

1:23:38 retrieved it and then we displayed that information and so each one of them was actually two tasks and next we have how

1:23:46 many things changed through our configurations and so there we have our

1:23:52 ansible responses there to our Playbook everything occurred successfully and we

1:23:58 got all the information that we wanted our next agenda item is Python and Pi EZ

1:24:07 let's see what we can do what you what you can do if you know a little bit more

1:24:14 now you might be asking yourself do I really need to learn a programming language is that going to help me as a

1:24:21 network engineer automation is going to become a huge thing so we need to learn a little bit

1:24:28 more there's a many reasons why python is a great choice for a network engineer to

1:24:34 learn it's a fairly simple language but yet has a lot of power behind it in the

1:24:39 things that it can do not only that but a number of python libraries already exist they can help you with network

1:24:47 automation making python a powerful automation tool now you can also extend customized tools

1:24:55 like ansible and salt with custom python modules

1:25:00 knowing programming can help you understand how existing tools work by reading the source code and lastly you

1:25:08 can treat your infrastructure holistically as code instead of a per box basis

1:25:15 if you need to Learn Python because it has a lot of benefits what exactly is it

1:25:20 well python is a high level application Level programming language my high level

1:25:26 means most of the hard work interacting with the underlying system has been

1:25:31 taken out of the equation for you so when you write your code you can

1:25:37 write straightforward code and tell your system what you wanted to do and all the

1:25:43 underlining complexity is handled for you so you don't have the controls that you

1:25:49 might have in C or another programming language but that's replaced with the ability to that have the ability to

1:25:56 learn it faster and get it to work quicker so both python for other things that you

1:26:03 wanted to do people have developed modules and libraries that you can add to python

1:26:10 that can help you specialize in certain areas for example Juniper has created

1:26:16 the pi easy library that takes a lot of the complexity out of connecting and

1:26:22 interacting with juniper devices so you don't need to learn that fewer commands means you can be up and

1:26:29 running faster now there's many different features they can be supported and so you have

1:26:36 multiple programming paradigms which is part of the Python paradigms and python

1:26:42 runs on many different platforms so you have that so here's a simple script and this is

1:26:50 not a complete script there's no code here on how to connect to the devices but some we're going to go over some

1:26:57 basic structure and how it works and we'll walk this through as part as an example when the code is complete

1:27:03 Python scripts are saved with the dot py extension but let's look at some of this

1:27:10 code one of the first things we can see at the very top is what we call a shebang

1:27:17 it's a pound sign exclamation or a pound sign bang and it's called a

1:27:23 shebang this tells python when it's followed with the path to python that you don't

1:27:30 have to launch that dot py extension by lot typing Python and then the name of

1:27:37 the file you can just do a DOT slash and the name of the file and it knows where

1:27:42 to find python because of this shebang this is very common to see in Python

1:27:48 scripts next you see this pound sign followed by this is a comment well

1:27:55 anytime we put a pound sign to the front that makes the rest of the line just a comment this system of being able to put

1:28:02 a pound sign and then the rest line is a comment makes it really easy to add comments in our code and we should

1:28:08 comment our code both for us and to help others that might have to help look

1:28:13 through our code at a time that tells us hey what are we trying to do with this next next section of code now another

1:28:21 thing you can do is you can create variables in lower level applications in

1:28:27 programming languages you have to define the data types and the information

1:28:32 that's going to be stored in that variable in Python you just create the

1:28:37 variable and the system will determine what type of data you're going to store in there and in that case we're going to

1:28:44 store two interface values ge000 and xe100

1:28:51 then we're going to use that in a for Loop so we want to do something for a

1:28:58 number of times for interface in my interfaces and this

1:29:03 means that my variable interfaces has two variables so we're going to look at

1:29:09 the first interface value first and then the next one and this is going to control the program

1:29:16 code that's going to follow right beneath it and I know it's a flow

1:29:21 control process because I end it with a colon and that means I'm doing some flow

1:29:27 control programming here so very simple now when I do a flow

1:29:33 control the code that follows within the four next Loop needs to be indented by

1:29:39 indenting here by four spaces it shows that this code is subjected to

1:29:47 the for Loop so anything that's indented the four spaces will be part of that

1:29:54 control statement and once it's not indented like the print statement that is outside of the

1:30:01 for Loop now within the four next Loop we have an

1:30:07 if conditional statement if this statement is true then do this

1:30:13 if it's not then do this and if that's not true then do this

1:30:18 so it's a conditional if and because it's conditional it also has a colon at

1:30:25 the end so it begins the condition because it's a conditional statement

1:30:30 then the work I want done within that initial statement is indented as you see

1:30:36 here and so here we're going to print some information here depending on which if statement we take

1:30:44 for those print statements you'll see that the percent s in each print

1:30:50 statement how does that get populated it's a variable it's an unknown variable inside

1:30:56 the print statement how does it get populated well that interface on the

1:31:02 back because up at the top it's four interface in my interfaces so that

1:31:07 interface will be ge000 for the first run through so depending on which

1:31:13 comparison it hits that interface will be populated into that percent s

1:31:20 now you can have multiple variables in your print statement and multiple variables at the end now the first one

1:31:27 would go into the first the second goes in the second and so on so it's pretty straightforward when you're when you

1:31:33 look at the structure and now when we're at the end here we don't have any variables so this will

1:31:40 print the string at the end of the report that the that we're finished testing once you finish writing your

1:31:46 script and save it as a DOT py file you're ready to test it in order to test

1:31:51 a python script you have to make sure you have the executable permission on that py file itself you can check that

1:31:59 in Linux using the ls command if you have executable permissions if

1:32:05 you haven't CR included the shebang at the beginning of the script you'll have to use the keyword python

1:32:11 before you type in the file name of the dot py file if you have should use the shebang

1:32:19 and given the path of to the python directory in the file you can use the

1:32:24 shortcut by using the dot slash and the file name and it will run the python

1:32:30 script that way as well when you save your code as a DOT Pui

1:32:36 file it's not ready to run in the python virtual machine

1:32:41 python is an interpreted language and as such no compilation is required on your

1:32:48 part but the code has to be translated into a form that the python virtual

1:32:53 machine can read so that dot py file that you save was

1:32:59 run through the python interpreter and a pyc file is created so to be able to

1:33:07 send to the python virtual machine this byte code is then given to the

1:33:13 python virtual machine and it's executed in runtime module when

1:33:18 it's finished the process is stopped and the code is no longer running

1:33:25 the python on-box scripting has been evolving and changing over the the few

1:33:31 versions here we started with version 16.1 to have python on the Box on the MX

1:33:38 and qfx models as of 19.4 we view on the

1:33:44 box with python3 and we support the full range of Juno's devices we also support

1:33:51 the full range of scripts the commit event opt and SNMP Scripts

1:33:57 Juno's OS evolve got full Python 3 support and released

1:34:03 21.1 R1 even though python is a high level

1:34:09 application programming language that hides a lot of the complexities of

1:34:14 things of what things need to be done by lower level programs there are some things that can take quite a few

1:34:20 commands to do like connecting to as specific vendor's equipment and

1:34:26 exchanging information with them that's specific to those devices to make the

1:34:31 job easier when dealing with juniper products Juniper has developed Pi EZ it

1:34:38 is a tool that makes it easier to work with juniper devices and exchange

1:34:45 information with them they've hidden all that extra work from you your commands

1:34:50 can be simpler and more straightforward and give you better integration between the two products so Pi easy is a

1:34:57 separate tool that has to be installed and it works with any junos device

1:35:03 running junos 11.4 or later and it supports netconf telnet console

1:35:09 connections it can parse the XML RPC outputs it knows about loads and commits

1:35:16 and how to handle those it has file systems utilities so Pi EZ makes your

1:35:22 job connecting to Juniper devices using python a lot easier

1:35:28 here are some ways Pi EZ can help automate your network one of the job responsibilities of a network engineer

1:35:35 is to perform some sort of network audit a common way to com perform this audit

1:35:42 is to open an SSH terminal each device run commands to look at the hardware look at the firmware versions and then

1:35:49 take all that information and manually populate it into a spreadsheet Pi easy can easily connect to Juno's

1:35:57 devices collect the data and store the information in the ready-to-use format

1:36:02 once Pi is ZZ program has been written there's nothing more to do than to run

1:36:08 the program and let it run another way to use Pi easy automation is when

1:36:14 updates to the network are needed sometimes a change in one part of the network can have unexpected consequences

1:36:21 in another part of the network it can be difficult to predict what will happen by capturing the state of the

1:36:27 network devices before a change and then comparing it to the state of the same devices after the change you can quickly

1:36:34 bring the issue to light without automation to help highlight these differences troubleshooting this

1:36:41 type of issue can consume a lot of resources in time Pi EZ makes it easy to collect this

1:36:48 information and display it in the right way pie easy can even help in the repetitive

1:36:55 tasks such as bringing up new circuits when adding new circuits there might be

1:37:01 more information needed than an IP address other options may be needed and must be entered to conform to corporate

1:37:09 policies when these types of tasks are performed manually a piece of information might not be included or an

1:37:15 input error could occur that would result in a network issue Pi EZ can make it easy to automate

1:37:22 configuration deployments the automation can make sure all the required information is entered and the address

1:37:29 is right before changing the configuration this frees up Engineers to perform other tasks while reducing or

1:37:37 eliminating errors we need to prepare our junos devices so that they can work with pie easy

1:37:45 pie easy usually connects through net comp over SSH using port 830.

1:37:52 we need to make sure that that is turned on on our junos device which we'd use under system Services hierarchy the set

1:37:59 netcomp SSH command we can also use a standard SSH Port if

1:38:04 we want to we could also use a Serial port or a telnet they're also supported but

1:38:11 typically we're going to use SSH to do this the scripts that we're going to run with

1:38:18 pi EZ we need to have certain permissions to run those and so when we

1:38:25 log in we need to log in with a user that has those correct permissions to

1:38:31 run those now for a lab it's not too bad to send

1:38:37 passwords over the the wire but usually you do not want to send passwords over wire even if it's encrypted with SSH so

1:38:45 it's great if you want to make some SSH public private keys for your production

1:38:51 use to be able to access your junos device we use Pi e z in your Python program the

1:38:59 code module you'll want to use will need to be imported these modules are part of the pi easy

1:39:05 Library at the beginning of the Python program you will use the from statement and

1:39:11 reference the pi easy Library using jnpr.junos next you'll enter the keyword

1:39:19 from with the name of the module you'd like to import which module you import is

1:39:25 depends on which application you need the device module represents the junos

1:39:31 device and allows you to connect to and re and retrieve fax from the device the

1:39:36 exception module lets you take certain actions on errors that might come back from the Juno's

1:39:43 device the utils module handles software installation and copy operations and

1:39:51 configuration management the op module helps you take output from

1:39:57 an operational command and filter out the pieces that you want now Juniper Networks has extensive

1:40:04 documentation for all the modules and how to use them

1:40:11 no matter how big of a application you're trying to create with python there's some structure that we're going

1:40:18 to need to do if we're going to ever if we're going to connect to uh Juno's devices and in this case what we need to

1:40:26 do is the first thing is we're not going to need to import our PI easy Library so

1:40:33 we say use the keyword from and say from jnpr.junos import device and again that

1:40:41 device allows us to connect to Juno's devices we're also going to import P

1:40:47 print or pretty print and this will allow us to make output just look a

1:40:53 little bit better when we use this command the second thing we're going to do is we're going to create a variable and

1:41:00 we're going to use the device object and put all of our hosts in there with their

1:41:06 authentication information and so here you see we have vmx1 with

1:41:12 the username and password now we could add multiple hosts inside of there into

1:41:17 this Dev device but here we're only going to have one we're then going to use this Dev

1:41:23 variable and use the open command to open a connection over there using the

1:41:29 credentials over to the junos device once we have the device open

1:41:36 we're going to perform the tasks we want so here we are saying we're going to use the dev variable again for that device

1:41:44 and say hey look we want to bring back the facts for that device just the hardware information and different

1:41:50 things so we're going to say Dev dot facts and then we're going to say we want to put

1:41:55 that into a pretty print so we print that out and so that is our task there

1:42:00 on step four the fifth one is we need to close that connection down so that we aren't

1:42:06 interrupting either any other connections or doing anything else so we close that down it frees up the

1:42:12 resources on our device that are holding that Connection open

1:42:17 to make script writing easier Pi EZ has a context manager that takes on the the

1:42:24 responsibility of opening and closing the connection automatically to invoke the context manager write your device

1:42:31 class connection information as before but instead of storing the information

1:42:36 in a variable you're you're going to use the command with at the beginning of the

1:42:43 line and include the as variable name at the end here the variable name is Dev now

1:42:49 you can perform your tasks directly with the open and close statement will be

1:42:55 handled by the context manager the previous code to open and close are

1:43:00 still there but just for demonstration purposely they're being they're commented out the script produces the

1:43:07 same result as before when it is executed writing more sophisticated scripts that

1:43:13 can interact with junos requires a deeper understanding of the different Pi easy modules

1:43:20 the utils module is a directory within the pi Z package that contains a number

1:43:25 of useful modules first there is the config module which provides classes and methods for

1:43:32 deploying Juno's configuration templates the fs module provides methods to manage

1:43:38 the junos file system the SCP provides methods to copy

1:43:44 software images or other files to remote devices start shell module provides methods that

1:43:52 operate the BSD shell level on a junos device

1:43:57 and the SWR software module provides classes and methods to upgrade Juno's

1:44:03 devices the config module is one of the more widely used modules it is used to manage

1:44:09 configurations configurations can be deployed as either structured or as unstructured structured

1:44:17 changes allows yaml files to be used to deploy the changes unstructured changes

1:44:23 can be submitted using XML or Json or other structures

1:44:28 or it can be actually changed as set commands ninja templates which are not covered in

1:44:35 this video is another way to add flexibility to your scripts by allowing you to generate device specific

1:44:42 configurations that can dynamically adjust to different IP addresses interfaces and other variable data

1:44:50 to interact with the Juno's configuration you'll need to have access to it within the script when you connect

1:44:58 to a device using the device class use the dev variable as input to the config

1:45:03 class object and store that result into a new variable this variable now

1:45:10 represents your connection to the candidate configuration file now you're able to perform various actions on the

1:45:18 configuration you can lock it you can load new configurations you can roll

1:45:23 back you can rescue you can then you can commit it and unlock it

1:45:30 here we're going to take what we talked about and add something new as well exceptions exceptions allows the script

1:45:37 to react when a line of code does not execute as planned rather than just stopping the script and you being left

1:45:44 wondering what happened you can put code into what we call a try accept block

1:45:50 in the try portion of the code errors are reported if they occur and the code

1:45:56 will take an action based on the error the error that you want to check for are

1:46:01 defined in what in your accept statements when an error matches an accept statement and error is generated

1:46:10 our script review will start at the first line here is our device import

1:46:16 Juniper dot Juno's import device and this allows us again to communicate with

1:46:21 the device the next line is our Juniper Juno's utilities for and we're going to import the config

1:46:28 piece so that we can import and work with the configuration then we're going

1:46:34 to go to the exception juniper.junos.exception and import all

1:46:39 possible exceptions it doesn't mean we're going to use them all we're just going to import them all so they're in

1:46:45 memory then we can go to our main block of code where we see our try accept block

1:46:52 which is a flow control statement which we can tell because there's a colon at

1:46:57 the end and the underline items that are indented that will be controlled by this

1:47:05 we can then go to find the connection information for our device then we can

1:47:10 open our connection and then we can use that open connection to extract the candidate configuration

1:47:18 and then we can put that into a variable and then we can use the methods of that

1:47:24 config object and lock our connection to the candidate config load a change into the candidate config

1:47:31 in this case we're going to be merging bgp Dash config.conf file we could do a replace

1:47:38 or override also but here we're just going to merge it into our configuration

1:47:43 we're then going to commit it and then unlocking the file now we'll print out a configuration

1:47:50 applied message back to the screen and if everything is done properly we'll jump to the finally section and close

1:47:57 the connection but if there was a problem if there's any issues along the way then the accept

1:48:03 block would kick in and based on the error that we encountered it would

1:48:10 depend on the message that would be returned here we've built out some accept options and depending on the

1:48:17 error that comes back it depends upon which one of these we're going to use so the first one here is it says if there

1:48:23 was a connect auth error then we're going to print authentication error

1:48:29 we can also print timeout errors and other different types of errors

1:48:34 another thing we can do is we can do a connect as error the as keyword allows

1:48:39 to save the exception object to a variable and so we're going to save that to the

1:48:45 error variable name now when we go to print out we can do this print command

1:48:51 and have a percent s in there for that that unknown variable and that unknown

1:48:57 variable will then print out whatever the string is in the error message that we get handed back and this allows us to

1:49:04 give more information back to the screen for the user finally at the end we have the finally

1:49:12 command this block is always going to be executed whether the exception happened

1:49:17 or not what so if the try worked it's gonna it's gonna happen if an exception

1:49:22 got pulled it's still going to happen so here we can put our Dev Dot close so that no matter what happens we make sure

1:49:28 we close out that device connection so using a text file is not the only way

1:49:37 we can change the configuration we can actually just put the text inside of a

1:49:42 variable here you see that we have the text for an interface and it's just

1:49:48 inside the variable data we're going to take that data that file and we can load

1:49:54 that onto the configuration here we also see that we have a configuration

1:50:01 with a pdif which command shows us the differences between the original file

1:50:07 and the new file and so that we can have that show us basically what the same that the same output as a show Pipe

1:50:14 compare command can so we can see which changes were actually made on the device

1:50:21 here we can do an if statement on a commit and so this way we know that if

1:50:28 the commit worked we'll go ahead and forward but if the commit fails and has an error what we're going to do is we're

1:50:34 going to do a rollback back to that configuration that we were just at so that we can keep moving forward well

1:50:42 we've reached the end of this course and we're so happy that you've taken time out of your busy schedule to be with us

1:50:49 to learn more about Juniper Networks and the junos operating system we sure hope that you have found this

1:50:56 very useful but you might be thinking well what's next now that I'm done with this course

1:51:02 attend another jumpstart Juniper class you can sign up at the URL on the screen

1:51:08 we have six courses right now that cover junos please watch for more jumpstart

1:51:14 Juniper videos coming soon another fantastic resource is the learning portal at juniper.net

1:51:21 there you'll find a lot of resources that can help you one of those is the Juniper open

1:51:27 learning Juniper open learning is for certification and to help people get

1:51:33 started with their certifications Juniper open learning has live seminars where you can ask experts questions

1:51:40 about the things you might need to know about the certifications they also have some online videos that

1:51:47 you can watch that go over the certification information and help you

1:51:53 learn the things that you need to know they also have practice tests you can

1:51:58 receive vouchers if you pass those practice tests to receive a discount on

1:52:03 your test that you need to take to become Juniper certified so make sure

1:52:09 you check out Juniper open learning another thing is the learning paths that you can find on the learning portal the

1:52:15 learning paths help you decide which track is best for you is it security is

1:52:21 a service provider Enterprise what things do you want to learn from Juniper

1:52:26 Networks On The Learning portal you'll also find all the on-demand courses from

1:52:33 the course development team from Juniper Networks they have many courses for you

1:52:38 to take on the different technologies that Juniper Network provides so that

1:52:43 you can learn and grow in the path that you want there's also a list of class schedules

1:52:50 for scheduled classes that are led by an instructor last of all is the all access

1:52:55 pass this all access pass allows you to take any course the Juniper has this all

1:53:02 access pass is a yearly subscription for you so that you can take as many classes

1:53:08 you'd like throughout the year it's a single price and it also comes with a

1:53:14 few perks and one of those perks is that you can take an actual class from one of

1:53:20 the class schedules so you can take the on-demand course and then you can actually take it from the

1:53:27 instructor so that really helps you be able to find the path that you want to

1:53:32 take Juniper Networks has created a certification path just for you

1:53:38 this certification path will help you distinguish yourself amongst your colleagues that you know how Juniper

1:53:46 Networks operates and how to design and maintain networks built by Juniper

1:53:53 Networks equipment there's four levels within the certification path that you can take

1:53:59 there's an associate level a specialist level a professional level and an expert level

1:54:04 at each one of these levels you get to show how much you know about Juniper

1:54:10 Networks operating system and devices each one of these certifications can run

1:54:17 within a different track Juniper Networks has seven tracks that you can pick from to show your

1:54:25 Proficiency in Juniper network devices and configurations

1:54:30 these tracks are service provider routing and switching Enterprise routing

1:54:35 and switching data center Juno security Cloud Automation and devops data center

1:54:41 Wan security design so there's a track for you to be able to

1:54:48 move forward and show that you are proficient with Juniper Networks devices

1:54:55 thanks again for attending our jumpstart Juniper course today