NETCONF and YANG: De facto Network Management for SDN
By Suvendu Mozumdar |
Technology Overview
Network Configuration Protocol, better known as NETCONF, gives access to the native capabilities of a device within a network, defines methods to manipulate its configuration database, retrieves operational data, and invokes specific operations. YANG provides the means to define the content carried through NETCONF, for both data and operations. Together, they help users build network management applications that meet the needs of network operators.
Network diagram of a NETCONF management system
The motivation behind NETCONF and YANG was that instead of individual devices with functionalities, there is a need to have a network management system that manages the network at the service level, which includes the following:
- Standardized data model (YANG)
- Network-wide configuration transactions
- Validation and roll-back of configuration
- Centralized backup and restore configuration
Businesses have used SNMP for a long time, but it was being used more for reading device states than for configuring devices. NETCONF and YANG address the shortcomings of SNMP and add more functionalities in network management, such as the following:
- Configuration transactions: NETCONF configurations work based on atomic transactions consisting of multiple configuration commands required to move a network from state A to state B. The order of the configuration snippets within a transaction does not matter and the success of a transaction is based on the success of all the command snippets. If any single command fails, the entire transaction becomes a failure. So, there is no intermediate erroneous state, either it’s at state A (if any one command of the transaction fails) or at state B (if the transaction is successful as a whole).
- Network-wide orchestrated activation: There is a distinction between the distribution of a configuration to all the networking devices and the activation of it. For example, if the operator wants to configure a VPN over a network of devices all at one time, NETCONF provides the flexibility to distribute the configuration, validate it, lock all device configurations, commit the configuration, and unlock. This set of actions will result in enabling a VPN over the entire network at the same time, in an orchestrated, synchronized way.
- Network-level validation and roll-back: Each NETCONF server keeps a 'Candidate database' (in parallel to 'Running config database.') Using this candidate data store, a NETCONF Manager can implement a network-wide transaction by sending a configuration to the candidate of each device, validating the candidate, and if all participants are fine, telling them to commit the changes. If the results are not satisfactory, the Manager can ask to roll-back all devices.
- Save and restore configurations: NETCONF Manager can take a backup of the networking device configuration whenever needed and restore it by sending the saved configuration to any networking device.
With this brief overview about the technology, let us now discuss a test scenario to validate a NETCONF Server’s (networking devices) functionality and scalability using the IxNetwork product.
NETCONF Manager Test Scenario
Keeping in mind the features of NETCONF as discussed in the preceding sections, it’s important to test a NETCONF Server’s functionalities thoroughly. The important aspects of a NETCONF Server validation can be classified in the following categories:
- Validate the YANG model encoding of NETCONF operations (for example, <get>, <get-config>, or <edit-config>) received in Request XML messages (for example, ietf, openconf, or proprietary).
- Stress management plane with many concurrent NETCONF sessions and assess the impact to regular control plane and data plane operation of a network device.
- Measure the device response time of the NETCONF transaction.
Let’s describe a typical NETCONF Server test scenario in more detail.
- Test Objective: Measure the efficiency of the NETCONF Server in terms of the time it takes to respond to NETCONF Request XMLs when multiple concurrent NETCONF Client sessions are active.
- Test Topology: There are multiple NETCONF Clients and all of them are connected to a single NETCONF Server (DUT), as shown:
Test Steps: The test steps are noted as follows:
- The NETCONF Clients are preconfigured with a set of NETCONF Request XMLs as per the YANG model supported by the DUT. The XMLs have different types of command snippets like edit-config, get, and get-config.
- After the sessions are established, the NETCONF clients will start sending the NETCONF Request messages in the form of XML files and the Server is supposed to respond with the NETCONF Reply messages with the same XML format.
- Let’s assume the Clients have sent some Request messages and stopped sending thereafter.
- For each session, measure how much time (min, max, and average) the Server takes to send a Reply message after receiving a Request message.
- Now have the Clients resume sending the Request messages again at a higher transmission rate for a certain duration of time and measure how that affects the DUT’s response time under stress condition.
Test NETCONF/YANG with IxNetwork
To validate these scenarios, a test tool is very much needed that can emulate multiple NETCONF clients having sessions with the same NETCONF Server (DUT). IxNetwork NETCONF/YANG emulation offers a rich set of features that can help carry out the test scenario described earlier. The following is a summary of the various capabilities provided:
- Multiple SSH authentication mechanisms (username/password, key based).
- Wireshark support to show decrypted SSH data exchange.
Encrypted SSH Packet
Decrypted SSH Packet
- The client is agnostic to the YANG model supported by the Server (DUT). It takes pre-configured command snippet files (NETCONF Requests) in XML format as input and sends those to the NETCONF Servers. The XML can be written as per any YANG model.
- Send multiple XML files over each NETCONF session with user-defined order and duration to stress the management plan.
- Measures time taken by the DUT to respond to a received request. The following is a time diagram to explain the mechanism of how it is done:
- The Response time is measured in different levels as follows:
- Min/Max response time of the DUT as a whole.
- Min/Max/Average response time per the NETCONF session.
- Response time for each reply XML is also recorded within the reply XML.
- Record client-server interactions for post-processing, which helps to validate the YANG model encoding:
- Every command and corresponding replies.
- Reply XMLs and Errors stored and organized in a hierarchical order.
The following is an image of the IxNetwork NETCONF Emulation
NETCONF Command Snippet Configuration