Partner Community Techplayon Codeplayon Telcosought
Network Protocols

NETCONF: a NETwork CONFiguration protocol

ByAdmin

Jan 13, 2023
Table of Contents show

NETCONF (Network Configuration Protocol) is a network management protocol that enables programmatic configuration of network devices. It is a standard protocol defined by the IETF (Internet Engineering Task Force) and is mainly used to configure and manage routers, switches, and other network devices. In this blog post, we will discuss the basics of NETCONF, its features, and how it can be used to manage network devices.

NETCONF is a remote management protocol that uses an XML data model to represent the configuration of a device. The protocol defines a set of operations that can be used to retrieve, modify, and delete configuration data on a device.

History of Netconf network protocol

NETCONF, the Network Configuration Protocol, was officially released as a standard in 2006 with the publication of RFC 4741. Further it is defined in various RFC’s like:

  • RFC 4742, which covers the use of NETCONF over Secure SHell (SSH)
  • RFC 4743, which covers the use of NETCONF over the Simple Object Access Protocol
  • RFC 5539, which covers the use of NETCONF over Transport Layer Security (TLS).

    These versions were later updated in 2011 and became:
  • RFC 6241, which obsoletes RFC 4741 with a small set of changes
  • RFC 6242, which obsoletes RFC 4742 and introduces new features such as a new framing mechanism to address potential security issues with the initial design.
  • RFC 5277, which describes an asynchronous notification mechanism allowing clients to subscribe to named event streams
  • RFC 6243, which describes an extension to the NETCONF protocol that allows clients to identify how defaults are processed by the server.

Capabilities of Netconf network protocol

NETCONF capabilities are a way for the NETCONF client and server to advertise and negotiate the features and functionalities that they support. They are defined in YANG models and are identified by unique URIs (Uniform Resource Identifiers) that are included in the “hello” message exchanged between the client and server during the initial connection.

NETCONF capabilities are divided into two main categories:

  • Base capabilities: These are the capabilities that are required for all NETCONF implementations and are defined in the NETCONF base specification (RFC 6241). Examples include the “urn:ietf:params:netconf:base:1.0” capability, which indicates support for the NETCONF base protocol, and the “urn:ietf:params:netconf:capability:writable-running:1.0” capability, which indicates support for the “writable-running” feature.
  • Vendor-specific capabilities: These are capabilities that are specific to a particular vendor or device and are defined in vendor-specific YANG models. Examples include “urn:example:top” and “urn:example:interfaces” which are custom capabilities that are specific to that vendor.

NETCONF capabilities can provide a wide range of functionalities such as:

  • Support for different transport protocols, such as SSH, SOAP, and TLS.
  • Support for different types of data stores, such as the running, candidate, and startup configurations.
  • Support for different types of data models, such as YANG, YIN, and JS.
  • Support for different types of operations, such as “get-config”, “edit-config”, and “lock”.
  • Support for different types of notifications, such as “netconf-session-start” and “netconf-session-end”.
  • Support for different types of security features, such as authentication and encryption.

Communication steps of Netconf

The steps for NETCONF communication between a client and a server can be summarized as follows:

  1. The NETCONF client establishes a secure transport connection with the NETCONF server. This is typically done using SSH, SOAP or Transport Layer Security (TLS) over port 830. The client and server authenticate each other using the same mechanisms used in the underlying transport.
  2. “Hello” message exchange:
    • The NETCONF client sends a “hello” message to the server, which includes a list of the YANG models it supports i.e. the information about the client’s capabilities and supported NETCONF version.
    • The server responds with its own “hello” message, which includes a list of the YANG models it supports i.e. the information about the server’s capabilities and supported NETCONF version.

      This allows the client and server to determine which models are supported by both and to use those models to encode and decode the messages exchanged between them.
  3. The NETCONF client and server now have a session established, and the client can start sending RPC requests to the server. These requests are typically encoded in XML and include the operation to be performed, as well as any necessary parameters.
  4. The NETCONF server processes the RPC request, performs the requested operation, and sends the results back to the client in the form of an XML-encoded response.
  5. The NETCONF client can continue to send RPC requests to the server, and the server will continue to process and respond to them as long as the session is active.
  6. Once the NETCONF client is finished with its operations, it sends a “close-session” request to the server and the session is closed.
a network configuration protocol i.e. netconf is used to configured network devices

“RPC” stands for “Remote Procedure Call“. In the context of NETCONF, an RPC is a request that is sent from a NETCONF client to a NETCONF server, asking the server to perform a specific operation or set of operations. The NETCONF server will then respond with the results of the requested operation(s).

RPCs in NETCONF are defined using the YANG (RFC 6020) data modeling language. YANG is used to model the configuration and state data for NETCONF, as well as to define the operations that can be performed on the data. Each operation is defined as an RPC in the YANG model.

It’s important to note that the NETCONF protocol also includes a feature called “subscription” which allows a client to subscribe to notifications of changes to a device’s configuration. This way the server can send notifications to the client without the client requesting them.

Netconf Base Operations

The NETCONF protocol defines a set of base operations that can be used to retrieve, modify, and delete configuration data on a device. These operations are defined in the NETCONF protocol and are used to manipulate the device’s configuration data. The most basic operations include:

  1. “get” : This operation is used to retrieve the current configuration of a device. It can be used to retrieve the entire configuration or only a specific part of it. The response from the server will be in the form of an XML-encoded message that contains the requested configuration data.
  2. “get-config” : This operation is used to retrieve the configuration data from a specified source, such as the running configuration or the startup configuration of a device. The response from the server will be in the form of an XML-encoded message that contains the requested configuration data.
  3. “edit-config” : This operation is used to modify the configuration of a device. It can be used to add, modify, or delete configuration data. The request from the client will be in the form of an XML-encoded message that contains the new configuration data.
  4. “copy-config” : This operation is used to copy the configuration data from one source to another. It can be used to copy data between different parts of the configuration, such as from the running configuration to the startup configuration.
  5. “delete-config” : This operation is used to delete a specific part of the configuration from a device. It can be used to delete an entire configuration or only a specific part of it.
  6. “lock” : This operation is used to lock the configuration of a device to prevent other users or systems from making changes to it.
  7. “unlock” : This operation is used to release a lock on the configuration of a device.
  8. “commit” : This operation is used to apply changes made to the device’s candidate configuration to the running configuration.
  9. “discard-changes” : This operation is used to discard changes made to the device’s candidate configuration without applying them to the running configuration.
  10. “validate” : This operation is used to check the syntax and semantics of a configuration data against the device’s YANG model.

These are the base operations provided by NETCONF, they are the foundation to configure and manage network devices, however, it’s important to note that not all devices support all the operations and it also depends on the YANG models supported by the device.

Example of communication step of get-config in Netconf

Below is an example of a “get-config” operation between a NETCONF client and server:

  1. The NETCONF client establishes a secure transport connection with the NETCONF server using SSH or TLS.
  2. The client sends a “get-config” RPC request to the server, encoded in XML. The request includes the source of the configuration data, such as the running or startup configuration, and the filter criteria to retrieve a specific part of the configuration:
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source>
      <running/>
    </source>
    <filter type="subtree">
      <top xmlns="urn:example:top">
        <interfaces>
          <interface>
            <name>eth0</name>
          </interface>
        </interfaces>
      </top>
    </filter>
  </get-config>
</rpc>
  1. The NETCONF server processes the request, and retrieves the requested configuration data from the running configuration.
  2. The server sends a response to the client, encoded in XML, that contains the requested configuration data:
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <data>
    <top xmlns="urn:example:top">
      <interfaces>
        <interface>
          <name>eth0</name>
          <description>Ethernet Interface 0</description>
          <ip-address>192.168.1.1</ip-address>
          <subnet-mask>255.255.255.0</subnet-mask>
        </interface>
      </interfaces>
    </top>
  </data>
</rpc-reply>

It’s important to note that the example is a simplified version of what a get-config operation would look like in practice and it also depends on the YANG models supported by the device. The filter criteria, the XML namespace and the structure of the response may vary depending on the specific device and the YANG models it supports.

Also, this example uses the “subtree” filter type, but there are other filter types such as “xpath” and “xslt” which can be used to retrieve a specific part of the configuration.

The NETCONF protocol is widely supported by most of the major network equipment vendors and it is becoming increasingly popular as a way to automate network configuration and management tasks. However, it has some limitations too, such as its complexity and the need for a deep understanding of YANG data modeling language to effectively use it.

Conclusion

NETCONF is a powerful protocol that enables programmatic configuration and management of network devices and it is based on the client-server model. It uses an Extensible Markup Language (XML) encoding for its messages and YANG data modeling language to define the data structures, operations, and constraints that are used to configure and manage network devices. It has a set of base operations such as get-config, edit-config, copy-config, delete-config, lock, unlock and is widely supported by most of the major network equipment vendors. However, it has some limitations too, such as its complexity and the need for a deep understanding of YANG data modeling language to effectively use it.

One thought on “NETCONF: a NETwork CONFiguration protocol”

Comments are closed.