NETCONF tutorial

Network Configuration Protocol (NETCONF), like the traditional CLI mode and SNMP, is a network device management protocol. It provides a mechanism for configuring devices and querying the network configuration and status. So why should we use NETCONF instead of CLI? The main reason is: NETCONF is ideal for network automation and cloud-based networks.

The traditional CLI mode is designed to be used by humans and based on man-machine interfaces. The CLI provides humans with a very user-friendly means for interacting with a device. Commands are very readable, easy to remember and have no painful syntactic requirements. But the configuration varies with vendors. The same command is implemented in different ways on different devices and on different vendors. Therefore, the manual learning and maintaining cost is high.

Fortunately, the industry finally realized standardized data models and configuration protocols were needed. So, the IETF developed NETCONF and Yet Another Next Generation (YANG) data modeling language to add structure, interoperability, and control to the chaotic configuration environment.

NETCONF, on the other hand, was designed for automation applications. It uses a clearly defined XML API that computer programs can understand easily. Similar to SNMP that uses MIB files to model data, NETCONF uses YANG to describe the interaction models between the NETCONF client and server.

By following YANG models, configuration engineers can use a graphical application to generate configurations for different devices of different vendors with ease. Engineers do not need to pay attention to the differences between YANG models as well. The graphical application automatically parses the YANG model data, shifting the focus of engineers from device and function differences to user requirements.

Another advantage of NETCONF is that it allows configuration to occur in a transactional manner (backup and restore capability). NETCONF takes into account when some of the network devices successfully upload the configuration, but others fail to upload the configuration. In this case, NETCONF allows a managed device to rollback to a known-state configuration. This is because NETCONF defines transactional models that synchronize, validate, and commit device configuration within an entire network deployment.

NETCONF can be conceptually partitioned into four layers:

– Layer 1: The transport protocol layer provides a communication path between the client and server. NETCONF can be layered over any transport protocol that provides a set of basic requirements.
– Layer 2: The Remote Procedure Calls (RPC) layer provides a simple, transport-independent framing mechanism for encoding RPCs. RPC is a kind of request-response protocol. An RPC is initiated by the client, which sends a request message to a known remote server to execute a specified procedure with supplied parameters. The remote server sends a response to the client, and the application continues its process. ALL NETCONF messages are encoded in XML.
– Layer 3: The operations layer defines a set of base operations invoked as RPC methods with XML-encoded parameters.
– Layer 4: The content layer did not provided a standard for content layer in the RFC. In 2008 and 2009 a NETMOD working group came up with YANG. YANG at the Content layer is used to provide the “human readable” format. YANG is a data modeling language used to model configuration and state data manipulated by NETCONF, NETCONF remote procedure calls, and NETCONF notifications.

How NETCONF works?

In below graphic, you can see that a NETCONF manager (usually our SSH client) communicates with a NETCONF server (usually the network device at hand). They exchange capabilities to understand what features are supported. Using Remote Procedure Call (RPC) calls, the SSH client can then retrieve information from the SSH server. The support of SSH is considered mandatory for NETCONF implementations.

NETCONF Transport

NETCONF messages are encoded in XML. Each message is framed by:
– NETCONF 1.0: a character sequence ]]>]]>
– NETCONF 1.1: a line with the number of characters to read in ASCII
– NETCONF messages are encrypted by SSH.
– NETCONF over SOAP, BEEP (both now deprecated) and TLS are also defined, but not used SSH provides authentication, integrity and confidentiality.
– NETCONF is connected oriented using TCP.
– No need for manager to request resends
– Efficient use of the medium

NETCONF Data stores

NETCONF utilizes multiple configuration data stores (candidate, running, startup) but “running” is the only mandatory data store. Each data store may hold an entire copy of the configuration. Not all data stores are supported by all devices. Not all device’s are writable -> May have to copy from writable one.

Note: Every NETCONF message must target a data store.

NETCONF Operations

NETCONF protocol is based on XML messages exchanged via SSH protocol using TCP port 830 (default). Network devices running a NETCONF agent can be managed through these operations:

In the next page we will learn some examples of NETCONF operations.