Network Configuration Protocol (NETCONF) is an XML-based network management protocol with filtering capabilities. It provides programmable mechanisms to manage and configure network devices. Through NETCONF, you can configure device parameters, retrieve parameter values, and get statistics information.

In NETCONF messages, each data item is contained in a fixed element. This enables different devices of the same vendor to provide the same access method and the same result presentation method. For the devices of different vendors, XML mapping in NETCONF messages can achieve the same effect. For a network environment containing different devices regardless of vendors, you can develop a NETCONF-based NMS system to configure and manage devices in a simple and effective way.

NETCONF structure

NETCONF has four layers: content layer, operations layer, RPC layer, and transport protocol layer.

Table 1 NETCONF layers and XML layers

NETCONF layer	XML layer	Description
Content	Configuration data, status data, and statistics information	The content layer contains a set of managed objects, which can be configuration data, status data, and statistics information. For information about the operable data, see the NETCONF XML API reference for the device.
Operations	<get>,<get-config>,<edit-config>…	The operations layer defines a set of base operations invoked as RPC methods with XML-encoded parameters. NETCONF base operations include data retrieval operations, configuration operations, lock operations, and session operations. For the device supported operations, see "Appendix A Supported NETCONF operations."
RPC	<rpc>,<rpc-reply>	The RPC layer provides a simple, transport-independent framing mechanism for encoding RPCs. The <rpc> and <rpc-reply> elements are used to enclose NETCONF requests and responses (data at the operations layer and the content layer).
Transport Protocol	· High encryption in non-FIPS mode: Console/Telnet/SSH/HTTP/HTTPS/TLS · High encryption in FIPS mode: Console/SSH/HTTPS/TLS	The transport protocol layer provides reliable, connection-oriented, serial data links. For high encryption in non-FIPS mode, the following login methods are available: · You can log in through Telnet, SSH, or the console port to perform NETCONF operations at the CLI. · You can log in through HTTP or HTTPS to perform NETCONF operations in the Web interface or perform NETCONF-over-SOAP operations. For high encryption in FIPS mode, all login methods are the same as in non-FIPS mode except that you cannot use HTTP or Telnet.

NETCONF message format

NETCONF

IMPORTANT:

When configuring NETCONF in XML view, you must add the end mark "]]>]]>" at the end of an XML message. Otherwise, the device cannot identify the message. Examples in this chapter do not have this end mark. Do add it in actual operations.

All NETCONF messages are XML-based and comply with RFC 4741. Any incoming NETCONF messages must pass XML Schema check before it can be processed. If a NETCONF message fails XML Schema check, the device sends an error message to the client.

For information about the NETCONF operations supported by the device and the operable data, see the NETCONF XML API reference for the device.

The following example shows a NETCONF message for getting all parameters of all interfaces on the device:

<?xml version="1.0" encoding="utf-8"?>

<get-bulk>

<Ifmgr>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get-bulk>

</rpc>

IMPORTANT:

Exclude the first line <?xml version="1.0" encoding="UTF-8"?> from a NETCONF message in actual operations. This line only illustrates the encoding format of NETCONF messages.

NETCONF over SOAP

All NETCONF over SOAP messages are XML-based and comply with RFC 4741. NETCONF messages are contained in the <Body> element of SOAP messages. NETCONF over SOAP messages also comply with the following rules:

· SOAP messages must use the SOAP Envelope namespaces.

· SOAP messages must use the SOAP Encoding namespaces.

· SOAP messages cannot contain the following information:

¡ DTD reference.

¡ XML processing instructions.

The following example shows a NETCONF over SOAP message for getting all parameters of all interfaces on the device:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Header>

<auth:Authentication env:mustUnderstand="1" xmlns:auth="http://www.h3c.com/netconf/base:1.0">

<auth:AuthInfo>800207F0120020C</auth:AuthInfo>

</auth:Authentication>

</env:Header>

<env:Body>

<get-bulk>

<Ifmgr>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get-bulk>

</rpc>

</env:Body>

</env:Envelope>

How to use NETCONF

You can use NETCONF to manage and configure the device by using the methods in Table 2.

Table 2 NETCONF methods for configuring the device

Configuration tool	Login method	Remarks
CLI	· Console port · SSH · Telnet	To implement NETCONF operations, copy valid NETCONF messages to the CLI in XML view. This method is suitable for R&D and test purposes.
Standard Web interface for the device	· High encryption in FIPS mode: HTTPS · High encryption in non-FIPS mode: ¡ HTTP ¡ HTTPS	The system automatically converts the configuration operations on the Web interface to NETCONF messages and sends them to the device to implement NETCONF operations. This method is the most commonly used method.
Custom Web interface	N/A	To use this method, you must enable NETCONF over SOAP. By default, the device cannot interpret custom Web interfaces' URLs. For the device to interpret these URLs, you must encode the NETCONF messages sent from a custom Web interface in SOAP.

Protocols and standards

· RFC 3339, Date and Time on the Internet: Timestamps

· RFC 4741, NETCONF Configuration Protocol

· RFC 4742, Using the NETCONF Configuration Protocol over Secure SHell (SSH)

· RFC 4743, Using NETCONF over the Simple Object Access Protocol (SOAP)

· RFC 5277, NETCONF Event Notifications

· RFC 5381, Experience of Implementing NETCONF over SOAP

· RFC 5539, NETCONF over Transport Layer Security (TLS)

· RFC 6241, Network Configuration Protocol

FIPS compliance

The device supports the FIPS mode that complies with NIST FIPS 140-2 requirements. Support for features, commands, and parameters might differ in FIPS mode (see Security Configuration Guide) and non-FIPS mode.

NETCONF configuration task list

Task at a glance
(Optional.) Enabling NETCONF over SOAP
(Optional.) Enabling NETCONF over SSH
(Optional.) Enabling NETCONF logging
(Required.) Establishing a NETCONF session
(Optional.) Subscribing to event notifications
(Optional.) Locking/unlocking the configuration
(Optional.) Performing the get/get-bulk operation
(Optional.) Performing the get-config/get-bulk-config operation
(Optional.) Performing the edit-config operation
(Optional.) Rolling back the configuration based on a rollback point
(Optional.) Saving, rolling back, and loading the configuration
(Optional.) Filtering data
(Optional.) Performing CLI operations through NETCONF
(Optional.) Retrieving NETCONF session information
(Optional.) Terminating another NETCONF session
(Optional.) Returning to the CLI

Enabling NETCONF over SOAP

NETCONF messages can be encapsulated into SOAP messages and transmitted over HTTP and HTTPS. After enabling NETCONF over SOAP, you can develop Web configuration interface to perform NETCONF operations.

To enable NETCONF over SOAP:

Step	Command	Remark
1. Enter system view.	system-view	N/A
2. Enable NETCONF over SOAP.	· Enable NETCONF over SOAP over HTTP (not available for high encryption in FIPS mode): netconf soap http enable · Enable NETCONF over SOAP over HTTPS: netconf soap https enable	By default, the NETCONF over SOAP feature is disabled.
3. Set the DSCP value for NETCONF over SOAP packets.	· Set the DSCP value for NETCONF over SOAP over HTTP packets: netconf soap http dscp dscp-value · Set the DSCP value for NETCONF over SOAP over HTTPS packets: netconf soap https dscp dscp-value	By default, the DSCP value is 0 for NETCONF over SOAP packets.

Enabling NETCONF over SSH

This feature uses a client to perform NETCONF operations on the device through a NETCONF over SSH connection.

To enable NETCONF over SSH:

Step	Command	Remark
1. Enter system view.	system-view	N/A
2. Enable NETCONF over SSH.	netconf ssh server enable	By default, NETCONF over SSH is disabled.
3. Specify a port to listen for NETCONF over SSH connections.	netconf ssh server port port-number	By default, port 830 listens for NETCONF over SSH connections.

Enabling NETCONF logging

NETCONF logging generates logs for different NETCONF operation sources and NETCONF operations.

To enable NETCONF logging:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable NETCONF logging.	netconf log source { all \| { agent \| soap \| web } * } { { protocol-operation { all \| { action \| config \| get \| set \| session \| syntax \| others } * } } \| verbose }	By default, NETCONF logging is disabled.

Establishing a NETCONF session

A client must send a hello message to a device to complete the capabilities exchange before the device processes other requests from the client.

You can use the aaa session-limit command (see Security Command Reference) to set the maximum number of NETCONF sessions that the device can support. If the upper limit is reached, new NETCONF users cannot access the device.

Entering XML view

Task	Command	Remarks
Enter XML view.	xml	Available in user view.

Exchanging capabilities

After you enter XML view, the client and the device exchange their capabilities before you can perform subsequent operations. The device automatically advertises its NETCONF capabilities to the client in a hello message as follows:

<?xml version="1.0" encoding="UTF-8"?><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:params:netconf:base:1.1</capability><capability>urn:ietf:params:netconf:writable-running</capability><capability>urn:ietf:params:netconf:capability:notification:1.0</capability><capability>urn:ietf:params:netconf:capability:validate:1.1</capability><capability>urn:ietf:params:netconf:capability:interleave:1.0</capability><capability>urn:h3c:params:netconf:capability:h3c-netconf-ext:1.0</capability></capabilities><session-id>1</session-id></hello>]]>]]>

The <capabilities> parameter represents the capabilities supported by the device.

The <session-id> parameter represents the unique ID assigned to the current session.

After receiving the hello message from the device, copy the following message to notify the device of the capabilities (user-configurable) supported by the client:

capability-set

</capability>

</capabilities>

</hello>

capability-set represents the capabilities supported by the client. Use a pair of <capability> and </capability> tags to enclose a capability.

Subscribing to event notifications

After you subscribe to event notifications, the device sends event notifications to the NETCONF client when a subscribed event takes place on the device. The notifications include the code, group, severity, start time, and description of the events. The device supports only log subscription. For information about which event notifications you can subscribe to, see the system log messages reference for the device.

A subscription takes effect only on the current session. If the session is terminated, the subscription is automatically canceled.

You can send multiple subscription messages to subscribe to notification of multiple events.

Subscription procedure

# Copy the following message to the client to complete the subscription:

<event:create-subscription xmlns:event="urn:ietf:params:xml:ns:netconf:notification:1.0"/>

</rpc>

The <event> parameter represents an event to which you have subscribed.

After receiving the subscription request from the client, the device returns a response in the following format if the subscription is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

If the subscription fails, the device returns an error message in the following format:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<rpc-error>

<error-type>error-type</error-type>

<error-tag>error-tag</error-tag>

<error-severity>error-severity</error-severity>

<error-message xml:lang="en">error-message</error-message>

</rpc-error>

</rpc-reply>

For more information about error messages, see RFC 4741.

Example for subscribing to event notifications

Network requirements

Configure a client to subscribe to all events with no time limitation. After the subscription is successful, all events on the device are sent to the client before the session between the device and client is terminated.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Subscribe to all events with no time limitation.

<create-subscription xmlns ="urn:ietf:params:xml:ns:netconf:notification:1.0">

<stream>NETCONF</stream>

</create-subscription>

</rpc>

Verifying the configuration

# If the client receives the following response, the subscription is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

<ok/>

</rpc-reply>

# If fan 1 on the device encounters problems, the device sends the following text to the client that has subscribed to all events:

<?xml version="1.0" encoding="UTF-8"?>

<Code>FAN_DIRECTION_NOT_PREFERRED</Code>

<Severity>Alert</Severity>

<context>Fan 1 airflow direction is not preferred on slot 6, please check it.</context>

</event>

</notification>

# When another client (192.168.100.130) logs in to the device, the device sends a notification to the client that has subscribed to all events:

<?xml version="1.0" encoding="UTF-8"?>

<Group>SHELL</Group>

<Code>SHELL_LOGIN</Code>

<Severity>Notification</Severity>

<context>VTY logged in from 192.168.100.130.</context>

</event>

</notification>

Locking/unlocking the configuration

The device supports multiple users to simultaneously manage and monitor the device using NETCONF. During device configuration and maintenance or network troubleshooting, a user can lock the configuration to prevent other users from changing it. After that, only the user holding the lock can change the configuration, and other users can only read the configuration.

In addition, only the user holding the lock can release the lock. After the lock is released, other users can change the current configuration or lock the configuration. If the session of the user that holds the lock is terminated, the system automatically releases the lock.

Locking the configuration

# Copy the following text to the client to lock the configuration:

<?xml version="1.0" encoding="UTF-8"?>

<lock>

</target>

</lock>

</rpc>

After receiving the lock request, the device returns a response in the following format if the lock operation is successful:

<?xml version="1.0" encoding="UTF-8" ?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Unlocking the configuration

# Copy the following text to the client to unlock the configuration:

<?xml version="1.0" encoding="UTF-8"?>

</target>

</unlock>

</rpc>

After receiving the unlock request, the device returns a response in the following format if the unlock operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Example for locking the configuration

Network requirements

Lock the device configuration so that other users cannot change the device configuration.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Lock the configuration.

<?xml version="1.0" encoding="UTF-8"?>

<lock>

</target>

</lock>

</rpc>

Verifying the configuration

If the client receives the following response, the lock operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

If another client sends a lock request, the device returns the following response:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<rpc-error>

<error-type>protocol</error-type>

<error-tag>lock-denied</error-tag>

<error-severity>error</error-severity>

<error-message xml:lang="en">Lock failed, lock is already held.</error-message>

<error-info>

<session-id>1</session-id>

</error-info>

</rpc-error>

</rpc-reply>

The output shows that the lock operation failed because the client with session ID 1 held the lock, and only the client holding the lock can release the lock.

Performing service operations

You can use NETCONF to perform service operations on the device, such as retrieving and modifying the specified information. The basic operations include get, get-bulk, get-config, get-bulk-config, and edit-config, which are used to retrieve all data, retrieve configuration data, and edit the data of the specified module. For more information, see the NETCONF XML API reference for the device.

Performing the get/get-bulk operation

The get operation is used to retrieve device configuration and state information that match the conditions. In some cases, this operation leads to inefficiency.

The get-bulk operation is used to retrieve a number of data entries starting from the data entry next to the one with the specified index. One data entry contains a device configuration entry and a state information entry. The data entry quantity is defined by the count attribute, and the index is specified by the index attribute. The returned output does not include the index information. If you do not specify the index attribute, the index value starts with 1 by default.

The get-bulk operation retrieves all the rest data entries starting from the data entry next to the one with the specified index if either of the following conditions occurs:

· You do not specify the count attribute.

· The number of matching data entries is less than the value of the count attribute.

# Copy the following text to the client to perform the get operation:

<?xml version="1.0" encoding="UTF-8"?>

<getoperation>

Specify the module, submodule, table name, and column name

</top>

</filter>

</getoperation>

</rpc>

The <getoperation> parameter can be <get> or <get-bulk>. The <filter> element is used to filter data, and it can contain module name, submodule name, table name, and column name.

· If the module name and the submodule name are not provided, the operation retrieves the data for all modules and submodules. If a module name or a submodule name is provided, the operation retrieves the data for the specified module or submodule.

· If the table name is not provided, the operation retrieves the data for all tables. If a table name is provided, the operation retrieves the data for the specified table.

· If only the index column is provided, the operation retrieves the data for all columns. If the index column and other columns are provided, the operation retrieves the data for the index column and the specified columns.

The <get> and <get-bulk> messages are similar. A <get-bulk> message carries the count and index attributes. The following is a <get-bulk> message example:

<?xml version="1.0" encoding="UTF-8" ?>

<get-bulk>

<Log>

</Log>

</Logs>

</Syslog>

</top>

</filter>

</get-bulk>

</rpc>

The count attribute complies with the following rules:

· The count attribute can be placed in the module node and table node. In other nodes, it cannot be resolved.

· When the count attribute is placed in the module node, a descendant node inherits this count attribute if the descendant node does not contain the count attribute.

Verifying the configuration

After receiving the get-bulk request, the device returns a response in the following format if the operation is successful:

<?xml version="1.0"?>

<rpc-reply message-id="100"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<data>

Device state and configuration data

</data>

</rpc-reply>

Performing the get-config/get-bulk-config operation

The get-config and get-bulk-config operations are used to retrieve all non-default configurations, which are configured by means of CLI, MIB, and Web. The <get-config> and <get-bulk-config> messages can contain the <filter> element for filtering data.

The <get-config> and <get-bulk-config> messages are similar. The following is a <get-config> message example:

<?xml version="1.0"?>

<get-config>

</source>

Specify the module name, submodule name, table name, and column name

</top>

</filter>

</get-config>

</rpc>

Verifying the configuration

After receiving the get-config request, the device returns a response in the following format if the operation is successful:

<?xml version="1.0"?>

<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<data>

All data matching the specified filter

</data>

</rpc-reply>

Performing the edit-config operation

The edit-config operation supports the following operation attributes: merge, create, replace, remove, delete, default-operation, error-option, and test-option. For more information about these attributes, see "Appendix A Supported NETCONF operations."

# Copy the following text to perform the <edit-config> operation:

<?xml version="1.0"?>

<edit-config>

<error-option>

Default operation when an error occurs

</error-option>

Specify the module name, submodule name, table name, and column name

</top>

</config>

</edit-config>

</rpc>

After receiving the edit-config request, the device returns a response in the following format if the operation is successful:

<?xml version="1.0">

<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

# Perform the get operation to verify that the current value of the parameter is the same as the value specified through the edit-config operation. (Details not shown.)

All-module configuration data retrieval example

Network requirements

Retrieve configuration data for all modules.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Retrieve configuration data for all modules.

<rpc message-id="100"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<get-config>

</source>

</get-config>

</rpc>

Verifying the configuration

If the client receives the following text, the get-config operation is successful:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

<data>

<Ifmgr>

</Interface>

</Interface>

</Interface>

</Interface>

</Interface>

</Interfaces>

</Ifmgr>

</LogBuffer>

</Syslog>

<ZoneName>beijing</ZoneName>

</TimeZone>

</Device>

</System>

<WebUI>

</WebUI>

</Fundamentals>

</top>

</data>

</rpc-reply>

Syslog configuration data retrieval example

Network requirements

Retrieve configuration data for the Syslog module.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Retrieve configuration data for the Syslog module.

<rpc message-id="100"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<get-config>

</source>

</top>

</filter>

</get-config>

</rpc>

Verifying the configuration

If the client receives the following text, the get-config operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

<data>

</LogBuffer>

</Syslog>

</top>

</data>

</rpc-reply>

Example for retrieving a data entry for the interface table

Network requirements

Retrieve a data entry for the interface table.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

<capability>urn:ietf:params:netconf:base:1.0</capability>

</capabilities>

</hello>

# Retrieve a data entry for the interface table.

<get-bulk>

<Ifmgr>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get-bulk>

</rpc>

Verifying the configuration

If the client receives the following text, the get-bulk operation is successful:

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

<data>

<Ifmgr>

<Name>GigabitEthernet1/0/2</Name>

<Description>GigabitEthernet 1/0/2 Interface</Description>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</data>

</rpc-reply>

Example for changing the value of a parameter

Network requirements

Change the log buffer size for the Syslog module to 512.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

<capability>urn:ietf:params:netconf:base:1.0</capability>

</capabilities>

</hello>

# Change the log buffer size for the Syslog module to 512.

<edit-config>

</target>

</LogBuffer>

</Syslog>

</top>

</config>

</edit-config>

</rpc>

Verifying the configuration

If the client receives the following text, the edit-config operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Rolling back the configuration based on a rollback point

You can roll back the configuration based on a rollback point when one of the following situations occurs:

· A NETCONF client sends a rollback request.

· A NETCONF client stays idle longer than the rollback idle timeout time.

· A NETCONF client is disconnected from the device.

NOTE:

NETCONF uses the save-point operation to configure a rollback point.

To roll back the configuration based on a rollback point, perform the following tasks:

1. Lock the system.

Multiple users might simultaneously use NETCONF to configure the device. As a best practice, lock the system before rolling back the configuration to prevent other users from modifying the running configuration.

2. Configure a rollback point. For more information, see "Configuring a rollback point."

3. Edit the device configuration. For more information, see "Performing the edit-config operation."

4. Accept the configuration or roll back the configuration based on the rollback point. For more information, see "Performing the save-point/commit operation" or"Performing the save-point/rollback operation."

The configuration can also be rolled back automatically when the NETCONF session idle time exceeds the rollback idle timeout time.

5. Release the lock.

Configuring a rollback point

# Copy the following text to the client to configure a rollback point:

<save-point>

<begin>

<confirm-timeout>100</confirm-timeout>

</begin>

</save-point>

</rpc>

The <confirm-timeout> parameter specifies the rollback idle timeout time in the range of 1 to 65536 seconds (the default is 600 seconds). This parameter is optional.

A NETCONF session can have only one rollback point. To change a rollback point for a session, you must perform one of the following tasks:

· Delete the rollback point and reconfigure it.

· Configure a new rollback point after the rollback idle timeout time expires.

After receiving the save-point request, the device returns a response in the following format if the rollback point is successfully configured:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

</rpc-reply>

Performing the save-point/rollback operation

# Copy the following text to the client to roll back the configuration:

<save-point>

</rollback>

</save-point>

</rpc>

After receiving the rollback request, the device returns a response in the following format if the rollback operation is successful:

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

</rpc-reply>

Performing the save-point/commit operation

# Copy the following text to the client to accept the configuration:

<save-point>

</commit>

</save-point>

</rpc>

After receiving the commit request, the device returns a response in the following format if the commit operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

<data>

<save-point>

<commit-id>4</commit-id>

</commit>

</save-point>

</data>

</rpc-reply>

Saving, rolling back, and loading the configuration

Use NETCONF to save, roll back, or load the configuration.

Saving the configuration

# Copy the following text to the client to save the device configuration to the specified file:

<?xml version="1.0" encoding="UTF-8"?>

<file>Specify the configuration file name</file>

</save>

</rpc>

The name of the specified configuration file must start with the storage media name and end with the extension .cfg. If the file name is not specified, the configuration is saved to the main next-startup configuration file by default.

If AllMDC is set to true in the management MDC, the configuration of each MDC is separately saved in the specified file. If AllMDC is not specified, only the configuration of the current MDC is saved. This attribute takes effect only on the management MDC.

After receiving the save request, the device returns a response in the following format if the save operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Rolling back the configuration

# Copy the following text to the client to roll back the configuration:

<?xml version="1.0" encoding="UTF-8"?>

<file>Specify the configuration file name</file>

</rollback>

</rpc>

After receiving the rollback request, the device returns a response in the following format if the rollback operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Loading the configuration

After you perform the load operation, the loaded configurations are merged into the current configuration as follows:

· New configurations are directly loaded.

· Configurations that already exist in the current configuration are replaced by those loaded from the configuration file.

# Copy the following text to the client to load a configuration file for the device:

<?xml version="1.0" encoding="UTF-8"?>

<load>

<file>Specify the configuration file name</file>

</load>

</rpc>

After receiving the load request, the device returns a response in the following format if the load operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Example for saving the configuration

Network requirements

Save the current configuration to the configuration file my_config.cfg.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Save the configuration of the device to the configuration file my_config.cfg.

<?xml version="1.0" encoding="UTF-8"?>

<save>

<file> my_config.cfg</file>

</save>

</rpc>

Verifying the configuration

If the client receives the following response, the save operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Filtering data

You can define a filter with the <filter> element to filter information when you perform a get, get-bulk, get-config, or get-bulk-config operation. Data filtering mechanisms include full match, regular expression match, and conditional match. Full match has the highest priority and conditional match has the lowest priority. When more than one filtering criteria is specified, the one with the highest priority takes effect.

· Full match

You can specify an element value in an XML message to implement full match. If multiple element values are provided, the system returns the data that matches all the specified values.

# Copy the following text to the client to retrieve configuration data of all interfaces in UP state:

<get>

<Ifmgr>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get>

</rpc>

You can also specify an attribute name that is the same as a column name of the current table at the row to implement full match. The system returns only configuration data that matches this attribute name. The XML message equivalent to the above element-value-based full match is as follows:

<get>

<Ifmgr>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get>

</rpc>

The above examples show that both element-value-based full match and attribute-name-based full match can retrieve the same configuration data for all UP interfaces.

· Regular expression match

To implement a complex data filtering with characters, you can add a regExp attribute for a specific element.

# Copy the following text to the client to retrieve the descriptions of interfaces, of which all the characters must be upper-case letters from A to Z:

<get-config>

</source>

<Ifmgr>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get-config>

</rpc>

· Conditional match

To implement a complex data filtering with digits and character strings, you can add a match attribute for a specific element. Table 3 lists the conditional match operators.

Table 3 Conditional match operators

Operation	Operator	Remarks
More than	match="more:value"	More than the specified value. The supported data types include date, digit, and character string.
Less than	match="less:value"	Less than the specified value. The supported data types include date, digit, and character string.
Not less than	match="notLess:value"	Not less than the specified value. The supported data types include date, digit, and character string.
Not more than	match="notMore:value"	Not more than the specified value. The supported data types include date, digit, and character string.
Equal	match="equal:value"	Equal to the specified value. The supported data types include date, digit, character string, OID, and BOOL.
Not equal	match="notEqual:value"	Not equal to the specified value. The supported data types include date, digit, character string, OID, and BOOL.
Include	match="include:string"	Includes the specified string. The supported data types include only character string.
Not include	match="exclude:string"	Excludes the specified string. The supported data types include only character string.
Start with	match="startWith:string"	Starts with the specified string. The supported data types include character string and OID.
End with	match="endWith:string"	Ends with the specified string. The supported data types include only character string.

# Copy the following text to the client to retrieve extension information about the entity whose CPU usage is more than 50%:

<get>

</Entity>

</ExtPhysicalEntities>

</Device>

</top>

</filter>

</get>

</rpc>

Example for filtering data with regular expression match

Network requirements

Retrieve all data including colons in the Description column of the Interfaces table under the Ifmgr module.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Retrieve all data including colons in the Description column of the Interfaces table under the Ifmgr module.

<?xml version="1.0"?>

<rpc message-id="100"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:reg="http://www.h3c.com/netconf/base:1.0">

<get>

<Ifmgr>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get>

</rpc>

Verifying the configuration

If the client receives the following text, the operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:reg="http://www.h3c.com/netconf/base:1.0" message-id="100">

<data>

<Ifmgr>

<Description>Ten-GigabitEthernet1/0/49:1 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/49:2 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/49:3 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/49:4 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/50:1 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/50:2 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/50:3 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/50:4 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/51:1 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/51:2 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/51:3 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet1/0/51:4 Interface</Description>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</data>

</rpc-reply>

Example for filtering data by conditional match

Network requirements

Retrieve data in the Name column with the ifindex value not less than 5000 in the Interfaces table under the Ifmgr module.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Retrieve data in the Name column with the ifindex value not less than 5000 in the Interfaces table under the Ifmgr module.

<rpc message-id="100"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="http://www.h3c.com/netconf/base:1.0">

<get>

<Ifmgr>

<Name/>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get>

</rpc>

Verifying the configuration

If the client receives the following text, the operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="http://www.h3c.com/netconf/base:1.0" message-id="100">

<data>

<Ifmgr>

</Interface>

<Name>Register-Tunnel0</Name>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</data>

</rpc-reply>

Performing CLI operations through NETCONF

You can enclose command lines in XML messages to configure the device.

Configuration procedure

# Copy either of the following texts depending on the command type:

· Copy the following text to the client to execute configuration commands:

<?xml version="1.0" encoding="UTF-8"?>

<CLI>

Commands

</Configuration >

</CLI>

</rpc>

The <Configuration> element can contain multiple commands, with one command on one line.

The following example shows a message for entering probe view:

<CLI>

probe

</Configuration>

</CLI>

</rpc>

· Copy the following text to the client to execute display commands:

<?xml version="1.0" encoding="UTF-8"?>

<CLI>

Commands

</Execution>

</CLI>

</rpc>

The <Execution> element can contain multiple commands, with one command on one line.

The following example shows a message for displaying device version information:

<CLI>

display version

</Execution>

</CLI>

</rpc>

After receiving the CLI operation request, the device returns a response in the following format if the CLI operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<CLI>

<![CDATA[Responses to the commands]]>

</Execution>

</CLI>

</rpc-reply>

CLI operation example

Configuration requirements

Send the display current-configuration command to the device.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Copy the following text to the client to execute the display current-configuration command:

<?xml version="1.0" encoding="UTF-8"?>

<CLI>

display current-configuration

</Execution>

</CLI>

</rpc>

Verifying the configuration

If the client receives the following text, the operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<CLI>

<Execution><![CDATA[

version 7.1.052, Demo 2501005

sysname ab

ftp server enable

ftp update fast

ftp timeout 2000

irf mac-address persistent timer

irf auto-update enable

undo irf link-delay

domain default enable system

telnet server enable

vlan 1

vlan 1000

radius scheme system

primary authentication 127.0.0.1 1645

]]>

</Execution>

</CLI>

</rpc-reply>

Retrieving NETCONF session information

You can use the get-sessions operation to retrieve NETCONF session information of the device.

# Copy the following message to the client to retrieve NETCONF session information from the device:

<?xml version="1.0" encoding="UTF-8"?>

<get-sessions/>

</rpc>

After receiving the get-sessions request, the device returns a response in the following format if the get-sessions operation is successful:

<?xml version="1.0" encoding="UTF-8" ?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<get-sessions>

<SessionID>Configuration session ID </SessionID>

<Line>line information</Line>

<UserName>Name of the use creating the session</UserName>

<Since>Time when the session was created</Since>

<LockHeld>Whether the session holds a lock</LockHeld>

</Session>

</get-sessions>

</rpc-reply>

For example, to get NETCONF session information:

# Enter XML view.

<Sysname> xml

# Copy the following message to the client to exchange capabilities with the device:

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Copy the following message to the client to get the current NETCONF session information on the device:

<?xml version="1.0" encoding="UTF-8"?>

<get-sessions/>

</rpc>

If the client receives a message as follows, the operation is successful:

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">

<get-sessions>

<LockHeld>false</LockHeld>

</Session>

</get-sessions>

</rpc-reply>

The output shows the following information:

· The session ID of an existing NETCONF session is 1.

· The login user type is vty0.

· The login time is 2011-01-05T00:24:57.

· The user does not hold the lock of the configuration.

Terminating another NETCONF session

NETCONF allows one client to terminate the NETCONF session of another client. The client whose session is terminated returns to user view.

# Copy the following message to the client to terminate the specified NETCONF session:

<kill-session>

<session-id>

Specified session-ID

</session-id>

</kill-session>

</rpc>

After receiving the kill-session request, the device returns a response in the following format if the kill-session operation is successful:

<?xml version="1.0" encoding="UTF-8" ?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Configuration example

Configuration requirement

The user whose session's ID is 1 terminates the session with session ID 2.

Configuration procedure

# Enter XML view.

<Sysname> xml

# Exchange capabilities.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Terminate the session with session ID 2.

<kill-session>

<session-id>2</session-id>

</kill-session>

</rpc>

Verifying the configuration

If the client receives the following text, the NETCONF session with session ID 2 has been terminated, and the client with session ID 2 has returned from XML view to user view:

<?xml version="1.0" encoding="UTF-8" ?>

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Returning to the CLI

To return from XML view to the CLI, send the following close-session request:

<close-session/>

</rpc>

When the device receives the close-session request, it sends the following response and returns to CLI's user view:

<?xml version="1.0" encoding="UTF-8" ?>

<rpc-reply message-id="101"

xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Appendix

Appendix A Supported NETCONF operations

Table 4 lists the NETCONF operations available with Comware 7.

Table 4 NETCONF operations

Operation	Description	XML example
get	Retrieves device configuration and state information.	To retrieve device configuration and state information for the Syslog module: <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="http://www.h3c.com/netconf/base:1.0"> <get> <filter type="subtree"> <top xmlns="http://www.h3c.com/netconf/data:1.0" > <Syslog> </Syslog> </top> </filter> </get> </rpc>
get-config	Retrieves the non-default configuration data. If non-default configuration data does not exist, the device returns a response with empty data.	To retrieve non-default configuration data for the interface table: <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="http://www.h3c.com/netconf/base:1.0"> <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns="http://www.h3c.com/netconf/config:1.0"> <Ifmgr> <Interfaces> <Interface/> </Interfaces> </Ifmgr> </top> </filter> </get-config> </rpc>
get-bulk	Retrieves a number of data entries (including device configuration and state information) starting from the data entry next to the one with the specified index.	To retrieve device configuration and state information for all interface: <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-bulk> <filter type="subtree"> <top xmlns="http://www.h3c.com/netconf/data:1.0"> <Ifmgr> <Interfaces> <Interface/> </Interfaces> </Ifmgr> </top> </filter> </get-bulk> </rpc>
get-bulk-config	Retrieves a number of non-default configuration data entries starting from the data entry next to the one with the specified index.	To retrieve non-default configuration for all interfaces: <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > <get-bulk-config> <source> <running/> </source> <filter type="subtree"> <top xmlns="http://www.h3c.com/netconf/config:1.0"> <Ifmgr> </Ifmgr> </top> </filter> </get-bulk-config> </rpc>
edit-config: merge	Changes the running configuration. To use the merge attribute in the edit-config operation, you must specify the operation target (on a specified level): · If the specified target exists, the operation directly changes the configuration for the target. · If the specified target does not exist, the operation creates and configures the target. · If the specified target does not exist and it cannot be created, an error message is returned.	To change the buffer size to 120: <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <top xmlns="http://www.h3c.com/netconf/config:1.0"> <Syslog xmlns="http://www.h3c.com/netconf/config:1.0" xc:operation="merge"> <LogBuffer> <BufferSize>120</BufferSize> </LogBuffer> </Syslog> </top> </config> </edit-config> </rpc>
edit-config: create	Creates a specified target. To use the create attribute in the edit-config operation, you must specify the operation target. · If the table supports target creation and the specified target does not exist, the operation creates and then configures the target. · If the specified target exists, a data-exist error message is returned.	The XML data format is the same as the edit-config message with the merget attribute. Change the operation attribute from merge to create.
edit-config: replace	Replaces the specified target. · If the specified target exists, the operation replaces the configuration of the target with the configuration carried in the message. · If the specified target does not exist but is allowed to be created, create the target and then apply the configuration of the target. · If the specified target does not exist and is not allowed to be created, the operation is not conducted and an invalid-value error message is returned.	The syntax is the same as the edit-config message with the merget attribute. Change the operation attribute from merge to replace.
edit-config: remove	Removes the specified configuration. · If the specified target has only the table index, the operation removes all configuration of the specified target, and the target itself. · If the specified target has the table index and configuration data, the operation removes the specified configuration data of this target. · If the specified target does not exist, or the XML message does not specify any targets, a success message is returned.	The syntax is the same as the edit-config message with the merget attribute. Change the operation attribute from merge to remove.
edit-config: delete	Deletes the specified configuration. · If the specified target has only the table index, the operation removes all configuration of the specified target, and the target itself. · If the specified target has the table index and configuration data, the operation removes the specified configuration data of this target. · If the specified target does not exist, an error message is returned, showing that the target does not exist.	The syntax is the same as the edit-config message with the merget attribute. Change the operation attribute from merge to delete.
edit-config: default-operation	Modifies the current configuration of the device using the default operation method. If you do not specify an operation attribute for an edit-config message, NETCONF uses one of the following default operation attributes: merge, create, delete, and replace. Your setting of the value for the <default-operation> element takes effect only once. If you do not specify an operation attribute and the default operation method for an <edit-config> message, merge is always applied. · merge—The default value for the <default-operation> element. · replace—Value used when the operation attribute is not specified and the default operation method is specified as replace. · none—Value used when the operation attribute is not specified and the default operation method is specified as none. If this value is specified, the edit-config operation is used only for schema verification rather than issuing a configuration. If the schema verification is passed, a successful message is returned. Otherwise, an error message is returned.	To issue an empty operation for schema verification purposes: <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <default-operation>none</default-operation> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns="http://www.h3c.com/netconf/config:1.0"> <Ifmgr> <Interfaces> <Interface> <IfIndex>262</IfIndex> <Description>222222</Description> </Interface> </Interfaces> </Ifmgr> </top> </config> </edit-config> </rpc>
edit-config: error-option	Determines the action to take in case of a configuration error. The error-option element has one of the following values: · stop-on-error—Stops the operation on error and returns an error message. This is the default error-option value. · continue-on-error—Continues the operation on error and returns an error message. · rollback-on-error—Rolls back the configuration.	To issue the configuration for two interfaces with the error-option element value as continue-on-error: <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <error-option>continue-on-error</error-option> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns="http://www.h3c.com/netconf/config:1.0"> <Ifmgr xc:operation="merge"> <Interfaces> <Interface> <IfIndex>262</IfIndex> <Description>222</Description> <ConfigSpeed>1000000</ConfigSpeed> <ConfigDuplex>1</ConfigDuplex> </Interface> <Interface> <IfIndex>263</IfIndex> <Description>333</Description> <ConfigSpeed>1000000</ConfigSpeed> <ConfigDuplex>1</ConfigDuplex> </Interface> </Interfaces> </Ifmgr> </top> </config> </edit-config> </rpc>
edit-config: test-option	Determines whether to issue a configuration item in the edit-configure operation. The test-option element has one of the following values: · test-then-set—Performs a validation test before attempting to set. If the validation test fails, the edit-config operation is not performed. This is the default test-option value. · set—Directly performs the set operation without the validation test. · test-only—Performs only a validation test without attempting to set. If the validation test succeeds, a successful message is returned. Otherwise, an error message is returned.	To issue the configuration for an interface for test purposes: <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <test-option>test-only</test-option> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns="http://www.h3c.com/netconf/config:1.0"> <Ifmgr xc:operation="merge"> <Interfaces> <Interface> <IfIndex>262</IfIndex> <Description>222</Description> <ConfigSpeed>1000000</ConfigSpeed> <ConfigDuplex>1</ConfigDuplex> </Interface> </Interfaces> </Ifmgr> </top> </config> </edit-config> </rpc>
action	Issues actions that are not for configuring data, for example, reset action.	To clear statistics information for all interfaces: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <action> <top xmlns="http://www.h3c.com/netconf/action:1.0"> <Ifmgr> <ClearAllIfStatistics> <Clear> </Clear> </ClearAllIfStatistics> </Ifmgr> </top> </action> </rpc>
lock	Locks the configuration data made through NETCONF sessions. The configurations can be changed by the edit-config operation. Other configurations are not limited by the lock operation. This lock operation does not lock the configurations made through other protocols, for example, SNMP.	To lock the configuration: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <lock> <target> <running/> </target> </lock> </rpc>
unlock	Unlocks the configuration, so NETCONF sessions can change device configuration. When a NETCONF session is terminated, the related locked configuration is also unlocked.	To unlock the configuration: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <unlock> <target> <running/> </target> </unlock> </rpc>
get-sessions	Retrieves information about all NETCONF sessions in the system.	To retrieve information about all NETCONF sessions in the system: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-sessions/> </rpc>
close-session	Terminates the NETCONF session for the current user, to unlock the configuration and release the resources (for example, memory) of this session. This operation logs the current user off the XML view.	To terminate the NETCONF session for the current user: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <close-session /> </rpc>
kill-session	Terminates the NETCONF session for another user. This operation cannot terminate the NETCONF session for the current user.	To terminate the NETCONF session with session-id 1: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <kill-session> <session-id>1</session-id> </kill-session> </rpc>
CLI	Executes CLI operations. A request message encloses commands in the <CLI> element, and a response message encloses the command output in the <CLI> element. NETCONF supports the following views: · Execution—User view. · Configuration—System view. To execute a command in other views, specify the command for entering the specified view, and then the desired command.	To execute the display this command in system view: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <CLI> <Configuration>display this</Configuration> </CLI> </rpc>
save	Saves the running configuration. You can use the <file> element to specify a file for saving the configuration. If you do not specify a file, the running configuration is saved to the main next-startup configuration file. The AllMDC attribute specifies that all MDC configurations are saved. It applies only to management MDC.	To save the running configuration to the file test.cfg: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <save AllMDC=”true”> <file>test.cfg</file> </save> </rpc>
load	Loads the configuration. After the device finishes the load operation, the configuration in the specified file is merged into the current configuration of the device.	To merge the configuration in the file a1.cfg to the current configuration of the device: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <load> <file>a1.cfg</file> </load> </rpc>
rollback	Rolls back the configuration. To do so, you must specify the configuration file in the <file> element. After the device finishes the rollback operation, the current device configuration is totally replaced with the configuration in the specified configuration file.	To roll back the current configuration to the configuration in the file 1A.cfg: <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rollback> <file>1A.cfg</file> </rollback> </rpc>

12-Network Management and Monitoring Configuration Guide

NETCONF message format

NETCONF

NETCONF over SOAP

NETCONF configuration task list

Exchanging capabilities

Example for subscribing to event notifications

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Verifying the configuration

Verifying the configuration

All-module configuration data retrieval example

Network requirements

Configuration procedure

Verifying the configuration

Syslog configuration data retrieval example

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Rolling back the configuration based on a rollback point

Configuring a rollback point

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Network requirements

Configuration procedure

Verifying the configuration

Configuration requirements

Configuration procedure

Verifying the configuration

Configuration requirement

Configuration procedure

Verifying the configuration

Appendix A Supported NETCONF operations

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us