An Introduction to NETCONF/YANG

Table of Contents

TL;DR

NETCONF/YANG provides a standardized way to programmatically update and modify the configuration of a network device. To break this down further. YANG is the modelling language that describes the configuration changes. Whereas NETCONF is the protocol that applies the changes to the relevant datastore (i.e running, saved etc) upon the device.

Introduction

Let us start with the problem. Historically, the main method of configuring a networking device had been via the CLI or in some cases SNMP. However these methods presented a number of issues. Such as:

CLI disadvantages,

The CLI INPUT (commands) differs from vendor to vendor.
The CLI OUTPUT from each vendor differs. Requiring separate parsing logic for each vendor.
The CLI structure and syntax are prone to changes. Making our CLI scripts fragile.

SNMP disadvantages,

Unreliable as it inherently uses UDP as its transport protocol.
Traditionally insecure. Though SNMPv3 looks to address this, it still comes with its own security challenges. Mainly being the discovery messages used to negotiate the authentication and encryption keys are neither authenticated nor encrypted.^[1]
No clear delimiter between configuration data and monitoring data. Resulting in additional logic having to be performed on the client side in order to sort.
Lacks standard MIBs for configuring networks. That is why, vendors have developed various proprietary MIBs which become a barrier to managing cross vendor platforms.^[2]
Provides no real transactional operation model, to allow for simple rollbacks etc.

With the adoption of network automation increasing (such as SDN, think NBI) there was a need to standardize and improve the way that networking devices were programmed. A way that provided,

A programmatic interface for device configuration.
Separation of configuration and state data.
The ability to configure services not just devices.
Integrated error checking and recovery.

The solution to this issue came from the IETF, in the form of NETCONF and YANG. In its simplest form (and to recap our previous TL;DR) YANG provides a language to describe your desired configuration (or state). NETCONF, on the other hand provides the protocol to deliver and perform the required operations in order to achieve the desired state, described within the YANG model.

netconf-stack6

Figure 1 – NETCONF/YANG Stack.

YANG

YANG (Yet Another Next Generation) is a data modelling language, providing a standardized way to model the operational and configuration data of a network device. YANG, being a language is being protocol independent, can then be converted into any encoding format, e.g. XML or JSON.^[3]

Open/Native Models

You may be asking who creates these models? The models are classified as either Open or Native based, with different groups working across each one.

Open Models – Designed to be independent of the underlying platform and normalize the per-vendor configuration of network devices. Open YANG Models are developed by Vendors and Standards bodies, such as IETF, ITU, OpenConfig etc.
Native Models – Native Models are developed by the vendors. They relate and are designed to integrate to features or configuration only relevant to that platform.

Components

A YANG model is made up from various components. Let’s look at these components, in relation to our example (seen within Figure 2).

yang

Figure 2 – YANG Structure (Source : Cisco Live – DEVNET-1721).

Container – A collection of information logically grouped. Such a container for configuration, and one for state.
List – Within a container you can have a list or even multiple lists. Such as a list of interfaces.
Key – Each item within the list is references via a key.
Leaf – Inside our list we have leaf’s. Containing our information.
Data Type – Each leaf is associated against a data type.

NETCONF

NETCONF (NETwork CONFiguration) is a protocol defined by the IETF to “install, manipulate, and delete the configuration of network devices”.^[4] NETCONF operations are performed via a RPC layer using XML based encoding.

Some of the key features to NETCONF are, ability to rollback configurations, ability to support any data model and the separation of config from operational state.

Protocol Stack

The NETCONF protocol can be broken down into 4 layers. They are,

Content – NETCONF data models and protocol operations use the YANG modeling language (RFC 6020). A data model outlines the structure, semantics and syntax of the data.^[5]
Operations – A set of base protocol operations initiated via by RPC methods using XML-encoding, in order to perform operations upon the device. Such as <get-config>, <edit-config> and <get>.
Messages – A set of RPC messages and notifications are defined for use including <rpc>, <rpc-reply> and <rpc-error>.^[6]
Transport – The transport layer used to provide a communication path between the client/server (manager/agent). The protocol used is agnostic to NETCONF, but SSH is typically used.

Figure 3 – NETCONF protocol stack.

Communication

NETCONF is based upon a client/server model, as known (as per NETCONF’s terminology) – Manager and Agent.

Within the communication flow of a NETCONF session there are 3 main parts. These are:

Session Establishment – Each side sends a <hello>, along with its <capabilities>. Announcing what operations (capabilities) it supports.
Operation Request – The client then sends its request (operation) to the server via the<rpc> message. The response is then sent back to the client within <rpc-reply>.
Session Close – The session is then closed by the client via <close-session>.

Operations

Actions are performed upon the network device (and its datastores) via a set of Operations. Each of the operations relate to the devices (client or server’s) capabilities. For example if we look at <get-config> this is supported under the :base capability.

Operation	Description
<get>	Fetch running configuration and state information
<get-config>	Fetch all or part of specified configuration data store
<edit-config>	Load all or part of a configuration to the specified configuration data store
<copy-config>	Replace the whole configuration data store with another data store
<delete-config>	Delete a configuration data store
<discard-changes>	Clear all changes from <candidate/> and make it match the <running/> configuration data store
<create-subscription>	Create a NETCONF notification subscription
<commit>	Copy candidate data store to running data store
<cancel-commit>	Cancels an ongoing confirmed commit
<lock>	Lock the entire configuration data store system so one my session can write
<unlock>	Unlock the entire configuration data store system so any session can write
<close-session>	Graceful termination of NETCONF session
<kill-session>	Forced termination of NETCONF session

Configuration Datastores

There are 4 NETCONF configuration datastores – Running, Startup, Candidate and URL. Actions are then performed against these datastores via the various NETCONF operations (as previously seen):

Running – The configuration datastore containing the configuration that is applied and running upon the network device.
Startup – The configuration datastore holding the configuration loaded by the device when it boots.^[7]
Candidate – A configuration datastore that can be manipulated without impacting the device’s current configuration and that can be committed to the running configuration datastore.^[8]
URL – A configuration datastore thats configuration resides within a separate location, accessed via a URL.

References

[1] “Under New Management: Practical Attacks on SNMPv3 – Usenix.” https://www.usenix.org/system/files/conference/woot12/woot12-final14.pdf. Accessed 17 Oct. 2017.
[2] “Can NETCONF and YANG save from network disasters ? – TelcoCloud ….” 18 Jan. 2016, http://www.telcocloudbridge.com/can-netconf-yang-save-network-disasters/. Accessed 17 Oct. 2017.
[3] “YANG data modeling – Wikipedia.” https://en.wikipedia.org/wiki/YANG. Accessed 19 Oct. 2017.
[4] “Tail-f Systems.” http://www.tail-f.com/. Accessed 20 Oct. 2017.
[5] “NETCONF: Introduction To An Emerging Networking Standard ….” 20 Jun. 2014, https://www.networkcomputing.com/networking/netconf-introduction-emerging-networking-standard/338840365. Accessed 22 Oct. 2017.
[6] “NETCONF: Introduction To An Emerging Networking Standard ….” 20 Jun. 2014, https://www.networkcomputing.com/networking/netconf-introduction-emerging-networking-standard/338840365. Accessed 22 Oct. 2017.
[7] “NETCONF Primer – NETCONFc.” http://www.seguesoft.com/netconf-primer. Accessed 20 Oct. 2017.
[8] “NETCONF Primer – NETCONFc.” http://www.seguesoft.com/netconf-primer. Accessed 20 Oct. 2017.

Want to become a networking expert?

Here is our hand-picked selection of the best courses you can find online:
Cisco CCNA 200-301 Certification Gold Bootcamp
Complete Cyber Security Course – Network Security
Internet Security Deep Dive course
Python Pro Bootcamp
and our recommended certification practice exams:
AlphaPrep Practice Tests - Free Trial