NETCONF and YANG: De facto Network Management for SDN
Network Configuration Protocol, better known as NETCONF, gives access to the native capabilities of a device within a network, defining methods to manipulate its configuration database, retrieve operational data, and invoke specific operations. YANG provides the means to define the content carried via 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, instead of individual devices with functionalities, to have a network management system that manages the network at the service level that includes:
- 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:
- 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, now let us discuss a test scenario to validate a NETCONF Server’s (networking devices) functionality and scalability using Ixia’s IxNetwork product.
NETCONF Manager Test Scenario
Keeping in mind the features of NETCONF as discussed in the above 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 (e.g., <get>, <get-config>, <edit-config>) received in Request XML messages (e.g., 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 device response time of NETCONF transaction
Let’s describe a typical NETCONF Server test scenario in more detail.
- Test Objective: Measure the efficiency of 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, 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, get-config.
- Once sessions are established, NETCONF clients will start sending NETCONF Request messages in the form of XML files and the Server is supposed to respond with 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/average) the Server takes to send a Reply message after receiving a Request message.
- Now have the Clients resume sending 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 Ixia 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). Ixia IxNetwork NETCONF/YANG emulation offers a rich set of features that can help carry out the test scenario described above. Below 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. Shown below is a time diagram to explain the mechanism of how it is done.
- The Response time is measured in different levels as noted below:
- Min/Max response time of the DUT as a whole
- Min/Max/Average response time per 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 YANG model encoding:
- Every command and corresponding replies
- Reply XMLs/Errors stored and organized in a hierarchical order.
Find below a screenshot of the IxNetwork NETCONF Emulation
NETCONF Command Snippet Configuration
Check out the IxNetwork NETCONF Client Emulation Use Cases video