• 06/20/2014
    7:00 AM
    Natalie Timms
  • Natalie Timms
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    Vote up!
    Vote down!

NETCONF: Introduction To An Emerging Networking Standard

By providing a programmatic interface, NETCONF eliminates the need to use proprietary CLIs for network device configuration and can facilitate SDN.

Standards bodies like the IETF have been responsible for introducing innovative new protocols and methods for vendor-agnostic deployment. Some of the most well-known protocol definitions that have gone on to become network staples include IKE and IPsec, RADIUS, and of course routing protocols and applications.

In this article, I will examine an emerging industry standard that plays an important role in the SDN space: Network Configuration Protocol (NETCONF).

Originally published as RFC 4741 in 2006, NETCONF is positioned as a standardized method for network device configuration. Network devices can typically be configured using a vendor-specific CLI. NETCONF provides a programmatic interface to a network device, eliminating the need for users to understand proprietary CLI syntax for device configuration or managing operational data. It leverages the ability to separate configuration data from operational data and statistics (state data) from a device by providing operations for the retrieval of both data types.

This differs from SNMP, which uses a single get operation to pull all data from a device, leaving it up to the user to sort through a plethora of management information base (MIB) variables. SNMP has also been used traditionally for performance and monitoring rather than device configuration.

The transport used by NETCONF is TCP based and ties in to security protocols like SSHv2 and TLS. This compares with SNMP and its use of best effort UDP and no standard security mechanism.

The NETCONF protocol is built on a four-layer approach:

1)      Secure Transport Layer: Authentication and integrity can be provided by protocols such as TCP-based TLS and SSHv2.

2)      Message Layer: A set of RPC messages and notifications are defined for use including <rpc>, <rpc-reply> and <rpc-error>.

3)      Operations Layer: Defines a set of base protocol operations invoked by RPC methods using XML-encoding. These include <get-config>, <edit-config> and <get>.

4)      Content Layer: 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.

Here is a simple NETCONF example:

Configuration data is carried inside a <config> element and conforms to the data model identified by the namespace referenced in the RPC message.

XML subtree filtering is used to build the selection criteria to be enforced within an operation to be carried via the RPC message.

Set the maximum transmission unit (MTU) to 1500 on an interface named "Ethernet0/0" in the running configuration:

     <rpc message-id="101"
           <top xmlns="">
Acknowledge the operation:
     <rpc-reply message-id="101"

NETCONF is supplemented by some key operational capabilities, such as support for rollback and confirmed commit and validation of configurations.

In terms of SDN, NETCONF is often referenced as a southbound API from an SDN controller to network agents like switches and routers due to its potential for supporting multi-vendor environments.

NETCONF and its role in SDN will become even more interesting with the recent announcement of Cisco’s plan to acquire Tail-f Systems. Tail-f’s ConfD uses NETCONF and YANG modeling language to provide SDN-ready configuration and operational data management as well as supporting multi-vendor on-device management, although how Cisco maintains Tail-f's level of vendor neutrality will be interesting to watch. 

More information about NETCONF from a protocol and standards perspective is available on the NETCONF wiki.


The Value in Data

SDN can cut OPEX and CAPEX costs, and NETCONF creates a nice and clean environment by allowing for the separation of configuration data from operational data. I wonder if having operational data separate from a device will enables a new source of revenue generation -- social media generates revenge why measuring interaction, networks might be able to do the same.

Support for NETCONF?

Thanks for the overview. Are many vendors on board with supporting NETCONF and Yang? And is there overlap between NETCONF and OpenFlow? That is, are they each doing similar things, or do they compliment each other?

Re: Support for NETCONF?

According to information in, there are a number of vendors supporting NETCONF/YANG. The extent of vendor support would be found on their websites. For example Cisco has included configuring NETCONF and using various secure transports like SSHv2 and BEEP in Cisco IOS documentation. NETCONF and OpenFlow are both denoted as southbound APIs in an SDN model but there is a subtle difference. NETCONF manages changes to device state and function via configuration modifications which are generally permanent in nature, for example add a route map to influence traffic flows. OpenFlow will allow device state change to be directly manipulated, for example make a temporary change in a forwarding table to modify a flow. There isn't any reason why both could not be used together.

Re: Support for NETCONF?

Thanks for sharing that link Natalie, and for the additional details!

When is a Standard Not A Standard?

"This differs from SNMP, which uses a single get operation to pull all data from a device, leaving it up to the user to sort through a plethora of management information base (MIB) variables."

...whereas with NETCONF we end up browsing the XSD instead because despite what it sounds like above, my limited experience with NETCONF suggests that it is anything but standardized between vendors. And that's really really really annoying because it makes adoption of NETCONF more difficult, and this limits access to all the cool stuff mentioned in the article above. 

It starts badly when Cisco and Juniper - two main players who support NETCONF to one degree or another - can't even agree on a port or a subsystem name. The IANA-assigned port for NETCONF over SSH is tcp/830. The default subsystem name is "netconf". Naturally then when I test a Cisco Nexus5k and a Juniper SRX I discover that to connect, I need:

Cisco NXOS:
  ssh -p 22 -s "xmlconfig"
Juniper Junos OS:
  ssh -p 830 -s "netconf"

Different port, different subsystem? In other words, out of the box I can't even connect to Cisco and Juniper devices the same way, meaning I have to either have meta data elsewhere telling me what vendor/OS each device uses, or I have to go through a crazy bunch of 'try it, fail, try next' steps.

Maybe at least we'll have some consistency in the XML RPC command structure? Well, actually, no we don't. I decided to test the same command - to show the bridging table entry for a specified MAC address - on both platforms and discovered that the difference between Cisco's and Juniper's implementation of the same query is both huge and depressing. The resulting XML isn't much better (in fact Cisco's XML reply makes me want to cry).

Oh well. So much for the idea that we can separate function from implementation - the implemention from connection to command is vendor specific, so I have to maintain multiple incompatible structures in my code if I want it to work in a heterogenous network. Isn't that great?

Don't get me wrong - I still think NETCONF is great, but my experience scripting with it so far has been exceptionally frustrating.




"although how Cisco maintains Tail-f's level of vendor neutrality will be interesting to watch."

It will. The joy of Tail-f was that they were truly presenting something that separated function from implementation (declarative language version procedural). We'll have to wait and see what happens as a result of the acquisition, but having a multivendor 'rosetta stone' product owned by a single vendor doesn't initially give me confidence. Tail-f is also the OEM providing ConfD services to (in their words as I recall) 7 out of the top 10 largest network vendors. The other 6 (for Cisco is surely one of those 7) must be extremely concerned right now.