So now let's talk about NetConf and RESTConf.
So NetConf and RESTConf we mentioned many times now and
specifically we said they are going to be what?
Two different ways that we can communicate between our controllers
and
our devices.
Or
even me sitting at a computer
talking to my device.
Because my device would be the controller in this case, even though it's not an official controller,
I'm still there. So these are self-bound APIs. Self-bound APIs, NetConf and RESTConf.
Used for transportation, used for configuration, used to tell devices to do this or learn about da-da-da-da from the device.
Whatever it happens to be.
So NetConf provides a mechanism so we can install, manipulate, delete the configuration of network devices.
Now RESTConf does the same thing for me too.
NetConf is based on XML. RESTConf is based on HTTP based protocol REST APIs.
XML, HTTP, REST APIs. So typically JSON is going to be used over here.
Right. JSON versus XML.
RPCs therefore. RPCs.
Remote procedure calls.
When we're communicating. Whereas over here with RESTConf, what are we doing? With RESTConf, it's going to be
HTTP verbs. It's going to be those verbs
that we were talking about earlier. Get, put, post, delete.
So why the two? Why the two? Here's the reason why.
NetConf is really, really great when you have a station, a computer,
talking to the device.
Remote procedure calls are not human-friendly at all. Okay, they're not.
And they're based on XML. Not human-friendly.
So RESTConf though is really good when you,
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.
RESTConf is good for humans. NetConf, great for machines. That's why the two.
So what I need you to know is what we're going to see on this page.
What we're going to talk about here. We have this protocol stack for NetConf and RESTConf.
Secure transportation, messages, operations, access to take, and content configuration and operational data.
So let's start off at the bottom here with secure transport.
NetConf using SSH.
So if we're using SSH,
what do we have?
Certificates, port 22, but by default it actually uses port 830.
Okay, so it's not actually using port 22 by default. It's using port 830, but SSH, certificates, things like that.
Whereas RESTConf, it's HTTPS.
So we'd be using SSLTLS because of HTTPS.
So therefore we need certificates.
So therefore we need certificates as well.
But what else do we need here for this to work?
We need a web server.
So if I am using RESTConf to connect to my device
from wherever,
I am the client, you are the server.
So who has to have the web server running? Me or the router?
The router has to have the web server running.
And so what we have is we have NGINX.
NGINX is our internal web server on our routers.
It acts as a proxy web server specifically.
And this is going to give us our TLS-based HTTP connections that we need
from whatever it is that's using RESTConf to connect to our router.
So when I was playing around here with Postman,
and I'm using HTTPS here,
I am using RESTConf for this.
Therefore the router has RESTConf running.
It has an HTTPS server running on it right now.
That's what it has for me to be able to do what I was doing.
And so my RESTConf request gets sent via HTTPS.
It's received by the NGINX proxy web server first.
And then the request is going to be transferred to the ConfD web server
that is running on my actual router.
So we have a ConfD web server running on the router,
but then we have a RESTConf request.
So we have a ConfD web server running on the router,
but the NGINX proxy web server is in front of it,
and it's the one that first checks the incoming connection.
And then, if everything is good there,
it passes it off to ConfD for further processing.
Pause a little bit longer for you,
because you want to take a screenshot of that,
or if you come back later, make sure you take a screenshot of that.
Post it on your wall in your office maybe.
All right, let's move on up the stack.
So now when it comes to messaging,
if they're talking about NetConf on the exam,
RPC, remote procedure calls.
RESTConf, REST APIs.
So since we're using RPC here,
and we're using REST APIs here,
that's going to have an effect on our operational actions.
So our operational actions,
you're going to see Get, GetConfig, EditConfig, CopyConfig, DeleteConfig,
Commit, Lock, Unlock, CloseSession, KillSession, right?
And then on RESTConf, because of REST APIs,
Head, Get, Post, Put, Patch, Delete.
Those are the verbs we talked about a while ago.
And then as we mentioned earlier,
when it comes to the content configuration
and operational data,
we got XML for NetConf,
and for RESTConf, we have,
we can do XML,
but definitely JSON is a better formatting
for that, for human beings.
So we have this concept of data stores now on our devices.
We have the RunningConfigDataStore,
the StartupConfigDataStore,
and the CandidateConfigDataStore.
So we're going to go ahead
and we have the RunningConfigDataStore,
the StartupConfigDataStore,
and the CandidateConfigDataStore.
And so when it comes to
software-defined networking devices
that are out there,
not all of them are going to have all these data stores,
because not all of them are going to need it.
But all devices need one of these.
All devices need one of these,
and that is the RunningConfigDataStore.
So this configuration data store
holds the complete configuration
currently active on the device.
So you can only have one
RunningConfigDataStore on your device,
and it has to always exist.
So if we went to our router,
and I said, hey,
I want to see the context
of the RunningConfigDataStore.
Show RunningConfig.
That's all it means.
So we're dealing with
the RunningConfig.
So it's the RunningConfigStore
in our RunningConfigDataStore.
So the StartupConfigurationDataStore,
what do you think that is, folks?
Well, it's where we store
a copy
of our configuration,
so that way there,
when the device boots,
that is the config that is loaded.
Now on older equipment,
show StartupConfig,
even modern equipment, right?
Show StartupConfig.
There's my StartupConfigDataStore.
So in the world of software-defined networking,
does every device need
a StartupConfigDataStore?
And the answer to that is no,
because think about a pure,
pure, pure software-defined
networking router or switch.
Who is always going to tell it
what its configuration is?
The controller.
So it doesn't have to store
its configuration at all,
because it's always being told
when it boots,
here's your config.
When it's running and things change,
the controller says,
here's your updated config.
And so it never needs
to store its own config.
So if you ever buy a product
that is purely, purely, purely
a true, true, true software-defined
networking device
that doesn't store anything on itself,
then it only has a running config.
It won't have a StartupConfig.
But Cisco devices have both.
Cisco devices will have a running config
and a StartupConfig.
And the reason why is because
if something happens to the controller
and it doesn't have anything on it,
so this is Cisco's idea
of fallback capabilities
and the ability to still survive
if your controller blows up on you,
which is nice to have.
And then what about
these candidate data stores?
What is that?
How many of you have Nexus products?
Anybody here have a Nexus product?
If you have a Nexus product,
when you do your configuration
and you hit Enter,
does it actually apply
in some way?
Or do you have to commit it later on?
You have to commit it later on.
So, iOS and iOS XE,
every time you hit Enter,
it applies your config.
It applies your config.
Well, with something like a Nexus product
running Nexus OS operating system,
when you do your configuration
and you hit Enter,
it doesn't apply it.
It stores it in a candidate data store.
And then when you commit,
then it takes everything
in the candidate data store
and puts it to the running config.
So, that's all that is.
Cisco iOS and iOS XE devices
don't have a candidate data store.
Nexus products do.
But those are the three
different data stores we have.
We could possibly have,
depending on the equipment.
So, you'll see here an example
of NetConf RPC call.
How do I know it's an RPC call?
It says right here in the header.
So, for example,
I want to get information
from the running config.
I want to get information
from the startup config.
You would specify that
in your actual call to the device.
So, the server is making
the call to the device.
This would be my call.
This would be the message
that's going from the server
to the device using NetConf.
So, in this case here,
it's an RPC call.
I want to get information
from the running config,
the data store.
And what do we want to get?
Well, we only want to get
information pertaining
to the YANG data model
called IETF interfaces.
There, now you can see it
in action right there.
I'm actually able to specify
that I only want information
from that store
pertaining to IETF interfaces.
And then we can take it even further.
Well, which interface do you want?
Right, if I didn't specify
interface here, name,
then it would just give me all interfaces.
But now I'm saying this specific
interface by its name.
Right, and then close it out.
So, there's just an example
of a type of RPC call
that you can make
to get the details that you want.
Now, how do we turn on
the configuration mode?
And you type in netconf yang.
And then netconf gets enabled.
Your device is using SSH,
then it becomes an SSH server.
So, that way there,
the controller can SSH to the device
and make the RPC calls that it needs.
So, netconf listens on any IP address
assigned to the system.
So, if your system has five different IP addresses,
netconf's running on all those IP addresses.
It's going to be port 830 by default,
as I said.
But you can change that port number.
If you want to use port 22, you can.
But 830 is the default.
And SSH automatically gets enabled
as soon as you type in netconf dash yang
because it can't work without SSH.
So, SSH automatically enabled.
You can have self-signed certificates
on your device.
You're going to use,
better in a production environment,
to use certificates from a certificate server,
your keying materials, stuff like that,
centralized, managed, all of that stuff.
So, that's the command.
That's the port number by default.
And we're using SSH.
All right, so let's shift our attention
over now to RESTconf.
So, with RESTconf, we're using URLs.
We're not using RPC calls.
So, we're using URLs.
We're using HTTP messages.
So, now that we know a little bit more
about YANG data models,
we're going to be able to see here
better information.
We're going to understand this URL a lot better,
this REST API call.
So, we got HTTPS,
as we talked about before,
for SSL TLS encryption.
You got the name of the server,
the port number the server is using.
So, depending on how you set it up,
right, default port 443,
then you'd be using 443.
But you actually have to specify
the name and the port number.
Okay, well, you don't have to specify
the port number if you are using 443,
because that's what HTTPS uses by default is 443.
But if you use a different port number,
then you have to specify it.
So, what about 1389?
Well, then you would specify the name
or the IP address followed by port 1389,
so that way their HTTPS is using 1389 instead.
All right, so you got to have
the right port number there
depending on what you're using on your actual device
that you're trying to contact.
Then root, so in this case,
we're using RESTconf,
so the root is actually RESTconf.
That's what it's going to be.
Your datastore, so is it the running config datastore,
startup config, whatever the datastore is.
So, what do we want?
Well, in this case, IETF interfaces,
but if we wanted a different YANG data model,
like I want the BGP or I want this information,
that information,
you're specifying it there in the actual title
or in the URL, I should say.
So, this is why when I was saying
every little tiny component of your device
technically now has its own API,
because if you're looking at it this way,
I could specify the YANG data model
and then therefore on my device
only now the IETF interfaces
are affected by this.
But then you specify the container
and therefore what is the container?
It's either this container or this container.
If I leave a blank,
then it's both containers
in that particular YANG module.
And then you have your leaf, right?
So, if I specify this, then I specify this.
If I specify this, then I specify this.
So, the leaf changes.
And then you have other options you can use,
other options that you can use for filtering.
For example, if I don't set a filter,
then it gives me all of this information back.
But if I set a filter, I could say
only give me name or only give me description
or only give me type.
I can control that.
So, earlier when I was using Postman,
that's what was happening.
So, if I say, let me close this without saving.
No, because I know I made some changes there.
Don't save.
All right, so pull all interfaces.
So, you'll see here,
oh, let's go back here.
All right, there is the URL.
IETF interfaces.
So, there is our module.
There is our container.
So, I'm saying just give me everything
in that container for that module.
Send.
There it is.
All right, let's go just interfaces state.
So, notice here, IETF interfaces,
interfaces state.
So, now I'm specifically saying,
hey, I only want that second container.
Send.
So, it's only going to return to me
the second container information.
So, what if I want to create,
as we saw earlier?
So, I want to create an interface.
So, IETF interfaces, the model,
the container,
then inside that particular container,
what is the interface I want to create?
So, that is now the actual interface,
and then my extra option.
So, that would be the option.
I want to call it loopback 150.
So, then when I click send,
I have included right now,
so far, right?
So, I specified this,
I specified this, I specified this,
I specified this,
but you got to go into the body as well now
because I'm putting, right?
What information are we going to apply here?
And then which one of those
are going to be empty?
So, if I open this up,
so the name is loopback,
description, type, enabled,
IP address and mask.
So, do I have to fill everything in?
No, if I don't fill stuff in,
then it goes to the default value
on that platform,
the default value on that platform.
So, let's go back to here
and say I want loopback 150.
Oh, there it is.
So, in this case,
so when you think about it,
when I created the interface,
interface loopback 150,
I didn't provide all the values.
What did we provide?
The name, the description,
the type, true and the IP address, right?
That's what we provided,
but there are other details there.
So, if we want to get the interface state
as an example,
see if I can do this right now.
Interface, interface-state,
I believe it is.
No, I don't have that.
That's a 404 that I've found.
I got to double check on that.
I got to look that up.
What is it going to be?
Interface-state, that should work.
No, interfaces-state under
IETF interfaces.
Oh, the wrong spot.
That's what I did wrong.
Interfaces-state,
and then this is
interface.
There you go.
So, you can see that
even though we had default values for the interface,
well, here's other information about it.
So, if you don't put specific things in
on other aspects,
look, it randomly picked eight
for my interface index number
because I didn't supply one.
So, that's all I'm trying to show you right now
is that this ensures that
whether I'm on a Cisco device,
an HP device, it doesn't matter.
I can put in the information I need here
for it.
So, for example,
if it was a HP device in my environment
or a Juniper device in my environment,
then all I have to do is make sure
I put in the correct name,
the correct port,
and then
this would all be the same,
and then this would just be
the interface name and number
on that device,
and then I can get the output I need,
and it would be this stuff,
the same stuff with just the outputs
pertaining to that device.
See the consistency now?
When compared to trying to learn
the CLI of every device
that exists out there,
that's why this is happening.
HTTPS is needed for Rescoff
on iOS XE.
Port 443
is used by default.
You turn on the HTTPS server
by typing in IP HTTP secure server.
Therefore, it listens,
the web server listens on any IP address
assigned to the system,
and then you enable Rescoff
by just typing in rescoff.
That's it.
And then you can start using
REST API calls to your device.
It's incredible.
It really is.