Introduction

The Network Configuration Protocol (NETCONF) is a filtering-capable XML-based protocol for network
management. It offers fully programmable means of controlling and configuring the operation of networking
equipment. You can set the device parameters, get the parameter values, and obtain statistical information
using it. Furthermore, it shortens the time allotted for managing the setup of network devices. In this case,
rather than manually configuring everything, NETCONF does automatically.

What is NETCONF?
NETCONF is a network management protocol that uses a simple remote procedure call (RPC) mechanism to
interact with network devices. It is designed to work with the Simple Network Management Protocol
(SNMP) and uses an Extensible Markup Language (XML) data encoding format. It allows network
administrators to configure, monitor, and troubleshoot network devices remotely, making it a valuable tool
for managing large and complex networks.

• It is used to connect with the device securely to do the configurations and fetch the operational data.
• It does not define the data format; this responsibility was taken up by YANG (Yet Another Next Generation)
data modelling language, which was described by IETF.
• It does the transportation using an SSH connection on port number 830.

In a setup like the one shown above, tools like Ansible and Python can be used on Management PC to
configure routers through Network Configuration Protocol. The two required things on the router will be the
SSH configurations and enabling the NETCONF. The Data Structuring Language used by the Network
Configuration Protocol is XML (Extensible Markup Language), meaning the payload you want to push on
the device should be in XML format.

NETCONF History

NETCONF was introduced to address the limitations of SNMP and CLI. Netconf base protocol was first
introduced in late 2006 as an RFC 4741 NETCONF Configuration Protocol by NETCONF working groups.
In 2011, the revised version was published as RFC 6241, and today it’s the most current version. Several
RFCs have been published by Internet Engineering Task Force (IETF).

Some of the supporting RFCs published by IETF are:

• RFC 4742
• RFC 4743
• RFC 5539

The RFCs, as mentioned above, were updated in 2011 and became:

• RFC 6241 (old version 4741)

• RFC 6242 (old version 4742)

Let's move on and understand why we needed this protocol in the first place.

Why Network Configuration Protocol (NETCONF) vs. Other Approaches

Back in 2002, when the IAB (Internet Architecture Board) and IETF (Internet Engineering Task Force) set
up a workshop with network operators to address the concerns of network operators on issues related to
network management, they realized that the industry was extensively dependent upon the SNMP (Simple
Network Management Protocol) for the network management. SNMP is a great protocol when it comes to
monitoring the devices, especially when the information is limited. But SNMP wasn’t good enough to be
used for configuration purposes. Some of the requirements that operators listed that they wanted were:

• Easy to use technology.

• Clear differentiation between configuration and operational data.
• Compatibility with extensive network services (like VPNs and IPTV)
• In the event of failure, configuration transactions, and simple rollback should be supported.
• Standardized representation of configurations between different vendors.

Network Configuration Protocol was the output that fulfilled the requirements mentioned above.

How does NETCONF works?

It includes at least one network management system (NMS) that manages network devices. The following
diagram depicts Network Configuration Protocol's fundamental network architecture.
There are two main parts to the NETCONF framework: the client and the server.

The following are some of the services that a client may offer:

• Uses Network Configuration Protocol to control network hardware.

• To get information about or change the value of a parameter, RPC requests are sent to a NETCONF server.
• Recognizes a controlled device's state from the alarms and events sent by the device's NETCONF server.

A Network Configuration Protocol client will send a request to the server, which will then analyse the
request before responding to the client.

• The NETCONF server receives a request from a NETCONF client, analyses the request, and returns a response
to the client.
• Whenever a problem or other event occurs on a managed device, the Network Configuration Protocol server
will use the notification mechanism to deliver an alert or event to the client.

NETCONF Structure

As can be seen in the illustration, Network Configuration Protocol may be conceptually divided into four
layers.
 1. The Secure Transport layer ensures that NETCONF messages are reliably delivered and in the correct
sequence. SSH is one example of a secure transport protocol that may be used to comply with it. Required
functionality includes NETCONF via SSH support.
2. The Network Configuration Protocol requests and replies are formatted using an RPC-like communication
model supplied by the Messages layer, which rides on top of the Secure Transport layer to provide a secure
and stable connection. Data is gathered from the network and organized into NETCONF messages in order to
be transmitted up to the Operations layer. The Operations layer frames RPCs for transmission to the Secure
Transport layer in the network’s transmit direction.
3. The Operations layer supplies the collection of management primitives needed to access and alter NE
information. Its operations are defined in the operation layer.
4. NE data is represented by YANG modules and stored in the Content layer. YANG modules create a clean
separation between NE configuration data and NE operational data, making administration much simpler.

Before we discuss the abilities of Network Configuration Protocol, let’s quickly understand the difference
between Configurational and Operational data. Everything which you can write on a device is configuration
data, for example, interface state and the IP address assigned to the interface; on the other hand, Operational
data, also known as read-only status data, is non-configurational, for example, the number of packets that
were dropped, number of packets sent or received, or overall interface traffic statistics.

NETCONF Operations

It provides a set of operations that can be used to manage the device (depending on the NETCONF
compatibility of the device.). Actions are performed upon the network device (and its data stores) via a set of
operations.

Let’s understand these operations one by one.

<get> To fetch operational data from the device.

<get-config> To fetch the configurational data from the device.

<edit-config> To push/load configuration on the device.

<copy-config> To replace a set of configurations with new configurations.

<delete-config> To delete a set of configurations.

<commit> To copy the candidate configurations to running configurations.

<lock>/<unlock> To lock or unlock the configurations.

<close-session> To close the session.

<kill-session> To forcefully terminate the session.

The operation <edit-config> can be used with different attributes based on the requirement. The several
supported attributes are:

• Merge: This is the default attribute used by the operation and is used to merge the configurations with the
pre-existing configurations.
• Replace: This is used to replace the whole set of configurations with new ones.
 • Create: The attribute create is used to add the configuration data only if the configuration data doesn’t exist
on the device. If it exists, then an error message is returned.
• Delete: When this attribute has been used, the defined configuration set is deleted from the device.

Key NETCONF Capabilities

NETCONF is a network management protocol that provides several key capabilities for configuring and
monitoring network devices. Some of these capabilities are:

• The ability to edit and validate device configuration data in a structured and consistent way, using XML or
JSON encoding and YANG data models.
• The ability to retrieve operational state data from devices, such as interface statistics, routing tables, or
device status.
• The ability to invoke remote procedure calls (RPCs) on devices, such as rebooting, testing, or applying
changes.
• The ability to subscribe to notifications from devices, such as alarms, events, or telemetry data.
• The ability to use secure transport protocols, such as SSH or TLS, for authentication and encryption of
Network Configuration Protocol messages.

Why do we call NETCONF a part of Model Driven Programmability?

NETCONF is a Model Driven Programmability method as it works according to the rules defined in data
models written in YANG. Let’s get deeper into how these data models are used. For example, let’s consider a
data model for describing the information related to a person.

Gender – Male/Female/Other

Height – Feet/Inches/Meters/Centimetres

Weight – Kilograms/Pounds

Name – Maximum 15 Alphabets allowed

Contact Number – Only numbers are allowed

By using this data model for collecting information from a group of people, I can ensure that I am collecting
only valid data. Similarly, it uses Data Models to ensure that the appropriate data hierarchy is there. YANG
data models provide a clear and concise structure through modules and submodules, which can be used to
manage devices.

If the request made by the client is successfully validated, then the server processes the request and returns a
response to the client in the form of another XML message. The response may contain the information
requested by the client or a status message indicating the result of the operation.