WEBVTT

00:00:00.000 --> 00:00:03.740
So now let's talk about NetConf and RESTConf.

00:00:05.280 --> 00:00:08.960
So NetConf and RESTConf we mentioned many times now and

00:00:09.960 --> 00:00:11.960
specifically we said they are going to be what?

00:00:13.000 --> 00:00:17.080
Two different ways that we can communicate between our controllers

00:00:18.000 --> 00:00:19.360
and

00:00:19.360 --> 00:00:21.360
our devices.

00:00:23.440 --> 00:00:24.920
Or

00:00:24.920 --> 00:00:26.920
even me sitting at a computer

00:00:27.880 --> 00:00:29.880
talking to my device.

00:00:30.520 --> 00:00:33.720
Because my device would be the controller in this case, even though it's not an official controller,

00:00:33.720 --> 00:00:38.600
I'm still there. So these are self-bound APIs. Self-bound APIs, NetConf and RESTConf.

00:00:39.520 --> 00:00:47.120
Used for transportation, used for configuration, used to tell devices to do this or learn about da-da-da-da from the device.

00:00:47.120 --> 00:00:49.120
Whatever it happens to be.

00:00:49.680 --> 00:00:55.080
So NetConf provides a mechanism so we can install, manipulate, delete the configuration of network devices.

00:00:55.360 --> 00:00:57.400
Now RESTConf does the same thing for me too.

00:00:58.400 --> 00:01:05.400
NetConf is based on XML. RESTConf is based on HTTP based protocol REST APIs.

00:01:07.160 --> 00:01:12.760
XML, HTTP, REST APIs. So typically JSON is going to be used over here.

00:01:13.920 --> 00:01:16.080
Right. JSON versus XML.

00:01:17.600 --> 00:01:19.600
RPCs therefore. RPCs.

00:01:21.160 --> 00:01:23.160
Remote procedure calls.

00:01:23.320 --> 00:01:28.520
When we're communicating. Whereas over here with RESTConf, what are we doing? With RESTConf, it's going to be

00:01:33.400 --> 00:01:35.400
HTTP verbs. It's going to be those verbs

00:01:38.000 --> 00:01:41.600
that we were talking about earlier. Get, put, post, delete.

00:01:42.880 --> 00:01:46.280
So why the two? Why the two? Here's the reason why.

00:01:47.280 --> 00:01:52.320
NetConf is really, really great when you have a station, a computer,

00:01:52.960 --> 00:01:54.960
talking to the device.

00:01:55.080 --> 00:01:58.520
Remote procedure calls are not human-friendly at all. Okay, they're not.

00:02:00.240 --> 00:02:03.080
And they're based on XML. Not human-friendly.

00:02:03.720 --> 00:02:06.160
So RESTConf though is really good when you,

00:02:07.080 --> 00:02:13.400
let's say you're using a web browser to communicate with the device or you have some sort of web app to communicate with the device.

00:02:15.200 --> 00:02:20.640
RESTConf is good for humans. NetConf, great for machines. That's why the two.

00:02:21.640 --> 00:02:24.680
So what I need you to know is what we're going to see on this page.

00:02:25.480 --> 00:02:30.200
What we're going to talk about here. We have this protocol stack for NetConf and RESTConf.

00:02:31.480 --> 00:02:36.920
Secure transportation, messages, operations, access to take, and content configuration and operational data.

00:02:37.960 --> 00:02:39.960
So let's start off at the bottom here with secure transport.

00:02:41.080 --> 00:02:43.080
NetConf using SSH.

00:02:43.920 --> 00:02:45.920
So if we're using SSH,

00:02:46.560 --> 00:02:48.560
what do we have?

00:02:49.560 --> 00:02:54.560
Certificates, port 22, but by default it actually uses port 830.

00:02:55.560 --> 00:03:01.760
Okay, so it's not actually using port 22 by default. It's using port 830, but SSH, certificates, things like that.

00:03:02.560 --> 00:03:04.560
Whereas RESTConf, it's HTTPS.

00:03:05.560 --> 00:03:11.560
So we'd be using SSLTLS because of HTTPS.

00:03:14.560 --> 00:03:16.560
So therefore we need certificates.

00:03:17.560 --> 00:03:19.560
So therefore we need certificates as well.

00:03:23.560 --> 00:03:25.560
But what else do we need here for this to work?

00:03:27.560 --> 00:03:29.560
We need a web server.

00:03:31.560 --> 00:03:36.560
So if I am using RESTConf to connect to my device

00:03:40.560 --> 00:03:42.560
from wherever,

00:03:43.560 --> 00:03:47.560
I am the client, you are the server.

00:03:47.560 --> 00:03:51.560
So who has to have the web server running? Me or the router?

00:03:53.560 --> 00:03:55.560
The router has to have the web server running.

00:03:56.560 --> 00:03:59.560
And so what we have is we have NGINX.

00:04:01.560 --> 00:04:07.560
NGINX is our internal web server on our routers.

00:04:08.560 --> 00:04:10.560
NGINX is our internal web server on our routers.

00:04:11.560 --> 00:04:15.560
It acts as a proxy web server specifically.

00:04:18.560 --> 00:04:23.560
And this is going to give us our TLS-based HTTP connections that we need

00:04:24.560 --> 00:04:27.560
from whatever it is that's using RESTConf to connect to our router.

00:04:29.560 --> 00:04:32.560
So when I was playing around here with Postman,

00:04:32.560 --> 00:04:34.560
and I'm using HTTPS here,

00:04:37.560 --> 00:04:40.560
I am using RESTConf for this.

00:04:42.560 --> 00:04:45.560
Therefore the router has RESTConf running.

00:04:46.560 --> 00:04:52.560
It has an HTTPS server running on it right now.

00:04:53.560 --> 00:04:56.560
That's what it has for me to be able to do what I was doing.

00:04:56.560 --> 00:05:00.560
And so my RESTConf request gets sent via HTTPS.

00:05:01.560 --> 00:05:05.560
It's received by the NGINX proxy web server first.

00:05:06.560 --> 00:05:13.560
And then the request is going to be transferred to the ConfD web server

00:05:14.560 --> 00:05:16.560
that is running on my actual router.

00:05:17.560 --> 00:05:19.560
So we have a ConfD web server running on the router,

00:05:20.560 --> 00:05:22.560
but then we have a RESTConf request.

00:05:23.560 --> 00:05:25.560
So we have a ConfD web server running on the router,

00:05:26.560 --> 00:05:28.560
but the NGINX proxy web server is in front of it,

00:05:29.560 --> 00:05:32.560
and it's the one that first checks the incoming connection.

00:05:33.560 --> 00:05:34.560
And then, if everything is good there,

00:05:35.560 --> 00:05:36.560
it passes it off to ConfD for further processing.

00:05:53.560 --> 00:05:54.560
Pause a little bit longer for you,

00:05:55.560 --> 00:05:56.560
because you want to take a screenshot of that,

00:05:57.560 --> 00:05:58.560
or if you come back later, make sure you take a screenshot of that.

00:06:01.560 --> 00:06:03.560
Post it on your wall in your office maybe.

00:06:05.560 --> 00:06:06.560
All right, let's move on up the stack.

00:06:07.560 --> 00:06:09.560
So now when it comes to messaging,

00:06:10.560 --> 00:06:12.560
if they're talking about NetConf on the exam,

00:06:13.560 --> 00:06:15.560
RPC, remote procedure calls.

00:06:16.560 --> 00:06:17.560
RESTConf, REST APIs.

00:06:18.560 --> 00:06:19.560
So since we're using RPC here,

00:06:20.560 --> 00:06:21.560
and we're using REST APIs here,

00:06:22.560 --> 00:06:24.560
that's going to have an effect on our operational actions.

00:06:25.560 --> 00:06:26.560
So our operational actions,

00:06:27.560 --> 00:06:29.560
you're going to see Get, GetConfig, EditConfig, CopyConfig, DeleteConfig,

00:06:30.560 --> 00:06:32.560
Commit, Lock, Unlock, CloseSession, KillSession, right?

00:06:33.560 --> 00:06:35.560
And then on RESTConf, because of REST APIs,

00:06:36.560 --> 00:06:38.560
Head, Get, Post, Put, Patch, Delete.

00:06:39.560 --> 00:06:41.560
Those are the verbs we talked about a while ago.

00:06:52.560 --> 00:06:53.560
And then as we mentioned earlier,

00:06:54.560 --> 00:06:55.560
when it comes to the content configuration

00:06:56.560 --> 00:06:57.560
and operational data,

00:06:58.560 --> 00:06:59.560
we got XML for NetConf,

00:07:00.560 --> 00:07:01.560
and for RESTConf, we have,

00:07:02.560 --> 00:07:03.560
we can do XML,

00:07:04.560 --> 00:07:05.560
but definitely JSON is a better formatting

00:07:06.560 --> 00:07:07.560
for that, for human beings.

00:07:09.560 --> 00:07:11.560
So we have this concept of data stores now on our devices.

00:07:12.560 --> 00:07:13.560
We have the RunningConfigDataStore,

00:07:14.560 --> 00:07:15.560
the StartupConfigDataStore,

00:07:16.560 --> 00:07:17.560
and the CandidateConfigDataStore.

00:07:18.560 --> 00:07:19.560
So we're going to go ahead

00:07:19.560 --> 00:07:20.560
and we have the RunningConfigDataStore,

00:07:21.560 --> 00:07:22.560
the StartupConfigDataStore,

00:07:23.560 --> 00:07:24.560
and the CandidateConfigDataStore.

00:07:25.560 --> 00:07:26.560
And so when it comes to

00:07:27.560 --> 00:07:28.560
software-defined networking devices

00:07:29.560 --> 00:07:30.560
that are out there,

00:07:31.560 --> 00:07:32.560
not all of them are going to have all these data stores,

00:07:33.560 --> 00:07:34.560
because not all of them are going to need it.

00:07:35.560 --> 00:07:36.560
But all devices need one of these.

00:07:37.560 --> 00:07:38.560
All devices need one of these,

00:07:39.560 --> 00:07:40.560
and that is the RunningConfigDataStore.

00:07:41.560 --> 00:07:42.560
So this configuration data store

00:07:43.560 --> 00:07:44.560
holds the complete configuration

00:07:45.560 --> 00:07:47.560
currently active on the device.

00:07:48.560 --> 00:07:49.560
So you can only have one

00:07:50.560 --> 00:07:52.560
RunningConfigDataStore on your device,

00:07:53.560 --> 00:07:54.560
and it has to always exist.

00:07:59.560 --> 00:08:01.560
So if we went to our router,

00:08:02.560 --> 00:08:03.560
and I said, hey,

00:08:04.560 --> 00:08:05.560
I want to see the context

00:08:06.560 --> 00:08:07.560
of the RunningConfigDataStore.

00:08:14.560 --> 00:08:15.560
Show RunningConfig.

00:08:15.560 --> 00:08:16.560
That's all it means.

00:08:17.560 --> 00:08:18.560
So we're dealing with

00:08:21.560 --> 00:08:22.560
the RunningConfig.

00:08:24.560 --> 00:08:25.560
So it's the RunningConfigStore

00:08:26.560 --> 00:08:27.560
in our RunningConfigDataStore.

00:08:29.560 --> 00:08:30.560
So the StartupConfigurationDataStore,

00:08:31.560 --> 00:08:32.560
what do you think that is, folks?

00:08:33.560 --> 00:08:35.560
Well, it's where we store

00:08:36.560 --> 00:08:37.560
a copy

00:08:38.560 --> 00:08:39.560
of our configuration,

00:08:41.560 --> 00:08:42.560
so that way there,

00:08:43.560 --> 00:08:44.560
when the device boots,

00:08:46.560 --> 00:08:48.560
that is the config that is loaded.

00:08:51.560 --> 00:08:54.560
Now on older equipment,

00:08:55.560 --> 00:08:56.560
show StartupConfig,

00:08:57.560 --> 00:08:58.560
even modern equipment, right?

00:08:59.560 --> 00:09:00.560
Show StartupConfig.

00:09:01.560 --> 00:09:02.560
There's my StartupConfigDataStore.

00:09:05.560 --> 00:09:07.560
So in the world of software-defined networking,

00:09:08.560 --> 00:09:09.560
does every device need

00:09:10.560 --> 00:09:11.560
a StartupConfigDataStore?

00:09:12.560 --> 00:09:13.560
And the answer to that is no,

00:09:13.560 --> 00:09:14.560
because think about a pure,

00:09:15.560 --> 00:09:16.560
pure, pure software-defined

00:09:17.560 --> 00:09:18.560
networking router or switch.

00:09:21.560 --> 00:09:23.560
Who is always going to tell it

00:09:24.560 --> 00:09:25.560
what its configuration is?

00:09:26.560 --> 00:09:27.560
The controller.

00:09:28.560 --> 00:09:29.560
So it doesn't have to store

00:09:30.560 --> 00:09:31.560
its configuration at all,

00:09:32.560 --> 00:09:33.560
because it's always being told

00:09:34.560 --> 00:09:35.560
when it boots,

00:09:36.560 --> 00:09:37.560
here's your config.

00:09:38.560 --> 00:09:39.560
When it's running and things change,

00:09:40.560 --> 00:09:41.560
the controller says,

00:09:41.560 --> 00:09:42.560
here's your updated config.

00:09:43.560 --> 00:09:44.560
And so it never needs

00:09:45.560 --> 00:09:46.560
to store its own config.

00:09:47.560 --> 00:09:48.560
So if you ever buy a product

00:09:49.560 --> 00:09:50.560
that is purely, purely, purely

00:09:51.560 --> 00:09:52.560
a true, true, true software-defined

00:09:53.560 --> 00:09:54.560
networking device

00:09:55.560 --> 00:09:56.560
that doesn't store anything on itself,

00:09:57.560 --> 00:09:58.560
then it only has a running config.

00:09:59.560 --> 00:10:00.560
It won't have a StartupConfig.

00:10:01.560 --> 00:10:02.560
But Cisco devices have both.

00:10:03.560 --> 00:10:04.560
Cisco devices will have a running config

00:10:05.560 --> 00:10:06.560
and a StartupConfig.

00:10:07.560 --> 00:10:08.560
And the reason why is because

00:10:09.560 --> 00:10:10.560
if something happens to the controller

00:10:11.560 --> 00:10:12.560
and it doesn't have anything on it,

00:10:13.560 --> 00:10:14.560
so this is Cisco's idea

00:10:15.560 --> 00:10:16.560
of fallback capabilities

00:10:17.560 --> 00:10:18.560
and the ability to still survive

00:10:19.560 --> 00:10:20.560
if your controller blows up on you,

00:10:21.560 --> 00:10:22.560
which is nice to have.

00:10:23.560 --> 00:10:24.560
And then what about

00:10:25.560 --> 00:10:26.560
these candidate data stores?

00:10:27.560 --> 00:10:28.560
What is that?

00:10:29.560 --> 00:10:30.560
How many of you have Nexus products?

00:10:31.560 --> 00:10:32.560
Anybody here have a Nexus product?

00:10:33.560 --> 00:10:34.560
If you have a Nexus product,

00:10:35.560 --> 00:10:36.560
when you do your configuration

00:10:37.560 --> 00:10:38.560
and you hit Enter,

00:10:39.560 --> 00:10:40.560
does it actually apply

00:10:41.560 --> 00:10:42.560
in some way?

00:10:43.560 --> 00:10:45.560
Or do you have to commit it later on?

00:10:46.560 --> 00:10:47.560
You have to commit it later on.

00:10:48.560 --> 00:10:49.560
So, iOS and iOS XE,

00:10:50.560 --> 00:10:51.560
every time you hit Enter,

00:10:52.560 --> 00:10:53.560
it applies your config.

00:10:54.560 --> 00:10:55.560
It applies your config.

00:10:56.560 --> 00:10:57.560
Well, with something like a Nexus product

00:10:58.560 --> 00:10:59.560
running Nexus OS operating system,

00:11:00.560 --> 00:11:01.560
when you do your configuration

00:11:02.560 --> 00:11:03.560
and you hit Enter,

00:11:04.560 --> 00:11:05.560
it doesn't apply it.

00:11:06.560 --> 00:11:07.560
It stores it in a candidate data store.

00:11:08.560 --> 00:11:09.560
And then when you commit,

00:11:09.560 --> 00:11:10.560
then it takes everything

00:11:11.560 --> 00:11:12.560
in the candidate data store

00:11:13.560 --> 00:11:14.560
and puts it to the running config.

00:11:15.560 --> 00:11:16.560
So, that's all that is.

00:11:17.560 --> 00:11:18.560
Cisco iOS and iOS XE devices

00:11:19.560 --> 00:11:20.560
don't have a candidate data store.

00:11:21.560 --> 00:11:22.560
Nexus products do.

00:11:23.560 --> 00:11:24.560
But those are the three

00:11:25.560 --> 00:11:26.560
different data stores we have.

00:11:27.560 --> 00:11:28.560
We could possibly have,

00:11:29.560 --> 00:11:30.560
depending on the equipment.

00:11:31.560 --> 00:11:32.560
So, you'll see here an example

00:11:33.560 --> 00:11:34.560
of NetConf RPC call.

00:11:35.560 --> 00:11:36.560
How do I know it's an RPC call?

00:11:37.560 --> 00:11:38.560
It says right here in the header.

00:11:39.560 --> 00:11:40.560
So, for example,

00:11:41.560 --> 00:11:42.560
I want to get information

00:11:43.560 --> 00:11:44.560
from the running config.

00:11:45.560 --> 00:11:46.560
I want to get information

00:11:47.560 --> 00:11:48.560
from the startup config.

00:11:49.560 --> 00:11:50.560
You would specify that

00:11:51.560 --> 00:11:52.560
in your actual call to the device.

00:11:53.560 --> 00:11:54.560
So, the server is making

00:11:55.560 --> 00:11:56.560
the call to the device.

00:11:57.560 --> 00:11:58.560
This would be my call.

00:11:59.560 --> 00:12:00.560
This would be the message

00:12:01.560 --> 00:12:02.560
that's going from the server

00:12:03.560 --> 00:12:04.560
to the device using NetConf.

00:12:05.560 --> 00:12:06.560
So, in this case here,

00:12:07.560 --> 00:12:08.560
it's an RPC call.

00:12:09.560 --> 00:12:10.560
I want to get information

00:12:11.560 --> 00:12:12.560
from the running config,

00:12:13.560 --> 00:12:14.560
the data store.

00:12:15.560 --> 00:12:17.560
And what do we want to get?

00:12:18.560 --> 00:12:20.560
Well, we only want to get

00:12:21.560 --> 00:12:22.560
information pertaining

00:12:23.560 --> 00:12:24.560
to the YANG data model

00:12:25.560 --> 00:12:26.560
called IETF interfaces.

00:12:27.560 --> 00:12:28.560
There, now you can see it

00:12:29.560 --> 00:12:30.560
in action right there.

00:12:31.560 --> 00:12:32.560
I'm actually able to specify

00:12:33.560 --> 00:12:35.560
that I only want information

00:12:36.560 --> 00:12:37.560
from that store

00:12:37.560 --> 00:12:39.560
pertaining to IETF interfaces.

00:12:40.560 --> 00:12:42.560
And then we can take it even further.

00:12:43.560 --> 00:12:44.560
Well, which interface do you want?

00:12:45.560 --> 00:12:46.560
Right, if I didn't specify

00:12:47.560 --> 00:12:48.560
interface here, name,

00:12:49.560 --> 00:12:50.560
then it would just give me all interfaces.

00:12:51.560 --> 00:12:52.560
But now I'm saying this specific

00:12:53.560 --> 00:12:54.560
interface by its name.

00:12:55.560 --> 00:12:56.560
Right, and then close it out.

00:12:57.560 --> 00:12:58.560
So, there's just an example

00:12:59.560 --> 00:13:00.560
of a type of RPC call

00:13:01.560 --> 00:13:02.560
that you can make

00:13:03.560 --> 00:13:04.560
to get the details that you want.

00:13:05.560 --> 00:13:06.560
Now, how do we turn on

00:13:07.560 --> 00:13:08.560
the configuration mode?

00:13:09.560 --> 00:13:10.560
And you type in netconf yang.

00:13:11.560 --> 00:13:13.560
And then netconf gets enabled.

00:13:14.560 --> 00:13:15.560
Your device is using SSH,

00:13:16.560 --> 00:13:17.560
then it becomes an SSH server.

00:13:18.560 --> 00:13:19.560
So, that way there,

00:13:20.560 --> 00:13:22.560
the controller can SSH to the device

00:13:23.560 --> 00:13:24.560
and make the RPC calls that it needs.

00:13:25.560 --> 00:13:27.560
So, netconf listens on any IP address

00:13:28.560 --> 00:13:29.560
assigned to the system.

00:13:30.560 --> 00:13:31.560
So, if your system has five different IP addresses,

00:13:32.560 --> 00:13:33.560
netconf's running on all those IP addresses.

00:13:34.560 --> 00:13:35.560
It's going to be port 830 by default,

00:13:35.560 --> 00:13:36.560
as I said.

00:13:37.560 --> 00:13:38.560
But you can change that port number.

00:13:39.560 --> 00:13:40.560
If you want to use port 22, you can.

00:13:41.560 --> 00:13:42.560
But 830 is the default.

00:13:43.560 --> 00:13:44.560
And SSH automatically gets enabled

00:13:45.560 --> 00:13:46.560
as soon as you type in netconf dash yang

00:13:47.560 --> 00:13:48.560
because it can't work without SSH.

00:13:49.560 --> 00:13:50.560
So, SSH automatically enabled.

00:13:51.560 --> 00:13:52.560
You can have self-signed certificates

00:13:53.560 --> 00:13:54.560
on your device.

00:13:55.560 --> 00:13:56.560
You're going to use,

00:13:57.560 --> 00:13:58.560
better in a production environment,

00:13:59.560 --> 00:14:00.560
to use certificates from a certificate server,

00:14:01.560 --> 00:14:02.560
your keying materials, stuff like that,

00:14:03.560 --> 00:14:04.560
centralized, managed, all of that stuff.

00:14:05.560 --> 00:14:06.560
So, that's the command.

00:14:07.560 --> 00:14:08.560
That's the port number by default.

00:14:09.560 --> 00:14:10.560
And we're using SSH.

00:14:11.560 --> 00:14:12.560
All right, so let's shift our attention

00:14:13.560 --> 00:14:14.560
over now to RESTconf.

00:14:15.560 --> 00:14:16.560
So, with RESTconf, we're using URLs.

00:14:17.560 --> 00:14:18.560
We're not using RPC calls.

00:14:19.560 --> 00:14:20.560
So, we're using URLs.

00:14:21.560 --> 00:14:22.560
We're using HTTP messages.

00:14:23.560 --> 00:14:24.560
So, now that we know a little bit more

00:14:25.560 --> 00:14:26.560
about YANG data models,

00:14:27.560 --> 00:14:28.560
we're going to be able to see here

00:14:29.560 --> 00:14:30.560
better information.

00:14:30.560 --> 00:14:31.560
We're going to understand this URL a lot better,

00:14:32.560 --> 00:14:33.560
this REST API call.

00:14:33.560 --> 00:14:34.560
So, we got HTTPS,

00:14:35.560 --> 00:14:36.560
as we talked about before,

00:14:37.560 --> 00:14:38.560
for SSL TLS encryption.

00:14:39.560 --> 00:14:40.560
You got the name of the server,

00:14:41.560 --> 00:14:42.560
the port number the server is using.

00:14:43.560 --> 00:14:44.560
So, depending on how you set it up,

00:14:45.560 --> 00:14:46.560
right, default port 443,

00:14:47.560 --> 00:14:48.560
then you'd be using 443.

00:14:49.560 --> 00:14:50.560
But you actually have to specify

00:14:51.560 --> 00:14:52.560
the name and the port number.

00:14:53.560 --> 00:14:54.560
Okay, well, you don't have to specify

00:14:55.560 --> 00:14:56.560
the port number if you are using 443,

00:14:57.560 --> 00:14:58.560
because that's what HTTPS uses by default is 443.

00:14:59.560 --> 00:15:00.560
But if you use a different port number,

00:15:01.560 --> 00:15:02.560
then you have to specify it.

00:15:03.560 --> 00:15:04.560
So, what about 1389?

00:15:05.560 --> 00:15:06.560
Well, then you would specify the name

00:15:07.560 --> 00:15:08.560
or the IP address followed by port 1389,

00:15:09.560 --> 00:15:11.560
so that way their HTTPS is using 1389 instead.

00:15:12.560 --> 00:15:13.560
All right, so you got to have

00:15:14.560 --> 00:15:15.560
the right port number there

00:15:16.560 --> 00:15:17.560
depending on what you're using on your actual device

00:15:18.560 --> 00:15:19.560
that you're trying to contact.

00:15:20.560 --> 00:15:21.560
Then root, so in this case,

00:15:22.560 --> 00:15:23.560
we're using RESTconf,

00:15:24.560 --> 00:15:25.560
so the root is actually RESTconf.

00:15:26.560 --> 00:15:27.560
That's what it's going to be.

00:15:28.560 --> 00:15:29.560
Your datastore, so is it the running config datastore,

00:15:30.560 --> 00:15:31.560
startup config, whatever the datastore is.

00:15:31.560 --> 00:15:32.560
So, what do we want?

00:15:33.560 --> 00:15:34.560
Well, in this case, IETF interfaces,

00:15:35.560 --> 00:15:36.560
but if we wanted a different YANG data model,

00:15:37.560 --> 00:15:38.560
like I want the BGP or I want this information,

00:15:39.560 --> 00:15:40.560
that information,

00:15:41.560 --> 00:15:42.560
you're specifying it there in the actual title

00:15:43.560 --> 00:15:44.560
or in the URL, I should say.

00:15:45.560 --> 00:15:46.560
So, this is why when I was saying

00:15:47.560 --> 00:15:48.560
every little tiny component of your device

00:15:49.560 --> 00:15:51.560
technically now has its own API,

00:15:52.560 --> 00:15:54.560
because if you're looking at it this way,

00:15:55.560 --> 00:15:56.560
I could specify the YANG data model

00:15:57.560 --> 00:15:59.560
and then therefore on my device

00:15:59.560 --> 00:16:01.560
only now the IETF interfaces

00:16:02.560 --> 00:16:03.560
are affected by this.

00:16:04.560 --> 00:16:05.560
But then you specify the container

00:16:06.560 --> 00:16:07.560
and therefore what is the container?

00:16:08.560 --> 00:16:09.560
It's either this container or this container.

00:16:10.560 --> 00:16:11.560
If I leave a blank,

00:16:12.560 --> 00:16:13.560
then it's both containers

00:16:14.560 --> 00:16:15.560
in that particular YANG module.

00:16:16.560 --> 00:16:17.560
And then you have your leaf, right?

00:16:18.560 --> 00:16:20.560
So, if I specify this, then I specify this.

00:16:21.560 --> 00:16:22.560
If I specify this, then I specify this.

00:16:23.560 --> 00:16:24.560
So, the leaf changes.

00:16:25.560 --> 00:16:26.560
And then you have other options you can use,

00:16:27.560 --> 00:16:28.560
other options that you can use for filtering.

00:16:29.560 --> 00:16:31.560
For example, if I don't set a filter,

00:16:32.560 --> 00:16:34.560
then it gives me all of this information back.

00:16:35.560 --> 00:16:36.560
But if I set a filter, I could say

00:16:37.560 --> 00:16:38.560
only give me name or only give me description

00:16:39.560 --> 00:16:40.560
or only give me type.

00:16:41.560 --> 00:16:42.560
I can control that.

00:16:43.560 --> 00:16:44.560
So, earlier when I was using Postman,

00:16:45.560 --> 00:16:46.560
that's what was happening.

00:16:47.560 --> 00:16:48.560
So, if I say, let me close this without saving.

00:16:49.560 --> 00:16:50.560
No, because I know I made some changes there.

00:16:51.560 --> 00:16:52.560
Don't save.

00:16:53.560 --> 00:16:54.560
All right, so pull all interfaces.

00:16:55.560 --> 00:16:56.560
So, you'll see here,

00:16:57.560 --> 00:16:58.560
oh, let's go back here.

00:16:59.560 --> 00:17:02.560
All right, there is the URL.

00:17:03.560 --> 00:17:05.560
IETF interfaces.

00:17:06.560 --> 00:17:07.560
So, there is our module.

00:17:08.560 --> 00:17:09.560
There is our container.

00:17:10.560 --> 00:17:11.560
So, I'm saying just give me everything

00:17:12.560 --> 00:17:13.560
in that container for that module.

00:17:14.560 --> 00:17:15.560
Send.

00:17:16.560 --> 00:17:17.560
There it is.

00:17:20.560 --> 00:17:23.560
All right, let's go just interfaces state.

00:17:24.560 --> 00:17:25.560
So, notice here, IETF interfaces,

00:17:26.560 --> 00:17:28.560
interfaces state.

00:17:29.560 --> 00:17:30.560
So, now I'm specifically saying,

00:17:31.560 --> 00:17:33.560
hey, I only want that second container.

00:17:34.560 --> 00:17:35.560
Send.

00:17:36.560 --> 00:17:37.560
So, it's only going to return to me

00:17:38.560 --> 00:17:47.560
the second container information.

00:17:48.560 --> 00:17:49.560
So, what if I want to create,

00:17:50.560 --> 00:17:51.560
as we saw earlier?

00:17:52.560 --> 00:17:53.560
So, I want to create an interface.

00:17:54.560 --> 00:17:55.560
So, IETF interfaces, the model,

00:17:56.560 --> 00:17:57.560
the container,

00:17:57.560 --> 00:17:59.560
then inside that particular container,

00:18:00.560 --> 00:18:01.560
what is the interface I want to create?

00:18:02.560 --> 00:18:04.560
So, that is now the actual interface,

00:18:05.560 --> 00:18:06.560
and then my extra option.

00:18:07.560 --> 00:18:08.560
So, that would be the option.

00:18:09.560 --> 00:18:10.560
I want to call it loopback 150.

00:18:11.560 --> 00:18:12.560
So, then when I click send,

00:18:13.560 --> 00:18:15.560
I have included right now,

00:18:16.560 --> 00:18:17.560
so far, right?

00:18:18.560 --> 00:18:19.560
So, I specified this,

00:18:20.560 --> 00:18:21.560
I specified this, I specified this,

00:18:22.560 --> 00:18:23.560
I specified this,

00:18:24.560 --> 00:18:25.560
but you got to go into the body as well now

00:18:25.560 --> 00:18:26.560
because I'm putting, right?

00:18:27.560 --> 00:18:28.560
What information are we going to apply here?

00:18:29.560 --> 00:18:30.560
And then which one of those

00:18:31.560 --> 00:18:32.560
are going to be empty?

00:18:33.560 --> 00:18:34.560
So, if I open this up,

00:18:35.560 --> 00:18:36.560
so the name is loopback,

00:18:37.560 --> 00:18:39.560
description, type, enabled,

00:18:40.560 --> 00:18:41.560
IP address and mask.

00:18:42.560 --> 00:18:44.560
So, do I have to fill everything in?

00:18:45.560 --> 00:18:46.560
No, if I don't fill stuff in,

00:18:47.560 --> 00:18:48.560
then it goes to the default value

00:18:49.560 --> 00:18:50.560
on that platform,

00:18:51.560 --> 00:18:52.560
the default value on that platform.

00:18:52.560 --> 00:18:54.560
So, let's go back to here

00:18:55.560 --> 00:18:57.560
and say I want loopback 150.

00:19:14.560 --> 00:19:15.560
Oh, there it is.

00:19:16.560 --> 00:19:17.560
So, in this case,

00:19:18.560 --> 00:19:19.560
so when you think about it,

00:19:20.560 --> 00:19:21.560
when I created the interface,

00:19:22.560 --> 00:19:24.560
interface loopback 150,

00:19:25.560 --> 00:19:27.560
I didn't provide all the values.

00:19:28.560 --> 00:19:29.560
What did we provide?

00:19:30.560 --> 00:19:31.560
The name, the description,

00:19:32.560 --> 00:19:35.560
the type, true and the IP address, right?

00:19:36.560 --> 00:19:37.560
That's what we provided,

00:19:38.560 --> 00:19:39.560
but there are other details there.

00:19:40.560 --> 00:19:41.560
So, if we want to get the interface state

00:19:42.560 --> 00:19:43.560
as an example,

00:19:44.560 --> 00:19:45.560
see if I can do this right now.

00:19:46.560 --> 00:19:47.560
Interface, interface-state,

00:19:48.560 --> 00:19:49.560
I believe it is.

00:19:49.560 --> 00:19:50.560
No, I don't have that.

00:19:51.560 --> 00:19:52.560
That's a 404 that I've found.

00:19:53.560 --> 00:19:54.560
I got to double check on that.

00:19:55.560 --> 00:19:56.560
I got to look that up.

00:19:57.560 --> 00:19:58.560
What is it going to be?

00:19:59.560 --> 00:20:00.560
Interface-state, that should work.

00:20:01.560 --> 00:20:04.560
No, interfaces-state under

00:20:09.560 --> 00:20:10.560
IETF interfaces.

00:20:11.560 --> 00:20:12.560
Oh, the wrong spot.

00:20:13.560 --> 00:20:14.560
That's what I did wrong.

00:20:15.560 --> 00:20:16.560
Interfaces-state,

00:20:17.560 --> 00:20:18.560
and then this is

00:20:19.560 --> 00:20:20.560
interface.

00:20:21.560 --> 00:20:22.560
There you go.

00:20:25.560 --> 00:20:26.560
So, you can see that

00:20:27.560 --> 00:20:28.560
even though we had default values for the interface,

00:20:29.560 --> 00:20:30.560
well, here's other information about it.

00:20:32.560 --> 00:20:33.560
So, if you don't put specific things in

00:20:34.560 --> 00:20:35.560
on other aspects,

00:20:36.560 --> 00:20:37.560
look, it randomly picked eight

00:20:38.560 --> 00:20:39.560
for my interface index number

00:20:40.560 --> 00:20:41.560
because I didn't supply one.

00:20:42.560 --> 00:20:43.560
So, that's all I'm trying to show you right now

00:20:44.560 --> 00:20:46.560
is that this ensures that

00:20:47.560 --> 00:20:48.560
whether I'm on a Cisco device,

00:20:49.560 --> 00:20:50.560
an HP device, it doesn't matter.

00:20:52.560 --> 00:20:54.560
I can put in the information I need here

00:20:55.560 --> 00:20:56.560
for it.

00:20:57.560 --> 00:20:58.560
So, for example,

00:20:59.560 --> 00:21:00.560
if it was a HP device in my environment

00:21:01.560 --> 00:21:02.560
or a Juniper device in my environment,

00:21:03.560 --> 00:21:04.560
then all I have to do is make sure

00:21:05.560 --> 00:21:06.560
I put in the correct name,

00:21:07.560 --> 00:21:08.560
the correct port,

00:21:09.560 --> 00:21:10.560
and then

00:21:11.560 --> 00:21:13.560
this would all be the same,

00:21:14.560 --> 00:21:15.560
and then this would just be

00:21:16.560 --> 00:21:17.560
the interface name and number

00:21:17.560 --> 00:21:18.560
on that device,

00:21:19.560 --> 00:21:20.560
and then I can get the output I need,

00:21:21.560 --> 00:21:22.560
and it would be this stuff,

00:21:23.560 --> 00:21:24.560
the same stuff with just the outputs

00:21:25.560 --> 00:21:26.560
pertaining to that device.

00:21:27.560 --> 00:21:28.560
See the consistency now?

00:21:29.560 --> 00:21:30.560
When compared to trying to learn

00:21:31.560 --> 00:21:32.560
the CLI of every device

00:21:33.560 --> 00:21:34.560
that exists out there,

00:21:35.560 --> 00:21:36.560
that's why this is happening.

00:21:38.560 --> 00:21:39.560
HTTPS is needed for Rescoff

00:21:40.560 --> 00:21:41.560
on iOS XE.

00:21:42.560 --> 00:21:43.560
Port 443

00:21:44.560 --> 00:21:45.560
is used by default.

00:21:45.560 --> 00:21:46.560
You turn on the HTTPS server

00:21:47.560 --> 00:21:49.560
by typing in IP HTTP secure server.

00:21:50.560 --> 00:21:51.560
Therefore, it listens,

00:21:52.560 --> 00:21:53.560
the web server listens on any IP address

00:21:54.560 --> 00:21:55.560
assigned to the system,

00:21:56.560 --> 00:21:57.560
and then you enable Rescoff

00:21:58.560 --> 00:21:59.560
by just typing in rescoff.

00:22:00.560 --> 00:22:01.560
That's it.

00:22:02.560 --> 00:22:03.560
And then you can start using

00:22:04.560 --> 00:22:05.560
REST API calls to your device.

00:22:06.560 --> 00:22:07.560
It's incredible.

00:22:08.560 --> 00:22:09.560
It really is.