Understanding the NETCONF XML Management Protocol

Benefits of NETCONF

NETCONF is a standards-based protocol that was developed specifically for managing network devices.
NETCONF uses secure, connection-oriented sessions that provide for authentication, data integrity, and confidentiality.
NETCONF is vendor agnostic, so you can use the same NETCONF base operations to manage devices from different vendors.

NETCONF XML Management Protocol Overview

The NETCONF XML management protocol is a standards-based protocol that is specifically tailored for communicating with and managing network devices. NETCONF uses a client/server model and remote procedure call (RPC)-based communication. A NETCONF client establishes a connection and NETCONF session with a NETCONF server and executes operations on the device. Junos devices integrate the NETCONF server into the OS, and thus the server does not appear as a separate entry in process listings.

NETCONF uses XML-based data encoding for the RPCs and configuration data. The NETCONF protocol defines basic operations that are equivalent to CLI configuration mode commands. Client applications use the protocol operations to display, edit, and commit configuration data (among other operations), just as administrators use the CLI configuration mode commands to perform those operations. Within a NETCONF session, client applications can also execute RPCs equivalent to Junos OS operational mode commands.

Conceptually, NETCONF can be divided into 4 layers. Table 1 describes the layers.

Table 1: NETCONF Layers
NETCONF Layer	Description
Transport	The transport layer facilitates the creation of sessions between the client and the server using various protocols.
Messages	The messages layer is a transport-independent framing mechanism for encoding RPCs and notifications. The tags include: `<rpc>`—Encapsulates RPCs sent to the NETCONF server. `<rpc-reply>`—Encapsulates RPC replies received from the NETCONF server, which can include data, `<ok/>` tags, and errors and warnings. `<notification>`—Encapsulates notification messages, which are one-way messages that the NETCONF server sends asynchronously to NETCONF clients that subscribe to notifications. For more information about NETCONF event notifications, see NETCONF Event Notifications.
Operations	The operations layer defines the protocol operations that you can perform on a network device. The operations comprise base protocol operations, for example, `<get-config>`, `<edit-config>`, and `<commit>`, as well as vendor-specific operations. A client application invokes the operations as RPCs and provides XML-encoded parameters. See the NETCONF Protocol Operations and Attributes section of this guide for more information about specific operations.
Content	The content layer contains the RPC request and response payloads in XML format. This layer defines the configuration data and the notification data.

Communication between the NETCONF server and a client application is session based. The server and client explicitly establish a connection and session before exchanging data. As defined by the transport layer, NETCONF can use any secure transport protocol that meets the necessary requirements. Junos devices support NETCONF sessions over SSH, outbound SSH, TLS, and outbound HTTPS, as well as NETCONF Call Home sessions over outbound SSH.

Each NETCONF session begins with a handshake, in which the server and client exchange <hello> tags that enclose their supported NETCONF capabilities. Within a NETCONF session, the client and server exchange messages, which contain RPCs, RPC replies, or notifications. The NETCONF operations layer defines the protocol operations that a client application can use to manage a device. The content layer describes the encoded parameters and data included in the RPCs. NETCONF and the Junos XML API Overview describes the content layer in more detail. After the client application finishes making requests, it closes the NETCONF session and connection.

A NETCONF client sends RPCs to the NETCONF server to request information, execute operational commands, or modify the configuration on a device. The NETCONF server processes the RPCs and sends RPC replies to the client. Depending on the request, RPC replies return requested information or indicate the success or failure of the requested operation.

For more information about NETCONF, see the following RFCS:

RFC 6241, Network Configuration Protocol (NETCONF)
RFC 6242, Using the NETCONF Protocol over Secure Shell (SSH)

NETCONF and the Junos XML API Overview

The Junos XML API is an XML representation of Junos OS configuration statements and operational mode commands. The Junos XML API defines an XML equivalent for all statements in the Junos OS configuration hierarchy and many of the commands that you issue in CLI operational mode. Each operational mode command with a Junos XML counterpart maps to a request tag element and, if necessary, a response tag element. Junos XML request tags are equivalent in function to the corresponding operational mode commands in the CLI.

NETCONF client applications can request information, execute operational commands, or modify the configuration on a Junos device. The client application encodes the request in NETCONF and Junos XML API tag elements and sends it to the NETCONF server on the device. The NETCONF server directs the request to the appropriate software modules, encodes the response in NETCONF and Junos XML API tag elements, and returns the result to the client application.

When a NETCONF client modifies the Junos OS configuration, the RPC content includes Junos XML configuration data. NETCONF clients can also send operational RPCs with the appropriate request tags to execute operational commands or retrieve information. The server returns the response using Junos XML API elements enclosed within the corresponding response tag element.

For example, to request information about the status of a device’s interfaces, a client application sends the Junos XML API <get-interface-information/> request tag.

The NETCONF server gathers the information from the interface process and returns it in the Junos XML API <interface-information> response tag element.

You can determine Junos XML API content in a number of ways. The Juniper Networks XML API Explorer enables you to browse Junos XML API elements. You can view the configuration elements and the operational request and response tags supported in a given OS and release.

Additionally, on Junos devices, you can use the pipe (|) operator in the CLI to view Junos XML API content. For example, to retrieve the operational request tag for a given command, issue command | display xml rpc in the CLI. The following example shows that the request tag for the show interfaces command is <get-interface-information>.

Similarly, to retrieve configuration data in XML format use the show configuration | display xml command.

You can use NETCONF and the Junos XML API to manage Junos devices. You can write client applications to interact with the NETCONF server. You can also use NETCONF to build custom end-user interfaces for configuration and information retrieval and display, such as a Web browser-based interface.

Advantages of Using NETCONF and the Junos XML API

NETCONF and the Junos XML API fully document all options for every supported Junos OS operational request and all elements in every Junos OS configuration statement. The tag names clearly indicate the function of an element in an operational request or configuration statement.

The combination of meaningful tag names and the structural rules in a DTD makes it easy to understand the content and structure of an XML-tagged data set. NETCONF and Junos XML tag elements make it straightforward for client applications to parse the device output to find and display specific information, as described in the following sections.

Parse Device Output
Display Device Output

Parse Device Output

The following example illustrates how the Junos XML API makes it easier to parse device output and extract the needed information. The example compares formatted ASCII and XML-tagged output from a device running Junos OS. The formatted ASCII output is:

The corresponding XML-tagged version is:

When a client application needs to extract a specific value from formatted ASCII output, it must rely on the value’s location, expressed either absolutely or with respect to labels or values in adjacent fields. Suppose that the client application wants to extract the interface index. It can use a regular-expression matching utility to locate specific strings, but the number of digits in the interface index is not necessarily predictable. The client application cannot simply read a certain number of characters after the Interface index: label. Instead, it must extract everything between the label and the subsequent label, which is:

A problem arises if the format or ordering of output changes in a later version of the Junos OS. For example, the output might add a Logical index field following the interface index number.

An application that extracts the interface index number delimited by the Interface index: and SNMP ifIndex labels now obtains an incorrect result. In this case, you must update the application to manually search for the following label instead:

In contrast, the structured nature of XML-tagged output enables a client application to retrieve the interface index by extracting everything within the opening <local-index> tag and closing </local-index> tag. The application does not have to rely on an element’s position in the output string. As a result, the NETCONF server can emit the child tag elements in any order within the <physical-interface> element. Adding a new <logical-index> element does not affect an application’s ability to locate the <local-index> element and extract its contents.

Display Device Output

XML-tagged output is also easier to transform into different display formats. For example, you might want to display different amounts of detail about a given device component at different times. When a device returns formatted ASCII output, you must write special routines and data structures in your application to extract the information needed for a given detail level. In contrast, the inherent structure of XML output is an ideal basis for a display program’s own structures. You can use the same extraction routine for several levels of detail, simply ignoring the tag elements that you don't need when displaying less detail.

ON THIS PAGE