So friends, let's talk about the NetConf protocol.
Now before we actually begin talking about what NetConf actually is,
let's first talk about where it actually came from.
So you might be familiar with a particular protocol known as SNMP,
the Simple Network Management Protocol.
And in many respects, this was the catalyst for the development of NetConf,
so what exactly am I talking about?
Well, with respect to SNMP,
the way it was initially designed was to actually be able to pull back WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the way it was initially designed was to actually be able to pull back
operational state data.
So that would be things like, you know,
do you have any errors on your interface?
Are your OSPF adjacencies in the full state pretty much the type of things we
get
via our regular CLI show commands?
So state data was the first component of SNMP,
but the other component was also having the ability to make configuration
changes.
Now, if you happen to work with SNMP in any real capacity,
you'll know that this part here is largely ignored.
We mostly use SNMP to ultimately monitor the state of our environment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We mostly use SNMP to ultimately monitor the state of our environment.
So you know, you might configure SNMP to have particular traps
and then send alerts, maybe if an interface goes down that type of thing,
once again, this is all about monitoring the state of the network,
not actually making configuration changes.
Now, I don't want to go into all the details about why SNMP kind of failed for
configuration changes.
Basically, it really just was kind of awkward.
You know, it wasn't intuitive and it never really got off the ground.
All right, so we have this protocol that was designed for state monitoring WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, so we have this protocol that was designed for state monitoring
as well as configuration changes, but it doesn't really make any type of
network configuration changes.
So what can you imagine the solution would be?
Well, if you happen to think that the development of a protocol that could
actually handle
the configuration portion of the network,
well, you would kind of be on the right track.
This is what Nikconn was really designed to handle.
Now, first things first, let me just plan to flag right here.
I don't want you to get to the wrong end of the stick.
Just because the protocol is called Nikconn, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Just because the protocol is called Nikconn,
it's not just about network configuration.
Nikconn is also capable of managing state data,
so retrieving the information about the current configuration of our network,
not just making those changes, but no doubt one of the primary drivers of Nik
conn
was its ability to make configuration changes.
So let's talk about how it actually does this task.
Okay, so let's imagine we have a little router over here,
and here I am on my little laptop.
Now, if I wanted to remotely manage this particular router, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, if I wanted to remotely manage this particular router,
what I could do is I could use SSH,
and I could go in and make configuration changes directly via the CLI,
you know, typing things like router OSPF1, that type of stuff.
Now, notice this portion right here, SSH.
The reason why we use this protocol is because it is indeed secure.
It wraps the whole communication in encryption.
Here's the thing, SSH is very, very commonly used.
Everyone pretty much has some experience with it.
So the thought process behind Nikconn
at the time of its development was why not make use of this particular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at the time of its development was why not make use of this particular
transport.
So instead of sending CLI commands down the SSH channel,
we ultimately send something called RPCs.
These are remote procedure calls.
Now, we'll talk about this in a little bit more detail very, very shortly.
But the first thing to focus in on is this communication channel right here,
SSH. Now, typically, your regular SSH is going to be connecting over a default
port of 22,
but with Nikconn, it actually is a little bit different.
The default SSH port is 830. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The default SSH port is 830.
Now, one of the things to note about SSH is that it allows us to maintain a
stateful connection.
So this is one of the advantages, compared to say HTTP.
Remember when we used Resconn, it was stateless.
In the case of Nikconn, the connection is stateful.
So once again, let's imagine here I am here on my laptop and I want to make a
remote connection
to the router here over Nikconn.
So this is going to be SSH 830.
Because the connection is stateful, it means the connection can be maintained. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Because the connection is stateful, it means the connection can be maintained.
So we open up the connection to this device here.
We then send some configurations down.
And then because we have this stateful connection,
what we can then do is ultimately send a commit message.
If you happen to have experience with Cisco's iOS XR platform,
or maybe say for example, Juniper devices, you will actually understand what
this commit is all about.
But in case you haven't worked with these devices, then let me just describe to
you what is going on here.
So the thing is, with Nikconn, we actually have different data stores, okay? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the thing is, with Nikconn, we actually have different data stores, okay?
Let me tell you what they are.
So the first data store we have is what is known as the startup data store.
Now pretty much this data store stores these startup configurations.
So kind of like when you go on your regular CLI and you type the command "Copy
Run Start",
you are saving the running configuration into the startup data store.
So if you happen to reboot the device, your configurations that you just saved
are going to be persistent.
Now the next data store we have in Nikconn is what is known as the running data
store.
This is just like when you type the command "Show Running Configuration" WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is just like when you type the command "Show Running Configuration"
and you see the actual live running config.
This is the data store that contains that particular information.
So these ones are pretty intuitive.
But Nikconn also brings a third data store here, okay?
And this one is known as the candidate data store.
So this one here might be a little bit more confusing and this is what we're
talking about
with respect to our commit operations.
What you can do with the candidate data store is you can make changes to the
configuration of your device.
But the configurations are quite simply not going to take effect. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But the configurations are quite simply not going to take effect.
They're just going to lie in this candidate data store waiting to go live and
they will not go live
until you specify that you want to commit them into the running data store.
So why would we ever want to do such a thing?
Well let's imagine we have some routers here, okay?
And we're going to manage them via Nikconn.
So here we are over here.
So with Nikconn, what we can do is we can open up a connection to all these
devices, as so.
And then we can begin pushing down all the configurations that we want to these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then we can begin pushing down all the configurations that we want to these
devices, okay?
Now if we specify in our Nikconn configuration that we only want to target the
candidate data store
of all these devices, then once our configurations have been pushed, nothing is
actually going to happen
to these devices. So no changes are going to be applied.
The running configurations of all these devices are still going to be remained
untouched.
The difference here is that once we have sent all of our configurations and
were now happy for
the changes to take effect, we can effectively make them take effect all at
once by sending a commit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
message to all of these devices at the same time. And then all of the changes
that have been pushed
into the candidate data store of all these devices are then copied into the
running data store
and then take effect on the live configurations. So as opposed to pushing
configuration changes,
one by one by one, as each line happens to be applied, we can effectively send
a bulk configurations,
let them lie dormant until we're ready and then flip the switch and they all go
live at the very same
time. So this is one of the benefits about how Nikconn can actually manage WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
time. So this is one of the benefits about how Nikconn can actually manage
configuration changes.
It's very, very good at this particular task. Now one thing to state about Nik
conn is that the data
we're actually sending is once again going to be a young model. This is
actually mandatory. This
is something we have to do very, very similar to what we saw with Resconn. The
difference though,
if you recall, with Resconn, we had the ability for JSON encoding as well as
XML with Nikconn.
Unfortunately, it's all going to be XML encoders. We're going to be using our
opening tags as well WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
opening tags as well
as our closing tags. So you know, this isn't the worst thing in the world. XML
is fairly human-readable,
but for me, it just isn't quite as good so there are some limitations. And
quite honestly, people do
complain when you first begin using Nikconn, it can be a little bit daunting
and it can be a little
bit confusing. This is unfortunately something that everyone just kind of
struggles with at first.
It takes a little bit of time just to get used to what you're doing. So pretty
much what I'm saying is
don't beat yourself up if you find this a little bit confusing the first time
you see it. Now, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
you see it. Now,
finally, remember I happen to mention this thing about an RPC, a remote
procedure call. Let me just
talk a little bit more about that. So pretty much, the RPC is kind of like the
instruction that we
are sending to the device. So what kind of instructions could we actually send
to that device? Well,
let's imagine once again, finally, we have our router here and let's say we
have a little laptop.
Let's imagine I wanted to get the state of my network, but what I could do is I
could send what is
known as a getRPC. And quite simply, we would then get the state and the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
known as a getRPC. And quite simply, we would then get the state and the
configuration information
from that particular device. So this would be one RPC. Now, another RPC we
could send, which is very,
very similar as one known as a get-hiphon-config RPC. Now, this might be a
little bit confusing at first,
but actually is quite important. When we happen to send a regular getRPC, we're
getting both state data
and configuration data. So that will be things like we have actually configured
. So if we happen to
configure things like router OSPF1 on the device, this is configuration data we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
configure things like router OSPF1 on the device, this is configuration data we
have actually
since. And when we send a get request, we get this type of config data, but we
also get the
operational data such as interface statistics. How many errors have been seen
on a particular
interface? How many unicast packets? How many broadcasts? That type of thing.
So the get-config
RPC allows us to cleanly separate out configuration data and state data. If we
just want to get the
config such as, you know, the router OSPF1 configuration we sent, then we could WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
config such as, you know, the router OSPF1 configuration we sent, then we could
send this information.
If we want to get more general information, we can send the get request to
essentially get both
state and config. So we have the getRPC, the get-config RPC. The next RPC we
can get is the edit
config RPC. As you can imagine, this one is used to actually make configuration
changes to edit a
particular data store. So imagine we wanted to add a new network statement
within our OSPF configuration
that would require an edit of the config. Therefore, we will send the edit WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that would require an edit of the config. Therefore, we will send the edit
config RPC. Now if we wanted
to delete a particular configuration, what we could then send would be a delete
config RPC. So say,
for example, you wanted to delete a description on a particular interface. Well
, you could send
that particular RPC to do that particular task. And we also have the copyconfig
RPC, which allows
us to essentially copy configurations across different data stores. So if you
want to copy the
configuration from the running data store into the startup data store, you
could send a copy
config. So I know that was a lot of theory and overview to get us going. Now we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
config. So I know that was a lot of theory and overview to get us going. Now we
have a rough idea
about how this weird Nikcon thing actually does operate. Let's now get hands on
and begin making
in some requests to order the base.