Introduction
In this blog we will be looking at a NETCONF overview and its practical use case for network programmability. To begin with, NETCONF stands for network configuration protocol and it is a next-generation network management protocol that is designed specifically for transactional network management and to improve upon the weaknesses of SNMP. network device is separated into two classes. These classes are configuration data and state data.
Configuration data is the writable data required to transform a system from its initial default state into its current, whereas state data is the additional data on a system that is not configuration data, such as read-only status information and collected statistics.
In addition, NETCONF can store that configuration data in one of several data stores. It is one of the unique attributes of NETCONF, although a device does not have to implement this feature to “support” the protocol. NETCONF uses a candidate configuration, simply a configuration with all proposed changes applied in an uncommitted state. It is the equivalent of entering CLI commands and having them not take effect right away. You would then “commit” all the changes as a single transaction. Once committed, you would see them in the running configuration.
NETCONF Protocol Stack
NETCONF has the following protocol stack:
- Transport
Most common NETCONF implementations use SSH as the transport protocol and by default on TCP PORT 830. - Messages
NETCONF supports two message types: <rpc> and <rpc-reply>. NETCONF messages are encoded in XML and based on remote procedure call-based communication. - Operations
The two most common operations performed with NETCONF are configuration update and retrieval.
The <get> operation retrieves the running configuration and device state information.
An <edit-config> operation might be used to perform a configuration change. The <edit-config> operation loads all or part of a specified configuration to the specified target configuration datastore. The <edit-config> operation also supports the ability to merge, replace, and create configurations based on particular elements of the configuration using an operation attribute embedded within the XML, making editing configurations very flexible with NETCONF.
A network device analyses the source and target configurations and performs the requested changes. The target configuration is not necessarily replaced. Instead, the target configuration is changed based on the source data and requested operations.
Other NETCONF operations include the following:
<get-config>: This operation retrieves all or part of a specified configuration datastore.
<copy-config>: This operation creates or replaces an entire configuration datastore with the contents of another complete configuration datastore.
<delete-config>: This operation deletes a configuration datastore. The running configuration datastore cannot be deleted.
<lock>: This operation allows the client to lock the entire configuration datastore system of a device.
<unlock>: This operation unlocks a previously issued lock on a configuration datastore.
<close-session>: This operation requests a graceful termination of a NETCONF session.
<kill-session>: This operation forces the termination of a NETCONF session. - Content: Content is an XML representation of a YANG data model that the device supports. It is common for models to be written in YANG, but in the NETCONF context, they are represented using XML data encoding. Content is embedded within <rpc> operation tag elements.
Operational Statistics Example
The following is the procedure used to get show interface statistics via Netconf console.
Step 1: In this step, gather show interfaces fxp0.0 statistics in xml rpc format. Then gather <rpc> format output and use the same RPC format in the following step 2 – using netconf-console2 command.
lab> show interfaces fxp0.0 statistics detail | display xml rpc <rpc-reply xmlns:junos="http://xml.juniper.net/junos/23.2R1.13/junos"> <rpc> <get-interface-information> <statistics/> <detail/> <interface-name>fxp0.0</interface-name> </get-interface-information> </rpc> <cli> <banner></banner> </cli> </rpc-reply>
Step 2: Use Netconf-console to get interface statistics such as input packets, output packets, MTU details, policer, class of service details.
netconf-console2 --host 192.168.107.134 -u lab -p Abcd1234 --port 830 --rpc=-<<<' <get-interface-information> <statistics/> <interface-name>fxp0</interface-name> </get-interface-information> ' <?xml version='1.0' encoding='UTF-8'?> <nc:rpc-reply xmlns:junos="http://xml.juniper.net/junos/23.2R1.13/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:27a1cd25-0a08-4714-bb73-432bd4dabab0"> <interface-information xmlns="http://xml.juniper.net/junos/23.2R0/junos-interface" junos:style="normal"> <physical-interface> <name> fxp0 </name> <admin-status junos:format="Enabled"> up </admin-status> <oper-status> up </oper-status> <<SNIP>> <traffic-statistics junos:style="brief"> <input-packets> 251175 </input-packets> <output-packets> 260492 </output-packets> <<SNIP>> </traffic-statistics> </physical-interface> </interface-information> </nc:rpc-reply>
Configuration Change
NETCONF holds a datastore and that is known as candidate configuration. The candidate configuration datastore holds configuration objects (for example, CLI commands) that are not yet applied to the device. Configurations that are entered on the device that supports candidate configuration are not applied immediately. Instead, they are held in the candidate configuration and applied only when the commit operation is performed. The commit operation instructs the device to implement the configuration data that are contained in the candidate configuration. If the device does succeed in committing, the running configuration must be updated with the contents of the candidate configuration.
NETCONF supports multiple datastores as highlighted in below diagram, including a running, startup, and candidate configuration.
Configuration Change Example
In the following section we discuss how NETCONF is used to apply changes to a loopback interface.
Before applying configuration, let us capture the output below, which highlights openconfig interface configuration of loopback0 and no IP address configured on that interface.
lab> show configuration openconfig-interfaces:interfaces interface lo0 { config { name lo0; type idx:softwareLoopback; }
Next, we will configure a candidate database with a Loopback IP address of 1.1.1.3 and with a prefix-length of 32; highlighted in purple in step 1. Step 2 commits XML candidate config highlighted in red. In step 3, NETCONF is setting the interface and in step 4 NETCONF is committing the change.
Set IP Address On Loopback
#more js-oc-set-interface.xml <edit-config> <target> <candidate/> </target> <config> <interfaces xmlns="http://openconfig.net/yang/interfaces"> <interface> <name>lo0</name> <config> <name>lo0</name> <type xmlns:idx="urn:ietf:params:xml:ns:yang:iana-if-type">idx:softwareLoopback</type> </config> <subinterfaces> <subinterface> <index>0</index> <ipv4 xmlns="http://openconfig.net/yang/interfaces/ip"> <addresses> <address> <ip>1.1.1.3</ip> <config> <ip>1.1.1.3</ip> <prefix-length>32</prefix-length> </config> </address> </addresses> </ipv4> </subinterface> </subinterfaces> </interface> </interfaces> </config> </edit-config>
#more commit.xml <commit/>
#xargs -a js-connect netconf-console2 --rpc=js-oc-set-interface.xml <?xml version='1.0' encoding='UTF-8'?> <nc:rpc-reply xmlns:junos="http://xml.juniper.net/junos/23.2R1.13/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:9c0fe1f6-41fa-405a-9c09-8359817f8aa1"> <nc:ok/> </nc:rpc-reply>
#xargs -a js-connect netconf-console2 --rpc=commit.xml <?xml version='1.0' encoding='UTF-8'?> <nc:rpc-reply xmlns:junos="http://xml.juniper.net/junos/23.2R1.13/junos" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:3565bfc8-c6c7-4d68-a281-7dee9b7b2e17"> <output>kenv: unable to get vmtype</output> <nc:ok/> </nc:rpc-reply>
Post committing change, we can observe that IP Address 1.1.1.3 and prefix-length 32 has been applied to loopback 0 interface.
lab> show configuration openconfig-interfaces:interfaces interface lo0 { config { name lo0; type idx:softwareLoopback; } subinterfaces { subinterface 0 { openconfig-if-ip:ipv4 { addresses { address 1.1.1.3 { config { ip 1.1.1.3; prefix-length 32; } } } } } } } lab> ping 1.1.1.3 PING 1.1.1.3 (1.1.1.3): 56 data bytes 64 bytes from 1.1.1.3: icmp_seq=0 ttl=64 time=0.035 ms 64 bytes from 1.1.1.3: icmp_seq=1 ttl=64 time=0.067 ms ^C
Summary
NETCONF is a protocol developed by the Internet Engineering Task Force (IETF) to facilitate the management of network devices. It allows for the installation, manipulation, and deletion of the configuration of network devices. NETCONF is widely supported in modern network equipment and management systems, making it a key tool in network management and automation frameworks.
If you'd like to learn more about NETCONF protocols along with RESTCONF protocols and and YANG data models check out our webinar recording Fundamentals of Network Programmability. We are also running a training course on Network Automation which is free of charge to Service Providers and those who run their own network. More details and sign up button below: