The Network Configuration Protocol, NETCONF, is an IETF network management protocol. It was developed in the NETCONF working group and published in December 2006 as RFC 4741 and later revised in June 2011 and published as RFC 6241. It was first brought to the IETF by Juniper with their XML configuration management concept and shared with the community. The NETCONF Working Group was created in 2002.
NETCONF can be conceptually partitioned into four layers: Layer Example +-------------+ +-----------------------------+ (4) | Content | | Configuration data | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (3) | Operations | | <get-config>, <edit-config> | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (2) | RPC | | <rpc>, <rpc-reply> | +-------------+ +-----------------------------+ | | +-------------+ +-----------------------------+ (1) | Transport | | BEEP, SSH, SSL, console | | Protocol | | | +-------------+ +-----------------------------+ 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. Section 2 discusses these requirements. 2. The RPC layer provides a simple, transport-independent framing mechanism for encoding RPCs. Section 4 documents this protocol. 3. The operations layer defines a set of base operations invoked as RPC methods with XML-encoded parameters. Section 7 details the list of base operations. 4. The content layer is outside the scope of this document. Given the current proprietary nature of the configuration data being manipulated, the specification of this content depends on the NETCONF implementation. It is expected that a separate effort to specify a standard data definition language and standard content will be undertaken.
The NETCONF 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.
The content layer is outside the scope of this document. Given the current proprietary nature of the configuration data being manipulated, the specification of this content depends on the NETCONF implementation. It is expected that a separate effort to specify a standard data definition language and standard content will be undertaken.
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 the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications.
An Architecture for Network Management Using NETCONF and YANG describes how NETCONF and YANG help build network management applications that meet the needs of network operators.
NETCONF defines operations that are invoked as RPCs from the client (the application) to the server (running on the device). The following table lists some of these operations: +---------------+---------------------------------------------------+ | Operation | Description | +---------------+---------------------------------------------------+ | commit | Commit the "candidate" configuration to "running" | | copy-config | Copy one configuration datastore to another | | delete-config | Delete a configuration datastore | | edit-config | Change the contents of a configuration datastore | | get-config | Retrieve all or part of a configuration datastore | | lock | Prevent changes to a datastore from another party | | unlock | Release a lock on a datastore | +---------------+---------------------------------------------------+ A YANG module defines a data model in terms of the data, its hierarchical organization, and the constraints on that data. YANG defines how this data is represented in XML and how that data is used in NETCONF operations. The following table briefly describes some common YANG statements: +--------------+----------------------------------------------------+ | Statement | Description | +--------------+----------------------------------------------------+ | augment | Extends existing data hierarchies | | choice | Defines mutually exclusive alternatives | | container | Defines a layer of the data hierarchy | | extension | Allows new statements to be added to YANG | | feature | Indicates parts of the model that are optional | | grouping | Groups data definitions into reusable sets | | key | Defines the key leafs for lists | | leaf | Defines a leaf node in the data hierarchy | | leaf-list | A leaf node that can appear multiple times | | list | A hierarchy that can appear multiple times | | notification | Defines notification | | rpc | Defines input and output parameters for an RPC | | | operation | | typedef | Defines a new type | | uses | Incorporates the contents of a "grouping" | +--------------+----------------------------------------------------+ The YANG data modeling language is the central piece of a group of related technologies. The YANG language itself, described in [RFC6020], defines the syntax of the language and its statements, the meaning of those statements, and how to combine them to build the hierarchy of nodes that describe a data model. In some environments, incorporating a YANG parser may not be an acceptable option. For those scenarios, an XML grammar for YANG is defined as YIN (YANG Independent Notation). YIN allows the use of XML parsers that are readily available in both open source and commercial versions. Conversion between YANG and YIN is direct, loss-less, and reversible. YANG statements are converted to XML elements, preserving the structure and content of YANG, but enabling the use of off-the-shelf XML parsers rather than requiring the intergration of a YANG parser. YIN maintains complete semantic equivalance with YANG.
Following up on the YANG data model there are a number of IETF NETMOD Drafts for specific modules such as Inteface type, Interface config, IP config, translating MIB to YANG and Routing configuration. A Listing of these can be found at Netconf Central with more detailed information on YANG, which is out of the scope of this post.
SNMP was created in the late 1980′s and is rather well known, but still I find it used at a minimum of its capabilites. Mostly SNMPv2c is turned on with a basic read-only community string to poll the interface utilization of network devices on any give Network Management Software, such as SolarWinds, HPOV or CiscoWorks…only to be forgotten and rarely looked at. As for using SNMP for configuration, most have this capablity turned off due to the security risks with read-write community strings.
SNMPv3 you say? Most people I come in contact with the V3 scares them on mere mention of Users, Groups and Views add Authentication and Encryption to the mix and most are not even going to attempt to get it to work. Not to mention a lack of education on the abilities of SNMP and how it operates with the Management Information Base (MIB) and Object Identifiers (OID) to not only poll the counters but set the configuration as well.
But SNMP is still needed. Based on some quotes from the NETCONF working group, replacing SNMP is not even part of the charter for NETCONF. “This is NETCONF - configuration specific, not out to replace SNMP notifications, traps, etc.” – Randy Bush and “The work in the SNMP community (if there is any) doesn’t have much impact on the netconf WG, since netconf is not intended to be a replacement for SNMP.” – Andy Bierman
So who is using NETCONF and leading the charge for this protocol that could be the end of the proprietary CLI?
Vendor support for NETCONF:
Alaxala - Ethernet switches
Cisco - IOS 12.4(9)T and later, IOS XE 2.1 and later
Ericsson
Juniper Networks – JUNOS 7.5 and later
RuggedCom - Routers and switches, RX5000 and MX5000
Taseon - Intelligent optical networks, TN 320
Verivue - Next-generation video distribution, MDX 9020
Edgeware - Servers for on-demand TV, WTV-2X
Nexor - Messaging Gateways
Telco Systems - Carrier Ethernet Multiservice Aggregation, T-Metro 7224
Tools to interface with NETCONF and YANG:
Commercial:
Applied Informatics
GoAhead
SNMP Research
Tail-f Systems
Open Source:
Ncclient (client)
netopeer (client/server)
YencaP (client/server)
Yuma (client/server)
Please note - the above lists were taken from a A 30-minute Introduction to NETCONF and YANG – Presentation Transcript by Tail-f.
Based on the IOS version I have available, both my router (Version 12.4(15)T12) and switch (12.2(50)SE3) versions of NETCONF were very disappointing, including the Cisco documention and the NETCONF Client GUI that would not install on my Windows 7 workstation, when compared to Juniper documentation. For OpenFlow it is only mentioned on Openflow 1.X Discussion page, “The consensus seems to be that the best way to do this is not via the OpenFlow protocol, but via a different protocol. Most frequently named candidates are SNMP and Netconf.”
Here’s an example of using NETCONF with Cisco. I work in a Cisco-only environment and do not have access to Junosphere, although maybe someday it would be nice to play around with and learn some Junos.
linux:~$ ssh -s [email protected] netconf
Password:
<?xml version=”1.0″ encoding=”UTF-8″?><hello><capabilities><capability>urn:ietf:params:netconf:base:1.0</capability><capability>urn:ietf:params:netconf:capability:writeable-running:1.0</capability><capability>urn:ietf:params:netconf:capability:startup:1.0</capability><capability>urn:ietf:params:netconf:capability:url:1.0</capability><capability>urn:cisco:params:netconf:capability:notification:1.0</capability></capabilities><session-id>1731357996</session-id></hello>]]>]]>
SEND a HELLO back to the Cisco router
<?xml version=”1.0″ encoding=”UTF-8″?>
<hello>
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
</capabilities>
</hello>]]>]]>
To get the configuration you have to send:
<?xml version=”1.0″ encoding=”UTF-8″?>
<rpc message-id=”101″ xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0″ \
xmlns:cpi=”http://www.cisco.com/cpi_10/schema“>
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>]]>]]>
The Router returns:
<?xml version=”1.0″ encoding=”UTF-8″?>
<rpc message-id=”101″ xmlns=”urn:ietf:params:xml:ns:netconf:base:1.0″ \
xmlns:cpi=”http://www.cisco.com/cpi_10/schema“>
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>]]>]]>
<?xml version=”1.0″ encoding=”UTF-8″?><rpc-reply message-id=”101″ xmlns=”urn:ietf:params:netconf:base:1.0″><data><cli-config-data-block>!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname cisco
!
boot-start-marker
boot-end-marker
!
no aaa new-model
memory-size iomem 5
ip cef
!
ip domain name g.com.local
!
username cisco privilege 15 password 0 cisco
archive
log config
hidekeys
!
ip ssh version 2
!
interface Tunnel1
no ip address
!
interface FastEthernet0/0
ip address 192.168.56.10 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
ip forward-protocol nd
!
ip http server
no ip http secure-server
!
control-plane
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
login local
!
netconf ssh
!
</cli-config-data-block></data></rpc-reply>]]>]]>
Wrapping up, I think NETCONF has a lot of potential to change the way network devices are configured. I mean, to think that there would be one XML-based configuration scheme to upload and download no matter what the vendor is great. This is in the same realm of what OpenFlow is doing with being able to allow their controller to control the flows on any vendor’s switch, only the actual commands sent to change the configuration of the device would be XML-based. Scripting with perl or python is also the biggest way to see the value in this movement. Having a dedicated programmer and also network people learning the basics of scripting is going to be ever more crucical in the path ahead. All in all, I think NETCONF is a great stride forward. But as I said earlier, SNMP has been around since the dawn of IP networking and still a lot of networks do not utilize it to its full capacity. So NETCONF will take some time for not only vendors to implement, but also for the network professionals to actually use it instead of the old CLI commands.
About Garry Baker
