Alright friends, let's talk about network automation in the modern world.
So you may recall when we first talked about Ansible, one of the big benefits
was that
no matter if you had an old dusty legacy device, if you could SSH enter the
device and access
to CLI, then ultimately you could automate that device. The same thing would be
true for
regular Python, you could use things like NetMico to connect over SSH and do
your management,
but again you're just managing the CLI. Now of course you can automate things WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but again you're just managing the CLI. Now of course you can automate things
via the CLI,
but you're kind of trying to use a square peg in a round hole right here. And
the NetWorking
world kind of realised it. So what actually happened was we had a development
of more modern
protocols to handle automation. Now this is what we're going to be talking
about in this particular
video, at least one of the modern protocols. So drumroll please, what is the
name of this protocol
that we are talking about? Well this one is called RestConf. Now you may recall
from a previous
scale we happened to talk about Rest API. Remember, representational state WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
scale we happened to talk about Rest API. Remember, representational state
transfer,
the thing that uses HTTP with all of the HTTP methods and data scores that type
of thing,
well this is pretty much what we're talking about. We are effectively
introducing the world
of rest into our configuration management. Now first thing to state about Rest
Conf is that it
is a more modern implementation of something known as NetConf. So NetConf is
older than RestConf,
but it is also quite a bit more complex, at least because of the ability or
rather the requirement WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
rather the requirement
to work with XML, you know, our old favourite, not really. So what I thought I
would do would be to
first deal with RestConf. And once we have that in the rear mirror then we can
cycle back in an
upcoming scale to talk a little bit more about NetConf. But for context just
understand that
RestConf kind of comes out of NetConf. It's pretty much a subset of NetConf
that has been
designed to work in this type of Rest API style manner. So you may recall when
it comes to Rest APIs,
if you just watched the previous scale we were utilising things such as HTTP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if you just watched the previous scale we were utilising things such as HTTP
methods,
these are still in play with respect to RestConf. So that means if you want to
read information
from a device, what would you do? You would send an HTTP get request if you
want to modify
your configuration. What could you do? Well you could send things like a post
request. Maybe you want
to delete a look back. What could you do? Send an HTTP delete request. So as
you can probably tell,
we really are heavily reliant on HTTP and more specifically we're going to be
using HTTP. So this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
using HTTP. So this
means the default port for RestConf is going to be the default HTTP. So let's
just back up a
little bit for a moment. Remember what I just said about NetConf? NetConf is
quite a bit more complex
than RestConf and one of the reasons is because of its reliance on XML. So you
will be pleased to know
that with respect to RestConf, but RestConf also does XML. Okay, okay, okay,
that was kind of anticlimactic.
Perhaps you were wanting a better solution, but the good news is that I'm only WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Perhaps you were wanting a better solution, but the good news is that I'm only
kidding on. We do
have the ability to work with XML if we so wish with RestConf, but RestConf and
the style of a true
Rest API, we do also have the ability for JSON supports. So pretty much if you
want XML, you can have it.
But if you're not any type of RestConf enabled device is going to give you this
ability to pull back
and work with this JSON data much, much easier at least in my opinion. Again,
big thing to remember
here with respect to RestConf. If you recall when we talked about Rest APIs, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
here with respect to RestConf. If you recall when we talked about Rest APIs, we
saw we had particular
response codes, so that would mean that, you know, if you happen to have a
successful request,
the response code would start with a two. And if it was a successful retrieval
of information,
if you get request, you could expect to see a 200 response code, whereas if you
happen to successfully
create something, it would be a 201. These response codes are absolutely still
valid and prevalent
within RestConf, so it's going to give you a lot of information about the state
of your request.
Now pop quiz, if you can remember how exactly do we target particular resources WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now pop quiz, if you can remember how exactly do we target particular resources
when we're working
with the Rest API? Well, if you remember, if we specify a particular URL and
make a request to it,
that's going to allow us to target a very particular resource within the Rest
API server in a
similar way or other in the exact same way, should I say? This is what we're
talking about with
network automation. So let me just highlight this to you. Imagine we've got our
little router here,
router one, and over here, this is me with my little Linux machine, okay, with WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
router one, and over here, this is me with my little Linux machine, okay, with
all of my Python
code and all that stuff, as opposed to logging in and managing this device via
SSH. Instead now,
what I will be doing is making HTTP extra questions of the device. And on this
device, because it has
been configured to use RestConf, it's kind of acting like a little web server
in a way, okay? So now
imagine if you happen to have some OSPF configurations on this device, as
opposed to logging in via SSH and
typing, you know, show IP OSPF database or show IP OSPF interface, whatever it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
typing, you know, show IP OSPF database or show IP OSPF interface, whatever it
may be. Instead,
you're going to send an HTTP get request to the target device. And in order to
specify that you want
OSPF information in your get request, what you're going to do is to target a
very particular URL.
Now, here is the crux of RestConf. This is a very, very big topic. And we
briefly covered it in a
previous skill. The way we actually specify the information that we want is all
about how the data is
modeled i.e. We correlated to the Yang model. Now, what I will say here is that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
modeled i.e. We correlated to the Yang model. Now, what I will say here is that
the Yang modeling
portion of modern network automation. This is by far the most complex part that
people kind of get
tripped upon. It's unfortunate. But quite honestly, everyone I know seems to
agree, Yang just is
kind of hard to work with, even though it is very, very powerful. So all I'm
saying is, if it does
quite make sense, the very first time you look at it, then honestly just be
kind to yourself,
everyone is kind of the same way, just revisit it. And with some time
practicing, it will then
begin to sink in. So again, let me just draw this out one more time. Here's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
begin to sink in. So again, let me just draw this out one more time. Here's the
router R1.
It has been configured to use the RestConf protocol. Here is our Linux server
over here that's
going to be making HTTP requests or rather HTTP requests. And say, for example,
that the IP address
of this particular device, the router itself, let's go and imagine that the
address was, I don't know,
let's say 10.1.1.1. And also, let's pre-suppose that this device had been
configured with a BGP
information. So the way the request would actually look would be we would go
and target 80 DPS, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and target 80 DPS,
colon, forward slash, forward slash, then we would have either DNS name or the
IP address of the
target. So in this case here, it would be 10.1.1.1. And then the next
components are going to allow us to
specify which resource do we want to target. So it might look like, say,
forward slash,
restcon, forward slash data, forward slash BGP. Okay. So when we send this get
request to this URL,
this device knows to send back the BGP information over 80 DPS back to here and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this device knows to send back the BGP information over 80 DPS back to here and
we can read it and
it's going to be formatted in JSON or if we so wish we can have it come back to
us in XML, the BGP
information, which means that we can now work with it in a programmatic manner.
Now like I say,
this part here, the part where we specify the resource, this is absolutely not
random, this is
related to the Yang tree for whatever the configuration you're trying to target
. So again, just hearing
this, it does sound a little bit esoteric, but we will get to see examples and
it should hopefully
begin to slowly make more sense as you get familiar with it. Okay. So now we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
begin to slowly make more sense as you get familiar with it. Okay. So now we
know that restcon is going
to allow us to interact with a device much like a rest API. We're going to have
access to
a crowd operations, a response code, that type of thing. With that now said,
let's take a look at
some particular library we can use in order to make use of requests to write
the via Python.