NETCONF Overview and Concepts

In this lesson we’ll be going over NETCONF concepts. We talked about NETCONF very briefly in a previous lesson, but in this lesson we’re going to take a much deeper dive into the NETCONF protocol. We’re going to enable NETCONF on our router, and we’re going to take a look at what starting a NETCONF session looks like.

NETCONF is a standards-based protocol. This was not developed by Juniper, it is an RFC standard, defined in RFC 6241 and it is implemented by many different network device vendors out there. It is called NETCONF as it is the Network Configuration protocol. NETCONF was designed with different protocol layers.

As shown in the diagram above, it has the transport layer, messages layer, operations layer and content layer. Our transport layer contains the transport protocol that it’s using to communicate. These are protocols like SSH or HTTP/TLS. We won’t be covering the transport protocols in detail here as they are their own protocols.

Our messages layer includes the <rpc> tag, the <rpc-reply> tag and the <notification> tag. This is defining what our NETCONF message is actually containing, whether it’s an RPC call, or an RPC reply or a notification message that’s being sent by the NETCONF server. The <rpc> element encapsulates all RPCs to the NETCONF server. So this is the client -> server message, where the server in this case is your router, your switch or your network device.

That’s the terminology, that NETCONF is using and the <rpc> element, which includes both operational mode RPCs and configuration RPCs. Recall from our previous lesson that we have RPCs which are XML tag Remote Procedure Calls. They can get operational mode information, or we can apply some configuration with our RPC as well.

The other possible element is <rpc-reply>. So this XML element encapsulates all RPC replies from the NETCONF server. This is a server -> client message.

This includes data retrieved from any configuration or error messages, all information coming back from our RPC server in response to an RPC. The last response element from the server is the <notification> element.

Notification elements are sent to a client who initiated a subscription. So you, as the client, your device needs to subscribe to some events from your NETCONF server. Anytime events matching your subscription are created, they are sent to your client via notification messages. We create a subscription using the <create-subscription> element.

All of these are XML element tags. We go much deeper into XML in a later lesson, as well as talk about the structure of XML, but right now it’s just important to know that the words encapsulated by the angle brackets, like <rcp>, are XML element tags.

Further up in the layer stack, here we have the operations layer. This is where we have our different operations, like <get-config> or <edit-config>. Our <commit-config> command and other RPCs are available in the operations layer as well.

Some other important RPCs to know that exist in this layer are the <lock-config> and <unlock-config>. This would be for doing edit exclusive and then releasing the configuration database by exiting configuration mode, if we were at the CLI. In the operations layer we also can create our subscription to receive the <notification> messages described above. We also have <close-session> and <kill-session> when we want to close our own NETCONF session, or kill some other user session respectively. Perhaps there’s a stuck session on our device, and we need to end that session.

These commands can differ from network vendor to network vendor, the ones listed are specifically Juniper NETCONF operations layer commands.

Moving right on up here to finally the content layer. Now, this just contains the payload of the request or response. If you are doing some configuration and applying a configuration to your device, this content layer will have that configuration to be applied inside of it. If you are getting some configuration or getting some operational mode information from your device, our content layer is going to include that information in it.

In order to use NETCONF on our Junos device, we actually need to enable it. It’s a pretty simple command, in the [edit system services] hierarchy, we do set netconf ssh to enable NETCONF over SSH. That is a required statement here and NETCONF uses TCP port 830 by default.

Definitely make sure that you remember for the JNCIA-DevOps exam that it uses TCP port 830 by default for ‘NETCONF over SSH’. This is configurable, so that you can change that port number if you wish.

NETCONF is now enabled on your device and you can use NETCONF to communicate. This will use SSH authentication if you’re doing it remotely, so you will need to log into your device using SSH authentication. That is configured for either using local usernames and passwords or some external authentication server like a RADIUS or TACACS server. More detail about initial configuration in the JNCIA-Junos lesson.

Let’s take a look at what a netconf session actually looks like. When you’re at the operational mode prompt and you enter the netconf command it will open a NETCONF session for you, and this is the type of output that you will end up seeing for opening that NETCONF session.

The important item to point out here is that the last characters, the ]]>]]> is an indicator for the end of the NETCONF message.

We can see the initial session opening includes the permissions that were used to open the NETCONF session, and that the user ben opened the NETCONF session. If your user class only has specific commands available, then you may not be able to run everything via NETCONF, only the things that are available to you will be allowed over NETCONF as well.

For a full Lab demonstration, please watch the lesson video below!