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

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
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).
Principles

Principles

Basic Concepts

NETCONF Components

NETCONF provides a standard framework and a set of standard Remote Procedure Call (RPC) methods, through which network administrators and application developers can manage configurations of network devices. The device configuration data and the NETCONF protocol are encoded with the Extensible Markup Language (XML).

NETCONF uses a client/server architecture, as shown in Figure 14-17.

Figure 14-17 NETCONF client/server architecture

The NETCONF architecture involves two roles: NETCONF manager and NETCONF agent.

  • NETCONF manager: functions as a client on the network. It runs on NMS/EMS and interacts with the NETCONF agent to manage devices. The network administrator uses the NETCONF manager (NMS/EMS) to send <rpc> requests encoded in XML format to the NETCONF agent.
  • NETCONF Agent: functions as a server on the network. To manage device configurations, the NETCONF manager sends a request to the NETCONF agent. The NETCONF agent decodes the request and manages the configuration of the device with the help of Configuration Management Framework (CMF) and sends a response to the NETCONF manager in XML format.
NETCONF Structure

NETCONF can be conceptually partitioned into four layers, as described in Table 14-9.

Table 14-9 NETCONF structure

Layer

Example

Description

Layer 1: transport protocols

BEEP, SSH, SSL

The transport layer provides a communication path for interaction between the NETCONF manager and NETCONF agent.

NETCONF can be layered over any transport protocol that meets the following basic requirements:
  • The transport protocol is connection-oriented. The NETCONF manager and NETCONF agent must establish a persistent connection. This connection must provide reliable, sequenced data transmission.
  • The transport layer provides user authentication, data integrity, and confidentiality for NETCONF.
  • The transport protocol provides a mechanism to distinguish the session type (client or server) for NETCONF.
NOTE:

Currently, the device only supports SSH as the transport layer protocol of NETCONF.

Layer 2: RPC

<rpc>, <rpc-reply>

The RPC layer provides a simple RPC request and reply mechanism independent of transport protocols. The client uses the <rpc> element to encapsulate RPC request information and sends the RPC request information to the server using a secure, connection-oriented session. The server uses the <rpc-reply> element to encapsulate RPC response information (content at the operation and content layers) and sends the RPC response information to the client.

Normally, the <rpc-reply> element encapsulates data required by the client or a configuration success message. 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>, <notification>

The operation layer defines a series of operations used in RPC. These operations compose the basic capabilities of NETCONF.

Layer 4: content

Configuration data

The content layer describes configuration data required for network management. The content layer is the only layer that is not standardized. It has no standard modeling language or data model. Therefore, configuration data varies according to devices from different vendors.

NETCONF Transport Layer

The transport layer provides a reliable mechanism to send data based on the sequence number. The mechanism provides such capabilities as user authentication, data integrity, and confidentiality.

NETCONF is connection-oriented and must provide reliable and sequenced data transmission. NETCONF does not verify, check integrity of, or acknowledge transmitted data. Therefore, NETCONF requires SSH as its transport layer protocol.

After the NETCONF agent process is started, the NETCONF agent can receive connection requests sent from the NETCONF manager and process corresponding configurations. User authentication is performed during connection setup. The process is as follows:
  1. The NETCONF agent process is started.
  2. The NETCONF agent creates a listening port and waits for connection requests from the NETCONF manager (SSH client).
  3. The SSH client sends a connection request to the NETCONF agent.
  4. The NETCONF agent and SSH client start data transmission and exchange complete information and encryption keys. The NETCONF agent authenticates the client using the ssh-userauth service.
  5. After the client is authenticated, the NETCONF agent sends the authentication information to the user management module to establish a session with the SSH client. The client starts the ssh-connection service.

A connection at the transport layer of NETCONF has been set up. The NETCONF manager can manage the NETCONF agent through this session.

After a NETCONF connection is established, the client and the server exchange NETCONF messages. The NETCONF agent sends a Hello message that carries its capabilities and identifiers. The client also sends a Hello message that carries its capabilities. After receiving the Hello message sent from the client, the NETCONF agent identifies the capabilities that will be used and ignores unnecessary and unidentified capabilities.

NOTE:

For details about NETCONF capabilities, see NETCONF Operation Layer.

The following is a sample of a Hello message sent by the NETCONF manager.

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
    <capability>urn:huawei:netconf:capability:sync:1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/sync/1.0</capability>
    <capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/discard-commit/1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/rollback/1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/exchange/1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/action/1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/update/1.0</capability>
  </capabilities>
</hello>
]]>]]>

The following is a sample of a Hello message sent by the NETCONF agent.

<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">

   <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0/capability>
    <capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/sync/1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/exchange/1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/active/1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/action/1.0</capability>
    <capability>http://www.huawei.com/netconf/capability/update/1.0</capability>
   </capabilities>
   <session-id>1149</session-id>
</hello>

The following are the samples of invalid Hello messages sent by the NETCONF manager:

  • Hello messages without base capabilities

    <?xml version="1.0">
    <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <capabilities>
    </capabilities>
    </hello>
  • No correct Hello messages

    <?xml version="1.0">
    <capabilities>
    <capabilities>urn:ietf:params:netconf:base:1.0</capability>
    <capabilities>urn:ietf:params:netconf:capability:candidate:1.0</capability>
    </capabilities>
    </hello>

NETCONF RPC Layer

A program can use the Remote Procedure Call (RPC) protocol to request services from a remote computer program over a network without knowing the underlying network technologies. The RPC protocol assumes the existence of a transmission protocol such as Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) to transmit data exchanged between communicating programs. In the open systems interconnection (OSI) reference model, RPC traverses the transport layer and application layer. RPC simplifies development of applications such as a network distributed multi-program.

NETCONF uses a RPC-based communication mechanism. The NETCONF manager and NETCONF agent use <rpc> and <rpc-reply> elements to provide framing of NETCONF requests and responses independent of transport layer protocols, implementing device configuration and management. After the NETCONF manager and NETCONF agent exchange hello messages, the NETCONF manager sends <rpc> request messages to the NETCONF agent to configure and manage the NETCONF agent. The NETCONF agent sends an <rpc-reply> message in response to each request message.

<rpc> Element

The <rpc> element encapsulates a request message that the NETCONF manager sends to the NETCONF agent. The format of an RPC request message is as follows:

<rpc message-id="101"
     xmlns="urn:idtf:params:xml:ns:netconf:base:1.0">
    <some-method>
        <!--method parameters here  -->
    </some-method>
</rpc>
<rpc-reply> Element

The <rpc-reply> element encapsulates a response message for an RPC request message. The NETCONF agent must return an <rpc-reply> message containing every attribute in the <rpc> request message to the NETCONF manager. For example, the <rpc> element invokes the NETCONF <get> operation to obtain the user ID. The <rpc> request message contains the user-id attribute, as follows:

<rpc message-id="101"
     xmlns="urn:idtf:params:xml:ns:netconf:base:1.0">
     xmlns:ex="http://example.net/content/1.0"
     ex:user-id="fred"
    <get/>
</rpc>

The <rpc-reply> message contains the value of user-id, as follows:

<rpc-reply message-id="101"
     xmlns="urn:idtf:params:xml:ns:netconf:base:1.0">
     xmlns:ex="http://example.net/content/1.0"
     ex:user-id="fred"
    <data>
       <!--contents here  -->
    <data>
</rpc-reply>

If an error occurs during RPC request processing, the NETCONF agent returns an <rpc-reply> message containing the <rpc-error> element and other elements to notify the NETCONF manager of the failure cause.

NETCONF Operation Layer

The operation layer is the core of NETCONF, and its function is similar to SNMP primitives. The NETCONF operation layer defines an underlying operation set used to configure and obtain device information saved in a database. The defined operations allow you to obtain, configure, copy, and delete device information in the database. The basic operations defined by NETCONF must be a minimal set of functions.

NOTE:

By default, the NETCONF agent supports all basic operations defined by NETCONF.

For details about the NETCONF database, see NETCONF Content Layer.

When the NETCONF manager and NETCONF agent establish an NETCONF session, they send the base capability of NETCONF urn:ietf:params:netconf:base:1.0 to the peer.

Table 14-10 describes basic operations defined in the base capability.

Table 14-10 Basic operations defined in the base capability of NETCONF

Basic Operation

Description

<get-config>

Obtains all or specified configuration data from the <running/>, <candidate/>, and <startup/> configuration databases.

<get>

Obtains some or all running configuration data and status data from the <running/> configuration database.

<edit-config>

Creates, modifies, or deletes configuration data.

<copy-config>

Replaces the target configuration database with the source configuration database. If no target configuration database has been created, this operation creates a configuration database. If a target configuration database has been created, the source configuration database replaces the target configuration database.

<delete-config>

Deletes a configuration database. The <running/> configuration database cannot be deleted.

<lock>

Locks a configuration database. A locked configuration database cannot be modified by other users. Locking a configuration database ensures that the configuration of a database is not affected by the configuration of the NETCONF manager, SNMP, or command-line interface (CLI) script, preventing a conflict.

<unlock>

Unlocks a locked configuration database. Users can unlock only the configuration databases they have locked.

<close-session>

Closes an NETCONF session.

<kill-session>

Forcibly closes an NETCONF session. Only an administrator can perform this operation.

In addition to the basic functionality, NETCONF also allows the NETCONF manager to discover the extended protocol set supported by the NETCONF agent. The feature is called capabilities. NETCONF uses capabilities to define additional functions except the basic functionality. The capabilities enhance the NETCONF functionality and strengthen the fault tolerance and scalability. This facilitates the implementation of the NETCONF-based open network management architecture and provides an efficient method for equipment manufacturers to comply with NETCONF and expand device functionality.

Table 14-11 describes the standard capabilities defined by NETCONF and operations defined in the standard capabilities.

Table 14-11 Standard capabilities defined by NETCONF and operations defined in the standard capabilities

Standard Capability

Description

Operation Defined in the Standard Capability

Dependency

writable-running

This capability allows a device to access the <running/> configuration database. That is, the device supports <edit-config> and <copy-config> operations for running configuration data.

-

-

Candidate configuration

This capability indicates that a device supports the <candidate/> configuration database.

This capability allows the device to perform operations on configuration data without affecting the configuration data in use.

Two operations are added:
  • <commit>: converts all configuration data in the <candidate/> configuration database into running configuration data.
  • <discard-changes>: discards uncommitted configuration data from the <candidate/> configuration database. After this operation is performed, the configuration data in the <candidate/> configuration database remains the same as the data in the <running/> configuration database.

-

Confirmed Commit

This capability indicates that the device allows the <commit> operation to carry the <confirmed> and <confirm-timeout> parameters.

If the Confirmed Commit capability is used in a specified interval, all configured data are performed and converted to the running configuration data on the device. If the Confirmed Commit capability is used when the interval elapses, the configured data are not performed and restored to the original configuration. The interval can be configured using the <confirm-timeout> parameter.

The following two operations are added:
  • <confirmed>: performs all configured data and converts them to the running configuration data on a device. The Confirmed Commit capability already contains this parameter.
  • <onfirm-timeout>: specifies the interval at which the Confirmed Commit capability is used, in seconds. The default value is 600s.

-

Rollback on error

This capability allows a device to perform rollback when an error occurs. 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 status before the <edit-config> operation is performed.

-

-

Distinct startup

This capability allows a device to perform a distinct startup. The NETCONF agent checks parameter availability and consistency.

NOTE:

This capability indicates that the NETCONF agent supports the <startup/> configuration database and can distinguish the <running/> configuration database from the <startup/> configuration database. To permanently save configuration data in the <running/> configuration database, the device performs a <copy-config> operation to copy the configuration data from the <running/> configuration database to the <startup/> configuration database.

-

-

Notification

This capability indicates that the device can report alarms and events to the network management system (NMS) sequentially using notification messages. The NMS can then manage the device based on received alarms and events. The NETCONF notification mechanism is an active notification mechanism based on Transmission Control Protocol (TCP) connections.

-

-

Interleave

This capability improves management efficiency by enabling a NETCONF session to be used for multiple purposes, reducing the total number of required NETCONF sessions and switching between NETCONF sessions.

-

-

In addition to the base capability, Huawei defines proprietary capabilities and operations in the proprietary capabilities, as described in Table 14-12.

Table 14-12 Proprietary capabilities defined by Huawei and operations defined in the proprietary capabilities

Proprietary Capability

Description

Operation Defined in the Proprietary Capability

Dependency

Sync

This capability allows a device to perform data synchronization.

The NETCONF manager sends a request to the NETCONF agent to update the local data set of the NETCONF manager. A file transfer protocol is used to synchronize NETCONF agent data to a destination folder.

  • <sync-full>: synchronizes the device configuration file to a target server in compressed mode.
  • <sync-inc>: synchronizes the device configuration file between two check points.

-

Active notification

This capability allows a device to notify the peer that it is active.

<active>: When the NETCONF agent is performing an operation that takes a long time, it periodically sends <active> packets to notify the NETCONF manager that it is active and performing an operation.

-

Action

This capability allows a device to run commands.

<execute-action>: requests the NETCONF agent to run a maintenance command (excluding basic configuration and query commands).

-

Execute CLI

This capability indicates that the device can interact with the request sender in request processing.

Only a device with the exchange capability supports the <execute-cli> operation.

The NETCONF manager performs the <execute-cli> operation to execute CLI commands through NETCONF. Maximum 60 commands are allowed in single <rpc> request. Maximum command string length allowed is 512 bytes. Execute-cli operation behaves as stop on error. For example, if any failure in command execution, then it does not execute the rest of commands in <rpc> request.

-

-

Update

This capability allows a device to update configuration data.

<update>: updates configuration data in the <candidate/> configuration database to the <running/> configuration database when a conflict occurs during data commitment.

-

Exchange

This capability allows a device to exchange information with a peer.

If an NETCONF session has the exchange capability, it supports the <get-next> operation.

-

-

Commit-description

This capability indicates that a description of the committed data can be configured when the data in the <candidate/> configuration database is committed to the <running/> configuration database.

-

-

Discard Commit

This operation is used to cancel/abort an ongoing confirmed-commit operation. For example, before confirmed commit timeout or confirming <commit> operation.

-

-

NETCONF Content Layer

The content layer describes configuration data required for network management. The configuration data varies according to devices from different vendors. The content layer is the only layer that is not standardized. It has no standard modeling language or data model.

NETCONF defines three standard conceptual configuration databases.

  • <running/>

    This configuration database stores various configuration parameters that are running on a device. It is the only standard database that is mandatory if the NETCONF agent does not support the candidate capability. The NETCONF agent must be allowed to edit the database.

    The <running/> database also stores all the conceptual status information currently available on the device. A <get> operation can be performed on the <running/> database to obtain the status information, statistics, and configuration parameters. The <get-config> operation obtains only the configuration data.

  • <candidate/>

    The NETCONF supports the candidate capability to perform operations on the <candidate/> database. Any change to the <candidate/> database does not directly affect the network device. The administrator performs a <commit> operation to activate the changes made to the <candidate/> database and make them a part of <running/> database. After a successful <commit> operation, the <candidate/> database and <running/> database have the same content. A <lock> operation can be performed only on the <running/> database.

    The <candidate/> database is a global database, and the administrator can perform a <discard-changes> operation to remove the modified configurations that are not required.

  • <startup/>

    The NETCONF supports the startup capability to perform corresponding operations on the <startup/> database. The NETCONF agent allows an administrator to define a separate data set and perform a distinct startup for a device. If this capability takes effect, the NETCONF agent does not save changes of the <running/> database to the data set. Instead, the NETCONF agent performs a <copy-config> operation to overwrite content in the <startup/> database with current configurations. If this capability does not take effect, the NETCONF agent updates the data set when the running configuration is modified. In either of the preceding situations, the NETCONF agent needs to maintain the configurations of the data set and can restore the configuration after the device restarts.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 57260

Downloads: 3617

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