CloudEngine S5700 and S6700 V600R022C00 Configuration Guide - System Management
NETCONF Configuration
- NETCONF Overview
- Understanding NETCONF
- NETCONF Operation Capabilities
- Configuration Precautions for NETCONF
- Installing ncclient
- Establishing a NETCONF Session
- Establishing a NETCONF Session
- Configuring an SSH User
- Enabling NETCONF
- Establishing a NETCONF Connection Between a Device and an NMS
- Logging In to the Server Using the NMS
- Verifying the Configuration
- Example for Configuring a Device to Communicate with ncclient Using NETCONF
- Example for Configuring a Device to Communicate with iMaster NCE-Campus Using NETCONF
- Configuring NETCONF Authorization
- Maintaining NETCONF
- Examples for Basic NETCONF Operations
NETCONF Overview
Definition
The Network Configuration Protocol (NETCONF) is an extensible markup language (XML)-based network configuration and management protocol. NETCONF uses a simple remote procedure call (RPC) mechanism to implement communication between a client and a server. NETCONF provides a method for a network management station (client), which is a central computer that runs network management software, to remotely manage and monitor devices.
The NMS uses NETCONF to implement local management and perform operations such as adding, modifying, and deleting configurations of remote devices. This protocol allows a device to provide a complete and formal application programming interface (API). Network management applications can use this API to send and receive complete or partial configuration data sets.
Purpose
As networks become larger and more complex, the Simple Network Management Protocol (SNMP) can no longer meet the requirements for managing and configuring networks. This is where NETCONF comes into play.
Table 11-1 lists the differences between SNMP and NETCONF.
Function |
SNMP |
NETCONF |
|---|---|---|
Configuration management |
SNMP does not provide a lock mechanism when multiple users perform operations on the same configuration. |
NETCONF provides a lock mechanism to ensure that operations performed by multiple users do not conflict with each other. |
Querying |
SNMP can be used to query one or more records in a table, requiring multiple interactions. |
NETCONF allows you to directly query the configuration data of the system and supports data filtering. |
Scalability |
Poor. |
Good.
|
Safety |
SNMPv2, released by the International Architecture Board (IAB) in 1996, provides only limited security improvements over SNMPv1. SNMPv3, released in 2002, also has major security problems: no encryption capability and no support for security protocol algorithms at the transport layer. |
NETCONF uses existing security protocols to ensure network security and is not specific to any security protocols. NETCONF is therefore more flexible than SNMP in security protection.
NOTE:
Secure Shell (SSH) is the preferred transport protocol in NETCONF and is used to transmit XML information. |
Benefits
- Facilitates configuration data management and interoperability between different vendors' devices by using XML encoding to define messages and using the RPC mechanism to modify configuration data.
- Reduces network faults caused by manual configuration errors.
- Improves the efficiency of tool-based upgrades to system software.
- Provides high extensibility, allowing different vendors to define additional NETCONF operations.
- Improves data security using authentication and authorization mechanisms.
This document is written according to device information obtained under lab conditions and therefore may not cover all scenarios. Due to factors such as version upgrades and differences in device models, the content provided in this document may differ from the information on user device interfaces. Such information takes precedence over the content provided by this document.
Understanding NETCONF
NETCONF Network Architecture
Basic Network Architecture of NETCONF
Figure 11-1 shows the basic network architecture of NETCONF. It must contain at least one network management system (NMS) that runs on an NMS server and manages devices.
The architecture consists of two main elements: client and server.
Main Element |
Function |
|---|---|
NETCONF client |
A client manages network devices using NETCONF.
|
NETCONF server |
A server maintains information of managed devices, responds to RPC requests sent by clients, and sends the requested management data to the clients.
|
A network device must support at least one NETCONF session, which is a logical connection between a client and a server. The information that a client obtains from a server can be configuration or status data.
- The client can modify and operate configuration data to implement a user-expected status of the server.
- The client cannot modify status data, which mainly includes the running status and statistics of the server.
Establishing a Basic NETCONF Session
The client triggers the establishment of a NETCONF session. It then completes SSH connection setup after authentication and authorization are complete.
The client and server complete NETCONF session establishment and capability negotiation.
The client sends one or more requests to the server for RPC interaction (authorization). For example:
Modify the configuration.
Query the configuration data or status.
Perform maintenance operations on the device.
Terminate the NETCONF session.
Tear down the SSH connection.
Session Interaction Between the Client and Server
After a NETCONF session is established, the client and server immediately exchange Hello messages with each other (these messages include the <hello> element, which contains the set of capabilities supported locally). If both ends support a capability, they can implement special management functions based on this capability.
The result of negotiating standard capabilities (except the notification capability) depends on the server-side capability set whereas that of extended capabilities depends on which capabilities both ends support.
A NETCONF server can send a <hello> element to advertise the capabilities that it supports.
- If the capabilities contained in a <hello> element sent from the peer are all standard capabilities, the Huawei device replies with a YANG packet.
After a server exchanges <hello> elements with a client, the server waits for <rpc> elements from the client. The server returns an <rpc-reply> element in response to each <rpc> element. Figure 11-2 shows the capability interaction between the NETCONF server and client.
NETCONF Protocol Architecture
NETCONF Protocol Framework
Like the open systems interconnection (OSI) model, the NETCONF protocol framework also uses a hierarchical structure. Each layer encapsulates certain functions and provides services for its upper layer.
This hierarchical structure enables each layer to focus only on a single aspect of NETCONF and reduces the dependencies between different layers. In this way, the impact that internal implementation imposes on other layers can be minimized.
Table 11-3 describes the four layers of the NETCONF protocol framework.
Layer |
Example |
Description |
|---|---|---|
Layer 1: transport |
BEEP, SSH, and SSL |
The transport layer provides a communication path for interaction between a NETCONF client and server. NETCONF can be carried over any transport protocol that meets the following basic requirements:
NOTE:
Currently, the device supports only SSH as the transport layer protocol for NETCONF. |
Layer 2: message layer |
<rpc> and <rpc-reply> |
The message layer provides a simple RPC request and response mechanism independent of transport protocols. The client encapsulates RPC request information in the <rpc> element and sends it to the server through a secure and connection-oriented session. The server encapsulates RPC reply information (content at the operation and content layers) in the <rpc-reply> element and sends it to the client. In normal cases, the <rpc-reply> element encapsulates data required by the client or information about a configuration success. If the client sends an incorrect request or the server fails to process a request from the client, the server encapsulates the <rpc-error> element containing detailed error information in the <rpc-reply> element and sends the <rpc-reply> element to the client. |
Layer 3: operations |
<get-config>, <edit-config>, and <notification> |
The operations layer defines a series of basic operations used in RPC. These operations constitute basic capabilities of NETCONF. |
Layer 4: content |
Configuration data |
The content layer describes configuration data involved in network management. The configuration data depends on vendors' devices. To date, only the content layer remains to be standardized for NETCONF. This layer has no standard NETCONF data modeling language or data model. |
NETCONF Modeling Language
YANG is a data modeling language developed to design NETCONF-oriented configuration data, status data models, RPC models, and notification mechanisms.
The YANG data model is a machine-oriented model interface, which defines data structures and constraints to provide more flexible and complete data description.
Encoding Format
XML encoding is used in NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and XML-specific tools.
XML-based network management uses XML to describe managed data and management operations. In this way, management information forms a database that is understandable to computers, allowing them to efficiently process network management data using enhanced management capabilities.
- <?: indicates the start of an instruction.
- xml: identifies an XML file.
- version="1.0": The XML1.0 standard version is used.
- encoding: indicates the character set encoding format. Only UTF-8 encoding is supported.
- ?>: indicates the end of an instruction.
Communication Modes
The NETCONF client and server communicate through the RPC mechanism. To implement the communication, a secure and connection-oriented session must be established. After receiving an RPC request from the client, the server processes the request and sends a response message to the client. The RPC request from the client and the response message from the server are encoded in XML format. The XML-encoded <rpc> and <rpc-reply> elements provide a request and response message framework independent of transport layer protocols. Table 11-4 lists some basic RPC elements.
Element |
Description |
|---|---|
<rpc> |
Encapsulates a request that the client sends to the NETCONF server. |
<rpc-reply> |
Encapsulates a response message that the NETCONF server sends in reply to each <rpc> request it receives. |
<rpc-error> |
Notifies a client of an error that occurs during processing of an <rpc> request. The server encapsulates the <rpc-error> element in the <rpc-reply> element and sends the <rpc-reply> element to the client. |
<ok> |
Notifies a client that no errors occur during processing of an <rpc> request. The server encapsulates the <ok> element in the <rpc-reply> element and sends the <rpc-reply> element to the client. |
Capability Set
NETCONF defines the syntax and semantics of capabilities. The protocol allows the client and server to notify each other of supported capabilities. The client can send the operation requests only within the capability range supported by the server.
A capability set includes basic and extended functions implemented based on NETCONF. The NETCONF capability set includes a standard capability set defined by the IETF standards organization. In addition, a device can use the capability set to add a protocol operation so that the operation range of the existing configuration object is extended.
Each capability is identified by a unique uniform resource identifier (URI). The URI format of the capability set defined by NETCONF is as follows:
urn:ietf:params:xml:ns:netconf:capability:{name}:{version}
In addition to the NETCONF-defined capability set, a vendor can define additional capability sets to extend management functions. A module that supports the YANG model needs to add YANG notifications to Hello messages before sending the messages. The message format is as follows:
<capability>urn:huawei:yang:huawei-ifm?module=huawei-ifm&revision=2022-03-30</capability>
Configuration Database
A configuration database is a collection of complete configuration parameters for a device. Table 11-5 describes NETCONF-defined configuration databases.
Configuration Database |
Description |
|---|---|
<running/> |
Stores the device's currently running configuration, status information, and statistics. Unless the NETCONF server supports the candidate capability, this configuration database is the only standard database that is mandatory. To support modification of the <running/> configuration database, a device must have the writable-running capability. |
<candidate/> |
Stores the configuration data to be run on a device. An administrator can perform operations on the <candidate/> configuration database. Any change to the <candidate/> database does not directly affect the configurations currently running on the device. To support the <candidate/> configuration database, a device must have the candidate capability. NOTE:
The <candidate/> configuration databases supported by devices do not allow inter-session data sharing. Therefore, the configuration of the <candidate/> configuration database does not require additional locking operations. |
<startup/> |
Stores the configuration data loaded during device startup, which is similar to the saved configuration file. To support the <startup/> configuration database, a device must have the distinct startup capability. |
NETCONF Message Formats
Request Message
Figure 11-3 shows the structure of a complete NETCONF request message.
- Message: The message layer provides a simple and independent mechanism of transmitting frames for RPC messages. The client encapsulates an RPC request into an <rpc> element and sends it to the server, which encapsulates the result of processing this request into the <rpc-reply> element and sends it to the client.
- Operations: The operations layer defines a set of basic NETCONF operations. These operations are invoked by RPC methods that are based on XML encoding parameters.
- Content: The content (managed object) layer defines a configuration data model. Currently, mainstream configuration data models include the YANG model.
Field |
Description |
|---|---|
message-id |
Indicates the information code. The value is specified by the client that initiates the RPC request. After receiving the RPC request message, the server saves the message-id attribute, which is used in an <rpc-reply> message to be generated. |
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" |
Indicates the NETCONF XML namespace. base indicates that basic operation types are supported. base1.0: Indicates that the <running/> configuration database is supported. Basic operations, such as <get-config>, <get>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <close-session>, and <kill-session>, are defined. You can set the <error-option> parameter to stop-on-error, continue-on-error, or rollback-on-error. base1.1: Indicates an upgrade of base1.0, with the following changes:
If you want to perform an operation in base1.1, the client must support base1.1 so that this capability can be advertised during capability set exchange. |
<edit-config> |
Indicates the operation type. |
<target> |
Indicates the target data set to be operated:
|
<default-operation> |
Indicates the default operation type. |
<error-option> |
Indicates the mode for processing subsequent operations if an error occurs during an <edit-config> operation. The options are as follows:
|
<config> |
Indicates a group of hierarchical configuration items defined in the data model. The configuration items must be placed in the specified namespace and meet the constraints of that data model, as defined by its capability set. |
]]>]]> |
Indicates the end character of an XML message. NOTE:
When a server exchanges XML packets with a client, the packets must be concluded with the end character ]]>]]>. Otherwise, the device cannot identify the XML packets and does not respond to them. By default, the end character is automatically added to XML messages sent by a device. The examples provided in this document omit the end character for brevity. If the capability set in the <hello> elements contains base1.1, the RPC messages in the YANG model support the chunk format. Messages in chunk format can be fragmented. The end character is \n##\n. |
Response Message
If a request message is successfully executed, the device returns a successful response. Otherwise, the device returns a failed response.
- For a successful response, an <rpc-reply> message carrying the <ok> element is returned.
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="10" nc-ext:flow-id="33" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/></rpc-reply> - For a failed response, an <rpc-reply> message carrying the <rpc-error> element is returned.
<?xml version="1.0" encoding="utf-8"? <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5"> <rpc-error> <error-type>application</error-type> <error-tag>data-exists</error-tag> <error-severity>error</error-severity> <error-app-tag>43</error-app-tag> <error-path xmlns:acl="urn:huawei:yang:huawei-acl">acl:acl/acl:groups/acl:group[acl:identity='2000']</error-path> <error-message xml:lang="en">Invalid ACL number:Number can not be the number of an existent ACL.</error-message> <error-info xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext"> <nc-ext:error-info-code>8123</nc-ext:error-info-code> </error-info> </rpc-error> </rpc-reply>Table 11-7 Description of each field in a response messageField
Description
xmlns
Indicates the NETCONF XML namespace.
message-id
Indicates the information code. The value is specified by the client that initiates the RPC request. After receiving the RPC request message, the server saves the message-id attribute, which is used in an <rpc-reply> message to be generated.
flow-id
Indicates the configuration change ID.
NOTE:The flow-id field is carried only in the running data set of the <edit-config> operation or in the response packet of the <commit> or <sync-full> operation.
flow-id-time
Indicates the time when the configuration change ID is generated.
NOTE:The flow-id-time field is carried only in the running data set of the <edit-config> operation or the response packet of the <commit> operation.
<error-type>
Defines the protocol layer at which an error occurs. The value can be transport, RPC, protocol, or application.
<error-tag>
Indicates the error information.
<error-severity>
Indicates the severity of an error. The value can be error or warning.
<error-app-tag>
Indicates a specific error type. This element is not present if no <error-tag> is associated with the error type.
<error-path>
Indicates the location where the error occurs and the name of the file where the error occurs.
<error-message>
Indicates the description of the error.
<error-info>
Indicates the error information about a specific protocol or data model. This element is not present if the correct <error-info> is not provided.
<error-paras>
Indicates an error parameter list.
NETCONF Subtree Filtering
Overview
Subtree filtering is a mechanism that allows an application to query particular data for a <get> or <get-config> operation.
Subtree filtering provides a small set of filters for inclusion, simple content exact-match, and selection. The NETCONF agent does not need to use any semantics specific to any particular data model during processing, allowing for simple and centralized implementation policies.
Subtree Filter Components
Each node specified in subtree filtering represents a filter. The filter only selects nodes associated with the basic data model of a specified database on the NETCONF server. A node matching any filtering rule and element hierarchy is selected. Table 11-8 describes subtree filter components.
Component |
Description |
|---|---|
Namespace selection |
If namespaces are used, the filter output will include only elements from the specified namespace. |
Containment node |
A containment node is a node that contains child elements within a subtree filter. For each containment node specified in a subtree filter, all data model instances that are exact matches for the specified namespaces and element hierarchy are included in the filter output. |
Content match node |
A content match node is a leaf node that contains simple content within a subtree filter. This node is used to select some or all of its relevant nodes for filter output and represents an exact-match filter of the leaf node element content. |
Selection node |
A selection node is an empty leaf node within a subtree filter. This node represents an explicit selection filter of the underlying data model. Presence of any selection nodes within a set of sibling nodes will cause the filter to select the specified subtrees and suppress automatic selection of the entire set of sibling nodes in the underlying data model. |
Namespace selection
If the XML namespace associated with a specific node in the <filter> element is the same as that in the underlying data model, the namespace is matched.
<filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"/> </filter>
In this example, the <top> element is a selection node. If the node namespace complies with http://example.com/schema/1.2/config, the node and its child nodes will be included in the filter for output.
Containment node
The child element of a containment node can be a node of any type, including another containment node. For each containment node specified in the subtree filter, all data model instances that completely match the specified namespace and element hierarchy, and any attribute-matching expression are included in the output.
<filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <users/> </top> </filter>
In this example, the <top> element is a containment node.
Content match node
A leaf node that contains simple content is called a content match node. It is used to select some or all of its sibling nodes for filter output and represents exact match of the leaf node element content.
<filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>fred</name> </user> </users> </top> </filter>In this example, both the <users> and <user> nodes are containment nodes, and the <name> node is a content match node. Because the sibling nodes of the <name> node are not specified, only <user> nodes that comply with namespace http://example.com/schema/1.2/config, with their element hierarchies matching the name element and their values being fred, can be included in the filter output. All sibling nodes of the <name> node are included in the filter output.
![]()
The support-filter statement in the YANG model indicates whether filtering based on node content is supported when a node is being operated.
- For key nodes, filtering based on node content is supported by default.
- For non-key nodes, filtering based on node content is not supported by default. If the value of the support-filter statement is set to true for a non-key node, filtering based on node content is supported.
Selection node
Selection nodes represent a basic data model for an explicit selection of filters. If any selection node appears in a group of same-level sibling nodes, the filter selects a specified subtree and suppresses the automatic selection of the entire sibling node set in the basic data model. In a filtering expression, an empty tag (such as <foo/>) or an expression with explicit start and end tags (such as <foo> </ foo>) can be used to specify an empty leaf node. In this case, all blank characters will be ignored.
<filter type="subtree"> <top xmlns="http://example.com/schema/1.2/config"> <users/> </top> </filter>
In this example, the <top> node is a containment node, and the <users> node is a selection node. The <users> node can be included for filter output only when the <users> node complies with namespace http://example.com/schema/1.2/config and is contained in the <top> element in the root directory of the configuration database.
Subtree Filter Processing
If no filter is used, all data in the current data model is returned in the query result.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get/> </rpc>
RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <!-- ... entire set of data returned ... --> </data> </rpc-reply>
If an empty filter is used, the query result contains no data output, in that no content match or selection node is specified.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get> <filter type="subtree"> </filter> </get> </rpc>
RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> </data> </rpc-reply>
Multi-subtree filtering
The following example uses the root, fred, and barney subtree filters.
The root subtree filter contains two containment nodes (<users> and <user>), one content match node (<name>), and one selection node (<company-info>). As for subtrees that meet selection criteria, only <company-info> is selected.
The fred subtree filter contains three containment nodes (<users>, <user>, and <company-info>), one content match node (<name>), and one selection node (<id>). As for subtrees that meet the selection criteria, only the <id> element in <company-info> is selected.
The barney subtree filter contains three containment nodes (<users>, <user>, and <company-info>), two content match nodes (<name> and <type>), and one selection node (<dept>). User barney is not of the userbarney type and does not comply with the subtree filtering rule. Therefore, the entire subtree of barney (including its parent node <user>) is not selected.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> <filter type="subtree"> <ifm xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <company-info/> </user> <user> <name>fred</name> <company-info> <id/> </company-info> </user> <user> <name>barney</name> <type>userbarney</type> <company-info> <dept/> </company-info> </user> </users> </ifm> </filter> </get-config> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <ifm xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <company-info> <dept>1</dept> <id>1</id> </company-info> </user> <user> <name>fred</name> <company-info> <id>2</id> </company-info> </user> </users> </ifm> </data> </rpc-reply>
NETCONF Operation Capabilities
NETCONF provides a set of basic operations for you to manage device configurations and retrieve device configuration and status data. NETCONF also provides additional operations based on the capabilities advertised by a device.
Basic NETCONF Operations
get-config
- source: specifies a configuration database in which configuration data is being queried. The value can be <running/>, <candidate/>, or <startup/>.
- filter: specifies a range to be queried in the configuration database. If this parameter is not specified, all configurations on the device are returned.
The following example shows how to query interface configuration of the IFM feature in the <running/> database. The queried interface information is contained in an RPC reply message.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="827"> <get-config> <source> <running/> </source> <filter type="subtree"> <ifm:ifm xmlns:ifm="urn:huawei:yang:huawei-ifm"> <ifm:interfaces> <ifm:interface/> </ifm:interfaces> </ifm:ifm> </filter> </get-config> </rpc>- RPC reply
<?xml version="1.0" encoding="utf-8"?> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name>10GE1/0/1</name> <class>main-interface</class> <type>10GE</type> <number>1/0/1</number> <admin-status>up</admin-status> <link-protocol>ethernet</link-protocol> <statistic-enable>true</statistic-enable> <mtu>1500</mtu> <spread-mtu-flag>false</spread-mtu-flag> <vrf-name>_public_</vrf-name> </interface> </interfaces> </ifm> </data>
get
The <get> operation only retrieves data from the <running/> configuration database.
If the <get> operation is successful, the NETCONF server returns an <rpc-reply> element containing a <data> element with the results of the query. If the operation fails, the server returns an <rpc-reply> element containing an <rpc-error> element.
- The <get-config> operation can retrieve data from the <running/>, <candidate/>, and <startup/> configuration databases, whereas the <get> operation can only retrieve data from the <running/> configuration database.
- The <get-config> operation can only retrieve configuration data, whereas the <get> operation can retrieve both configuration and status data.
The following example shows how to query interface configuration of the IFM feature in the database. The queried interface information is contained in an RPC reply message.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="831"> <get> <filter type="subtree"> <ifm:ifm xmlns:ifm="urn:huawei:yang:huawei-ifm"> <ifm:interfaces> <ifm:interface/> </ifm:interfaces> </ifm:ifm> </filter> </get> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name>10GE1/0/1</name> <index>4</index> <class>main-interface</class> <type>10GE</type> <position>0/0/0</position> <number>1/0/1</number> <admin-status>up</admin-status> <link-protocol>ethernet</link-protocol> <statistic-enable>true</statistic-enable> <mtu>1500</mtu> <spread-mtu-flag>false</spread-mtu-flag> <vrf-name>_public_</vrf-name> <dynamic> <oper-status>up</oper-status> <physical-status>up</physical-status> <link-status>up</link-status> <mtu>1500</mtu> <bandwidth>100000000</bandwidth> <ipv4-status>up</ipv4-status> <ipv6-status>down</ipv6-status> <is-control-flap-damp>false</is-control-flap-damp> <mac-address>00e0-fc12-3456</mac-address> <line-protocol-up-time>2019-05-25T02:33:46Z</line-protocol-up-time> <is-offline>false</is-offline> <link-quality-grade>good</link-quality-grade> </dynamic> <mib-statistics> <receive-byte>0</receive-byte> <send-byte>0</send-byte> <receive-packet>363175</receive-packet> <send-packet>61660</send-packet> <receive-unicast-packet>66334</receive-unicast-packet> <receive-multicast-packet>169727</receive-multicast-packet> <receive-broad-packet>127122</receive-broad-packet> <send-unicast-packet>61363</send-unicast-packet> <send-multicast-packet>0</send-multicast-packet> <send-broad-packet>299</send-broad-packet> <receive-error-packet>0</receive-error-packet> <receive-drop-packet>0</receive-drop-packet> <send-error-packet>0</send-error-packet> <send-drop-packet>0</send-drop-packet> </mib-statistics> <common-statistics> <stati-interval>300</stati-interval> <in-byte-rate>40</in-byte-rate> <in-bit-rate>320</in-bit-rate> <in-packet-rate>2</in-packet-rate> <in-use-rate>0.01%</in-use-rate> <out-byte-rate>0</out-byte-rate> <out-bit-rate>0</out-bit-rate> <out-packet-rate>0</out-packet-rate> <out-use-rate>0.00%</out-use-rate> <receive-byte>0</receive-byte> <send-byte>0</send-byte> <receive-packet>363183</receive-packet> <send-packet>61662</send-packet> <receive-unicast-packet>66334</receive-unicast-packet> <receive-multicast-packet>169727</receive-multicast-packet> <receive-broad-packet>127122</receive-broad-packet> <send-unicast-packet>61363</send-unicast-packet> <send-multicast-packet>0</send-multicast-packet> <send-broad-packet>299</send-broad-packet> <receive-error-packet>0</receive-error-packet> <receive-drop-packet>0</receive-drop-packet> <send-error-packet>0</send-error-packet> <send-drop-packet>0</send-drop-packet> <send-unicast-bit>0</send-unicast-bit> <receive-unicast-bit>0</receive-unicast-bit> <send-multicast-bit>0</send-multicast-bit> <receive-multicast-bit>0</receive-multicast-bit> <send-broad-bit>0</send-broad-bit> <receive-broad-bit>0</receive-broad-bit> <send-unicast-bit-rate>0</send-unicast-bit-rate> <receive-unicast-bit-rate>0</receive-unicast-bit-rate> <send-multicast-bit-rate>0</send-multicast-bit-rate> <receive-multicast-bit-rate>0</receive-multicast-bit-rate> <send-broad-bit-rate>0</send-broad-bit-rate> <receive-broad-bit-rate>0</receive-broad-bit-rate> <send-unicast-packet-rate>0</send-unicast-packet-rate> <receive-unicast-packet-rate>0</receive-unicast-packet-rate> <send-multicast-packet-rate>0</send-multicast-packet-rate> <receive-multicast-packet-rate>0</receive-multicast-packet-rate> <send-broadcast-packet-rate>0</send-broadcast-packet-rate> <receive-broadcast-packet-rate>0</receive-broadcast-packet-rate> </common-statistics> </interface> </ifm> </data>
edit-config
The <edit-config> operation loads all or some configurations to a specified target configuration database (<running/> or <candidate/>).
The <edit-config> operation supports multiple modes for loading configurations. For example, you can load local and remote files, and edit files online. If a NETCONF server supports the URL capability, the <url> parameter (which identifies a local configuration file) can be used to replace the <config> parameter.
<config>: indicates a group of hierarchical configuration items defined in the data model.
The <config> parameter may contain the optional operation attribute, which is used to specify an operation type for a configuration item. If the operation attribute is not present, the <merge> operation is performed by default. The values of the operation attribute are as follows:- merge: modifies or creates data in the database. This is the default operation.
- create: adds configuration data to the configuration database only if such data does not exist. If the configuration data already exists, <rpc-error> is returned, in which the <error-tag> value is data-exists.
- delete: deletes a specified configuration data record from the configuration database. If the data exists, it is deleted. If the data does not exist, <rpc-error> is returned, in which the <error-tag> value is data-missing.
- remove: removes a specified configuration data record from the configuration database. If the data exists, it is deleted. If the data does not exist, a success message is returned.
- replace: replaces existing data or creates data that does not exist in the database.
<target>: indicates the configuration database to be edited. The configuration database can be set based on scenarios.
In immediate validation mode, set the database to <running/>.
In two-phase validation mode, set the database to <candidate/>. After editing the database, perform the <commit> operation so that the modified configuration takes effect.
In trial mode, set the database to <candidate/>.
<default-operation>: sets a default operation for the <edit-config> operation.
The <default-operation> parameter is optional. Its values are as follows:
merge: merges the configuration data in the <config> parameter with that in the target configuration database. This is the default operation.
replace: completely replaces the configuration data in the target configuration database with the configuration data in the <config> parameter.
none: ensures that the configuration data in <config> does not affect that in the target configuration database, with the exception that the operation specified by the <operation> attribute is performed. If the <config> parameter contains configuration data that does not exist at the corresponding data level in the target configuration database, <rpc-error> is returned, in which the <error-tag> value is data-missing. This prevents redundant elements from being created when a specified operation is performed. For example, when a specified child element is deleted, <config> contains the parent hierarchical structure of the child element but the target database does not contain the configuration of the parent element. If the value of the <default-operation> parameter is not none, the configuration of the parent element is created in the database when the child element is deleted. Otherwise, the child element is deleted, and the configuration of the parent element is not created.
<error-option>: sets a mode for processing subsequent instance configurations if an error occurs in the current instance configuration. Its values are as follows (the default value is stop-on-error):
- If the target configuration database is <running/>:
- stop-on-error: stops the operation if an error occurs and rolls back the configuration according to rollback-on-error.
- continue-on-error: records the error information and continues the execution after an error occurs. If an error occurs, the NETCONF server returns an RPC reply message to the client, indicating an operation failure.
- rollback-on-error: stops the operation after an error occurs and rolls back the configuration to the state before the <edit-config> operation is performed. This operation is supported only when the device supports the rollback-on-error capability.
- If the target configuration database is <candidate/>, set the value of <error-option> to rollback-on-error for subsequent instances after an error occurs in the current instance configuration.
The following example shows how to change the ifDescr value of 10GE1/0/1 in the running configuration database to huawei.- RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="15"> <edit-config> <target> <running/> </target> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name>10GE1/0/1</name> <class>main-interface</class> <type>10GE</type> <number>1/0/1</number> <admin-status>up</admin-status> </interface> </interfaces> </ifm> </config> </edit-config> </rpc> - RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="15" nc-ext:flow-id="27" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>
The following example shows how to delete the configuration of the interface named LoopBack1023 from the running configuration database.- RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="844"> <edit-config> <target> <running/> </target> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"> <name>LoopBack1023</name> </interface> </interfaces> </ifm> </config> </edit-config> </rpc> - RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="844" nc-ext:flow-id="29" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>
- If the target configuration database is <running/>:
If the <test-option> parameter value is test-then-set or the parameter is not specified, nodes at any layer support the <replace> operation, which replaces the configuration in the target database with that in the current RPC request.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id=""> <edit-config> <target> <running/> </target> <config> <acl xmlns="urn:huawei:yang:huawei-acl"> <groups> <group nc:operation="replace" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <identity>2000</identity> <type>basic</type> <match-order>config</match-order> <step>5</step> </group> </groups> </acl> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="849" nc-ext:flow-id="31" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>If the <test-option> parameter value is test-then-set or the parameter is not specified, nodes at any layer support the <delete> and <remove> operations, which delete all configuration data of a specified node in the configuration database.
The following example shows how to delete the vplsInstances configuration.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="849"> <edit-config> <target> <running/> </target> <config> <l2vpn xmlns="urn:huawei:yang:huawei-l2vpn"> <instances xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="delete"/> </l2vpn> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="849" nc-ext:flow-id="31" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>
copy-config
- The configuration data in the <candidate/> and <running/> databases can be saved to a specified URL file.
- The configuration data in the <running/> database can be copied to the <candidate/> or <startup/> database.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <copy-config> <target> <url>file:///abc.xml</url> </target> <source> <running/> </source> </copy-config> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <copy-config> <target> <url>ftp://root:root@10.1.1.1/abc.xml</url> </target> <source> <candidate/> </source> </copy-config> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
delete-config
This operation deletes a configuration database. The <running/> configuration database cannot be deleted.
If the <delete-config> operation is successful, the server sends an <rpc-reply> element containing an <ok> element. Otherwise, the server sends an <rpc-reply> element containing an <rpc-error> element.
The following is an example of deleting the <startup/> database.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <delete-config> <target> <startup/> </target> </delete-config> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
lock
This operation locks a configuration database of a device, preventing it from being modified by other users. The locks eliminate errors caused by simultaneous modifications of the database by NETCONF managers or SNMP or CLI scripts.
If the configuration database is already locked by an authorized user, the <error-tag> element will be displayed as lock-denied and the <error-info> element will include <session-id> of the lock owner in the reply message.
The following example shows a successful locking of the <running/> configuration database.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <lock> <target> <running/> </target> </lock> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
The following example shows a failure to lock the <running/> configuration database.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <lock> <target> <running/> </target> </lock> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>protocol</error-type> <error-tag>lock-denied</error-tag> <error-severity>error</error-severity> <error-app-tag>43</error-app-tag> <error-message>The configuration is locked by other user. [Session ID = 629] </error-message> <error-info> <session-id>629</session-id> <error-paras> <error-para>629</error-para> </error-paras> </error-info> </rpc-error> </rpc-reply>
unlock
This operation cancels the <lock> operation performed by the specified user, rather than the <lock> operation performed by other users.
If the <unlock> operation is successful, the server sends an <rpc-reply> element containing an <ok> element. Otherwise, the server sends an <rpc-reply> element containing an <rpc-error> element.
The following is an example of unlocking the <running/> database.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <unlock> <target> <running/> </target> </unlock> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
close-session
This operation terminates a NETCONF session.
After receiving a <close-session> request, the NETCONF server terminates the current NETCONF session. The server releases all locks and resources associated with the session. After receiving a <close-session> request, the NETCONF server ignores all request messages of the session.
The following is an example of terminating the current NETCONF session.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <close-session/> </rpc>
RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
kill-session
The <kill-session> operation forcibly terminates a NETCONF session. Only an administrator is authorized to perform this operation.
After receiving a <kill-session> request, the NETCONF server stops all operations that are being performed for the session, releases all the locks and resources associated with the session, and terminates the session.
If the NETCONF server receives a <kill-session> request when performing the <commit> operation, it must restore the configuration to the state before the configuration is committed.
The following is an example of forcibly terminating the NETCONF session with the session ID of 4.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <kill-session> <session-id>4</session-id> </kill-session> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
NETCONF Standard Capability Set
Writable-running
This capability indicates that the device supports direct writes to the <running/> configuration database. Specifically, the device supports <edit-config> and <copy-config> operations on the <running/> configuration database.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name>10GE1/0/1</name> <mtu>1500</mtu> </interface> </interfaces> </ifm> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101" nc-ext:flow-id="27" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>
Candidate Configuration
This capability indicates that the device supports the <candidate/> configuration database.
The <candidate/> configuration database holds a complete set of configuration data that can be manipulated without impacting the device's current configuration. This configuration database serves as a work place for manipulating configuration data.
Additions, deletions, and changes can be made to the data in the <candidate/> configuration database to construct the desired configuration data. The following operations can be performed at any time:
<commit>: converts all configuration data in the <candidate/> configuration database into running configuration data.
If the <commit> operation fails, the content in the <candidate/> configuration database remains unchanged.
<discard-changes>: discards uncommitted configuration data in the <candidate/> configuration database. After this operation is performed, the configuration data in the <candidate/> configuration database is the same as that in the <running/> configuration database again.
A device establishes an independent <candidate/> configuration database for each NETCONF session.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <candidate/> </target> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name>10GE1/0/1</name> <mtu>1500</mtu> </interface> </interfaces> </ifm> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <ok/> </rpc-reply>
Confirmed Commit
This capability indicates that the device can confirm configurations. In other words, the <commit> message delivered in this instance does not directly commit the configuration and depends on the next <commit> message to trigger configuration commitment.
confirmed-commit:1.0
The <commit> operation can carry the <confirmed> and <confirm-timeout> parameters.
- <confirmed>: submits the configuration data in the <candidate/> configuration database and converts it into the running configuration data on a device (configuration data in the <running/> configuration database).
- <confirm-timeout>: specifies a timeout period for confirming the <commit> operation, in seconds. The default value is 600s. After the <commit> operation is performed, if the confirmation operation is not performed within the timeout period, the configuration in the <running/> configuration database is rolled back to the state before the <commit> operation is performed and the modified data in the <candidate/> configuration database is abandoned.
This capability is valid only when the device supports the candidate configuration capability. It is mainly used in service trial running and verification scenarios.
The following is an example of submitting the current configuration and setting the timeout period for confirming the <commit> operation to 120s.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit> <confirmed/> <confirm-timeout>120</confirm-timeout> </commit> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101" nc-ext:flow-id="29" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>
confirmed-commit:1.1
The <commit> operation can carry the <persist> and <persist-id> parameters.
If a <confirmed-commit> message carries the <persist> parameter, the trial run operation created using <confirmed-commit> is still effective after the associated session is terminated. The device allows a message to carry the <persist-id> parameter to update an existing trial run operation.
The following example shows how to carry the <persist> parameter in a message for the <commit> operation.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3"> <commit> <confirmed/> <persist>123</persist> </commit> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3" nc-ext:flow-id="29" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>The following example shows how to carry the <persist-id> parameter in a message for the <commit> operation.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <commit> <confirmed/> <persist-id>123</persist-id> </commit> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2" nc-ext:flow-id="29" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>The <cancel-commit> operation is supported. The <persist-id> parameter can be carried to terminate the trial run operation being executed, which is created using <confirmed-commit> with the <persist> parameter.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <cancel-commit> <persist-id>IQ,d4668</persist-id> </cancel-commit> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <ok/> </rpc-reply>
Rollback on Error
This capability allows the device to perform a rollback when an error occurs. Specifically, "rollback-on-error" can be carried in the <error-option> parameter of the <edit-config> operation. If an error occurs and the <rpc-error> element is generated, the server stops performing the <edit-config> operation and restores the specified configuration to the state before the <edit-config> operation is performed.
This capability is valid only when the device supports the candidate configuration capability.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <error-option>rollback-on-error</error-option> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name>10GE1/0/1</name> <mtu>1000</mtu> </interface> </interfaces> </ifm> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101" nc-ext:flow-id="27" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>
Distinct Startup
This capability indicates that the device can perform an independent startup. Specifically, the device can distinguish the <running/> configuration database from the <startup/> configuration database.
The NETCONF server needs to independently maintain the running configuration and restore the configuration after the device restarts. Because the configuration data of the <running/> configuration database is not automatically synchronized to the <startup/> configuration database, you must copy the data from the <running/> configuration database to the <startup/> configuration database by using an operation such as a <copy-config>.
The following is an example of executing the <copy-config> operation to copy the data from the <running/> database to the <startup/> database.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <copy-config> <source> <running/> </source> <target> <startup/> </target> </copy-config> </rpc>RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
XPath Capability
This capability indicates that the device can use XPath expressions in the <filter> element as query conditions, and the <get> and <get-config> operations can query specified data through an XPath.
XPath — XML Path Language — uses path expressions for the addressing of parts of an XML file. The XPath syntax is similar to the file path in the file management system.
If an XPath expression is used as a filter criterion, the value of the type attribute in the <filter> element is xpath, and the value of the select attribute (which must exist) is the XPath expression.
<filter xmlns:acm="urn:ietf:params:xml:ns:yang:ietf-netconf-acm" type="xpath" select="/acm:nacm/acm:rule-list[acm:name='2000']"/>
- An XPath can only function as a basic absolute path, and steps are separated using slashes (/), for example, /acl/aclGroups/aclGroup.
- Only predicates in the [node name='value'] format (for example, [genre='Computer']) are supported, and there can be multiple predicates in an AND relationship. In the following example, the predicate is [acm:name='2000'].
<filter xmlns:acm="urn:ietf:params:xml:ns:yang:ietf-netconf-acm" type="xpath" select="/acm:nacm/acm:rule-list[acm:name='2000']"/>
- XPath supports multiple namespaces, which are separated using colons.
XPath expressions cannot be used as filter criteria for such operations as notifications, full synchronization, incremental synchronization, or copy-config.
XPath expressions support the following operations:
Use the specified XPath as a filter criterion to query information about all nodes in the XPath.
The following is an example of querying information about all nodes in the /acl:acl/acl:groups/acl:group XPath of the <running/> database.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="19"> <get-config> <source> <running/> </source> <filter xmlns:acl="urn:huawei:yang:huawei-acl" type="xpath" select="/acl:acl/acl:groups/acl:group"/> </get-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="6"> <data> <acl xmlns="urn:huawei:yang:huawei-acl"> <groups> <group> <identity>2000</identity> <type>basic</type> <match-order>config</match-order> <step>5</step> </group> </groups> </acl> </data> </rpc-reply>Use the value of a node in the specified XPath as a filter criterion to query information about the node that matches this value in the XPath.
The following is an example of querying information about the node for which "identity" is set to 2000 in the /acl:acl/acl:groups/acl:group XPath of the <running/> database.
RPC request
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> <get-config> <source> <running/> </source> <filter type="xpath" xmlns:acl="urn:huawei:yang:huawei-acl" select="/acl:acl/acl:groups/acl:group[acl:identity='2000']"/> </get-config> </rpc>- RPC reply
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> <data> <acl xmlns="urn:huawei:yang:huawei-acl"> <groups> <group> <identity>2000</identity> <type>basic</type> <match-order>config</match-order> <step>5</step> </group> </groups> </acl> </data> </rpc-reply>
Use two or more XPaths in the OR relationship as filter criteria to query information about the same node in all expressions.
The following is an example of querying information about the same node in the /nacm/rule-list/group and /nacm/rule-list/rule XPaths of the <candidate/> database.
- RPC request
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <candidate/> </source> <filter type="xpath" select="/t:nacm/t:rule-list/t:group | /t:nacm/t:rule-list/t:rule" xmlns:t="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/> </get-config> </rpc> - RPC reply
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <rule-list> <name>list1</name> <group>group1</group> <rule> <name>rule11</name> <module-name>*</module-name> <access-operations>create read update delete</access-operations> <action>permit</action> <rpc-name>commit</rpc-name> </rule> <rule> <name>rule12</name> <module-name>*</module-name> <access-operations>read</access-operations> <action>deny</action> <rpc-name>edit-config</rpc-name> </rule> </rule-list> <rule-list> <name>list2</name> <group>group2</group> <rule> <name>rule21</name> <module-name>*</module-name> <access-operations>create read update delete</access-operations> <action>permit</action> <rpc-name>commit</rpc-name> </rule> </rule-list> </nacm> </data> </rpc-reply>
- RPC request
Use the /* symbol as a filter criterion to query information about all nodes in the specified XPath (before the * symbol).
The following is an example of querying information about all nodes in the /nacm XPath of the <candidate/> database.
- RPC request
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <candidate/> </source> <filter type="xpath" select="/t:nacm/*" xmlns:t="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"/> </get-config> </rpc> - RPC reply
<rpc-reply message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <enable-nacm>false</enable-nacm> <read-default>deny</read-default> <write-default>deny</write-default> <exec-default>deny</exec-default> <groups> <group> <name>group1</name> <user-name>puneeth1</user-name> <user-name>puneeth2</user-name> <user-name>puneeth3</user-name> </group> <group> <name>group2</name> <user-name>puneeth1</user-name> <user-name>puneeth2</user-name> <user-name>puneeth3</user-name> </group> </groups> <rule-list> <name>list1</name> <group>group1</group> <rule> <name>rule11</name> <module-name>*</module-name> <access-operations>create read update delete</access-operations> <action>permit</action> <rpc-name>commit</rpc-name> </rule> <rule> <name>rule12</name> <module-name>*</module-name> <access-operations>read</access-operations> <action>deny</action> <rpc-name>edit-config</rpc-name> </rule> </rule-list> </nacm> </data> </rpc-reply>
- RPC request
- Pagination query is supported. That is, in the <get-config> and <get> operations, the optional parameter [position() >= a and position() <= b] is added to the XPath filter expression to query the data of the list/leaf-list nodes in the specified range [a, b].
- You can specify the left and right boundaries, which are interchangeable, for the pagination query.
For example, either of the following expressions is used to query the data of nodes 1 to 100 on the list node interface.
select="/ifm:ifm/ifm:interfaces/ifm:interface[position() >= 1 and position() <= 100] "
select="/ifm:ifm/ifm:interfaces/ifm:interface[position() <= 100 and position() >= 1] "
- You can specify the same left and right boundary values for the pagination query. If they are the same, the query range is a fixed value rather than a value range.
For example, the following expression is used to query the data of the first node on the list node interface.
select="/ifm:ifm/ifm:interfaces/ifm:interface[position() >= 1 and position() <= 1] "
- You can specify only one boundary (left or right) for the pagination query. If only the left boundary is specified, the data of the specified node and all the subsequent nodes is queried. Conversely, if only the right boundary is specified, the data of node 1 to the specified node is queried.
For example, the first of the following two expressions is used to query information about node 100 and all the subsequent nodes on the list node interface, and the second expression is used to query information about nodes 1 to 200 on the list node interface.
select="/ifm:ifm/ifm:interfaces/ifm:interface[position() >= 100] "
select="/ifm:ifm/ifm:interfaces/ifm:interface[position() <= 200] "
- The pagination query function verifies a specified query range, which must meet the following conditions:
- The left boundary value must be less than or equal to the right boundary value.
- The left and right boundary values are integers ranging from 1 to 1000000000. If the left boundary of the specified query range exceeds the actual number of data records to be queried, no query result is displayed.
- The pagination query function supports query based on multiple filter criteria, meaning that each query can contain more than one filter criterion.
For example, the following expression contains two filter criteria, indicating that the LoopBack port data of nodes 1 to 100 is queried.
select="/ifm:ifm/ifm:interfaces/ifm:interface[ifm:type='LoopBack'][position() >= 1 and position()<= 100]"
- Only the list and leaf-list nodes support the pagination query function, and no other node can follow the position() parameter.
For example:
select="/ifm:ifm/ifm:interfaces/ifm:interface[position() >= 1 and position() <= 100] "
In the preceding expression, the node interface is a list node, and the expression [position() >= 1 and position() <= 100] is not followed by another node.
- Multiple position() parameters cannot be combined by the OR symbol (|) to deliver the pagination query operation. To query different services, you must therefore deliver the pagination query operations separately.
- If a user sends two pagination query requests at a maximum interval of 3 minutes, the entered XPaths are the same (same prefix, namespace, and node), and the input numbers for the pagination query are consecutive, the device considers the later query request as part of the first one and preferentially obtains the data to be queried from the cache. If the input numbers for pagination query are not consecutive or the interval between two requests exceeds 3 minutes, the later query operation is processed as a new request. The queried content is obtained from the device configuration database.
For example:
- A user delivers two pagination query requests within 3 minutes. The first queries the content of nodes 1 to 100 of a specified list/leaf-list node, and the second queries the content of nodes 101 to 200 of the same XPath. If the device configuration changes at any time between the two query operations, the data queried by the user is the data before the change, that is, the data in the cache.
- If a user delivers two pagination query requests (with the first querying the content of nodes 1 to 100 and the second querying the content of nodes 301 to 400) and the device configuration changes at any time between the two query operations, the pre-change data is obtained for the first request and the post-change data is obtained for the second. This is true regardless of whether the interval between the two requests exceeds 3 minutes.
- The same XPath indicates that the prefixes, namespaces, and nodes are identical. If one of them is different, the queries are considered to be different. For example, the XPath prefixes of the following two expressions are considered different, meaning that the device processes them as two independent requests.
select="/t:ifm/t:interfaces/t:interface[t:type='LoopBack'][position() >= 1 and position()<= 100]"
select="/l:ifm/l:interfaces/l:interface[l:type='LoopBack'][position() >= 101 and position()<= 200]"
![]()
During packet delivery, the greater-than sign (>) and less-than sign (<) in the position() expression must be represented by the escape characters > and <.
For example, query information about the first and second NACM authentication user groups in the <running/> configuration database.
- RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="827"> <get-config> <source> <running/> </source> <filter xmlns:t="urn:ietf:params:xml:ns:yang:ietf-netconf-acm" type="xpath" select="/t:nacm/t:groups/t:group[position()>=1 and position()<=2]"/> </get-config> </rpc> - RPC reply
<?xml version="1.0" encoding="utf-8"?> <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <nacm xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-acm"> <groups> <group> <name>1</name> <user-name>test1</user-name> <user-name>test2</user-name> <user-name>test3</user-name> <user-name>test4</user-name> </group> <group> <name>2</name> <user-name>test1</user-name> <user-name>test2</user-name> <user-name>test3</user-name> </group> </groups> </nacm> </data>
- You can specify the left and right boundaries, which are interchangeable, for the pagination query.
Validate
This capability indicates that the device can deliver configurations without considering the configuration sequence. During the delivery, the device checks only the syntactic validity of configurations rather than the configuration sequence. The device checks semantic validity when committing the configurations. After correcting the configuration delivery sequence, the device commits the configurations to the <running/> configuration database.
Before performing the validate operation, you are advised to lock the <running/> configuration database to prevent adverse impacts on the validate operation when other users operate the <running/> configuration database.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <validate> <source> <candidate/> </source> </validate> </rpc>
RPC reply
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
- Syntactic check: checks RPC packet validity, model matching, data type, value range, authorization, whether data to be created already exists or data to be deleted has already been deleted, and whether there is a parent node.
- Semantic check: checks semantic items, such as the dependency between configurations.
The <source> parameter of the validate operation supports only the <candidate/> and <running/> configuration databases.
- test-then-set: The system checks the delivered configurations for syntactic and semantics errors. If the check succeeds, the system modifies the configuration. If the check fails, the system displays a failure message and the failure cause and does not modify the configuration.
- set: The system checks configurations for syntactic errors. If no errors are found, the system commits the configurations to the <candidate/> configuration database. Semantic errors are not checked. However, when performing the commit or confirmed-commit operation, the system checks configurations for semantic errors and commits the configurations to the <running/> configuration database if no errors are found.
- test-only: The system checks configurations only for syntactic and semantic errors and reports the result without committing the configurations to any configuration database.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <test-option>test-then-set</test-option> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge"> <name>10GE1/0/1</name> <description>text</description> </interface> </interfaces> </ifm> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2" nc-ext:flow-id="27" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>
URL
- <edit-config>: submits the configuration file in a specified path to <candidate/> or <running/>.
- <copy-config>: copies data in <candidate/> or <running/> to a file in a specified path.
- The SFTP or FTP protocol is used to query files on an SFTP or FTP server. The path format is ftp://user name:password@IP address of the SFTP or FTP server/file directory/file name.
- The file protocol is used to query local files. The path format is file:///file directory/file name.
The HTTP or HTTPS protocol is used to search for files on an HTTP or HTTPS server. The path format is http (or https)://IP address of the HTTP or HTTPS server (or DNS):port number/file directory/file name.
The file name is a string of case-sensitive characters starting with an underscore (_) or a letter. It supports only underscores, digits, and letters. The dot (.) can be used only in the file name extension, and only one dot is supported. The file name including a path cannot contain more than 256 characters.
For the <copy-config> operation, if the file specified in the <url> element does not exist, the file is directly created. If the file exists, it is overwritten.
When you perform the <edit-config> operation, the file specified in <url> must exist.
The HTTP or HTTPS protocol supports only the <edit-config> operation in a YANG model.
Copy the data in the <running/> configuration database to the local abc.xml file.
RPC request
<?xml version="1.0" encoding="UTF-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <copy-config> <target> <url>file:///abc.xml</url> </target> <source> <running/> </source> </copy-config> </rpc>
RPC reply
<?xml version="1.0" encoding="UTF-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5"> <ok/> </rpc>
The following is an example of committing the content of the config.xml file on the FTP server to the <candidate/> database.
RPC request
<?xml version="1.0" encoding="UTF-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5"> <edit-config> <target> <candidate/> </target> <url>ftp://root:root@10.1.1.2/config.xml</url> </edit-config> </rpc>
RPC reply
<?xml version="1.0" encoding="UTF-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5"> <ok/> </rpc>
RPC request
<?xml version="1.0" encoding="UTF-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <edit-config> <target> <candidate/> </target> <url>http://192.168.1.1:8080/config.xml</url> </edit-config> </rpc>- RPC reply
<?xml version="1.0" encoding="UTF-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <ok/> </rpc>
Notification Capabilities
Notification 1.0
A device can send alarms and events to a client using the NETCONF notification capability, thereby allowing the client to promptly detect device configuration or other changes. You can perform the <create-subscription> operation to subscribe to device alarms and events. If the <rpc-reply> element returned by the device contains an <ok> element, the <create-subscription> operation is successful. In this case, the device will proactively report the generated alarms and events to the client through NETCONF.
- Alarms and events can be subscribed to in either of the following modes: long-term subscription and subscription within a specified period.
Long-term subscription: After the subscription is successful, if the <startTime> element is specified in the subscription message, the device sends historical alarms and events to the NMS and then sends a <replayComplete> message to notify the NMS that the replay is complete. If a new alarm or event is generated, the device also sends it to the NMS. If the <startTime> element is not specified in the subscription message, the device sends all newly generated alarms and events to the NMS. After a NETCONF session is terminated, the subscription is automatically canceled.
Subscription within a specified period: After the subscription is successful, the device sends the alarms and events that are generated during the specified period and that meet the filtering conditions to the NMS. Because the <startTime> element is specified in the subscription message, the device sends historical alarms and events to the NMS and then sends a <replayComplete> message to notify the NMS that the replay is complete. When the specified <stopTime> has been reached, the NETCONF module sends a <notificationComplete> message to notify the NMS that the subscription is terminated.
Historical alarms and events refer to those generated from the <startTime> specified in the subscription message to when the user performs the subscription operation. If <stopTime> is not specified, the subscription is a long-term one. If both <startTime> and <stopTime> are specified, the subscription is within a specified period. The format of the subscription message sent by the device to the NMS is as follows:
RPC request (NETCONF subscription)
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <stream>NETCONF</stream> <filter type="subtree"> <hwCPUUtilizationRisingAlarm xmlns="urn:huawei:yang:huawei-sem" /> </filter> <startTime>2016-10-20T14:50:00Z</startTime> <stopTime>2016-10-23T06:22:04Z</stopTime> </create-subscription> </rpc>RPC reply (NETCONF subscription)
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
RPC request (NETCONF-WITH-RES-CONFIG subscription)
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <stream>NETCONF-WITH-RES-CONFIG</stream> <filter type="subtree"> <netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications"/> </filter> </create-subscription> </rpc>RPC reply (NETCONF-WITH-RES-CONFIG subscription)
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="5"> <ok/> </rpc-reply>
Example of reporting a notification (NETCONF-WITH-RES-CONFIG subscription)
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2020-12-09T20:41:14Z</eventTime> <alt-resource-config xmlns="urn:huawei:yang:huawei-notification-common"> <notification-id>135598331</notification-id> <notification-class>event</notification-class> <event-level>informational</event-level> </alt-resource-config> <netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications"> <changed-by> <server/> </changed-by> <datastore>running</datastore> </netconf-config-change> </notification>Table 11-9 Element descriptionsElement
Description
Value Range
Mandatory
Constraints
stream
Event flow type
The value is a case-sensitive enumerated type and can be:
- NETCONF: indicates that the NETCONF notification mechanism is used to report alarms and events.
- NETCONF-WITH-RES-CONFIG: indicates that the reported alarms or events carry Huawei's proprietary extension attribute huawei-notification-common.
No
N/A
filter
Alarm or event filter
The value is a string of characters in the format of <alarm name xmlns=namespace of the alarm name/> or <event name xmlns=namespace of the event name/>.
No
If no filter is specified, all alarms and events that can be reported through notifications are subscribed to.
startTime
Start time
The value is in the time format.
No
The start time must be earlier than the time when the subscription operation is performed.
stopTime
End time
The value is in the time format.
No
The end time must be later than the start time.
- After the subscription is successful, the device encapsulates the alarm or event information into notification messages and sends them to the NMS.
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2016-11-26T13:51:00Z</eventTime> <hwCPUUtilizationResume xmlns="urn:huawei:yang:huawei-sem"> <TrapSeverity>0</TrapSeverity> <ProbableCause>0</ProbableCause> <EventType>0</EventType> <PhysicalIndex>0</PhysicalIndex> <PhysicalName>SimulateStringData</PhysicalName> <RelativeResource>SimulateStringData</RelativeResource> <UsageType>0</UsageType> <SubIndex>0</SubIndex> <CpuUsage>0</CpuUsage> <Unit>0</Unit> <CpuUsageThreshold>0</CpuUsageThreshold> </hwCPUUtilizationResume> </notification>
- After alarms and events are reported to the NMS, the NETCONF module sends a subscription completion message to the NMS.
After historical alarms and events are reported to the NMS, the NETCONF module sends a replayComplete message to the NMS.
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2016-11-29T11:57:15Z</eventTime> <replayComplete xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0" /> </notification>
When <stopTime> specified in the subscription message has been reached, the NETCONF module sends a notificationComplete message to notify the NMS that the subscription is terminated.
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventTime>2016-11-29T11:57:25Z</eventTime> <notificationComplete xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0" /> </notification>
Table 11-10 Element descriptionsElement
Description
Value Range
Mandatory
Constraints
replayComplete
After historical alarms and events are reported to the NMS, the NETCONF module sends a replayComplete message to the NMS.
N/A
No
N/A
notificationComplete
When <stopTime> specified in the subscription message has been reached, the NETCONF module sends a notificationComplete message to notify the NMS that the subscription is terminated.
N/A
No
N/A
YANG-library
This capability indicates that a device can provide the YANG capabilities that it supports. Basic information about YANG modules that a server supports can be viewed on a NETCONF client. The information includes the module name, YANG model version, namespace, and list of submodules and is saved in the local buffer.
- revision: indicates the revision date. It is the same as the module revision date.
- module-set-id: indicates the ID of a module set, which is used to identify the set of YANG modules supported by the server. If the YANG module changes, the module set ID changes accordingly.
The following is an XML example of querying the module-set-id value of the YANG module whose name is ietf-yang-library and conformance-type is implement and querying basic information about the YANG module huawei-aaa.
RPC request
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="23">
<get>
<filter type="subtree">
<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module-set-id></module-set-id>
<module>
<name>ietf-yang-library</name>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>huawei-aaa</name>
</module>
</modules-state>
</filter>
</get>
</rpc>
Information contained in the reply includes the module-set-id value, YANG module version used, namespace, list of submodules, and revision date. If the reply does not contain the YANG module version information, YANG1.0 is used by default.
RPC reply
<?xml version="1.0" encoding="utf-8"?>
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module-set-id>2148066159</module-set-id>
<module>
<name>ietf-yang-library</name>
<revision>2016-06-21</revision>
<namespace>urn:ietf:params:xml:ns:yang:ietf-yang-library</namespace>
<conformance-type>implement</conformance-type>
</module>
<module>
<name>huawei-aaa</name>
<revision>2020-03-23</revision>
<namespace>urn:huawei:yang:huawei-aaa</namespace>
<conformance-type>implement</conformance-type>
<deviation>
<name>huawei-aaa-deviations-cx</name>
<revision>2020-03-23</revision>
</deviation>
<submodule>
<name>huawei-aaa-lam</name>
<revision>2020-03-23</revision>
</submodule>
<submodule>
<name>huawei-aaa-type</name>
<revision>2020-03-23</revision>
</submodule>
</module>
</modules-state>
</data>
NETCONF Extended Capability Set
Sync
This capability enables a device to perform full or incremental data synchronization. Through data synchronization, the NMS or controller that manages network devices can have the same configuration data with NEs in real time.
Full Synchronization
The <sync-full> operation requests a device to implement full data synchronization. After the NMS connects to an NE for the first time, it synchronizes all data of the NE to the NMS.
The YANG model defines the capability in the huawei-netconf-sync.yang file.
After the server receives an <rpc> element containing a <sync-full> element, the server performs a syntax check on the <rpc> element. If the element fails the syntax check, the server returns an <rpc-reply> element containing an <rpc-error> element to terminate processing. Otherwise, the server responds with <rpc-reply>, obtains the synchronization data, encapsulates the data in XML format, writes the data into XML files by feature, compresses the data into a .zip file, and automatically transfers the file to the specified directory through FTP or SFTP. SFTP is recommended because it is more secure than FTP.
Full synchronization supports the following functions:
- Cancels a specific full data synchronization operation.
- Uploads a full data synchronization file.
- Queries the file upload progress.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <sync-full xmlns="urn:huawei:yang:huawei-netconf-sync"> <target> <user-name>root</user-name> <password>YsHsjx_202206</password> <target-addr>10.1.1.1</target-addr> <path>/home</path> </target> <transfer-protocol>ftp</transfer-protocol> <transfer-method>auto</transfer-method> <filename-prefix>Multi_App_sync_full</filename-prefix> <app-err-operation>stop-on-error</app-err-operation> <filter> <aaa xmlns="urn:huawei:yang:huawei-aaa"/> </filter> </sync-full> </rpc>RPC reply
The RPC reply message carries a full data synchronization identifier assigned by the NETCONF server. This message is returned using the <sync-full-id> parameter.
![]()
After full synchronization is triggered, the RPC reply message sent by the device carries the nc-ext attribute.
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns:nc-sync="urn:huawei:yang:huawei-netconf-sync" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2" nc-ext:flow-id="32"> <nc-sync:sync-full-id>185</nc-sync:sync-full-id> </rpc-reply>
RPC request
<rpc message-id="cancel" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <cancel-synchronization xmlns="urn:huawei:yang:huawei-netconf-sync"> <sync-full-id>185</sync-full-id> </cancel-synchronization> </rpc>RPC reply
Success reply <?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="cancel" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
RPC request
<rpc message-id="upload" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <upload-sync-file xmlns="urn:huawei:yang:huawei-netconf-sync"> <sync-full-id>185</sync-full-id> <result-save-time>1</result-save-time> </upload-sync-file> </rpc>RPC reply
<?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="upload" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
RPC request
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="query_status185"> <get> <filter type="subtree"> <synchronization xmlns="urn:huawei:yang:huawei-netconf-sync"> <file-transfer-statuss> <file-transfer-status> <sync-full-id>185</sync-full-id> <status></status> <progress></progress> <error-message></error-message> </file-transfer-status> </file-transfer-statuss> </synchronization> </filter> </get> </rpc>RPC reply
<?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="query_status12" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> <synchronization xmlns="urn:huawei:yang:huawei-netconf-sync"> <file-transfer-statuss> <file-transfer-status> <sync-full-id>12</sync-full-id> <status>In-Progress</status> <progress>50</progress> </file-transfer-status> </file-transfer-statuss> </synchronization> </data> </rpc-reply>
Incremental Synchronization
The <sync-increment> operation requests a device to synchronize incremental configuration data. When the configuration changes, the client detects the change through the configuration change identifier flow-id. Each time the configuration changes, the value of flow-id increases by 1. If the client needs to obtain the modified configuration, it synchronizes data incrementally.
If the <sync-increment> operation succeeds, the NETCONF server replies with an <rpc-reply> element that contains the <data> element. The <data> element contains the data that was changed between two configuration committing operations. If the operation fails, the server returns an <rpc-reply> element containing an <rpc-error> element.
<sync-increment> uses the difference attribute to identify the change operation of a configuration data instance. The YANG model defines the capability in the huawei-netconf-metadata.yang file.
The following is an example of an incremental data synchronization operation that synchronizes IFM module configurations between change points 6 and 7.
RPC request
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <sync-increment xmlns="urn:huawei:yang:huawei-netconf-sync"> <target> <flow-id>7</flow-id> </target> <source> <flow-id>6</flow-id> </source> <filter type="subtree"> <ifm xmlns="urn:huawei:yang:huawei-ifm"/> </filter> </sync-increment> </rpc>RPC reply
<rpc-reply xmlns:nc-md="urn:huawei:yang:huawei-netconf-metadata"> <data xmlns="urn:huawei:yang:huawei-netconf-sync"> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaceName>Vlanif 1</interfaceName> <ifAm4s> <ifAm4 nc-md:difference="create"> <ipAddress>10.1.1.1</ipAddress> <netMask>255.255.255.0</netMask> <addressType/> </ifAm4> </ifAm4s> </interface> </interfaces> </ifm> </data> </rpc-reply>
Synchronizing MDA
<sync-mda-resource-file> requests the device to synchronize the model driver adapter (MDA) package. When the NMS manages devices, it needs to obtain resource files from the devices. In this case, MDA synchronization can be used.
<sync-mda-resource-file> uses resource-type to specify and obtain one or more types of MDA package resources. The YANG model is defined in huawei-netconf-sync.yang. The following MDA package resources are supported: YANG file, YANG Chinese file, YANG patch file, YANG Chinese patch file, alarm file, alarm patch file, panel file, and panel patch file.
- RPC request
<?xml version="1.0" encoding="UTF-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> <nc-sync:sync-mda-resource-file xmlns:nc-sync="urn:huawei:yang:huawei-netconf-sync"> <nc-sync:resource-type>yang yang-patch yang-zh-cn yang-zh-cn-patch alarm alarm-patch panel panel-patch</nc-sync:resource-type> <nc-sync:transfer-protocol>sftp</nc-sync:transfer-protocol> <nc-sync:user-name>huaweiuser</nc-sync:user-name> <nc-sync:password>YsHsjx_202206</nc-sync:password> <nc-sync:target-addr>10.16.1.2</nc-sync:target-addr> <nc-sync:file-name-prefix>L</nc-sync:file-name-prefix> </nc-sync:sync-mda-resource-file> </rpc> - RPC reply
<?xml version="1.0" encoding="UTF-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1"> <ok/> </rpc-reply>
Active Notification
The Active Notification capability enables a device to periodically send keepalive messages to a client when the device is processing a time-consuming operation. This prevents a timeout when the client does no receive a response from the device. When the device processes time-consuming RPC requests, such as <copy-config> and other operations, the device periodically (at an interval of 20s) sends a netconf-rpc-keepalive notification message to the client to ensure that the connection is active.
The YANG model defines the capability in the huawei-ietf-netconf-ext.yang file.
A client needs to subscribe to keepalive notification to receive keepalive messages when it sends a time-consuming RPC request.
- RPC request
<netconf:rpc netconf:message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <filter netconf:type="subtree"> <nc-ext:netconf-rpc-keepalive xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext"/> </filter> </create-subscription> </netconf:rpc> - Notification reporting
<netconf:rpc netconf:message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <filter netconf:type="subtree"> <nc-ext:netconf-rpc-keepalive xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext"/> </filter> </create-subscription> </netconf:rpc>
Commit-Description
The Commit-Description capability enables a user to specify a description when a device performs a <commit> operation. The description can be used as a mnemonic when rolling back configurations.
The description is carried in the description parameter of the commit operation. The YANG model defines the capability in the huawei-ietf-netconf-ext.yang file.
- RPC request
<?xml version='1.0' encoding='UTF-8'?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <commit> <description xmlns="urn:huawei:yang:huawei-ietf-netconf-ext">Config interfaces</description> </commit> </rpc> - RPC reply
<?xml version='1.0' encoding='UTF-8'?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101" nc-ext:flow-id="31" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>
With-defaults
The <with-defaults> capability indicates that a device can process default values of the model. The <get>, <get-config>, and <copy-config> operations can carry the <with-defaults> parameter.
The available options of the <with-defaults> parameter are as follows:
report-all: queries all nodes and does not perform any operation on the nodes.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <get xmlns:wsss="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults"> <filter type="subtree"> <system xmlns="urn:huawei:yang:huawei-system"/> </filter> <with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">report-all</with-defaults> </get> </rpc>
RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="4"> <data> <system xmlns="urn:huawei:yang:huawei-system"> <systemInfo> <lsRole>admin</lsRole> <authenFlag>false</authenFlag> </systemInfo> </system> </data> </rpc-reply>
trim: trims the nodes whose values equal the default ones from the query results.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3"> <get xmlns:wsss="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults"> <filter type="subtree"> <system xmlns="urn:huawei:yang:huawei-system"/> </filter> <with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">trim</with-defaults> </get> </rpc>
RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3"> <data> <system xmlns="urn:huawei:yang:huawei-system"> <systemInfo> <lsRole>admin</lsRole> </systemInfo> </system> </data> </rpc-reply>
report-all-tagged: queries all nodes and uses namespace:default="true" to identify the nodes whose values equal the default ones.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <get xmlns:wsss="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults"> <filter type="subtree"> <system xmlns="urn:huawei:yang:huawei-system"/> </filter> <with-defaults xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-with-defaults">report-all-tagged</with-defaults> </get> </rpc>
RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0" message-id="2"> <data> <system xmlns="urn:huawei:yang:huawei-system"> <systemInfo> <lsRole>admin</lsRole> <authenFlag wd:default="true">false</authenFlag> </systemInfo> </system> </data> </rpc-reply>
If a node is identified using namespace:default="true", the <edit-config> operation can identify the <default> attribute on the node and determine whether the node value equals to the default one.
The operation attribute of the <edit-config> operation can only be create, merge, or replace. If the operation attribute is set to remove or delete, <rpc-error> is returned.
If the value of the default attribute is true or 1 and the value of the leaf node is the same as the default value defined in the YANG file, the <edit-config> operation returns <ok>. Otherwise, <rpc-error> is returned. It contains the names and values of the leaf nodes whose values are different from the default ones defined in the YANG file.The default value of the leaf node ifDf is true. In this example, the value is false, which is the same as the default value defined in the YANG file. After the <edit-config> operation is performed, <ok> is returned.
RPC request
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0"> <target> <running/> </target> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge"> <ifName>10GE1/0/1</ifName> <ifDf wd:default="true">false</ifDf> </interface> </interfaces> </ifm> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2" nc-ext:flow-id="31" nc-ext:flow-id-time="2022-05-11T10:19:30Z"> <ok/> </rpc-reply>The default value of the leaf node ifDf is true. In this example, the value is true, which is different from the default value (false) defined in the YANG file. After the <edit-config> operation is performed, <rpc-error> is returned. error-para includes the incorrect node name and the actual value.
RPC request
<?xml version="1.0" encoding="utf-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <edit-config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:wd="urn:ietf:params:xml:ns:netconf:default:1.0"> <target> <running/> </target> <config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge"> <ifName>10GE1/0/1</ifName> <ifDf wd:default="true">true</ifDf> </interface> </interfaces> </ifm> </config> </edit-config> </rpc>RPC reply
<?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2"> <rpc-error> <error-type>application</error-type> <error-tag>bad-element</error-tag> <error-severity>error</error-severity> <error-path xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:ifm="urn:huawei:yang:huawei-ifm">/nc:rpc/nc:edit-config/nc:config/ifm:ifm/ifm:interfaces/ifm:interface[ifm:ifName='Ethernet0/1/0']/ifm:ifDf</error-path> <error-message xml:lang="en">ifDf has invalid value true.</error-message> <error-info xmlns:nc-ext="urn:huawei:yang:huawei-ietf-netconf-ext"> <bad-element>ifDf</bad-element> <nc-ext:error-info-code>317</nc-ext:error-info-code> <nc-ext:error-paras> <nc-ext:error-para>ifDf</nc-ext:error-para> <nc-ext:error-para>true</nc-ext:error-para> </nc-ext:error-paras> </error-info> </rpc-error> </rpc-reply>
Configuration Precautions for NETCONF
Licensing Requirements
NETCONF is not under license control.
Hardware Requirements
|
Series |
Models |
|---|---|
S5732-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 |
S6730-H-V2 series |
S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
Feature Requirements
Feature Requirements |
Series |
Models |
|---|---|---|
For NETCONF operations, if no service response is received within 32 seconds, a timeout occurs. If a response is received before the timeout, the device is reset. |
S5732-H-V2 series S6730-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
If a schema patch operation is performed when a user is performing a schema operation, the schema operation will fail. |
S5732-H-V2 series S6730-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
The size of a delivered RPC message cannot be greater than 30 MB. |
S5732-H-V2 series S6730-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
The device can use only SSH as the transport protocol of NETCONF. Before using NETCONF to manage network devices, you must configure SSH. |
S5732-H-V2 series S6730-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
An end-to-end NETCONF operation must be completed within 60 minutes. Otherwise, a timeout occurs. |
S5732-H-V2 series S6730-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
If the NMS client only notifies the base capability in compliance with the standard, the YANG mode is used for interconnection. If the exchange capability is advertised, the Huawei proprietary schema mode is used for interconnection. |
S5732-H-V2 series S6730-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
During schema patch installation, the database may be locked. In this case, operations such as full synchronization and database locking cannot be performed. |
S5732-H-V2 series S6730-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
1. If the capability set contained in the Hello packet sent by the peer contains extended capabilities, the device replies with a schema packet. 2. The exchange capability set is advertised to differentiate large-scale data processing modes. 3. The sync capability set is advertised to determine whether the message returned by edit-config carries a flow ID. |
S5732-H-V2 series S6730-H-V2 series |
S5732-H24S4X6QZ-TV2/S5732-H24S4X6QZ-V2/S5732-H24UM4Y2CZ-TV2/S5732-H24UM4Y2CZ-V2/S5732-H44S4X6QZ-TV2/S5732-H44S4X6QZ-V2/S5732-H48UM4Y2CZ-TV2/S5732-H48UM4Y2CZ-V2 S6730-H24X6C-TV2/S6730-H24X6C-V2/S6730-H28X6CZ-TV2/S6730-H28X6CZ-V2/S6730-H48X6C-TV2/S6730-H48X6C-V2/S6730-H48X6CZ-TV2/S6730-H48X6CZ-V2/S6730-H48Y6C-TV2/S6730-H48Y6C-V2 |
Installing ncclient
ncclient is an open-source Python library for NETCONF clients. It makes writing network-management scripts easier by offering an intuitive API that maps the XML-encoded nature of NETCONF to Python scripts.
ncclient functioning as the NETCONF client can establish a NETCONF session with a device (NETCONF server).
Before performing NETCONF operations, you need to install Python and then ncclient.
Establishing a NETCONF Session
Establishing a NETCONF Session
A device can establish a NETCONF session with both iMaster NCE-Campus and a third-party NMS. A NETCONF session between a device and iMaster NCE-Campus can be established in either ZTP or CLI mode. However, a device can establish a NETCONF session with a third-party NMS only in CLI mode.
In a NETCONF session, the device functions as a NETCONF server, and iMaster NCE-Campus or the third-party NMS functions as a NETCONF client.
Establishing a NETCONF Session in ZTP Mode
ZTP can be deployed using DHCP options or the registration center.
DHCP Option-based deployment: An unconfigured device obtains Option 148 from a DHCP server through ZTP deployment, thereby automatically establishing a NETCONF session with iMaster NCE-Campus. In this scenario, the involved device interface is added to VLAN 1 by default.
- Configure DHCP Option 148 on the DHCP server and add a DHCP server port that has a reachable route to the device to VLAN 1. Option 148 is in the format of agilemanage-domain=ip1&ip2;agilemanage-port=port1&port2 and contains the IP address and port number of iMaster NCE-Campus.
- Upon startup, an unconfigured device sends a request packet to the DHCP server through VLAN 1.
- After receiving the request, the DHCP server returns a DHCP response packet containing Option 148 to the device.
- After detecting that the response packet from the DHCP server carries Option 148, the device enables NETCONF and proactive NETCONF registration, creates an SSH user (huawei), configures the management VLAN 1, and obtains the IP address and port number of iMaster NCE-Campus.
- The device uses the obtained IP address and port number of iMaster NCE-Campus to establish a NETCONF connection with iMaster NCE-Campus.
If a DHCP server and a device are on different network segments, a DHCP relay agent is required to forward DHCP packets.
If a management VLAN has been configured for the switch using iMaster NCE-Campus or a command, the switch uses this management VLAN to send requests to the DHCP server. Therefore, ensure that the switch can communicate with the DHCP server in this management VLAN, so that the switch can go online properly.
If the switch does not register with iMaster NCE-Campus for the first time, the switch preferentially uses the device IP address cached in the memory and the URL/IP address and port number of iMaster NCE-Campus. If you want to change the URL/IP address and port number of iMaster NCE-Campus by modifying Option 148, restart the switch so that the switch can obtain the URL/IP address and port number of iMaster NCE-Campus again.
Establishing a NETCONF Session in CLI Mode
A NETCONF client proactively establishes a NETCONF session with a NETCONF server.
Configure an SSH user on a NETCONF server (device), enable NETCONF, and wait for a NETCONF client to trigger the establishment of a NETCONF session. The NETCONF client uses the SSH username and password configured on the device to establish a NETCONF connection with the device.
A NETCONF server proactively establishes a NETCONF session with a NETCONF client.
If an NMS does not support automatic device discovery, it cannot manage devices as soon as they go online. In this case, the NETCONF server (device) must proactively establish a NETCONF session with the NETCONF client (NMS). To achieve this, you can enable proactive NETCONF registration or configure a management VLAN. Before using either method, you need to configure an SSH user and enable NETCONF on the device.
- Enabling proactive NETCONF registrationFigure 11-5 Establishing a NETCONF session between a device and an NMS by enabling proactive NETCONF registration
![]( "Click to enlarge")
- Configure an SSH user and enable NETCONF and proactive NETCONF registration on a device.
- The device proactively establishes a NETCONF session with the NMS.
- Configuring a management VLAN
A DHCP server is required to establish a NETCONF session between a device and an NMS by configuring a management VLAN. The management VLAN must be planned, with a DHCP server interface that has a reachable route to the device added to the VLAN.
Figure 11-6 Establishing a NETCONF session between a device and an NMS by configuring a management VLAN![]()
- Configure DHCP Option 148 on a DHCP server and add a DHCP server interface that has a reachable route to the device to a management VLAN. Option 148 is in the format of agilemanage-domain=ip1&ip2;agilemanage-port=port1&port2 and contains the IP address and port number of the NMS.
- Configure an SSH user, enable NETCONF, and configure a management VLAN on the device.
- After a management VLAN is configured on the device, the device uses the management VLAN to send a request packet to the DHCP server.
- After receiving the request, the DHCP server returns a DHCP response packet containing Option 148 to the device.
- After receiving the DHCP response packet, the device obtains the IP address and port number of the NMS and uses them to establish a NETCONF session with the NMS.
If a DHCP server and a device are on different network segments, a DHCP relay agent is required to forward DHCP packets.
Configuring an SSH User
Context
- password-rsa: The password authentication and RSA authentication requirements must be met.
- password-dsa: The password authentication and DSA authentication requirements must be met.
- password-ecc: The password authentication and ECC authentication requirements must be met.
- password-x509v3-rsa: The password authentication and X509V3-SSH-RSA authentication requirements must be met.
- all: The requirements of any one of the authentication modes must be met.
The SSH protocol supports SSH1.X (earlier than SSH2.0) and SSH2.0 (recommended). In SSH2.0, the symmetric encryption algorithm using the CBC mode may encounter plaintext-recovery attacks and leak encrypted data. Therefore, the CBC mode is not recommended for data encryption in SSH2.0.
RSA (1024 bits or less) is an insecure encryption algorithm. You are advised to use a secure algorithm.
Procedure
- Enter the system view.
system-view
- Create an SSH user.
ssh user user-name
- Configure an authentication mode for the SSH user.
ssh user user-name authentication-type { password | rsa | password-rsa | all | dsa | password-dsa | ecc | password-ecc | password-x509v3-rsa | x509v3-rsa }
If no SSH user is configured using the ssh user user-name command, run the ssh authentication-type default password command to configure password authentication as the default authentication mode. This facilitates configuration if multiple users need to use password authentication, because you only need to configure AAA users.
- The password authentication mode is implemented based on AAA. When the password, password-rsa, password-x509v3-rsa, password-dsa, or password-ecc authentication mode is used to log in to the device, you need to create a local user in the AAA view with the same name as the SSH user.
- If an SSH user is authenticated using the RSA, DSA, or ECC authentication mode, both the SSH server and client need to generate the local RSA, DSA, or ECC key pair and have each other's public key configured locally.
Configure the authentication mode based on the preceding configuration. For details, see Table 11-13.
Table 11-13 Configuration in different authentication modesAuthentication Mode
Configuration Notes
password
Create an AAA user with the same username as the SSH user. For details, see Table 11-14.
RSA, DSA, or ECC
Configure the device to generate the local RSA, DSA, or ECC key pair. For details, see Table 11-15.
password-rsa, password-dsa, or password-ecc
Create an AAA user with the same username as the SSH user and generate a local RSA, DSA, or ECC key pair. For details, see Table 11-14 and Table 11-15.
x509v3-rsa
Bind the SSH user to the PKI realm. For details, see Table 11-16.
password-x509v3-rsa
Create an AAA user with the same username as the SSH user and bind the AAA user to the PKI realm. For details, see Table 11-14 and Table 11-16.
Table 11-14 Creating a local user with the same name as the SSH user in the AAA viewStep
Command
Description
Enter the system view.
system-view
-
Enter the AAA view.
aaa
-
Configure the local username and password.
local-user user-name password irreversible-cipher password
For security purposes, change the password periodically.
Configure a service type for the local user.
local-user user-name service-type ssh
-
Configure a privilege level for the local user.
local-user user-name privilege level level
-
Return to the system view.
quit
-
Table 11-15 Configuring the local RSA, DSA, or ECC key for the SSH userStep
Command
Description
Enter the system view.
system-view
-
Configure an authentication type for the SSH connection.
ssh authorization-type default { aaa | root }
By default, the authentication type of the SSH connection is AAA.
When the authentication type is AAA, only the password authentication mode can be configured. If the public key authentication mode is used, perform either of the following operations:- Run this command with the authentication type set to root.
- In the AAA view, create a local user with the same name as the SSH user.
Enter the RSA, DSA, or ECC public key view.
rsa peer-public-key key-name [ encoding-type enc-type ]
or
dsa peer-public-key key-name encoding-type enc-type
or
ecc peer-public-key key-name [ encoding-type enc-type ]
or
-
Enter the public key editing view.
public-key-code begin
-
Edit the public key.
hex-data
- The public key must be a hexadecimal character string in the public key encoding format, and generated by SSH client software. For detailed operations, see the help documentation for the SSH client software.
- You need to enter the RSA, DSA, or ECC public key on the device functioning as the SSH server.
Exit the public key editing view.
public-key-code end
- If hex-data is invalid, the key cannot be generated after you run this command.
- If the key specified by key-name has been deleted in another view, the system displays a message indicating that the key does not exist and directly returns to the system view when you run this command.
Return to the system view from the public key view.
peer-public-key end
-
Assign an RSA, DSA, or ECC public key to the SSH user.
ssh user user-name assign { rsa-key | dsa-key | ecc-key } key-name
-
- Configure a service type for the SSH user.
ssh user user-name service-type { snetconf | all }
By default, no service type is configured for an SSH user.
Enabling NETCONF
Context
A NETCONF connection can be established between the client and server using the well-known port 22 only after NETCONF is enabled on the server.
Well-known port 22: Before the SSH server can set up a NETCONF session with the client through this port, the snetconf server enable command must be run on the SSH server.
Well-known port 830: Only the protocol inbound ssh port 830 command needs to be run on the SSH server (running the snetconf server enable command is not required).
Procedure
- Enter the system view.
system-view - Enable NETCONF.
Both the snetconf server enable and protocol inbound ssh port 830 commands can enable NETCONF. If both commands are run, the client can use either port 22 or port 830 to set up a NETCONF connection with the server.
Enable the NETCONF service of the SSH server so that the client can use TCP port 22 to set up a NETCONF connection with the server.
snetconf [ ipv4 | ipv6 ] server enable
Enable the NETCONF service of the SSH server so that the client can use TCP port 830 to set up a NETCONF connection with the server.
netconf protocol inbound ssh [ ipv4 | ipv6 ] port 830 quit
![]()
After the NETCONF service of the SSH server is disabled on TCP port 22 or 830, all clients connecting to port 22 or 830 through NETCONF are disconnected.
- (Optional) Set NETCONF parameters as required. Using default values is recommended.Table 11-17 NETCONF parameters
Operation
Command
Description
Configure the maximum number of NETCONF users that the NETCONF user interface supports.
netconf
max-sessions count
If the maximum number of users that are using NETCONF is reached, subsequent users are prevented from using NETCONF for device operations. This mechanism ensures network management security.
By default, a maximum of 5 NETCONF users are permitted to access the SSH server.
Configure the timeout period for disconnecting from the NETCONF user interface.
netconf
idle-timeout minutes [ seconds ]
If no timeout period is set for an idle NETCONF connection, other authorized users may not obtain idle NETCONF connections. That is, authorized users cannot use NETCONF to manage the device.
The default timeout period is 10 minutes.
Establishing a NETCONF Connection Between a Device and an NMS
Context
You can use either of the following methods to set up a NETCONF connection between a device and an NMS:
- By enabling proactive NETCONF registration: If the NMS does not support automatic device discovery, for example, an iMaster NCE-Campus server is used as the NMS, you can enable proactive NETCONF registration on a device. After the device goes online, it proactively sends a NETCONF connection request to the NMS and establishes a NETCONF connection with the NMS, in this way, you can manage the device through the NMS in a timely manner.
- By configuring a management VLAN: You can configure a management VLAN to enable a device to obtain the NMS IP address from the DHCP server and initiate a request to the NMS for NETCONF connection setup as long as the device interface connected to the DHCP server is added to the corresponding VLAN.
Procedure
- Establishing a NETCONF connection between a device and an NMS by enabling proactive NETCONF registration
- Create a NETCONF connection instance and enter the NETCONF connection instance view.
endpoint endpoint-name
![]()
If both the agile controller management-vlan and endpoint endpoint-name commands are configured on a device, endpoint-name cannot contain a VLANIF and VLAN ID combination, for example, VLANIF10.
- Create a NETCONF connection instance and enter the NETCONF connection instance view.
- Establishing a NETCONF connection between a device and an NMS by configuring a management VLAN
- Configure a VLAN for the device to communicate with the DHCP server.
agile controller management-vlan vlan-id [ ipv6 ]
![]()
If the device has gone online, switching the management VLAN will cause the device to go offline. Perform this operation based on actual conditions.
If both the agile controller management-vlan and endpoint endpoint-name commands are configured on a device, endpoint-name cannot contain a VLANIF and VLAN ID combination, for example, VLANIF10.
- Configure a VLAN for the device to communicate with the DHCP server.
Follow-up Procedure
After proactive NETCONF registration is enabled or a management VLAN is configured during deployment, you can perform the following operations to check the registration status and offline reasons of a device to facilitate deployment.
- Run the display controller connect-status command to check the registration status of the device with the NMS.
- Run the display controller register-fail-record command to check records about device registration failures. This allows you to determine the failure cause as well as date and time when the device failed to register with the NMS.
- Run the display controller offline-record command to check the reason why the device went offline from the NMS.
- Run the reset controller register-fail-record command to clear records about device registration failures. This enables the device to re-collect statistics about registration failures with the NMS.
- Run the reset controller offline-record command to clear records about the reasons why the device went offline from the NMS.
Logging In to the Server Using the NMS
Context
After the preceding configuration is complete, you can log in to the server from the client using the NMS. This allows you to remotely configure devices.
The NMS can manage devices only after it has established a connection and can communicate with them.
Before deploying NEs, divide the network into subnets as required. The physical topology must be easy for routine maintenance in addition to showing the actual network structure.
If the Huawei NMS is used, creating NEs will consume specific upgrade licenses or NE resource licenses. If there are no remaining NE resources or specific upgrade licenses, the system displays a message indicating that it cannot create additional NEs. In this case, apply for NE resources or specific upgrade licenses.
For installation and maintenance of the NMS, see the relevant installation instruction and usage guidelines.
Verifying the Configuration
Procedure
- Run the display ssh user-information [ username ] command on the SSH server to check information about SSH users.
- Run the display ssh server status command on the SSH server to check its global configuration.
- Run the display ssh server session command on the SSH server to check information about sessions between the SSH server and the SSH client (client).
- Run the display netconf capability command to check the capabilities that the server supports.
- Run the display netconf session command to check information about all NETCONF sessions.
- Run the display netconfc session [ peer-id peer-id ] command to check NETCONFC session information.
Example for Configuring a Device to Communicate with ncclient Using NETCONF
Networking Requirements
When the NMS is used to centrally manage devices on a network that requires high security and scalability, you can use NETCONF to ensure communication between the NMS and the devices.
On the network shown in Figure 11-7, the NMS is deployed on client001 that functions as the SSH client. The server functions as the SSH server, which receives connection requests and establishes a connection with the SSH client, implementing configuration file management using NETCONF. SSH is a secure application-layer protocol, thereby enhancing the reliability of NETCONF.
Precautions
An SSH user named client001 is used as an example. If password authentication is used to authenticate the SSH user, the server needs to generate an Elliptic Curves Cryptography (ECC) key.
Configuration Roadmap
The configuration roadmap is as follows:
- Configure an IP address for the server interface connecting to the client so that the Layer 3 route between the client and server is reachable.
- Configure virtual type terminal (VTY) user interfaces on the server to support SSH so that SSH users can be managed and monitored with better connection security.
Deploy SSH on the server to improve NETCONF security.
- Create an SSH user with administrative rights.
- Create an ECC key pair.
- Configure an authentication mode for the SSH user.
- Configure a service type for the SSH user.
- Enable NETCONF so that the client can log in to the server.
- Deploy the NMS on the client to implement NMS-based network management on the client.
Log in to the server using the NMS to manage configuration files remotely.
Procedure
- Configure an IP address for the server interface connecting to the client.
<HUAWEI> system-view [HUAWEI] sysname netconf-agent [netconf-agent] interface 10ge 1/0/1 [netconf-agent-10GE1/0/1] undo portswitch [netconf-agent-10GE1/0/1] ip address 10.1.1.1 24 [netconf-agent-10GE1/0/1] quit
- Configure VTY user interfaces on the server to support SSH.
[netconf-agent] user-interface vty 0 4 [netconf-agent-ui-vty0-4] authentication-mode aaa [netconf-agent-ui-vty0-4] protocol inbound ssh [netconf-agent] quit
![]()
After SSH is configured, the device automatically disables the Telnet function.
- Deploy SSH on the server.
Create an SSH user.
# Create the SSH user client001.
[netconf-agent] ssh user client001 [netconf-agent] aaa [netconf-agent-aaa] local-user client001 password irreversible-cipher ******** [netconf-agent-aaa] local-user client001 service-type ssh [netconf-agent-aaa] local-user client001 privilege level 3 [netconf-agent] quit
Create an ECC key pair.
[netconf-agent] ecc local-key-pair create
The key name will be: Host_ECC % ECC keys defined for Host_ECC already exist. Confirm to replace them? Please select [Y/N]: Y The key modulus can be any one of the following: 256, 384, 521. Key pair generation will take a short while. Please input the modulus [default=521]:521
After the ECC key pair is created, run the display ecc local-key-pair public command to check information about the public key in the ECC key pair.
Configure an authentication mode for the SSH user.
[netconf-agent] ssh user client001 authentication-type password
Configure a service type for the SSH user.
[netconf-agent] ssh user client001 service-type all
- Configure a source interface for the SSH server.
[netconf-agent] ssh server-source all-interface
- Enable NETCONF on the server.
[netconf-agent] snetconf server enable
- Set the NETCONF timeout interval.
[netconf-agent] netconf [netconf-agent-netconf] idle-timeout 0 0 [netconf-agent-netconf] quit
- Deploy the NMS on the client and log in to the server through the NMS.
The following uses ncclient as an example to describe how to establish a NETCONF session. Before establishing a NETCONF session, check that the host (the management network interface on the server) can be pinged to ensure Layer 3 communication between ncclient and the server.
Create an SSH connection with a destination IP address of 10.1.1.1. The connection uses password authentication, with a username of client001 and a password of YsHsjx_202206. When the connect function is invoked, the client connects to the device and automatically establishes a NETCONF session. The following two examples can be used as references. If a message like "No module named XXX" is displayed during script running, run the pip install XXX command to install the required module.
- Example 1: In this example, connection-related parameters are provided during script execution.
- Create a file named huawei-connect-1.py and copy the following content to it.
# -*- coding: utf-8 -*- import sys from ncclient import manager from ncclient import operations def huawei_connect(host, port, user, password): return manager.connect(host=host, port=port, username=user, password=password, hostkey_verify = False, device_params={'name': "huaweiyang"}, allow_agent = False, look_for_keys = False) def test_connect(host, port, user, password): with huawei_connect(host, port=port, user=user, password=password) as m: n = m._session.id print("The session id is %s." % (n)) if __name__ == '__main__': test_connect(sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4])Relevant parameters are as follows:
- host: IP address of the device functioning as a NETCONF server or the device that is accessed through SSH.
- port: number of the port used to establish an SSH connection. The default port number is 22 if you run the snetconf server enable command to enable NETCONF, or 830 if you run the protocol inbound ssh port 830 command to establish a NETCONF connection.
- username: name of the configured SSH user.
- password: password of the SSH user.
- Navigate to the path where the Python file resides and execute the file:
>python huawei-connect-1.py 10.1.1.1 830 client001 YsHsjx_202206
- Create a file named huawei-connect-1.py and copy the following content to it.
- Example 2: In this example, connection-related parameters are provided in a script file.
- Create a file named huawei-connect-2.py and copy the following content to it.
# -*- coding: utf-8 -*- import sys from ncclient import manager from ncclient import operations def huawei_connect(): return manager.connect(host="10.1.1.1", port=830, username="client001", password="YsHsjx_202206", hostkey_verify = False, device_params={'name': "huaweiyang"}, allow_agent = False, look_for_keys = False) def test_connect(): with huawei_connect() as m: n = m._session.id print("The session id is %s." % (n)) if __name__ == '__main__': test_connect() - Navigate to the path where the Python file resides and execute the file:
>python huawei-connect-2.py
- Create a file named huawei-connect-2.py and copy the following content to it.
----End
- Example 1: In this example, connection-related parameters are provided during script execution.
Verifying the Configuration
After the preceding configuration is complete, you can log in to the remote device using NETCONF to manage its configuration files remotely.
Run the following commands on the server (SSH server) to check configuration information:
# Run the display users command to check information about users who have logged in to the server.
[netconf-agent] display users
NOTE: User-Intf: The absolute number and the relative number of user interface Authen: Whether the authentication passes Author: Command line authorization flag -------------------------------------------------------------------------------- User-Intf Delay Type Network Address Authen Author Username -------------------------------------------------------------------------------- 100 NCA 0 00:02:50 SSH 10.2.2.2 pass yes client001
# Run the display ssh user-information command to check SSH user information.
[netconf-agent] display ssh user-information
-------------------------------------------------------------------------------- User Name : client001 Authentication-Type : password User-public-key-name : - User-public-key-type : - Sftp-directory : - Service-type : snetconf -------------------------------------------------------------------------------- Total 1, 1 printed
# Run the display ssh server status command to check global configurations of the SSH server.
[netconf-agent] display ssh server status
SSH Version : 2.0 SSH authentication timeout (Seconds) : 60 SSH authentication retries (Times) : 3 SSH server key generating interval (Hours) : 0 SSH version 1.x compatibility : Enable SSH server keepalive : Disable SFTP IPv4 server : Disable SFTP IPv6 server : Disable STELNET IPv4 server : Disable STELNET IPv6 server : Disable SNETCONF IPv4 server : Enable SNETCONF IPv6 server : Enable SNETCONF IPv4 server port(830) : Disable SNETCONF IPv6 server port(830) : Disable SSH IPv4 server port : 22 SSH IPv6 server port : 22 ACL name : ACL number : ACL6 name : ACL6 number : SSH server ip-block : Enable
# Run the display netconf capability command to check the capabilities that the server supports.
[netconf-agent] display netconf capability
--------------------------------------------------
Capability
--------------------------------------------------
urn:ietf:params:netconf:base:1.0
urn:ietf:params:netconf:base:1.1
urn:ietf:params:netconf:capability:writable-running:1.0
urn:ietf:params:netconf:capability:candidate:1.0
urn:ietf:params:netconf:capability:confirmed-commit:1.0
urn:ietf:params:netconf:capability:confirmed-commit:1.1
urn:ietf:params:netconf:capability:rollback-on-error:1.0
urn:ietf:params:netconf:capability:validate:1.0
urn:ietf:params:netconf:capability:validate:1.1
urn:ietf:params:netconf:capability:startup:1.0
urn:ietf:params:netconf:capability:url:1.0?scheme=file,ftp,sftp
urn:ietf:params:netconf:capability:xpath:1.0
urn:ietf:params:netconf:capability:notification:1.0
urn:ietf:params:netconf:capability:interleave:1.0
urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=report-all&also-supported=report-all-tagged,trim
urn:ietf:params:netconf:capability:yang-library:1.0?revision=2016-06-21&module-set-id=1903662584
http://www.huawei.com/netconf/capability/sync/1.0
http://www.huawei.com/netconf/capability/sync/1.1
http://www.huawei.com/netconf/capability/sync/1.2
http://www.huawei.com/netconf/capability/sync/1.3
http://www.huawei.com/netconf/capability/exchange/1.0
http://www.huawei.com/netconf/capability/exchange/1.2
http://www.huawei.com/netconf/capability/active/1.0
http://www.huawei.com/netconf/capability/action/1.0
http://www.huawei.com/netconf/capability/discard-commit/1.0
http://www.huawei.com/netconf/capability/execute-cli/1.0
http://www.huawei.com/netconf/capability/update/1.0
http://www.huawei.com/netconf/capability/commit-description/1.0
http://www.huawei.com/netconf/capability/sync-config/1.0
http://www.huawei.com/netconf/capability/sync-config/1.1
http://www.huawei.com/netconf/capability/schema/1.0
--------------------------------------------------
Configuration Scripts
Server
#
sysname netconf-agent
#
aaa
local-user client001 password irreversible-cipher $1d$81&FR0T'4Jo#YvBu$#xMPY2{x(9PKGM@fU0&PP^BH(*|7W+b1tAM91X+A$
local-user client001 service-type ssh
local-user client001 privilege level 3
#
interface 10GE1/0/1
undo portswitch
ip address 10.1.1.1 255.255.255.0
#
snetconf server enable
ssh server-source all-interface
ssh user client001
ssh user client001 authentication-type password
ssh user client001 service-type all
#
netconf
idle-timeout 0 0
#
return
Example for Configuring a Device to Communicate with iMaster NCE-Campus Using NETCONF
Networking Requirements
When the NMS is used to centrally manage devices on a network that requires high security and scalability, you can use NETCONF to ensure communication between the NMS and the devices.
In Figure 11-8, a Huawei iMaster NCE-Campus server is used as the NMS. The administrator wants to configure and manage devices on the network through the NMS to improve network configuration and maintenance efficiency.
Configuration Roadmap
Configure NETCONF connections between the NMS and devices so that the NMS can be used to configure and manage the devices. Configure a reachable route between the devices and the NMS based on the actual networking. Device A and Device B function as servers. The following uses DeviceA as an example. The configuration of DeviceB is similar to that of DeviceA, and is not described here.
- Configure an SSH server user.
![]()
The SSH username in the current configuration must be huawei.
- Configure the source interface, PKI certificate, authorization type, and public key algorithm for the SSH server.
- Enable NETCONF.
- Establish a NETCONF connection between the device and the NMS.
- Configure iMaster NCE-Campus.
Procedure
- Configure an SSH server user.
<HUAWEI> system-view [HUAWEI] sysname DeviceA [DeviceA] ssh user huawei [DeviceA] ssh user huawei authentication-type x509v3-rsa [DeviceA] ssh user huawei assign pki default [DeviceA] ssh user huawei service-type snetconf
- Check the public key algorithm of the SSH server.
[DeviceA] display current-configuration | in ssh server publickey
- Configure the source interface, PKI certificate, authorization type, and public key algorithm for the SSH server. Add the x509v3-ssh-rsa algorithm without changing the current public key algorithms configured on the SSH server. In this example, the default public key algorithms RSA_SHA2_256 and RSA_SHA2_512 are used.
[DeviceA] ssh server-source all-interface Warning: SSH server source configuration will take effect in the next login. Do you want to continue? [Y/N]:Y Warning: It expandes the range of accessed IP. [DeviceA] ssh server assign pki default [DeviceA] ssh authorization-type default root [DeviceA] ssh server publickey x509v3-ssh-rsa rsa_sha2_256 rsa_sha2_512
- Enable NETCONF.
[DeviceA] snetconf server enable
- Establish a NETCONF connection between the device and the NMS.
[DeviceA] netconf [DeviceA-netconf] callhome default-callhome [DeviceA-netconf-callhome-default-callhome] endpoint netconf_192.168.30.1 [DeviceA-netconf-callhome-default-callhome-endpoint-netconf_192.168.30.1] peer-ip 192.168.30.1 port 10020 [DeviceA-netconf-callhome-default-callhome-endpoint-netconf_192.168.30.1] return <DeviceA>
![]()
NETCONF is carried over SSH to ensure data transmission security. Before authentication, you need to import the ESN, device type, and CA certificate of each device to iMaster NCE-Campus. To perform certificate-related operations, such as updating the local certificate, run commands on the device. For details, see "PKI Configuration" in the Configuration Guide - Security.
- Load the preset CA certificate from the NVRAM to the default domain.
<DeviceA> system-view [DeviceA] pki import-certificate default_ca realm default Info: Succeeded in importing the certificate.
- Configure iMaster NCE-Campus.
Log in to iMaster NCE-Campus and add a device using the ESN of the device. For details about how to configure iMaster NCE-Campus, see iMaster NCE-Campus Product Documentation.
Verifying the Configuration
Run the display controller connect-status command in the system view to check the status of the controller through which the device goes online. Check the Register phase field to determine whether the device is successfully connected to the NMS. If Registered is displayed, the registration is successful.
<DeviceA>display controller connect-status
Management VLAN : - #Management VLAN
Device sitecode : - #Device site code
Controller IP address : 192.168.30.1 #Controller IP address
Controller port : 10020 #Controller port
Upstream port : 10GE3/0/1 #Upstream port
Register phase : Registered #Register phase
Last registration failure reason : - #Reason for the last registration failure
Configuration Scripts
- DeviceA
# snetconf server enable ssh user huawei ssh user huawei authentication-type x509v3-rsa ssh user huawei assign pki default ssh user huawei service-type snetconf ssh server-source all-interface ssh server assign pki default ssh authorization-type default root # ssh server publickey x509v3-ssh-rsa rsa_sha2_256 rsa_sha2_512 # netconf callhome default-callhome endpoint netconf_192.168.30.1 peer-ip 192.168.30.1 port 10020 # return
- DeviceB
# snetconf server enable ssh user huawei ssh user huawei authentication-type x509v3-rsa ssh user huawei assign pki default ssh user huawei service-type snetconf ssh server-source all-interface ssh server assign pki default ssh authorization-type default root # ssh server publickey x509v3-ssh-rsa rsa_sha2_256 rsa_sha2_512 # netconf callhome default-callhome endpoint netconf_192.168.30.1 peer-ip 192.168.30.1 port 10020 # return
Configuring NETCONF Authorization
Understanding IETF-NACM Authorization
Overview
IETF-NACM provides simple and easy-to-configure database access control rules. It helps flexibly manage specific users' permissions to perform NETCONF operations and access NETCONF resources.
The YANG model defines the capability in the ietf-netconf-acm.yang file.
Protocol operation authorization: authorizes users to perform specific NETCONF operations.
Such operations include <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, and <action>.
Module authorization: authorizes users to access specific feature modules.
Data node authorization: authorizes users to query and modify specific data nodes.
Notification authorization: authorizes a system to report specified alarms or events through the notification mechanism.
- Action authorization: authorizes users to define operations for data nodes through "action" statements.
Emergency session recovery: authorizes users to directly initialize or repair the IETF-NACM authorization configuration without the restriction of access control rules.
Emergency session recovery is a process in which a management-level user or a user in the manage-ug group bypasses the access control rule and initializes or repairs the IETF-NACM authorization configuration.
Management-level users are level-3 users.
By default, IETF-NACM authorization is disabled and the Huawei-NACM authorization process is followed. If IETF-NACM authorization is enabled, the IETF-NACM authorization process is followed.
If IETF-NACM authorization is enabled, this process is followed, and the access permission on get/ietf-yang-library must be enabled during session establishment. Otherwise, session establishment fails due to a lack of permissions.
Data Node Access
The access control permissions of IETF-NACM apply only to NETCONF databases (<candidate/>, <running/>, and <startup/>). The local or remote file or database accessed using the <url> parameter is not controlled by IETF-NACM.
- Create: allows a client to add new data nodes to a database.
- Read: allows a client to read a data node from a database or receive notification events.
- Update: allows a client to update existing data nodes in a database.
- Delete: allows a client to delete a data node from a database.
- Exec: allows a client to perform protocol operations.
Authorization is performed only for the delivered operations (it is not performed for all the changed nodes in the model tree). For example, when a delete operation is performed for a parent node, this operation automatically applies to its child nodes without authorization. In this case, the data of both the parent node and its child nodes is deleted.
Components of IETF-NACM
Table 11-18 describes the components and functions of IETF-NACM.
Name |
Description |
|---|---|
User |
User defined in the NACM view. The user must be an SSH user. IETF-NACM authorizes only users. User authentication is implemented in AAA. |
Group |
Group defined in the NACM view. This group instead of a user performs protocol operations in a NETCONF session. The group identifier is a group name, which is unique on the NETCONF server. A user can be a member of multiple groups. |
Global execution control |
Execution control can be:
|
Access control rule |
There are five access control rules:
|
Implementation
After a NETCONF session is established and a user passes the authentication, the NETCONF server controls access permissions based on the username, group name, and NACM authorization rule list. Authorization rules are associated with users through the user group. The administrator of a user group can manage the permissions of users in the group.
- An IETF-NACM user is associated with an IETF-NACM user group. After users are added to a user group, they have the same permissions.
- An IETF-NACM user group is associated with an IETF-NACM authorization rule list.
An IETF-NACM authorization rule list is associated with IETF-NACM authorization rules.
Various authorization rules can be added to an IETF-NACM authorization rule list in the format of combinations. Users associated with the list can use the rules it contains.
IETF-NACM Authorization Process
Figure 11-9 shows the IETF-NACM authorization process.
When a user group and an authorization rule list are traversed, if the username that is the same as that carried in the request is not found or no rule that matches the requested operation is detected, the operation performed varies with the authorized content. For details, see Table 11-19.
Authorized Content |
Operation |
|---|---|
Protocol operation |
|
Data node |
|
Notification |
|
Action |
|
Configuring IETF-NACM Authorization
Context
NACM authorization is an IETF-defined, more flexible authorization mode. NACM authorization rules allow you to define NACM authorization rules to control specific users' permissions to perform NETCONF operations and access NETCONF resources.
Procedure
- Enter the system view.
system-view - Enter the NETCONF user interface view.
netconf - Enter the NACM view.
nacm - Enable the NACM function.
nacm enable - (Optional) Configure the operation permissions of a user as required.Table 11-20 A user's operation permissions
Operation
Command
Description
Configure the user's permission on query operations.
read-default permit
By default, the user's permission on query operations is disabled.
Configure the user's permission on configuration operations.
write-default permit
By default, a user's permission on configuration operations is disabled.
Configure the user's default execution permission on RPC operations.
execute-default permit
By default, the user's permission on RPC operations is enabled.
- Create an NACM user group and enter the NACM user group view.
group-name group-name
- Create a user in the NACM user group.
user-name user-name
- Exit the NACM user group view.
quit - Create a NACM authorization rule list and enter the NACM authorization rule list view.
rule-list-name list-name
- Associate the NACM user group with the NACM authentication rule list.
group group-name
- Configure an NACM authorization rule name in the NACM authorization rule list view.
rule-name rule-name action { permit | deny }
- (Optional) Configure a description for the NACM authorization rule list.
description description
- Configure the name of a feature module allowed for access.
module-name module-name
By default, the feature module name is an asterisk (*), indicating all features.
- Configure an NACM authorization rule type.
rule-type { rpc-name rpc-name | notification-name notification-name | path path }
- Configure protocol operations.
access-operation { { create | read | update | delete | exec } * | * }
Examples for Basic NETCONF Operations
This section provides examples for using ncclient to compile a Python script, connect to a device, establish a NETCONF session, and perform basic operations such as configuration management, status query, and event notification. The typical procedure is as follows:
- Create a .py file (Python script) and import the dependent library.
- Invoke the connect function to create a NETCONF session through SSH.
- Construct different RPC messages.
- Execute the Python script.
For details about how to establish a NETCONF session and execute the Python script, see Establishing a NETCONF Session.
The following sections describe how to construct messages for different RPC operations.
Modifying and Committing the Configuration
Basic Operations
- Construct the data to be configured, for example, the interface MTU. The corresponding XPath is /ifm/interfaces/interface.
CREATE_INTERFACE = '''<config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name>10GE1/0/1</name> <mtu>1500</mtu> </interface> </interfaces> </ifm> </config>''' - Set the validation mode.
- Immediate validation mode: The configuration takes effect immediately after messages are sent.Deliver an <edit-config> message to modify the <running/> configuration database on the server and verify the returned message.
rpc_obj = m.edit_config(target='running', config=CREATE_INTERFACE) _check_response(rpc_obj, 'CREATE_INTERFACE')
- Immediate validation mode: The configuration takes effect immediately after messages are sent.
Example
This example shows how to configure a simple Python script to connect to the device and implement configuration.
Deliver the script configuration. In the command, test_edit_config_running.py is the script name, 172.16.0.3 is the server address, client001 is the username, and YsHsjx_202206 is the password.
$ test_edit_config_running.py 172.16.0.3 22 client001 YsHsjx_202206 RPCReply for CREATE_INTERFACE is <?xml version="1.0" encoding="UTF-8"?> <rpc-reply message-id="urn:uuid:ad4c7284-49f7-4aef-9d7d-70331de46303" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> CREATE_INTERFACE successful
# test_edit_config_running.py
import sys
import logging
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
CREATE_INTERFACE = '''<config>
<ifm xmlns="urn:huawei:yang:huawei-ifm">
<interfaces>
<interface>
<name>10GE1/0/1</name>
<mtu>1500</mtu>
</interface>
</interfaces>
</ifm>qiant
</config>'''
#Fill the device information and establish a NETCONF session
def huawei_connect(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name': "huaweiyang"},
allow_agent = False,
look_for_keys = False)
def _check_response(rpc_obj, snippet_name):
print("RPCReply for %s is %s" % (snippet_name, rpc_obj.xml))
xml_str = rpc_obj.xml
if "<ok/>" in xml_str:
print("%s successful" % snippet_name)
else:
print("Cannot successfully execute: %s" % snippet_name)
def test_edit_config_running(host, port, user, password):
#1.Create a NETCONF session
with huawei_connect(host, port=port, user=user, password=password) as m:
#2.Send RPC and check RPC reply
rpc_obj = m.edit_config(target='candidate', config=CREATE_INTERFACE)
_check_response(rpc_obj, 'CREATE_INTERFACE')
if __name__ == '__main__':
test_edit_config_running(sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4])
Displaying Configuration or Status Data
Basic Operations
- Construct a filtering condition, for example, ifName, and then query details about all interfaces. The corresponding XPath is /ifm/interfaces/interface.
If you do not need to filter query results, skip this step.
FILTER = '''<ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name/> </interface> </interfaces> </ifm>''' - Construct a <get> or <get-config> packet and query current running data.
- Construct a <get> packet.
get_reply = m.get([FILTER])
- Construct a <get-config> packet.
get_reply = get_config(source='running', filter=[FILTER], with_defaults="trim")
In the preceding example, "m" indicates the following:
with huawei_connect(host, port=port, user=user, password=password) as m:
- Construct a <get> packet.
Example
This example shows how to configure a simple Python script to connect to the device and implement query.
# test_get.py
import sys
import logging
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
FILTER = '''<ifm xmlns="urn:huawei:yang:huawei-ifm">
<interfaces>
<interface>
<name/>
<mtu/>
</interface>
</interfaces>
</ifm>'''
# Fill the device information and establish a NETCONF session
def huawei_connect(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name': "huaweiyang"},
allow_agent = False,
look_for_keys = False)
def test_get(host, port, user, password):
#1.Create a NETCONF session
with huawei_connect(host, port=port, user=user, password=password) as m:
n = m._session.id
print("The session id is %s." % (n))
#2.Send get RPC and print RPC reply
get_reply = m.get([FILTER])
print(get_reply)
if __name__ == '__main__':
test_get(sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4])
Maintenance
Basic Operations
- Construct an RPC action message based on the corresponding data model. In this example, action is set to save configuration. The corresponding XPath is /save/filename.
ACTION = '''<rpc message-id="{}" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <save xmlns="urn:huawei:yang:huawei-cfg"> <filename>test.cfg</filename> </save> </rpc>''' - Deliver the action message.
# Set the message-id for the rpc msgId = 1001
rpc = ACTION.format(msgId) # Send RPC m._session.send(rpc)
Example
This example shows how to configure a simple Python program to connect to the device and implement maintenance.
# test_action.py
import sys
import logging
import time
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
ACTION = '''<rpc message-id="{}" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<save xmlns="urn:huawei:yang:huawei-cfg">
<filename>test.cfg</filename>
</save>
</rpc>'''
def test_action(host, port, user, password):
#Fill the device information and establish a NETCONF session
with manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name': "huaweiyang"},
allow_agent = False,
look_for_keys = False) as m:
#Set the message-id for the rpc
msgId = 1001
rpc = ACTION.format(msgId)
#Send RPC
m._session.send(rpc)
time.sleep(2)
if __name__ == '__main__':
logging.basicConfig(level=logging.DEBUG)
test_action(sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4])
Subscription Event Notification
Basic Operations
- Construct a notification subscription message.
CREATE_SUBSCRIPTION = '''<?xml version="1.0" encoding="UTF-8"?> <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="{}"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <stream>NETCONF</stream> </create-subscription> </rpc>'''
- Deliver the notification subscription message.
#Set the message-id for the rpc msgId = 1001 rpc = CREATE_SUBSCRIPTION.format(msgId) #create subscription m._session.send(rpc)
- Wait for notification alarm reporting.
m.take_notification(block=True, timeout=None)
Example
This example shows how to configure a simple Python script to connect to the device and implement event notification.
# test_notification.py
import sys
import logging
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
CREATE_SUBSCRIPTION = '''<?xml version="1.0" encoding="UTF-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="{}">
<create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<stream>NETCONF</stream>
</create-subscription>
</rpc>'''
#Fill the device information and establish a NETCONF session
def huawei_connect(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name': "huaweiyang"},
allow_agent = False,
look_for_keys = False)
def test_notification(host, port, user, password):
#1.Create a NETCONF session
with huawei_connect(host, port=port, user=user, password=password) as m:
#2.Set the message-id for the rpc
msgId = 1001
rpc = CREATE_SUBSCRIPTION.format(msgId)
#3.Send rpc
result = m._session.send(rpc)
#4.Attempt to retrieve one notification
m.take_notification(block=True, timeout=None)
print("The notification message is %s." % (ntf))
if __name__ == '__main__':
logging.basicConfig(level=logging.DEBUG)
test_notification(sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4])
Configuration Export
Basic Operations
Construct a copy-config message and deliver it.
m.copy_config(source="running", target="file:///output.xml")
Example
This example shows how to configure a simple Python script to connect to the device and export the configuration.
# test_export_config.py
import sys
from ncclient import manager
#Fill the device information and establish a NETCONF session
def huawei_connect(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name': "huaweiyang"},
allow_agent = False,
look_for_keys = False)
def test_export_config(host, port, user, password):
with huawei_connect(host, port=port, user=user, password=password) as m:
with m.locked("running"):
m.copy_config(source="running", target="file:///output.xml")
if __name__ == '__main__':
test_export_config(sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4])
Configuration Validation
Basic Operations
- Construct the data to be configured, for example, the interface MTU. The corresponding XPath is /ifm/interfaces/interface.
CREATE_INTERFACE = '''<config> <ifm xmlns="urn:huawei:yang:huawei-ifm"> <interfaces> <interface> <name></name> <mtu>1300</mtu> </interface> </interfaces> </ifm> </config>''' - Deliver an <edit-config> message in which the value of <test-option> is set.
rpc_obj = m.edit_config(target='candidate', config=CREATE_INTERFACE, test_option='set') _check_response(rpc_obj, 'CREATE_INTERFACE')
- Deliver a validate message.
m.validate(source="candidate")
In the preceding example, "m" indicates the following:with huawei_connect(host, port=port, user=user, password=password) as m:
Example
# test_validate.py
import sys
import logging
from ncclient import manager
from ncclient import operations
log = logging.getLogger(__name__)
CREATE_INTERFACE = '''<config>
<ifm xmlns="urn:huawei:yang:huawei-ifm">
<interfaces>
<interface>
<name>10GE1/0/1</name>
<mtu>1300</mtu>
</interface>
</interfaces>
</ifm>
</config>'''
#Fill the device information and establish a NETCONF session
def huawei_connect(host, port, user, password):
return manager.connect(host=host,
port=port,
username=user,
password=password,
hostkey_verify = False,
device_params={'name': "huaweiyang"},
allow_agent = False,
look_for_keys = False)
def _check_response(rpc_obj, snippet_name):
print("RPCReply for %s is %s" % (snippet_name, rpc_obj.xml))
xml_str = rpc_obj.xml
if "<ok/>" in xml_str:
print("%s successful" % snippet_name)
else:
print("Cannot successfully execute: %s" % snippet_name)
def test_validate(host, port, user, password):
#1.Create a NETCONF session
with huawei_connect(host, port=port, user=user, password=password) as m:
#2.Send RPC and check RPC reply
rpc_obj = m.edit_config(target='candidate', config=CREATE_INTERFACE, test_option='set')
_check_response(rpc_obj, 'CREATE_INTERFACE')
#validate check
m.validate(source="candidate")
m.commit()
if __name__ == '__main__':
test_validate(sys.argv[1], sys.argv[2], sys.argv[3], sys.argv[4])
- NETCONF Overview
- Understanding NETCONF
- NETCONF Operation Capabilities
- Configuration Precautions for NETCONF
- Installing ncclient
- Establishing a NETCONF Session
- Establishing a NETCONF Session
- Configuring an SSH User
- Enabling NETCONF
- Establishing a NETCONF Connection Between a Device and an NMS
- Logging In to the Server Using the NMS
- Verifying the Configuration
- Example for Configuring a Device to Communicate with ncclient Using NETCONF
- Example for Configuring a Device to Communicate with iMaster NCE-Campus Using NETCONF
- Configuring NETCONF Authorization
- Maintaining NETCONF
- Examples for Basic NETCONF Operations