NETCONF is a standardized IETF configuration management protocol published in RFC 6241.The NETCONF protocol defines operations for managing network devices where configuration data can be retrieved, uploaded, manipulated, and deleted. The standard also defines the application programming interface as well as the connectivity requirements for NETCONF. It is secure, connection oriented, and runs on top of the SSHv2 transport protocol as specified in RFC 6242.
The NETCONF protocol uses a remote procedure call (RPC) paradigm. A client encodes an RPC in XML and sends it to a server using a secure, connection-oriented session. The server responds with a reply encoded in XML. The contents of both the request and the response are fully described in XML DTDs or XML schemas, or both, allowing both parties to recognize the syntax constraints imposed on the exchange
Netconf Layers
NETCONF can be conceptually partitioned into four layers as described in RFC 6241
Operations
NETCONF has several base operations that an operator can use. It provides an initial set of operations and a number of capabilities that can be used to extend the base
Operation Name |
Description |
|---|---|
get |
Retrieve running configuration and device state information (great for "situational awareness") |
get-config |
Retrieve all or part of a specified configuration datastore. |
edit-config |
Loads all or part of a specified configuration to a target configuration datastore. |
copy-config |
Overwrites an existing configuration datastore with the contents of another. |
delete-config |
Deletes a configuration datastore (the "running" datastore cannot be deleted) |
lock |
Locks a configuration datastore so that changes are only allowed by the requesting client. |
unlock |
Releases a configuration datastore from a lock that was previously issued by the same client. |
close-session |
Attempts to gracefully terminate a NETCONF session (allows device to finish any tasks) |
kill-session |
Forces termination of a NETCONF session (device must stop all tasks and quit) |
Capabilities
NETCONF allows a client to discover the set of protocol extensions supported by a server. These “capabilities” permit the client to adjust its behavior to take advantage of the features exposed by the device. The capability definitions can be easily extended in a noncentralized manner. NETCONF, “capabilities” provide a way for a network device to offer functionality beyond the base operations. NETCONF allows endpoints to come to an agreement on which additional operations are suported
Capability Name |
Description |
|---|---|
Writable-Running |
Indicates the NETCONF server allows clients to edit the running configuration directly |
Candidate Configuration |
Network device supports a candidate capability, as well as the "commit" operation |
Confirmed Commit |
Supports additional operations and parameters for the "commit" operation |
Rollback-On-Error |
Network device is able to roll-back to previous good configuration if changes fail |
Validate |
The device is able to check configuration for syntax errors before applying it to a datastore. |
Distinct Startup |
Device maintains a separate startup configuration that is loaded on boot |
URL |
Device can also accept a URL as a parameter to operations like edit-config |
XPath |
The network device accepts XPath expressions within filters sent inside operations |
Configuration Datastores
A configuration datastore is the complete set of configuration information that is required to get a device from its initial default state into a desired operational state. There are three possible datastores that can be addressed by NETCONF: “running”, “candidate”, and “startup”.
running configuration datastore |
Represents the currently active configuration of a device and is always present |
startup configuration datastore |
Represents the configuration that will be used during the next startup |
candidate configuration datastore |
Represents a configuration that may become a |
“candidate” datastore as a sort of “proposed” datastore, or a configuration that is staged, but not yet pushed to the forefront. This will require the client to also send a “commit” operation in order to instruct the server to push the candidate datastore onto the running datastore - or in other words, cause the configuration to take effect on the network device.
If such a capability is not supported, then the NETCONF device must allow direct access to the “Running” datastore for the client to make network changes take effect.
The NETCONF protocol is a building block in a system of automated configuration. XML provides a flexible but fully specified encoding mechanism for hierarchical content. NETCONF can be used in concert with XSLT to provide a system for automated generation of full and partial configurations.