CloudEngine 6800&5800 V100R001C00 Configuration Guide - Network Management 04 PDF

CloudEngine 6800&5800 Series Switches
V100R001C00
Configuration Guide - Network
Management
Issue 04
Date 2013-07-10
HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,
and recommendations in this document are provided "AS IS" without warranties, guarantees or representations
of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://enterprise.huawei.com
Issue 04 (2013-07-10) Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd.
i
About This Document
Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the network management feature supported by
the device.
This document is intended for:
l Data configuration engineers
l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
DANGER
Indicates a hazard with a high level or medium level of risk
which, if not avoided, could result in death or serious injury.
WARNING
Indicates a hazard with a low level of risk which, if not
avoided, could result in minor or moderate injury.
CAUTION
Indicates a potentially hazardous situation that, if not
avoided, could result in equipment damage, data loss,
performance deterioration, or unanticipated results.
TIP
Provides a tip that may help you solve a problem or save time.
NOTE
Provides additional information to emphasize or supplement
important points in the main text.

Configuration Guide - Network Management About This Document
ii
Command Conventions
The command conventions that may be found in this document are defined as follows.
Convention Description
Boldface The keywords of a command line are in boldface.
Italic Command arguments are in italics.
[ ] Items (keywords or arguments) in brackets [ ] are optional.
{ x | y | ... } Optional items are grouped in braces and separated by
vertical bars. One item is selected.
[ x | y | ... ] Optional items are grouped in brackets and separated by
vertical bars. One item is selected or no item is selected.
{ x | y | ... }
*
Optional items are grouped in braces and separated by
vertical bars. A minimum of one item or a maximum of all
items can be selected.
[ x | y | ... ]
*
Optional items are grouped in brackets and separated by
vertical bars. You can select one or several items, or select
no item.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.

Interface Numbering Conventions
Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 04 (2013-07-10)
This version has the following updates:
The following information is modified:
l 7.5.1 Clearing LLDP Statistics
l 7.5.2 Monitoring LLDP Status
iii
l 1.4.3 (Optional) Configuring the Trap Function
l 1.4.1 Configuring Basic SNMPv1 Functions
l 1.5.1 Configuring Basic SNMPv2c Functions
l 1.5.3 (Optional) Configuring the Trap/Inform Function
l 1.5.5 Checking the Configuration
Initial commercial release.
iv
Contents
About This Document.....................................................................................................................ii
1 SNMP Configuration....................................................................................................................1
1.1 SNMP Overview.............................................................................................................................................................3
1.2 SNMP Features Supported by the Device......................................................................................................................3
1.3 Default Configuration.....................................................................................................................................................5
1.4 Configuring a Device to Communicate with an NMS by Running SNMPv1................................................................6
1.4.1 Configuring Basic SNMPv1 Functions.......................................................................................................................6
1.4.2 (Optional) Restricting Management Rights of the NMS.............................................................................................8
1.4.3 (Optional) Configuring the Trap Function..................................................................................................................9
1.4.4 (Optional) Enhancing the Reliability for Transmitting SNMP Packets....................................................................11
1.4.5 Checking the Configuration.......................................................................................................................................11
1.5 Configuring a Device to Communicate with an NMS by Running SNMPv2c............................................................12
1.5.1 Configuring Basic SNMPv2c Functions...................................................................................................................13
1.5.2 (Optional) Restricting Management Rights of the NMS...........................................................................................14
1.5.3 (Optional) Configuring the Trap/Inform Function....................................................................................................16
1.6 Configuring a Device to Communicate with an NMS by Running SNMPv3..............................................................19
1.6.1 Configuring Basic SNMPv3 Functions.....................................................................................................................20
1.6.2 (Optional) Restricting Management Rights of the NMS...........................................................................................22
1.6.3 (Optional) Configuring the Trap/Inform Function....................................................................................................25
1.7 Maintaining SNMP.......................................................................................................................................................28
1.7.1 Checking the Statistics About SNMP Packets..........................................................................................................28
1.8 SNMP Configuration Examples...................................................................................................................................28
1.8.1 Example for Configuring a Device to Communicate with an NM Station by Using SNMPv1................................29
1.8.2 Example for Configuring a Device to Communicate with an NM Station by Using SNMPv2c..............................32
1.8.3 Example for Configuring a Device to Communicate with an NM Station by Using SNMPv3................................35
2 RMON Configuration.................................................................................................................39
2.1 RMON Overview.........................................................................................................................................................40
2.2 RMON Supported by the Device..................................................................................................................................41
Configuration Guide - Network Management Contents
v
2.3 Configuring RMON......................................................................................................................................................42
2.3.1 Configuring RMON Statistics Functions..................................................................................................................42
2.3.2 Configuring RMON Alarm Functions.......................................................................................................................44
2.4 Configuration Example.................................................................................................................................................45
2.4.1 Example for Configuring RMON..............................................................................................................................45
3 NETCONF Configuration..........................................................................................................50
3.1 Overview......................................................................................................................................................................51
3.2 Establishing Communication Between the NMS and a Device Using NETCONF.....................................................52
3.2.1 Configuring VTY User Interfaces to Support SSH...................................................................................................52
3.2.2 Configuring an SSH User..........................................................................................................................................53
3.2.3 Enabling NETCONF.................................................................................................................................................57
3.2.4 Logging in to the NETCONF Agent Using the NMS...............................................................................................58
3.3 Configuration Examples...............................................................................................................................................59
3.3.1 Example for Establishing Communication Between the NMS and a Device Using NETCONF.............................59
4 NTP Configuration......................................................................................................................64
4.1 NTP Overview..............................................................................................................................................................65
4.2 NTP Features Supported by the Device.......................................................................................................................65
4.3 Default Configuration...................................................................................................................................................66
4.4 Configuring Basic NTP Functions...............................................................................................................................67
4.4.1 Configuring an NTP primary clock...........................................................................................................................67
4.4.2 Configuring NTP Operating Modes..........................................................................................................................68
4.5 Configuring the Local Source Interface for Sending and Receiving NTP Packets......................................................73
4.6 Limit on the Number of Local Dynamic Sessions.......................................................................................................74
4.7 Configuring NTP Access Control.................................................................................................................................74
4.7.1 Disabling a Specified Interface from Receiving NTP Packets..................................................................................75
4.7.2 Configuring NTP Access Control Authority.............................................................................................................75
4.7.3 Configuring NTP Authentication..............................................................................................................................77
4.8 Maintaining NTP..........................................................................................................................................................78
4.8.1 Monitoring the Running Status of NTP.....................................................................................................................78
4.9 Configuration Examples of NTP..................................................................................................................................79
4.9.1 Example for Configuring Authenticated NTP Unicast Client/Server Mode.............................................................79
4.9.2 Example for Configuring NTP Symmetric Peer Mode.............................................................................................84
4.9.3 Example for Configuring Authenticated NTP Broadcast Mode................................................................................87
4.9.4 Example for Configuring NTP Multicast Mode........................................................................................................91
5 Ping and Tracert Configuration................................................................................................96
5.1 Ping/Tracert Overview.................................................................................................................................................97
5.1.1 Ping/Tracert...............................................................................................................................................................97
vi
5.1.2 TRILL Ping................................................................................................................................................................98
5.2 Checking IP Network Connectivity Through Ping/Tracert..........................................................................................99
5.2.1 Checking IP Network Connectivity Through Ping....................................................................................................99
5.2.2 Detecting IP Network Paths and Locating Faults Through Tracert..........................................................................99
5.3 Checking TRILL Network Connectivity Through Ping.............................................................................................100
5.4 Configuration Examples.............................................................................................................................................100
5.4.1 Example for Performing Ping and Tracert Operations............................................................................................100
6 NQA Configuration..................................................................................................................102
6.1 NQA Overview...........................................................................................................................................................103
6.2 NQA Features Supported by the Device....................................................................................................................103
6.3 Configuring an NQA Test Instance............................................................................................................................104
6.3.1 Configuring an ICMP Test Instance........................................................................................................................104
6.3.2 Configuring an ICMP Jitter Test Instance...............................................................................................................106
6.3.3 Configuring a TCP Test Instance............................................................................................................................108
6.3.4 Configuring a UDP Jitter Test Instance...................................................................................................................110
6.3.5 Checking the Configuration.....................................................................................................................................113
6.4 Configuring the NQA Transmission Delay Threshold and Alarm Threshold............................................................113
6.4.1 Configuring the Two-Way Transmission Delay Threshold....................................................................................114
6.4.2 Configuring the One-Way Transmission Delay Threshold.....................................................................................114
6.5 Configuring the Trap Function...................................................................................................................................115
6.5.1 Enabling the NQA Alarm Function.........................................................................................................................116
6.5.2 Configuring the NQA Client to Send Traps When a Test Fails..............................................................................116
6.5.3 Configuring the NQA Client to Send Traps When a Probe Fails............................................................................117
6.5.4 Configuring the NQA Client to Send Traps After a Probe Succeeds......................................................................118
6.5.5 Configuring the NQA Client to Send Traps When the Transmission Delay Exceeds the Threshold.....................118
6.6 Scheduling an NQA Test Instance..............................................................................................................................119
6.6.1 Starting an NQA Test Instance................................................................................................................................119
6.6.2 (Optional) Stopping an NQA Test Instance............................................................................................................121
6.6.3 Checking Test Results.............................................................................................................................................122
6.7 Maintaining NQA.......................................................................................................................................................122
6.7.1 Clearing NQA Test Statistics..................................................................................................................................123
6.8.1 Example for Configuring an ICMP Test Instance...................................................................................................123
6.8.2 Example for Configuring an ICMP Jitter Test Instance..........................................................................................125
6.8.3 Example for Configuring a TCP Test Instance.......................................................................................................128
6.8.4 Example for Configuring a UDP Jitter Test Instance..............................................................................................131
7 LLDP Configuration.................................................................................................................134
7.1 LLDP Overview.........................................................................................................................................................135
7.2 Default Configuration.................................................................................................................................................135
7.3 Configuring Basic LLDP Functions...........................................................................................................................135
7.3.1 Enabling LLDP........................................................................................................................................................136
vii
7.3.2 (Optional) Disabling LLDP on an Interface............................................................................................................136
7.3.3 (Optional) Configuring an LLDP Management Address........................................................................................137
7.3.4 (Optional) Configuring LLDP Time Parameters.....................................................................................................138
7.3.5 (Optional) Configuring the Delay in Initializing Interfaces....................................................................................139
7.3.6 (Optional) Configuring the Type of TLVs that an Interface Can Send...................................................................139
7.3.7 (Optional) Configuring the Number of LLDP Packets Quickly Sent by the Device to a Neighbor.......................140
7.3.8 (Optional) Configuring MDN..................................................................................................................................141
7.4 Configuring the LLDP Alarm Function.....................................................................................................................143
7.4.1 Setting the Delay in Sending Traps About Neighbor Information Changes...........................................................143
7.4.2 Enabling the LLDP Trap Function.........................................................................................................................144
7.5 Maintenance LLDP.....................................................................................................................................................145
7.5.1 Clearing LLDP Statistics.........................................................................................................................................145
7.5.2 Monitoring LLDP Status.........................................................................................................................................146
7.6.1 Example for Configuring LLDP on the Device That Has a Single Neighbor.........................................................146
7.6.2 Example for Configuring LLDP on the Device That Has Multiple Neighbors.......................................................150
7.6.3 Example for Configuring LLDP on the Network with link aggregation configured..............................................155
7.6.4 Example for Configuring MDN..............................................................................................................................160
8 Packet Capture Configuration................................................................................................164
8.1 Packet Capture Overview...........................................................................................................................................165
8.2 Configuring the Device to Capture Forwarded Packets.............................................................................................165
8.3 Configuring the Capture Function for Packets Sent to the CPU................................................................................166
8.4.1 Example for Configuring Packet Capture Function................................................................................................167
viii
1 SNMP Configuration
About This Chapter
The Simple Network Management Protocol (SNMP) is a standard network management protocol
widely used on TCP/IP networks. It uses a central computer (a network management station)
that runs network management software to manage network elements. There are three SNMP
versions, SNMPv1, SNMPv2c, and SNMPv3. Users can choose to configure one or more
versions if needed.
1.1 SNMP Overview
As a network management standard protocol used on TCP/IP networks, SNMP uses a central
computer (NMS) that runs network management software to manage network elements.
1.2 SNMP Features Supported by the Device
This section compares SNMP versions in terms of their support for features and usage scenarios
to provide a reference for your SNMP version selection during network deployment.
1.3 Default Configuration
This topic describes the default settings of common parameters.
1.4 Configuring a Device to Communicate with an NMS by Running SNMPv1
After SNMPv1 is configured, a managed device and an NMS can run SNMPv1 to communicate
with each other. To ensure communication, you need to configure the agent and NMS. This
section describes the configuration on a managed device (the agent side). For details about
configuration on an NMS, see the pertaining NMS operation guide.
1.5 Configuring a Device to Communicate with an NMS by Running SNMPv2c
After SNMPv2c is configured, a managed device and an NMS can run SNMPv2c to
communicate with each other. To ensure communication, you need to configure the agent and
NMS. This section describes the configuration on a managed device (the agent side). For details
about configuration on an NMS, see the pertaining NMS operation guide.
1.6 Configuring a Device to Communicate with an NMS by Running SNMPv3
1.7 Maintaining SNMP
Configuration Guide - Network Management 1 SNMP Configuration
1
This chapter describes how to monitor SNMP running status after the SNMP configuration is
complete.
1.8 SNMP Configuration Examples
This section provides several examples for configuring SNMP. The configuration roadmap in
the examples helps you understand the configuration procedures. Each configuration example
provides information about the networking requirements and configuration roadmap.
2
1.1 SNMP Overview
As a network management standard protocol used on TCP/IP networks, SNMP uses a central
computer (NMS) that runs network management software to manage network elements.
In a large network, it is very difficult for network administrator to detect, locate and rectify the
fault as the devices does not report the fault. This affects maintenance efficiency and increases
maintenance workload. To solve this problem, equipment vendors have provided network
management functions in some products. The NMS then can query the status of remote devices,
and devices can send traps to the NMS in the case of particular events.
SNMP is an application layer protocol that defines the transmission of management information
between the NMS and the agent. SNMP defines operations that the NMS can perform on
managed devices and enables devices to report traps upon a fault.
1.2 SNMP Features Supported by the Device
This section compares SNMP versions in terms of their support for features and usage scenarios
to provide a reference for your SNMP version selection during network deployment.
The device supports SNMPv1, SNMPv2c, and SNMPv3. Table 1-1 lists the features supported
by SNMP, and Table 1-2 shows the support of different SNMP versions for the features. Table
1-3 describes the usage scenarios of SNMP versions, which helps you choose a proper version
for the communication between an NMS and managed devices based on the network operation
conditions.
NOTE
When multiple NMSs using different SNMP versions manage the same device in a network SNMPv1,
SNMPv2c, and SNMPv3 are configured on the device for its communication with all the NMSs.
Table 1-1 Description of features supported by SNMP
Feature Description
Access control This function is used to restrict a user's device administration rights.
It gives specific users the rights to manage specified objects on
devices and therefore provides fine management.
Authentication and
privacy
The authentication and privacy packets are transmitted between the
NMS and managed devices. This prevents data packets from being
intercepted or modified, improving data sending security.
Error code Error codes help the administrator to identify and rectify faults. It is
easy for the administrator to manage the device if the error codes are
more with variety.
Trap Traps are sent from managed devices to the NMS. Traps help
administrator to know device faults.
The managed devices do not require the acknowledgement from the
NMS after sending traps.
3
Feature Description
Inform Informs are sent from managed devices to the NMS.
The managed devices require the acknowledgement from the NMS
after sending informs. If a managed device does not receive an
acknowledgement after sending an inform.
GetBulk GetBulk allows an administrator to perform Get-Next operations in
batches. In a large network, GetBulk reduces the workload of
administrator and improves management efficiency.

NOTE
After the restart, the NMS can receive the informs that are sent during the restart.
Table 1-2 Different SNMP versions support for the features
Feature SNMPv1 SNMPv2c SNMPv3
Access control Access control based
on the community
name and MIB view
Access control based
on the community
name and MIB view
Access control based
on the user, user
group, and MIB view
Authentication and
privacy
Authentication based
on the community
name
Authentication
based on the
community name
Supported
authentication and
privacy modes are as
follows:
Authentication
mode:
l MD5
l SHA
Encryption mode:
DES56
Error code 6 error codes
supported
16 error codes
supported
16 error codes
supported
Trap Supported Supported Supported
Inform Not supported Supported Supported
GetBulk Not supported Supported Supported

4
Table 1-3 Usage scenarios of different SNMP versions
Version Usage Scenario
SNMPv1 This version is applicable to small-scale networks whose networking
is simple and security requirements are low or whose security and
stability are good, such as campus networks and small enterprise
networks.
SNMPv2c This version is applicable to medium and large-scale networks whose
security requirements are not strict or whose security is good (for
example, VPNs) but whose services are so busy that traffic
congestion may occur.
Use inform to ensure the messages sent from managed devices are
received by the NMS.
SNMPv3 This version is applicable to networks of various scales, especially
the networks that have strict requirements on security and can be
managed only by authorized administrators. For example, data
between the NMS and managed device needs to be transmitted over
a public network.

If you plan to build a network, choose an SNMP version based on your usage scenario. If you
plan to expand or upgrade an existing network, choose an SNMP version to match the SNMP
version running on the NMS to ensure the communication between managed devices and the
NMS.
This topic describes the default settings of common parameters.
Table 1-4 lists the default settings of SNMP parameters.
Table 1-4 Default settings of SNMP parameters
Parameter Default Value
SNMP agent The SNMP agent function is disabled.
SNMP trap receive
host
No host is configured to receive traps.
SNMP version SNMPv3.
SNMPv3
authentication mode
and encryption mode
No authentication and no encryption.

5
1.4 Configuring a Device to Communicate with an NMS by
Running SNMPv1
Pre-configuration Tasks
Before configuring a device to communicate with an NMS by running SNMPv1, configure a
routing protocol to ensure that at least one route exist between switch and NMS.
Procedure
When you configure the device to communicate with the NMS using SNMPv1, Configuring
Basic SNMPv1 Functions is mandatory and optional steps can be performed in any sequence.
After the SNMP basic functions are configured, the NMS can communicate with managed
devices.
l The access permission of the NMS that uses the configured community name is
Viewdefault view (OID: 1.3.6.1).
l The managed device sends traps generated by the modules that are enabled by default to
the NMS.
If finer device management is required, follow directions below to configure a managed device:
l To allow a specified NMS that uses the community name to manage specified objects on
the device, follow the procedure described in Restricting Management Rights of the
NMS.
l To allow a specified module on the managed device to report traps to the NMS, follow the
procedure described in Configuring the Trap Function.
l To modify SNMP packet transmission parameters, see Enhancing the Reliability for
Transmitting SNMP Packets.
1.4.1 Configuring Basic SNMPv1 Functions
Context
For the configuration of basic SNMP functions, Step 1, Step 3, Step 4, Step 5 and Step 7 are
mandatory steps. After the configuration is complete, basic SNMP communication can be
established between the NMS and managed device.
Procedure
Step 1 Run:
system-view
The system view is displayed.
6
Step 2 (Optional) Run:
snmp-agent
The SNMP agent function is enabled.
By default, the SNMP agent function is disabled. By executing the snmp-agent command with
any parameter enables the SNMP agent function.
Step 3 Run:
snmp-agent sys-info version v1
The SNMP version is set to SNMPv1.
By default, SNMPv3 is enabled.
After SNMPv1 is enabled, the managed devices support SNMPv1 and SNMPv3 and can be
monitored and manged by both SNMPv1 and SNMPv3 NMSs.
Step 4 Run:
snmp-agent community { read | write } { community-name | cipher community-name }
The community name is set.
By default, the complexity check is enabled for a community name. If a community name fails
the complexity check, the community name cannot be configured. To disable the complexity
check for a community name, run the snmp-agent community complexity-check disable
command.
NOTE
The Switch has the following requirements for community name complexity:
l The default minimum length of a community name is six characters.
l A community name includes at least two kinds of characters, which can be uppercase letters, lowercase
letters, digits, and special characters except question marks (?) and spaces.
After the read-and-write community name is set, the NMS with this name has the right of the
ViewDefault view (OID: 1.3.6.1). To change the access right of the NMS, see Restricting
Management Rights of the NMS.
NOTE
Ensure that the community name of the NMS is the same as that set on the agent. If the NMS and the agent
have different community names, the NMS cannot access the agent.
Step 5 Run:
snmp-agent target-host [ host-name host-name ] trap address udp-domain ip-address
[ udp-port port-number | source interface-type interface-number | vpn-instance vpn-
instance-name ]
*
params securityname { security-name | cipher security-name }
[ v1 | private-netmanager | ext-vb | notify-filter-profile profile-name ]
*
The destination IP address of traps and error codes is configured.
snmp-agent sys-info { contact contact | location location }
The equipment administrators contact information or location is configured.
By default, the vendor's contact information is "R&D Beijing, Huawei Technologies co.,Ltd.".
The default location is "Beijing China".
7
This step is required for the NMS administrator to view contact information and locations of the
equipment administrator when the NMS manages many devices. This helps the NMS
administrator to contact the equipment administrators for fault location and rectification.
Step 7 Run:
commit
The configuration is committed.
----End
1.4.2 (Optional) Restricting Management Rights of the NMS
Context
When multiple NMSs using the same community name manage one device, perform this
configuration based on the site requirements.
Scenario Steps
All NMSs using this community name
have the right of the ViewDefault view.
No action required
Specified NMSs using this community
name have the right of the ViewDefault
view.
Step 1, Step 2, Step 4, Step 5
manage specified objects on the
managed device.
name manage specified objects on the
managed devices.
Step 1, Step 2, Step 3, Step 4, Step 5

NOTE
The ViewDefault view is the 1.3.6.1 view.
Procedure
Step 1 Run:
system-view
Step 2 Run the following commands to configure the ACL to filter managed devices.
1. Run:
acl { [ number ] acl-number | name acl-name basic }
A basic ACL is created.
2. Run:
rule [ rule-id ] { deny | permit } source { source-ip-address source-wildcard
| any }
8
A rule is added to the ACL.
3. Run:
quit
Return to the system view.
Step 3 Run:
snmp-agent mib-view { excluded | included } view-name oid-tree
A MIB view is created, and manageable MIB objects are specified.
By default, an NMS has right to access the objects in the ViewDefault view.
Step 4 Run:
[ mib-view view-name | acl { acl-number | acl-name } ]
*
The NMS's access right are specified.
By default, the community name has the right of the ViewDefault view.
NOTE
Before specifying the NMS to manage devices with this community name, check the ACL rule. When the
ACL rule is permit, the NMS with the source IP address specified in this rule can access the local device.
When the ACL rule is deny, the NMS with the source IP address specified in this rule cannot access the
local device.
Step 5 Run:
commit
----End
Follow-up Procedure
After the access right are configured, especially after the IP address of the NMS is specified, if
the IP address changes (for example, the NMS changes its location, or IP addresses are
reallocated due to network adjustment), you need to change the IP address of the NMS in the
ACL. Otherwise, the NMS cannot access the device.
1.4.3 (Optional) Configuring the Trap Function
Context
Users can enable the trap function for a specified module. The interface status trap is generated
when the interface status changes. You need to enable the trap function for the standard module
globally and enable the interface status trap function on the specified interface.
Procedure
Step 1 Run:
system-view
Step 2 Enable the trap function.
9
Enable the trap function for a module.
l Run:
snmp-agent trap enable
The trap function is enabled for all modules.
l Run:
snmp-agent trap enable feature-name
The trap function is enabled for a specified module.
Enable the trap function for an interface.
Run:
snmp-agent trap enable feature-name ifnet [ trap-name { linkdown | linkup } ]
The trap function is enabled on all interfaces.
By default, the trap function is disabled on all interfaces. When parameters linkdown and
linkup are configured, the device sends a trap to the NMS upon an interface status change. When
an interface frequently sends traps to the NMS because of frequent status changes, you can
disable the interface status trap function on the interface to reduce the NMS loads. The procedure
is as follows:
1. Run:
interface interface-type interface-number
The interface view is displayed.
2. Run:
undo enable snmp trap updown
The interface status trap function is disabled.
3. Run:
quit
Step 3 Run:
snmp-agent notify-filter-profile { excluded | included } profile-name oid-tree
A trap filtering rule is created or updated.
By default, no trap is filtered.
Step 4 Run:
snmp-agent trap source interface-type interface-number
The source interface for traps is specified.
After the source interface is specified, the IP address of the source interface is used as the source
IP address for sending traps. This helps the NMS identify the trap source. The source interface
that sends traps must have an IP address; otherwise, the commands will fail to take effect. To
ensure device security, it is recommended that you set the source IP address to the local loopback
address.
The source interface specified on the switch for traps must be consistent with that specified on
the NMS; otherwise, the NMS does not accept the traps sent from the switch.
Step 5 Run:
commit
10
----End
1.4.4 (Optional) Enhancing the Reliability for Transmitting SNMP
Packets
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent packet max-size byte-count
The maximum size of an SNMP packet that the device can receive or send is set.
By default, the maximum size of an SNMP packet that the device can receive or send is 12000
bytes.
Step 3 Run:
commit
----End
1.4.5 Checking the Configuration
Prerequisites
The configurations of basic SNMPv1 functions are complete.
Procedure
l Run the display snmp-agent community [ read | write ] command to check the
configured community name.
l Run the display snmp-agent sys-info version command to check the enabled SNMP
version.
l Run the display acl { acl-number | name acl-name | all } command to check the ACL
rules.
l Run the display snmp-agent mib-view [ exclude | include | viewname view-name ]
command to check the MIB view.
l Run the display snmp-agent mib modules command to check information about loaded
MIB files.
l Run the display snmp-agent sys-info contact command to check the equipment
administrator's contact information.
l Run the display snmp-agent sys-info location command to check the location of the
switch.
11
l Run the display current-configuration | include max-size command to check the
maximum size of an SNMP packet.
l Run the display current-configuration | include trap command to check the configuration
of the trap function.
l Run the display snmp-agent trap all command to check current and default status of all
traps in all features.
l Run the display snmp-agent vacmgroup command to check all the configured View-
based Access Control Model (VACM) groups.
l Run the display snmp-agent target-host command to check information about the target
host.
l Run the display snmp-agent notify-filter-profile profile-name command to check the
configurations of the filtered traps.
----End
Running SNMPv2c
After SNMPv2c is configured, a managed device and an NMS can run SNMPv2c to
communicate with each other. To ensure communication, you need to configure the agent and
NMS. This section describes the configuration on a managed device (the agent side). For details
about configuration on an NMS, see the pertaining NMS operation guide.
Before configuring a device to communicate with an NMS by running SNMPv2c, configure a
Procedure
When you configure the device to communicate with the NMS using SNMPv2c, Configuring
Basic SNMPv2c Functions is mandatory and optional steps can be performed in any sequence.
devices.
the NMS.
NMS.
procedure described in Configuring the Trap/Inform Function.
12
1.5.1 Configuring Basic SNMPv2c Functions
Context
For the configuration of basic SNMP functions, Step 1, Step 3, Step 4, Step 5 and Step 7, are
When you configure a destination IP address for traps and error codes sent from the managed
devices, configure the trap or inform function as required.
l The traps sent by the managed device do not need to be acknowledged by the NMS.
l The informs sent by the managed device need to be acknowledged by the NMS. If no
acknowledgement message from the NMS is received within a specified time period, the
managed device resends the inform until the number of retransmissions reaches the
maximum.
When the managed device sends an inform, it records the inform in the log. If the NMS
and link between the NMS and managed device recovers from a fault, the NMS can still
learn the inform sent during the fault occurrence and rectification.
In this regard, informs are more reliable than traps, but the device may need to buffer a lot of
informs because of the inform retransmission mechanism and this may consume many memory
resources. If the network is stable, using traps is recommended. If the network is unstable and
the device's memory capacity is sufficient, using inform is recommended.
Procedure
Step 1 Run:
system-view
snmp-agent
Step 3 Run:
snmp-agent sys-info version v2c
The SNMP version is set to SNMPv2c.
By default, SNMPv3 is enabled.
After SNMPv2c is enabled, the managed devices support SNMPv2c and SNMPv3 and can be
monitored and manged by both SNMPv2c and SNMPv3 NMSs.
Step 4 Run:
The community name is configured for the device.
By default, the complexity check is enabled for a community name. If a community name fails
the complexity check, the community name cannot be configured. To disable the complexity
13
check for a community name, run the snmp-agent community complexity-check disable
command.
NOTE
The Switch has the following requirements for community name complexity:
l The default minimum length of a community name is six characters.
l A community name includes at least two kinds of characters, which can be uppercase letters, lowercase
letters, digits, and special characters except question marks (?) and spaces.
After the read-and-write community name is set, the NMS with this name has the right of the
ViewDefault view (OID: 1.3.6.1). To change the access right of the NMS, see Restricting
Management Rights of the NMS.
NOTE
Ensure that the community name of the NMS is the same as that set on the agent. If the NMS and the agent
have different community names, the NMS cannot access the agent.
Step 5 Choose one of the following commands as needed to configure a destination IP address of traps
and code errors sent from the device.
l To configure a destination IP address of traps and error codes, run:
snmp-agent target-host [ host-name host-name ] trap address udp-domain ip-
address [ udp-port port-number | source interface-type interface-number | vpn-
instance vpn-instance-name ]
*
params securityname { security-name | cipher
security-name } [ v2c | private-netmanager | ext-vb | notify-filter-profile
profile-name ]
*
l To configure a destination IP address of informs and error codes, run:
snmp-agent target-host [ host-name host-name ] inform address udp-domain ip-
*
params securityname { security-name | cipher
security-name } v2c [ ext-vb | notify-filter-profile profile-name ]
*
Step 7 Run:
commit
----End
Context
When multiple NMSs using the same community name manage one device, perform this
14
Scenario Steps
have the right of the ViewDefault view.
No action required
name have the right of the ViewDefault
view.
manage specified objects on the
managed device.
name manage specified objects on the
managed devices.
Step 1, Step 2, Step 3, Step 4, Step 5

NOTE
Procedure
Step 1 Run:
system-view
Step 2 Run the following commands to configure the ACL to filter managed devices.
1. Run:
2. Run:
| any }
3. Run:
quit
Step 3 Run:
Step 4 Run:
[ mib-view view-name | acl { acl-number | acl-name } ]
*
The NMS's access right are specified.
15
By default, the community name has the right of the ViewDefault view.
NOTE
local device.
Step 5 Run:
commit
----End
Follow-up Procedure
1.5.3 (Optional) Configuring the Trap/Inform Function
Context
Procedure
Step 1 Run:
system-view
l Run:
l Run:
Run:
16
is as follows:
1. Run:
2. Run:
3. Run:
quit
Step 3 Run:
Step 4 Configure trap function parameters based on the trap usage or inform usage selected during the
configuration of basic SNMPv2c functions.
Set trap parameters.
l Run:
After the source interface is specified, its IP address becomes the source IP address of traps.
Configuring the IP address of the local loopback interface as the source interface is
recommended, which can ensure device security.
The source interface specified on the switch for traps must be consistent with that specified
on the NMS; otherwise, the NMS does not accept the traps sent from the switch.
Set inform parameters.
1. Run:
snmp-agent inform { { timeout seconds | resend-times times | pending number }
*
| { timeout seconds | resend-times times }
*
[ host-name host-name | address
udp-domain ip-address [ vpn-instance vpn-instance-name ] params securityname
{ security-name | cipher security-name } ] }
The timeout period for waiting for Inform ACK messages, number of inform
retransmissions, and allowable maximum number of informs to be acknowledged are set.
If the network is unstable, you need to specify the number of inform retransmissions and
allowable maximum number of informs to be acknowledged when you set a timeout period
for waiting for Inform ACK messages. By default, the timeout period for waiting for Inform
ACK messages is 15 seconds; the number of inform retransmissions is 3; the allowable
maximum number of informs waiting to be acknowledged is 39.
2. Run:
snmp-agent notification-log enable
17
The alarm log function is enabled.
If the NMS and managed device cannot communicate because of a link failure, the managed
device no longer sends Inform messages but keeps recording alarm logs. When the link
recovers, the destination host synchronizes the recorded alarm logs with the managed
device.
After the alarm log function is enabled, only Inform messages are recorded, and Trap
messages are not recorded.
By default, the alarm log function is disabled.
3. Run:
snmp-agent notification-log { global-ageout ageout | global-limit limit }
*
The aging time of alarm logs and the maximum pieces of alarm logs in the log buffer are
set.
By default, the aging time of the alarm logs is 24 hours. If the aging time expires, the alarm
logs are automatically deleted.
By default, the log buffer can store a maximum of 500 alarm logs. If the number of alarm
logs exceeds 500, the NMS deletes alarm logs from the earliest one.
Step 5 Run:
commit
----End
Packets
Procedure
Step 1 Run:
system-view
Step 2 Run:
bytes.
Step 3 Run:
commit
----End
Prerequisites
The configurations of basic SNMPv2c functions are complete.
18
Procedure
l Run the display snmp-agent community [ read | write ] command to check the configured
community name.
version.
l Run the display acl { acl-number | name acl-name | all } command to check the ACL rules.
MIB files.
switch.
l Run the display current-configuration | include trap command to check trap
configuration.
host.
l Run the display snmp-agent inform [ host-name host-name | address udp-domain ip-
address [ vpn-instance vpn-instance-name ] params securityname { security-name |
cipher security-name } ] command to check inform parameters of all target hosts.
l Run the display snmp-agent notify-filter-profile [ profile-name ] command to check the
l Run the display snmp-agent notification-log [ info | logtime starttime to endtime | size
size ] command to view trap logs saved in the trap log buffer.
----End
Running SNMPv3
Before configuring a device to communicate with an NMS by running SNMPv3, configure a
19
Procedure
When you configure the device to communicate with the NMS using SNMPv3, Configuring
Basic SNMPv3 Functions is mandatory and optional steps can be performed in any sequence.
devices.
the NMS.
NMS.
procedure described in Configuring the Trap Function.
1.6.1 Configuring Basic SNMPv3 Functions
Context
For the configuration of basic SNMP functions, Step 1, Step 5, Step 6, Step 7 and Step 9 are
When you configure a destination IP address for traps and error codes sent from the managed
devices, configure the trap or inform function as required.
l The traps sent by the managed device do not need to be acknowledged by the NMS.
l The informs sent by the managed device need to be acknowledged by the NMS. If no
acknowledgement message from the NMS is received within a specified time period, the
managed device resends the inform until the number of retransmissions reaches the
maximum.
When the managed device sends an inform, it records the inform in the log. If the NMS
and link between the NMS and managed device recovers from a fault, the NMS can still
learn the inform sent during the fault occurrence and rectification.
In this regard, informs are more reliable than traps, but the device may need to buffer a lot of
informs because of the inform retransmission mechanism and this may consume many memory
resources. If the network is stable, using traps is recommended. If the network is unstable and
the device's memory capacity is sufficient, using inform is recommended.
Precaution
The security levels from the highest to the lowest must be trap host security, user security, and
user group security.
The security level description is as follows:
l Level 1: privacy (authentication and encryption)
20
l Level 2: authentication (only authentication)
l Level 3: none (no authentication and no encryption)
If the security level of a user group is level 1, the security levels of user and trap host must be
level 1. If the security level of a user group is level 2, the security levels of user and trap host
can be level 1 or level 2.
Procedure
Step 1 Run:
system-view
snmp-agent
The SNMP version is configured.
SNMPv3 is enabled by default; therefore, this step is optional.
snmp-agent local-engineid engineid
An engine ID is set for the local SNMP entity.
By default, the device automatically generates an engine ID using the internal algorithm. The
engine ID is composed of enterprise ID+device information.
If the local engine ID is set or changed, the existing SNMPv3 user will be deleted.
Step 5 Run:
snmp-agent group v3 group-name [ authentication | privacy ]
An SNMPv3 user group is configured.
If the network or network devices are in an insecure environment (for example, the network is
vulnerable to attacks), authentication or privacy can be configured in the command to enable
data authentication or privacy. By default, the created SNMP group is neither authenticated nor
encrypted.
Step 6 Run:
snmp-agent usm-user v3 user-name group-name [ authentication-mode { md5 | sha }
password [ privacy-mode { 3des168 | aes128 | aes192 | aes256 | des56 } encrypt-
password ] ] [ acl { acl-number | acl-name } ]
A user is added to the SNMPv3 user group.
NOTE
AES128 and AES256 algorithm are recommended to improve data transmission security.
21
After a user is added to the user group, the NMS that uses the name of the user can access the
objects in the ViewDefault view (OID: 1.3.6.1). If the local engine ID is set or changed, the
existing SNMPv3 user will be deleted.
If authentication and privacy have been enabled for the user group, the following authentication
and privacy modes can be configured for the data transmitted on the network.
Step 7 Choose one of the following commands as needed to configure a destination IP address of traps
and code errors sent from the device.
l To configure a destination IP address of traps and error codes, run:
snmp-agent target-host [ host-name host-name ] trap address udp-domain ip-
*
params securityname security-name [ v3
[ authentication | privacy ] | private-netmanager | ext-vb | notify-filter-
profile profile-name ]
*
l To configure a destination IP address of informs and error codes, run:
snmp-agent target-host [ host-name host-name ] inform address udp-domain ip-
*
params securityname security-name v3
[ authentication | privacy ][ ext-vb | notify-filter-profile profile-name ]
*
NOTE
Ensure that the security-name value is the same as the created user name; otherwise, the NMS cannot access
the device.
Step 9 Run:
commit
----End
Context
When multiple NMSs in the same SNMPv3 user group manage one device, perform this
Scenario Steps
All NMSs in this SNMPv3 user
group have the right of the
ViewDefault view.
No action required
22
Scenario Steps
Specified NMSs in this SNMPv3
user group have the right of the
ViewDefault view.
Step 1, Step 2, Step 4, Step 7 (based on the user group)
Step 1, Step 5, Step 6, Step 7 (based on the user)
Step 1, Step 2, Step 4, Step 5, Step 6, Step 7 (based on
the user group and user)
All NMSs in this SNMPv3 user
group manage specified objects
on the managed devices.
Specified NMSs in this SNMPv3
user group manage specified
objects on the managed devices.
Step 1, Step 2, Step 3, Step 4, Step 7 (based on the user
group)
Step 1, Step 3, Step 4, Step 5, Step 6, Step 7 (based on
the user)
Step 1, Step 2, Step 3, Step 4, Step 5, Step 6, Step 7
(based on the user group and user)

NOTE
Procedure
Step 1 Run:
system-view
Step 2 Run the following command to configure an ACL for an SNMP user group to filter the NMS
that does not match the ACL.
1. Run:
2. Run:
| any }
3. Run:
quit
Step 3 Run:
23
Step 4 Run:
snmp-agent group v3 group-name [ authentication | privacy ] [ read-view read-view
| write-view write-view | notify-view notify-view ]
*
[ acl { acl-number | acl-
name } ]
The write-read right is configured for a user group.
By default, the read-only view of an SNMP group is the ViewDefault view, and the names of
the read-write view and inform view are not specified.
To configure the NMS to receive traps or informsspecified by notify-view, you must first
configure the destination host for receiving traps.
NOTE
local device.
Step 5 Run the following command to configure an ACL for users in the SNMP user group to filter the
NMS that does not match the ACL.
1. Run:
2. Run:
| any }
3. Run:
quit
Step 6 Run:
snmp-agent usm-user v3 user-name group-name [ authentication-mode { md5 | sha }
password [ privacy-mode { 3des168 | aes128 | aes192 | aes256 | des56 } encrypt-
password ] ] [ acl { acl-number | acl-name } ]
Authentication and encryption are configured for SNMPv3 users in the specified user group.
l To allow all NMSs using the same SNMPv3 user name to access the agent, omit the parameter
acl.
l To allow specified NMSs to use this user name to access the agent, configure the parameter
acl.
NOTE
local device.
Step 7 Run:
commit
----End
24
Follow-up Procedure
1.6.3 (Optional) Configuring the Trap/Inform Function
Context
Procedure
Step 1 Run:
system-view
l Run:
l Run:
Run:
is as follows:
1. Run:
2. Run:
25
3. Run:
quit
Step 3 Run:
Step 4 Configure trap function parameters based on the trap usage or inform usage selected during the
configuration of basic SNMPv3 functions.
Set trap parameters.
l Run:
After the source interface is specified, its IP address becomes the source IP address of traps.
Configuring the IP address of the local loopback interface as the source interface is
recommended, which can ensure device security.
The source interface specified on the switch for traps must be consistent with that specified
on the NMS; otherwise, the NMS does not accept the traps sent from the switch.
Set inform parameters.
1. Run:
snmp-agent inform { { timeout seconds | resend-times times | pending number }
*
| { timeout seconds | resend-times times }
*
[ host-name host-name | address
udp-domain ip-address [ vpn-instance vpn-instance-name ] params securityname
{ security-name | cipher security-name } ] }
The timeout period for waiting for Inform ACK messages, number of inform
retransmissions, and allowable maximum number of informs to be acknowledged are set.
If the network is unstable, you need to specify the number of inform retransmissions and
allowable maximum number of informs to be acknowledged when you set a timeout period
for waiting for Inform ACK messages. By default, the timeout period for waiting for Inform
ACK messages is 15 seconds; the number of inform retransmissions is 3; the allowable
maximum number of informs waiting to be acknowledged is 39.
2. Run:
snmp-agent notification-log enable
The alarm log function is enabled.
If the NMS and managed device cannot communicate because of a link failure, the managed
device no longer sends Inform messages but keeps recording alarm logs. When the link
recovers, the destination host synchronizes the recorded alarm logs with the managed
device.
After the alarm log function is enabled, only Inform messages are recorded, and Trap
messages are not recorded.
By default, the alarm log function is disabled.
3. Run:
snmp-agent notification-log { global-ageout ageout | global-limit limit }
*
The aging time of alarm logs and the maximum pieces of alarm logs in the log buffer are
set.
26
By default, the aging time of the alarm logs is 24 hours. If the aging time expires, the alarm
logs are automatically deleted.
By default, the log buffer can store a maximum of 500 alarm logs. If the number of alarm
logs exceeds 500, the NMS deletes alarm logs from the earliest one.
Step 5 Run:
commit
----End
Packets
Procedure
Step 1 Run:
system-view
Step 2 Run:
bytes.
Step 3 Run:
commit
----End
Prerequisites
The configurations of basic SNMPv3 functions are complete.
Procedure
l Run the display snmp-agent usm-user [ engineid engineid | group group-name |
username user-name ]
*
command to check user information.
version.
l Run the display acl { acl-number | name acl-name | all } command to check the ACL rules.
27
MIB files.
switch.
l Run the display current-configuration | include trap command to check trap
configuration.
host.
l Run the display snmp-agent inform [ host-name host-name | address udp-domain ip-
address [ vpn-instance vpn-instance-name ] params securityname { security-name |
cipher security-name } ] command to check inform parameters of all target hosts or a
specified target host and information about host statistics.
l Run the display snmp-agent notify-filter-profile profile-name command to check the
l Run the display snmp-agent notification-log [ info | logtime starttime to endtime | size
size ] command to view trap logs saved in the trap log buffer.
----End
1.7 Maintaining SNMP
This chapter describes how to monitor SNMP running status after the SNMP configuration is
complete.
1.7.1 Checking the Statistics About SNMP Packets
Procedure
l Run:
display snmp-agent statistics
The statistics about SNMP messages are displayed.
----End
1.8 SNMP Configuration Examples
This section provides several examples for configuring SNMP. The configuration roadmap in
the examples helps you understand the configuration procedures. Each configuration example
provides information about the networking requirements and configuration roadmap.
28
1.8.1 Example for Configuring a Device to Communicate with an
NM Station by Using SNMPv1
Networking Requirements
As shown in Figure 1-1, NMS1 and NMS2 monitor devices on the network. The network is
small and has high security, devices are configured to use SNMPv1 to communicate with the
NMSs.
A switch is added on the network for expansion and monitored by the NMSs. Users want to
monitor the switch using current network resources and quickly locate and troubleshoot faults
on the switch. The NMS needs to manage objects excluding the ISIS object on the switch.
Figure 1-1 Networking diagram for configuring a device to communicate with an NMS by using
SNMPv1
1.1.2.1/24
10GE1/0/1
Switch
1.1.1.1/24
1.1.1.2/24
NMS2
IP Network
NMS1
Configuration Roadmap
SNMPv1 can be used after a device is added on the user network. To reduce the load of the
NMS, configure NMS2 to monitor the switch and NMS1 not to monitor the switch.
The configuration roadmap is as follows:
1. Configure the SNMP version of the switch as SNMPv1.
2. Configure the user access permission to allow NMS2 to manage objects excluding the ISIS
object on the switch.
3. Configure the trap function for the switch to deliver traps generated on the switch to NMS2.
Only modules that are enabled by default can deliver traps, which helps locate traps and
prevent unwanted traps.
4. Configure contact information for the switch administrator. In this way, upon detecting a
fault on the switch, the NMS administrator then can contact the nearest device administrator
to quickly locate and troubleshoot the fault.
5. Configure the NMS2.
Procedure
Step 1 Configure available routes between the switch and the NMSs. Details for the configuration
procedure are not provided here.
29
Step 2 Enable the SNMP agent.
<HUAWEI> system-view
[~HUAWEI] snmp-agent
[~HUAWEI] commit
Step 3 Configure the switch to run SNMPv1.
[~HUAWEI] snmp-agent sys-info version v1
[~HUAWEI] commit
Step 4 Configure the NMSs access rights.
# Configure an ACL to allow NMS2 to manage and disable NMS1 from managing the switch.
[~HUAWEI] acl 2001
[~HUAWEI-acl4-basic-2001] rule 5 permit source 1.1.1.2 0.0.0.0
[~HUAWEI-acl4-basic-2001] rule 6 deny source 1.1.1.1 0.0.0.0
[~HUAWEI-acl4-basic-2001] commit
[~HUAWEI-acl4-basic-2001] quit
# Configure a MIB view and allow NMS2 to manage every MIB object except ISIS on the
switch.
[~HUAWEI] snmp-agent mib-view excluded allextisis 1.3.6.1.3.37
[~HUAWEI] commit
# Configure the community name and apply the ACL and MIB views.
[~HUAWEI] snmp-agent community write adminnms2 mib-view allextisis acl 2001
[~HUAWEI] commit
Step 5 Configure the trap function.
[~HUAWEI] snmp-agent target-host host-name NMS2 trap address udp-domain 1.1.1.2
params securityname adminnms2
[~HUAWEI] commit
Step 6 Configure the contact information of the equipment administrator.
[~HUAWEI] snmp-agent sys-info contact call Operator at 010-12345678
[~HUAWEI] commit
Step 7 Configure NMS2.
Configure the read-and-write community name on the SNMPv1 NMS. For details about the
NMS configuration, see the related NMS manual.
NOTE
Keep the authentication parameters on the NMS the same as those on the device; If the parameters are
inconsistent, the NMS cannot manage devices.
Step 8 Verify the configuration.
After the configuration is complete, run the following commands to verify that the configuration
has taken effect.
# Check the configured SNMP version.
[~HUAWEI] display snmp-agent sys-info version
SNMP version running in the system:
SNMPv1 SNMPv3
# Check information about the SNMP community name.
<HUAWEI> display snmp-agent community
Community name: %@%@emYDL$qPUTma0F4MK#[N"SJA)>9u=!60s,lX*DNyV,Y(BYPKv3-n619,}
>vf}EBy$(d!w]TQ%@%@
Group name:SnmpCommunity1[55062]
30
Acl:2001
Storage-type: nonVolatile
# Check the configured ACL.
<HUAWEI> display acl 2001
Basic ACL 2001, 2 rules
Acl's step is 5
rule 5 permit source 1.1.1.2 0 (0 times matched)
rule 6 deny source 1.1.1.1 0 (0 times matched)
# Check the MIB view.
<HUAWEI> display snmp-agent mib-view viewname allextisis
View name:allextisis
MIB Subtree: isisMIB
Subtree mask: FC(Hex)
View Type: excluded
View status: active
# Check the target host.
<HUAWEI> display snmp-agent target-host
Target-host NO. 1
-----------------------------------------------------------
Host-name : NMS2
IP-address : 1.1.1.2
Source interface : -
VPN instance : -
Security name : %$%$ng@e@0{jJ!KusVUg$R*@"_VM%$%$
Port : 162
Type : trap
Version : v1
Level : No authentication and privacy
NMS type : NMS
With ext-vb : No
Notification filter profile name : -
-----------------------------------------------------------
# Check the contact information of the equipment administrator.
<HUAWEI> display snmp-agent sys-info contact
The contact person for this managed node:
call Operator at 010-12345678
----End
Configuration Files
Configuration file of the switch
#
acl number 2001
rule 5 permit source 1.1.1.2 0
rule 6 deny source 1.1.1.1 0
#
interface Vlanif100
ip address 1.1.2.1 255.255.255.0
#
interface 10GE1/0/1
port link-type trunk
port trunk allow-pass vlan 100
#
ospf 1
area 0.0.0.0
network 1.1.2.0 0.0.0.255
#
snmp-agent
31
snmp-agent local-engineid 800007DB03360102101100
snmp-agent sys-info contact call Operator at 010-12345678
snmp-agent sys-info version v1 v3
snmp-agent community write cipher %@%@emYDL$qPUTma0F4MK#[N"SJA)>9u=!60s,lX*DNyV,Y
(BYPKv3-n619,}>vf}EBy$(d!w]TQ%@%@ mib-view allextisis acl 2001
snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname cipher %
$%$ng@e@0{jJ!KusVUg$R*@"_VM%$%$
snmp-agent mib-view excluded allextisis isisMIB
#
return
NM Station by Using SNMPv2c
large and has high security, devices are configured to use SNMPv2c to communicate with NMSs.
A switch is added on the network for expansion and monitored by the NMSs.
Users want to monitor the switch using current network resources and quickly locate and
troubleshoot faults on the switch. The NMS needs to manage objects excluding the ISIS object
on the switch.
SNMPv2c
1.1.2.1/24
10GE1/0/1
Switch
1.1.1.1/24
1.1.1.2/24
NMS2
NMS1
IP Network
SNMPv2c can still be used after a device is added on the user network. To reduce the load of
the NMS, configure NMS2 to monitor the switch and NMS1 not to monitor the switch.
1. Configure the SNMP version of the switch as SNMPv2c.
2. Configure the user access permission to allow NMS2 to manage objects excluding the ISIS
object on the switch.
3. Configure the inform function for the switch to deliver traps generated on the switch to
NMS2. Only modules that are enabled by default can deliver traps, which helps locate traps
and prevent unwanted traps.
32
Procedure
Step 2 Enable the SNMP agent.
[~HUAWEI] commit
Step 3 Configure the switch to run SNMPv2c.
[~HUAWEI] snmp-agent sys-info version v2c
[~HUAWEI] commit
[~HUAWEI] acl 2001
[~HUAWEI-acl-basic-2001] rule 5 permit source 1.1.1.2 0.0.0.0
[~HUAWEI-acl-basic-2001] rule 6 deny source 1.1.1.1 0.0.0.0
[~HUAWEI-acl-basic-2001] commit
[~HUAWEI-acl-basic-2001] quit
# Configure the MIB view and configure NMS2 to manage objects excluding the ISIS object.
[~HUAWEI] commit
# Configure the community name and apply the ACL and MIB views.
[~HUAWEI] snmp-agent community write adminnms2 mib-view allextisis acl 2001
[~HUAWEI] commit
[~HUAWEI] snmp-agent target-host host-name NMS2 inform address udp-domain 1.1.1.2
params securityname adminnms2 v2c
[~HUAWEI] snmp-agent inform timeout 5 resend-times 6 pending 7
[~HUAWEI] commit
[~HUAWEI] commit
Step 7 Configure NMS2.
Configure the read-and-write community name on the SNMPv2 NMS. For details about the
NMS configuration, see the related NMS manual.
NOTE
has taken effect.
33
SNMPv2c SNMPv3
# Check information about the SNMP community name.
<HUAWEI> display snmp-agent community
Community name: %@%@emYDL$qPUTma0F4MK#[N"SJA)>9u=!60s,lX*DNyV,Y(BYPKv3-n619,}
>vf}EBy$(d!w]TQ%@%@
Group name:SnmpCommunity1[55062]
Acl:2001
Acl's step is 5
View name: allextisis
View Type: excluded
View status: active
Target-host NO. 1
-----------------------------------------------------------
Host-name : NMS2
VPN instance : -
Security name : %$%$ng@e@0{jJ!KusVUg$R*@"_VM%$%$
Port : 162
Type : inform
Version : v2c
NMS type : NMS
With ext-vb : No
-----------------------------------------------------------
----End
Configuration Files
#
acl number 2001
#
34
interface Vlanif100
ip address 1.1.2.1 255.255.255.0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 1.1.2.0 0.0.0.255
#
snmp-agent
snmp-agent inform timeout 5
snmp-agent inform resend-times 6
snmp-agent inform pending 7
snmp-agent sys-info version v2c v3
snmp-agent community write cipher %@%@emYDL$qPUTma0F4MK#[N"SJA)>9u=!60s,lX*DNyV,Y
(BYPKv3-n619,}>vf}EBy$(d!w]TQ%@%@ mib-view allextisis acl 2001
snmp-agent target-host inform address udp-domain 1.1.1.2 params securityname cipher
%$%$ng@e@0{jJ!KusVUg$R*@"_VM%$%$ v2c
#
return
NM Station by Using SNMPv3
large and has high security, devices are configured to use SNMPv3 to communicate with NMSs
and configured with authentication and encryption. A switch is added on the network for
expansion and monitored by the NMSs.
Users want to monitor the switch using current network resources and quickly locate and
troubleshoot faults on the switch. The NMS needs to manage objects excluding the ISIS object
on the switch.
SNMPv3
1.1.2.1/24
10GE1/0/1
Switch
1.1.1.1/24
1.1.1.2/24
NMS2
NMS1
IP Network
SNMPv3 can still be used after a device is added on the user network. To reduce the load of the
NMS, configure NMS2 to monitor the switch and NMS1 not to monitor the switch.
35
1. Configure the SNMP version of the switch as SNMPv3.
2. Configure user access rights to allow NMS2 to manage nodes excluding ISIS on the
switch.
3. Configure the trap function for the switch to deliver traps generated on the switch to NMS2.
Only modules that are enabled by default can deliver traps, which helps locate traps and
prevent unwanted traps.
Procedure
Step 2 Configure the SNMP agent.
[~HUAWEI] commit
Step 3 Configure the switch to run SNMPv3.
[~HUAWEI] snmp-agent sys-info version v3
[~HUAWEI] commit
[~HUAWEI] acl 2001
[~HUAWEI-acl4-basic-2001] rule 5 permit source 1.1.1.2 0.0.0.0
[~HUAWEI-acl4-basic-2001] rule 6 deny source 1.1.1.1 0.0.0.0
[~HUAWEI-acl4-basic-2001] commit
[~HUAWEI-acl4-basic-2001] quit
# Configure a MIB view.
[~HUAWEI] commit
# Configure an SNMPv3 user group and add a user to the group, and configure authentication
for the NMS administrator and privacy for the data transmitted between the switch and NMS2.
[~HUAWEI] snmp-agent usm-user v3 nms2-admin admin authentication-mode md5 abc123456
privacy-mode des56 123456abc
[~HUAWEI] snmp-agent group v3 admin privacy write-view allextisis acl 2001
[~HUAWEI] commit
[~HUAWEI] snmp-agent target-host host-name NMS2 trap address udp-domain 1.1.1.2
params securityname nms2-admin v3 privacy
[~HUAWEI] commit
[~HUAWEI] commit
Step 7 Configure the NMS.
36
You need to set the user name and security level for the NMS using SNMPv3. You can set the
security level by specifying the authentication mode, authentication password, encryption mode,
and encryption password. For details about the NMS configuration, see the related NMS manual.
NOTE
has taken effect.
SNMPv3
# Check the user group information.
<HUAWEI> display snmp-agent group admin
Group name: admin
Security model: USM privacy
Readview: ViewDefault
Writeview: allextisis
Notifyview :<no specified>
Acl:2001
# Check the user information.
<HUAWEI> display snmp-agent usm-user
User name: nms2-admin
Engine ID: 800007DB0300259E0370C3 active
Authentication Protocol: md5
Privacy Protocol: aes128
Group name: admin
Acl's step is 5
View name: allextisis
View Type: excluded
View status: active
Target-host NO. 1
----------------------------------------------------------------------
Host-name : NMS2
VPN instance : -
37
Security name : nms2-admin
Port : 162
Type : trap
Version : v3
NMS type : NMS
With ext-vb : No
--------------------------------------------------------------------
----End
Configuration Files
#
acl number 2001
#
interface Vlanif100
ip address 1.1.2.1 255.255.255.0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 1.1.2.0 0.0.0.255
#
snmp-agent
snmp-agent group v3 admin privacy write-view allextisis acl 2001
snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname nms2-
admin v3 privacy
snmp-agent usm-user v3 nms2-admin admin authentication-mode md5 %$%$-Kac&A\]
wOi0mMN*Ns:L"tkb%$%$ privacy-mode aes128 %$%$"Omo=_P#(0b'4D"k7d*/"xof%$%$
#
return
38
2 RMON Configuration
About This Chapter
Remote Network Monitoring (RMON), defined by IETF, is a widely used network management
protocol. It provides packet statistics and alarm functions for Ethernet interfaces. The
management devices use RMON to remotely monitor and manage network elements.
2.1 RMON Overview
RMON implementation is based on SNMP and uses the same network management station
(NMS) as SNMP to manage network elements.
2.2 RMON Supported by the Device
Before configuring RMON, understand concepts of four groups (statistics, history, alarm, and
event).
2.3 Configuring RMON
RMON collects traffic statistics and monitors network status on the specified network segment.
2.4 Configuration Example
This section provides configuration examples for RMON.
Configuration Guide - Network Management 2 RMON Configuration
39
2.1 RMON Overview
RMON implementation is based on SNMP and uses the same network management station
(NMS) as SNMP to manage network elements.
RMON
SNMP is a widely used network management protocol. It collects statistics about network
communication by using the agent software embedded in the managed devices. The NMS polls
the agent to provide network communication information. The agent then searches the
Management Information Base (MIB) and returns the required information to the NMS. The
NMS can manage the network based on returned information. The MIB counter only records
the statistics, but cannot analyze history information about routine communication. To display
traffic volume and changes on a whole day, the NMS has to keep on polling and analyze network
traffic based on the obtained information.
SNMP polling has the following disadvantages:
l Occupies a large number of network resources. Polling generates many communication
packets. On a large-sized network, congestion may occur or even the network is blocked.
Therefore, SNMP is not applicable to large-sized networks and cannot recycle large amount
of data, such as routing information.
l Increases the burden of network administrators. The network administrators are responsible
for collecting all data using the NMS software. It is difficult for an administrator to monitor
more than three network segments.
IETF develops RMON to improve usability of network management information and lighten
the burden on the NMS and network administrators. Compared with SNMP, RMON is more
applicable to large-sized networks and can monitor traffic on one or multiple network segments.
The characteristics of RMON are as follows:
l SNMP is the basis of RMON, and RMON is an enhancement of SNMP. RMON is
implemented based on the SNMP structure and compatible with SNMP. It consists of NMS
and agents. Network administrators can use the SNMP NMS to implement RMON without
additional training.
l RMON enables SNMP to monitor remote network devices actively and effectively.
According to RMON, a managed device actively sends a trap to the NMS when the alarm
threshold is reached. The NMS does not need to perform polling to obtain MIB variables
so that communication traffic between the NMS and managed device is reduced. Therefore,
RMON can easily and efficiently manage large-sized networks.
RMON defines multiple monitors to collect network management information in either of the
following ways:
l The NMS obtains management information directly from the RMON probe and controls
network resources. This allows the NMS to obtain all RMON MIB information.
l A RMON agent is embedded into a network device, such as a switch, so that the device
can provide the RMON probe function. The NMS uses basic SNMP commands to exchange
data with the RMON agent and collect network management information. Due to the
limitation on resources, the NMS can only obtain information about statistics, history,
alarms, and events.
40
Huawei devices have embedded RMON agent. The management device can obtain information
including traffic volume, error packet statistics, and performance statistics of the entire network
segment connected to the interfaces on the managed devices.
2.2 RMON Supported by the Device
Before configuring RMON, understand concepts of four groups (statistics, history, alarm, and
event).
RMON
RMON provides packet statistics and alarm functions. The management devices use RMON to
remotely monitor and manage network elements.
RMON uses statistics group and history group to provide Ethernet statistics and history statistics
functions.
l Ethernet statistics (statistics group in RMON MIB): collects basic statistics on each
monitored network. The system keeps on collecting traffic statistics and distribution of each
type of packets on a network segment. Additionally, the system can count the number of
error packets of different types, collisions, CRC error packets, undersized (or large) packets,
broadcast and multicast packets, bytes received, and packets received.
l History statistics (history group in RMON MIB): periodically samples and records network
statistics. The system can periodically collect statistics on each type of traffic, including
bandwidth usage, number of error packets, and total number of packets.
RMON alarm functions include event definition function and alarm threshold setting function.
l Event definition (event group in RMON MIB): controls the events and notifications sent
from the device and provides all events related to RMON agent. When an event occurs, the
system records a log or sends a trap to the NMS.
l Alarm threshold setting (alarm group in RMON MIB): monitors the specified alarm
variables (OID of an object). Based on the user-defined thresholds and sampling time, the
system periodically obtains the specified alarm variables. When the alarm variables values
reach or exceed the rising threshold, a rising threshold alarm event is triggered. When the
alarm variables values reach or fall below the falling threshold, a falling threshold alarm
event is triggered. The RMON agent records the monitored status in log or sends a trap to
the NMS.
RMON standard (RFC 2819) defines multiple RMON groups. The switch supports the statistics,
history, alarm, and event groups. Details about the groups are as follows:
l Statistics group
The statistics group keeps on collecting statistics on each type of traffic on Ethernet
interfaces and records statistics results in the etherStatsTable for later retrieval. Traffic
statistics include the number of network collisions, CRC error packets, undersized (or large)
data packets, broadcast packets, multicast packets, received bytes, and received packets.
After a statistics entry is created on an interface, the statistics group starts collecting
statistics on the packets. The statistics are accumulated.
l History group
The history group periodically collects network status statistics and stores them for future
use.
41
The history group provides two tables:
historyControlTable: sets control information such as the sampling interval.
etherHistoryTable: stores network statistics collected by the history group and provides
the network administrator with history statistics such as the traffic on a network segment,
error packets, broadcast packets, bandwidth usage, and collisions.
l Event group
The defined events are used for the configuration options of alarm group. When alarm
conditions are met, an event is triggered. RMON event management is to add events to the
specified rows in the event table, and the following options are supported:
log: only send log
trap: only send trap to the NMS
log-trap: send both log and trap
none: take no action
l Alarm group
An alarm group presets a set of thresholds for alarm variables, which can be objects in a
local MIB. Based on the user-defined alarmTable, the system periodically obtains the
specified alarm variables. When the alarm variables values reach or exceed the rising
threshold, a rising threshold alarm event is triggered. When the alarm variables values reach
or fall below the falling threshold, the system takes actions according to the action
configuration.
2.3 Configuring RMON
RMON collects traffic statistics and monitors network status on the specified network segment.
Before configuring RMON, complete the following tasks:
l Configuring Ethernet interface parameters
l Configuring basic SNMP functions
Configuration Process
The RMON statistics function and RMON alarm function can be configured in any sequence.
However, if the alarm variables configured in RMON alarm function are MIB variables defined
in the statistics group or history group, the Ethernet statistics function or history statistics
function must be configured on the monitored Ethernet interface first. Otherwise, alarm entries
cannot be created.
2.3.1 Configuring RMON Statistics Functions
Context
RMON statistics functions include Ethernet statistics function and history statistics function,
which apply to different scenarios:
l To keep on collecting traffic statistics on an Ethernet interface, configure the Ethernet
statistics function. Ethernet statistics include the number of network collisions, CRC error
42
packets, undersized (or large) data packets, broadcast packets, multicast packets, received
bytes, and received packets.
l To store the statistics on the specified interface for later retrieval, configure the history
statistics function. History statistics include bandwidth usage, number of error packets, and
total of packets.
Procedure
l Configuring Ethernet statistics
1. Run:
system-view
2. Run:
interface { GE | 10GE | 40GE } interface-number
NOTE
The CE6800 does not support GE interfaces.
3. Run:
rmon-statistics enable
RMON statistics function is enabled on an interface.
4. Run:
rmon statistics entry-number [ owner owner-name ]
A statistics table is created and an entry is added to the table.
5. Run:
commit
l Configuring history statistics
1. Run:
system-view
2. Run:
interface { GE | 10GE | 40GE } interface-number
NOTE
3. Run:
RMON statistics function is enabled on an interface.
4. Run:
rmon history entry-number buckets number interval sampling-interval
[ owner owner-name ]
A history control table is created and an entry is added to the table.
43
5. Run:
commit
----End
2.3.2 Configuring RMON Alarm Functions
Context
RMON alarm functions include event definition function and alarm threshold setting function.
To monitor the system running status, configure the alarm threshold setting function. When an
error occurs in the system, the related event is triggered. The event definition function can
determine whether to log the event or send a trap to the NMS.
NOTE
If the alarm variables configured in RMON alarm function are MIB variables defined in the statistics group or
history group, the Ethernet statistics function or history statistics function must be configured on the monitored
Ethernet interface first.
Procedure
Step 1 Run:
system-view
Step 2 Run the rmon event entry-number [ description string ] { log | trap object | log-trap object |
none } [ owner owner-name ] command to create an event table and add an entry to the table.
snmp-agent trap enable feature-name rmon [ trap-name { fallingalarm |
risingalarm } ]
The trap function is enabled for the RMON module.
By default, all alarms for the RMON module are enabled. If only one or some event alarms need
to be enabled, run the snmp-agent trap enable feature-name rmon trap-name command.
Step 4 Run:
rmon alarmentry-number alarm-OID sampling-time { absolute | changeratio | delta }
rising-threshold threshold-value1 event-entry1 falling-threshold threshold-value2
event-entry2 [ startup-alarm { | rising | risingorfalling } ] [ owner owner-
name ]
An alarm table is created and an entry is added to the table.
Step 5 Run:
commit
----End
44
Prerequisites
The RMON configurations are complete.
Procedure
l Run the display rmon alarm [ entry-number ] command to view RMON alarm
configurations.
l Run the display rmon event [ entry-number ] command to view RMON event
configurations.
l Run the display rmon eventlog [ entry-number ] command to view details about RMON
event logs.
l Run the display rmon history [ GE interface-number | 10GE interface-number | 40GE
interface-number ] command to view RMON history sampling records.
NOTE
l Run the display rmon statistics [ GE interface-number | 10GE interface-number |
40GE interface-number ] command to view RMON Ethernet statistics.
NOTE
The RMON statistics are more detailed than the display interface command output.
l Run the display snmp-agent trap feature-name rmon all command to view the status of
all traps about the RMON module.
----End
2.4 Configuration Example
This section provides configuration examples for RMON.
2.4.1 Example for Configuring RMON
As shown in Figure 2-1, the subnet connected to 10GE1/0/1 on the switch needs to be monitored,
including
l Collecting real-time and history statistics on traffic and each type of packets
l Recording logs when the traffic volume per minute exceeds the threshold
l Monitoring broadcast and multicast traffic volume on the subnet and reporting alarm to the
NMS when the traffic volume exceeds the threshold
45
Figure 2-1 Networking diagram of RMON configuration
NMS
IP
Network
10GE1/0/2
VLANIF100
2.2.2.1/24
10GE1/0/1
VLANIF110
3.3.3.1/24
1.1.1.1/24
Switch
To collect real-time and history statistics on traffic and each type of packets, configure the
RMON statistics function. To report alarms to the NMS when traffic volume exceeds the
threshold, configure the RMON alarm function.
1. Assign IP addresses to interfaces of the switch.Configure a reachable route between the
switch and NMS.
2. Configure basic SNMP functions and enable the switch to send traps to the NMS.
3. Enable RMON statistics function and configure the statistics table and history control table.
4. Configure the event table, alarm table.
Procedure
Step 1 Configure IP addresses and reachable route for switch interfaces.
[~HUAWEI] vlan 100
[~HUAWEI-vlan100] quit
[~HUAWEI] interface vlanif 100
[~HUAWEI-Vlanif100] ip address 2.2.2.1 24
[~HUAWEI-Vlanif100] quit
[~HUAWEI] quit
[~HUAWEI] interface 10GE 1/0/2
[~HUAWEI-10GE1/0/2] port link-type trunk
[~HUAWEI-10GE1/0/2] port trunk pvid vlan 100
[~HUAWEI-10GE1/0/2] port trunk allow-pass vlan 100
[~HUAWEI-10GE1/0/2] quit
[~HUAWEI] vlan 110
[~HUAWEI-vlan110] quit
[~HUAWEI] interface vlanif 110
[~HUAWEI-Vlanif110] ip address 3.3.3.1 24
[~HUAWEI-Vlanif110] quit
[~HUAWEI] quit
[~HUAWEI-10GE1/0/1] port link-type trunk
[~HUAWEI-10GE1/0/1] port trunk pvid vlan 110
[~HUAWEI-10GE1/0/1] port trunk allow-pass vlan 110
[~HUAWEI] ospf
[~HUAWEI-ospf-1] area 0
[~HUAWEI-ospf-1-area-0.0.0.0] network 2.2.2.0 0.0.0.255
[~HUAWEI-ospf-1-area-0.0.0.0] network 3.3.3.0 0.0.0.255
[~HUAWEI-ospf-1-area-0.0.0.0] quit
[~HUAWEI-ospf-1] quit[~HUAWEI] commit
Step 2 Configure basic SNMP functions and enable the switch to send traps to the NMS.
46
# Configure SNMPv3 on the switch. Configure an SNMP user group admin and add a user nms-
admin to the user group.
[~HUAWEI]snmp-agent group v3 admin privacy
[~HUAWEI]snmp-agent usm-user v3 nms-admin admin authentication-mode md5 abc123456
privacy-mode des56 123456abc
# Enable SNMP to send traps.
[~HUAWEI] snmp-agent trap enable
# Specify the NMS that receives the traps.
[~HUAWEI] snmp-agent target-host trap address udp-domain 1.1.1.1 params
securityname nms-admin v3 privacy
Step 3 Configure statistics function.
# Enable the RMON statistics function on the interface.
[~HUAWEI-10GE1/0/1] rmon-statistics enable
[~HUAWEI-10GE1/0/1] commit
# Configure the statistics table.
NOTE
The interface enabled with the statistics function cannot be added to an Eth-Trunk.
[~HUAWEI-10GE1/0/1] rmon statistics 1 owner Test300
# Configure the history control table. Sample traffic on the subnet every 30 seconds and save
the latest 10 records
[~HUAWEI-10GE1/0/1] rmon history 1 buckets 10 interval 30 owner Test300
Step 4 Configure the alarm function.
# Configure the event table. Configure the switch to record logs for RMON event 1 and send
traps to the NMS for RMON event 2.
[~HUAWEI] rmon event 1 log owner Test300
[~HUAWEI] rmon event 2 description forUseofPrialarm trap public owner Test300
[~HUAWEI] commit
# Configure the alarm table. Set the sampling interval and the threshold for triggering event 1
(OID is 1.3.6.1.2.1.16.1.1.1.6.1).
[~HUAWEI] rmon alarm 1 1.3.6.1.2.1.16.1.1.1.6.1 30 absolute rising-threshold 500 1
falling-threshold 100 1 owner Test300
[~HUAWEI] commit
# View traffic volume on the subnet.
<HUAWEI> display rmon statistics 10GE 1/0/1
Statistics entry 1 owned by Test300 is valid.
Interface : 10GE1/0/1<ifEntry.402653698>
Received :
octets :142915224 , packets :1749151
broadcast packets :11603 , multicast packets:756252
undersize packets :0 , oversize packets :0
fragments packets :0 , jabbers packets :0
CRC alignment errors:0 , collisions :0
47
Dropped packet (insufficient resources):1795
Packets received according to length (octets):
64 :150183 , 65-127 :150183 , 128-255 :1383
256-511:3698 , 512-1023:0 , 1024-1518:0
# View the sampling records.
<HUAWEI> display rmon history 10GE 1/0/1
History control entry 1 owned by Test300 is valid
Samples interface : 10GE1/0/1<ifEntry.402653698>
Sampling interval : 30(sec) with 10 buckets max
Last Sampling time : 0days 00h:19m:43s.49th
Latest sampled values :
octets :654 , packets :0
broadcast packets :7 , multicast packets :0
undersize packets :6 , oversize packets :0
fragments packets :0 , jabbers packets :0
CRC alignment errors :0 , collisions :0
Dropped packet :0 , utilization :0
# View the RMON event configurations.
<HUAWEI> display rmon event
Event table 1 owned by Test300 is valid.
Description: null.
Will cause log when triggered, last triggered at 0days 00h:24m:10s.05th.
Description: forUseofPrialarm.
Will cause snmp-trap when triggered, last triggered at 0days 00h:26m:10s.05th.
# View the RMON alarm configurations.
<HUAWEI> display rmon alarm 1
Alarm table 1 owned by Test300 is valid.
Samples absolute value : 1.3.6.1.2.1.16.1.1.1.6.1
Sampling interval : 30(sec)
Rising threshold : 500(linked with event 1)
Falling threshold : 100(linked with event 1)
When startup enables : risingOrFallingAlarm
Latest value : 1975
# View the event logs.
<HUAWEI> display rmon eventlog
Generates eventLog 1.1 at 0days 00h:39m:30s.01th.
Description: The 1.3.6.1.2.1.16.1.1.1.6.1 defined in alarm table 1 is less than
or equal to 100 with alarm value 0. Alarm sample type is absolute.
----End
Configuration Files
#
vlan batch 100 110
#
interface Vlanif100
ip address 2.2.2.1 255.255.255.0
#
interface Vlanif110
ip address 3.3.3.1 255.255.255.0
#
interface 10GE1/0/2
port trunk pvid vlan 100
#
interface 10GE1/0/1
48
rmon statistics 1 owner Test300
rmon history 1 buckets 10 interval 30 owner Test300
#
ospf 1
area 0.0.0.0
network 2.2.2.0 0.0.0.255
network 3.3.3.0 0.0.0.255
#
snmp-agent
snmp-agent local-engineid 800007DB0300C020177602
snmp-agent group v3 admin privacy
snmp-agent target-host trap address udp-domain 1.1.1.1 params securityname nms-
admin v3 privacy
snmp-agent usm-user v3 nms-admin admin authentication-mode md5 %$%$BSjq-g0l:Z52@h/
D:+:*"qh_%$%$ privacy-mode des56 %$%$-h~)EBEr;%^3<3ERc%$%$
#
rmon event 1 description null log owner Test300
rmon event 2 description forUseofPrialarm trap public owner Test300
rmon alarm 1 1.3.6.1.2.1.16.1.1.1.6.1 30 absolute rising-threshold 500 1 falling-
threshold 100 1 owner Test300
#
#
return
49
3 NETCONF Configuration
About This Chapter
Network Configuration Protocol (NETCONF) provides a set of protocols for communication
between the Network Management System (NMS) and devices. The NMS can use NETCONF
to install, maintain, and delete the configuration of devices.
3.1 Overview
NETCONF provides mechanisms to install, maintain, and delete the configuration of devices
on distributed networks. For example, device configuration can be restored and new
configuration data can be added.
3.2 Establishing Communication Between the NMS and a Device Using NETCONF
To ensure proper communication between the network management system (NMS) and the
managed devices, enable the Secure Shell (SSH) service on the NETCONF agent and deploy
the NMS on the NETCONF manager.
3.3 Configuration Examples
The section provides an NETCONF configuration example, including networking requirements,
networking diagram, configuration roadmap, and configuration procedure.
Configuration Guide - Network Management 3 NETCONF Configuration
50
3.1 Overview
NETCONF provides mechanisms to install, maintain, and delete the configuration of devices
on distributed networks. For example, device configuration can be restored and new
configuration data can be added.
NETCONF Overview
The Simple Network Management Protocol (SNMP) has lagged behind carriers' demands for
better management (especially configuration management) of large-scale and complex
networks. The XML-based NETCONF has been introduced to provide the required
configuration management.
NETCONF is a network configuration and management protocol based on the Extensible
Markup Language (XML). NETCONF implements communication between clients and servers
using the Remote Procedure Calls (RPC) mechanism.
Table 3-1 describes the comparison between NETCONF and SNMP.
Table 3-1 Comparison between NETCONF and SNMP
Item SNMP NETCONF
Configur
ation
manage
ment
SNMP does not provide a
protection lock mechanism
when multiple users
perform operations on the
same configuration.
NETCONF provides a protection lock mechanism
to prevent operations performed by multiple users
from conflicting with each other.
Query Querying one or more
records in a table requires
multiple interaction
processes.
NETCONF can be used to directly query a record
on the system, and supports filtering of data
queries.
Extensib
ility
SNMP is not readily
extensible.
NETCONF offers good extensibility:
l NETCONF operations are defined in four
layers that are independent of each other.
Extensions to one layer have little effect on the
other layers.
l NETCONF's XML encoding format helps
expand the protocol's management capability
and system compatibility.
Security SNMPv3, released in 2002,
is the latest version of
SNMP. SNMPv3 uses self-
defined security parameters
that provide poor
extensibility.
NETCONF uses existing security protocols to
ensure network security, and is not specific to any
security protocols. NETCONF is more flexible
than SNMP in ensuring security.
NOTE
NETCONF prefers Secure Shell (SSH) as the transport
protocol and uses SSH to transmit XML information.

51
Applicable Environment
NETCONF ensures security and extensibility. When the NMS is used to manage network
devices, you can use NETCONF to ensure communication between the NMS and the devices.
As shown in Figure 3-1, the NMS is deployed on the NETCONF manager that functions as the
SSH client. The NETCONF agent functions as the SSH server that receives connection requests
from the SSH client. SSH is a security protocol at the application layer, enhancing the reliability
of NETCONF. In this networking, NETCONF is used to manage the configuration of the SSH
server.
Figure 3-1 Networking diagram for establishing communication between the NMS and a device
using NETCONF
IP network
NETCONF Manager
EMS/NMS
SSH
NETCONF Agent

3.2 Establishing Communication Between the NMS and a
Device Using NETCONF
To ensure proper communication between the network management system (NMS) and the
managed devices, enable the Secure Shell (SSH) service on the NETCONF agent and deploy
the NMS on the NETCONF manager.
3.2.1 Configuring VTY User Interfaces to Support SSH
Context
Currently, the device can use only the Secure Shell (SSH) protocol as the transport protocol of
NETCONF. Users can use NETCONF to establish a connection between the NETCONF
manager and NETCONF agent only when one or more VTY user interfaces support the SSH
protocol.
NOTE
Before configuring a user interface to support SSH, set the authentication mode of the user interface to
AAA. Otherwise, the protocol inbound ssh command does not take effect.
Procedure
Step 1 Run:
system-view
52
Step 2 Run:
user-interface vty first-ui-number [ last-ui-number ]
A VTY user interface view is displayed.
Step 3 Run:
authentication-mode aaa
AAA authentication is set.
Step 4 Run:
protocol inbound { ssh | all }
SSH is enabled on the VTY user interface.
By default, the system supports Telnet.
For the configuration of other attributes for a VTY user interface, see Configuring VTY User
Interfaces in the CloudEngine 6800&5800 Series Switches Configuration Guide - Basic
Configuration.
Step 5 Run:
commit
----End
3.2.2 Configuring an SSH User
Context
NETCONF requires SSH as its transport layer protocol. Before using NETCONF to manage
network devices, configure the user to log in to the device through SSH.
l SSH users can be authenticated in four modes: RSA, password, password-RSA, and All.
Password authentication depends on AAA. Before a user logs in to the device with password
or password-RSA authentication mode, a local user with the same user name must be
created in the AAA view.
l Configuring the system to generate a local RSA key pair is a key step for SSH login. If an
SSH user logs in to an SSH server in password authentication mode, configure the server
to generate a local RSA key pair. If an SSH user logs in to an SSH server in RSA
authentication mode, configure both the server and the client to generate local RSA key
pairs.
NOTE
Password-RSA authentication requires success of both password authentication and RSA authentication.
The All authentication mode requires success of either password authentication or RSA authentication.
Perform the following steps on the NETCONF agent (SSH server):
Procedure
Step 1 Run:
system-view
53
Step 2 Run:
ssh user user-name
An SSH user is created.
If password or password-RSA authentication is configured for the SSH user, create the same
SSH user in the AAA view and set the local user access type to SSH.
1. Run the aaa command to enter the AAA view.
2. Run the local-user user-name password [ irreversible-cipher irreversible-cipher-
password ] command to configure a local user name and a password.
3. Run the local-user user-name service-type ssh command to set the local user access type
to SSH.
4. Run the quit command to exit from the AAA view and enter the system view.
By default, a local user can use any access type. You can specify an access type to allow only
users configured with the specified access type to log in to the device.
Step 3 Run:
rsa local-key-pair create
A local RSA key pair is generated.
NOTE
l The rsa local-key-pair create command must be used to create a local RSA key pair before other SSH-
related configuration.
l After the key pair is generated, run the display rsa local-key-pair public command to view information
about the public key in the local key pair.
l To clear the local RSA key pair, run the rsa local-key-pair destroy command to destroy all local RSA
key-pairs, including the local key-pair and server key-pair.
Check whether all local RSA key pairs are destroyed after running the rsa local-key-pair destroy
command. The rsa local-key-pair destroy command configuration takes effect only once and therefore
will not be saved in the configuration file.
Step 4 Select either of the SSH user authentication modes listed in Table 3-2.
Table 3-2 SSH user authentication mode
SSH user
authentication
mode
Operation
Password
authentication
When local authentication or HWTACACS authentication is used:
l If there are only a few users, use password authentication.
Run the ssh user user-name authentication-type password
command to configure password authentication.
l If there are a large number of users, use default password
authentication to simplify configuration.
Run the ssh authentication-type default password command to
configure default password authentication.
54
SSH user
authentication
mode
Operation
RSA authentication 1. Run the ssh user user-name authentication-type rsa command to
configure RSA authentication.
2. Run the rsa peer-public-key key-name command to enter the
public key view.
3. Run the public-key-code begin command to enter the public key
edit view.
4. Enter hex-data to edit the public key.
NOTE
l In the public key edit view, only hexadecimal strings complying with
the public key format can be typed in. Each string is randomly generated
on an SSH client. For detailed operations, see manuals for SSH client
software.
l After entering the public key edit view, paste the RSA public key
generated on the client to the server.
5. Run the public-key-code end command to exit from the public key
edit view.
l Running the peer-public-key end command generates a key
only after a valid hex-data complying with the public key format
is entered.
l If the peer-public-key end command is used after the key key-
name specified in Step b is deleted in another window, the
system prompts a message, indicating that the key does not exist,
and the system view is displayed.
6. Run the peer-public-key end command to return to the system
view.
7. Run the ssh user user-name assign rsa-key key-name command to
assign the SSH user a public key.

Step 5 (Optional) Perform one or more operations as described in Table 3-3.
Table 3-3 Operations
Server
Parameter
Command Description
Configure the
interval at
which the key
pair of the SSH
server is
updated
Run the ssh server rekey-interval
interval command.
By default, the interval is 0,
indicating that the key is never
updated.
You can set an interval at which the
key pair of an SSH server is updated.
When the timer expires, the key pair
is automatically updated, improving
security.
55
Server
Parameter
Command Description
Configure the
timeout period
of SSH
authentication
Run the ssh server timeout
seconds command.
By default, the timeout period is 60
seconds.
If a user fails to log in when the
timeout period of SSH
authentication expires, the system
disconnects the current connection
to ensure the system security.
Configure the
number of
times that SSH
authentication
is retried
Run the ssh server authentication-
retries times command.
By default, SSH authentication
retries a maximum of 3 times.
The number of times that SSH
authentication is retried is set to
deny access of invalid users.
Configure
earlier SSH
version
compatibility
Run the undo ssh server
compatible-ssh1x disable
command.
By default, an SSH server running
SSH2.0 is compatible with SSH1.X.
To prevent clients running SSH1.3
to SSH1.99 from logging in, run the
ssh server compatible-ssh1x
disable command to disable support
for earlier SSH protocol versions.
There are two SSH versions:
SSH1.X (earlier than SSH2.0) and
SSH2.0. SSH2.0 has an extended
structure and supports more
authentication modes and key
exchange methods than SSH1.X.
SSH2.0 also supports more
advanced services such as SFTP.
Configure the
listening port
number of the
SSH server
Run the ssh server port port-
number command.
If a new listening port is set, the SSH
server cuts off all established
STelnet and SFTP connections, and
uses the new port number to listen
to connection requests. By default,
the listening port number is 22.
The default listening port number of
an SSH server is 22. Users can log
in to the device by using the default
listening port number. Attackers
may access the default listening
port, consuming bandwidth,
deteriorating server performance,
and causing authorized users unable
to access the server. After the
listening port number of the SSH
server is changed, attackers do not
know the new port number. This
effectively prevents attackers from
accessing the listening port and
improves security.
Configuring an
ACL on the
SSH server
Run the ssh server acl { acl-
number | name acl-name }
command.
This command specifies the clients
that can access the SSH server. This
configuration prevents
unauthorized users from accessing
the SSH server, ensuring data
security.
56
Server
Parameter
Command Description
Enabling the
keepalive
feature on the
SSH server
Run the ssh server keepalive
enable command.
By default, the keepalive feature is
disabled on the SSH server.
After this feature is enabled, the
SSH server returns keepalive
responses to an SSH client to check
whether the connection between
them is normal, facilitating fast fault
detection.

Step 6 Run:
ssh user username service-type snetconf
The service type of an SSH user is set to SNETCONF.
By default, the service type of an SSH user is none. That is, no service is supported.
NOTE
l To establish a NETCONF connection using the well-known port 22, an SSH user must set the service
type to SNETCONF.
l To establish a NETCONF connection using the well-known port 830, an SSH user does not need to
set the service type to SNETCONF.
The user can run the protocol inbound ssh port 830 command in the NETCONF view.
Step 7 Run:
commit
----End
3.2.3 Enabling NETCONF
Context
An NETCONF connection can be established between the NETCONF manager and the
NETCONF agent using the well-known port 22 only after NETCONF is enabled on the
NETCONF agent.
Procedure
Step 1 Run:
system-view
Step 2 Run:
snetconf server enable
NETCONF service is enabled.
By default, NETCONF is disabled on device.
Step 3 Run:
57
commit
----End
Follow-up Procedure
Set correct NETCONF parameters to ensure secure NETCONF session connections.
1. Run:
netconf
The NETCONF user interface view is displayed.
2. Perform one or more operations in Table 3-4 to set the desired NETCONF parameters.
Table 3-4 Server parameters
Server Parameter Operation Description
Maximum number
of NETCONF users
that the NETCONF
user interface
supports
max-sessions The default maximum number
of NETCONF users is 5.
To prevent unauthorized users
from logging in to the device
using NETCONF, set the
maximum number of
NETCONF users. After the
maximum number of
NETCONF users is reached,
subsequent users are not
allowed log in to the device.
This mechanism ensures
network management security.
Timeout period of
an idle NETCONF
connection
idle-timeout (NETCONF
user interface view)
The default timeout period is
10 minutes.
If no timeout period is set for
an idle NETCONF connection,
the idle NETCONF connection
cannot be released in time to be
used by other authorized users.

3. Run:
commit
3.2.4 Logging in to the NETCONF Agent Using the NMS
Context
The NMS can manage devices only when the NMS has connected to corresponding NEs and
can communicate with them.
58
Before deploying NEs, properly divide sub-networks. The physical topology must be easy for
routine maintenance in addition for showing the actual network structure.
For installation and maintenance of the NMS, see the relevant installation instruction and usage
guidelines.
Background
After NETCONF is configured to allow the NMS to remotely manage configuration of devices,
you can view detailed SSH session information (indicating that the NETCONF manager has
logged in to the NETCONF agent), and the capabilities that the NETCONF agent supports.
Procedure
l Run the display ssh user-information username command on the SSH server (NETCONF
agent) to check information about the SSH user on the NETCONF client.
l Run the display ssh server status command on the SSH server to check its global
configuration.
l Run the display ssh server session command on the SSH server to check information about
sessions between the SSH server and the SSH client (NETCONF manager).
l Run the display netconf capability command to view the capabilities that the NETCONF
agent supports.
----End
The section provides an NETCONF configuration example, including networking requirements,
networking diagram, configuration roadmap, and configuration procedure.
3.3.1 Example for Establishing Communication Between the NMS
and a Device Using NETCONF
NETCONF ensures security and extensibility. When the NMS is used to manage network
devices, you can use NETCONF to ensure communication between the NMS and the devices.
As shown in Figure 3-2, the NMS is deployed on the NETCONF manager that functions as the
SSH client. The NETCONF agent functions as the SSH server that receives connection requests
from and establishes the connection with the SSH client. SSH is a security protocol at the
application layer, enhancing the reliability of NETCONF. In this networking, NETCONF is used
to manage the configuration of the SSH server.
59
Figure 3-2 Networking diagram for establishing communication between the NMS and a device
using NETCONF
NETCONF Manager
Client 001
SSH Server
NETCONF Agent
NETCONF Manager
Client 002
MEth0/0/0
10.1.1.1/24

1. Configure an IP address for the management interface of the NETCONF agent so that there
are reachable Layer 3 routes between the client and server.
2. Configure virtual type terminal (VTY) user interfaces on the NETCONF agent to support
SSH so that SSH users can be managed and monitored with better connection security.
3. Deploy SSH on the NETCONF agent to improve NETCONF security.
a. Create an SSH user.
b. Create a local RSA key pair.
c. Configure an authentication mode for the SSH user.
d. Configure a service type for the SSH user.
4. Enable NETCONF to allow the client to connect to the server.
5. Deploy the NMS on the NETCONF manager to implement NMS-based network
management on the client.
6. Log in to the NETCONF agent using the NMS to manage the configuration remotely.
Procedure
Step 1 Configure an IP address for the management interface of the NETCONF agent.
[~HUAWEI] sysname netconf-agent
[~HUAWEI] commit
[~netconf-agent] interface meth 0/0/0
[~netconf-agent-meth0/0/0] ip address 10.1.1.1 24
[~netconf-agent-meth0/0/0] commit
[~netconf-agent-meth0/0/0] quit
Step 2 Configure the VTY user interface to support the SSH protocol.
[~netconf-agent] user-interface vty 0 4
[~netconf-agent-ui-vty0-4] authentication-mode aaa
[~netconf-agent-ui-vty0-4] protocol inbound ssh
60
[~netconf-agent-ui-vty0-4] commit
[~netconf-agent-ui-vty0-4] quit
Step 3 Deploy SSH on the NETCONF agent.
1. Create an SSH user.
# Create an SSH user named Client001 and set the user password to huawei123.
[~netconf-agent] ssh user client001
[~netconf-agent] aaa
[~netconf-agent-aaa] local-user client001 password irreversible-cipher
huawei123
[~netconf-agent-aaa] local-user client001 service-type ssh
[~netconf-agent-aaa] commit
[~netconf-agent-aaa] quit
2. Create a local RSA key pair.
[~netconf-agent] rsa local-key-pair create
The key name will be: netconf-agent_Host
The range of public key size is (512 ~ 2048).
NOTE: If the key modulus is greater than 512,
It will take a few minutes.
Input the bits in the modulus [default = 2048] : 512
[~netconf-agent] commit
After the local RSA key pair is created, run the display rsa local-key-pair public command
to view information about the public key in the local RSA key pair.
3. Configure an authentication mode for the SSH user.
[~netconf-agent] ssh user client001 authentication-type password
4. Configure a service type for the SSH user.
[~netconf-agent] ssh user client001 service-type snetconf
Step 4 Enable NETCONF on the NETCONF agent.
[~netconf-agent] snetconf server enable
Step 5 Deploy the NMS on the NETCONF manager.
For login to remote devices using the NMS, see the relevant usage guide of the NMS.
If a Huawei NMS is used, contact Huawei technical personnel for the NSM operation manual.
Step 6 Log in to the NETCONF agent from the NETCONF manager using the NMS.
For login to remote devices using the NMS, see the relevant usage guide of the NMS.
If a Huawei NMS is used, contact Huawei technical personnel for the NSM operation manual.
After the preceding configuration is complete, you can log in to the remote device using
NETCONF to manage its configuration remotely.
NOTE
All the following operations are performed on the NETCONF agent (SSH server).
# Run the display users command to view information about users who have logged in to the
NETCONF agent.
[~netconf-agent] display users
User-Intf Delay Type Network Address AuthenStatus AuthorcmdFlag
100 VTY 0 00:02:50 SSH 10.2.2.2 pass yes
Username : client001
61
# Run the display ssh user-information command to view SSH user information.
[~netconf-agent] display ssh user-information
--------------------------------------------------------------------------------
User Name : client001
Authentication-Type : password
User-public-key-name : -
Sftp-directory : -
Service-type : snetconf
--------------------------------------------------------------------------------
Total 1, 1 printed
Run the display ssh server status command to view global configuration of the SSH server.
-----------------------------------------------------------------------
SSH Version : 2.0
SSH authentication timeout (Seconds) : 60
SSH authentication retries (Times) : 3
SSH server key generating interval (Hours) : 0
SSH version 1.x compatibility : ENABLED
SSH server keepalive : DISABLED
SFTP server : DISABLED
STELNET server : DISABLED
SNETCONF server : ENABLED
SNETCONF server port(830) : DISABLED
SSH server DES : Disable
SSH server port : 22
ACL name :
ACL number :
ACL6 name :
ACL6 number :
SSH server source address : 0.0.0.0
-----------------------------------------------------------------------
# Run the display netconf capability command to view the capabilities that the NETCONF
agent supports.
----------------------------------
Capability Scope Version
----------------------------------
Base public 1.0
Writable-Running public 1.0
Candidate public 1.0
Distinct Startup public 1.0
Rollback on Error public 1.0
Sync private 1.0
Exchange private 1.0
Active private 1.0
Action private 1.0
Update private 1.0
Commit-Description private 1.0
----------------------------------
----End
Configuration file of the NETCONF agent
#
sysname netconf-agent
#
rsa peer-public-key 192.168.1.182
public-key-code begin
308188
028180
BFC74D30 A65080B1 51E3E266 E0E38BEE 45EA3FC9 E416FE34 710EDE6C 4E28A1F2
6643523D 559BD5F2 85D60F0A 3D1B1373 FB37EF05 692A147D 3795F3B6 B4A1CD1D
F544F30C F13EE75D 20A55B32 887C03F5 348A3400 07E7931A 945A2A15 572697F5
348F127E 717FB6F8 2749B663 C91BB57B 5862D3BC 006B8D15 26DD201A AA84A53D
0203
62
010001
public-key-code end
peer-public-key end
#
snetconf server enable
ssh user client001
ssh user client001 authentication-type password
ssh user client001 service-type snetconf
#
aaa
local-user client001 password irreversible-cipher ~#Dg8:9$H>ajUn1vMEIBS(P#
local-user client001 service-type ssh
#
interface MEth0/0/0
ip address 10.1.1.1 255.255.255.0
#
user-interface vty 0 4
authentication-mode aaa
protocol inbound ssh
#
return
63
4 NTP Configuration
About This Chapter
Network Time Protocol (NTP) synchronizes time among a set of distributed time servers and
clients.
4.1 NTP Overview
Network Time Protocol (NTP) is a protocol for synchronizing clocks on the network.
4.2 NTP Features Supported by the Device
The device supports basic NTP functions, local source interface for sending and receiving NTP
packets, limit on the number of local dynamic sessions, and NTP access control.
This section describes the default system configuration and default parameters.
4.4 Configuring Basic NTP Functions
You can configure basic NTP functions to enable devices on the network to synchronize clocks.
4.5 Configuring the Local Source Interface for Sending and Receiving NTP Packets
You can configure a local source interface for sending and receiving NTP packets to prevent the
IP addresses of other interfaces on the device becoming the destination address of a reply packet.
This facilitates deployment of traffic control policies.
4.6 Limit on the Number of Local Dynamic Sessions
To limit the number of local NTP dynamic sessions, the number of local NTP dynamic sessions
that can be established on the device can be specified.
4.7 Configuring NTP Access Control
In networks demanding high security, reliable clock synchronization can be implemented by
configuring the NTP security.
4.8 Maintaining NTP
In the maintenance of NTP, NTP packets are cleared, and the running status of NTP is monitored.
4.9 Configuration Examples of NTP
This topic provides configuration examples of NTP together with the configuration flowchart.
The configuration examples explain networking requirements, configuration notes, and
configuration roadmap.
Configuration Guide - Network Management 4 NTP Configuration
64
4.1 NTP Overview
Network Time Protocol (NTP) is a protocol for synchronizing clocks on the network.
As the Internet develops, people have different requirements on time synchronization. Precise
time is needed in real-time online transactions, manufacturing process control, time
configuration on communication networks, network security design, distributed network
computation and processing, transportation management, database management, and call
records. However, when all the devices on a network need to be synchronized, it is almost
impossible for an administrator to manually change the system clocks through command lines.
This is because the workload is heavy and clock precision cannot be ensured.
To address the problem, NTP is introduced.
NTP is mainly used to synchronize clocks of all the devices on the network. You can configure
NTP so that all the clocks on the network are synchronized soon with high precision, preventing
errors and heavy loads of network administrators.
4.2 NTP Features Supported by the Device
The device supports basic NTP functions, local source interface for sending and receiving NTP
packets, limit on the number of local dynamic sessions, and NTP access control.
Basic NTP Functions
Local Source Interface for Sending and Receiving NTP Packets
Limit on the Number of Local Dynamic Sessions
An NTP-enabled device supports a maximum of 128 sessions at the same time, including static
sessions and dynamic sessions. In unicast client/server mode and symmetric peer mode, sessions
are established by command lines; therefore, these sessions are static sessions. Sessions
established in broadcast mode and multicast mode are dynamic sessions.
Excess dynamic sessions limit the number of static sessions. To address this problem, you can
limit the number of dynamic sessions on the device.
When you set the limit on the number of dynamic sessions, note the following points:
l Established dynamic NTP sessions are not affected. When the number of dynamic sessions
exceeds the limit, the established dynamic sessions are not deleted, but you cannot establish
new dynamic sessions.
l The limit must be set on the client because the server cannot record the number of NTP
sessions.
65
NTP Access Control
On networks requiring high security, you can use NTP security functions to prevent malicious
attacks from modifying NTP packets.
The device supports the following NTP security functions:
l Disabling a specified interface from receiving NTP packets
You can disable the interface connected to external devices from receiving NTP packets
in the following scenarios:
An unreliable clock server exists on the interface. After the NTP functions are enabled,
all interfaces can receive NTP packets by default. However, an unreliable clock source
makes NTP clock data inaccurate.
The NTP clock data are modified when the interface is attacked maliciously.
l Configuring NTP access control authority
NTP access control provides simple methods to ensure security. When an access request
reaches the local end, the access request is successively matched with the access authority
from peer, server, synchronization, and query in sequence. The first successfully matched
authority takes effect.
peer: indicates the maximum access authority. The remote end can perform time
requests and control queries for the local NTP service. The local clock can also be
synchronized with the clock of the remote server.
server: indicates that the remote end can send a time request and a control query to the
local end. The local clock, however, cannot be synchronized with the clock of the remote
server.
synchronization: indicates that the remote end can perform only the time request to the
local end.
query: indicates the minimum access authority. The remote end can only perform the
control query to the local end.
l Configuring NTP authentication
You can enable NTP authentication on networks requiring high security. NTP
authentication ensures that the client only synchronizes with the authenticated server by
requiring passwords on the client and the server, which improves network security.
This section describes the default system configuration and default parameters.
Table 4-1 Default configuration of the device
Parameter Default Values
NTP function Enabled
NTP
authentication
Disabled
NTP access
control
No access control authority is set.

66
4.4 Configuring Basic NTP Functions
Before the basic NTP functions are configured, complete the following task:
l Configuring the network layer address and routing protocol of an interface to ensure that
NTP packets can reach the destination.
Configuration Procedure
Basic NTP configuration contains the configuration of the NTP primary clock and operating
mode.
4.4.1 Configuring an NTP primary clock
Context
A device on the network can synchronize its clock in the following manners.
l Synchronizing with the local clock: The local clock is used as the reference clock.
l Synchronizing with another device on the network: This device is used as an NTP clock
server to provide a reference clock for the local clock.
If both manners are configured, the device selects an optimal clock source by comparing the
clocks determined in the two manners. The clock of a lower stratum is preferred.
An authoritative clock is used as a reference time source for a synchronization subnet, and is
located at the top of a hierarchical structure on the synchronization subnet. The authoritative
clock is stratum0. The current authoritative clock is mostly a Radio Clock or the Global
Positioning System. The time of the authoritative clock is synchronized through the broadcast
UTC time code other than NTP.
In actual circumstances, the NTP server synchronized with the authoritative clock is set as
stratum1, and is used as a master reference clock source. Other devices on the network
synchronize their clocks with the clock of the NTP server, which means the local clock of the
NTP server is configured as the NTP primary clock. The NTP distance from a device on the
network to the master reference clock source, that is, the number of NTP servers on the NTP
synchronization chain, determines the stratum of the clock on the device.
As shown in Figure 4-1, SwitchA is the primary clock, and the clock stratum is 1. The clock
synchronization direction is from SwitchA to SwitchB, and further to SwitchC. Only after the
SwitchB is synchronized, SwitchC can synchronize its clock with the clock of SwitchB. After
all the devices on the synchronization subnet are synchronized, SwitchB and SwitchC are
respectively stratum2 and stratum3.
67
Figure 4-1 NTP synchronization subnet
Stratum1
Stratum2
Stratum3
SwitchA
SwitchB
SwitchC
Synchronization direction
NOTE
After the local clock is configured as the reference clock, the local device can be used as the clock source
to synchronize other devices on the network. Confirm before this configuration, so as avoid clock errors
on the network.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ntp refclock-master [ ip-address ] [ stratum ]
The local clock is configured as the NTP primary clock.
By default, no NTP primary clock is specified.
Step 3 Run:
commit
----End
4.4.2 Configuring NTP Operating Modes
Context
The following NTP operating modes are supported by a device:
68
Operating
Mode
Usage Scenario Deployment Location
and Synchronization
Direction
Unicast
client/server
mode
The unicast client/server mode is used on a
higher stratum on a synchronization subnet.
In this mode, the IP address of the server
needs to be obtained in advance.
You need to configure only
the client. The server needs to
be configured with only an
NTP primary clock.
Note that the client can be
synchronized to the server
but the server cannot be
synchronized to the client.
Symmetric
peer mode
The symmetric peer mode is used on a lower
stratum on the synchronization subnet. In this
mode, a symmetric active peer and a
symmetric passive peer can be synchronized
with each other. To be specific, a symmetric
peer of a higher stratum is synchronized to a
symmetric peer of a lower stratum.
You need to configure only
the symmetric active peer.
The symmetric passive peer
does not need to be
configured with an NTP
command.
In symmetric peer mode, a
symmetric peer of a higher
stratum is synchronized to a
symmetric peer of a lower
stratum.
Broadcast
mode
When the IP address of a server or a
symmetric peer is not determined, or when
the clocks of a large number of devices need
to be synchronized on a network, clock
synchronization can be implemented in the
broadcast mode.
Relevant commands need to
be run on the server and the
client.
Multicast
mode
The multicast mode applies to the high-speed
network that has multiple workstations and
does not require high accuracy. In a typical
scenario, one or more clock servers on the
network periodically send multicast packets
to the workstations. The delay of packet
transmission in a LAN is at the milliseconds
level.
Relevant commands need to
be run on the server and the
client.

NOTE
If a source address from which NTP packets are sent is specified on the server, the address must be the
same as the server IP address configured on the client. Otherwise, the client cannot process the NTP packets
sent by the server, resulting in failed clock synchronization.
Procedure
l Unicast Client/Server Mode
69
NOTE
In the unicast client/server mode, you need to configure only the client. The server needs to be
configured with only an NTP primary clock.
Only after the clock on the server is synchronized, the server can function as a clock server to which
other devices can be synchronized. When the clock stratum of the server is greater than or equal to
the clock stratum of the client, the client is not synchronized to the server.
You can run the ntp unicast-server command repeatedly to configure multiple servers. The client
selects the optimal clock source by selecting a preferred clock.
Configure the unicast client.
1. Run:
system-view
2. Run:
ntp unicast-server ip-address [ version number | authentication-keyid key-
id | source-interface interface-type interface-number | vpn-instance vpn-
instance-name | preferred ]
*
An NTP server is configured.
The value of ip-address is the IP address of the NTP server. It can be the address of
a host instead of being a broadcast address or a multicast address.
To specify the parameter authentication-keyid, see 4.7.3 Configuring NTP
Authentication.
3. Run:
commit
l Symmetric Peer Mode
NOTE
Only the IP address of the symmetric passive peer needs to be specified on the symmetric active peer
by a user, and both symmetric peers use this IP address to exchange NTP packets.
One of the symmetric active peer and the symmetric passive peer must be in the synchronized state.
Otherwise, they cannot be synchronized.
You can run the ntp unicast-peer command repeatedly to configure multiple symmetric passive
peers. When a symmetric active peer has multiple symmetric passive peers configured, the
synchronization direction follows the principle that a symmetric peer of a larger stratum is
synchronized with a symmetric peer of a smaller stratum.
Configure the symmetric active peer.
1. Run:
system-view
2. Run:
ntp unicast-peer ip-address [ version number | authentication-keyid key-
id | source-interface interface-type interface-number | vpn-instance vpn-
instance-name | preferred ]
*
The NTP symmetric passive peer is configured.
The value of ip-address must be a unicast address, and cannot be a broadcast address
or a multicast address.
70
Authentication.
3. Run:
commit
l Broadcast Mode
NOTE
The broadcast mode can be used only on a local area network (LAN).
Only after the clock of the broadcast server is synchronized, the broadcast client can be synchronized
with the broadcast server.
Configure the NTP broadcast server.
1. Run:
system-view
2. Run:
The interface for sending NTP broadcast packets is specified, and the interface view
is displayed. The interface can be a VLANIF or loopback interface.
3. Run:
ntp broadcast-server [ version number | authentication-keyid key-id ]
*
The local switch is configured as the NTP broadcast server.
Authentication.
4. Run:
commit
Configure the NTP broadcast client.
1. Run:
system-view
2. Run:
The interface for receiving NTP broadcast packets is specified, and the interface view
3. Run:
ntp broadcast-client
The local switch is configured as the NTP broadcast client.
4. Run:
commit
l Multicast Mode
71
NOTE
Only after the clock of the multicast server is synchronized, the multicast client can be synchronized
with the multicast server.
Currently a maximum of 1024 multicast clients can be configured, but a maximum of 128 multicast
clients can work simultaneously.
Configure the NTP multicast server.
1. Run:
system-view
2. Run:
The interface for sending NTP multicast packets is specified, and the interface view
3. Run:
ntp multicast-server [ ip-address ] [ version number | authentication-
keyid key-id | ttl ttl-number ]
*
The local switch is configured as the NTP multicast server.
Authentication.
4. Run:
commit
Configure the NTP multicast client.
1. Run:
system-view
2. Run:
The interface for receiving NTP multicast packets is specified, and the interface view
3. Run:
ntp multicast-client [ ip-address ]
The local switch is configured as the NTP multicast client.
4. Run:
commit
----End
Prerequisites
All configurations of basic NTP functions are completed.
72
Procedure
l Run the display ntp status command to check the NTP service status.
l Run the display ntp sessions [ verbose ] command to check the NTP session status.
l Run the display ntp trace command to check the path of reference clock source from the
local device.
l Run the display ntp statistics packet [ peer [ ip-address [ vpn-instance vpn-instance-
name ] ] | interface { interface-type interface-number | all } ] command to check the
statistical information about NTP packets or symmetric peers.
l Run the display ntp slot-status command to check the state of the clock system on the
device.
----End
4.5 Configuring the Local Source Interface for Sending and
Receiving NTP Packets
Prerequisites
All configurations of basic NTP functions have been completed.
NOTE
If the ntp unicast-server or the ntp unicast-peer command specifies the source interface of NTP packets,
the specified source interface takes effect.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ntp source-interface interface-type interface-number [ vpn-instance vpn-instance-
name ]
The local source interface for sending and receiving NTP packets is configured.
By default, the local source interface for sending NTP packets is not specified. The source IP
address of an NTP packet is selected according to the route.
In broadcast and multicast modes, the NTP service is performed on the source interface and the
ntp source-interface command does not take effect.
If the specified NTP source interface is in Down state, the source IP address of a sent NTP packet
is the primary IP address of the packet's outbound interface.
Step 3 Run:
commit
73
----End
Checking the Configuration
l Run the display current-configuration | include ntp command to check the configuration
about the local source interface for sending and receiving NTP packets.
4.6 Limit on the Number of Local Dynamic Sessions
To limit the number of local NTP dynamic sessions, the number of local NTP dynamic sessions
that can be established on the device can be specified.
Prerequisites
NOTE
The ntp max-dynamic-sessions command runs without affecting the existing NTP sessions. When the
number of local dynamic NTP sessions exceeds the maximum number, a new session cannot be established.
In both unicast client/server mode and symmetric peer mode, command lines are used to establish a
connection, which is a static session. Dynamic sessions are established in broadcast mode and multicast
mode, so that the limit on the number of local dynamic sessions takes effect.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ntp max-dynamic-sessions number
The number of local dynamic sessions that can be established is configured.
By default, a maximum of 100 NTP dynamic sessions can be established.
Step 3 Run:
commit
----End
Checking the Configuration
l Run the display current-configuration | include ntp command to check the number of
local dynamic sessions that can be established.
4.7 Configuring NTP Access Control
In networks demanding high security, reliable clock synchronization can be implemented by
configuring the NTP security.
74
Prerequisites
To configure access authority, configure the ACL for access control.
Configuration Order
You can perform the following configuration tasks in any sequence as required.
4.7.1 Disabling a Specified Interface from Receiving NTP Packets
Context
You can disable the interface connected to external devices from receiving NTP packets in the
following scenarios:
l An unreliable clock server exists on the interface. After the NTP functions are enabled, all
interfaces can receive NTP packets by default. However, an unreliable clock source makes
NTP clock data inaccurate.
l The NTP clock data are modified when the interface is attacked maliciously.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The interface for receiving NTP packets is specified. The interface can be a VLANIF or loopback
interface.
Step 3 Run:
ntp receive disable
The interface is disabled from receiving NTP packets.
Step 4 Run:
commit
----End
4.7.2 Configuring NTP Access Control Authority
Context
NTP access control is a simple security measure. When an access request reaches the local end,
the access request is successively matched with the access authority from the maximum one to
the minimum one. The first successfully matched access authority takes effect. The matching
order is: peer, server, synchronization, and query.
75
The access control authority is configured on different devices in different NTP operating modes,
as described in Table 4-2.
Table 4-2 Configuration of the NTP access control authority
NTP Operating
Mode
Restricted NTP Request
Type
Configured Device
Unicast NTP client/
server mode
The client is restricted from
synchronizing to the server.
Client
Unicast NTP client/
server mode
The server is restricted from
processing the clock
synchronization request sent
by the client.
Server
NTP symmetric peer
mode
A symmetric passive peer and
a symmetric active peer are
restricted from synchronizing
with each other.
Symmetric active peer
NTP symmetric peer
mode
The symmetric passive peer is
restricted from processing the
clock request sent by the
symmetric active peer.
Symmetric passive peer
NTP multicast mode The client is restricted from
NTP multicast client
NTP broadcast
mode
The client is restricted from
NTP broadcast client

Procedure
Step 1 Run:
system-view
Step 2 Configure the basic ACL.
Before configuring the access control rights, you must create a basic ACL. For the creation
procedure, see "ACL Configuration" in the CloudEngine 6800&5800 Series Switches
Configuration Guide-Security.
Step 3 Run:
ntp access { peer | query | server | synchronization } { acl-number | acl-name acl-
name }
The access control authority of the NTP service is configured.
By default, no access control authority is set.
76
NOTE
Check the configuration of the ACL rule before configuring the NTP access control authority in the ACL. When
the ACL rule is permit, the peer device with the source IP address specified in this rule can access the NTP
service on the local device. The access right of the peer device is configured using the ntp access command.
When the ACL rule is deny, the peer device with the source IP address specified in this rule cannot access the
NTP service on the local device.
Step 4 Run:
commit
----End
4.7.3 Configuring NTP Authentication
Context
In some networks demanding high security, the authentication function needs to be enabled when
you use the NTP protocol. Password authentication of a client and a server ensures that the client
only synchronizes with a device that has been authenticated, improving the network security.
When configuring the NTP authentication function, note the following rules:
l The NTP authentication function must be enabled first; otherwise, authentication cannot
be implemented.
l The NTP authentication function needs to be configured on both the client and the server.
Otherwise, the NTP authentication function does not take effect.
l If the NTP authentication function is enabled, a trusted key is configured on the client.
l Keys configured on the server and the client must be identical.
l The device that wants to synchronize its clock should declare its key as reliable.Otherwise,
NTP authentication will fail.
NOTE
In NTP symmetric peer mode, the symmetric active peer functions as a client and the symmetric passive
peer functions as a server.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ntp authentication enable
The NTP authentication function is enabled.
Step 3 Run:
ntp authentication-keyid key-id authentication-mode { md5 | hmac-sha256 } { plain
password-plain | [ cipher ] password }
The NTP authentication key is configured.
Step 4 Run:
77
ntp trusted authentication-keyid key-id
The reliable key is specified.
Step 5 Run:
commit
----End
Follow-up Procedure
After the configuration of the NTP authentication is completed, apply the NTP authentication
key in Configuring NTP Operating Modes. That is, specify the parameter authentication-
keyid.
Prerequisites
The configuration of NTP access control is completed.
Procedure
l Run the display current-configuration | include ntp command to check the NTP
configuration.
l Run the display ntp status command to check the NTP service status.
l Run the display ntp sessions [ verbose ] command to check the NTP session status.
----End
4.8 Maintaining NTP
In the maintenance of NTP, NTP packets are cleared, and the running status of NTP is monitored.
4.8.1 Monitoring the Running Status of NTP
Context
To monitor the NTP running status after configurations of NTP are complete, run the following
commands in any view.
Procedure
l Run:
display ntp statistics packet [ peer [ ip-address [ vpn-instance vpn-instance-
name ] ] | interface { interface-type interface-number | all } ]
The statistics on NTP packets or symmetric peers are checked.
l Run:
display ntp slot-status
78
The status of the clock system on a device is checked.
l Run:
display ntp status
Check the status information of NTP.
l Run:
display ntp sessions [ verbose ]
All session information maintained by the local NTP service is checked.
l Run:
display ntp trace
The path from the local device to the reference clock source is checked.
----End
4.9 Configuration Examples of NTP
This topic provides configuration examples of NTP together with the configuration flowchart.
The configuration examples explain networking requirements, configuration notes, and
configuration roadmap.
4.9.1 Example for Configuring Authenticated NTP Unicast Client/
Server Mode
As shown in Figure 4-2, SwitchB, SwitchC, and SwitchD are on a local area network (LAN),
and are connected to SwitchA through a network. SwitchA has synchronized its clock to an
authoritative clock, the Global Positioning System (GPS).
As is required by the user, the three devices SwitchB, SwitchC, and SwitchD on the LAN must
synchronize their clocks to the clock of SwitchA to ensure a precise charging service.
Figure 4-2 Networking diagram for configuring NTP unicast client/server mode
SwitchA
IP
Network
SwitchB
SwitchC
SwitchD
10GE1/0/1
2.2.2.2/24
VLANIF100
10GE1/0/1
1.0.1.1/24
VLANIF110
10GE1/0/2
1.0.0.1/24
VLANIF111
10GE1/0/1
1.0.0.2/24
VLANIF111
10GE1/0/1
1.0.0.3/24
VLANIF111
79
You can configure the authenticated unicast client/server mode to meet the user's requirement
for clock synchronization on the LAN. The configuration roadmap is as follows:
1. Configure SwitchA as the primary time server.
2. The NTP unicast client/server mode is used to synchronize the clocks of SwitchA and
SwitchB. SwitchA functions as the server, and SwitchB functions as the client.
3. The NTP unicast client/server mode is used to synchronize the clocks of SwitchB,
SwitchC, and SwitchD. SwitchB functions as the server, while SwitchC and SwitchD
function as the clients.
4. SwitchA and SwitchB are connected through the network, which is not secure, so that the
NTP authentication function is enabled.
NOTE
When configuring NTP authentication in the unicast client/server mode, enable the NTP authentication on
the client, and specify the NTP server address and the authentication key sent to the server. Otherwise, the
NTP authentication is not performed, and the NTP client and server are directly synchronized.
Procedure
Step 1 According to Figure 4-2, configure IP addresses, and configure reachable routes between any
two of SwitchA, SwitchB, SwitchC, and SwitchD.
# Configure an IP address on SwitchA. For details about the configurations of SwitchB,
SwitchC, and SwitchD, see "Configuration Files".
[~HUAWEI] sysname SwitchA
[~HUAWEI] commit
[~SwitchA] vlan 100
[~SwitchA-vlan100] quit
[~SwitchA] interface vlanif 100
[~SwitchA-Vlanif100] ip address 2.2.2.2 24
[~SwitchA-Vlanif100] quit
[~SwitchA] interface 10ge 1/0/1
[~SwitchA-10GE1/0/1] port link-type trunk
[~SwitchA-10GE1/0/1] port trunk pvid vlan 100
[~SwitchA-10GE1/0/1] port trunk allow-pass vlan 100
[~SwitchA-10GE1/0/1] quit
[~SwitchA] ospf 1
[~SwitchA-ospf-1] area 0
[~SwitchA-ospf-1-area-0.0.0.0] network 2.2.2.0 0.0.0.255
[~SwitchA-ospf-1-area-0.0.0.0] quit
[~SwitchA-ospf-1] quit
[~SwitchA] commit
Step 2 Configure an NTP primary clock on SwitchA and enable the NTP authentication function.
# Specify the local clock of SwitchA as the primary clock, and set the clock stratum to 2.
[~SwitchA] ntp refclock-master 2
# Enable the NTP authentication function, configure the authentication key, and specify the key
as reliable.
[~SwitchA] ntp authentication enable
[~SwitchA] ntp authentication-keyid 42 authentication-mode md5 Hello
[~SwitchA] ntp trusted authentication-keyid 42
[~SwitchA] commit
Step 3 Enable the NTP authentication function on SwitchB.
80
# Enable the NTP authentication function on SwitchB, configure the authentication key, and
specify the key as reliable.
<SwitchB> system-view
[~SwitchB] ntp authentication enable
[~SwitchB] ntp authentication-keyid 42 authentication-mode md5 Hello
[~SwitchB] ntp trusted authentication-keyid 42
# Specify SwitchA as the NTP server of SwitchB, and use the configured authentication key.
[~SwitchB] ntp unicast-server 2.2.2.2 authentication-keyid 42
[~SwitchB] commit
Step 4 Specify on SwitchC that SwitchB functions as the NTP server of SwitchC.
<SwitchC> system-view
[~SwitchC] ntp authentication enable
[~SwitchC] ntp authentication-keyid 42 authentication-mode md5 Hello
[~SwitchC] ntp trusted authentication-keyid 42
[~SwitchC] ntp unicast-server 1.0.0.1 authentication-keyid 42
[~SwitchC] commit
Step 5 Specify on SwitchD that SwitchB functions as the NTP server of SwitchD.
<SwitchD> system-view
[~SwitchD] ntp authentication enable
[~SwitchD] ntp authentication-keyid 42 authentication-mode md5 Hello
[~SwitchD] ntp trusted authentication-keyid 42
[~SwitchD] ntp unicast-server 1.0.0.1 authentication-keyid 42
[~SwitchD] commit
After the preceding configuration is complete, SwitchB can synchronize its clock with the clock
of SwitchA.
# Check the NTP status of SwitchB, and you can find that the clock status is "synchronized",
indicating that the synchronization is complete. The stratum of the clock is 3, which is one
stratum lower than that of the clock of the server SwitchA.
[~SwitchB] display ntp status
clock status: synchronized
clock stratum: 3
reference clock ID: 2.2.2.2
nominal frequency: 60.0002 Hz
actual frequency: 60.0002 Hz
clock precision: 2^18
clock offset: 3.8128 ms
root delay: 31.26 ms
root dispersion: 74.20 ms
peer dispersion: 34.30 ms
reference time: 11:55:56.833 UTC Mar 2 2012(C7B15BCC.D5604189)
synchronization state: clock synchronized
After the preceding configuration is complete, SwitchC can synchronize its clock with the clock
of SwitchB.
# Check the NTP status of SwitchC, and you can find that the clock status is "synchronized",
stratum lower than that of the clock of the server SwitchB.
[~SwitchC] display ntp status
clock stratum: 4
81
# Check the NTP status of SwitchD, and you can find that the clock status is "synchronized",
stratum lower than that of the clock of the server SwitchB.
[~SwitchD] display ntp status
clock stratum: 4
# Check the NTP status of SwitchA.
[~SwitchA] display ntp status
clock stratum: 2
reference clock ID: LOCAL(0)
root delay: 0.00 ms
reference time: 12:01:48.377 UTC Mar 2 2012(C7B15D2C.60A15981)
----End
Configuration Files
l Configuration file of SwitchA
#
sysname SwitchA
#
ntp authentication-keyid 42 authentication-mode md5 cipher %$%$iU;C@~zqb+};!@!
vGIp5q}tk%$%$
ntp refclock-master 2
#
vlan batch 100
#
interface Vlanif100
ip address 2.2.2.2 255.255.255.0
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 2.2.2.0 0.0.0.255
82
#
return
l Configuration file of SwitchB
#
sysname SwitchB
#
vGIp5q}tk%$%$
ntp trusted authentication-keyid 42
ntp unicast-server 2.2.2.2 authentication-keyid 42
#
vlan batch 110 to 111
#
interface Vlanif110
ip address 1.0.1.1 255.255.255.0
#
interface Vlanif111
ip address 1.0.0.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 1.0.0.0 0.0.0.255
network 1.0.1.0 0.0.0.255
#
return
l Configuration file of SwitchC
#
sysname SwitchC
#
vGIp5q}tk%$%$
#
#
vlan batch 111
#
interface Vlanif111
ip address 1.0.0.2 255.255.255.0
#
interface 10GE1/0/1
#
return
l Configuration file of SwitchD
#
sysname SwitchD
#
vGIp5q}tk%$%$
83
#
#
vlan batch 111
#
interface Vlanif111
ip address 1.0.0.3 255.255.255.0
#
interface 10GE1/0/1
#
return
4.9.2 Example for Configuring NTP Symmetric Peer Mode
As shown in Figure 4-3, three devices are on a local area network (LAN).
The clocks of the devices on the LAN need to be synchronized to facilitate device management.
SwitchC has synchronized its clock with an authoritative clock, the Global Positioning System
(GPS), through a network. The user requires SwitchD and SwitchE to synchronize their clocks
to the clock of SwitchC.
Figure 4-3 Networking diagram for configuring the symmetric peer mode
SwitchC
10GE1/0/1
VLANIF100
10.0.0.3/24
10GE1/0/1
VLANIF100
10.0.0.2/24
SwitchE
SwitchD
10GE1/0/1
VLANIF100
10.0.0.1/24
You can configure the NTP protocol to synchronize time, and use the NTP symmetric peer mode
to meet the user's requirement for time synchronization. The configuration roadmap is as follows:
1. Configure the local clock of SwitchC as the NTP primary clock.
2. The NTP unicast server/client mode is used to synchronize the clocks of SwitchC and
SwitchD. SwitchC functions as the server, and SwitchD functions as the client.
3. The symmetric peer mode is used to synchronize the clocks of SwitchE and SwitchD.
SwitchE functions as the symmetric active peer and sends a clock synchronization request
to SwitchD.
84
Procedure
Step 1 Configure IP addresses for SwitchC, SwitchD, and SwitchE.
Configure an IP address for each interface according to Figure 4-3. After the configurations are
complete, the three switches can ping each other.
# Configure an IP address on SwitchC. For details about the configurations of SwitchD and
SwitchE, see "Configuration Files".
[~HUAWEI] sysname SwitchC
[~HUAWEI] commit
[~SwitchC] vlan 100
[~SwitchC-vlan100] quit
[~SwitchC] interface vlanif 100
[~SwitchC-Vlanif100] ip address 10.0.0.1 24
[~SwitchC-Vlanif100] quit
[~SwitchC] interface 10ge 1/0/1
[~SwitchC-10GE1/0/1] port link-type trunk
[~SwitchC-10GE1/0/1] port trunk pvid vlan 100
[~SwitchC-10GE1/0/1] port trunk allow-pass vlan 100
[~SwitchC-10GE1/0/1] quit
[~SwitchC] commit
Step 2 Configure the NTP client/server mode.
# Set the local clock of SwitchC as the NTP primary clock, and set the clock stratum to 2.
[~SwitchC] ntp refclock-master 2
[~SwitchC] commit
# Specify on SwitchD that SwitchC functions as the NTP server of SwitchD.
[~SwitchD] ntp unicast-server 10.0.0.1
[~SwitchD] commit
After the preceding configuration is complete, SwitchD can synchronize its clock with the clock
of SwitchC.
stratum lower than that of the clock of SwitchC.
clock stratum: 3
reference clock ID: 10.0.0.1 nominal frequency: 60.0029 Hz
reference time: 06:52:33.465 UTC Mar 7 2012(C7B7AC31.773E89A8)
Step 3 Configure the NTP unicast symmetric peer mode.
# Specify on SwitchE that SwitchD functions as the symmetric passive peer of SwitchE.
<SwitchE> system-view
[~SwitchE] ntp unicast-peer 10.0.0.2
[~SwitchE] commit
85
SwitchE is not configured with a primary clock and its clock stratum is lower than that of
SwitchD, so that SwitchE synchronizes its clock with the clock of SwitchD.
Monitor the status of SwitchE after the synchronization. The clock of SwitchE is in
"synchronized" status, indicating that the synchronization is complete. The clock stratum of
SwitchE is 4, which is one stratum lower than that of the symmetric passive peer SwitchD.
# Check the clock status of SwitchE.
[~SwitchE] display ntp status
clock stratum: 4
reference time: 06:55:50.784 UTC Mar 7 2012(C7B7ACF6.C8D002E2)
----End
Configuration Files
#
sysname SwitchC
#
#
vlan batch 100
#
interface Vlanif100
ip address 10.0.0.1 255.255.255.0
#
interface 10GE1/0/1
#
return
#
sysname SwitchD
#
ntp unicast-server 10.0.0.1
#
vlan batch 100
#
interface Vlanif100
ip address 10.0.0.2 255.255.255.0
#
interface 10GE1/0/1
#
return
l Configuration file of SwitchE
86
#
sysname SwitchE
#
ntp unicast-peer 10.0.0.2
#
vlan batch 100
#
interface Vlanif100
ip address 10.0.0.3 255.255.255.0
#
interface 10GE1/0/1
#
return
4.9.3 Example for Configuring Authenticated NTP Broadcast Mode
As shown in Figure 4-4, SwitchF, SwitchC, and SwitchD are on a local area network (LAN).
SwitchA directly connects to SwitchF. SwitchC directly synchronizes its clock to an
authoritative clock, the Global Positioning System (GPS), by radio.
To provide charging services, all switches (except SwitchA) in Figure 4-4 are required to
synchronize their clocks to a standard clock. SwitchA is outside the charging range, and does
not need to synchronize its clock to the standard clock.
Figure 4-4 Networking diagram for configuring authenticated NTP broadcast mode
10GE1/0/1
VLANIF20
1.0.1.11/24
SwitchA SwitchF
SwitchC
SwitchD
10GE1/0/2
VLANIF10
3.0.1.2/24
10GE1/0/1
VLANIF10
3.0.1.31/24
10GE1/0/1
VLANIF10
3.0.1.32/24
10GE1/0/1
VLANIF20
1.0.1.2/24
You can configure the NTP protocol to synchronize time, and use the authenticated NTP
broadcast mode to meet the user's requirement. The configuration roadmap is as follows:
1. Configure SwitchC as the primary time server, use the local clock as the NTP primary
clock, and set the clock stratum to 3.
2. Configure SwitchC as the NTP broadcast server that sends broadcast packets from interface
VLANIF10 (the corresponding physical interface is 10GE1/0/1).
3. Configure SwitchA, SwitchD and SwitchF as NTP broadcast clients. SwitchA uses
VLANIF20 (the corresponding physical interface is 10GE1/0/1) to listen to the broadcast
packets. SwitchD uses VLANIF10 (the corresponding physical interface is 10GE1/0/1) to
87
listen to the broadcast packets. SwitchF uses interface VLANIF10 (the corresponding
physical interface is 10GE1/0/2) to listen to the broadcast packets.
4. To strengthen the network security, the NTP authentication function is enabled.
Procedure
Step 1 Configure an IP address for each interface according to Figure 4-4, and configure reachable
routes between the switches.
# Configure an IP address for the interface and configure a routing protocol on SwitchA.
[~HUAWEI] commit
[~SwitchA] vlan 20
[~SwitchA-vlanif20] ip address 1.0.1.11 24
[~SwitchA-vlanif20] quit
[~SwitchA] ospf 1
[SwitchA] commit
For details about the configurations of SwitchC, SwitchD, and SwitchF, see "Configuration
Files".
Step 2 Configure the NTP broadcast server, and enable the authentication.
# Configure the local clock of SwitchC as the NTP primary clock, and set the clock stratum to
3.
# Enable NTP authentication.
[~SwitchC] ntp authentication enable
[~SwitchC] ntp authentication-keyid 16 authentication-mode md5 Hello
# Configure SwitchC as the NTP broadcast server that sends NTP broadcast packets from
VLANIF10, and specify the key with the ID 16 for encryption.
[~SwitchC-Vlanif10] ntp broadcast-server authentication-keyid 16
[~SwitchC] commit
Step 3 Configure the NTP broadcast client SwitchD on a network segment the same as that of the NTP
server.
[~SwitchD] ntp authentication enable
[~SwitchD] ntp authentication-keyid 16 authentication-mode md5 Hello
[~SwitchD] ntp trusted authentication-keyid 16
# Configure SwitchD as the NTP broadcast client that listens to the NTP broadcast packets from
interface VLANIF10.
[~SwitchD] interface vlanif 10
[~SwitchD-Vlanif10] ntp broadcast-client
88
[~SwitchD-Vlanif10] quit
[~SwitchD] commit
After the configuration is complete, SwitchD synchronizes its clock to that of SwitchC. For
details about the configuration of SwitchF, which is similar to that of SwitchC, see the
corresponding configuration file.
Step 4 Configure the NTP broadcast client SwitchA on a network segment different from that of the
server.
[~SwitchA] ntp authentication enable
[~SwitchA] ntp authentication-keyid 16 authentication-mode md5 Hello
[~SwitchA] ntp trusted authentication-keyid 16
# Configure SwitchA as the NTP broadcast client that listens to the NTP broadcast packets from
interface VLANIF20.
[~SwitchA-Vlanif20] ntp broadcast-client
[~SwitchA] commit
After the preceding configuration is complete, SwitchD can synchronize its clock to that of
SwitchC, but SwitchA cannot synchronize its clock to that of SwitchC.
This is because SwitchA is on a network segment different from that of SwitchC, but SwitchD
is on a network segment the same as that of SwitchC.
stratum lower than that of the clock of SwitchC.
clock stratum: 4
root delay: 0.00 ms
reference time: 12:17:21.773 UTC Mar 7 2012(C7B7F851.C5EAF25B)
----End
Configuration Files
#
sysname SwitchA
#
ntp authentication-keyid 16 authentication-mode md5 cipher %$%$Q1Ub0~;Ga!
9IasE'@Db-,5,#%$%$
#
vlan batch 20
#
interface Vlanif20
ip address 1.0.1.11 255.255.255.0
89
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 1.0.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
9IasE'@Db-,5,#%$%$
#
vlan batch 10
#
interface Vlanif10
ip address 3.0.1.31 255.255.255.0
ntp broadcast-server authentication-keyid 16
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 3.0.1.0 0.0.0.255
#
return
#
sysname SwitchD
#
9IasE'@Db-,5,#%$%$
#
vlan batch 10
#
interface Vlanif10
ip address 3.0.1.32 255.255.255.0
#
interface 10GE1/0/1
#
return
l Configuration file of SwitchF
#
sysname SwitchF
#
9IasE'@Db-,5,#%$%$
#
90
vlan batch 10 20
#
interface Vlanif10
ip address 3.0.1.2 255.255.255.0
#
interface Vlanif20
ip address 1.0.1.2 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
ospf 1
area 0.0.0.0
network 1.0.1.0 0.0.0.255
network 3.0.1.0 0.0.0.255
#
return
4.9.4 Example for Configuring NTP Multicast Mode
As shown in Figure 4-5, SwitchF, SwitchC, and SwitchD are on a local area network (LAN).
SwitchA directly connects to SwitchF. SwitchC directly synchronizes its clock to an
authoritative clock, the Global Positioning System (GPS), by radio.
To provide charging services, the clocks of all switches on the network need to be synchronized
to the clock of SwitchC.
Figure 4-5 Networking diagram for configuring NTP multicast mode
10GE1/0/1
VLANIF20
1.0.1.11/24
SwitchA SwitchF
SwitchC
SwitchD
10GE1/0/2
VLANIF10
3.0.1.2/24
10GE1/0/1
VLANIF10
3.0.1.31/24
10GE1/0/1
VLANIF10
3.0.1.32/24
10GE1/0/1
VLANIF20
1.0.1.2/24
You can configure the NTP protocol to synchronize time, and use the NTP multicast mode to
meet the user's requirement. The configuration roadmap is as follows:
91
1. Configure SwitchC as the primary time server, use the local clock as the NTP primary
clock, and set the clock stratum to 2.
2. Configure SwitchC as the NTP multicast server that sends multicast packets from interface
VLANIF10 (the corresponding physical interface is 10GE1/0/1).
3. Configure SwitchA, SwitchD, and SwitchF as NTP multicast clients. SwitchA uses
VLANIF20 (the corresponding physical interface is 10GE1/0/1) to listen to the multicast
packets. SwitchD uses interface VLANIF10 (the corresponding physical interface is
10GE1/0/1) to listen to the multicast packets. SwitchF uses interface VLANIF10 (the
corresponding physical interface is 10GE1/0/2) to listen to the multicast packets.
4. Configure a multicast route, so that SwitchA can receive the multicast packets.
Procedure
Step 1 Configure an IP address for each interface according to Figure 4-5, and configure reachable
routes between the switches.
# Configure an IP address for the interface and configure a routing protocol on SwitchA.
[~HUAWEI] commit
[~SwitchA] vlan 20
[~SwitchA] ospf 1
[~SwitchA] commit
For details about the configurations of SwitchC, SwitchD, and SwitchF, see "Configuration
Files".
Step 2 Configure the NTP multicast server.
# Configure the local clock of SwitchC as the NTP primary clock, and set the clock stratum to
2.
# Configure SwitchC as the NTP multicast server that sends NTP multicast packets from
interface VLANIF10.
[~SwitchC-Vlanif10] ntp multicast-server
[~SwitchC] commit
Step 3 Configure the NTP multicast client SwitchD on a network segment the same as that of the NTP
server.
# Configure SwitchD as the NTP multicast client that listens to the NTP multicast packets from
interface VLANIF10.
[~SwitchD] interface vlanif 10
[~SwitchD-Vlanif10] ntp multicast-client
92
[~SwitchD-Vlanif10] quit
[~SwitchD] commit
Step 4 Configure the NTP multicast client SwitchA on a network segment different from that of the
server.
# Configure SwitchA as the NTP multicast client that listens to the NTP multicast packets from
interface VLANIF20.
<SwitchA> system-view
[~SwitchA-Vlanif20] ntp multicast-client
[~SwitchA] commit
Step 5 Configure a multicast route, so that SwitchA on a network segment different from that of
SwitchC can receive NTP multicast packets.
# Configure the multicast routing function on SwitchC.
[~SwitchC] multicast routing-enable
[~SwitchC] intface vlanif 10
[~SwitchC-Vlanif10] pim sm
[~SwitchC] commit
# Configure the multicast routing function on SwitchF.
[~SwitchF] multicast routing-enable
[~SwitchF] intface vlanif 20
[~SwitchF-Vlanif20] pim sm
[~SwitchF-Vlanif20] igmp enable
[~SwitchF-Vlanif20] igmp static-group 224.0.1.1
[~SwitchF-Vlanif20] quit
[~SwitchF] pim
[~SwitchF-pim] c-bsr vlanif 20
[~SwitchF-pim] c-rp vlanif 20
[~SwitchF-pim] quit
[~SwitchF] interface 10ge 1/0/1
[~SwitchF-10GE1/0/1] l2-multicast static-group group-address 224.0.1.1 vlan 20
[~SwitchF-10GE1/0/1] quit
[~SwitchF] commit
After the preceding configuration is complete, SwitchD and SwitchA can synchronize their
clocks to the clock of SwitchC.
stratum lower than that of the clock of the server SwitchC.
clock stratum: 3
root delay: 0.00 ms
# Check the NTP status of SwitchA, and you can find that the clock status is "synchronized",
stratum lower than that of the clock of the server SwitchC.
[~SwitchA] display ntp status
93
clock stratum: 3
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 20
#
interface Vlanif20
ip address 1.0.1.11 255.255.255.0
ntp multicast-client
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 1.0.1.0 0.0.0.255
#
return
#
sysname SwitchC
#
vlan batch 10
#
#
multicast routing-enable
#
interface Vlanif10
ip address 3.0.1.31 255.255.255.0
ntp multicast-server
pim sm
#
interface 10GE1/0/1
#
ospf 1
area 0.0.0.0
network 3.0.1.0 0.0.0.255
#
return
#
sysname SwitchD
#
vlan batch 10
94
#
interface Vlanif10
ip address 3.0.1.32 255.255.255.0
ntp multicast-client
#
interface 10GE1/0/1
#
return
l Configuration file of SwitchF
#
sysname SwitchF
#
vlan batch 10 20
#
multicast routing-enable
#
interface Vlanif10
ip address 3.0.1.2 255.255.255.0
#
interface Vlanif20
ip address 1.0.1.2 255.255.255.0
pim sm
igmp enable
igmp static-group 224.0.1.1
#
interface 10GE1/0/1
l2-multicast static-group group-address 224.0.1.1 vlan 20
#
interface 10GE1/0/2
#
pim
c-bsr Vlanif20
c-rp Vlanif20
#
ospf 1
area 0.0.0.0
network 1.0.1.0 0.0.0.255
network 3.0.1.0 0.0.0.255
#
return
95
5 Ping and Tracert Configuration
About This Chapter
You can use the ping command to check network connectivity, and the tracert command to
check the path from the source to the destination and to locate faults on the network.
5.1 Ping/Tracert Overview
The ping command is a most commonly used debugging tool for checking network connectivity
and host reachability. The tracert command is used to check the path of packets from the source
host to the destination host.
5.2 Checking IP Network Connectivity Through Ping/Tracert
You can use the ping command to check IP network connectivity, and the tracert command to
5.3 Checking TRILL Network Connectivity Through Ping
You can run the ping command to check unicast forwarding paths and reachability of nodes
along paths on a TRILL network.
This section provides a configuration example of ping and tracert operations.
Configuration Guide - Network Management 5 Ping and Tracert Configuration
96
5.1 Ping/Tracert Overview
The ping command is a most commonly used debugging tool for checking network connectivity
and host reachability. The tracert command is used to check the path of packets from the source
host to the destination host.
5.1.1 Ping/Tracert
Introduction to Ping/Tracert
The ping command checks network connectivity and host reachability.
The tracert command checks the path of packets from the source end to the destination end and
check network connectivity. When a network fault occurs, you can use the tracert command to
locate the fault.
Ping
The ping command implementation is based on the Internet Control Message Protocol (ICMP).
The source end sends an ICMP Echo Request message to the destination end, and determines
reachability of the destination end. If the source end receives an ICMP Echo Reply message
from the destination end within a specified period, the destination end is reachable. If the source
end does not receive an ICMP Echo Reply message from the destination end within a specified
period, the destination end is unreachable. The source end determines the quality of the link to
the reachable destination end based on the number of sent ICMP Echo Request messages and
received ICMP Echo Reply messages, and determines the distance between the source end and
destination end according to the round-trip time (RTT) of ping packets.
Tracert
Figure 5-1 Tracert working process
SwitchA Log host
TTL=1
TTL=2
TTL=3
SwitchB SwitchC
1.1.1.1/24
1.1.1.2/24
1.1.2.1/24
1.1.2.2/24
1.1.3.1/24
1.1.3.2/24
UDP datagram
ICMP Time Exceeded message
ICMP Destination Unreachable message

The tracert command implementation is based on the ICMP. As shown in Figure 5-1, the
working process of tracert is as follows:
97
1. The source end (SwitchA) sends a UDP packet whose TTL value is 1 and destination UDP
port number is larger than 30000 to the destination end (Log host). In most cases, the UDP
port whose number is larger than 30000 is not used by any program.
2. Upon receiving the UDP packet, the first-hop host (SwitchB) determines that the destination
IP address of the packet is not the local IP address and decreases the TTL value by one.
The TTL value is 0, so SwitchB discards the UDP packet, and sends an ICMP Time
Exceeded message containing its local IP address 1.1.1.2 to SwitchA. SwitchA obtains the
IP address of SwitchB.
3. Upon receiving the ICMP Time Exceeded message from SwitchB, SwitchA sends a UDP
packet with the TTL value of 2.
4. Upon receiving the UDP packet, the second-hop host (SwitchC) returns an ICMP Time
Exceeded message containing its local IP address 1.1.2.2 to SwitchA.
5. The preceding process is repeated until the destination end determines that the destination
IP address of the UDP packet is its local IP address and processes the packet. The destination
end searches for the upper-layer protocol that uses the destination port number of the packet.
No program uses this UDP port number, so the destination end returns an ICMP Destination
Unreachable message containing its local IP address 1.1.3.2.
6. Upon receiving the ICMP Destination Unreachable message, the source end determines
that the UDP packet has reached the destination end, stops tracert, and generates the path
of the UDP packet 1.1.1.2 -> 1.1.2.2 -> 1.1.3.2.
5.1.2 TRILL Ping
TRILL ping has been developed to detect TRILL network connectivity, locate fault on the TRILL
network, and improve network reliability.
Figure 5-2 Networking diagram of TRILL ping
RB1 RB4
RB3 RB2
RB5
RB6
Echo Request Packet
Echo Reply Packet

98
As shown in Figure 5-2, RB1 initiates a unicast TRILL ping to detect link connectivity between
RB1 and RB3.
1. By searching for the TRILL unicast forwarding table based on the destination nickname,
RB1 obtains the outbound interface and next hop to the destination RB. RB1 then constructs
a unicast Echo Request packet and sends the packet to the next-hop RB4.
2. RB4 parses the TRILL header in the received Echo Request packet. By searching for the
unicast forwarding table based on the destination nickname, RB4 obtains the outbound
interface and next hop to the destination RB. RB4 then sends the packet to the next-hop
RB3.
3. If the TTL value is within the specified range, RB3 responds with an Echo Reply packet;
if the TTL value exceeds the specified range, RB3 sends no response packet. If the source
RB receives no response packet within a specified period, the link between RB1 and RB3
fails.
5.2 Checking IP Network Connectivity Through Ping/
Tracert
You can use the ping command to check IP network connectivity, and the tracert command to
5.2.1 Checking IP Network Connectivity Through Ping
Context
During routine system maintenance, you can run the ping command to check network
connectivity. If the ping fails, run the tracert command to locate the fault on the network.
Procedure
l Run the ping command to check IP network connectivity.
Run:
ping [ ip ] [ -a source-ip-address | -c count | -d | -f | -h ttl-value | -i
interface-type interface-number | -m time |-p pattern | -q | -r | -s
packetsize | -system-time | -t timeout | -tos tos-value | -v | -vpn-
*
host [ ip-forwarding ]
Network connectivity is tested.
----End
5.2.2 Detecting IP Network Paths and Locating Faults Through
Tracert
Context
During routine system maintenance, you can run the ping command to check network
connectivity. If the ping fails, run the tracert command to locate the fault on the network.
99
Procedure
l Detect IP network paths and locate faults through tracert.
Run:
tracert [ -a source-ip-address | -f first-ttl | -m max-ttl | -p port | -q
nqueries | -vpn-instance vpn-instance-name | -w timeout ]
*
host
The path from a source to a destination is displayed, and the fault is located.
----End
5.3 Checking TRILL Network Connectivity Through Ping
You can run the ping command to check unicast forwarding paths and reachability of nodes
along paths on a TRILL network.
Before detecting TRILL network connectivity through ping, configure the TRILL function.
Procedure
l Check TRILL network connectivity through ping.
Run:
ping trill [ -c count | -h ttl-value | -m time | -t timeout ]
*
nickname
A unicast forwarding path and reachability of nodes along the path on a TRILL network
are tested.
----End
This section provides a configuration example of ping and tracert operations.
5.4.1 Example for Performing Ping and Tracert Operations
Configuration Requirements
As shown in Figure 5-3, after configuring SwitchA, check the link between SwitchA and the
log host. If the link is disconnected, you need to locate the fault.
Figure 5-3 Networking diagram of ping and tracert operations
SwitchA Log host
1.1.1.2/24 1.1.3.2/24
1.1.2.2/24
1.1.1.1/24 1.1.2.1/24 1.1.3.1/24
SwitchB SwitchC

100
1. Run the ping command on SwitchA to check connectivity between SwitchA and the log
host.
2. Run the tracert command to locate the faulty link segment if the link is disconnected.
Procedure
Step 1 Run the ping command.
# Run the ping command on SwitchA to check connectivity between SwitchA and the log host.
<HUAWEI> ping 1.1.3.2
PING 1.1.3.2: 56 data bytes, press CTRL_C to break
Request time out
Request time out
Request time out
Request time out
Request time out
--- 1.1.3.2 ping statistics ---
5 packet(s) transmitted
0 packet(s) received
100.00% packet loss
The output on SwitchA shows that the log host is unreachable, which indicates that a fault occurs
on the link between SwitchA and the log host.
Step 2 Run the tracert command.
# Run the tracert command on SwitchA to locate the faulty link segment.
<HUAWEI> tracert 1.1.3.2
traceroute to 1.1.3.2(1.1.3.2), max hops: 30 ,packet length: 40
1 1.1.1.2 4 ms 5 ms 5 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
...
The preceding output shows that the ICMP Echo Request packet passes SwitchB but does not
reach SwitchC. This indicates that the link between SwitchB and SwitchC fails. After the link
between SwitchB and SwitchC is recovered, repeat Step 1 and Step 2 to ensure that SwitchA
and the log host can communicate properly.
----End
101
6 NQA Configuration
About This Chapter
This chapter describes how to configure the Network Quality Analysis (NQA) to monitor the
network operating status and collect network operation indexes in real time.
6.1 NQA Overview
Network Quality Analysis (NQA) is a feature that monitors network performance in real time
and helps diagnose faults occurring on the network.
6.2 NQA Features Supported by the Device
This section describes the NQA test types supported by the device.
6.3 Configuring an NQA Test Instance
You can configure an NQA test instance to perform an NQA test of a specified type.
6.4 Configuring the NQA Transmission Delay Threshold and Alarm Threshold
The statistics about the test packets that exceed the threshold are displayed in the NQA test result.
This provides a basis for the network administrators to analyze the operating status of the
specified service. The alarm information is sent to the NMS to report the change to the device.
6.5 Configuring the Trap Function
A device generates traps no matter whether the NQA test succeeds or fails. You can enable or
disable the trap function to determine whether the device sends traps to the NMS.
6.6 Scheduling an NQA Test Instance
After completing the configuration of an NQA test instance, you can schedule the NQA test
instance as required, for example, starting the NQA test instance.
6.7 Maintaining NQA
This section describes how to maintain an NQA test instance. You can restart the test instance
and clear the statistics on the test result to maintain a test instance.
This section provides NQA configuration examples. A networking diagram is provided to
demonstrate the configuration procedure in each example.
Configuration Guide - Network Management 6 NQA Configuration
102
6.1 NQA Overview
Network Quality Analysis (NQA) is a feature that monitors network performance in real time
and helps diagnose faults occurring on the network.
As increasing services and applications are deployed on the Internet, traditional network
performance analysis tools (such as Ping and Tracert) cannot meet customer requirements for
diversified services and real-time monitoring.
NQA sends test packets to analyze the network performance and quality of service. NQA can
provide various network performance parameters. Using NQA test results, you can:
l Obtain the network performance in real time and take measures to improve the network
performance.
l Diagnose the network and identify causes of network faults.
NQA can also be associated with Tracks module and application modules to monitors network
status in real time. You can take measures according to test results in a timely manner to avoid
communications interruption and ensure the service quality.
NQA has the following characteristics:
l Supports multiple test types.
NQA is an extension and enhancement of ping. The ping function uses the Internet Control
Message Protocol (ICMP) to measure the round-trip time (RTT) of packets traveling
between the source host and the destination host. NQA provides more functions than ping.
l Supports association function.
NQA provides test results for other modules so that other modules can take measures
according to test results. Currently, NQA can be associated with the Virtual Router
Redundancy Protocol (VRRP), static routes, backup interfaces, and policy-based routing
(PBR).
6.2 NQA Features Supported by the Device
This section describes the NQA test types supported by the device.
Cooperation Between NQA and NMS
l All NQA functions can be managed by the NMS.
l NQA Management Information Base (MIB) is supported.
l DISMAN-TRACEROUTE-MIB is supported.
l DISMAN-NSLOOKUP-MIB is supported.
l DISMAN-PING-MIB is supported.
Supported NQA Test Instances
l ICMP test
l ICMP jitter test
l TCP test
103
l UDP Jitter test
NQA Tests Supported by the Switch
Implementation of basic NQA test functions
You can perform an NQA test by 6.3 Configuring an NQA Test Instance and 6.6 Scheduling
an NQA Test Instance.
Implementation of extended NQA test functions
6.4 Configuring the NQA Transmission Delay Threshold and Alarm Threshold, 6.5
Configuring the Trap Function are extended NQA functions and are optional in NQA
configuration. You can configure NQA tests based on test requirements.
NOTE
Configuring the Trap Function cannot be performed for an ICMP jitter test instance.
6.3 Configuring an NQA Test Instance
You can configure an NQA test instance to perform an NQA test of a specified type.
l Starting the device
l Configuring routing to ensure reachable routes between devices involved in the test
NOTE
The pre-configuration tasks differ from different test instances. For details, see the configuration of each
test instance.
The following test instances are independent from each other. You can configure one or more
test instances as required.
6.3.1 Configuring an ICMP Test Instance
Context
Before configuring an ICMP test instance, configure reachable routes between the NQA client
and the tested device.
An ICMP test has the same function as the ping command but displays more detailed
information.
NOTE
Perform the following steps on the NQA client.
Procedure
Step 1 Run:
system-view
104
Step 2 Run:
nqa test-instance admin-name test-name
An NQA test instance is created, and the NQA view is displayed.
Step 3 Run:
test-type icmp
The test type is set to ICMP.
Step 4 Run:
destination-address ipv4 ipv4-address
The destination address is configured.
Step 5 (Optional) Run the following commands as required to configure parameters for the ICMP test.
l Run:
description string
A description is configured for the test instance.
l Run:
frequency interval
The test period is set for the NQA test instance.
l Run:
timeout time
The timeout period of a probe is set for the NQA test instance.
By default, the timeout period of a ICMP probe is 3 seconds.
l Run:
source-interface interface-type interface-number
The source interface that sends test packets is configured.
l Run:
source-address ipv4 ip-address
The source IP address is configured.
ip-address is similar to -a in the ping command.
l Run:
ttl number
The TTL value is set.
number is similar to -h in the ping command.
l Run:
datasize size
The size of Echo Request packets excluding the IP header is configured.
size is similar to -s in the ping command.
l Run:
datafill fillstring
The padding field is configured.
fillstring is similar to -p in the ping command.
l Run:
105
sendpacket passroute
The NQA test instance is configured to send packets without searching the routing table.
l Run:
probe-count number
The number of probes in a test is set.
l Run:
tos value
The type of service (ToS) field value in an IP header is configured.
value is similar to -tos in the ping command.
l Run:
fail-percent percent
The failure percentage is set for the NQA test instance.
l Run:
interval seconds interval
The interval at which test packets are sent is configured.
interval is similar to -m in the ping command.
l Run:
vpn-instance vpn-instance-name
The VPN instance name is configured.
l Run:
records history number
The maximum number of historical records is set for the NQA test instance.
l Run:
records result number
The maximum number of result records is set for the NQA test instance.
Step 6 Run:
commit
----End
6.3.2 Configuring an ICMP Jitter Test Instance
Context
Before configuring an ICMP jitter test, ensure that the NQA client and the tested device have
reachable routes to each other.
When configuring an ICMP jitter test instance, you can set the number of packets to be sent
consecutively in a single test. This configuration can simulate traffic of various types in a
specified period. For example, you can simulate voice service traffic through this configuration.
NOTE
Perform the following steps on the NQA client. The NQA client also functions as the ICMP jitter client.
106
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
test-type icmpjitter
The test type is set to ICMP Jitter.
Step 4 Run:
Step 5 Configure global parameters for the test instance to simulate network packets.
l Run:
icmp-jitter-mode { icmp-echo | icmp-timestamp }
An NQA ICMP jitter test instance is created.
l Run:
datafill fillstring
The padding field is configured.
l Run:
datasize size
The size of Echo Request packets without the IP header is configured.
l Run:
jitter-packetnum number
The number of packets sent each time in a probe is set.
l Run:
probe-count number
l Run:
interval { milliseconds interval | seconds interval }
The interval at which NQA test packets are sent is set.
l Run:
source-address ipv4 ipv4-address
The source IP address is set.
l Run:
ttl number
The TTL value in the NQA test packet is set.
l Run:
tos value
107
Type of Service (ToS) is set for the test packet.
Step 6 Run:
commit
----End
6.3.3 Configuring a TCP Test Instance
Context
Before configuring a TCP test instance, configure a TCP server and ensure reachable routes
between the TCP client and the TCP server.
An NQA TCP test measures the speed at which a TCP connection can be set up between an
NQA client and a TCP server through the three-way handshake.
NOTE
The NQA client also functions as the TCP client.
Procedure
l Configure the TCP server.
1. Run:
system-view
2. Run:
nqa server tcpconnect [ vpn-instance vpn-instance-name ] ip-address port-
number
The monitoring IP address and port number of the TCP server are configured.
l Configure the NQA client.
1. Run:
system-view
2. Run:
3. Run:
test-type tcp
The test type is set to TCP.
4. Run:
The destination IP address is configured.
5. (Optional) Run the following commands as required to configure parameters for the
TCP test.
108
Run:
description string
Run:
frequency interval
Run:
timeout time
Run:
destination-port port-number
The destination port number is configured.
Run:
Run:
source-port port-number
The source port number is configured.
Run:
ttl number
Run:
The NQA test instance is configured to send packets without searching the routing
table.
Run:
probe-count number
Run:
tos value
Type of Service (TOS) is set for the test packet.
Run:
Run:
interval seconds interval
The interval at which test packets are sent is configured.
Run:
Run:
109
Run:
6. Run:
commit
----End
6.3.4 Configuring a UDP Jitter Test Instance
Context
When configuring a UDP Jitter test instance, configure reachable routes between the UDP Jitter
client and the UDP Jitter server.
You can set the number of packets to be sent consecutively in each test instance. This
configuration is used to simulate certain traffic. For example, G.711 traffic can be simulated
within 1 minute by sending 3000 UDP packets at an interval of 20 milliseconds.
NOTE
Configuring NTP on the client and the server can effectively improve the accuracy of the test.
The NQA client also functions as the UDP Jitter client. The jitter obtained in this test is the UDP Jitter.
Perform the following steps on the NQA client.
Procedure
l Configure the UDP Jitter server.
1. Run:
system-view
2. Run:
nqa server udpecho [ vpn-instance vpn-instance-name ] ip-address port-
number
The monitoring IP address and port number of the UDP server are configured.
l Configure the NQA client.
1. Run:
system-view
2. (Optional) Run:
nqa jitter tag-version version-number
The version number is configured for Jitter packets.
By default, the version number of Jitter test packets is 1.
After setting the version number of the Jitter test packets to 2 and enabling the NQA
client to collect statistics about packet loss in one direction, you can view the number
of lost packets on the link from the source to the destination, from the destination to
110
the source, or from unknown directions. Based on these statistics, you can easily locate
network faults and detect malicious attacks.
3. Run:
4. Run:
test-type jitter
The test type is set to Jitter.
5. Run:
6. Run:
destination-port port-number
The destination port number is configured.
7. (Optional) Run the following commands as required to configure parameters for the
Jitter test:
Run:
description string
Run:
frequency interval
Run:
timeout time
Run:
Run:
source-port port-number
The source port number is configured.
Run:
ttl number
Run:
datasize size
The packet size is set for the NQA test instance.
Run:
datafill fillstring
The padding field is configured for the NQA test instance.
Run:
source-interface interface-type interface-number
111
The source interface that sends test packets is configured.
Run:
The NQA test instance is configured to send packets without searching the routing
table.
By default, the NQA test packets are sent with searching the routing table.
Run:
probe-count number
The number of probes in each test is set.
By default, the number of probes is 3.
Run:
tos value
Type of Service (TOS) is set for the test packet.
Run:
By default, the failure percentage is 100%, that is, the test is regarded failed only
when all the probes fail.
Run:
interval { milliseconds interval | seconds interval }
The interval at which test packets are sent is set.
A shorter interval enables a test to be complete sooner. Delays occur during the
sending and receiving of test packets on the processor. Therefore, if the interval
for sending test packets is short, the Jitter test results are inaccurate.
Run:
jitter-packetnum number
The number of test packets sent in each probe is set.
By default, 20 packets are sent each time in each test.
The Jitter test is used to collect and analyze the delay variation during the UDP
packet transmission. To improve the accuracy of the test result, the system sends
multiple test packets each time. The more test packets are sent, the more accurate
the statistics are, and the longer the test lasts.
NOTE
The probe-count command sets the number of Jitter probes and the jitter-packetnum
command sets the number of test packets sent during each probe. The product of probe
count multiplied by the number of test packets must be smaller than or equal to 3000.
Run:
jitter-codec { g711a | g711u | g729a }
The code type is configured for jitter tests of analog voice services.
This command is applied only to jitter tests of analog voice services.
Run:
adv-factor factor-value
The advantage factor is configured for analog voice test calculation.
This command is applied only to jitter tests of analog voice services.
112
Run:
Run:
Run:
8. Run:
commit
----End
Prerequisites
After completing NQA configuration, run the following commands to check the NQA
configuration.
Procedure
l Run the display nqa server command on the NQA server to check information about the
server.
----End
6.4 Configuring the NQA Transmission Delay Threshold
and Alarm Threshold
The statistics about the test packets that exceed the threshold are displayed in the NQA test result.
This provides a basis for the network administrators to analyze the operating status of the
specified service. The alarm information is sent to the NMS to report the change to the device.
Before configuring the NQA transmission threshold and alarm function, complete the following
tasks:
l Enabling the device
l Creating the NQA test instance and configuring related parameters
The configured NQA transmission threshold and Alarm Threshold help you obtain the statistics
about the test packet that exceed the thresholds in the test result. This improves the NQA function
and provides an optional configuration for NQA test.
113
The alarm information can be sent to the NMS only when the routes between the device and
NMS are reachable and the related configurations are completed.
Perform the following configurations on the NQA client.
6.4.1 Configuring the Two-Way Transmission Delay Threshold
Context
If the two-way transmission delay threshold is configured for an NQA test instance, the statistics
about the test packets that exceed the threshold are displayed in the test result. This provides a
basis for the network administrators to analyze the operating status of the specified service.
NOTE
This two-way transmission delay refers to the round-trip transmission delay.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The NQA view is displayed.
Step 3 Run:
threshold rtd rtd-value
The two-way transmission delay threshold is configured.
By default, no two-way transmission delay threshold is configured.
Step 4 Run:
commit
----End
6.4.2 Configuring the One-Way Transmission Delay Threshold
Context
In Jitter tests , after the one-way transmission delay threshold is configured, the test results show
statistics about the test packets of which the transmission exceeds the threshold. Network
administrators can analyze the operating status of the network according to the test results.
NOTE
The one-way transmission delay threshold can be configured only when the test-type is set to jitter.
You can perform either of Step 3 and Step 4 or both of them in any sequence.
114
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
threshold owd-sd owd-sd-value
The one-way transmission delay threshold (from the source to the destination) is configured.
By default, no one-way transmission delay threshold is configured.
Step 4 Run:
threshold owd-ds owd-ds-value
The one-way transmission delay threshold (from the destination to the source) is configured.
By default, no one-way transmission threshold is configured.
Step 5 Run:
commit
----End
6.5 Configuring the Trap Function
A device generates traps no matter whether the NQA test succeeds or fails. You can enable or
disable the trap function to determine whether the device sends traps to the NMS.
Context
NQA supports three types of traps as defined in DISMAN-PING-MIB. NQA also supports the
sending of traps to the NMS when the one-way or two-way transmission delay exceeds the
threshold.
l For all test instances, if the two-way transmission delay exceeds the threshold and the trap
function is enabled, traps are sent to the NMS with the specified IP address.
l During a jitter test, if the one-way delay from the source to the destination or from the
destination to the source exceeds the threshold and the trap function is enabled, the NQA
client sends a trap message to the specified NMS IP address.
Traps carry the following information: destination IP addresses, operating status, destination IP
address of the test packet, minimum RTT, maximum RTT, total RTT, number of sent probe
packets, number of received packets, RTT square sum, and time of the latest successful probe.
Before configuring the trap function of the NQA test, complete the following tasks:
115
l Configuring reachable routes between the NQA client and the NMS
l Creating the NQA test instance and configuring related parameters
The following configuration is a supplement to NQA tests. All configurations are optional.
The configurations take effect after the NQA alarm function is enabled.
NOTE
6.5.1 Enabling the NQA Alarm Function
Context
After the NQA alarm function is enabled, the device sends alarms to the NMS.
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent trap enable feature-name nqa [ trap-name
{ nqajitterstatsowdthresholdnotificationds |
nqajitterstatsowdthresholdnotificationsd | nqajitterstatsrtdthresholdnotification
| nqajitterstatstestfailed | nqaresultsprobefailed | nqaresultstestcompleted |
nqaresultstestfailed | nqaresultsthresholdnotification | pingprobefailed |
pingtestcompleted | pingtestfailed | traceroutetestcompleted |
traceroutetestfailed } ]
The alarm function is enabled for the NQA module.
By default, the alarm function is enabled for the NQA module.
Step 3 Run:
commit
----End
6.5.2 Configuring the NQA Client to Send Traps When a Test Fails
Procedure
Step 1 Run:
system-view
Step 2 Run:
116
Step 3 Run:
send-trap testfailure
The NQA client is configured to send traps when the test fails.
By default, the NQA client sends no trap when an NQA test fails.
Step 4 Run:
test-failtimes times
The threshold on the traps sent after the NQA test fails is configured, The threshold specifies
maximum number of continuous test failures for the NQA test instance.
By default, a trap is sent for each test failure.
Step 5 Run:
commit
----End
6.5.3 Configuring the NQA Client to Send Traps When a Probe Fails
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
send-trap probefailure
The NQA client is configured to send traps when a probe fails.
By default, the NQA client sends no trap when a probe fails.
Step 4 Run:
probe-failtimes times
The threshold on the traps sent after the probe fails is configured, The threshold specifies
maximum number of continuous probe failures for the NQA test instance.
By default, a trap is sent for each probe failure.
Step 5 Run:
commit
----End
117
6.5.4 Configuring the NQA Client to Send Traps After a Probe
Succeeds
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
send-trap testcomplete
The NQA client is configured to send traps when a probe succeeds.
By default, the NQA client sends no trap when a probe succeeds.
Step 4 Run:
commit
----End
6.5.5 Configuring the NQA Client to Send Traps When the
Transmission Delay Exceeds the Threshold
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
send-trap { owd-ds | owd-sd | rtd }*
The NQA client is configured to send traps when the transmission delay exceeds the threshold.
By default, the NQA client sends no trap when the transmission delay exceeds the threshold.
NOTE
Parameters owd-ds and owd-sd can be configured only for jitter test instances.
Step 4 Run:
commit
118
----End
Context
After configuring the trap function, check the alarm information.
Procedure
l Run the display snmp-agent trap feature-name nqa all command to check status of all
traps on the NQA module.
----End
6.6 Scheduling an NQA Test Instance
After completing the configuration of an NQA test instance, you can schedule the NQA test
instance as required, for example, starting the NQA test instance.
Before scheduling an NQA test instance, complete the following tasks:
l Configuring the server
l Configuring an NQA test instance on the client
l Configuring reachable routes between the server and the client
NOTE
6.6.1 Starting an NQA Test Instance
Context
After completing the configuration of an NQA test instance, start the NQA test instance in
following modes:
l Start the NQA test instance immediately.
l Start the NQA test instance at a specified time.
l Start the NQA test instance after a delay.
If the test fails, restart the NQA test instance in the next time period.
119
NOTE
l If the number of running test instances reaches the maximum value defined by the system, the start
command is invalid.
l For the same test instance, the start now command can be used again only when the previous test is
complete.
l The specified time to start a test instance must be later than the current time of the device.
Procedure
l Start an NQA test instance.
1. Run:
system-view
2. Run:
3. Run:
start
The NQA test instance is started.
Run:
start now [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay { seconds second
| hh:mm:ss } | lifetime { seconds second | hh:mm:ss } } ]
The NQA test instance is started immediately.
Run:
start at [ yyyy/mm/dd ] hh:mm:ss [ end { at [ yyyy/mm/dd ] hh:mm:ss |
delay { seconds second | hh:mm:ss } | lifetime { seconds second |
hh:mm:ss } } ]
The NQA test instance is started in a specified time.
Run:
start delay { seconds second | hh:mm:ss } [ end { at [ yyyy/mm/dd ]
hh:mm:ss | delay { seconds second | hh:mm:ss } | lifetime { seconds
second | hh:mm:ss } } ]
The NQA test instance is started after a specified delay.
Run:
start daily hh:mm:ss to hh:mm:ss [ begin yyyy/mm/dd ] [ end yyyy/mm/
dd ]
The NQA test instance is started at a fixed time every day.
4. Run:
commit
l Restart an NQA test instance.
1. Run:
system-view
2. Run:
120
3. Run:
restart
Then NQA test instance is restarted.
NOTE
l The restart command stops the running test instance and restart it.
l The restart command functions the same as the start now command.
4. Run:
commit
----End
6.6.2 (Optional) Stopping an NQA Test Instance
Context
A running NQA test instance can stop in the following modes:
l The test stops automatically after all test packets are sent.
l Stop the NQA test instance at a specified time.
l Stop the NQA test instance after a delay.
l Start a test instance and stop it at specified time every day.
Stop a running NQA test instance using either of the following commands:
l Run the undo start command to stop the running NQA test instance.
l Run the stop command to stop the running NQA test instance.
Procedure
l Run the undo start command.
1. Run:
system-view
2. Run:
3. Run:
undo start
The running NQA test instance is stopped.
4. Run:
commit
l Run the stop command.
121
1. Run:
system-view
2. Run:
3. Run:
stop
The running NQA test instance is stopped.
4. Run:
commit
----End
6.6.3 Checking Test Results
Prerequisites
An NQA test instance has been configured and the NQA test has been completed.
NOTE
l The display nqa results command displays the test results of only the test instances that have been
completed.
l The display nqa results collection command displays accumulative results of all test instances. Only
the jitter tests support the query of accumulative results.
l Failed Jitter tests are not recorded in the historical records.
Procedure
l Run the display nqa results [ collection ] [ test-instance admin-name test-name ]
command to check NQA test results.
l Run the display nqa history [ test-instance admin-name test-name ] command to check
the historical records of NQA test instances.
l Run the display nqa results this command to check results of an NQA test in the specified
test instance view.
l Run the display nqa history this command to check historical records of NQA tests in the
specified test instance view.
----End
6.7 Maintaining NQA
This section describes how to maintain an NQA test instance. You can restart the test instance
and clear the statistics on the test result to maintain a test instance.
122
6.7.1 Clearing NQA Test Statistics
Context
To obtain the latest test results, clear the current test results by running the following commands.
CAUTION
l Statistics cannot be restored after being cleared. Confirm the action before you run the
commands.
l Statistics on the running test instance cannot be cleared.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
clear-records
The statistics about NQA test instances are cleared.
----End
This section provides NQA configuration examples. A networking diagram is provided to
demonstrate the configuration procedure in each example.
6.8.1 Example for Configuring an ICMP Test Instance
As shown in Figure 6-1, SwitchA, SwitchB, and SwitchC communicate at Layer 3 using
VLANIF interfaces.
SwitchA functions as an NQA client to test whether SwitchB is reachable.
Figure 6-1 Networking diagram for configuring an ICMP test instance
10GE1/0/1
VLANIF10
20.20.20.1/24
VLANIF10
20.20.20.2/24
10GE1/0/1
SwitchA
SwitchB
NQA agent
123

1. Configure an NQA ICMP test instance to test whether the route between the local device
(SwitchA) and the specified destination device (SwitchB) is reachable and check the RTT
of a test packet.
Procedure
Step 1 Create VLANs and add interfaces to the VLANs.
# Configure SwitchA.
<Huawei> system-view
[~Huawei] sysname SwitchA
[~Huawei] commit
[~SwitchA] vlan 10
[~SwitchA-10GE1/0/1] commit
# Configure SwitchB.
[~Huawei] sysname SwitchB
[~Huawei] commit
[~SwitchB] vlan 10
[~SwitchB-vlan10] quit
[~SwitchB] interface 10ge 1/0/1
[~SwitchB-10GE1/0/1] port link-type trunk
[~SwitchB-10GE1/0/1] port trunk pvid vlan 10
[~SwitchB-10GE1/0/1] port trunk allow-pass vlan 10
[~SwitchB-10GE1/0/1] commit
[~SwitchB-10GE1/0/1] quit
Step 2 Create VLANIF interfaces and assign IP addresses to the VLANIF interfaces.
[~SwitchA-Vlanif10] commit
[~SwitchB] interface vlanif 10
[~SwitchB-Vlanif10] ip address 20.20.20.2 24
[~SwitchB-Vlanif10] commit
[~SwitchB-Vlanif10] quit
Step 3 Enable the NQA client and create an ICMP NQA test instance.
[~SwitchA] nqa test-instance admin icmp
[~SwitchA-nqa-admin-icmp] test-type icmp
[~SwitchA-nqa-admin-icmp] destination-address ipv4 20.20.20.2
[~SwitchA-nqa-admin-icmp] commit
Step 4 Start the test instance immediately.
[~SwitchA-nqa-admin-icmp] start now
[~SwitchA-nqa-admin-icmp] commit
124
[~SwitchA-nqa-admin-icmp] display nqa results test-instance admin icmp

NQA entry(admin, icmp) :test flag is active ,test type is ICMP
1 . Test 1 result The test is finished
Send operation times: 3 Receive response times: 3
Completion:success RTD over thresholds number:0
Attempts number:1 Drop operation number:0
Disconnect operation number:0 Operation timeout number:0
System busy operation number:0 Connection fail number:0
Operation sequence errors number:0 RTT stats errors number:0
Destination IP address:20.20.20.2
Min/Max/Average completion time: 2/5/3
Sum/Square-Sum completion time: 9/33
Last response packet receiving time: 2012-08-08
15:53:08.4
Lost packet ratio: 0 %
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
interface Vlanif10
ip address 20.20.20.1 255.255.255.0
#
interface 10GE1/0/1
#
nqa test-instance admin icmp
test-type icmp
destination-address ipv4 20.20.20.2
start now
#
return
#
sysname SwitchB
#
vlan batch 10
#
interface Vlanif10
ip address 20.20.20.2 255.255.255.0
#
interface 10GE1/0/1
#
return
6.8.2 Example for Configuring an ICMP Jitter Test Instance
As shown in Figure 6-2, SwitchA, SwitchB, and SwitchC communicate at Layer 3 using
VLANIF interfaces.
125
SwitchA functions as the NQA client to test the jitter of the network between SwtichA and
SwtichB.
Figure 6-2 Networking diagram for configuring an ICMP jitter test instance
10GE1/0/1
VLANIF10
20.20.20.1/24
VLANIF10
20.20.20.2/24
10GE1/0/1
SwitchA
SwitchB
NQA agent

1. Configure SwtichA as an NQA client and create an ICMP jitter test instance on SwtichA.
Procedure
Step 1 Create VLANs and add interfaces to the VLANs.
[~Huawei] commit
[~SwitchA] vlan 10
[~SwitchA-10GE1/0/1] commit
[~Huawei] sysname SwitchB
[~Huawei] commit
[~SwitchB] vlan 10
[~SwitchB-vlan10] quit
[~SwitchB] interface 10ge 1/0/1
[~SwitchB-10GE1/0/1] port link-type trunk
[~SwitchB-10GE1/0/1] port trunk pvid vlan 10
[~SwitchB-10GE1/0/1] port trunk allow-pass vlan 10
[~SwitchB-10GE1/0/1] commit
[~SwitchB-10GE1/0/1] quit
Step 2 Create VLANIF interfaces and assign IP addresses to the VLANIF interfaces.
[~SwitchA-Vlanif10] commit
[~SwitchB] interface vlanif 10
[~SwitchB-Vlanif10] ip address 20.20.20.2 24
126
[~SwitchB-Vlanif10] commit
[~SwitchB-Vlanif10] quit
Step 3 # Enable the NQA client and create an ICMP jitter NQA test instance.
[~SwitchA] nqa test-instance admin icmpjitter
[~SwitchA-nqa-admin-icmpjitter] test-type icmpjitter
[~SwitchA-nqa-admin-icmpjitter] destination-address ipv4 20.20.20.2
[~SwitchA-nqa-admin-icmpjitter] commit
Step 4 Start the test instance immediately.
[~SwitchA-nqa-admin-icmpjitter] start now
[~SwitchA-nqa-admin-icmpjitter] commit
[~SwitchA-nqa-admin-icmpjitter] display nqa results test-instance admin icmpjitter
[~SwitchA-nqa-admin-icmpjitter] display nqa results test-instance admin
icmpjitter

NQA entry(admin, icmpjitter) :test flag is active ,test type is ICMPJITTER
SendProbe:60 ResponseProbe:60
OWD over thresholds SD number:0 OWD over thresholds DS number:0
Min/Max/Avg/Sum RTT:1/89/5/312 RTT square sum:17032
Num Of RTT:60 Drop operation number:0
System busy operation number:0 Operation timeout number:0
Min positive SD:0 Min positive DS:6
Max positive SD:0 Max positive DS:19
Positive SD number:0 Positive DS number:55
Positive SD sum:0 Positive DS sum:987
Positive SD square Sum:0 Positive DS square sum:17869
Min negative SD:15 Min negative DS:2
Max negative SD:19 Max negative DS:2
Negative SD number:59 Negative DS number:4
Negative SD sum:1067 Negative DS sum:8
Negative SD square sum:19315 Negative DS square sum:16
Min delay SD:1 Min delay DS:0
Max delay SD:89 Max delay DS:6
Delay SD square sum:16906 Delay DS square sum:36
Packet loss SD:0 Packet loss DS:0
Packet loss unknown:0 Average of jitter:0
Average of jitter SD:0 Average of jitter DS:0
Jitter out value:0.0000000 Jitter in value:0.0000000
Number Of OWD:0 Packet loss Ratio:0 %
OWD SD sum:0 OWD DS sum:0
ICPIF value:0 MOS-CQ value:0
TimeStamp unit:ms
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 10
#
interface Vlanif10
ip address 20.20.20.1 255.255.255.0
#
interface 10GE1/0/1
127
#
nqa test-instance admin icmpjitter
test-type icmpjitter
start now
#
return
#
sysname SwitchB
#
vlan batch 10
#
interface Vlanif10
ip address 20.20.20.2 255.255.255.0
#
interface 10GE1/0/1
#
return
6.8.3 Example for Configuring a TCP Test Instance
The NQA TCP test instance is used to obtain the time for setting up a TCP connection between
SwitchA and SwitchC, as shown in the Figure 6-3.
Figure 6-3 Networking diagram for configuring a TCP test instance
SwitchA
10GE1/0/1
VLANIF100
10.1.1.1/24
VLANIF100
10.1.1.2/24
VLANIF110
10.2.1.2/24
VLANIF110
10.2.1.1/24
10GE1/0/1 10GE1/0/2 10GE1/0/2
SwitchC SwitchB
NQA Server

1. Configure switchA as an NQA client and SwtichC as an NQA server.
2. Configure the monitoring port number on the NQA server and create an NQA TCP test
instance on the NQA client.
Procedure
Step 1 Configure each interface and ensure reachable routes between Switches, as shown in Figure
6-3.
128
[~Huawei] commit
[~SwitchA] vlan 100
[~SwitchA] quit
[~SwitchA] ip route-static 10.2.1.0 24 10.1.1.2
[~SwitchA] commit
NOTE
For configurations of SwitchB and SwitchC, see the configuration files.
Step 2 Configure the NQA server on SwitchC.
# Configure the IP address and port number for monitoring TCP connections on the NQA server.
[~SwitchC] nqa server tcpconnect 10.2.1.2 9000
[~SwitchC] commit
Step 3 Configure SwitchA.
# Enable the NQA client and create a TCP Private test instance.
[~SwitchA] nqa test-instance admin tcp
[~SwitchA-nqa-admin-tcp] test-type tcp
[~SwitchA-nqa-admin-tcp] destination-address ipv4 10.2.1.2
[~SwitchA-nqa-admin-tcp] destination-port 9000
[~SwitchA-nqa-admin-tcp] commit
Step 4 Start the test instance.
[~SwitchA-nqa-admin-tcp] start now
[~SwitchA-nqa-admin-tcp] commit
[~SwitchA-nqa-admin-tcp] display nqa results test-instance admin tcp

NQA entry(admin, tcp) :test flag is active ,test type is TCP
Send operation times: 3 Receive response times: 3
Attempts number:1 Drop operation number:0
Disconnect operation number:0 Operation timeout number:0
System busy operation number:0 Connection fail number:0
Destination IP address:10.2.1.2
Min/Max/Average completion time: 103/133/114
Sum/Square-Sum completion time: 343/39747
Last response packet receiving time: 2012-08-09
00:24:06.1
Lost packet ratio: 0 %
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100
129
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
#
interface 10GE1/0/1
#
nqa test-instance admin tcp
test-type tcp
destination-port 9000
start now
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
return
#
sysname SwitchB
#
vlan batch 100 110
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif110
ip address 10.2.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
#
sysname SwitchC
#
vlan batch 110
#
interface Vlanif110
ip address 10.2.1.2 255.255.255.0
#
interface 10GE1/0/2
#
nqa server tcpconnect 10.2.1.2 9000
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.1
#
return
130
6.8.4 Example for Configuring a UDP Jitter Test Instance
The NQA jitter test instance is used to obtain the jitter time of transmitting a packet from SwitchA
to SwitchC, as shown in Figure 6-4.
Figure 6-4 Networking diagram for configuring a UDP Jitter test instance
SwitchA
10GE1/0/1
VLANIF100
10.1.1.1/24
VLANIF100
10.1.1.2/24
VLANIF110
10.2.1.2/24
VLANIF110
10.2.1.1/24
10GE1/0/1 10GE1/0/2 10GE1/0/2
SwitchC SwitchB
NQA Server

1. Configure SwitchA as an NQA client and SwtichC as an NQA server.
2. Configure the monitoring IP address and port number on the NQA server, and configure a
jitter test instance on the NQA client.
Procedure
Step 1 Configure each interface and ensure reachable routes between Switches, as shown in Figure
6-4.
[~Huawei] commit
[~SwitchA] vlan 100
[~SwitchA] quit
[~SwitchA] ip route-static 10.2.1.0 24 10.1.1.2
[~SwitchA] commit
NOTE
For configurations of SwitchB and SwitchC, see the configuration files.
Step 2 Configure the NQA server on SwitchC.
# Configure the IP address and port number for monitoring UDP services on the NQA server.
131
[~SwitchC] nqa server udpecho 10.2.1.2 9000
[~SwitchC] commit
Step 3 Configure SwitchA.
# Enable the NQA client and create an NQA jitter test instance.
[~SwitchA] nqa test-instance admin jitter
[~SwitchA-nqa-admin-jitter] test-type jitter
[~SwitchA-nqa-admin-jitter] destination-address ipv4 10.2.1.2
[~SwitchA-nqa-admin-jitter] destination-port 9000
[~SwitchA-nqa-admin-jitter] commit
Step 4 Start the test instance.
[~SwitchA-nqa-admin-jitter] start now
[~SwitchA-nqa-admin-jitter] commit
[~SwitchA-nqa-admin-jitter] display nqa results test-instance admin jitter

NQA entry (admin, jitter) :test flag is active ,test type is
JITTER
SendProbe:60 ResponseProbe:60
OWD over thresholds SD number:0 OWD over thresholds DS number:0
Min/Max/Avg/Sum RTT:2/50/5/282 RTT square sum:4940
Num Of RTT:60 Drop operation number:0
System busy operation number:0 Operation timeout number:0
Min positive SD:1 Min positive DS:1
Max positive SD:1 Max positive DS:1
Positive SD number:11 Positive DS number:20
Positive SD sum:11 Positive DS sum:20
Positive SD square sum:11 Positive DS square sum:20
Min negative SD:1 Min negative DS:1
Max negative SD:11 Max negative DS:16
Negative SD number:13 Negative DS number:20
Negative SD sum:27 Negative DS sum:51
Negative SD square sum:157 Negative DS square sum:505
Min delay SD:1 Min delay DS:1
Max delay SD:25 Max delay DS:24
Delay SD square sum:1163 Delay DS square sum:1067
Packet loss SD:0 Packet loss DS:0
Packet loss unknown:0 Average of jitter:1
Average of jitter SD:1 Average of jitter DS:1
Jitter out value:0.4972660 Jitter in value:1.0068400
Number Of OWD:60 Packet loss ratio:0 %
OWD SD sum:123 OWD DS sum:99
ICPIF value:0 MOS-CQ value:438
TimeStamp unit: ms
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100
#
interface Vlanif100
ip address 10.1.1.1 255.255.255.0
#
interface 10GE1/0/1
132
#
nqa test-instance admin jitter
test-type jitter
destination-port 9000
start now
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
return
#
sysname SwitchB
#
vlan batch 100 110
#
interface Vlanif100
ip address 10.1.1.2 255.255.255.0
#
interface Vlanif110
ip address 10.2.1.1 255.255.255.0
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
#
sysname SwitchC
#
vlan batch 110
#
interface Vlanif110
ip address 10.2.1.2 255.255.255.0
#
interface 10GE1/0/2
#
nqa server udpecho 10.2.1.2 9000
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.1
#
return
133
7 LLDP Configuration
About This Chapter
The Link Layer Discovery Protocol (LLDP) allows you to obtain details about the network
topology, changes in the topology, and detect incorrect configurations on the network.
7.1 LLDP Overview
LLDP is a standard link-layer protocol. An LLDP-capable device encapsulates main device
information into LLDP packets and sends the LLDP packets to its neighbors. When receiving
the LLDP packets, neighbors save the information carried in the LLDP packets to the
management information base (MIB). The NMS queries and determines link status based on
information in the MIB.
This section describes the default LLDP configuration.
7.3 Configuring Basic LLDP Functions
When LLDP is configured on devices, the NMS can obtain detailed Layer 2 information such
as the network topology, device interface status, and management address.
7.4 Configuring the LLDP Alarm Function
This section describes how to configure the LLDP alarm function on a network device, so that
the device can send alarms to the NMS when information about neighbors changes.
7.5 Maintenance LLDP
This section describes how to clear LLDP statistics and monitor LLDP status.
This section provides several configuration examples of LLDP, including networking
requirements and configuration roadmap.
Configuration Guide - Network Management 7 LLDP Configuration
134
7.1 LLDP Overview
LLDP is a standard link-layer protocol. An LLDP-capable device encapsulates main device
information into LLDP packets and sends the LLDP packets to its neighbors. When receiving
the LLDP packets, neighbors save the information carried in the LLDP packets to the
management information base (MIB). The NMS queries and determines link status based on
information in the MIB.
The network scale develops quickly, network device types are increasing, and their
configurations are complicated. The NMS is required to have more functions and higher
processing capability. The traditional NMS can only analyze Layer 3 network topologies and
cannot obtain details about the Layer 2 network topology or detect configuration conflicts. To
overcome this limitation, a standard Layer 2 information exchange protocol is needed.
The LLDP protocol provides a standard link-layer discovery method. Based on Layer 2
information obtained using LLDP, the NMS can quickly detect configuration conflicts between
devices and locate network faults. Users can use the NMS to monitor link status of LLDP-enabled
devices and quickly locate faults on the network.
This section describes the default LLDP configuration.
Table 7-1 describes the default LLDP configuration.
Table 7-1 Default LLDP configuration
Parameter Default Setting
Interval between sending LLDP packets 30 seconds
Delay in sending LLDP packets 2 seconds
Hold time multiplier of device information on
neighbors
4
Delay in initializing interfaces 2 seconds
Delay in sending a notification after neighbor
information changes
5 seconds

7.3 Configuring Basic LLDP Functions
When LLDP is configured on devices, the NMS can obtain detailed Layer 2 information such
as the network topology, device interface status, and management address.
Before configuring LLDP, ensure that the local device and NMS are reachable to each other,
and configure the Simple Network Management Protocol (SNMP).
135
7.3.1 Enabling LLDP
Context
The LLDP function enables a device to send LLDP packets with local system status information
to neighbors and parse LLDP packets received from neighbors. The NMS obtains Layer 2
connection status from the device to analyze the network topology.
Procedure
Step 1 Run:
system-view
Step 2 Run:
lldp enable
LLDP is enabled globally.
By default, LLDP is disabled globally.
Step 3 Run:
commit
----End
7.3.2 (Optional) Disabling LLDP on an Interface
Context
LLDP can be enabled in the system view and the interface view.
l When LLDP is enabled in the system view, LLDP is enabled on all interfaces.
l When LLDP is disabled in the system view, LLDP is disabled on all interfaces.
l An interface can send and receive LLDP packets only after LLDP is enabled in both the
system view and the interface view.
l After LLDP is disabled globally, the commands for enabling and disabling LLDP on an
interface do not take effect.
l If LLDP needs to be disabled on some interfaces, enable LLDP globally first, and run the
lldp disable command on these interfaces. To re-enable LLDP on these interfaces, run the
undo lldp disable command in the views of these interfaces.
NOTE
l Only physical interfaces support LLDP. Logical interfaces such as the VLANIF and Eth-Trunk
interfaces do not support LLDP.
l On an Eth-Trunk, LLDP can only be enabled on member interfaces. LLDP status of a member
interface does not affect that of another.
136
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
lldp disable
LLDP is disabled on the interface.
Step 4 Run:
commit
----End
7.3.3 (Optional) Configuring an LLDP Management Address
Context
The management address of a device is carried in the Management Address TLV field of the
LLDP packet. The NMS uses management addresses to identify and manage devices.
If no management address is configured or the configured management address is invalid, the
system sets an IP address in the address list as the management address. The system selects the
IP address in the following sequence: loopback interface address, console port address, and
VLANIF interface address. Among the IP addresses of the same type, the system selects the
smallest one. If the system does not find a management IP address, the bridge MAC address is
used as the management address.
Procedure
Step 1 Run:
system-view
Step 2 Run:
lldp management-address ip-address
The LLDP management address is configured.
The value of ip-address must be a valid unicast IP address existing on the device.
Step 3 Run:
commit
----End
137
7.3.4 (Optional) Configuring LLDP Time Parameters
Context
Interval between sending LLDP packets
When the LLDP status of the device keeps unchanged, the device sends LLDP packets to the
neighbors at a certain interval.
Consider the value of delay when adjusting the value of interval because it is restricted by the
value of delay.
l The value of interval ranges from 5 to 32768. Increasing the value of interval is not
restricted by the value of delay.
l The value of interval must be equal to or greater than four times the value of delay.
Therefore, if you want to set interval to be smaller than four times the value of delay, first
reduce the delay value to be equal to or smaller than a quarter of the new interval value,
and then reduce the interval value.
Delay in sending LLDP packets
There is a delay before the device sends an LLDP packet to the neighbor when the device status
changes frequently.
Consider the value of interval when adjusting the value of delay because it is restricted by the
value of interval.
l The value of delay ranges from 1 to 8192. Decreasing the value of delay is not restricted
by the value of interval.
l The value of delay must be smaller than or equal to a quarter of interval. Therefore, if you
want to set delay to be greater than a quarter of interval, first increase the interval value to
four times the new delay value, and then increase the delay value.
Hold time multiplier of device information on neighbors
The hold time multiplier is used to calculate the Time to Live (TTL), which determines how
long information about a device can be saved on the neighbors. You can specify the storage time
of device information on the neighbors. After receiving an LLDP packet, a neighbor updates the
aging time of the device information from the sender based on the TTL.
The storage time calculation formula is: TTL = Min (65535, (interval x hold)).
l TTL is the device information storage time. It is the smaller value between 65535 and
(interval x hold).
l interval indicates the interval at which the device sends LLDP packets to neighbors.
l hold indicates the hold time multiplier of device information on neighbors. The value ranges
from 2 to 10.
Procedure
Step 1 Run:
system-view
Step 2 Run:
lldp transmit interval interval
138
The interval between sending LLDP packets is set.
The default interval between sending LLDP packets is 30 seconds.
Step 3 Run:
lldp transmit delay delay
The delay in sending LLDP packets is set.
The default delay in sending LLDP packets is 2 seconds.
Step 4 Run:
lldp transmit multiplier hold
The hold time multiplier of device information stored on neighbors is set.
The default hold time multiplier is 4.
Step 5 Run:
commit
----End
7.3.5 (Optional) Configuring the Delay in Initializing Interfaces
Context
The delay in initializing interfaces is the delay before LLDP is re-enabled on an interface. The
delay suppresses the topology flapping caused by the frequent LLDP status changes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
lldp restart delay
The delay in initializing interfaces is set.
The default delay is 2 seconds.
Step 3 Run:
commit
----End
7.3.6 (Optional) Configuring the Type of TLVs that an Interface Can
Send
139
Context
TLVs that can be encapsulated into an LLDPDU include basic TLVs, TLVs defined by IEEE
802.1, TLVs defined by IEEE 802.3, and DCBX TLVs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
lldp tlv-enable { dot1-tlv protocol-identity | dcbx }
Types of TLVs allowed to be advertised by LLDP are configured.
By default, all TLVs except DCBX TLVs and Protocol Identity TLVs are allowed to be
advertised by LLDP.
NOTE
CE5800 does not support DCBX TLVs.
To disable LLDP on an interface from advertising any TLVs except DCBX TLVs and Protocol Identity
TLVs, run the lldp tlv-disable command.
Step 4 Run:
commit
----End
7.3.7 (Optional) Configuring the Number of LLDP Packets Quickly
Sent by the Device to a Neighbor
Context
When the device discovers a neighbor, LLDP status changes from disabled to enabled on the
device, or the status of interfaces on the device changes from Down to Up, the device quickly
sends a specified number of LLDP packets to the neighbor to notify it of local device information.
The device sends one LLDP packet to the neighbor per second without any delay. After sending
the specified number of LLDP packets, the device sends LLDP packets to the neighbor at the
interval set in the lldp trasmit interval interval command.
Procedure
Step 1 Run:
system-view
140
Step 2 Run:
lldp fast-count count
The number of LLDP packets being sent in quick succession to neighbors is configured.
By default, the number of LLDP packets being sent in quick succession to neighbors is 4.
Step 3 Run:
commit
----End
7.3.8 (Optional) Configuring MDN
Context
MDN obtains the MAC addresses of non-Huawei devices. As shown in Figure 7-1, SwitchA is
a Huawei device and SwitchB is a non-Huawei device. After MDN is configured on SwitchA,
SwitchA can receive non-Link Layer Discovery Protocol (LLDP) packets from SwitchB and
obtain SwitchB's MAC address carried in the packets. The MDN function helps the NMS draw
the network topology between SwitchA and SwitchB.
Figure 7-1 Networking diagram for MDN application
NMS
LLDP interface
NMS: Network Management System
SNMP packet
Non-LLDP packet
S
N
M
P

SwitchA
SwitchB
Procedure
l Enable MDN globally.
1. Run:
system-view
141
2. Run:
lldp mdn enable (system view)
MDN is enabled globally.
By default, the MDN function is disabled globally.
NOTE
After MDN is enabled globally, the MDN function takes effect on all interfaces on the device.
3. Run:
commit
l Enable MDN on an interface.
1. Run:
system-view
2. Run:
3. Run:
lldp mdn enable (interface view)
MDN is enabled on the interface.
By default, if MDN is enabled globally, the MDN function takes effect on all interfaces
on the device. If MDN is disabled globally, the MDN function does not take effect on
any interface.
NOTE
If the undo lldp mdn enable (interface view) command is configured on a specified interface,
the MDN function on the interface is disabled but uses the global configuration in the
configuration file. If MDN is enabled globally, the interface still has this function enabled. If
MDN is disabled globally, the interface has this function disabled.
4. Run:
commit
l Disable the MDN function on a specified interface after MDN is enabled globally.
1. Run:
system-view
2. Run:
3. Run:
lldp mdn disable
The MDN function is disabled on the interface.
142
4. Run:
commit
----End
Procedure
l Run the display lldp local [ interface interface-type interface-number ] command to view
LLDP local information on a specified interface or all interfaces.
l Run the display lldp neighbor [ interface interface-type interface-number ] command to
view neighbor information in the system or on an interface.
l Run the display lldp neighbor brief command to view brief information about neighbors.
l Run the display lldp tlv-config [ interface interface-type interface-number ] command to
view TLV types supported by the entire system or an interface.
l Run the display lldp mdn local [ interface interface-type interface-number ] command to
view MDN status in the system or on an interface.
l Run the display lldp mdn neighbor [ interface interface-type interface-number ]
command to view MDN neighbor status in the system or on an interface.
----End
7.4 Configuring the LLDP Alarm Function
This section describes how to configure the LLDP alarm function on a network device, so that
the device can send alarms to the NMS when information about neighbors changes.
Before configuring the LLDP alarm function, complete the following task:
l Configuring reachable routes between devices and the NMS, and SNMP parameters
Configuration Procedures
To avoid network flapping caused by frequent LLDP alarms being sent to the NMS, configure
a delay for the device to send alarms.
After the LLDP alarm function is configured on a device, the device sends alarms to the NMS
when information about neighbors changes.
7.4.1 Setting the Delay in Sending Traps About Neighbor
Information Changes
143
Context
There is a delay before the device sends LLDP traps about neighbor information changes to the
NMS. When neighbor information changes frequently, extend the delay to prevent the device
from sending traps to the NMS too frequently. This suppresses the topology flapping.
The configured delay applies only to the trap, which reports changes in neighbor information,
including the number of added neighbors, number of deleted neighbors, number of neighbors
that are aged out, and number of neighbors of which the information is deleted.
Procedure
Step 1 Run:
system-view
Step 2 Run:
lldp trap-interval interval
The delay in sending neighbor change traps to the NMS is set.
The default delay in sending neighbor change traps to the NMS is 5 seconds.
Step 3 Run:
lldp mdn trap-interval interval
The delay in sending MDN neighbor change traps to the NMS is set.
By default, the delay for a device to send alarms about MDN neighbor information changes to
the NMS is 5 seconds.
Step 4 Run:
commit
----End
7.4.2 Enabling the LLDP Trap Function
Context
After the LLDP trap function is enabled, the device sends traps to the NMS in one of the following
cases:
l MDN Neighbor information changes.
l Neighbor information changes. No trap is generated if the management address of a
neighbor changes.
144
NOTE
l The LLDP trap function applies to all interfaces. The LLDP trap function takes effect no matter whether
LLDP is enabled globally.
l If the network topology is unstable, disable the LLDP trap function to prevent frequent trap sending.
l To set the interval between sending neighbor change traps to the NMS, run the lldp trap-interval and
lldp mdn trap-interval commands. If neighbor information changes frequently, extend the interval to
reduce the number of traps. In this way, network topology flapping is suppressed.
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent trap enable feature-name lldp [ trap-name { hwlldpmdnremtableschange |
lldpremtableschange } ]
The LLDP trap function is enabled.
By default, the hwlldpmdnremtableschange trap is disabled, and the lldpremtableschange trap
is enabled.
Step 3 Run:
commit
----End
Prerequisites
All configurations for the LLDP alarm function are complete.
Procedure
l Run the display snmp-agent trap feature-name lldp all command to view status of all
traps on the LLDP module.
l Run the display lldp local [ interface interface-type interface-number ] command to view
LLDP status in the system or on an interface.
l Run the display lldp mdn local [ interface interface-type interface-name ] command to
view MDN status in the system or on an interface.
----End
7.5 Maintenance LLDP
This section describes how to clear LLDP statistics and monitor LLDP status.
7.5.1 Clearing LLDP Statistics
145
Context
CAUTION
Statistics cannot be restored after being cleared. Therefore, exercise caution when you run the
following commands.
Procedure
l Run the reset lldp statistics [ interface interface-type interface-number ] command in the
user view to clear LLDP packet statistics in the system or on an interface.
l Run the clear lldp neighbor [ interface interface-type interface-number ] command in the
user view to clear neighbor information in the system or on an interface.
l Run the reset lldp mdn statistics [ interface interface-type interface-number ] command
in the user view to clear non-LLDP packet statistics in the system or on an interface.
----End
7.5.2 Monitoring LLDP Status
Context
In routine maintenance, you can run the following commands in any view to check the LLDP
status.
Procedure
l Run the display lldp statistics [ interface interface-type interface-number ] command to
view statistics about sent and received LLDP packets in the system or on an interface.
l Run the display lldp mdn statistics [ interface interface-type interface-number ] command
to check statistics about non-LLDP packets received by all interfaces or a specified
interface.
----End
This section provides several configuration examples of LLDP, including networking
requirements and configuration roadmap.
7.6.1 Example for Configuring LLDP on the Device That Has a
Single Neighbor
As shown in Figure 7-2, SwitchA and SwitchB are directly connected; SwitchA and ME are
directly connected; routes between the NMS and SwitchA, and the NMS and SwitchB are
reachable; SNMP is configured.
146
A network administrator wants to obtain communication information between SwitchA and ME,
and between SwitchA and SwitchB, and alarms of device function changes to know the detailed
network topology and configuration conflicts.
Figure 7-2 Single-neighbor network
Network
SwitchA
SwitchB
ME
NMS
LLDP interface
SNMP packet
LLDPDU packet
L
L
D
P
D
U
S
N
M
P

S
N
M
P

IP:10.10.10.1
10GE1/0/2 10GE1/0/1
10GE1/0/1
IP:10.10.10.2
The LLDP function can meet the network administrator's requirement. The configuration
roadmap is as follows:
1. Enable global LLDP on SwitchA and SwitchB.
2. Configure management IP addresses for SwitchA and SwitchB.
3. Enable the LLDP trap function on SwitchA and SwitchB so that traps can be sent to the
NMS in a timely manner.
Procedure
Step 1 Enable global LLDP on SwitchA and SwitchB.
[~HUAWEI] commit
[~SwitchA] lldp enable
[~SwitchA] commit
[~HUAWEI] sysname SwitchB
[~HUAWEI] commit
[~SwitchB] lldp enable
[~SwitchB] commit
Step 2 Configure management IP addresses for SwitchA and SwitchB.
147
[~SwitchA] lldp management-address 10.10.10.1
[~SwitchA] commit
[~SwitchB] lldp management-address 10.10.10.2
[~SwitchB] commit
Step 3 Enable the LLDP trap function on SwitchA and SwitchB.
[~SwitchA] snmp-agent trap enable feature-name lldp
[~SwitchA] commit
[~SwitchB] snmp-agent trap enable feature-name lldp
[~SwitchB] commit
Step 4 Verify the configurations.
l Check SwitchA.
# Check the SwitchA configuration.
<SwitchA> display lldp local
System information
--------------------------------------------------------------------------
Chassis type :macAddress
Chassis ID :00c0-2017-7602
System name :SwitchA
System description :Huawei Versatile Routing Platform Software
VRP (R) software, Version 8.50 (CE6850 V100R001C00)
Copyright (C) 2011-2012 Huawei Technologies Co., Ltd.
HUAWEI CE6850
System capabilities supported :bridge router
System capabilities enabled :bridge router
LLDP Up time :2012/05/30 09:50:32
System configuration
--------------------------------------------------------------------------
LLDP Status :enabled (default is disabled)
LLDP Message Tx Interval :30 (default is 30s)
LLDP Message Tx Hold Multiplier :4 (default is 4)
LLDP Refresh Delay :2 (default is 2s)
LLDP Tx Delay :2 (default is 2s)
LLDP Notification Interval :5 (default is 5s)
LLDP Notification Enable :enabled (default is enabled)
Management Address :ipv4: 10.10.10.2
LLDP Fast Message Count :4 (default is 4)
Remote Table Statistics:
--------------------------------------------------------------------------
Remote Table Last Change Time :12 days,3 hours, 45 minutes,33 seconds
Remote Neighbors Added :3
Remote Neighbors Deleted :0
Remote Neighbors Dropped :0
Remote Neighbors Aged :2
Total Neighbors :1
148
Port information:
--------------------------------------------------------------------------
Interface 10GE1/0/1:
LLDP Enable Status :enabled (default is disabled)
Total Neighbors :0
Port ID subtype :interfaceName
Port ID :10GE1/0/1
Port description :
Port and Protocol VLAN ID(PPVID) :unsupported
Port VLAN ID(PVID) :100
VLAN name of VLAN 100 :VLAN100
Protocol identity :STP RSTP/MSTP LACP
Auto-negotiation supported :No
Auto-negotiation enabled :No
OperMau :speed (10000) /duplex (Full)
Link aggregation supported :Yes
Link aggregation enabled :No
Aggregation port ID :0
Maximum frame Size :9216
EEE support :No
Transmit Tw :65535
Receive Tw :65535
Fallback Receive Tw :0
Echo Transmit Tw :0
Echo Receive Tw :0
---- More ----
# Check neighbor information of SwitchA.
<SwitchA> display lldp neighbor interface 10ge 1/0/1
10GE1/0/1 has 1 neighbors:
Neighbor index :1
Chassis ID :00c0-2017-7602
Port ID type :interfaceName
Port ID :10GE1/0/1
Port description :HUAWEI, CloudEngine Series, 10GE1/0/1
Interface
System name :SwitchB
HUAWEI CE6850
System capabilities supported :
System capabilities enabled :
Management address type :ipv4
Management address :10.10.10.2
Expired time :111s
Protocol identity :--
OperMau :speed (0) /duplex (Unknown)
Discovered time :2012-06-11 23:15:17
EEE support :No
Transmit Tw :65535
149
Receive Tw :65535
Echo Transmit Tw :0
Echo Receive Tw :0
l Check SwitchB.
Refer to the steps for checking SwitchA.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100
#
interface Vlanif100
ip address 10.10.10.1 255.255.255.0
#
snmp-agent trap enable feature-name lldp trap-name hwLldpMdnRemTablesChange
#
lldp enable
#
lldp management-address 10.10.10.1
#
return
#
sysname SwitchB
#
vlan batch 100
#
interface Vlanif100
ip address 10.10.10.2 255.255.255.0
#
#
lldp enable
#
#
return
7.6.2 Example for Configuring LLDP on the Device That Has
Multiple Neighbors
As shown in Figure 7-3, SwitchA, SwitchB, and SwitchC are connected to the NMS using a
hub. Routes between the NMS and SwitchA, SwitchB, and SwitchC are reachable, and SNMP
is configured.
A network administrator wants to obtain Layer 2 information about SwitchA, SwitchB, and
SwitchC to know the detailed network topology and configuration conflicts.
150
Figure 7-3 Multiple-neighbor network
NMS
S
N
M
P
LLDP interface
S
N
M
P
L
L
D
P
D
U
L
L
D
P
D
U
SwitchA SwitchB SwitchC
SNMP packet
LLDPDU packet
L
L
D
P
D
U
IP:10.10.10.1 IP:10.10.10.2 IP:10.10.10.3
10GE1/0/1
10GE1/0/1
10GE1/0/1
Switch
1. Enable global LLDP on SwitchA, SwitchB, and SwitchC.
2. Configure management IP addresses for SwitchA, SwitchB, and SwitchC.
Procedure
Step 1 Enable global LLDP on SwitchA, SwitchB, and SwitchC.
[~HUAWEI] commit
[~SwitchA] lldp enable
[~SwitchA] commit
[~HUAWEI] commit
[~SwitchB] commit
# Configure SwitchC.
[~HUAWEI] sysname SwitchC
[~HUAWEI] commit
151
[~SwitchC] lldp enable
[~SwitchC] commit
Step 2 Configure management IP addresses for SwitchA, SwitchB, and SwitchC.
[~SwitchA] commit
[~SwitchB] commit
# Configure SwitchC.
[~SwitchC] lldp management-address 10.10.10.3
[~SwitchC] commit
l Check SwitchA.
# Check the SwitchA configuration.
--------------------------------------------------------------------------
System information
Chassis ID :00c0-2017-7602
HUAWEI CE6850
LLDP Up time :2012/05/30 09:50:32
--------------------------------------------------------------------------
--------------------------------------------------------------------------
Remote Table Last Change Time :12 days,3 hours, 45 minutes,33 seconds
Total Neighbors :1
152
Port information:
--------------------------------------------------------------------------
Total Neighbors :0
Port ID :10GE1/0/1
Interface
OperMau :speed (10000) /duplex (Full)
EEE support :No
Transmit Tw :65535
Receive Tw :65535
Echo Transmit Tw :0
Echo Receive Tw :0
---- More ----
<SwitchA> display lldp neighbor interface 10ge 1/0/1
Neighbor index :1
Chassis ID :00c0-2017-7602
Port ID :10GE1/0/1
Port description :HUAWEI, CloudEngine Series, 10GE1/0/1 Inter
face
System name :SwitchB
HUAWEI CE6850
Expired time :96s
Auto-negotiation supported :Yes
Discovered time :2012-05-14 22:03:06
EEE support :No
153
Transmit Tw :65535
Receive Tw :65535
Echo Transmit Tw :0
Echo Receive Tw :0
Neighbor index :2
Chassis ID :00c0-2017-7603
Port ID :10GE1/0/1
Port description :HUAWEI, CloudEngine Series, 10GE1/0/1 Inter
face
System name :SwitchC
HUAWEI CE6850
System capabilities supported :
System capabilities enabled :
Expired time :96s
Auto-negotiation supported :Yes
Discovered time :2012-05-14 22:03:06
EEE support :No
Transmit Tw :65535
Receive Tw :65535
Echo Transmit Tw :0
Echo Receive Tw :0
l Check SwitchB.
l Check SwitchC.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100
#
interface Vlanif100
ip address 10.10.10.1 255.255.255.0
#
lldp enable
#
154
#
return
#
sysname SwitchB
#
vlan batch 100
#
interface Vlanif100
ip address 10.10.10.2 255.255.255.0
#
lldp enable
#
#
return
#
sysname SwitchC
#
vlan batch 100
#
interface Vlanif100
ip address 10.10.10.3 255.255.255.0
#
lldp enable
#
#
return
7.6.3 Example for Configuring LLDP on the Network with link
aggregation configured
As shown in Figure 7-4, SwitchA and SwitchB are connected through an Eth-Trunk. Routes
between the NMS and switches are reachable, and SNMP is configured.
A network administrator wants to obtain Layer 2 information about SwitchA and SwitchB to
know the detailed network topology and configuration conflicts.
155
Figure 7-4 Network with link aggregation configured
SwitchA SwitchB Enterprise User Enterprise User
Network
NMS
Eth-Trunk
LLDP interface
SNMP packet
LLDPDU
LLDPDU packet
SNMP
SNMP
IP:10.10.10.1 IP:10.10.10.2
1. Add the physical interfaces on SwitchA and SwitchB to the Eth-Trunk.
2. Enable global LLDP on SwitchA and SwitchB.
3. Configure management IP addresses for SwitchA and SwitchB.
Procedure
Step 1 Add the physical interfaces on SwitchA and SwitchB to the Eth-Trunk.
[~HUAWEI] commit
[~SwitchA] vlan batch 100
[~SwitchA] interface eth-trunk 1
[~SwitchA-Eth-Trunk1] trunkport 10ge 1/0/1 to 1/0/3
[~SwitchA-Eth-Trunk1] port link-type trunk
[~SwitchA-Eth-Trunk1] port trunk allow-pass vlan 100
[~SwitchA-Eth-Trunk1] commit
[~SwitchA-Eth-Trunk1] quit
[~HUAWEI] commit
[~SwitchB] vlan batch 100
[~SwitchB] interface eth-trunk 1
[~SwitchB-Eth-Trunk1] trunkport 10ge 1/0/1 to 1/0/3
[~SwitchB-Eth-Trunk1] port link-type trunk
[~SwitchB-Eth-Trunk1] port trunk allow-pass vlan 100
[~SwitchB-Eth-Trunk1] commit
[~SwitchB-Eth-Trunk1] quit
156
Step 2 Enable global LLDP on SwitchA and SwitchB.
[~~SwitchA] lldp enable
[~~SwitchA] commit
[~SwitchB] commit
Step 3 Configure management IP addresses for SwitchA and SwitchB.
[~~SwitchA] commit
[~SwitchB] commit
l Check the SwitchA configuration.
# Check whether the physical interfaces are added to Eth-Trunk1.
<SwitchA> display eth-trunk 1
Eth-Trunk1's state information is:
WorkingMode: NORMAL Hash arithmetic: According to SIP-XOR-DIP
Least Active-linknumber: 1 Max Bandwidth-affected-linknumber: 16
Operate status: up Number Of Up Ports In Trunk: 3
-------------------------------------------------------------------------------
-
PortName Status Weight
10GE1/0/1 Up 1
10GE1/0/2 Up 1
10GE1/0/3 Up 1
# View the LLDP configurations.
System information
--------------------------------------------------------------------------
Chassis ID :0025-9e37-eea5
HUAWEI CE6850
LLDP Up time :2012/05/14 22:02:32
--------------------------------------------------------------------------
157
--------------------------------------------------------------------------
Remote Table Last Change Time :0 days, 3 hours, 30 minutes, 27 seconds
Total Neighbors :1
Port information:
--------------------------------------------------------------------------
Total Neighbors :1
Port ID :10GE1/0/1
Interface
EEE support :No
Transmit Tw :65535
Receive Tw :65535
Echo Transmit Tw :0
Echo Receive Tw :0
Total Neighbors :1
Port ID :10GE1/0/2
Interface
158
EEE support :No
Transmit Tw :65535
Receive Tw :65535
Echo Transmit Tw :0
Echo Receive Tw :0
Total Neighbors :1
Port ID :10GE1/0/3
Interface
EEE support :No
Transmit Tw :65535
Receive Tw :65535
Echo Transmit Tw :0
Echo Receive Tw :0
<SwitchA> display lldp neighbor brief
Local Intf Neighbor Dev Neighbor Intf Exptime(sec)
-------------------------------------------------------------------------------
10GE1/0/1 SwitchB 10GE1/0/1 115
10GE1/0/2 SwitchB 10GE1/0/2 115
10GE1/0/3 SwitchB 10GE1/0/3 115
l Check the SwitchB configuration.
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 100
#
interface Vlanif100
ip address 10.10.10.1 255.255.255.0
#
interface Eth-Trunk1
#
interface 10GE1/0/1
eth-trunk 1
#
interface 10GE1/0/2
159
eth-trunk 1
#
interface 10GE1/0/3
eth-trunk 1
#
lldp enable
#
#
return
#
sysname SwitchB
#
vlan batch 100
#
interface Vlanif100
ip address 10.10.10.2 255.255.255.0
#
interface Eth-Trunk1
#
interface 10GE1/0/1
eth-trunk 1
#
interface 10GE1/0/2
eth-trunk 1
#
interface 10GE1/0/3
eth-trunk 1
#
lldp enable
#
#
return
7.6.4 Example for Configuring MDN
As shown in Figure 7-5, non-Huawei devices IP phone 1 and IP phone 2 have reachable links
to the Huawei device (Switch). The route from the Switch to the NMS is reachable. The goal
for this example is to enable the Switch to receive and identify the non-Link Layer Discovery
Protocol (LLDP) packets that IP phone 1 and IP phone 2 send and to obtain the MAC addresses
of the two non-Huawei devices. The NMS can obtain topology information between the Switch,
IP phone 1, and IP phone 2 by exchanging SNMP packets with them.
160
Figure 7-5 Networking diagram for configuring MDN
IP Phone1 Switch
NMS
LLDP interface
SNMP packet
Non-LLDP packet
IP:10.10.10.2
10GE1/0/2
IP Phone2
10GE1/0/1
1. Enable the LLDP function for the Switch globally.
2. Configure MDN on the Switch so that the Switch can detect non-Huawei devices to which
the Switch is directly connected.
3. Enable the alarm function about MDN neighbor information changes and set the delay for
the Switch to send alarms, which can minimize the consumption of system resources.
Procedure
Step 1 Enable the LLDP function for the Switch globally.
[~HUAWEI] sysname Switch
[~HUAWEI] commit
[~Switch] lldp enable
[~Switch] commit
Step 2 Configure MDN on the Switch.
# Configure MDN on 10GE 1/0/1.
[~Switch] lldp enable
[~Switch] interface 10ge 1/0/1
[~Switch-10GE1/0/1] lldp mdn enable
[~Switch-10GE1/0/1] quit
[~Switch] interface 10ge 1/0/2
[~Switch-10GE1/0/2] lldp mdn enable
[~Switch-10GE1/0/2] commit
[~Switch-10GE1/0/2] quit
Step 3 Enable the alarm function on the Switch about MDN neighbor information changes and set the
delay for the device to send alarms.
# Configure Switch.
[~Switch] snmp-agent trap enable feature-name lldp
[~Switch] lldp mdn trap interval 10
[~Switch] commit
161
# Check whether the alarm function about MDN neighbor information changes is enabled and
whether the displayed delay value for sending alarms is the same as the configured delay value.
l View the configuration and status information about MDN on the Switch.
<Switch> display lldp mdn local

--------------------------------------------------------------------------

MDN Notification Interval :5 (default is
5s)

MDN Notification Enable :enabled (default is
disabled)

Remote Table
Statistics:
--------------------------------------------------------------------------
Remote Table Last Change Time :0 days, 0 hours, 0 minutes, 0
seconds
Remote Neighbors Added :
0
Remote Neighbors Deleted :
0
Remote Neighbors Dropped :
0
Remote Neighbors Aged :
0
Total Neighbors :
0

Port
information:
--------------------------------------------------------------------------
MDN Status :receive enabled (default is
disabled)

Total Neighbors :1
l View information about MDN neighbors of the Switch.
<Switch> display lldp mdn neighbor
Neighbor index :1
MacAddress :0023-ea20-b010
Discovered time :2012-03-09 13:09:55
Neighbor index :1
MacAddress :0023-ea20-b011
Discovered time :2012-03-09 13:09:58
----End
Configuration Files
# Configuration file of Switch
#
sysname Switch
#
vlan batch 100
#
interface Vlanif100
ip address 10.10.10.2 255.255.255.0
#
162
interface 10GE1/0/1
lldp mdn enable
#
interface 10GE1/0/2
lldp mdn enable
#
#
lldp enable
#
return
163
8 Packet Capture Configuration
About This Chapter
This section describes the concept and configuration of the packet capture function and provides
configuration examples.
8.1 Packet Capture Overview
The packet capture function captures packets matching the specified rules. This function
improves network maintenance efficiency and reduces maintenance costs.
8.2 Configuring the Device to Capture Forwarded Packets
If the device fails to forward traffic correctly, configure the packet capture function to capture
forwarded packets for analysis. This allows the device to process invalid packets in time,
ensuring that network data can be transmitted correctly.
8.3 Configuring the Capture Function for Packets Sent to the CPU
When a CPU fault occurs, configure the packet capture function to capture packets sent to the
CPU for analysis. This allows the device to process invalid packets in time, ensuring that the
CPU works properly.
This section provides examples of packet capture configuration.
Configuration Guide - Network Management 8 Packet Capture Configuration
164
8.1 Packet Capture Overview
The packet capture function captures packets matching the specified rules. This function
improves network maintenance efficiency and reduces maintenance costs.
NOTE
Based on your requirements to detect failures in telecom transmission, this feature may collect or store
some communication information about specific customers. Huawei cannot offer services to collect or store
this information unilaterally. Before enabling the function, ensure that it is performed within the boundaries
permitted by applicable laws and regulations. Effective measures must be taken to ensure that information
is securely protected.
As Internet develops, devices on a network transmit various services, and network administrators
often need to capture packets on devices to locate faults. The packet capturing function allows
devices to capture received packets for fault location. This function simplifies the configurations
of packet analysis device and network monitoring device.
After the packet capturing function is enabled, the devices capture the packets matching certain
conditions. The maintenance personnel can run commands to view information about captured
packets or save the captured packets to the local storage media as *.cap files. The saved files
can be downloaded for fault analysis. This function greatly improves maintenance efficiency
and reduces maintenance costs.
The CE series switches can capture the following two types of packets:
l Forwarded packets: If the device fails to forward traffic correctly, for example, the traffic
does not match the traffic model, configure the packet capture function to capture forwarded
packets for analysis. This allows the device to process invalid packets in time, ensuring
that network data can be transmitted correctly.
l Packets sent to the CPU: When a CPU fault occurs, such as the CPU usage is high, configure
the packet capture function to capture packets sent to the CPU for analysis. This allows the
device to process invalid packets in time, ensuring that the CPU works properly.
8.2 Configuring the Device to Capture Forwarded Packets
If the device fails to forward traffic correctly, configure the packet capture function to capture
forwarded packets for analysis. This allows the device to process invalid packets in time,
ensuring that network data can be transmitted correctly.
Context
You can configure ACL rules to capture packets matching a specified ACL.
NOTE
After the packet capture function is enabled, performance of the device may be affected. Exercise caution
when you configure this function.
Procedure
Step 1 Run:
capture-packet interface interface-type interface-number [ acl acl-number | vlan
vlan-id | inner-vlan inner-vlan-id ]
*
destination { terminal | file file-name }
*

[ time-out time | packet-num number | packet-len { length | total-packet } ]
*
165
The device is configured to capture forwarded packets.
NOTE
l The device can capture only upstream packets and cannot capture downstream packets.
l You can set the timeout period specified by time and the number of packets to be captured specified
by number for a capture instance. If the timeout period expires or the specified number of packets are
captured, the system stops capturing packets.
l You can set packet capture parameters based on the number of packets on the interface. If a large
number of packets are forwarded on an interface, set the time parameter to a small value and the
number parameter to a large value. If a small number of packets are forwarded on an interface, set the
time parameter to a large value and the number parameter to a small value.
l The device supports only one instance for capturing incoming.
----End
8.3 Configuring the Capture Function for Packets Sent to the
CPU
When a CPU fault occurs, configure the packet capture function to capture packets sent to the
CPU for analysis. This allows the device to process invalid packets in time, ensuring that the
CPU works properly.
Context
You can configure ACL rules to capture packets matching a specified ACL.
Procedure
Step 1 Run:
capture-packet local-host [ interface interface-type interface-number ] [ acl { acl-
number | name acl-name } | vlan vlan-id | inner-vlan inner-vlan-id ]
*
destination
{ terminal | file file-name }
*
[ time-out time | packet-num number | packet-len
{ length | total-packet } ]
*
The device is configured to capture packets sent to the CPU.
NOTE
l You can set the timeout period specified by time and the number of packets to be captured specified
by number for a capture instance. If the timeout period expires or the specified number of packets are
captured, the system stops capturing packets.
l You can set packet capture parameters based on the number of packets on the interface. If a large
number of packets are forwarded on an interface, set the time parameter to a small value and the
number parameter to a large value. If a small number of packets are forwarded on an interface, set the
time parameter to a large value and the number parameter to a small value.
----End
This section provides examples of packet capture configuration.
166
8.4.1 Example for Configuring Packet Capture Function
As shown in Figure 8-1, the switch connects to the network through 10GE1/0/1.
Packets sent upstream from 10GE1/0/1 of the switch need to be Captured. Captured packet
information needs to be displayed on the terminal.
Figure 8-1 Networking diagram for configuring the packet capture function
Internet
10GE1/0/1
Switch

1. Capture all packets to be forwarded and display information about these packets on a
terminal
2. Capture packets sent to the CPU and display captured packet information on the terminal.
Procedure
Step 1 Capture all packets to be forwarded on 10GE1/0/1 and display information about these packets
on a terminal.
<HUAWEI>capture-packet interface 10GE1/0/1 destination terminal time-out 5 packet-
num 1
Info: Capture-packet will be shown on ternimal.
<HUAWEI>
Packet: 1
-------------------------------------------------------
00 25 9e 95 7c 4e 00 25 9e 95 7c 3e 81 00 20 de
08 06 00 01 08 00 06 04 00 02 00 25 9e 95 7c 3e
c0 a8 27 01 00 25 9e 95 7c 4e c0 a8 27 02 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------
------------------capture report-----------------------
Capture-Packet Index 1
Type : forwarding
Interface : 10GE1/0/1
Direction : inbound
Time-out : 5 seconds
Packet-num : 1
Packet-len : 64
BufferOnly : disabled
167
-------------------------------------------------------
Step 2 Capture packets sent to the CPU and display captured packet information on the terminal.
<HUAWEI>capture-packet local-host interface 10GE1/0/1 destination terminal packet-
num 3 time-out 10
Info: Capture-packet will be shown on terminal.
<HUAWEI>
Packet: 1
-------------------------------------------------------
00 25 9e 95 7c 40 00 19 21 db 25 a3 08 00 45 00
00 28 fb df 40 00 80 06 7b 0f c0 a8 01 03 c0 a8
01 8d 11 5f 00 17 a9 1e 44 56 3b e0 af 92 50 10
ff 53 42 42 00 00 00 00 00 00 00 00
-------------------------------------------------------
Packet: 2
-------------------------------------------------------
00 25 9e 95 7c 40 00 19 21 db 25 a3 08 00 45 00
00 28 fb e4 40 00 80 06 7b 0a c0 a8 01 03 c0 a8
01 8d 11 5f 00 17 a9 1e 44 56 3b e0 af a1 50 10
ff 44 42 42 00 00 00 00 00 00 00 00
-------------------------------------------------------
Packet: 3
-------------------------------------------------------
00 25 9e 95 7c 40 00 19 21 db 25 a3 08 00 45 00
00 28 fb e8 40 00 80 06 7b 06 c0 a8 01 03 c0 a8
01 8d 12 76 00 17 e9 d4 2d 60 11 61 41 17 50 10
fc b6 b3 02 00 00 00 00 00 00 00 00
-------------------------------------------------------
------------------capture report-----------------------
Capture-Packet Index 8
Type : local-host
SysID : all
Time-out : 10 seconds
Packet-num : 3
Packet-len : 64
BufferOnly : disabled
-------------------------------------------------------
----End
Configuration Files
None
168

CloudEngine 6800&5800 V100R001C00 Configuration Guide - Network Management 04 PDF

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CloudEngine 6800&5800 V100R001C00 Configuration Guide - Network Management 04 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

CloudEngine 6800&5800 Series Switches

Anda mungkin juga menyukai