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

Reminder

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

upgrade

Configuration Guide - Network Management and Monitoring

CloudEngine 8800, 7800, 6800, and 5800 V200R005C10

This document describes the configurations of Network Management and Monitoring, including SNMP, RMON, NETCONF, OpenFlow, LLDP, NQA, Mirroring, Packet Capture, Packet Trace, Path and Connectivity Detection Configuration, NetStream, sFlow, and iPCA.
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).
Basic Concepts of NETCONF

Basic Concepts of NETCONF

NETCONF Network Architecture

Figure 3-1 shows a typical NETCONF network topology which contains at least one NMS used for device management. The NETCONF network architecture consists of the following components:

  • NETCONF client

    A client uses NETCONF to manage network devices.
    • The client sends <rpc> elements to a NETCONF server to query or modify configuration data.
    • The client learns the status of a managed device based on the alarms and events reported by the NETCONF server of the managed device.
  • NETCONF server

    A server maintains the configuration data of managed devices, responds to the <rpc> elements sent by clients, and sends the requested management data to the clients.

    • After receiving a request from a client, the server parses the request, processes the request based on the configuration management framework (CMF), and then returns a response to the client.
    • If an alarm is generated or an event occurs on a managed device, the NETCONF server of the managed device reports the alarm or event to a NETCONF client for the client to learn the status of the managed device.
Figure 3-1 NETCONF network architecture

A NETCONF session is a logical connection between a client and a server. A network device must support at least one NETCONF session. The data that a NETCONF client obtains from a NETCONF server includes configuration data and status data.

  • The NETCONF client can modify configuration data and operate the configuration data so that the status of the NETCONF server migrates to a user-expected status.
  • The NETCONF client cannot modify status data. Status data includes the running status of the NETCONF server and other statistics.

NETCONF Modeling Language

  • Schema

    Schema is a set of rules defined for describing XML documents. A schema file defines all managed objects of the device, and the hierarchy, read and write attributes, and constraints of the managed objects.

    A schema file functions in a way similar to a Simple Network Management Protocol (SNMP) management information base (MIB) file.

  • YANG

    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.

Related Concepts

The NETCONF client and server communicate through the RPC mechanism. To implement the communication, a secure and connection-oriented session must be established. The client sends an RPC request to the server. After processing the request, the server sends a response to the client. The RPC request of the client and the response message of the server are encoded in XML format.

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.

  • XML encoding

    XML, the encoding format used by NETCONF, uses a text file to represent complex hierarchical data. NETCONF allows a user to use a traditional text compilation tool or XML-specific compilation tool to read, save, and operate configuration data.

    XML-based network management uses XML to describe managed data and management operations so that management information becomes a database comprehensible to computers. XML-based network management helps computers efficiently process network management data, improving network management capabilities.

    The XML encoding format file header is <?xml version= "1.0" encoding= "UTF-8" ?>, where:
    • <?: is the start of an instruction.
    • xml: identifies an XML file.
    • Version: indicates the NETCONF version. "1.0" indicates that the XML1.0 standard version is used.
    • encoding: is the character set encoding format. Only UTF-8 encoding is supported.
    • ?>: is the end of an instruction.
  • RPC mode

    NETCONF uses the RPC mechanism and XML-encoded <rpc> and <rpc-reply> elements to provide a framework of request and response messages independent of transport layer protocols. Table 3-3 lists some basic RPC elements.

    Table 3-3 Element description

    Element

    Description

    <rpc>

    Encapsulates a request that the client sends to the server.

    <rpc-reply>

    Encapsulates a response message for an <rpc> request message. The server returns a response message, which is encapsulated in the <rpc-reply>element, for each <rpc> request message.

    <rpc-error>

    Notifies a client of an error that occurs during <rpc> request processing. 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 <rpc> request processing. The server encapsulates the <ok> element in the <rpc-reply> element and sends the <rpc-reply> element to the client.

  • Capability set

    A capability set includes basic and extended functions implemented based on NETCONF. A device can add protocol operations through the capability set to extend the operation scope of existing configuration objects.

    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 capability set defined by NETCONF, a vendor can define additional capability sets to extend management functions. For a module that supports the YANG model, the module needs to be added to the <hello> element. The message format is as follows:

    <capability>http://www.huawei.com/netconf/vrp/huawei-ifm?module=huawei-ifm&amp;revision=2013-01-01</capability>
  • Configuration database

    A configuration database is a collection of complete configuration parameters for a device. Table 3-4 describes NETCONF-defined configuration databases.

    Table 3-4 NETCONF-defined configuration databases

    Configuration database

    Description

    <running/>

    Stores the effective configuration, status information, and statistics on the current device.

    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, the device must have the writable-running capability.

    <candidate/>

    Stores the configuration data to be run by the device.

    An administrator can perform operations on the <candidate/> configuration database. Any change to the <candidate/> database does not directly affect the current device.

    To support the <candidate/> configuration database, the current device must have the candidate capability.

    NOTE:

    The <candidate/> configuration databases supported by Huawei 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 for device startup, which is similar to the saved configuration file.

    To support the <startup/> configuration database, the current device must have the Distinct Startup capability.

Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100075365

Views: 33952

Downloads: 123

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