Introduction
You may know network management can be performed by using Simple Network Management Protocol (SNMP) which was introduced in 1980 and is still being used by businesses around the world. SNPM uses a data modeling language called SMI (Structured Management Information) and stores its data in a Management Information Base (MIB). MIB has some drawbacks such as not being easy to read, no re-using code… SNMP itself can not perform an operation within a transaction; a write operation cannot rollback; cannot test configuration before final commit…NETCONF was introduced to resolve these drawbacks of SNMP and it has more than that. Let’s discover it now.
Overview
NETCONF is the network management protocol released by IETF whereas YANG is the data modeling language used by NETCONF. NETCONF overcomes drawbacks of SNMP by making it suitable for network management and automation. NETCONF has a client-server architecture that communicates using remote procedure calls. NETCONF operations take place in a configuration data-store and it defines three configuration data stores. Configuration data store is a conceptual location where configuration data is stored and accessed.
The NETCONF protocol uses a remote procedure call (RPC) paradigm. A client encodes anRPC in XML [W3C.REC-xml-20001006] 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
A brief description of YANG
- YANG is the data modeling language for NETCONF. Its syntax is like C, easy to understand
- YANG is used to define the syntax and semantics of the NETCONF operations, notification events, and database content. Machine and human readable semantics and constraints are used by YANG tools to automate behavior within the NETCONF protocol for clients and servers.
- The database is used to contain YANG data structures which represent the configuration of the device containing the NETCONF server. This configuration can be saved in non-volatile storage so the configuration can be restored upon reboot.
NETCONF transport:
- NETCONF messages are encoded in XML
- NETCONF messages are encrypted by SSH: SSH provides authentication, integrity and confidentiality
- NETCONF is connected oriented using TCP
NETCONF Capabilitie
Are the optional behaviors that the server supports. There are some major capabilities:
:candidate:
The :candidate capability indicates that database edits will be done to the <candidate> database, and saved with the <commit> operation.
Database edits are collected in the <candidate> and then applied, all or nothing, to the <running> database, with the <commit> operation.
This capability is supported by default
:confirmed-commit:
The :confirmed-commit capability indicates that the server will support the <confirmed> and <confirm-timeout> parameters to the <commit> operation
:notification:
The :notification capability indicates that the server will accept the <create-subscription> operation, and deliver notifications to the session, according to the subscription request.
All <create-subscription> options and features are supported.
:rollback-on-error:
When set to rollback-on-error, if any part of the requested configuration change cannot be performed, the database will be restored to its previous state, and server instrumentation callbacks to ‘undo’ any changes made will be invoked.
:startup:
The :startup capability indicates that the <startup> configuration is supported by the server. By default, this capability is not supported.
:validate:
The :validate capability indicates that the <validate> operation is accepted, and the <test-option> for the <edit-config> operation is also accepted, by the server.
:writable-running:
The :writable-running capability indicates that the server uses the <running> configuration as its edit target. In this case, the <target> parameter for the <edit-config> operation can only be set to <running/>.
:xpath:
The :xpath capability indicates that XPath filtering is supported for the <get> and <get-config> operations.
NETCONF Configuration Data Stores
There are 3 configuration datastores in NETCONF:
- Candidate: the configuration datastore that can be manipulated without impacting the device’s current configuration and that can be committed to the running datastore. Not all devices support a candidate configuration datastore (see Capabilities above)
- Running: the configuration datastore holding the complete configuration currently active on the device. The running configuration datastore always exists.
- Startup: the configuration datastore holding the configuration loaded by the device when it boots. Only present on devices that separate the startup configuration datastore from the running configuration datastore (see Capabilities above).
NETCONF operations
- get: the <get> operation is used to retrieve data from the <running> configuration, or non-configuration data available on the server. Filter can be applied to <get> or <get-config> to select only specific subsets of all available data.
Examples:
<get> with subtree filtering:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″ message-id=”4″>
<nc:get>
<nc:filter type=”subtree”>
<proc:proc xmlns:proc=”http://netconfcentral.org/ns/proc”>
<proc:cpuinfo>
<proc:cpu>
<proc:cpu_MHz/>
</proc:cpu>
</proc:cpuinfo>
</proc:proc>
</nc:filter>
</nc:get>
</nc:rpc>
<get> with xpath filtering:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″
message-id=”4″>
<nc:get>
<nc:filter type=”xpath” select=”/proc/cpuinfo/cpu/cpu_MHz”/>
</nc:get>
</nc:rpc>]
Reply example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc-reply xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″
last-modified=”2011-08-21T17:51:46Z” message-id=”4″>
<nc:data>
<proc:proc xmlns:proc=”http://netconfcentral.org/ns/proc”>
<proc:cpuinfo>
<proc:cpu>
<proc:cpu_MHz>1600.000</proc:cpu_MHz>
<proc:processor>0</proc:processor>
</proc:cpu>
<proc:cpu>
<proc:cpu_MHz>2667.000</proc:cpu_MHz>
<proc:processor>1</proc:processor>
</proc:cpu>
</proc:cpuinfo>
</proc:proc>
</nc:data>
</nc:rpc-reply>
2. get-config: the operation is used to retrieve data from a NETCONF configuration database specified by the parameter. It also uses like operation
Example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″ message-id=”3″>
<nc:get-config>
<nc:source>
<nc:candidate/>
</nc:source>
<nc:filter type=”xpath” select=”/nacm/rules/moduleRule”/>
</nc:get-config>
</nc:rpc>
Reply example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc-reply xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″
last-modified=”2011-08-21T17:51:46Z” message-id=”3″>
<nc:data>
<nacm:nacm xmlns:nacm=”http://netconfcentral.org/ns/nacm”>
<nacm:rules>
<nacm:moduleRule>
<nacm:moduleName>netconf</nacm:moduleName>
<nacm:allowed-rights>read exec</nacm:allowed-rights>
<nacm:allowed-group>nacm:guest</nacm:allowed-group>
</nacm:moduleRule>
<nacm:moduleRule>
<nacm:moduleName>netconfd</nacm:moduleName>
<nacm:allowed-rights>read write exec</nacm:allowed-rights>
<nacm:allowed-group>nacm:admin</nacm:allowed-group>
<nacm:comment>access to shutdown and restart rpcs</nacm:comment>
</nacm:moduleRule>
<nacm:moduleRule>
<nacm:moduleName>netconf</nacm:moduleName>
<nacm:allowed-rights>read write exec</nacm:allowed-rights>
<nacm:allowed-group>nacm:admin</nacm:allowed-group>
<nacm:allowed-group>nacm:monitor</nacm:allowed-group>
</nacm:moduleRule>
</nacm:rules>
</nacm:nacm>
</nc:data>
</nc:rpc-reply>
3. edit-config: the operation is used to alter the target database. The target database is the configuration if the –target configuration parameter is set to ‘candidate’, and the configuration if it is set to ‘running’.
Example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″ message-id=”12″>
<nc:edit-config>
<nc:target>
<nc:candidate/>
</nc:target>
<nc:default-operation>merge</nc:default-operation>
<nc:test-option>set</nc:test-option>
<nc:error-option>rollback-on-error</nc:error-option>
<nc:config>
<t:musttest xmlns:t=”http://netconfcentral.org/ns/test”>
<t:A nc:operation=”create”>’testing one two'</t:A>
</t:musttest>
</nc:config>
</nc:edit-config>
</nc:rpc>
Reply example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc-reply xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″ message-id=”12″>
<nc:ok/>
</nc:rpc-reply>
4. commit: the operation is only available when the :candidate capability is supported. The parameters are only supported if the :confirmed-commit capability is supported. This operation causes all the edits in the configuration to be applied to the configuration. If there are no edits, then this operation has no effect.
Example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0 message-id=”5″>
<nc:commit/>
</nc:rpc>
Reply example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc-reply xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″ message-id=”5″>
<nc:ok/>
</nc:rpc-reply>
5. cancel-commit: the <cancel-commit> operation is used to cancel a confirmed commit
procedure in progress.
Example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0 message-id=”2″>
<nc:cancel-commit>
<nc:persist>mycommit</nc:persist>
</nc:cancel-commit>
</nc:rpc>
Reply example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc-reply xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″ message-id=”2″>
<nc:ok/>
</nc:rpc-reply>
6. discard-changes: the <discard-changes> operation is used to remove any edits from the <candidate> configuration. This is done by deleting the contents of the <candidate> and re-filling it with the contents of the <running> configuration.
If the <candidate> configuration is locked by another session, this operation will fail.
Example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″ message-id=”3″>
<nc:discard-changes/>
</nc:rpc>
7. create-subscription: the <create-subscription> operation is used to start a NETCONF
notifications subscription
Example:
<?xml version=”1.0″ encoding=”UTF-8″?>
<nc:rpc xmlns:nc=”urn:ietf:params:xml:ns:netconf:base:1.0″ message-id=”2″>
<ncEvent:create-subscription
xmlns:ncEvent=”urn:ietf:params:xml:ns:netconf:notification:1.0″>
<ncEvent:startTime>2009-01-01T00:00:00Z</ncEvent:startTime>
</ncEvent:create-subscription>
</nc:rpc>
Refer to https://datatracker.ietf.org/doc/html/rfc7950#page-116 for more operations and details.
How to get started with NETCONF
- Download NETCONF server (and client programs) source code from:
https://github.com/OpenClovis/OpenYuma
- Follow the guidelines in the README file to build the source
- Follow the guidelines from netconf/doc/yuma_docs for how to work with the netconfd and how to use the protocol operations
Conclusion
NETCONF protocol is the right approach to replace the SNMP because it overcomes the some drawbacks of SNMP.
NETCONF uses YANG as a data modelling language which is human readable, easy to use language.
NETCONF leverages the strong features of SSH like security, authentication to implement those in its server.
Other support, please send email to support@openclovis.org.