No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


Configuration Guide - Network Management and Monitoring

S2720, S5700, and S6720 V200R013C00

This document describes the configurations of Network Management and Monitoring, including SNMP, RMON, RMON2, LLDP, Performance Management, iPCA, NQA, Service Diagnosis, Mirroring, Packet Capture, NetStream, sFlow, TWAMP Light, NETCONF, ECA, Intelligent Video O&M, eMDI, and Network Deception.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
NETCONF Working Mechanism

NETCONF Working Mechanism


The switch supports the following NETCONF modes:
  • NETCONF over SSH: The NMS actively sets up a NETCONF session with the switch.
  • NETCONF over SSH Callhome: The switch actively sets up a NETCONF session with the NMS.

NETCONF System Model

The NETCONF system uses the Client/Server model, as shown in Figure 13-1. The network management system (NETCONF client) uses the NETCONF protocol to configure and manage the network device (NETCONF server).

Figure 13-1  NETCONF system model

NETCONF Protocol Architecture

Similar to the OSI model, NETCONF includes four layers, as shown in Table 13-2.

Table 13-2  NETCONF protocol architecture





Configuration data, status data, statistics, notifications, etc

The Content layer contains a set of managed objects, such as configuration data, status data, statistics, and notifications. For the content that can be read, written, and reported to the NMS, see NETCONF YANG API Reference.


Database, capability, and operation

The Operations layer defines the database, capabilities, and operations supported by NETCONF. For details, see Databases Supported by NETCONF and Capabilities and Operations Supported by NETCONF


<rpc>, <rpc-reply>, <notification>

The Messages layer provides a simple RPC request and response mechanism independent of transport protocols, and a notification mechanism used by the network devices to actively report traps and events to the NMS.
  • The NMS uses the <rpc> element to encapsulate RPC request information and sends the RPC request information to a network device. The network device uses the <rpc-reply> element to encapsulate RPC response information and sends the RPC response information to the NMS. Normally, the <rpc-reply> element encapsulates request data or a configuration success message. If the NMS sends an incorrect request or the network device fails to process a request from the NMS, the <rpc-reply> element returned to the NMS contains a <rpc-error> element.
  • The network device uses the <notification> element to report traps and events to the NMS.

Secure Transport

SSH, SOAP, etc

The Secure Transport layer provides a communication path for interaction between the NMS and network devices.

NETCONF can be layered over any transport protocol that meets the following basic requirements:
  • Connection-oriented: NETCONF is connection-oriented, requiring a persistent connection between peers. This connection MUST provide reliable, sequenced data delivery.
  • Reliable: NETCONF connections must provide authentication, data integrity, confidentiality, and replay protection.

The switch supports only the SSH protocol as transport protocol.

Updated: 2019-04-20

Document ID: EDOC1100065680

Views: 53225

Downloads: 504

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Previous Next