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 12800 and 12800E V200R005C10

This document describes the configurations of Network Management and Monitoring, including SNMP, RMON, LLDP, NQA, Service Diagnosis, Mirroring, Packet Capture, sFlow, and NETCONF.
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 Message Formats

NETCONF Message Formats

This section describes NETCONF message structures.

Figure 3-2 Structure of a NETCONF YANG message
Figure 3-3 Structure of a NETCONF schema message
A NETCONF message consists of the following three parts:
  • Message: The message layer provides a simple and independent transmission frame mechanism for RPC messages. The client encapsulates an RPC request into an <rpc> element. The server encapsulates the request processing result in the <rpc-replay> element and responds to the client.
  • Operations: The operations layer defines a set of basic NETCONF operations, and the 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 schema and YANG models.
NOTE:

YANG messages contain the modules that support the YANG model, such as huawei-isiscomm shown in Figure 3-2. Schema messages carry version information, such as the content in the blue dashed box shown in Figure 3-3.

The message's fields are as follows:
  • 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 when the <rpc-reply> message is generated.
  • "urn:ietf:params:xml:ns:netconf:base:1.0": Indicates the namespace of the NETCONF XML. "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: base1.1 is an upgrade of base:1.0, with the following items being changed.
      • The remove operation is added to the operation attribute of <edit-config>.
      • The well-known error-tagmalformed-message is added, and the well-known error-tagpartial-operation is obsolete.
      • The namespace wildcarding mechanism is added for subtree filtering.
      • The chunked framing mechanism is added to resolve the security issues in the end-of-message (EOM) mechanism.

      If you want to perform an operation in base1.1, the client must support base1.1 so that this capability can be advertised during capabilities exchange.

  • <edit-config>: Indicates the operation type.
  • <target>: Indicates the target file to be operated on.
  • <default-operation>: Indicates the default operation type.
  • <error-option>: Indicates the mode for processing subsequent operations if an error occurs when <edit-config> is set. The options are as follows:
    • stop-on-error: Stops the operation when an error occurs.
    • continue-on-error: Records the error information and continues the execution when an error occurs. The NETCONF server returns to the client an <rpc-reply> message indicating an operation failure if an error occurs.
    • rollback-on-error: Stops the operation when an error occurs and rolls back the configuration to the state before the <edit-config> operation is performed. This operation is only supported when the device supports the rollback-on-error capability.
  • <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:

    The XML messages sent by a client to a server must be concluded with the end character ]]>]]>. Otherwise, the server fails to identify the XML messages and does not respond to them. By default, the end character is automatically added to XML messages sent by a device. In the following example, the end character is not added, which facilitates XML format identification. In practice, the end character must be added.

    If the capability set in the <hello> elements contains base1.1, the RPC messages in YANG model support the chunk format. Messages in chunk format can be fragmented. The end character is \n##\n.

Response messages:
  • For a successful response, an <rpc-reply> message carrying the <ok> element is returned.
    <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
      <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="3">
      <rpc-error>
       <error-type>application</error-type>
       <error-tag>bad-element</error-tag>
       <error-severity>error</error-severity>
       <error-app-tag>43</error-app-tag>
       <error-path xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
    	  xmlns:acl="http://www.huawei.com/netconf/vrp/huawei-acl">/nc:rpc/nc:edit-config/nc:config/acl:acl/acl:aclGroups/acl:aclGroup[acl:aclNumOrName="2999"]/acl:aclRuleBas4s/acl:aclRuleBas4[acl:aclRuleName="rule_-2"]/acl:vrfAny</error-path>
       <error-message xml:lang="en">vrfAny has invalid value a.</error-message>
       <error-info>
        <bad-element>vrfAny</bad-element>
      </error-info>
     </rpc-error>
    </rpc-reply>
    The message's fields are as follows:
    • <error-type>: Defines the protocol layer of an error. The layer can be the transport, RPC, protocol, or application layer.
    • <error-tag>: Indicates the content of an error.
    • <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 does not appear if the correct <error-tag> is not associated with the error type.
    • <error-path>: Indicates the location where an error occurs and the file name.
    • <error-message>: Indicates the description of an error.
    • <error-info>: Contains the error content specific to a protocol or data model. This element does not appear if the correct <error info> is not provided.
    • <error-paras>: Indicates the list of error parameters.
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100075344

Views: 20829

Downloads: 22

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