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).
Basic Concepts

Basic Concepts

YANG is a modeling language in the Network Configuration Protocol (NETCONF). YANG defines a hierarchical data structure, which is used for NETCONF-based operations, including configuration, state data, Remote Procedure Calls (RPCs), and notifications. This allows a complete description of all data exchanged between a NETCONF client and server.

YANG Model File

A YANG model file contains the following information:
  • Module definition

    Modules and submodules: YANG structures data models into modules and submodules. A module can import data from other modules and reference data from submodules. The hierarchy can be augmented, allowing one module to add data nodes to the hierarchy defined in another module. This augmentation is conditional, with new nodes presented only if certain conditions are met.

    "import" and "include" statements for modules and submodules: The "include" statement allows a module or submodule to reference materials in submodules, and the "import" statement allows references to materials defined in other modules.

  • Namespace of a module

    The namespace of a module must be globally unique.

  • Version of a module

    The "revision" statement records the version change history of a module. Any updated revision information must be associated with the corresponding file name.

  • Module description and introduction

    The "organization" and "contact" statements provide organization and contact information about the module, so that the source of the module can be determined.

    The "description" statement describes basic module information.

Example of a YANG model file

Contents of "acme-system.yang"
module acme-system {
 namespace "http://acme.example.com/system";
 prefix "acme";
 organization "ACME Inc.";
 contact "joe@acme.example.com";
 description
 "The module for entities implementing the ACME system.";
 revision 2007-06-09 {
  description "Initial revision.";
 }
 container system {
  leaf host-name {
   type string;
   description "Hostname for this system";
  }
  leaf-list domain-search {
   type string;
   description "List of domain names to search";
  }
  container login {
   leaf message {
    type string;
    description
    "Message given at start of login session";
   }
   list user {
    key "name";
    leaf name {
     type string;
    }
   }
  }
 }
}

Operation Definition

You can define operations in the YANG model through RPCs or the "action" statement. The definitions include operation names, input parameters, and output parameters.

  • Defining an operation through an RPC

    YANG provides the RPC keyword, and an operation at the top layer of the model can be defined.

    The following example shows an operation defined using an RPC. The operation name is activate-software-image. The input parameter is image-name, which is specified as a character string, and the output parameter is status, which is also specified as a character string.

    rpc activate-software-image {
     input {
      leaf image-name {
       type string;
      }
     }
     output {
      leaf status {
       type string;
      }
     }
    }

    The corresponding NETCONF XML example is as follows.

    <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <activate-software-image xmlns="http://acme.example.com/system">
      <image-name>acmefw-2.3</image-name>
     </activate-software-image>
    </rpc>
    
    <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <status xmlns="http://acme.example.com/system">
      The image acmefw-2.3 is being installed.
     </status>
    </rpc-reply>
  • Defining an operation through the "action" statement

    Action is syntax of YANG. It can be associated with the container and list nodes to define operations such as <reset>, <reboot>, and <copy> for leaf nodes. Action includes the input and output statements.

    One leaf node can have multiple operations defined, but only one operation is delivered each time.

    In the following example, a list node named server is associated with the "action" statement, which defines a reset operation for a leaf node named reset-at.

    module example-server-farm {
      yang-version 1.1;
      namespace "urn:example:server-farm";
      prefix "sfarm";
      import ietf-yang-types {
       prefix "yang";
      }
      list server {
       key name;
       leaf name {
        type string;
       }
       action reset {
        input {
         leaf reset-at {
          type yang:date-and-time;
          mandatory true;
         }
        }
        output {
         leaf reset-finished-at {
          type yang:date-and-time;
          mandatory true;
         }
        }
       } 
      }  
    }

    The corresponding NETCONF XML description is as follows: The reset operation is performed for the server named apache-1 at the user-specified time "2014-07-29T13:42:00Z", and a reply packet indicating the execution end time is returned.

    • RPC request
      <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <action xmlns="urn:ietf:params:xml:ns:yang:1">
        <server xmlns="urn:example:server-farm">
         <name>apache-1</name>
         <reset>
          <reset-at>2014-07-29T13:42:00Z</reset-at>
         </reset>
        </server>
       </action>
      </rpc>
    • RPC reply
      <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <reset-finished-at xmlns="urn:example:server-farm">
        2014-07-29T13:42:12Z
       </reset-finished-at>
      </rpc-reply>

Notification Definition

NETCONF notification is a NETCONF-based mechanism for alarm and event subscription and reporting, providing a data-model-based asynchronous reporting service. YANG allows the definition of notifications suitable for NETCONF. YANG data definition statements are used to model the notification content.

NETCONF is different from the single-transmission and single-receiving mechanisms of RPC packets, which a client uses to query data. NETCONF notifications allow a server to proactively send notification packets to a client in case of an alarm or an event. NETCONF notification applies to scenarios where real-time detection of devices is required, such as, alarms and events reported to an NMS through NETCONF.

The following example shows a defined notification. The name is link-failure. If any of the if-name, if-admin-status, and if-oper-status parameter values changes, the change is reported to a client.

notification link-failure {
 description "A link failure has been detected";
 leaf if-name {
  type leafref {
   path "/interface/name";
  }
 }
 leaf if-admin-status {
  type admin-status;
 }
 leaf if-oper-status {
  type oper-status;
 }
}

The corresponding NETCONF XML example is as follows.

<notification xmlns="urn:ietf:params:netconf:capability:notification:1.0">
 <eventTime>2007-09-01T10:00:00Z</eventTime>
 <link-failure xmlns="http://acme.example.com/system">
 <if-name>so-1/2/3.0</if-name>
 <if-admin-status>up</if-admin-status>
 <if-oper-status>down</if-oper-status>
 </link-failure>
</notification>
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100075344

Views: 19572

Downloads: 22

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