Network Configuration Protocol (NETCONF) is an XML-based network management protocol. It provides programmable mechanisms to manage and configure network devices. Through NETCONF, you can configure device parameters, retrieve parameter values, and collect statistics. For a network that has devices from vendors, you can develop a NETCONF-based NMS system to configure and manage devices in a simple and effective way.

NETCONF structure

NETCONF has the following 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	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 references for the device.
Operations	<get>, <get-config>, <edit-config>…	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 "Supported NETCONF operations."
RPC	<rpc> and <rpc-reply>	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	Console/Telnet/SSH/HTTP/HTTPS/TLS	Provides reliable, connection-oriented, serial data links. The following transport layer sessions are available: · CLI sessions, including NETCONF over Telnet, NETCONF over SSH, and NETCONF over console. · NETCONF over HTTP sessions and NETCONF over HTTPS sessions. · NETCONF over SOAP sessions, including NETCONF over SOAP over HTTP and NETCONF over SOAP over HTTPS.

Basic NETCONF concepts

XML

eXtensible Markup Language (XML) is a simple, text-based data storage language. It describes the content and structure of data exchanged between entities on the Internet.

XML is case sensitive.

NETCONF uses XML-based data encoding for the configuration data and protocol messages. NETCONF messages are XML-based and comply with RFC 4741.

Element

Elements are the basic building blocks in an XML document. They act as containers to store various types of content, including text, child elements, and attributes.

An element encloses content in a pair of start and end tags, in <element-name>content</element-name> format. For example, the capability element is <capability>content</capability>.

If an element does not have content, that element is called an empty element. You can present an empty element in a self-closing empty tag in <element-name/> format, for example, <ok/>.

Attribute

Attributes provide meta-level information about an element. They are added in name=value format after the element name, within the start tag. For examples, the xmlns and operation attributes in the following element specify the namespace and operation type, respectively.

Namespace

A namespace is an abstract container or environment created to hold a logical group of unique identifiers or names. An identifier defined in a namespace is associated only with that namespace. Each data module must have a world-unique namespace to avoid element and attribute naming conflicts.

The device supports the following types of namespaces:

· urn:ietf:params:xml:ns:netconf:base:1.0 namespace—This namespace defines all NETCONF elements. All NETCONF messages must declare this namespace in the RPC layer.

· ietf-netconf namespace—The urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring namespace defined in a NETCONF protocol. NETCONF messages for the <get-schema> and <get><netconf-state/></get> operations must declare this namespace.

· Common namespace—A namespace that defines elements across service modules. In a packet that uses a common namespace, the namespace is indicated in the <top> element, and the modules are listed under the <top> element.

· H3C common namespaces—The http://www.h3c.com/netconf/ns:1.0 namespaces. The ns argument represents data, config, and action, which represent the data, configuration, and action namespaces, respectively. The common namespaces are shared by all modules. If used, a common namespace is typically specified for the xmlns attribute in the <top> element, and the modules are listed under the <top> element.

Example:

<get-bulk>

<Ifmgr>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get-bulk>

</rpc>

· Module-specific namespaces—A module has its own namespace to define module-specific elements. A packet that uses a module-specific namespace does not have the <top> element. The namespace follows the module name.

Example:

<get-bulk>

</Interfaces>

</Ifmgr>

</filter>

</get-bulk>

</rpc>

Node, module, table, row, and column

In H3C NETCONF XML AI references, elements are also called nodes. An element might be a module (or feature), table, row, or column node, as shown in Figure 1.

· Module—A feature module defines a hierarchy of related nodes. The element name for a module node is the module name.

· Table—A table contains rows and columns, with each row representing an object instance and each column containing a parameter for the instance. A table might also contains subtables.

· Row—Each row represents an object instance in the table.

· Column—Each column contains a parameter for the instance.

Figure 1 Node, module, table, row, and column in NETCONF messages

In Figure 1, the Ifmgr element represents the interface management module (Ifmgr). The Interfaces element is a table node in the Ifmgr module and it contains a table of interfaces. The Interface element is a row node and it contains data about an interface in the interface table. The IfIndex and Description elements are column nodes that contain the interface index and description of the interface.

NETCONF message format

NETCONF

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>

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 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>10000162a5d9091c0667ec821fb954147a16</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 perform NETCONF operations, copy valid NETCONF messages to the CLI in XML view.
Standard Web interface for the device	· HTTP · HTTPS	The system automatically converts the configuration operations on the Web interface to NETCONF messages and sends them to the device to perform NETCONF operations.
Custom user interface	N/A	Use a configuration tool to establish a NETCONF over SOAP or NETCONF over SSH session with the device. Then, you can issue NETCONF operations to configure and manage the device. To configure and manage the device through NECONF over SOAP, you must encapsulate NECONF messages in SOAP for transmission.

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

NETCONF tasks at a glance

To configure NETCONF, perform the following tasks:

1. Configuring NETCONF to use module-specific namespaces

2. Establishing a NETCONF session

a. (Optional.) Setting NETCONF session attributes

b. Establishing NETCONF over SOAP sessions

c. Establishing NETCONF over SSH sessions

d. Establishing NETCONF over Telnet or NETCONF over console sessions

e. Exchanging capabilities

3. (Optional.) Enabling the edit-config:replace operation to do full replacement

4. (Optional.) Retrieving device configuration information

¡ Retrieving device configuration and state information

¡ Retrieving non-default settings

¡ Retrieving NETCONF information

¡ Retrieving YANG file content

¡ Retrieving NETCONF session information

5. (Optional.) Filtering data

¡ Table-based filtering

¡ Column-based filtering

6. (Optional.) Locking or unlocking the configuration

f. Locking the configuration

g. Unlocking the configuration

7. (Optional.) Modifying the configuration

8. (Optional.) Managing configuration files

¡ Saving the running configuration

¡ Loading the configuration

¡ Rolling back the configuration

9. (Optional.) Managing the candidate configuration

10. (Optional.) Performing CLI operations

11. (Optional.) Subscribing to events

12. (Optional.) Terminating NETCONF sessions

13. (Optional.) Returning to the CLI

14. (Optional.) Enabling SNMP notifications for NETCONF

Configuring NETCONF to use module-specific namespaces

About this task

By default, the device uses the common namespace in the NETCONF responses to the requests for YANG file information. Perform this task to configure the device to use module-specific namespaces in the response messages.

The client performs the <get-schema> and <get><netconf-state/></get> operations to obtain information about YANG files on the device. For more information about the operations, see "Retrieving YANG file content" and "Retrieving NETCONF information."

Restrictions and guidelines

You do not need to perform this task if the client sends a hello message that includes the following capability during capability exchange:

<capability>urn:h3c:params:netconf:capability:module-specified-namespace:1.0</capability>

Procedure

1. Enter system view.

system-view

2. Configure NETCONF to use module-specific namespaces in messages responding to the client request of retrieving YANG file information.

netconf capability specific-namespace

By default, the common namespace is used in messages responding to the client request of retrieving YANG file information.

Establishing a NETCONF session

Restrictions and guidelines for NETCONF session establishment

After a NETCONF session is established, the device automatically sends its capabilities to the client. You must use a hello message to send the capabilities of the client to the device before you can perform any other NETCONF operations.

Before performing a NETCONF operation, make sure no other users are configuring or managing the device. If multiple users simultaneously configure or manage the device, the result might be different from what you expect.

You can use the aaa session-limit command 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. For information about this command, see AAA in BRAS Services Configuration Guide.

Setting NETCONF session attributes

1. Enter system view.

system-view

2. Set the NETCONF session idle timeout time.

netconf { agent | soap } idle-timeout minute

Parameter	Description
agent	Specifies the following sessions: · NETCONF over SSH sessions. · NETCONF over Telnet sessions. · NETCONF over console sessions. By default, the idle timeout time is 0, and the sessions never time out.
soap	Specifies the following sessions: · NETCONF over SOAP over HTTP sessions. · NETCONF over SOAP over HTTPS sessions. The default setting is 10 minutes.

Parameter

Description

agent

Specifies the following sessions:

· NETCONF over SSH sessions.

· NETCONF over Telnet sessions.

· NETCONF over console sessions.

By default, the idle timeout time is 0, and the sessions never time out.

soap

Specifies the following sessions:

· NETCONF over SOAP over HTTP sessions.

· NETCONF over SOAP over HTTPS sessions.

The default setting is 10 minutes.

3. Enable NETCONF logging.

netconf log source { all | { agent | soap | web } * } { protocol-operation { all | { action | config | get | session | set | syntax | others } * } | row-operation | verbose }

By default, the device logs only row operations for <action> and <edit-config> operations. NETCONF logging is disabled for all the other types of operations..

Establishing NETCONF over SOAP sessions

About this task

You can use a custom user interface to establish a NETCONF over SOAP session to the device and perform NETCONF operations. The NETCONF messages are encapsulated into SOAP messages and transmitted over HTTP or HTTPS.

Restrictions and guidelines

You can add an authentication domain to the <UserName> element of a SOAP request. The authentication domain takes effect only on the current request.

The mandatory authentication domain configured by using the netconf soap domain command takes precedence over the authentication domain specified in the <UserName> element of a SOAP request.

After the NETCONF over SOAP over HTTPS service is enabled, changes to the SSL server policy that is applied to the service do not take effect. For the changes to take effect, you must disable the service and then enable the service again.

Procedure

1. Enter system view.

system-view

2. (Optional.) Apply an SSL server policy to the NETCONF over SOAP over HTTPS service.

netconf soap https ssl-server-policy policy-name

By default, no SSL server policy is applied to the NETCONF over SOAP over HTTPS service.

The NETCONF over SOAP over HTTPS service will use the SSL server policy to enhance service security. For more information about SSL server policies, see SSL configuration in Security Configuration Guide.

3. Enable NETCONF over SOAP.

netconf soap { http | https } enable

By default, the NETCONF over SOAP feature is disabled.

4. (Optional.) Set the DSCP value for NETCONF over SOAP packets.

netconf soap { http | https } dscp dscp-value

By default, the DSCP value is 0 for NETCONF over SOAP packets.

5. (Optional.) Use an IPv4 ACL to control NETCONF over SOAP access.

netconf soap { http | https } acl { ipv4-acl-number | name ipv4-acl-name }

By default, no IPv4 ACL is applied to control NETCONF over SOAP access.

Only clients permitted by the IPv4 ACL can establish NETCONF over SOAP sessions.

6. (Optional.) Specify a mandatory authentication domain for NETCONF users.

netconf soap domain domain-name

By default, no mandatory authentication domain is specified for NETCONF users. For information about authentication domains, see BRAS Services Configuration Guide.

7. Use the custom user interface to establish a NETCONF over SOAP session with the device.

For information about the custom user interface, see the user guide for the interface.

Establishing NETCONF over SSH sessions

Prerequisites

Before establishing a NETCONF over SSH session, make sure the custom user interface can access the device through SSH.

Procedure

1. Enter system view.

system-view

2. Enable NETCONF over SSH.

netconf ssh server enable

By default, NETCONF over SSH is disabled.

3. (Optional.) Specify the listening port for NETCONF over SSH packets.

netconf ssh server port port-number

By default, the listening port number is 830.

4. Use the custom user interface to establish a NETCONF over SSH session with the device. For information about the custom user interface, see the user guide for the interface.

Establishing NETCONF over Telnet or NETCONF over console sessions

Restrictions and guidelines

To ensure the format correctness of a NETCONF message, do not enter the message manually. Copy and paste the message.

While the device is performing a NETCONF operation, do not perform any other operations, such as pasting a NETCONF message or pressing Enter.

For the device to identify NETCONF messages, you must add end mark ]]>]]> at the end of each NETCONF message. Examples in this document do not necessarily have this end mark. Do add the end mark in actual operations.

Prerequisites

To establish a NETCONF over Telnet session or a NETCONF over console session, first log in to the device through Telnet or the console port.

Procedure

To enter XML view, execute the following command in user view:

xml

If the XML view prompt appears, the NETCONF over Telnet session or NETCONF over console session is established successfully.

Exchanging capabilities

About this task

After a NETCONF session is established, the device sends its capabilities to the client. You must use a hello message to send the capabilities of the client to the device before you can perform any other NETCONF operations.

Hello message from the device to the client

<?xml version="1.0" encoding="UTF-8"?><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities>...</capabilities><session-id>1</session-id></hello>

The <capabilities> element carries the capabilities supported by the device.

The <session-id> element carries the unique ID assigned to the NETCONF session.

Hello message from the client to the device

After receiving the hello message from the device, copy the following hello message to notify the device of the capabilities supported by the client:

capability-set

</capability>

</capabilities>

</hello>

Item	Description
capability-set	Specifies a set of capabilities supported by the client. Use a pair of <capability> and </capability> tags to enclose each user-defined capability set.

Item

Description

capability-set

Specifies a set of capabilities supported by the client.

Use a pair of <capability> and </capability> tags to enclose each user-defined capability set.

Enabling the edit-config:replace operation to do full replacement

About this task

By default, the edit-config:replace operation does not do full replacement. This operation edits the specified columns and subtables in the target node and processes other columns and subtables as follows:

· If the target node contains only index columns and subtables, this operation leaves other columns and subtables unchanged.

· In other situations, this operation restores the unspecified columns to the default settings and leaves the unspecified subtables unchanged.

For example, the following XML request specifies only index columns VsiName, PeerAddr, and PWID and subtable TrafficPolicing in node LDPPeer. The edit-config:replace operation edits only subtable TrafficPolicing and leaves other columns and subtables of node LDPPeer unchanged.

<edit-config>

<test-option>set</test-option>

<error-option>continue-on-error</error-option>

<top>

<VPLS>

</Policing>

</TrafficPolicing>

</LDPPeer>

</LDPPeers>

</VPLS>

</top>

</config>

</edit-config>

</rpc>

If full replacement is enabled, the edit-config:replace operation edits the specified columns and subtables in the target node and restores the unspecified columns and subtables to the default settings.

For more information about the edit-config:replace operation, see "Supported NETCONF operations."

Procedure

1. Enter system view.

system-view

2. Enable the edit-config:replace operation to do full replacement.

netconf edit-config full-replace enable

By default, the edit-config:replace operation does not do full replacement.

Retrieving device configuration information

Restrictions and guidelines for device configuration retrieval

When you perform a standard retrieval operation (<get> or <get-config>) or a bulk retrieval operation (<get-bulk> or <get-bulk-config>) operation, use the following restrictions and guidelines:

· As a best practice to ensure retrieval performance, limit the number of data entries for each standard or bulk retrieval operation to 1000. If the number of data entries to retrieve exceeds 1000, use bulk retrieval operations as a best practice.

· The NETCONF server replaces unidentifiable characters in the retrieved data with question marks (?) before it sends the data to the client.

· If the process for a target module has not started yet, the NETCONF server returns the following message:

<?xml version="1.0"?>

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

<data/>

</rpc-reply>

· The <get><netconf-state/></get> operation does not support data filtering.

For more information about the NETCONF operations, see the NETCONF XML API references for the device.

Retrieving device configuration and state information

You can use the following NETCONF operations to retrieve device configuration and state information:

· <get> operation—Retrieves all device configuration and state information that match the specified conditions.

· <get-bulk> operation—Retrieves 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 returned output does not include the index information.

The <get> message and <get-bulk> message share the following format:

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

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

</top>

</filter>

</getoperation>

</rpc>

Item	Description
getoperation	Operation name, get or get-bulk.
filter	Specifies the filtering conditions, such as the module name, submodule name, table name, and column name. · If you specify a module name, the operation retrieves the data for the specified module. If you do not specify a module name, the operation retrieves the data for all modules. · If you specify a submodule name, the operation retrieves the data for the specified submodule. If you do not specify a submodule name, the operation retrieves the data for all submodules. · If you specify a table name, the operation retrieves the data for the specified table. If you do not specify a table name, the operation retrieves the data for all tables. · If you specify only the index column, the operation retrieves the data for all columns. If you specify the index column and any other columns, the operation retrieves the data for the index column and the specified columns.

Item

Description

getoperation

Operation name, get or get-bulk.

filter

Specifies the filtering conditions, such as the module name, submodule name, table name, and column name.

· If you specify a module name, the operation retrieves the data for the specified module. If you do not specify a module name, the operation retrieves the data for all modules.

· If you specify a submodule name, the operation retrieves the data for the specified submodule. If you do not specify a submodule name, the operation retrieves the data for all submodules.

· If you specify a table name, the operation retrieves the data for the specified table. If you do not specify a table name, the operation retrieves the data for all tables.

· If you specify only the index column, the operation retrieves the data for all columns. If you specify the index column and any other columns, the operation retrieves the data for the index column and the specified columns.

A <get-bulk> message can carry 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>

Attribute	Description
index	Specifies the index. If you do not specify this attribute, the index value starts with 1 by default.
count	Specifies the data entry quantity. 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. · 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.

Attribute

Description

index

Specifies the index.

If you do not specify this attribute, the index value starts with 1 by default.

count

Specifies the data entry quantity.

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.

· 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.

If the <get> or < get-bulk> operation succeeds, the device returns the retrieved data in the following format:

<?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>

Retrieving non-default settings

The <get-config> and <get-bulk-config> operations are used to retrieve all non-default settings. 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>

The value for datastore can be one of the following:

Value	Description
running	Specifies the running configuration datastore.
candidate	Specifies the candidate configuration datastore.

If the <get-config> or <get-bulk-config> operation succeeds, the device returns the retrieved data in the following format:

<?xml version="1.0"?>

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

<data>

Data matching the specified filter

</data>

</rpc-reply>

Retrieving NETCONF information

Use the <get><netconf-state/></get> message to retrieve NETCONF information.

# Copy the following text to the client to retrieve NETCONF information:

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

<get>

<netconf-state xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>

</netconf-state>

</filter>

</get>

</rpc>

If you do not specify a value for getType, the retrieval operation retrieves all NETCONF information.

The value for getType can be one of the following operations:

Operation	Description
capabilities	Retrieves device capabilities.
datastores	Retrieves databases from the device.
schemas	Retrieves the list of the YANG file names from the device.
sessions	Retrieves session information from the device.
statistics	Retrieves NETCONF statistics.

If the <get><netconf-state/></get> operation succeeds, the device returns a response in the following format:

<?xml version="1.0"?>

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

<data>

Retrieved NETCONF information

</data>

</rpc-reply>

Retrieving YANG file content

YANG files save the NETCONF operations supported by the device. You can identify the supported operations by retrieving and analyzing the content of YANG files.

YANG files are integrated in the device software and are named in the format of yang_identifier@yang_version.yang. You cannot view the YANG file names by executing the dir command. For information about retrieving the YANG file names, see "Retrieving NETCONF information."

# Copy the following text to the client to retrieve the YANG file named H3C-syslog-data@2017-01-01.yang:

<get-schema xmlns='urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring'>

<identifier>H3C-syslog-data</identifier>

</get-schema>

</rpc>

NOTE:

The YANG file names used in this document are for illustration only. They might differ from those came with your device.

# If the <get-schema> operation succeeds, the device returns a response in the following format:

<?xml version="1.0"?>

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

<data>

Content of the specified YANG file

</data>

</rpc-reply>

Retrieving NETCONF session information

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>

If the <get-sessions> operation succeeds, the device returns a response in the following format:

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

<rpc-reply message-id="100" 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 user 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>

Example: Retrieving a data entry for the interface table

Network configuration

Retrieve a data entry for the interface table.

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<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="100">

<data>

<Ifmgr>

<Name>Ten-GigabitEthernet3/1/2</Name>

<Description>Ten-GigabitEthernet3/1/2 Interface</Description>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</data>

</rpc-reply>

Example: Retrieving syslog configuration data

Network configuration

Retrieve configuration data for the Syslog module.

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Retrieve configuration data for the Syslog module.

<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="100">

<data>

</LogBuffer>

</Syslog>

</top>

</data>

</rpc-reply>

Example: Retrieving NETCONF session information

Network configuration

Get NETCONF session information.

Procedure

# 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>

Verifying the configuration

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="100">

<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 2017-01-07T00:24:57.

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

Filtering data

About data filtering

You can define a filter to filter information when you perform a <get>, <get-bulk>, <get-config>, or <get-bulk-config> operation. Data filtering includes the following types:

· Table-based filtering—Filters table information.

· Column-based filtering—Filters information for a single column.

Restrictions and guidelines for data filtering

For table-based filtering to take effect, you must configure table-based filtering before column-based filtering.

Table-based filtering

About this task

The namespace is http://www.h3c.com/netconf/base:1.0. The attribute name is filter. For information about the support for table-based match, see the NETCONF XML API references.

# Copy the following text to the client to retrieve the longest data with IP address 1.1.1.0 and mask length 24 from the IPv4 routing table:

<get>

<Route>

</Ipv4Routes>

</Route>

</top>

</filter>

</get>

</rpc>

Restrictions and guidelines

To use table-based filtering, specify a match criterion for the filter row attribute.

Column-based filtering

About this task

Column-based filtering includes full match filtering, regular expression match filtering, and conditional match filtering. Full match filtering has the highest priority and conditional match filtering has the lowest priority. When more than one filtering criterion is specified, the one with the highest priority takes effect.

Full match filtering

You can specify an element value in an XML message to implement full match filtering. 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 filtering. The system returns only configuration data that matches this attribute name. The XML message equivalent to the above element-value-based full match filtering is as follows:

<get>

<Ifmgr>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get>

</rpc>

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

Regular expression match filtering

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

The supported data types include integer, date and time, character string, IPv4 address, IPv4 mask, IPv6 address, MAC address, OID, and time zone.

# 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 filtering

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: Filtering data with regular expression match

Network configuration

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

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

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

<?xml version="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:h3c="http://www.h3c.com/netconf/base:1.0" message-id="100">

<data>

<Ifmgr>

<Description>Ten-GigabitEthernet3/1/1 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet3/1/2 Interface</Description>

</Interface>

<Description>Ten-GigabitEthernet3/1/3 Interface</Description>

</Interface>

</Ifmgr>

</top>

</data>

</rpc-reply>

Example: Filtering data by conditional match

Network configuration

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

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

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.

<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:h3c="http://www.h3c.com/netconf/base:1.0" message-id="100">

<data>

<Ifmgr>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</data>

</rpc-reply>

Locking or unlocking the configuration

About configuration locking and unlocking

Multiple methods are available for configuring the device, such as CLI, NETCONF, and SNMP. Before configuring, managing, or troubleshooting the device, you can lock the configuration to prevent other users from changing the device configuration. After you lock the configuration, only you can perform <edit-config> operations to change the configuration or unlock the configuration. Other users can only read the configuration.

If you close your NETCONF session, the system unlocks the configuration. You can also manually unlock the configuration.

Restrictions and guidelines for configuration locking and unlocking

The <lock> operation locks the configuration of the device. You cannot use it to lock the configuration for a specific module.

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>

The value for datastore can be one of the following:

Value	Description
running	Specifies the running configuration datastore.
candidate	Specifies the candidate configuration datastore.

If the <lock> operation succeeds, the device returns a response in the following format:

<?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>

Unlocking the configuration

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

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

</target>

</unlock>

</rpc>

The value for datastore can be one of the following:

Value	Description
running	Specifies the running configuration datastore.
candidate	Specifies the candidate configuration datastore.

If the <unlock> operation succeeds, the device returns a response in the following format:

<?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>

Example: Locking the running configuration

Network configuration

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

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

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="100" 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="100" 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 because the NETCONF lock is held by another session.</error-message>

<error-info>

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

</error-info>

</rpc-error>

</rpc-reply>

The output shows that the <lock> operation failed. The client with session ID 1 is holding the lock,

Modifying the configuration

About the <edit-config> operation

The <edit-config> operation includes the following operations: merge, create, replace, remove, delete, default-operation, error-option, test-option, and incremental. For more information about the operations, see "Supported NETCONF operations."

Procedure

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

<?xml version="1.0"?>

<edit-config>

<error-option>

error-option

</error-option>

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

</top>

</config>

</edit-config>

</rpc>

The value for datastore can be one of the following:

Value	Description
running	Specifies the running configuration datastore.
candidate	Specifies the candidate configuration datastore.

If you specify the running configuration datastore, you can also specify the <error-option> element. This element indicates the action to be taken in response to an error that occurs during the operation. It has the following values:

Value	Description
stop-on-error	Stops the <edit-config> operation.
continue-on-error	Continues the <edit-config> operation.
rollback-on-error	Rolls back the configuration to the configuration before the <edit-config> operation was performed. By default, an <edit-config> operation cannot be performed while the device is rolling back the configuration. If the rollback time exceeds the maximum time that the client can wait, the client determines that the <edit-config> operation has failed and performs the operation again. Because the previous rollback is not completed, the operation triggers another rollback. If this process repeats itself, CPU and memory resources will be exhausted and the device will reboot. To allow an <edit-config> operation to be performed during a configuration rollback, perform an <action> operation to change the value of the DisableEditConfigWhenRollback attribute to false.

If the <edit-config> operation succeeds, the device returns a response in the following format:

<?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 element value is the same as the value specified through the <edit-config> operation.

Example: Modifying the configuration

Network configuration

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

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

<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>

Saving the running configuration

About the <save> operation

A <save> operation saves the running configuration to a configuration file and specifies the file as the next-startup configuration file.

Restrictions and guidelines for configuration saving

The <save> operation is resource intensive. Do not perform this operation when system resources are heavily occupied.

Procedure

# Copy the following text to the client:

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

<file>Configuration file name</file>

</save>

</rpc>

Item	Description
file	Specifies the name of a configuration file. The name must start with the storage media name and end with the .cfg extension. If the text includes the file column, you must specify the file name. If the text does not include the file column, the configuration is automatically saved to the default main next-startup configuration file.
OverWrite	Determines whether the specified configuration file overwrites the original configuration file when the name of the specified configuration file already exists. The following values are available: · true—The specified configuration file overwrites the original file. · false—The running configuration cannot be saved, and the system displays an error message. The default value is true.

Item

Description

file

Specifies the name of a configuration file. The name must start with the storage media name and end with the .cfg extension.

If the text includes the file column, you must specify the file name. If the text does not include the file column, the configuration is automatically saved to the default main next-startup configuration file.

OverWrite

Determines whether the specified configuration file overwrites the original configuration file when the name of the specified configuration file already exists. The following values are available:

· true—The specified configuration file overwrites the original file.

· false—The running configuration cannot be saved, and the system displays an error message.

The default value is true.

If the <save> operation succeeds, the device returns a response in the following format:

<?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>

Example: Saving the running configuration

Network configuration

Save the running configuration to the config.cfg file.

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Save the running configuration of the device to the config.cfg file.

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

<save>

<file>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="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Loading the configuration

About the <load> operation

The <load> operation merges the configuration from a configuration file into the running configuration as follows:

· Loads settings that do not exist in the running configuration.

· Overwrites settings that already exist in the running configuration.

Restrictions and guidelines for configuration loading

When you perform a <load> operation, follow these restrictions and guidelines:

· The <load> operation is resource intensive. Do not perform this operation when the system resources are heavily occupied.

· Some settings in a configuration file might conflict with the existing settings. For the settings in the file to take effect, delete the existing conflicting settings, and then load the configuration file.

Procedure

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

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

<load>

<file>Configuration file name</file>

</load>

</rpc>

The configuration file name must start with the storage media name and end with the.cfg extension.

If the <load> operation succeeds, the device returns a response in the following format:

<?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

Restrictions and guidelines for configuration rollback

The <rollback> operation is resource intensive. Do not perform this operation when the system resources are heavily occupied.

By default, an <edit-config> operation cannot be performed while the device is rolling back the configuration. To allow an <edit-config> operation to be performed while the device is rolling back the configuration, perform an <action> operation to change the value of the DisableEditConfigWhenRollback attribute to false.

Rolling back the configuration based on a configuration file

# Copy the following text to the client to roll back the running configuration to the configuration in a configuration file:

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

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

</rollback>

</rpc>

If the <rollback> operation succeeds, the device returns a response in the following format:

<?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

About this task

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

· A NETCONF client sends a rollback request.

· The NETCONF session idle time is longer than the rollback idle timeout time.

· A NETCONF client is unexpectedly disconnected from the device.

Restrictions and guidelines

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

Procedure

1. Lock the running configuration. For more information, see "Locking or unlocking the configuration."

2. Enable configuration rollback based on a rollback point.

# Copy the following text to the client to perform a <save-point>/<begin> operation:

<save-point>

<begin>

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

</begin>

</save-point>

</rpc>

Item	Description
confirm-timeout	Specifies the rollback idle timeout time in the range of 1 to 65535 seconds. The default is 600 seconds. This item is optional.

If the <save-point/begin> operation succeeds, the device returns a response in the following format:

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

<data>

<save-point>

<commit-id>1</commit-id>

</commit>

</save-point>

</data>

</rpc-reply>

3. Modify the running configuration. For more information, see "Modifying the configuration."

4. Mark the rollback point.

The system supports a maximum of 50 rollback points. If the limit is reached, specify the force attribute for the <save-point>/<commit> operation to overwrite the earliest rollback point.

# Copy the following text to the client to perform a <save-point>/<commit> operation:

<save-point>

<label>SUPPORT VLAN<label>

<comment>vlan 1 to 100 and interfaces.</comment>

</commit>

</save-point>

</rpc>

The <label> and <comment> elements are optional.

If the <save-point>/<commit> operation succeeds, the device returns a response in the following format:

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

<data>

<save-point>

<commit-id>2</commit-id>

</commit>

</save-point>

</data>

</rpc-reply>

5. Retrieve the rollback point configuration records.

The following text shows the message format for a <save-point/get-commits> request:

<save-point>

<get-commits>

<commit-id/>

<commit-index/>

<commit-label/>

</get-commits>

</save-point>

</rpc>

Specify the <commit-id/>, <commit-index/>, or <commit-label/> element to retrieve the specified rollback point configuration records. If no element is specified, the operation retrieves records for all rollback point settings.

# Copy the following text to the client to perform a <save-point>/<get-commits> operation:

<save-point>

<get-commits>

<commit-label>SUPPORT VLAN</commit-label>

</get-commits>

</save-point>

</rpc>

If the <save-point/get-commits> operation succeeds, the device returns a response in the following format:

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

<data>

<save-point>

<commit-information>

<Label>SUPPORT VLAN</Label>

</commit-information>

</save-point>

</data>

</rpc-reply>

6. Retrieve the configuration data corresponding to a rollback point.

The following text shows the message format for a <save-point>/<get-commit-information> request:

<save-point>

<get-commit-information>

<commit-information>

<commit-id/>

<commit-index/>

<commit-label/>

</commit-information>

<compare-information>

<commit-id/>

<commit-index/>

<commit-label/>

</compare-information>

</get-commit-information>

</save-point>

</rpc>

Specify one of the following elements: <commit-id/>, <commit-index/>, and <commit-label/>. The <compare-information> element is optional.

Item	Description
commit-id	Uniquely identifies a rollback point.
commit-index	Specifies 50 most recently configured rollback points. The value of 0 indicates the most recently configured one and 49 indicates the earliest configured one.
commit-label	Specifies a unique label for a rollback point.
get-commit-information	Retrieves the configuration data corresponding to the most recently configured rollback point.

# Copy the following text to the client to perform a <save-point>/<get-commit-information> operation:

<save-point>

<get-commit-information>

<commit-information>

<commit-label>SUPPORT VLAN</commit-label>

</commit-information>

</get-commit-information>

</save-point>

</rpc>

If the <save-point/get-commit-information> operation succeeds, the device returns a response in the following format:

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

<data>

<save-point>

<commit-information>

…

interface vlan 1

…

</content>

</commit-information>

</save-point>

</data>

</rpc-reply>

7. Roll back the configuration based on a rollback point.

The configuration can also be automatically rolled back based on the most recently configured rollback point when the NETCONF session idle timer expires.

# Copy the following text to the client to perform a <save-point>/<rollback> operation:

<save-point>

<commit-id/>

<commit-index/>

<commit-label/>

</rollback>

</save-point>

</rpc>

Specify one of the following elements: <commit-id/>, <commit-index/>, and <commit-label/>. If no element is specified, the operation rolls back configuration based on the most recently configured rollback point.

Item	Description
commit-id	Uniquely identifies a rollback point.
commit-index	Specifies 50 most recently configured rollback points. The value of 0 indicates the most recently configured one and 49 indicates the earliest configured one.
commit-label	Specifies the unique label of a rollback point.

If the <save-point/rollback> operation succeeds, the device returns a response in the following format:

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

</rpc-reply>

8. End the rollback configuration.

# Copy the following text to the client to perform a <save-point>/<end> operation:

<save-point>

<end/>

</save-point>

</rpc>

If the <save-point/end> operation succeeds, the device returns a response in the following format:

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

<ok/>

</rpc-reply>

9. Unlock the configuration. For more information, see "Locking or unlocking the configuration."

Managing the candidate configuration

About this task

The candidate configuration datastore can be used to store or edit configuration data to be committed without impacting the device's running configuration. A commit operation commits the candidate configuration to the running configuration. After a successful commit operation, the system creates a configuration rollback point.

The candidate configuration datastore is globally unique.

Candidate configuration management tasks at a glance

To manage the candidate configuration, perform the following tasks:

1. Creating a candidate configuration datastore

2. Editing the candidate configuration datastore

3. Commit the candidate configuration

Choose one of the following tasks:

¡ Committing the candidate configuration immediately

¡ Committing the candidate configuration only after

4. (Optional.) Deleting the candidate configuration datastore

Perform this task to release system resources.

Creating a candidate configuration datastore

About this task

By default, the candidate configuration datastore does not exist. To create a candidate configuration datastore, perform the <copy-config> operation. This operation will create the candidate configuration datastore and copy the running configuration to the candidate configuration datastore. If the candidate configuration datastore already exists, the <copy-config> operation will overwrite existing candidate configuration in the datastore.

Procedure

# Copy the following text to the client to create a candidate configuration datastore and copy the running configuration to the candidate configuration datastore:

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

<copy-config>

</source>

</target>

</copy-config>

</rpc>

If the <copy-config> operation succeeds, the device returns a response in the following format:

<?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>

Editing the candidate configuration datastore

Restrictions and guidelines

As a best practice to prevent other users from changing the candidate configuration and to avoid configuration conflicts, lock the candidate configuration before editing it.

Procedure

1. Lock the candidate configuration. For more information, see "Locking or unlocking the configuration." Make sure you specify the candidate configuration datastore.

2. (Optional.) Retrieve non-default settings through a <get-config> or <get-bulk-config> operation. For more information, see "Retrieving non-default settings."

Skip this step if you know the non-default settings.

3. Edit the candidate configuration datastore through a <edit-config> operation. For more information, see "Modifying the configuration." Make sure you specify the candidate configuration datastore.

4. (Optional.) Restore the candidate configuration to the running configuration through a <discard-changes> operation. To perform a <discard-changes> operation, copy the following text to the client:

<discard-changes/>

</rpc>

Committing the candidate configuration immediately

# Copy the following text to the client to commit the candidate configuration to the running configuration immediately:

</rpc>

If the <commit> operation succeeds, the device returns a response in the following format:

<?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>

Committing the candidate configuration only after confirmation

About this task

A confirmation-required commit supports automatic rollback. If you require confirmation in the commit operation, the system will start a confirmation timeout timer.

· Before the timer expires, you can choose to commit the candidate configuration to the running configuration immediately or roll back the running configuration to the previously committed configuration.

· After the timer expires, the device automatically rolls back the running configuration to the previously committed configuration.

Procedure

1. Copy the following text to the client to commit the candidate configuration to the running configuration only after confirmation:

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

<persist>config-name</persist>

</commit>

</rpc>

Element	Description
confirm-timeout	Specifies the confirmation timeout timer, in seconds. The default is 600 seconds.
config-name	Specifies the name of the candidate configuration to be committed. The <persist> element enables the candidate configuration to survive after the NETCONF session terminates. · If you include the <persist> element in the commit operation, you can confirm the commit in any NETCONF session. Make sure you specify the <persist-id> element with the same candidate configuration name in the commit confirmation operation. · If you do not include the <persist> element in this commit operation, you can confirm the commit only in the current NETCONF session.

Element

Description

confirm-timeout

Specifies the confirmation timeout timer, in seconds. The default is 600 seconds.

config-name

Specifies the name of the candidate configuration to be committed.

The <persist> element enables the candidate configuration to survive after the NETCONF session terminates.

· If you include the <persist> element in the commit operation, you can confirm the commit in any NETCONF session. Make sure you specify the <persist-id> element with the same candidate configuration name in the commit confirmation operation.

· If you do not include the <persist> element in this commit operation, you can confirm the commit only in the current NETCONF session.

2. Choose one of the following tasks before the confirmation timeout timer expires:

¡ Commit the candidate configuration to the running configuration immediately by copying the following text to the client:

<persist-id>config-name</persist-id>

</commit>

</rpc>

Item

Description

config-name

Specifies the name of the candidate configuration to be committed. The name must be the same as that specified in the <persist> element.

If you do not include the <persist> element in the commit operation, you do not need to include the <persist-id> element in the confirmation.

¡ Cancel the commit and roll back the running configuration to the previously committed configuration by copying the following text to the client:

<cancel-commit/>

</rpc>

If the operation succeeds, the device returns a response in the following format:

<?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>

Deleting the candidate configuration datastore

# Copy the following text to the client to delete the candidate configuration datastore:

<delete-config>

</target>

</delete-config>

</rpc>

If the <delete-config> operation succeeds, the device returns a response in the following format:

<?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>

Performing CLI operations

About CLI operations

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

Restrictions and guidelines for CLI operations

Performing CLI operations through NETCONF is resource intensive. As a best practice, do not perform the following tasks:

· Enclose multiple command lines in one XML message.

· Use NETCONF to perform a CLI operation when other users are performing NETCONF CLI operations.

Procedure

# Copy the following text to the client to execute the 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.

If the CLI operation succeeds, the device returns a response in the following format:

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

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

<CLI>

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

</Execution>

</CLI>

</rpc-reply>

Example: Performing CLI operations

Network configuration

Send the display vlan command to the device.

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Copy the following text to the client to execute the display vlan command:

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

<CLI>

display vlan

</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="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<CLI>

<Execution><![CDATA[

<Sysname>display vlan

Total VLANs: 1

The VLANs include:

1(default)

]]>

</Execution>

</CLI>

</rpc-reply>

Subscribing to events

About event subscription

When an event takes place on the device, the device sends information about the event to NETCONF clients that have subscribed to the event.

Restrictions and guidelines for event subscription

Event subscription is not supported for NETCONF over SOAP sessions.

A subscription takes effect only on the current session. It is canceled when the session is terminated.

If you do not specify the event stream to be subscribed to, the device sends syslog event notifications to the NETCONF client.

Subscribing to syslog events

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

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

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

<stream>NETCONF</stream>

<Group>group</Group>

<Severity>severity</Severity>

</event>

</filter>

<startTime>start-time</startTime>

</create-subscription>

</rpc>

Item	Description
stream	Specifies the event stream. The name for the syslog event stream is NETCONF.
event	Specifies the event. For information about the events to which you can subscribe, see the system log message references for the device.
code	Specifies the mnemonic symbol of the log message.
group	Specifies the module name of the log message.
severity	Specifies the severity level of the log message.
start-time	Specifies the start time of the subscription.
stop-time	Specifies the end time of the subscription.

If the subscription succeeds, the device returns a response in the following format:

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

<rpc-reply message-id="100" 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="100" 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.

Subscribing to events monitored by NETCONF

After you subscribe to events as described in this section, NETCONF regularly polls the subscribed events and sends the events that match the subscription condition to the NETCONF client.

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

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

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

<stream>NETCONF_MONITOR_EXTENSION</stream>

<XPath>XPath</XPath>

<Interval>interval</Interval>

<ColumnName>ColumnName</ColumnName>

<ColumnValue>ColumnValue</ColumnValue>

<ColumnCondition>ColumnCondition</ColumnCondition>

</ColumnCondition>

</ColumnConditions>

<ColumnName>columnName</ColumnName>

</MustIncludeResultColumns>

</NetconfMonitor>

</filter>

<startTime>start-time</startTime>

</create-subscription>

</rpc>

Item	Description
stream	Specifies the event stream. The name for the event stream is NETCONF_MONITOR_EXTENSION.
NetconfMonitor	Specifies the filtering information for the event.
XPath	Specifies the path of the event in the format of ModuleName[/SubmoduleName]/TableName.
interval	Specifies the interval for NETCONF to obtain events that matches the subscription condition. The value range is 1 to 4294967 seconds. The default value is 300 seconds.
ColumnName	Specifies the name of a column in the format of [GroupName.]ColumnName.
ColumnValue	Specifies the baseline value.
ColumnCondition	Specifies the operator: · more. · less. · notLess. · notMore. · equal. · notEqual. · include. · exclude. · startWith. · endWith. Choose an operator according to the type of the baseline value.
start-time	Specifies the start time of the subscription.
stop-time	Specifies the end time of the subscription.

If the subscription succeeds, the device returns a response in the following format:

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

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

<ok/>

</rpc-reply>

Subscribing to events reported by modules

After you subscribe to events as described in this section, the specified modules report subscribed events to NETCONF. NETCONF sends the events to the NETCONF client.

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

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

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

<stream>XXX_STREAM</stream>

<ColumnName xs:condition="Condition">value</ColumnName>

</event>

</filter>

<startTime>start-time</startTime>

</create-subscription>

</rpc>

Item	Description
stream	Specifies the event stream.
event	Specifies the event name. An event stream includes multiple events. The events use the same namespaces as the event stream.
ColumnName	Specifies the name of a column.
Condition	Specifies the operator: · more. · less. · notLess. · notMore. · equal. · notEqual. · include. · exclude. · startWith. · endWith. Choose an operator according to the type of the baseline value.
value	Specifies the baseline value for the column.
start-time	Specifies the start time of the subscription.
stop-time	Specifies the end time of the subscription.

If the subscription succeeds, the device returns a response in the following format:

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

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

<ok/>

</rpc-reply>

Canceling an event subscription

# Copy the following message to the client to cancel a subscription:

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

<stream>XXX_STREAM</stream>

</cancel-subscription>

</rpc>

Item	Description
stream	Specifies the event stream.

If the cancelation succeeds, the device returns a response in the following format:

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

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

<ok/>

</rpc-reply>

If the subscription to be canceled does not exist, the device returns an error message in the following format:

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

<rpc-reply message-id="100" 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">The subscription stream to be canceled doesn't exist: Stream name=XXX_STREAM.</error-message>

</rpc-error>

</rpc-reply>

Example: Subscribing to syslog events

Network configuration

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

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

urn:ietf:params:netconf:base:1.0

</capability>

</capabilities>

</hello>

# Subscribe to syslog 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="100">

<ok/>

</rpc-reply>

# 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>

Terminating NETCONF sessions

About NETCONF session termination

NETCONF allows one client to terminate the NETCONF sessions of other clients. A client whose session is terminated returns to user view.

Procedure

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

<kill-session>

<session-id>

Specified session-ID

</session-id>

</kill-session>

</rpc>

If the <kill-session> operation succeeds, the device returns a response in the following format:

<?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>

Example: Terminating another NETCONF session

Network configuration

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

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

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="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Returning to the CLI

Restrictions and guidelines for returning to the CLI

Before returning from XML view to the CLI, you must first complete capability exchange between the device and the client.

Procedure

# Copy the following text to the client to return from XML view to the CLI:

<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="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

<ok/>

</rpc-reply>

Example: Returning to the CLI

Network configuration

After entering XML view, return to the CLI.

Procedure

# Enter XML view.

<Sysname> xml

# Notify the device of the NETCONF capabilities supported on the client.

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

</capabilities>

</hello>]]>]]>

# Return to the CLI.

<close-session/>

</rpc>]]>]]>

Verifying the configuration

If the user view prompt appears on the client, you have returned to the CLI.

Enabling SNMP notifications for NETCONF

About this task

To report critical NETCONF events to an SNMP NMS, enable SNMP notifications for NETCONF. For NETCONF SNMP notifications to be sent correctly, you must also configure SNMP on the device. For more information about configuring SNMP, see Network management and monitoring configuration guide.

Procedure

1. Enter system view.

system-view

2. Enable SNMP notifications for NETCONF.

snmp-agent trap enable netconf

By default, SNMP notifications are disabled for NETCONF.

Display and maintenance commands for NETCONF

Execute display commands in any view and reset commands in user view.

Task	Command
Display current NETCONF service status and global NETCONF service statistics.	display netconf service
Display NETCONF session status and statistics.	display netconf session
Clear NETCONF service statistics.	reset netconf service statistics
Clear NETCONF session statistics.	reset netconf session statistics

‌

Supported NETCONF operations

This chapter describes NETCONF operations available with Comware 7.

NETCONF packet strings are case sensitive.

Candidate configuration datastore operations

This section describes operations specific to the candidate configuration datastore. Besides these operations, you can also perform the following operations on the candidate configuration datastore:

· edit-config: create, edit-config: delete, edit-config: merge, edit-config: remove, and edit-config: replace.

· get-bulk-config and get-config.

· lock and unlock.

cancel-commit

Usage guidelines

This operation cancels an ongoing confirmed commit and roll back the running configuration to the previously committed configuration. Perform this task before the confirmation timeout timer expires.

XML example

# Cancel an ongoing commit and roll back the running configuration to the previously committed configuration.

<cancel-commit/>

</rpc>

commit (immediate commit)

Usage guidelines

This operation commits the candidate configuration to the running configuration immediately.

XML example

# Commit the candidate configuration to the running configuration immediately.

</rpc>

commit (confirmation-required commit)

Usage guidelines

This operation commits the candidate configuration to the running configuration only after the user confirms the commit. If the user does not confirm the commit, the device automatically rolls back the running configuration to the previously committed configuration.

When you perform this operation, you must specify the <confirmed> node and can specify the following columns:

· <confirm-timeout>—Specifies the confirmation timeout timer, in seconds. The default is 600 seconds.

· <persist>—Specifies the name of the candidate configuration and enable the candidate configuration to survive after the NETCONF session terminates. If you do not include the <persist> element in this commit operation, you can confirm the commit only in the current NETCONF session.

XML example

# Configure name test for the candidate configuration and commit the candidate configuration to the running configuration only after a confirmation. Set the confirmation timeout time to 600 seconds.

<confirm-timeout>600</confirm-timeout>

</commit>

</rpc>

commit (commit confirmation)

Usage guidelines

This operation confirms to commit the candidate configuration to the running configuration.

You must confirm the commit operation before the confirmation timeout timer expires.

If you include the <persist> element in the confirming commit operation, you must include the <persist-id> element in the confirmation operation. Make sure the value for the <persist-id> element is the same as that specified in the <persist> element.

If you do not include the <persist> element, the commit confirmation operation is the same as the immediate commit operation.

XML example

# Confirm to commit the candidate configuration with name test to the running configuration.

<persist-id>test</persist-id>

</commit>

</rpc>

copy-config

Usage guidelines

This operation copies the running configuration to a target configuration datastore. If the target configuration datastore does not exist, this operation creates the datastore.

In the current software version, this operation can only copy the running configuration to the candidate configuration store.

XML example

# Copy the running configuration to the candidate configuration datastore.

<copy-config>

</source>

</target>

</copy-config>

</rpc>

delete-config

Usage guidelines

This operation deletes a configuration datastore.

In the current software version, this operation can only delete the candidate configuration store.

XML example

# Delete the candidate configuration datastore.

<delete-config>

</target>

</delete-config>

</rpc>

discard-changes

Usage guidelines

This operation restores the candidate configuration to the previously committed configuration.

XML example

# Restore the candidate configuration to the previously committed configuration.

<discard-changes/>

</rpc>

CLI operations

CLI

Usage guidelines

This operation executes Comware CLI commands.

A request message encloses commands in the <CLI> element. A response message encloses the command output in the <CLI> element.

You can use the following elements to execute commands:

· Execution—Executes commands in user view.

· Configuration —Executes commands in system view.

To use this element, include the exec-use-channel attribute and specify a value for the attribute:

¡ false—Executes commands without using a channel.

¡ true—Executes commands by using a temporary channel. The channel is automatically closed after the execution.

¡ persist—Executes commands by using the persistent channel for the session.

To use the persistent channel, first perform an <Open-channel> operation to open the persistent channel. If you do not do so, the system will automatically open the persistent channel.

After using the persistent channel, perform a <Close-channel> operation to close the channel and return to system view. If you do not perform an <Open-channel> operation, the system stays in the view and will execute subsequent commands in the view.

You can also specify the error-when-rollback attribute in the <Configuration> element to indicate whether CLI operations are allowed during a configuration error-triggered configuration rollback. This attribute takes effect only if the value of the <error-option> element in <edit-config> operations is set to rollback-on-error. It has the following values:

¡ true—Rejects CLI operation requests and returns error messages.

¡ false (the default)—Allows CLI operations.

For CLI operations to be correctly performed, set the value of the error-when-rollback attribute to true.

NOTE:

To execute commands in a lower-level view of the system view, use the <Configuration> element to enter the view first.

A NETCONF session can have multiple temporary channels, but it can have only one persistent channel.

NETCONF does not support executing interactive commands.

You cannot use the quit command by using a channel to exit user view.

XML example

# Execute the vlan 3 command in system view without using a channel.

<CLI>

</CLI>

</rpc>

VLAN termination operations

createDot1qFlow

Usage guidelines

This operation enables user VLAN Dot1q termination on a subinterface, and specifies the outermost VLAN IDs in the VLAN-tagged packets that can be terminated by the subinterface. For more information about Dot1q termination, see VLAN termination configuration in Layer 2—LAN Switching Configuration Guide.

You must use <ifName> to specify the subinterface.

Use <vlanIdBgn> and <vlanldEnd> to specify the range of the outermost VLAN IDs in the VLAN-tagged packets that can be terminated by the subinterface. If you specify the same value for these two columns, the subinterface terminates only packets that use the value as the outermost VLAN ID.

The value range for the <groupId> column is 1 to 16. To use the device together with a third-party device, make sure this column uses the same value as the third-party device.

XML example

# Enable user VLAN Dot1q termination on Ten-GigabitEthernet 3/1/1.1. Configure the subinterface to terminate VLAN-tagged packets with outermost VLAN IDs in the range of 1 to 100.

<ifName>Ten-GigabitEthernet3/1/1.1</ifName>

</createDot1qFlow>

</rpc>

deleteDot1qFlow

Usage guidelines

This operation deletes Dot1q termination configuration from a subinterface.

You must use <ifName> to specify the subinterface.

Use <vlanIdBgn> and <vlanldEnd> to specify the range of the outermost VLAN IDs in the VLAN-tagged packets that you do not want to terminate on the subinterface. If you specify the same value for these two columns, you disable the subinterface from terminating packets that use the value as the outermost VLAN ID.

The value range for the <groupId> column is 1 to 16. To use the device together with a third-party device, make sure this column uses the same value as the third-party device.

XML example

# Delete the Dot1q termination configuration for VLAN-tagged packets with outermost VLAN IDs in the range of 1 to 100 on Ten-GigabitEthernet 3/1/1.1.

<ifName>Ten-GigabitEthernet3/1/1.1</ifName>

</deleteDot1qFlow>

</rpc>

Edit operations

edit-config: create

Usage guidelines

This operation creates target configuration items.

To use the create attribute in an <edit-config> operation, you must specify the target configuration item.

· If the table supports creating a target configuration item and the item does not exist, the operation creates the item and configures the item.

· If the specified item already exists, a data-exist error message is returned.

XML example

# Set the buffer size to 120.

<edit-config>

</target>

</LogBuffer>

</Syslog>

</top>

</config>

</edit-config>

</rpc>

edit-config: delete

Usage guidelines

This operation 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.

XML example

The syntax is the same as the edit-config message with the create attribute. Change the operation attribute from create to delete.

edit-config: merge

Usage guidelines

This operation commits target configuration items to the running configuration.

To use the merge attribute in an <edit-config> operation, you must specify the target configuration item (on a specific level):

· If the specified item exists, the operation directly updates the setting for the item.

· If the specified item does not exist, the operation creates the item and configures the item.

· If the specified item does not exist and it cannot be created, an error message is returned.

XML example

The XML data format is the same as the edit-config message with the create attribute. Change the operation attribute from create to merge.

edit-config: remove

Usage guidelines

This operation 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.

XML example

The syntax is the same as the edit-config message with the create attribute. Change the operation attribute from create to remove.

edit-config: replace

Usage guidelines

This operation replaces the specified configuration.

· 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, the operation creates the target and then applies the configuration.

· 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.

XML example

The syntax is the same as the edit-config message with the create attribute. Change the operation attribute from create to replace.

edit-config: test-option

Usage guidelines

This operation determines whether to commit a configuration item in an <edit-configure> operation. The <test-option> element has the following values:

· test-then-set—Performs a syntax check, and commits an item if the item passes the check. If the item fails the check, the item is not committed. This is the default test-option value.

· set—Commits the item without performing a syntax check.

· test-only—Performs only a syntax check. If the item passes the check, a success message is returned. Otherwise, an error message is returned.

XML example

# Test the configuration for an interface.

<edit-config>

</target>

<test-option>test-only</test-option>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</config>

</edit-config>

</rpc>

edit-config: default-operation

Usage guidelines

This operation modifies the current configuration of the device by using the default operation method.

NETCONF uses one of the following operation attributes to modify configuration: merge, create, delete, and replace If you do not specify an operation attribute for an edit-config message, NETCONF uses the default operation method. Your setting of the value for the <default-operation> element takes effect only once. If you do not specify an operation attribute or the default operation method for an <edit-config> message, merge always applies.

The <default-operation> element has the following values:

· merge—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.

XML example

# Issue an empty operation for schema verification purposes.

<edit-config>

</target>

<default-operation>none</default-operation>

<Ifmgr>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</config>

</edit-config>

</rpc>

edit-config: error-option

Usage guidelines

This operation determines the action to take in case of a configuration error.

The <error-option> element has the following values:

· stop-on-error—Stops the operation and returns an error message. This is the default error-option value.

· continue-on-error—Continues the operation and returns an error message.

· rollback-on-error—Rolls back the configuration.

XML example

# Issue the configuration for two interfaces with the <error-option> element value as continue-on-error.

<edit-config>

</target>

<error-option>continue-on-error</error-option>

</Interface>

</Interface>

</Interfaces>

</Ifmgr>

</top>

</config>

</edit-config>

</rpc>

edit-config: incremental

Usage guidelines

This operation adds configuration data to a column without affecting the original data.

The incremental attribute applies to a list column such as the vlan permitlist column.

You can use the incremental attribute for <edit-config> operations except the <replace> operation.

Support for the incremental attribute varies by module. For more information, see NETCONF XML API documents.

XML example

# Add VLANs 1 through 10 to an untagged VLAN list that has untagged VLANs 12 through 15.

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

xmlns:h3c="http://www.h3c.com/netconf/base:1.0">

<edit-config>

</target>

</Interface>

</HybridInterfaces>

</VLAN>

</top>

</config>

</edit-config>

</rpc>

Get operations

get

Usage guidelines

This operation retrieves device configuration and state information.

XML example

# Retrieve device configuration and state information for the Syslog module.

<get>

</Syslog>

</top>

</filter>

</get>

</rpc>

get-bulk

Usage guidelines

This operation 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.

XML example

# Retrieve device configuration and state information for all interfaces.

<get-bulk>

<Ifmgr>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get-bulk>

</rpc>

get-bulk-config

Usage guidelines

This operation retrieves a number of non-default configuration data entries starting from the data entry next to the one with the specified index.

XML example

# Retrieve non-default configuration for all interfaces.

<get-bulk-config>

</source>

<Ifmgr>

</Ifmgr>

</top>

</filter>

</get-bulk-config>

</rpc>

get-config

Usage guidelines

This operation retrieves non-default configuration data. If no non-default configuration data exists, the device returns a response with empty data.

XML example

# Retrieve non-default configuration data for the interface table.

<get-config>

</source>

<Ifmgr>

</Interfaces>

</Ifmgr>

</top>

</filter>

</get-config>

</rpc>

get-sessions

Usage guidelines

This operation retrieves information about all NETCONF sessions in the system. You cannot specify a session ID to retrieve information about a specific NETCONF session.

XML example

# Retrieve information about all NETCONF sessions in the system.

<get-sessions/>

</rpc>

Other operations

action

Usage guidelines

This operation issues actions for non-default settings, for example, reset action.

XML example

# Clear statistics information for all interfaces.

<Ifmgr>

<Clear>

</Clear>

</ClearAllIfStatistics>

</Ifmgr>

</top>

</action>

</rpc>

close-session

Usage guidelines

This operation terminates the current NETCONF session, unlock the configuration, and release the resources (for example, memory) used by the session. After this operation, you exit the XML view.

XML example

# Terminate the current NETCONF session.

<close-session/>

</rpc>

kill-session

Usage guidelines

This operation terminates the NETCONF session for another user. This operation cannot terminate the NETCONF session for the current user.

XML example

# Terminate the NETCONF session with session ID 1.

<kill-session>

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

</kill-session>

</rpc>

load

Usage guidelines

This operation loads the configuration. After the device finishes a <load> operation, the configuration in the specified file is merged into the current configuration of the device.

XML example

# Merge the configuration in file a1.cfg to the current configuration of the device.

<load>

</load>

</rpc>

lock

Usage guidelines

This operation locks the configuration. After the configuration is locked, you cannot perform <edit-config> operations. Other operations are allowed.

After a user locks the configuration, other users cannot use NETCONF or any other configuration methods such as CLI and SNMP to configure the device.

XML example

# Lock the configuration.

<lock>

</target>

</lock>

</rpc>

rollback

Usage guidelines

This operation 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.

XML example

# Roll back the current configuration to the configuration in file 1A.cfg.

</rollback>

</rpc>

save

Usage guidelines

This operation saves the running configuration. You can use the <file> element to specify a file for saving the configuration. If the text does not include the file column, the running configuration is automatically saved to the main next-startup configuration file.

The OverWrite attribute determines whether the current configuration overwrites the original configuration file when the specified file already exists.

XML example

# Save the running configuration to file test.cfg.

</save>

</rpc>

unlock

Usage guidelines

This operation unlocks the configuration, so other users can configure the device.

Terminating a NETCONF session automatically unlocks the configuration.

XML example

# Unlock the configuration.

</target>

</unlock>

</rpc>

15-Network Management and Monitoring Configuration Guide

XML

Element

Attribute

Namespace

Node, module, table, row, and column

NETCONF message format

NETCONF

NETCONF over SOAP

About this task

About this task

Restrictions and guidelines

Procedure

Prerequisites

Procedure

Restrictions and guidelines

Prerequisites

Procedure

Exchanging capabilities

About this task

Hello message from the device to the client

Hello message from the client to the device

About this task

Procedure

Network configuration

Procedure

Verifying the configuration

Network configuration

Procedure

Verifying the configuration

Network configuration

Procedure

Verifying the configuration

About this task

Restrictions and guidelines

About this task

Full match filtering

Regular expression match filtering

Conditional match filtering

Network configuration

Procedure

Verifying the configuration

Network configuration

Procedure

Verifying the configuration

Network configuration

Procedure

Verifying the configuration

Network configuration

Procedure

Verifying the configuration

Network configuration

Procedure

Verifying the configuration

About this task

Restrictions and guidelines

Procedure

About this task

Procedure

Restrictions and guidelines

Procedure

Committing the candidate configuration only after confirmation

About this task

Procedure

Example: Performing CLI operations

Network configuration

Procedure

Verifying the configuration

Procedure

Verifying the configuration

Terminating NETCONF sessions