netengine5000e

HUAWEI NetEngine5000E Core Router
V800R002C01
Configuration Guide - System

Management
Issue 01
Date 2011-10-15
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2011. 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 the 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://www.huawei.com
Email: support@huawei.com
Issue 01 (2011-10-15) Huawei Proprietary and Confidential i

Copyright © Huawei Technologies Co., Ltd.
Configuration Guide - System Management About This Document
About This Document
Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the System Management feature supported by the
NE5000E device.
This document describes how to configure the Basic Configurations feature.
This document is intended for:
l Data configuration engineers
l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Related Versions (Optional)

The following table lists the product versions related to this document.
Product Name Version
HUAWEI NetEngine5000E V800R002C01

Core Router
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates a hazard with a high level of risk, which if not

avoided, will result in death or serious injury.
Indicates a hazard with a medium or low level of risk, which

if not avoided, could result in minor or moderate injury.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential ii

Configuration Guide - System Management About This Document
Symbol Description
Indicates a potentially hazardous situation, which if not

avoided, could result in equipment damage, data loss,
performance degradation, or unexpected results.
Indicates a tip that may help you solve a problem or save time.
Provides additional information to emphasize or supplement

important points of the main text.
Command Conventions (Optional)

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. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n times.
# A line starting with the # sign is comments.
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains
all updates made in previous issues.
Changes in Issue 01 (2011-10-15)

The initial commercial release.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential iii

Configuration Guide - System Management Contents
Contents
About This Document.....................................................................................................................ii

1 Device Management.....................................................................................................................1
1.1 Device Management Overview..........................................................................................................................2
1.2 Device Management Features Supported by the NE5000E...............................................................................2
1.3 Powering Off the Board......................................................................................................................................3
1.4 Managing Online Devices..................................................................................................................................5
1.4.1 Checking Device Versions........................................................................................................................5
1.4.2 Viewing Basic Information About the Device..........................................................................................5
1.4.3 Checking Memory Usage..........................................................................................................................6
1.4.4 Checking CPU Usage................................................................................................................................6
1.4.5 Checking Device Temperatures.................................................................................................................6
1.4.6 Checking Device Voltages........................................................................................................................7
1.4.7 Checking the Power Module.....................................................................................................................7
1.4.8 Checking the Fan Module..........................................................................................................................8
1.4.9 Restarting the Device.................................................................................................................................8
1.4.10 Resetting a Board.....................................................................................................................................9
1.5 Configuring a Cleaning Cycle for the Air Filter.................................................................................................9
1.5.1 Configuring a Cleaning Cycle for the Air Filter........................................................................................9
1.5.2 Remonitoring the Cleaning Cycle of the Air Filter.................................................................................10
1.5.3 Checking the Configuration.....................................................................................................................10
1.6 Configuration Examples...................................................................................................................................11
1.6.1 Example for Powering Off the MPU.......................................................................................................11
2 NTP Configuration......................................................................................................................13
2.1 NTP Overview..................................................................................................................................................14
2.2 NTP Features Supported by the NE5000E.......................................................................................................14
2.3 Configuring Basic NTP Functions...................................................................................................................18
2.3.1 Configuring the NTP Primary Clock.......................................................................................................19
2.3.2 Configuring the Unicast Server/Client Mode..........................................................................................20
2.3.3 Configuring the Peer Mode.....................................................................................................................21
2.3.4 Configuring the Broadcast Mode............................................................................................................22
2.3.5 Configuring the Multicast Mode.............................................................................................................23
2.3.6 Disabling the Interface From Receiving NTP Packets............................................................................25
Issue 01 (2011-10-15) Huawei Proprietary and Confidential iv


2.4 Configuring NTP Security Mechanisms...........................................................................................................26
2.4.1 Setting NTP Access Authorities..............................................................................................................29
2.4.2 Enabling NTP Authentication.................................................................................................................30
2.4.3 Configuring NTP Authentication in Unicast Server/Client Mode..........................................................30
2.4.4 Configuring NTP Authentication in Peer Mode......................................................................................31
2.4.5 Configuring NTP Authentication in Broadcast Mode.............................................................................31
2.4.6 Configuring NTP Authentication in Multicast Mode..............................................................................32
2.5 Configuring the System Clock.........................................................................................................................33
2.6 Maintaining NTP..............................................................................................................................................34
2.6.1 Monitoring the NTP Running Status.......................................................................................................34
2.7 Configuration Examples...................................................................................................................................35
2.7.1 Example for Configuring NTP Authentication in Unicast Server and Client Mode...............................35
2.7.2 Example for Configuring NTP Peer Mode..............................................................................................39
2.7.3 Example for Configuring NTP Authentication in Broadcast Mode........................................................42
2.7.4 Example for Configuring Multicast Mode..............................................................................................46
3 SNMP Configuration..................................................................................................................50
3.1 Introduction to SNMP......................................................................................................................................51
3.1.1 SNMP Overview......................................................................................................................................51
3.1.2 SNMP Features Supported by the NE5000E...........................................................................................53
3.2 Configuring a Device to Communicate with an NM Station by Running SNMPv1........................................56
3.2.1 Configuring Basic SNMPv1 Functions...................................................................................................57
3.2.2 (Optional) Controlling the NM Station's Access to the Device...............................................................59
3.2.3 (Optional) Configuring the Trap Function..............................................................................................61
3.3 Configuring a Device to Communicate with an NM Station by Running SNMPv2c......................................64
3.3.1 Configuring Basic SNMPv2c Functions.................................................................................................65
3.3.4 (Optional) Configuring the Informs Function.........................................................................................70
3.4 Configuring a Device to Communicate with an NM Station by Running SNMPv3........................................74
3.4.1 Configuring Basic SNMPv3 Functions...................................................................................................75
3.4.3 Configuring SNMPv3 Authentication and Privacy.................................................................................80
3.4.5 (Optional) Configuring the Informs Function.........................................................................................82
3.5 SNMP Configuration Examples.......................................................................................................................86
3.5.1 Example for Configuring a Device to Communicate with an NM Station by Using SNMPv1..............86
3.5.2 Example for Configuring a Device to Communicate with an NM Station by Using SNMPv2c............89
Issue 01 (2011-10-15) Huawei Proprietary and Confidential v

3.5.3 Example for Configuring a Device to Communicate with an NM Station by Using SNMPv3..............93
4 Log Management.........................................................................................................................98
4.1 Log Management Overview.............................................................................................................................99
4.2 Log Management Features that the NE5000E Supports..................................................................................99
4.3 (Optional) Filtering Logs................................................................................................................................101
4.4 Setting the Maximum Number of Logs to Be Displayed...............................................................................102
4.5 Setting the Maximum Number of Traps to Be Displayed..............................................................................103
4.6 Saving Logs to a Local Log File....................................................................................................................104
4.7 Configuring Logs to Be Output to a Log Host...............................................................................................105
4.7.1 Enabling the Information Center...........................................................................................................105
4.7.2 (Optional) Specifying a Source Interface for Sending Logs to a Log Host...........................................106
4.7.3 Configuring Logs to Be Output to a Specified Log Host......................................................................106
4.7.4 Checking the Configuration...................................................................................................................107
4.8 Maintenance....................................................................................................................................................108
4.9 Configuration Examples.................................................................................................................................108
4.9.1 Example for Saving Logs to a Local Log File.......................................................................................108
4.9.2 Example for Configuring Logs to Be Output to a Log Host.................................................................110
5 Fault Management.....................................................................................................................113
5.1 Fault Management Overview.........................................................................................................................114
5.2 FM Supported by the NE5000E.....................................................................................................................114
5.3 Configuring FM..............................................................................................................................................114
5.3.1 Setting the Alarm Severity....................................................................................................................115
5.3.2 Configuring a Suppression Period for an Alarm...................................................................................115
5.3.3 Configuring Alarm Suppression............................................................................................................116
5.3.4 Filtering Out All Alarms........................................................................................................................117
5.3.5 Configuring an Alarm Filtering Table to Filter Out Alarms.................................................................117
5.3.6 Saving Alarms to a Log File..................................................................................................................118
5.4 Maintenance....................................................................................................................................................120
5.4.1 Clearing Alarm Statistics.......................................................................................................................120
5.4.2 Monitoring the Alarm Status.................................................................................................................120
5.5 Configuration Examples.................................................................................................................................121
5.5.1 Example for Configuring FM................................................................................................................121
6 NetStream Configuration.........................................................................................................124
6.1 NetStream Overview......................................................................................................................................126
6.2 NetStream Features Supported by the NE5000E...........................................................................................127
6.3 Collecting Statistics About IPv4 Original Flows...........................................................................................128
6.3.1 Specifying a NetStream Service Processing Mode...............................................................................130
6.3.2 Outputting Original Flows.....................................................................................................................132
6.3.3 (Optional) Adjusting the AS Field Mode and Interface Index Type.....................................................133
6.3.4 (Optional) Enabling Statistics Collection of TCP Flags........................................................................134
Issue 01 (2011-10-15) Huawei Proprietary and Confidential vi

6.3.5 Sampling IPv4 Flows.............................................................................................................................135

6.4 Collecting Statistics About IPv4 Aggregated Flows......................................................................................138
6.4.2 Configuring an Aggregation Mode for IPv4 Flows...............................................................................142
6.4.3 Outputting Aggregated Flows...............................................................................................................144
6.5 Collecting Statistics About IPv6 Original Flows...........................................................................................149
6.5.2 Outputting Original Flows.....................................................................................................................153
6.5.4 (Optional) Enabling Statistics Collection of TCP Flags in Original Flows..........................................155
6.6 Collecting Statistics About IPv6 Aggregated Flows......................................................................................159
6.6.2 Configuring an Aggregation Mode for IPv6 Flows...............................................................................162
6.6.3 Outputting Aggregated Flows...............................................................................................................164
6.7 Collecting Statistics About MPLS IPv4 Packets............................................................................................169
6.8 Collecting Statistics About MPLS IPv6 Packets............................................................................................173
6.9 Collecting Statistics About BGP/MPLS VPN Flows.....................................................................................175
6.10 Maintaining NetStream.................................................................................................................................176
6.10.1 Aging Original Flows Forcibly............................................................................................................176
6.10.2 Monitoring the NetStream Operating Status.......................................................................................177
6.11 Configuration Examples...............................................................................................................................178
6.11.1 Example for Collecting Statistics About Abnormal IPv4 Flows at the User Side..............................178
6.11.2 Example for Collecting Statistics About IPv4 Flows Aggregated Based on the AS Number............181
6.11.3 Example for Collecting Statistics About MPLS Original Flows.........................................................185
6.11.4 Example for Deploying NetStream on the BGP/MPLS IP VPN Network..........................................189
Issue 01 (2011-10-15) Huawei Proprietary and Confidential vii

Configuration Guide - System Management 1 Device Management
1 Device Management
About This Chapter
The stable running of the device depends on mature network planning and routine maintenance.
In addition, fast location of potential hazards is necessary. After understanding the concept and
operations of device management, you can manage the device effectively and efficiently.
1.1 Device Management Overview

The maintenance personnel must check alarm information immediately and deal with faults
properly to keep the device in normal operation and reduce the failure rate.
1.2 Device Management Features Supported by the NE5000E
The supported device management features include the power-off operation, master/slave
switchover, device monitoring, device restart, and board reset.
1.3 Powering Off the Board
When a board fails or needs maintenance or a hardware upgrade, you need to power off the
board. Then, you can remove the board.
1.4 Managing Online Devices
You need to manage online devices to ensure that the network works normally. This section
describes common operations of managing online devices.
1.5 Configuring a Cleaning Cycle for the Air Filter
This section describes the procedure for configuring a cleaning cycle for the air filter.
1.6 Configuration Examples
This section provides several examples for maintaining the router.
Issue 01 (2011-10-15) Huawei Proprietary and Confidential 1

1.1 Device Management Overview

properly to keep the device in normal operation and reduce the failure rate.
Concept
The stable running of the router depends on the mature network planning and routine
maintenance. In addition, fast detection of potential hazards is necessary.
properly to keep the device in normal operation and reduce the failure rate. Thus, the system
runs safely, stably, and reliably.
Device Management Operations

Device management operations include master/slave switchover, operation maintenance, board
replacement, and internal environment check. These operations ensure the smooth operation of
the router.
1.2 Device Management Features Supported by the

NE5000E
The supported device management features include the power-off operation, master/slave
switchover, device monitoring, device restart, and board reset.
l Power-off operation
You can power on or power off a board through command lines to perform hot swapping
without interrupting services on the router.
l Mster/slave switchover
The NE5000E supports the backup technology. The main control boards work in 1+1
backup mode, which is the precondition of the master/slave switchover in the system.
l Device monitoring
In routine maintenance of the device, you can run display commands to view the working
status of the router. This helps maintenance personnel fast locate the fault during the
troubleshooting procedure.
l Device restart
In some special cases, for example, in system upgrade, a router must be restarted so that
the configuration can take effect. In addition to being restarted after being powered off, the
NE5000E can be restarted through command lines.
l Board reset
When a board on the device malfunctions and cannot automatically recover, it is
recommended that the board be reset.

1.3 Powering Off the Board

When a board fails or needs maintenance or a hardware upgrade, you need to power off the
Applicable Environment
Determine the board to be powered off according to the actual situation.
l Power off the MPU.
The device adopts 1:1 redundancy of MPUs. In the operation of the device, one MPU
functions as the active one and the other functions as the standby one. You need to remove
the MPU in any of the following situations:
– The MPU needs maintenance, for example, dust cleaning.
– The hardware of the MPU needs an upgrade, for example, memory capacity expansion.
– The MPU fails.
WARNING
The router cannot work with a single MPU for a long time. If the MPU fails, the entire
system is broken down. Therefore, after the slave MPU is powered off, you must finish
required operations and restore the slave MPU immediately.
l Power off the SFU.

During normal operation of the device, four SFUs work in 3+1 load balancing mode. You
need to remove an SFU in any of the following situations:
– The SFU needs maintenance, for example, dust cleaning.
– The SFU fails and needs to be repaired or replaced.
l Power off the LPU.
You need to power off the LPU in any of the following situations:
– The LPU needs maintenance, for example, dust cleaning.
– The LPU fails and needs to be repaired or replaced.
Pre-configuration Tasks
Before powering off the board, complete the following tasks:
l Checking the slot of the board to be powered off
l Preparing a slave board if the board needs to be replaced
Procedure
l Powering off the MPU
1. Run the system-view command to enter the system view.
2. (Optional)Run the slave switchover command to perform the master/slave
switchover.

Before powering off the MPU, you need to run the display device command to view
the status of the MPU. If the MPU is the master MPU, perform the master/slave
switchover first.
3. Run the quit command to return to the system view
4. Run the power off slot slot-id-mpu command to power off the slave MPU.
NOTE
If there is no terminal on the deployment site, you can power off the slave MPU by pressing the OFL
button. The OFL button is on the upper part of the panel for the slave MPU. Press and hold the button
for six seconds till the OFL indicator lights. This indicates that the slave MPU is powered off.
l Powering off the SFU
1. Run the power off slot slot-id-sfu command to power off the SFU.
NOTE
If there is no terminal on the deployment site, you can power off the SFU by pressing the OFL button.
The OFL button is on the upper part of the panel of the SFU board. Press and hold the button for six
seconds till the OFL indicator lights. This indicates that the SFU is powered off.
l Powering off the LPU
After preparing a spare LPU, you can power off the LPU.
1. Run the power off slot slot-id-lpu [ card card-id ] command to power off the LPU.
NOTE
If there is no terminal on the deployment site, you can power off the LPU by pressing the OFL button.
The OFL button is in the upper part of the panel of the LPU. Press and hold the button for six seconds.
If the OFL indicator lights, it indicates that the LPU is powered off.
----End
Checking the Configuration

After the power-off operation, run the display device command. If the slave MPU is in the
abnormal state, it means that the operation succeeds. For example:
<HUAWEI> display device
Total Chassis Number: 1
Central Chassis Number: 0
Line Chassis Number: 1
Chassis ID: clc0
Device status:
---------------------------------------------------------------------------
Slot # Type Online Register Status Role LrId Primary
---------------------------------------------------------------------------
2 LPU Present Registered Normal LC 0 NA
17 MPU Present Registered Normal MMB 0 Master
18 MPU Present Unregistered Abnormal MMB 0 Slave
19 SFU Present Registered Normal OTHER 0 NA
23 CLK Present Registered Normal OTHER 0 Master
24 CLK Present Registered Normal OTHER 0 Slave
25 PWR Present Registered Normal OTHER 0 NA
27 FAN Present Registered Normal OTHER 0 NA
28 FAN Present Registered Normal OTHER 0 NA
---------------------------------------------------------------------------

1.4 Managing Online Devices

You need to manage online devices to ensure that the network works normally. This section
describes common operations of managing online devices.
You can manage online devices by viewing the information about the device or resetting a board
to ensure that the network works normally
Before managing online devices, complete the following task:
l Power on and start the router normally.
Configuration Procedure
You can choose to configure one of the following configuration tasks according to the applicable
environment.
1.4.1 Checking Device Versions

By querying the device, you can view the software version of the system and hardware and
software versions of each part.
Procedure
Step 1 Run the display version [ slot slot-id ] command to view versions of the router.
You can run the display version [ slot slot-id ] command in any view to view versions of the
router. Versions of the router include:
l System software version

l Hardware and software versions of the MPUs
l Hardware and software versions of the SFUs
l Hardware and software versions of the LPUs
l Hardware and software versions of fan modules and the backplane
----End
1.4.2 Viewing Basic Information About the Device

You can view basic information about the device, including the status of the entire device and
basic information about a module (for example, power module or fan module) in a certain slot.
Procedure
Step 1 Run the display device [ pic-status | slot-id ] command to view basic information about the
router.

In practice, you can run this command in any view to view basic information about the device.
slot-id specifies the slot ID of a module.
l Choose a board in a certain slot and view basic information about this board.
l Run the display device pic-status command to view basic information about the sub-cards
of each LPU on the router.
----End
1.4.3 Checking Memory Usage

By checking memory usage, you can view the current resource usage of the device.
Procedure
Step 1 Run the display memory-usage [ threshold ] [ slave | slot slot-id ] command to check the
memory usage of the MPU or LPU.
NOTE
To set the threshold of the memory usage of the MPU or LPU, you can run the set memory-usage
threshold threshold-value [ restore restore-threshold-value ] [ slave | slot slot-id ] command.
----End
1.4.4 Checking CPU Usage

By checking CPU usage, you can view the current resource usage of the device.
Procedure
Step 1 Run the display cpu-usage[ configuration ] [ slave | slot slot-id ] command to check the CPU
usage of an MPU or an LPU.
NOTE
To set the threshold of the CPU usage of the MPU, you can run the set cpu-usage threshold threshold-
value [ restore restore-threshold-value ] [ slave | slot slot-id ] command.
----End
1.4.5 Checking Device Temperatures

By checking device temperatures, you can view the current temperature status, temperature
alarm threshold, and actual temperature of each board.
Procedure
Step 1 Run the display temperature [ lpu [ slot slot-id ] | mpu | sfu | slot slot-id ] command to view
the working temperature of a board.
To view the working temperature of each board on the router, you can run the display
temperature command.
In practice, you can run the display temperature command in any view to view the current
working temperatures of the router. The temperature information includes the following
contents:

l Current temperature status of a board

l Alarm threshold of the board temperature
l Actual temperature of the board
----End
1.4.6 Checking Device Voltages

By checking the voltage status of each board on the device, you can know the number of voltage
sensors for boards, voltage sensors in use, working status of voltage sensors, alarm threshold of
voltage, actual voltage, and normal working temperature of voltage sensors.
Procedure
Step 1 Run the display voltage [ lpu [ slot slot-id ] | mpu | sfu | slot slot-id ] command to view the
voltage status of the specified board.
To view the voltage status of each board of the router, you can run the display voltage command.
In practice, you can run the display voltage command in any view to view the voltage status of
all the boards on the router. The voltage information includes the following:
l Number of voltage sensors for the boards

l Working voltage sensors for the boards
l Working status of voltage sensors for the boards
l Alarm threshold of the board voltage
l Actual board voltage
l Normal working temperature of the voltage sensors
----End
1.4.7 Checking the Power Module

By checking information about the current power module of the device, you can view the slot
ID of the power module, whether the power module is in position, the working mode of the
power module, and the status of the cable for the power module.
Procedure
Step 1 Run the display power [ { environment-info | manufacture-info } slot slot-id-power | slot
[ slot-id-lpu ] ] command to check the status of the power module for the router.
In practice, you can run this command to view the status of the power module for the router.
The displayed information includes the following:
l Slot ID of the power module

l Whether the power module is in position
l Working mode of the power module
l Status of the cable for the power module
----End

1.4.8 Checking the Fan Module

By checking the status of the fan module, you can view the slot ID of the fan module, whether
the fan module is in position and registered, the working status of the fan module, and the rotation
mode of the fan module.
Procedure
Step 1 Run the display fan command to view the status of the fan module.
In practice, you can run this command to view the fan status. The information includes the
following:
l Slot ID of the fan module

l Whether the fan module is in position and registered
l Working status of the fan module
l Rotation mode of the fan module
----End
1.4.9 Restarting the Device

After the software of a router is upgraded, you need to restart the router to validate the
configurations.
Context
CAUTION
Be cautious to use the reboot command because it can break down the entire network for a short
period. In addition, check whether configuration files need be saved before restarting the device.
Procedure
Step 1 Run:
reboot
The device is immediately restarted.
After the reboot command is run, the system checks whether the current configuration is
consistent with the configuration saved in the configuration file. If the configuration is
inconsistent wit the configuration saved in the configuration file, the system prompts you to save
the current configuration. The system then prompts you to confirm whether to save the current
configuration in the configuration file to be activated next time.
----End

1.4.10 Resetting a Board

During device maintenance, you can use a certain command to reset a board. Before resetting a
board, you need to save the configuration file on the board to ensure that the configuration can
automatically recover after the board is reset.
Background Information
When an operating board of the device fails, you are recommended to reset the board by using
the reset slot command.
WARNING
You need to back up important data before resetting a board.
Procedure
Step 1 Run the reset slot slot-id [ card card-id ]command in the user view to reset the faulty board or
subcard.
NOTE
l If this command is run to reset a master MPU and no slave MPU exists, the master MPU is reset with
the CPU being powered on. If a slave MPU exists, this command performs the master-slave MPU
switchover.
l If the board is still abnormal after being reset, contact Huawei technical support personnel.
----End
1.5 Configuring a Cleaning Cycle for the Air Filter

This section describes the procedure for configuring a cleaning cycle for the air filter.
When the air filter has been running for a period of a cleaning cycle time , the system will create
an alarm for cleaning the air filter. The cleaning cycle for the air filter can be configured.
Before configuring a cleaning cycle for the air filter, complete the following tasks:
l Logging in to a device to be upgraded
1.5.1 Configuring a Cleaning Cycle for the Air Filter
Context
Do as follows on the router:

Procedure
Step 1 Run:
system-view
The system view is displayed.

Step 2 Run
dustproof check-timer day days
The cleaning cycle for the air filtered is configured.
NOTE
The air filter is a component without memory. All the monitored information is saved on the MPU, which
may be inserted, removed, switched, or replaced during usage. Therefore, the monitoring cycle may differ
from the set cycle, but this does not affect the monitoring function.
----End
1.5.2 Remonitoring the Cleaning Cycle of the Air Filter
Context
The system generates an alarm about cleaning the air filter. After ensuring that the air filter is
cleaned or does not need to be cleaned, you need to clear the alarm and remonitor the cleaning
cycle of the air filter.
Do as follows on the router:
Procedure
Step 1 Run:
reset dustproof run-time
The alarm is cleared. The cleaning cycle of the air filter is monitored.
----End
1.5.3 Checking the Configuration
Procedure
Step 1 Run:
display dustproof
Information about the air filter is displayed.
----End
Example
Run the display dustproof command. You can view information about the cleaning cycle of
the air filter, the last time when the air filter was cleaned (referring to the time on the router),
how many days the router had been run since the previous cleaning, and how long the alarm
about cleaning the air filter exists. For example:

<HUAWEI> display dustproof

Clean Dustproof-Net cycle : 365(days)
Last clean date : 2011/02/07
Up to last clean days : 1(day)
Clean alarm existence days: 0(day)

This section provides several examples for maintaining the router.
1.6.1 Example for Powering Off the MPU

When the MPU fails or needs maintenance or a hardware upgrade, you need to power off the
Networking Requirements
After checking the alarm information, you find that the hardware on the master MPU fails. Then,
power off the master MPU and check it.
Configuration Notes
CAUTION
On a single NE5000E, interfaces are numbered in the format of slot number/sub-card number/
interface number; whereas in the multi-chassis scenario, interfaces are numbered in the format
of chassis ID/slot number/card number/interface number. This requires the chassis ID to be
specified along with the slot number.
The NE5000E cannot work with a single MPU for a long time. If the MPU fails, the whole
system is broken down. After the slave MPU is powered off, you must finish required operations
and restore the MPU immediately.
Configuration Roadmap
The configuration roadmap is as follows:
1. Switch the master MPU to the slave MPU.
2. Power off the slave MPU.
Data Preparation
To complete the configuration, you need the following data:
l Slot number of the master MPU
Procedure
Step 1 Perform a master/slave switchover on the router.
<HUAWEI> system-view
[~HUAWEI] slave switchover

Before performing the master and slave switchover, check that user interfaces such as AUX,
console, and VTY interfaces are connected to the two MPUs. Otherwise, users that use the
interfaces connected with the former master MPU automatically quit the login after the master
and slave switchover.
[~HUAWEI] quit
Step 2 Power off the MPU in slot 18.

<HUAWEI> power off slot 18
Step 3 Verify the configuration.

Check the registration status of the MPU. You can view that the MPU in slot 18 is in the
unregistered and abnormal state. It means that the MPU is powered off.
<HUAWEI> display device
Total Chassis Number: 1
Central Chassis Number: 0
Line Chassis Number: 1
Chassis ID: clc0
Device status:
---------------------------------------------------------------------------
Slot # Type Online Register Status Role LrId Primary
---------------------------------------------------------------------------
0/2 LPU Present Registered Normal LC 0 NA
0/17 MPU Present Registered Normal MMB 0 Master
0/18 MPU Present Unregistered Abnormal MMB 0 Slave
0/19 SFU Present Registered Normal OTHER 0 NA
0/23 CLK Present Registered Normal OTHER 0 Master
0/24 CLK Present Registered Normal OTHER 0 Slave
0/25 PWR Present Registered Normal OTHER 0 NA
0/27 FAN Present Registered Normal OTHER 0 NA
0/28 FAN Present Registered Normal OTHER 0 NA
---------------------------------------------------------------------------
----End
Configuration Files
None.

Configuration Guide - System Management 2 NTP Configuration
2 NTP Configuration
About This Chapter
This section describes the fundamentals, the configuration procedure, and the configuration
examples of Network Time Protocol (NTP).
2.1 NTP Overview

This section introduces applications of NTP.
2.2 NTP Features Supported by the NE5000E
This section describes the principles and working modes of NTP supported by the NE5000E.
2.3 Configuring Basic NTP Functions
This section describes how to configure basic NTP functions.
2.4 Configuring NTP Security Mechanisms
This section describes how to ensure the security of NTP sessions through NTP security
mechanisms.
2.5 Configuring the System Clock
You need to correctly set the system clock to ensure synchronization with other devices.
2.6 Maintaining NTP
This section describes how to maintain NTP. Maintaining NTP helps you to monitor the NTP
operating status.
This section provides several configuration examples of NTP.

2.1 NTP Overview

This section introduces applications of NTP.
NTP aims at synchronizing clocks of all the devices in a network. It keeps all the clocks of these
devices consistent, and enables devices to implement various applications based on the uniform
time.
Any local system that runs NTP can be time synchronized by other clock sources, and also
functions as a clock source to synchronize other clocks. In addition, mutual synchronization can
be performed by exchanging NTP packets.
NTP packets are encapsulated in UDP packets for transmission and NTP uses the 123 port.
NTP Application
NTP is applied in the following situations where all the clocks of hosts or routers in a network
need to be consistent:
l Network management: Analysis on logs or debugging information collected from different

routers should be performed based on time.
l Charging system: Requires the clocks of all devices to be consistent.
l Completing certain functions: For example, timing restart of all the routers in a network
requires the clocks of all the routers to be consistent.
l Several systems working together on the same complicate event: Systems have to take the
same clock for reference to ensure a proper sequence of implementation.
l Incremental backup between the backup server and clients: Clocks on the backup server
and clients should be synchronized.
When all the devices on a network need to be synchronized, it is almost impossible for an
administrator to manually change the system clock by executing commands. This is because the
work load is heavy and clock accuracy cannot be ensured. NTP can quickly synchronize the
clocks of network devices and ensure their precision.
NTP has the following advantages:
l Defining clock accuracy by means of stratum to synchronize the time of network devices
in a short time
l Supporting access control and MD5 authentication
l Transmitting packets in unicast, multicast or broadcast mode
2.2 NTP Features Supported by the NE5000E

This section describes the principles and working modes of NTP supported by the NE5000E.
Basic Concepts
Stratum: measures clock precision. The higher the stratum level, the lower the clock precision.
For example, clocks have 15 stratums and the stratum-1 clock has the highest precision; Stratum
16 indicates that the relevant clock is not synchronized.

Principles of NTP
Figure 2-1 shows the principles of NTP. Router A and Router B are connected through a WAN.
They both have their own system clocks. NTP implements automatic synchronization of their
clocks.
Suppose:
l Before the system clocks of Router A and Router B are synchronized, the clock of
Router A is set to 10:00:00 am and the clock of Router B is set to 11:00:00 am.
l Router B functions as an NTP time server. That is, Router A synchronizes its clock with
that of Router B.
l One-way transmission of data packets between Router A and Router B takes one second.
l Processing of data packets between Router A or Router B takes one second.
Figure 2-1 NTP basic principle diagram
NTP packet 10:00:00 am
Step1: Network
RouterA RouterB
NTP packet 10:00:00 am 11:00:01 am
Step2: Network
RouterA RouterB
NTP packet 10:00:00 am 11:00:01 am 11:00:02 am
Step3: Network
RouterA RouterB
NTP Packet received at 10:00:03 am
Step4: Network
RouterA RouterB
The process of synchronizing system clocks is as follows:
1. Router A sends an NTP packet to Router B. The packet carries the originating timestamp
when it leaves Router A, which is 10:00:00 am (T1).
2. When the NTP packet reaches Router B, Router B adds its receiving timestamp to the NTP
packet, which is 11: 00:01 am (T2).
3. When the NTP packet leaves Router B, Router B adds its transmitting timestamp to the
NTP packet, which is 11:00:02 am (T3).

4. When Router A receives the response packet, it adds a new receiving timestamp to it, which
is 10:00:03 am (T4).
Router A uses the received information to calculate the following two important values:
l Delay for the NTP message cycle: Delay = (T4 - T1) - (T3 - T2).
l Offset of Router A relative to Router B: Offset = ( (T2 - T1) + (T3 - T4) ) / 2.
According to the delay and the offset, Router A sets its own clock again to synchronize
with the clock of Router B.
The preceding example is only a simple description of the NTP operating principle. As
described in RFC 1305, NTP uses a more complex algorithm to ensure the precision of
clock synchronization.
The device that provides standard time is referred to as a time server, and the device that
enjoys the time service is referred to as a client.
NTP Working Modes

The NE5000E supports the following NTP working modes, as listed in Table 2-1.
Table 2-1 NTP working mode

Working Mode Location and Working Principle
Synchronization Direction
Unicast Server/Client In this mode, you need to 1. The client sends a

Mode configure only on the client. synchronization request
The server needs to be packet to the server, with
configured with only one NTP the mode field being set
primary clock. to 3. The value 3
The client can be synchronized indicates the client
with the server but the server mode.
cannot be synchronized with the 2. Upon receiving the
client. request packet, the server
automatically works in
the server mode and
sends a response packet
with the mode field being
set to 4. The value 4
indicates the server
mode.
3. After receiving the
response packet, the
client performs clock
filtering and selection,
and finally, is
synchronized with the
optimal server.


Peer Mode In this mode, you need to 1. The symmetric active

configure NTP only on the end sends a
symmetric active end. The synchronization request
symmetric active end and packet to the symmetric
symmetric passive end can be passive end with the
synchronized with each other. mode field being set to 1.
Note that the clock with a higher (The value 1 indicates
stratum is synchronized to the the symmetric active
one with a lower stratum. mode.)
2. Upon receiving the
request packet, the
symmetric passive end
automatically works in
symmetric passive mode
and sends a response
packet with the mode
field being set to 2. (The
value 2 indicates the
symmetric passive
mode.) Symmetric
passive also forms a
dynamic session with
symmetric active.
Broadcast Mode In this mode, you need to 1. The server periodically

configure both, the server and sends clock
the client. synchronization packets
The client can be synchronized to the broadcast address
with the server but the server 255.255.255.255.
cannot be synchronized with the 2. The client senses
client. broadcast packets from
the server.
3. After receiving the first
broadcast packet, to
estimate the network
delay, the client enables
a temporary server/client
model for exchanging
messages with the
remote server.
4. The client then works in
broadcast client mode,
and continues to sense
the incoming broadcast
packets to synchronize
the local clock.


Multicast Mode In this mode, you need to 1. The server periodically

configure both, the server and sends clock
the client. synchronization packets
The client can be synchronized to the configured
with the server but the server multicast IP address.
cannot be synchronized with the 2. The client senses
client. multicast packets from
the server.
3. After receiving the first
multicast packet, to
estimate the network
delay, the client enables
a temporary server/client
model for exchanging
messages with the
remote server.
4. The client works in
multicast client mode,
and continues to sense
the incoming multicast
packets to synchronize
the local clock.

This section describes how to configure basic NTP functions.
NTP has four operation modes. Select a proper mode based on the networking topology to
meet various clock synchronization requirements.
In unicast server/client mode and peer mode, NTP packets can have the same source IP address.
Before configuring basic functions of NTP, you need to complete the following tasks:
l Configuring the link layer protocol for the interface
l Configuring an IP address and a routing protocol for the interface to ensure that NTP packets
can reach destinations

Figure 2-2 Configuring basic NTP functions
Configure the NTP primary clock
Configure the unicast server/client

mode
Configure the peer mode
Configure the broadcast mode
Configure the multicast mode
Disable the interface from receiving NTP

packets
Mandatory procedure
Optional procedure
Related Tasks
2.7.2 Example for Configuring NTP Peer Mode
2.7.4 Example for Configuring Multicast Mode
2.3.1 Configuring the NTP Primary Clock

This section describes how to configure the NTP primary clock. The stratum configured for the
master clock on the server must be lesser than that for the clock on the client. Otherwise, the
clock on the client cannot synchronize with the master clock on the server. Do as follows on the
Server.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ntp-service refclock-master [ ip-address ] [ stratum ]
An NTP primary clock is configured.
ip-address specifies the IP address of the local reference clock. Reference clock addresses are
of the form 127.127.t.u. Here, "t" indicates the clock type and ranges from 0 to 37. Currently,
"t" is the local reference clock and the value is 1. "u" indicates the NTP process number, ranging
from 0 to 3. When no IP address is specified, the local clock whose IP address is 127.127.1.0
functions as the primary NTP clock by default.
stratum specifies the stratum of the local reference clock. If this parameter is not specified, the
default stratum is 8.
Step 3 Run:
commit
The configurations are committed.
----End
2.3.2 Configuring the Unicast Server/Client Mode

This section describes how to configure the unicast server and client mode. In client/server mode,
the clock on the client synchronizes with the primary clock on the server.
Procedure
l Configure the NTP client.
1. Run:
system-view

2. (Optional) Run:
ntp-service source-interface interface-type interface-number [ vpn-
instance vpn-instance-name ]
The specified source interface IP address is used as the source IP address to send NTP
packets irrespective of the out going interface.
3. Run:
ntp-service unicast-server ip-address [ version number | authentication-
keyid key-id | source-interface interface-type interface-number | vpn-
instance vpn-instance-name | preference ] *
The IP address of the NTP server is configured.
ip-address is the IP address of the NTP server. It can be the IP address of the host
rather than a broadcast address, a multicast address, or the IP address of the reference
clock. If the source interface to send NTP packets is specified on the server, the IP
address of the server configured on the client should be the same; otherwise, the client
cannot process NTP packets sent from the server and clock synchronization fails.
Step 2 is optional. If source-interface is specified in both Step 2 and Step 3, use the
source interface specified in Step 3 preferentially.

NOTE
When the unicast NTP server is specified, the local router functions as the client automatically.
The server needs to be configured with only a primary clock.
4. Run:
commit

l (Optional) Configure the NTP server.
1. Run:
system-view

2. Run:
The specified source interface IP address is used as the source IP address to send NTP
packets irrespective of the out going interface.
Commonly, specify the IP address of the NTP server on the client. The client and
server can then exchange NTP packets using this IP address.
If the source interface to send NTP packets is specified on the server, the IP address
of the server configured on the client should be the same; otherwise, the client cannot
process NTP packets sent from the server and clock synchronization fails.
3. Run:
commit

----End
2.3.3 Configuring the Peer Mode

This section describes how to configure the NTP peer mode. In this mode, clocks on the two
peers synchronize with each other. Each side can send the clock synchronization request message
to the peer and reply the clock synchronization request message from the peer.
Procedure
l Configuring the NTP Symmetric Active End
1. Run:
system-view

2. (Optional) Run:
The specified local source interface is configured to send the NTP packet.
3. Run:
ntp-service unicast-peer ip-address [ version number | authentication-
keyid key-id | source-interface interface-type interface-number | vpn-
instance vpn-instance-name | preference ] *
The NTP peer is configured.

Step 2 is optional. If source-interface is specified in both Step 2 and Step 3, use the
source interface specified in Step 3 preferentially.
ip-address is the IP address of the NTP peer. It can be the IP address of a host address
rather than a broadcast address, a multicast address, or the IP address of the reference
clock.
NOTE
After the NTP peer is specified, the local router runs in symmetric active mode. The symmetric
passive end does not need to be configured.
4. Run:
commit

l (Optional) Configuring the NTP Symmetric Passive End
1. Run:
system-view

2. Run:
The specified local source interface is configured to send the NTP packet.
Commonly, specify the IP address of the NTP symmetric passive on the symmetric
active. The symmetric active and symmetric passive can then exchange NTP packets
using this IP address.
If the source interface to send NTP packets is specified on the symmetric passive end,
the IP address of the NTP peer configured on the symmetric active end should be the
same; otherwise, the active end cannot process NTP packets sent from the passive end
and clock synchronization fails.
3. Run:
commit
----End
2.3.4 Configuring the Broadcast Mode

This part describes how to configure the NTP broadcast mode on the LAN to synchronize clocks
on the LAN.
Procedure
l Configuring an NTP Broadcast Server
1. Run:
system-view

2. Run:
interface interface-type interface-number

The view of the interface sending NTP broadcast messages is displayed.

3. Run:
ntp-service broadcast-server [ authentication-keyid key-id | version
number ] *
The local router is set as an NTP broadcast server.
After the configurations, the local router periodically sends the clock synchronization
packets to the broadcast address 255.255.255.255.
NOTE
Broadcast can be used only in the same LAN.
4. Run:
commit

l Configuring an NTP Broadcast Client
1. Run:
system-view

2. (Optional) Run:
ntp-service max-dynamic-sessions number
The number of local sessions allowed to be set up dynamically is set.
By default, a maximum of 100 NTP sessions can be set up dynamically.
Running the ntp-service max-dynamic-sessions command does not affect the setup
of NTP sessions. When the number of the sessions reaches or exceeds the maximum,
the new session cannot be set up further.
3. Run:
The view of the interface receiving NTP broadcast messages is displayed.

4. Run:
ntp-service broadcast-client
The local router is configured as an NTP broadcast client.
After the configurations, the local router senses the broadcast NTP packets sent from
the server and synchronizes the local clock.
5. Run:
commit
----End
2.3.5 Configuring the Multicast Mode

This part describes how to configure the NTP multicast mode to synchronize clocks in a multicast
domain.

Procedure
l Configuring an NTP Multicast Server
1. Run:
system-view

2. Run:
The view of the interface sending NTP multicast messages is displayed.

3. Run:
ntp-service multicast-server [ ip-address ] [ authentication-keyid key-id
| ttl ttl-number | version number ] *
The local router is set to be an NTP multicast server.
After the configurations, the local router periodically sends clock synchronization
packets to the configured multicast IP address.
4. Run:
commit

l Configuring an NTP Multicast Client
1. Run:
system-view

2. (Optional) Run:
ntp-service max-dynamic-sessions number
The number of local sessions allowed to be set up dynamically is set.
By default, up to 100 NTP sessions can be set up dynamically.
Running the ntp-service max-dynamic-sessions command does not affect the setup
of NTP sessions. When the number of the sessions reaches or exceeds the maximum,
the new session cannot be set up further.
3. Run:
The view of the interface receiving NTP multicast messages is displayed.

4. Run:
ntp-service multicast-client [ ip-address ]
The local router is set to be an NTP multicast client.
After the configurations, the local router senses the multicast NTP packets sent from
the server and synchronizes the local clock.
5. Run:
commit
----End

2.3.6 Disabling the Interface From Receiving NTP Packets

To prevent a host on the LAN from synchronizing the clock on the specified server, you can
disable the specified interface on the host from receiving NTP packets.
Procedure
Step 1 Run:
system-view

Step 2 Run:
The interface view is displayed.

Step 3 Run:
ntp-service in-interface disable
The interface on the router is disabled from receiving NTP packets.

Step 4 Run:
commit
----End

After the basic NTP functions are configured, you can view the details about the configured and
the dynamic NTP sessions, the status of the NTP service and so on.
Prerequisite
All configurations of basic NTP functions are complete.
Procedure
l Run the display ntp-service sessions command to view the details about the configured
and the dynamic NTP sessions.
l Run the display ntp-service status command to view the status of the NTP service.
l Run the display ntp-service trace command to trace the path of reference clock source
from the local device.
l Run the display ntp-service bd-status command to view the status of each board on a
router.
----End
Example
Run the display ntp-service sessions command to view the details about the configured and the
dynamic NTP sessions.
<HUAWEI>display ntp-service sessions

source reference stra reach poll now offset delay disper

**********************************************************************
[12345] 127.127.1.0 LOCAL(0) 1 3 64 68 0.0 0.0 0.4
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured,6 vpn-
instance
Run the display ntp-service status command to view the status of the NTP service.
<HUAWEI>display ntp-service status
clock status: synchronized
clock stratum: 2
reference clock ID: LOCAL (0)
nominal frequency: 60.0002 Hz
actual frequency: 60.0002 Hz
clock precision: 2^18
clock offset: 0.0000 ms
root delay: 0.00 ms
root dispersion: 0.00 ms
peer dispersion: 10.00 ms
reference time: 15:51:36.259 UTC Apr 25 2005 (C6179088.426490A3)
Run the display ntp-service trace command to trace the path of reference clock source from
the local device.
<HUAWEI> display ntp-service trace
server 127.0.0.1,stratum 5, offset 0.024099, synch distance 0.06337,
refid 127.127.1.0
Run the display ntp-service bd-status command to view the status of each board on a router.
<HUAWEI> display ntp-service bd-status
Board ID : 17
Sync Source : 127.127.1.0
NTP Server Configured : No
Clock Status : synchronized
Offset : 0.7 ms
Clock Precision : 2^17
Poll : 8
Reference Time : 17:04:55.236 UTC Sep 11 2009(CE5501B7.3C8D4BAD)
Current Time : 17:05:39.359 UTC Sep 11 2009(CE5501E3.5C0DB270)

This section describes how to ensure the security of NTP sessions through NTP security
mechanisms.
NTP supports two security mechanisms: access authority and NTP authentication.
l Access authority
Access authority is a type of simple security method provided by the NE5000E to protect
local NTP services.
The NE5000E provides four access authority levels. When an NTP access request packet
reaches the local end, it is matched in an order from the maximum access authority to the
minimum access authority. The first matched authority level takes effect. The matching
order is as follows:

– peer: indicates the maximum access authority. The remote end can send the request of
the local time and the control query to the local end. The local clock can also be
synchronized with that of the remote server.
– server: indicates the remote end can perform the time request and control query to the
local end but the local clock cannot be synchronized with that of the remote end.
– 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 perform only the
control query to the local end.
l NTP authentication
NTP authentication is required in some networks with high security demands.
The configuration of NTP authentication involves configuring NTP authentication on both,
the client and the server.
During the configuration of NTP authentication, pay attention to the following rules:
– Configure NTP authentication on both the client and the server; otherwise, the
authentication does not take effect.
– If NTP authentication is enabled, a reliable key needs to be configured at the same time.
– The authentication key configured on the server and that on the client should be
consistent.
– In NTP peer mode, the symmetric active end equals the client, and the symmetric passive
end equals the server.
Before configuring NTP security mechanisms, complete the following tasks:
l Configuring the link layer protocol on the interface.
l Configuring the link layer protocol and routing protocol to make the server and client
reachable.
l Configuring ACL rules if the access authority is configured.

Figure 2-3 Flowchart of configuring NTP security mechanisms.
Set NTP access authorities
Enable NTP authentication
Configure NTP authentication

reliable key
Configure NTP authentication in

unicast server/client mode

peer mode

broadcast mode

multicast mode
Mandatory procedure
Optional procedure
Related Tasks
2.7.1 Example for Configuring NTP Authentication in Unicast Server and Client Mode
2.7.3 Example for Configuring NTP Authentication in Broadcast Mode

2.4.1 Setting NTP Access Authorities

When receiving an access request packet, the NTP server matches the request packet with the
access authority in descending order (from peer, server, synchronization to query). The first
matched authority takes effect.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ntp-service access { peer | query | server | synchronization } acl-number
Access authority for the NTP service on the local router is configured.
Before specifying an ACL number, make sure you have already created and configured this
ACL.
You can configure the ntp-service access command depending on the actual situation.
Table 2-2 shows the detailed NTP access authorities.
Table 2-2 Description of the NTP access authorities
NTP Operation Mode Limited NTP Query Supported Devices
Unicast NTP server/client Synchronizing the client with Client

mode the server
Unicast NTP server/client Clock synchronization Server

mode request from the client
NTP peer mode Clock synchronization with Symmetric active end

each other
NTP peer mode Clock synchronization Symmetric passive end

request from the active end
NTP multicast mode Synchronizing the client with NTP multicast client
the server
NTP broadcast mode Synchronizing the client with NTP broadcast client
the server
Step 3 Run:
commit
----End

2.4.2 Enabling NTP Authentication

Both the NTP server and the NTP client must be enabled with NTP authentication and configured
with the same authentication key, and declare that the key is reliable. Otherwise, NTP
authentication will fail.
Context
You must enable NTP authentication, and then configure basic NTP functions and specify the
authentication key. Otherwise, the NTP authentication fails.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ntp-service authentication enable
NTP authentication is enabled.
Step 3 Run:
ntp-service authentication-keyid key-id authentication-mode md5 password
The NTP authentication key is configured.
Step 4 Run:
ntp-service reliable authentication-keyid key-id
The authentication key is declared to be reliable.
Step 5 Run:
commit
----End
2.4.3 Configuring NTP Authentication in Unicast Server/Client

Mode
By configuring the authentication key ID used in the synchronization with the specific NTP
server on the NTP client, you can apply NTP authentication in client/server mode. Do as follows
on the NTP unicast client.
Procedure
Step 1 Run:
system-view
Step 2 Run:

ntp-service unicast-server ip-address [ version number | authentication-keyid key-

id | source-interface interface-type interface-number | vpn-instance vpn-instance-
name | preference ] *
The authentication key ID used for synchronizing the server and client clocks is configured.
Step 3 Run:
commit
----End
2.4.4 Configuring NTP Authentication in Peer Mode

By configuring the authentication key ID used in the synchronization with the peer on the local
end, you can apply NTP authentication in peer mode. Do as follows on the symmetric active
end.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ntp-service unicast-peer ip-address [ version number | authentication-keyid key-id
| source-interface interface-type\ interface-number | vpn-instance vpn-instance-
name | preference ] *
The authentication key ID for the synchronization of the symmetric active and symmetric passive
clocks is configured.
Step 3 Run:
commit
----End
2.4.5 Configuring NTP Authentication in Broadcast Mode

After NTP authentication is enabled, you can configure the authentication key ID used in
synchronization with the NTP broadcast server on the local router to apply NTP authentication
in broadcast mode. Do as follows on the NTP broadcast server.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ntp-service broadcast-server [ authentication-keyid key-id | version number ] *
The authentication key ID used by the NTP broadcast server is configured.

Step 4 Run:
commit
----End
2.4.6 Configuring NTP Authentication in Multicast Mode

By configuring the authentication key ID used in the synchronization with the NTP multicast
server on the local router, you can apply NTP authentication in multicast mode. Do as follows
on the NTP multicast server.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
ntp-service multicast-server [ ip-address ] [ authentication-keyid key-id | ttl ttl-
number | version number ] *
The authentication key ID used by the NTP multicast server is configured.

Step 4 Run:
commit
----End

After the NTP security mechanisms are configured, you can view the details about the status of
the NTP service and the status of NTP sessions.
Prerequisite
All configurations of basic NTP functions are complete.
Procedure
l Run the display ntp-service sessions verbose command to view the status of NTP sessions.
----End

Example
Run the display ntp-service status command to view the status of the NTP service.
<HUAWEI> display ntp-service status
clock stratum: 2
reference clock ID: LOCAL (0)
root delay: 0.00 ms
reference time: 15:51:36.259 UTC Apr 25 2005 (C6179088.426490A3)
Run the display ntp-service sessions verbose command to view the status of NTP sessions.
<HUAWEI> display ntp-service sessions verbose
clock source: 172.11.12.1
clock stratum: 1
clock status: configured, master, sane, valid
reference clock ID: LOCAL(0)
local mode: client, local poll: 10
peer mode: server, peer poll: 10
offset: -3.2385 ms,delay: 26.97 ms, disper: 14.85 ms
root delay: 0.00 ms, root disper: 10.94 ms
reach: 377, sync dist: 0.058, sync state: 4
precision: 2^18, version: 3, peer interface: wildcard
reftime: 10:01:38.546 UTC Sep 5 2005(C6C69602.8C00DA1A)
orgtime: 10:01:43.463 UTC Sep 5 2005(C6C69607.76ACC921)
rcvtime: 10:01:43.480 UTC Sep 5 2005(C6C69607.7AF4ADBC)
xmttime: 10:01:43.452 UTC Sep 5 2005(C6C69607.73F1E8E6)
filter delay : 0.03 0.02 0.03 0.02 0.02 0.02 0.04 0.02
filter offset: 0.00 -0.01 0.00 0.01 0.00 0.00 0.00 0.00
filter disper: 0.03 0.02 0.00 0.11 0.09 0.08 0.06 0.05
2.5 Configuring the System Clock

You need to correctly set the system clock to ensure synchronization with other devices.
NTP provides the provision for configuring the system datetime, timezone and daylight saving
time information.
In the application environment where absolute time is strictly required, the current date and clock
of the router must be set.
None
Procedure
Step 1 Run:
clock datetime time date
The current time is set.

Step 2 Run:
system-view
Step 3 Run:
clock timezone time-zone-name { add | minus } offset
The time zone is set.

l To obtain the time of the time zone, you can add offset to the UTC standard time if add is
specified in the command.
l To obtain the time of the time zone, you can minus offset from the UTC standard time if
minus is specified in the command.
Step 4 Run:
clock daylight-saving-time time-zone-name one-year start-time start-date end-time end-date

offset
or,
clock daylight-saving-time time-zone-name repeating start-time { { first | second | third |

fourth | last } weekday month | start-date } end-time { { first | second | third | fourth | last }
weekday month | end-date } offset [ start-year [ end-year ] ]
The daylight saving time is set.
----End

Run the display clock command to display the system time.
<HUAWEI> display clock
2010-07-20 10:04:21
Tuesday
Time Zone : Default Zone Name add 00:00:00
2.6 Maintaining NTP

This section describes how to maintain NTP. Maintaining NTP helps you to monitor the NTP
operating status.
2.6.1 Monitoring the NTP Running Status

By running the display command, you can monitor the operation of NTP.
Context
In routine maintenance, you can run the following commands in any view to monitor the NTP
running status.

Procedure
l Run the display ntp-service sessions command to view the details about the configured
and the dynamic NTP sessions.
l Run the display ntp-service trace command to trace the path of reference clock source
from the local device.
l Run the display clock command to view the system time.
----End

This section provides several configuration examples of NTP.
2.7.1 Example for Configuring NTP Authentication in Unicast

Server and Client Mode
You must enable NTP authentication for the NTP client, and then specify the IP address for the
NTP server and the authentication key sent to the NTP server. Otherwise, if NTP authentication
fails, then no synchronization will take place. In general, for successful NTP authentication, you
must completely configure the NTP client and server.
CAUTION
On a single NE5000E, an interface is numbered in the format of slot number/card number/
interface number. On an NE5000E cluster, the interface is numbered in the format of chassis
ID/slot number/card number/interface number. This requires the chassis ID to be specified along
with the slot number.
As shown in Figure 2-4,

l Router A functions as a unicast NTP server. The clock on it functions as a primary NTP
clock with the stratum as 2.
l Router B functions as a unicast NTP client. Its clock needs to synchronize with the clock
on Router A.
l Router C and Router D function as NTP clients of Router B.
l Enable NTP authentication on all the Routers.

Figure 2-4 Networking diagram of the unicast server/client mode
GE 1/0/0
10.0.0.2/24
GE 1/0/0 IP GE 2/0/0 GE 1/0/0 Router C

2.2.2.2/24 Networ 10.0.0.1/24 GE 1/0/0
1.0.1.11/24
k 10.0.0.3/24
Router A Router B
Router D
Configuration Notes
l You must enable NTP authentication on the client prior to specifying the IP address of the
NTP server and authentication key to be sent to the server; otherwise, NTP authentication
is not performed before clock synchronization.
l You must configure the same authentication key on the NTP server and NTP client and
declare that the key is reliable. Otherwise, the NTP authentication fails.
l To implement authentication successfully, configure on both the server and the client.
1. Configure the clock on Router A to be the NTP primary clock.
2. Configure Router B to synchronize its clock with the clock of Router A.
3. Configure Router C and Router D to synchronize their clocks with the clock of Router B.
4. Enable NTP authentication on all the Routers.
Data Preparation
l IP address of the reference clock
l Stratum of the primary NTP clock
l Authentication key and its ID
Procedure
Step 1 Configure the IP addresses based on Figure 2-4 so that Router A, Router B, Router C, and
Router D are routable. The detailed procedures are not mentioned here.
Step 2 Configure a primary NTP clock on Router A and enable NTP authentication.
# On Router A, set its local clock as a primary NTP clock with stratum being 2.
<RouterA> system-view
[~RouterA] ntp-service refclock-master 2
# Enable NTP authentication, configure the authentication key, and declare the key to be reliable.
[~RouterA] ntp-service authentication enable

[~RouterA] ntp-service authentication-keyid 42 authentication-mode md5 Hello

[~RouterA] ntp-service reliable authentication-keyid 42
[~RouterA] commit
NOTE
Authentication keys configured on the server and the client should be the same.
Step 3 Configure a primary NTP clock on Router B and enable NTP authentication.
# On Router B, enable NTP authentication. Configure the authentication key and declare the
key to be reliable.
<RouterB> system-view
[~RouterB] ntp-service authentication enable
[~RouterB] ntp-service authentication-keyid 42 authentication-mode md5 Hello
[~RouterB] ntp-service reliable authentication-keyid 42
# Specify Router A to be the NTP server of Router B and use the authentication key.
[~RouterB] ntp-service unicast-server 2.2.2.2 authentication-keyid 42
[~RouterB] commit
Step 4 On Router C, specify Router B to be the NTP server of Router C.

<RouterC> system-view
[~RouterC] ntp-service authentication enable
[~RouterC] ntp-service authentication-keyid 42 authentication-mode md5 Hello
[~RouterC] ntp-service reliable authentication-keyid 42
[~RouterC] ntp-service unicast-server 10.0.0.1 authentication-keyid 42
[~RouterC] commit
Step 5 On Router D, specify Router B to be the NTP server of Router D.

<RouterD> system-view
[~RouterD] ntp-service authentication enable
[~RouterD] ntp-service authentication-keyid 42 authentication-mode md5 Hello
[~RouterD] ntp-service unicast-server 10.0.0.1 authentication-keyid 42
[~RouterD] commit

After the configurations, the clock on Router B can be synchronized with the clock on Router
A.
Display the NTP status on Router B and find the clock is synchronized. The stratum of the clock
is 3, one stratum lower than that on Router A.
[~RouterB] display ntp-service status
clock stratum: 3
reference clock ID: 2.2.2.2
root delay: 31.26 ms
reference time: 11:55:56.833 UTC Mar 2 2006(C7B15BCC.D5604189)
After the configurations, the clock on Router C can be synchronized with the clock on Router
B.
Display the NTP status on Router C and find that the clock is synchronized. The stratum of the
clock is 4, one stratum lower than that on Router B.
[~RouterC] display ntp-service status


clock stratum: 4
Display the NTP status on Router D and find that the clock is synchronized. The stratum of the
clock is 4, one stratum lower than that on Router B.
[~RouterD] display ntp-service status
clock stratum: 4
Display NTP status on Router A.

[~RouterA] display ntp-service status
clock stratum: 2
reference clock ID: LOCAL(0)
root delay: 0.00 ms
reference time: 12:01:48.377 UTC Mar 2 2006(C7B15D2C.60A15981)
----End
Configuration Files
l Configuration file of Router A
#
sysname RouterA
#
ntp-service authentication-keyid 42 authentication-mode md5 %@ENC;8HX
\#Q=^Q`MAF4<1!!
ntp-service reliable authentication-keyid 42
ntp-service refclock-master 2
#
interface GigabitEthernet1/0/0
undo shutdown
ip address 2.2.2.2 255.255.255.0
#
ospf 1
area 0.0.0.0
network 2.2.2.0 0.0.0.255
#
return
l Configuration file of Router B

#
sysname RouterB
#
\#Q=^Q`MAF4<1!!
ntp-service unicast-server 2.2.2.2 authentication-keyid 42
#
undo shutdown
ip address 10.0.0.1 255.255.255.0
undo shutdown
ip address 1.0.1.11 255.255.255.0
#
ospf 1
area 0.0.0.0
network 1.0.1.0 0.0.0.255
network 10.0.0.0 0.0.0.255
#
return
l Configuration file of Router C

#
sysname RouterC
#
\#Q=^Q`MAF4<1!!
#
undo shutdown
ip address 10.0.0.2 255.255.255.0
#
return
l Configuration file of Router D

#
sysname RouterD
#
\#Q=^Q`MAF4<1!!
#
undo shutdown
ip address 10.0.0.3 255.255.255.0
#
return
Related Tasks
2.7.2 Example for Configuring NTP Peer Mode

In NTP peer mode, both peers can be synchronized to the clock of each other.

CAUTION
As shown in Figure 2-5, three Routers are located in a LAN.
l Configure the clock on Router C to be an primary NTP clock with the stratum as 2.
l Router D takes Router C as its NTP server. That is, Router D functions as the client.
l Router E takes Router D as its symmetric passive end. That is, Router E is the symmetric
active end.
Figure 2-5 Networking diagram of the NTP peer mode

RouterC
GE1/0/0
3.0.1.31/24
GE1/0/0 GE1/0/0
3.0.1.33/24 3.0.1.32/24
RouterE RouterD
Configuration Notes
Before configuring a peer mode, ensure the peer is reachable from host side.
1. Configure the clock on Router C to be the NTP primary clock. The clock on Router D
should be synchronized to the clock on Router C.
2. Configure Router E and Router D to be NTP peer so that Router E should send clock
synchronization requests to Router D.
3. Finally, the clocks on Router C, Router D and Router E can be synchronized.
Data Preparation

l IP address of Router C
l IP address of Router D
l Stratum of the NTP primary clock
Procedure
Step 1 Configure IP addresses for Router C, Router D, and Router E.
Configure an IP address for each interface based on Figure 2-5. After configurations, the three
Routers can ping through each other.
The detailed procedures are not mentioned here.
Step 2 Configure the NTP server/client mode.
# Configure the clock on Router C to be its own reference clock with the stratum being 2.
[~RouterC] ntp-service refclock-master 2
[~RouterC] commit
# On Router D, configure Router C to be its NTP server.

[~RouterD] ntp-service unicast-server 3.0.1.31
[~RouterD] commit
After configurations, the clock on Router D can be synchronized to the clock on Router C.
Display the NTP status on Router D and find that the status is synchronized. The stratum of the
clock on Router D is 3, one stratum lower than that on Router C.
clock stratum: 3
reference time: 06:52:33.465 UTC Mar 7 2006(C7B7AC31.773E89A8)
Step 3 Configure the unicast NTP peer mode.

# On Router E, configure Router D to be the symmetric passive end.
<RouterE> system-view
[~RouterE] ntp-service unicast-peer 3.0.1.32
[~RouterE] commit
Since no primary clock is configured on Router E, the clock on Router E should be synchronized
to the clock on Router D.
View the status of Router E after clock synchronization and you can find that the status is
"synchronized". That is, clock synchronization completes. You can also find that the stratum of
the clock on Router E is 4, one stratum lower than that on Router D.
[~RouterE] display ntp-service status

clock stratum: 4
reference time: 06:55:50.784 UTC Mar 7 2006(C7B7ACF6.C8D002E2)
----End
Configuration Files
#
sysname RouterC
#
#
undo shutdown
ip address 3.0.1.31 255.255.255.0
#
return

#
sysname RouterD
#
ntp-service unicast-server 3.0.1.31
#
undo shutdown
ip address 3.0.1.32 255.255.255.0
#
return
l Configuration file of Router E

#
sysname RouterE
#
ntp-service unicast-peer 3.0.1.32
#
undo shutdown
ip address 3.0.1.33 255.255.255.0
#
return
Related Tasks
2.7.3 Example for Configuring NTP Authentication in Broadcast

Mode
On a LAN, the device with high clock precision functions as the NTP server, and other devices
are synchronized to the clock of the NTP server.

CAUTION

l Router C and Router D are in the same network segment; Router A is in another network
segment; Router F connects the two network segments.
l Router C functions as the NTP broadcast server and its clock is the NTP primary clock with
the stratum being 3. Broadcast packets are sent from GE 1/0/0.
l Router D and Router A sense the broadcast packets respectively from GE 1/0/0 of them.
l Enable NTP authentication on Router A, Router C and Router D.
Figure 2-6 Networking diagram of the NTP broadcast mode

GE1/0/0
3.0.1.31/24
Router C
GE1/0/0 GE2/0/0
1.0.1.11/24 3.0.1.2/24
GE1/0/0
Router A 1.0.1.2/24 Router F
GE1/0/0
3.0.1.32/24
Router D
Configuration Notes
Before configuring key at the client and server side, ensure the key already exists.
1. Configure Router C as an NTP broadcast server.
2. Configure Router A and Router D as the NTP broadcast clients.
3. Configure NTP authentication on Router A, Router C, and Router D.
Data Preparation

l IP addresses of Router A, Router C, Router D, and Router F

l Authentication key and its ID
Procedure
Step 1 Configure an IP address for each router.
Configure IP addresses based on Figure 2-6. The detailed procedures are not mentioned here.
Step 2 Configure an NTP broadcast server and enable NTP authentication on it.
# Set the local clock of Router C as a primary NTP clock with stratum being 3.
# Enable NTP authentication.

[~RouterC] ntp-service authentication enable
[~RouterC] ntp-service authentication-keyid 16 authentication-mode md5 Hello
# Configure Router C to be an NTP broadcast server. Broadcast packets are encrypted by using
the authentication key ID 16 and then sent from GE 1/0/0.
[~RouterC] interface gigabitethernet 1/0/0
[~RouterC-GigabitEthernet1/0/0] ntp-service broadcast-server authentication-keyid
16
[~RouterC-GigabitEthernet1/0/0] commit
[~RouterC-GigabitEthernet1/0/0] quit
Step 3 Configure the NTP broadcast client Router D on the same network segment as that of the NTP
server.
[~RouterD] ntp-service authentication enable
[~RouterD] ntp-service authentication-keyid 16 authentication-mode md5 Hello
[~RouterD] ntp-service reliable authentication-keyid 16
# Configure Router D to be the NTP broadcast client. Router D senses the broadcast packets on
GE 1/0/0.
[~RouterD] interface gigabitethernet 1/0/0
[~RouterD-GigabitEthernet1/0/0] ntp-service broadcast-client
[~RouterD-GigabitEthernet1/0/0] commit
[~RouterD-GigabitEthernet1/0/0] quit
After configurations, the clock on Router D is synchronized to the clock on Router C.

Step 4 Configure the NTP broadcast client Router A in a network segment different from that of the
NTP server.
[~RouterA] ntp-service authentication enable
[~RouterA] ntp-service authentication-keyid 16 authentication-mode md5 Hello
[~RouterA] ntp-service reliable authentication-keyid 16
# Configure Router A to be the NTP broadcast client. Router A senses the NTP broadcast packets
on GE 1/0/0.
[~RouterA] interface gigabitethernet 1/0/0

[~RouterA-GigabitEthernet1/0/0] ntp-service broadcast-client

[~RouterA-GigabitEthernet1/0/0] commit
[~RouterA-GigabitEthernet1/0/0]quit
After the configurations, the clock on Route D can be synchronized to the clock on Router C.
The clock on Router A, however, fails to be synchronized because Router A and Router C are
in different network segments and Router A cannot sense the broadcast packets sent from
Router C.
Check the NTP status on Router D and you can find that the clock status is "synchronized". That
is, clock synchronization completes. The stratum of the clock on Router D is 4, one stratum
lower than that of Router C.
clock stratum: 4
root delay: 0.00 ms
reference time: 12:17:21.773 UTC Mar 7 2006(C7B7F851.C5EAF25B)
----End
Configuration Files
#
sysname RouterA
#
\#Q=^Q`MAF4<1!!
#
undo shutdown
ip address 1.0.1.11 255.255.255.0
#
ospf 1
area 0.0.0.0
network 1.0.1.0 0.0.0.255
#
return

#
sysname RouterC
#
\#Q=^Q`MAF4<1!!
#
undo shutdown
ip address 3.0.1.31 255.255.255.0
ntp-service broadcast-server authentication-keyid 16

#
return

#
sysname RouterD
#
\#Q=^Q`MAF4<1!!
#
undo shutdown
ip address 3.0.1.32 255.255.255.0
#
Return
l Configuration file of Router F

#
sysname RouterF
#
undo shutdown
ip address 1.0.1.2 255.255.255.0
#
undo shutdown
ip address 3.0.1.2 255.255.255.0
#
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
Related Tasks
2.7.4 Example for Configuring Multicast Mode

In a multicast domain, the device with high clock precision functions as the NTP server, and
other devices are synchronized to the clock of the NTP server.
CAUTION

l Router C and Router D are in the same network segment; Router A is in another network
segment; Router F connects with the two network segments.
l Router C functions as an NTP multicast server and its clock is a primary NTP clock with
the stratum being 2. Multicast packets are sent out from GE 1/0/0.
l Router D and Router A sense the multicast packets respectively on GE 1/0/0 of them.
Figure 2-7 Networking diagram of the NTP multicast mode

GE1/0/0
3.0.1.31/24
Router C
GE1/0/0 GE2/0/0
1.0.1.11/24 3.0.1.2/24
GE1/0/0
Router A 1.0.1.2/24 Router F
GE1/0/0
3.0.1.32/24
Router D
1. Configure Router C as an NTP multicast server.
2. Configure Router A and Router D as NTP multicast clients.
Data Preparation
l IP addresses of Router A, Router C, Router D, and Router F
Procedure
Step 1 Configure an IP address for each Router.
Configure IP addresses based on Figure 2-7. The detailed procedures are not mentioned here.
Step 2 Configure an NTP multicast server.
# Set the local clock on Router C as a primary NTP primary clock with stratum being 2.
# Configure Router C to be an NTP multicast server. NTP multicast packets are sent from GE
1/0/0.
[~RouterC] interface gigabitethernet 1/0/0
[~RouterC-GigabitEthernet1/0/0] ntp-service multicast-server

[~RouterC-GigabitEthernet1/0/0] commit
Step 3 Configure the NTP multicast client Router D in the same network segment as that of the NTP
server.
# Configure Router D to be an NTP multicast client. Router D senses the NTP multicast packets
on GE 1/0/0.
[~RouterD-GigabitEthernet1/0/0] ntp-service multicast-client
[~RouterD-GigabitEthernet1/0/0] commit
Step 4 Configure the NTP multicast client Router A in a network segment different from that of the
NTP server.
# Configure Router A to be an NTP multicast client. Router A senses the NTP multicast packets
on GE 1/0/0.
[~RouterA] interface gigabitethernet 1/0/0
[~RouterA-GigabitEthernet1/0/0] ntp-service multicast-client
[~RouterA-GigabitEthernet1/0/0] commit

After the configurations, the clock on Router D can be synchronized to the clock on Router C.
The clock on Router A, however, fails to be synchronized because Router A and Router C are
in different network segments and Router A cannot sense the multicast packets sent from
Router C.
Check the NTP status on Router D and you can find that the clock status is "synchronized". That
is, clock synchronization completes. The stratum of the clock on Router D is 3, one stratum
lower than that on Router C.
clock stratum: 3
reference time: 17:03:32.022 UTC Apr 25 2005(C61734FD.800303C0)
----End
Configuration Files
#
sysname RouterA
#
undo shutdown
ip address 1.0.1.11 255.255.255.0
ntp-service multicast-client
#
return

#

sysname RouterC
#
#
undo shutdown
ip address 3.0.1.31 255.255.255.0
ntp-service multicast-server
#
return

#
sysname RouterD
#
undo shutdown
ip address 3.0.1.32 255.255.255.0
ntp-service multicast-client
#
return
Related Tasks

Configuration Guide - System Management 3 SNMP Configuration
3 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.
3.1 Introduction to SNMP

SNMP provides a set of standard protocols for the communication between the Network
Management station (NM station) that runs the Network Management System (NMS) and
devices, allowing the NM station to manage devices and receive alarms reported by the devices.
3.2 Configuring a Device to Communicate with an NM Station by Running SNMPv1
After SNMPv1 is configured, a managed device and an NM station can run SNMPv1 to
communicate with each other. To ensure communication, you need to configure the agent and
NM station. This section describes the configuration on a managed device (the agent side). For
details about configuration on an NM station, see the pertaining NM station operation guide.
3.3 Configuring a Device to Communicate with an NM Station by Running SNMPv2c
After SNMPv2c is configured, a managed device and an NM station can run SNMPv2c to
details about configuration on an NM station, see the pertaining NMS operation guide.
3.4 Configuring a Device to Communicate with an NM Station by Running SNMPv3
details about configurations on an NM station, see the NMS operation guide.
3.5 SNMP Configuration Examples
This section provides several configuration examples of SNMP. The configuration roadmap in
the examples helps you understand the configuration procedures. Each configuration example
provides information about the networking requirements, configuration notes, and configuration
roadmap.

3.1 Introduction to SNMP

SNMP provides a set of standard protocols for the communication between the Network
Management station (NM station) that runs the Network Management System (NMS) and
devices, allowing the NM station to manage devices and receive alarms reported by the devices.
3.1.1 SNMP Overview

Get and Set operations can be performed on a managed device that runs the SNMP agent to
manage device objects. These objects are uniquely identified in the Management Information
Base (MIB).
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 NM station then can query the status of remote
devices, and devices can send alarms to the NM station in the case of particular events.
SNMP operates at the application layer of the IP suite and defines the transmission of
management information between the NM station and devices. SNMP defines several device
management operations that can be performed by the NM station and allow devices to notify
the NM station of device faults by sending alarms.
SNMP Components
An SNMP managed network consists of the following three components:
l NM station: sends various packets to query managed devices and receives alarms from
these devices.
l Agent: is a network-management process on a managed device. An agent has the following
functions:
– Receives and parses query packets sent from the NM station.
– Reads or writes management variables based on the query type, and generates and sends
response packets to the NM station.
– Sends alarms to the NM station when particular events occur. For example, the system
view is displayed or closed, or the device is restarted. Protocol modules on the device
define the conditions that lead to the alarms.
l Managed device: is managed by an NM station and generates and reports alarms to the
NM station.
Figure 3-1 shows the relationship between the NM station and agent.

Figure 3-1 SNMP structure
UDP Port161
Request
Response
NM Station Agent
UDP Port162
NM Station Agent
MIB
To uniquely identify managed objects, SNMP organizes them in a hierarchical tree structure and
identifies each one by a path starting from the tree root, as shown in Figure 3-2. The NM station
uses the MIB to identify and manage device objects. The nodes on the tree are the managed
objects.
Figure 3-2 Structure of a MIB tree
1
1 2
1 2
1 B 2
5 6
A
As shown in Figure 3-2, object B is uniquely identified by a string of numbers, {1.2.1.1}. Such
a number string is called an Object Identifier (OID). A MIB tree is used to describe the hierarchy
of data in a MIB that collects the definitions of variables on the managed devices.
A user can use a standard MIB or define a MIB based on certain standards. Using a standard
MIB can reduce the costs on proxy deployment and therefore reduce the costs on the entire
network management system.
SNMP Operations
SNMP uses Get and Set operations to replace a complex command set. The operations used for
device management include GetRequest, GetNextRequest, GetResponse, GetBulk, SetRequest,
and notification from the agent to the NM station. The operations described in Figure 3-3 can
implement all functions.

Figure 3-3 Schematic diagram of SNMP operations

get-request
get-response
get-next-request
get-response
NM Station set-request Agent
UDP Port162 get-response UDP Port161
trap
Table 3-1 gives details on the SNMP operations.
Table 3-1 SNMP operations

Operation Function
GetRequest Retrieves the value of a variable. The NM station sends the

request to a managed device to obtain the status of an object
on the device.
GetNextRequest Retrieves the value of the next variable. The NM station

sends the request to a managed device to obtain the status
of the next object on the device.
GetResponse Responds to GetRequest, GetNextRequest, and

SetRequest operations. GetResponse is sent from the
managed device to the NM station, or by the manager in
case of inform ack and is processed by SNMP agent.
GetBulk Is an NMS-to-agent request, equaling continuous GetNext

operations.
SetRequest Sets the value of a variable. The NM station sends the

request to a managed device to adjust the status of an object
on the device.
Trap Reports an event to the NM station.
Inform Reports an event to the NM station and require

acknowledgement from the NM station.
3.1.2 SNMP Features Supported by the NE5000E

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 NE5000E supports SNMPv1, SNMPv2c, and SNMPv3. Table 3-2 lists the features
supported by SNMP, and Table 3-3 shows the support of different SNMP versions for the

features. Table 3-4 describes the usage scenarios of SNMP versions, which helps you choose a
proper version for the communication between an NM station and managed devices based on
the network operation conditions.
NOTE
When multiple NM stations 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 NM stations.
Table 3-2 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 NM station 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

NM station. Traps help administrator to know
device faults.
The managed devices do not require the
acknowledgement from the NM station after
sending traps.
Inform Informs are sent from managed devices to the

NM station.
The managed devices require the
acknowledgement from the NM station after
sending informs. If a managed device does
not receive an acknowledgement after
sending an inform, then the managed device
performs the following:
l Resend the inform to the NM station.
l Store the inform in the memory, which
consumes lot of system resources.
l Generate the log information.
NOTE
If the NM station restarts, it can learn the informs
sent during the restart process.

Feature Description
GetBulk GetBulk allows an administrator to perform

Get operations in batches. In a large network,
GetBulk reduces the workload of
administrator and improves management
efficiency.
Table 3-3 Different SNMP versions support for the features

Feature SNMPv1 SNMPv2c SNMPv3
Access control Community-name- Community-name- User or user group-

based access control based access control based access control
supported supported supported
Authentication and Not supported Not supported Supported

privacy authentication and
privacy modes are as
follows:
Authentication
mode:
l MD5
l SHA
Privacy mode:
DES56
Error code 6 error codes 16 error codes 16 error codes

supported supported supported
Trap Supported Supported Supported
Inform Not supported Supported Supported
GetBulk Not supported Supported Supported
Table 3-4 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.

Version Usage Scenario
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 NM
station.
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 NM station 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 NM station to ensure the communication between managed devices and
the NM station.
3.2 Configuring a Device to Communicate with an NM

Station by Running SNMPv1
details about configuration on an NM station, see the pertaining NM station operation guide.
SNMP has to be deployed in a network to allow the NMS to manage network devices.
If the network is secure and has few devices (for example, a campus network or a small enterprise
network), then SNMPv1 can be deployed to ensure communication between the NMS and
managed devices.
Before configuring a device to communicate with an NM station by running SNMPv1, configure
a routing protocol to ensure that at least one route exist between router and NM station.

Figure 3-4 Flowchart of configuring a device to communicate with an NM Station by running

SNMPv1
3.2.1 Configuring Basic SNMPv1 Functions

After basic SNMP functions are configured, an NM station can perform basic operations such
as Get and Set operations on a managed device, and the managed device can send alarms to the
NM station.
Context
Steps 3, 4, and 5 are mandatory to configure basic SNMP functions. After the configuration is
complete, basic SNMP communication can be established between the NM station and managed
device.
Procedure
Step 1 Run:
system-view

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 parameters can enable the SNMP agent function.
Step 3 Run:
snmp-agent sys-info version v1
The SNMP version is set.

By default, SNMPv3 is enabled.

After SNMPv1 is enabled on the managed device, the device supports both SNMPv1 and
SNMPv3. This means that the device can be monitored and managed by NM stations running
SNMPv1 or SNMPv3.
Step 4 Run:
snmp-agent community { read | write } { community-name | cipher community-name1 }
[ acl acl-number | mib-view view-name ] *
The community name is set.

After the community name is set, if no MIB view is configured, the NM station that uses the
community name has rights to access objects in the Viewdefault view (1.3.6.1).
l read: NM station administrator configures the read parameter to provide read access to the
low level administrator for a specified view.
l write: NM station administrator configures the write parameter to provide read and write
access to the low level administrator for a specified view.
Step 5 Choose either of the following commands as needed to configure a destination IP address for
the alarms and error codes sent from the device.
l To configure a destination IPv4 address for the alarms and error codes sent from the device,
run:
snmp-agent target-host trap address udp-domain ip-address [ udp-port port-
number ] [ vpn-instance vpn-instance-name ] params securityname security-name
[ v1 ] [ private-netmanager ]
run:
snmp-agent target-host trap ipv6 { address udp-domain ipv6-address } [ udp-port
port-number ] params securityname security-name [ v1 ]
The descriptions of the command parameters are as follows:

l udp-port: The default UDP port number is 162. In some special cases (for example, port
mirroring is configured to prevent a well-known port from being attacked), the parameter
udp-port can be used to specify a non-well-known UDP port number. This ensures
communication between the NM station and managed device.
l vpn-instance: If the alarms sent from the managed device to the NM station need to be
transmitted over a private network, the parameter vpn-instance vpn-instance-name needs to
be used to specify a VPN that takes over the sending task.
l securityname: Identifies the alarm sender, which helps you learn the alarm source.
snmp-agent sys-info { contact contact | location location }
The equipment administrators contact information or location is configured.

This step is required for the NMS administrator to view contact information and locations of the
equipment administrator when the NM station manages many devices. This helps the NMS
administrator to contact the equipment administrators for fault location and rectification.
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 1500
bytes.

After the maximum size is set, the device discards any SNMP packet that is larger than the set
size.
Step 8 Run:
commit
The configuration is committed.
----End
Follow-up Procedure
After the configuration is complete, basic communication can be established between the NM
station and managed device.
l Access control allows any NM station that uses the community name to monitor and manage
all the objects on the managed device.
l The managed device sends alarms generated by the modules that are enabled by default to
the NM station.
If finer device management is required, follow directions below to configure a managed device:
l To allow a specified NM station that uses the community name to manage specified objects
on the device, follow the procedure described in Controlling the NM Station's Access to
the Device.
l To allow a specified module on the managed device to report alarms to the NM station,
follow the procedure described in Configuring the Trap Function.
3.2.2 (Optional) Controlling the NM Station's Access to the Device

This section describes how to specify an NM station and manageable MIB objects for SNMP-
based communication between the NM station and managed device to improve communication
security.
Context
If a device is managed by multiple NM stations that use the same community name, note the
following points:
l If all the NM stations need to have rights to access the objects in the Viewdefault view
(1.3.6.1), skip the following steps.
l If some of the NM stations need to have rights to access the objects in the Viewdefault view
(1.3.6.1), skip Step 5.
l If all the NM stations need to manage specified objects on the device, skip Steps Step 2,
Step 3, and Step 4.
l If some of the NM stations need to manage specified objects on the device, perform all the
following steps.
Procedure
Step 1 Run:
system-view

Step 2 Run:
acl acl-number
A basic ACL is created to filter the NM station users to manage the device.
Step 3 Run:
rule [ rule-id ] { deny | permit } source { source-ip-address source-wildcard |
any }
A rule is added to the ACL.

Step 4 Run:
commit

Step 5 Run:
quit
Return to the system view.

Step 6 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 NM station has rights to access the objects in the Viewdefault view (1.3.6.1).
l excluded: If a few MIB objects on the device or some objects in the current MIB view do
not or no longer need to be managed by the NM station, excluded needs to be specified in
the command to exclude these MIB objects.
l included: If a few MIB objects on the device or some objects in the current MIB view need
to be managed by the NM station, included needs to be specified in the command to include
these MIB objects.
Step 7 Run:
The NM station's access rights are specified.

l mib-view: If some of the NM stations that use the community name need to have rights to
access the objects in the Viewdefault view (1.3.6.1), mib-view view-name does not need to
be configured in the command.
l acl: If all the NM stations that use the community name need to manage specified objects on
the device, acl acl-number does not need to be configured in the command.
If some of the NM stations that use the community name need to manage specified objects
on the device, both mib-view and acl need to be configured in the command.
Step 8 Run:
commit
----End

Follow-up Procedure
After the access rights are configured, especially after the IP address of the NM station is
specified, if the IP address changes (for example, the NM station changes its location, or IP
addresses are reallocated due to network adjustment), you need to change the IP address of the
NM station in the ACL. Otherwise, the NM station cannot access the device.
3.2.3 (Optional) Configuring the Trap Function

This section describes how to specify the alarms to be sent to the NM station, which help you
to locate important problems. After relevant parameters are set, the security of alarm sending
can be improved.
Procedure
Step 1 Run:
system-view
Step 2 Run:
snmp-agent trap enable
Alarm sending is enabled.
Step 3 Run:
snmp-agent trap enable feature-name feature-name trap-name trap-name
A trap function of a feature module is enabled. This means that an alarm of a specified feature
can be sent to the NM station.
NOTE
If the snmp-agent trap enable command is run to enable the trap functions of all modules, or the snmp-
agent trap enable feature-name command is run to enable three or more trap functions of a module, note
the following points:
l To disable the trap functions of all modules, you need to run the snmp-agent trap disable command.
l To restore the trap functions of all modules to the default status, you need to run the undo snmp-agent
trap enable or undo snmp-agent trap disable command.
l To disable one trap function of a module, you need to run the undo snmp-agent trap enable feature-
name command.
Step 4 Run:
snmp-agent trap source interface-type interface-number
The source interface for trap messages is specified.
After the source interface is specified, its IP address becomes the source IP address of trap
messages. 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 router for trap messages must be consistent with that
specified on the NM station; otherwise, the NM station does not accept the trap messages sent
from the router.
Step 5 Run:
commit

----End

After basic SNMPv1 functions are configured, you can view the SNMPv1 configuration.
Prerequisite
The configurations of basic SNMPv1 functions are complete.
Procedure
l Run the display snmp-agent community 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 command to check the rules in the specified ACL.
l Run the display snmp-agent mib-view command to check the MIB view.
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
router.
l Run the display current-configuration | include max-size command to check the
allowable maximum size of an SNMP packet.
l Run the display current-configuration | include trap command to check trap
configuration.
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.
----End
Example
When the configuration is complete, run the display snmp-agent community command. You
can view the configured community name.
<HUAWEI> display snmp-agent community
Community name:public
Group name:public
Storage-type: nonVolatile
Community name:private
Group name:private
Run the display snmp-agent sys-info version command. You can view the SNMP version
running on the agent.
<HUAWEI> display snmp-agent sys-info version
SNMP version running in the system:
SNMPv1 SNMPv3
Run the display acl acl-number command. You can view the rules in the specified ACL.
<HUAWEI> display acl 2000

Basic ACL 2000, 1 rule

Acl's step is 5
rule 5 permit source 1.1.1.1 0 (0 times matched)
Run the display snmp-agent mib-view command. You can view the MIB view.
<HUAWEI> display snmp-agent mib-view
View name:ViewDefault
MIB Subtree:internet
Subtree mask:
View Type:included
View status:active
MIB Subtree:snmpUsmMIB
Subtree mask:
View Type:excluded
View status:active
MIB Subtree:snmpVacmMIB
Subtree mask:
View Type:excluded
View status:active
MIB Subtree:snmpCommunityMIB
Subtree mask:
View Type:excluded
View status:active
Run the display snmp-agent sys-info contact command. You can view the equipment
<HUAWEI> display snmp-agent sys-info contact
The contact person for this managed node:
R&D Beijing, Huawei Technologies co.,Ltd.
Run the display snmp-agent sys-info location command. You can view the location of the
device.
<HUAWEI> display snmp-agent sys-info location
The physical location of this node:
Beijing China
Run the display current-configuration | include max-size command. You can view the
<HUAWEI> display current-configuration | include max-size
snmp-agent packet max-size 1800
Run the display current-configuration | include trap command. You can view trap
configuration.
<HUAWEI> display current-configuration | include trap
snmp-agent trap source Ethernet 3/0/7
snmp-agent target-host host-name targetHost_1_25846 trap ipv6 address udp-domain
1:1::1:1 udp-port 111 params securityname htipl
snmp-agent target-host host-name targetHost_2_51321 trap address udp-domain 1.1.
1.1 params securityname htipl
Run the display current-configuration command to view VACM groups.

<HUAWEI> display snmp-agent vacmgroup
--------------------------------------------------
Security name : public
Group name : public
Security model : SNMPv1


Group name : public
Security model : SNMPv2c
--------------------------------------------------
Run the display snmp-agent target-host command. You can view information about the target
host.
<HUAWEI> display snmp-agent target-host
Target-host NO. 1
-----------------------------------------------------------
Host-name : targetHost_1_55062
IP-address : 10.18.27.183
VPN instance : -
Port : 162
Type : trap
Version : v1
Level : No authentication and privacy
NMS type : NMS
-----------------------------------------------------------
Target-host NO. 2
-----------------------------------------------------------
IP-address : 10.18.27.184
VPN instance : -
Security name : private
Port : 162
Type : trap
Version : v1
NMS type : HW NMS
-----------------------------------------------------------

Station by Running SNMPv2c
After SNMPv2c is configured, a managed device and an NM station can run SNMPv2c to
details about configuration on an NM station, see the pertaining NMS operation guide.
SNMP has to be deployed in a network to allow the NMS to manage network devices.
If your network is of a large scale with many devices and its security requirements are not strict
or the network is secure (for example, a VPN network) but services on the network are so busy
that traffic congestion may occur, then the SNMPv2c can be deployed to ensure communication
between the NM station and managed devices.
Before configuring a device to communicate with an NM station by running SNMPv2c,
configure a routing protocol to ensure that at least one route exist between router and NM station.


SNMPv2c
3.3.1 Configuring Basic SNMPv2c Functions

After basic SNMP functions are configured, the NM station can perform basic operations such
as Get and Set operations on the managed device, and the managed device can send alarms to
the NM station.
Context
Steps 3, 4, and 5 are mandatory for the configuration of basic SNMP functions. After the
configuration is complete, basic SNMP communication can be established between the NM
Procedure
Step 1 Run:
system-view

snmp-agent

Step 3 Run:
snmp-agent sys-info version v2c

By default, SNMPv3 is enabled.
After SNMPv2c is enabled on the managed device, the device supports both SNMPv2c and
SNMPv3. This means that the device can be monitored and managed by NM stations running
SNMPv2c and SNMPv3.
Step 4 Run:
The community name is set.

After the community name is set, if no MIB view is configured, the NM station that uses the
community name has rights to access objects in the Viewdefault view (1.3.6.1).
Step 5 Choose one of the following commands as needed to configure the destination IP address for
l If the network is an IPv4 network, configure the device to send either traps or informs to the
NM station.
NOTE
The differences between traps and informs are as follows:

l The traps sent by the managed device do not need to be acknowledged by the NM station.
l The informs sent by the managed device need to be acknowledged by the NM station. If no
acknowledgement message from the NM station 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 NM station and
link between the NM station and managed device recovers from a fault, the NM station 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 informs is recommended.
– To configure a destination IP address for the traps and error codes sent from the device,
run:
number ] [ public-net | vpn-instance vpn-instance-name ] params securityname
security-name [ v2c ] [ private-netmanager ]
– To configure a destination IP address for the informs and error codes sent from the device,
run:
snmp-agent target-host inform address udp-domain ip-address [ udp-port port-
number ] [ vpn-instance vpn-instance-name ] params securityname security-
name [ v2c ]

– udp-port: The default destination UDP port number is 162. In some special cases (for
example, port mirroring is configured to prevent a well-known port from being attacked),

the parameter udp-port can be used to specify a non-well-known UDP port number. This
ensures communication between the NM station and managed device.
– public-net: If the alarms sent from the managed device to the NM station need to be
transmitted over a public network, the parameter public-net needs to be configured.
– vpn-instance: If the alarms sent from the managed device to the NM station need to be
transmitted over a private network, the parameter vpn-instance vpn-instance-name needs
to be used to specify a VPN that takes over the sending task.
– securityname: Identifies the alarm sender, which helps you learn the alarm source.
run:
snmp-agent target-host trap ipv6 { address udp-domain ipv6-address } [ udp-port
port-number ] params securityname security-name [ v2c ]
NOTE
An IPv6 network supports only traps, not informs.


bytes.
size.
Step 8 Run:
commit
----End
Follow-up Procedure
After the configuration is complete, basic communication can be conducted between the NM
l Access control allows any NM station that uses the community name to monitor and manage
all the objects on the managed device.
l The managed device sends alarms generated by the modules that are open by default to the
NM station.
If finer device management is required, follow directions below to configure the managed
device:

l To allow a specified NM station that uses the community name to manage specified objects
of the device, follow the procedure described in Controlling the NM Station's Access to
the Device.
follow the procedure described in Configuring the Trap Function or Configuring the
Inform Function.

This section describes how to specify an NM station and manageable MIB objects for SNMP
security.
Context
If a device is managed by multiple NM stations that use the same community name, note the
following points:
l If all the NM stations need to have rights to access the objects in the Viewdefault view,
skip the following steps.
l If some of the NM stations need to have rights to access the objects in the Viewdefault
view, skip Step 5.
l If all the NM stations need to manage specified objects on the device, skip Steps 2, Steps
3, and Steps 4.
following steps.
Procedure
Step 1 Run:
system-view

Step 2 Run:
acl acl-number
Step 3 Run:
any }

Step 4 Run:
commit

Step 5 Run:
quit

Step 6 Run:


By default, an NM station has rights to access the objects in the Viewdefault view.
these MIB objects.
Step 7 Run:
The NM station's access rights are specified.

l mib-view: If some of the NM stations that use the community name need to have rights to
access the objects in the Viewdefault view, mib-view view-name does not need to be
configured in the command.
l acl: If all the NM stations that use the community name need to manage specified objects on
the device, acl acl-number does not need to be configured in the command.
If some of the NM stations that use the community name need to manage specified objects
on the device, both mib-view and acl need to be configured in the command.
Step 8 Run:
commit
----End
Follow-up Procedure

can be improved.
Procedure
Step 1 Run:
system-view

Step 2 Run:
Step 3 Run:
NOTE
name command.
Step 4 Run:
from the router.
Step 5 Run:
commit
----End
3.3.4 (Optional) Configuring the Informs Function

The router enabled with the SNMP agent function can generate two notifications, namely, traps
and informs. Traps are messages alerting the NMS to a condition on the network. Informs are
traps that include a request for confirmation of receipt from the NMS (Informs are resent until
a reply is received). Informs are more reliable than traps.
Procedure
Step 1 Run:
system-view

Step 2 Run:
snmp-agent target-host [ host-name host-name ] inform address udp-domain ip-
address [ udp-port port-number ] [ vpn-instance vpn-instance-name ] params
securityname security-name [ v2c | v3 [ authentication | privacy ] ]
The target host that receives informs is configured.
NOTE
The IP address of the target host in this command must be an IPv4 address.

snmp-agent inform { timeout seconds | resend-times times | pending number } *
The timeout period for waiting for inform Ack messages, number of times to resend informs,
and the maximum pieces of pending informs (Informs need to be acknowledged) are set.
By default, the timeout period for inform Ack messages is 15 seconds, the number of times to
resend informs is 3, and the maximum count of pending informs is 39.
NOTE
If the network is unstable, you need to increase the timeout period. At the same time, you need to increase
the number of times to resend informs and the maximum count of pending informs.
Step 4 Run:
snmp-agent inform { timeout seconds | resend-times times } * [ host-name host-name
| address udp-domain ip-address [ vpn-instance vpn-instance-name ] params
securityname security-name ]
The timeout period for waiting for inform Ack messages and the number of times to resend
informs are set.
By default, the timeout period for waiting for inform Ack messages is 15 seconds and the number
of times to resend informs is 3.
Step 5 Run:
commit
----End

After basic SNMPv2c functions are configured, you can view the SNMPv2c configuration.
Prerequisite
The configurations of basic SNMPv2c functions are complete.
Procedure
l Run the display snmp-agent community command to check the configured community
name.
version.

router.
configuration.
l Run the display snmp-agent target-host command to check information about the target
host.
l Run the display snmp-agent inform command to check inform parameters of all target
hosts.
----End
Example
When the configuration is complete, run the display snmp-agent community command. You
can view the configured community name.
Community name:public
Group name:public
Community name:private
Group name:private
SNMPv1 SNMPv3
Acl's step is 5
Subtree mask:
View Type:included
View status:active
Subtree mask:
View Type:excluded
View status:active
Subtree mask:
View Type:excluded
View status:active

MIB Subtree:snmpModules.18
Subtree mask:
View Type:excluded
View status:active
device.
Beijing China
configuration.
host.
Target-host NO. 1
-----------------------------------------------------------
IP-address : 10.18.27.183
VPN instance : -
Port : 162
Type : inform
Version : v2c
NMS type : NMS
-----------------------------------------------------------
Target-host NO. 2
-----------------------------------------------------------
IP-address : 10.18.27.184
VPN instance : -
Port : 162
Type : trap
Version : v2c
NMS type : HW NMS
-----------------------------------------------------------
Run the display snmp-agent inform command. You can view the configuration of inform
notifications.

<HUAWEI> display snmp-agent inform

Global config: resend-times 3, timeout 15s, pending 39
Global status: current notification count 0
Target-host ID: Host name/VPN instance/IP-Address/Security name
targetHost_1_36305/-/1.2.1.2/public:
Config: resend-times 3, timeout 15s
Status: retries 0, pending 0, sent 0, dropped 0, failed 0, confirmed 0

--------------------------------------------------
Group name : public

Group name : public
--------------------------------------------------

Station by Running SNMPv3
details about configurations on an NM station, see the NMS operation guide.
The NM station manages a device by the following ways:
l Sends requests to the managed device to perform the GetRequest, GetNextRequest,
GetResponse, GetBulk, or SetRequest operation, obtaining data or setting values.
l Receives alarms (traps or informs) from the managed device to locate and handle device
faults based on the alarm information.
Before configuring a device to communicate with an NM station by running SNMPv3, configure
a routing protocol to ensure that at least one route exist between router and NM station.


SNMPv3
3.4.1 Configuring Basic SNMPv3 Functions

After basic SNMP functions are configured, the NM station can perform basic operations such
as Get and Set operations on the managed device, and the managed device can send alarms to
the NM station.
Context
Steps 4, 5, and 6 are mandatory to configure of basic SNMP functions. After the configuration
is complete, basic SNMP communication can be established between the NM station and
managed device.
Procedure
Step 1 Run:
system-view

snmp-agent



By default, SNMPv3 is enabled. So, this step is optional.
Step 4 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.
The available authentication and privacy modes are as follows:
l No authentication and no privacy: Neither authentication nor privacy is configured in the
command. This mode is applicable to secure networks managed by a specified administrator.
l Authentication without privacy: Only authentication is configured in the command. This
mode is applicable to secure networks managed by many administrators who may frequently
perform operations on the same device. In this mode, only the authenticated administrators
can access the managed device.
l Authentication and privacy: privacy is configured in the command. This mode is applicable
to insecure networks managed by many administrators who may frequently perform
operations on the same device. In this mode, only the authenticated administrators can access
the managed device, and transmitted data is encrypted to guard against interception and data
leaking.
Step 5 Run:
snmp-agent usm-user v3 user-name group-name [ authentication-mode { md5 | sha }
password [ privacy-mode des56 password ] ]
A user is added to the SNMPv3 user group.

After a user is added to the user group, the NM station that uses the name of the user can access
the objects in the Viewdefault view (1.3.6.1).
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.
l Authentication mode
– Message Digest 5 (MD5): generates a 128-bit message digest for an input message of any
length.
– Secure Hash Algorithm (SHA-1): generates a 160-bit message digest for an input message
of less than 264 bits.
MD5 is faster than SHA-1, but is considered less secure.
l Privacy mode
DES uses a 56-bit key to encrypt a 64-bit plain text block.
Step 6 Choose one of the following commands as needed to configure the destination IP address for

run:
number ] [ public-net | vpn-instance vpn-instance-name ] params securityname
security-name [ v3 [ authentication | privacy ] ] [ private-netmanager ]
run:
snmp-agent target-host trap ipv6 address udp-domain ip-address [ udp-port port-
number ] params securityname security-name [ v3 [ authentication | privacy ] ]

l udp-port: The default destination UDP port number is 162. In some special cases (for
example, port mirroring is configured to prevent a well-known port from being attacked),
the parameter udp-port can be used to specify a non-well-known UDP port number. This
ensures communication between the NM station and managed device.
l securityname: Identifies the alarm sender, which helps you learn the alarm source.
The engine ID for the local SNMP agent is set.

By default, the NE5000E uses an internal algorithm to automatically generate an engine ID for
a device. The engine ID consists of the enterprise number and the device information.

bytes.
size.
Step 10 Run:
commit
----End
Follow-up Procedure
After the steps, basic communication is established between the NM station and managed device.
l Access control allows any NM station in the configured SNMPv3 user group to monitor
and manage all the objects on the managed device.

l The managed device sends alarms generated by the modules that are open by default to the
NM station.=
If finer device management is required, follow directions below to configure the managed
device:
l To allow a specified NM station in an SNMPv3 user group to manage specified objects of
the device, follow the procedure described in Controlling the NM Station's Access to the
Device.
follow the procedure described in Configuring the Trap Function or Configuring the
Inform Function.

This section describes how to specify an NM station and manageable MIB objects for SNMPv3-
security.
Context
If a device is managed by multiple NM stations that are in the same SNMPv3 user group, note
l If all the NM stations need to have rights to access the objects in the Viewdefault view,
skip the following steps.
l If some of the NM stations need to have rights to access the objects in the Viewdefault
view, skip Step 5.
l If all the NM stations need to manage specified objects on the device, skip Step 2, Step
3, and Step 4.
following steps.
Procedure
Step 1 Run:
system-view
Step 2 Run:
acl acl-number
Step 3 Run:
any }
Step 4 Run:
commit

Step 5 Run:
quit

Step 6 Run:

By default, an NM station has rights to access the objects in the Viewdefault view.
these MIB objects.
Step 7 Run:
snmp-agent group v3 group-name [ authentication | privacy ] [ read-view read-view
| write-view write-view | notify-view notify-view ]* [ acl acl-number ]
The read and write permission is configured for the user group.
l read-view needs to be configured in the command if the NM station administrator needs the
read permission in the specified view in some cases. For example, a low-level administrator
needs to read certain data. write-view needs to be configured in the command if the NM
station administrator needs the read and write permissions in the specified view in some
cases. For example, a high-level administrator needs to read and write certain data.
l notify-view needs to be configured in the command if you want to filter out irrelevant alarms
and configure the managed device to send only the alarms of specified MIB objects to the
NM station. If the parameter is configured, only the alarms of the MIB objects specified by
notify-view is sent to the NM station.
l authentication or privacy can be configured in the command to improve security. If
authentication is configured, only authentication is performed. If privacy is configured,
both authentication and privacy are performed.
l If some NM stations that are in the same SNMPv3 user group need to have rights to access
the objects in the Viewdefault view, [ read-view read-view | write-view write-view | notify-
view notify-view ] does not need to be configured in the command.
l acl: If all the NM stations that are in the same SNMPv3 user group need to manage specified
objects on the device, acl acl-number does not need to be configured in the command.
If some of the NM stations that are in the same SNMPv3 user group need to manage specified
objects on the device, then mib-view and acl need to be configured in the command.
Step 8 Run:
commit
----End
Follow-up Procedure

3.4.3 Configuring SNMPv3 Authentication and Privacy

This section describes how to configure authentication and privacy to implement security
features of SNMPv3.
Procedure
Step 1 Run:
system-view

Step 2 Run:
snmp-agent group v3 group-name
An SNMPv3 user group is configured.

Step 3 (Optional) Configure an ACL, add an ACL rule and to apply an ACL to SNMPv3 user group.
1. Run:
acl acl-number
A basic ACL is created.

2. Run:
rule [ rule-id ] { deny | permit } source { source-ip-address source-wildcard
| any }

3. Run:
snmp-agent group v3 group-name acl acl-number
The ACL is applied.

Step 4 Add an SNMPv3 user to a user group.
Run:
snmp-agent usm-user v3 user-name group-name
A specific user is added to a specified SNMPv3 user group.

By mapping SNMPv3 users in different user groups into different views, you can configure
different access rights for SNMPv3 users in different user groups.
Step 5 (Optional) Configure an ACL for an SNMPv3 user.
1. Run:
acl acl-number
A basic ACL is created.

2. Run:
rule [ rule-id ] { deny | permit } source { source-ip-address source-wildcard
| any }

3. Run:
snmp-agent usm-user v3 user-name group-name acl acl-number

The ACL is applied.

Step 6 Run:
snmp-agent group v3 group-name authentication
Authentication is configured for a specified SNMPv3 user group.

Step 7 Run:
snmp-agent group v3 group-name privacy
Privacy is configured for a specified SNMPv3 user group.

Step 8 Run:
snmp-agent usm-user v3 user-name group-name [ [ authentication-mode { md5 | sha }
password ] [ privacy-mode des56 password ] ] [acl acl-number ]
Authentication and privacy are configured for SNMPv3 users in a user group.
Step 9 Run:
commit
----End

can be improved.
Procedure
Step 1 Run:
system-view

Step 2 Run:

Step 3 Run:
NOTE
name command.

Step 4 Run:

from the router.
Step 5 Run:
commit
----End
3.4.5 (Optional) Configuring the Informs Function

The router enabled with the SNMP agent function can generate two notifications, namely, traps
and informs. Traps are messages alerting the NMS to a condition on the network. Informs are
traps that include a request for confirmation of receipt from the NMS (Informs are resent until
a reply is received). Informs are more reliable than traps.
Procedure
Step 1 Run:
system-view

Step 2 Run:
snmp-agent target-host [ host-name host-name ] inform address udp-domain ip-
address [ udp-port port-number ] [ vpn-instance vpn-instance-name ] params
securityname security-name [ v2c | v3 [ authentication | privacy ] ]
The target host that receives informs is configured.
NOTE
The IP address of the target host in this command must be an IPv4 address.

snmp-agent inform { timeout seconds | resend-times times | pending number } *
The timeout period for waiting for inform Ack messages, number of times to resend informs,
and the maximum pieces of pending informs (Informs need to be acknowledged) are set.
By default, the timeout period for inform Ack messages is 15 seconds, the number of times to
resend informs is 3, and the maximum count of pending informs is 39.
NOTE
If the network is unstable, you need to increase the timeout period. At the same time, you need to increase
the number of times to resend informs and the maximum count of pending informs.
Step 4 Run:

snmp-agent inform { timeout seconds | resend-times times } * [ host-name host-name

| address udp-domain ip-address [ vpn-instance vpn-instance-name ] params
securityname security-name ]
The timeout period for waiting for inform Ack messages and the number of times to resend
informs are set.
By default, the timeout period for waiting for inform Ack messages is 15 seconds and the number
of times to resend informs is 3.
Step 5 Run:
commit
----End

After basic SNMPv3 functions are configured, you can view the SNMPv3 configuration.
Prerequisite
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.
router.
configuration.
l Run the display snmp-agent target-host command to check information about target
hosts.
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 ] ]
command to check inform parameters of all target hosts or a specified target host and
information about host statistics.
----End

Example
Run the display snmp-agent usm-user command. You can view SNMP user information.
<HUAWEI> display snmp-agent usm-user
User name: John
Engine ID: 800007DB03360102101100 active
Authentication Protocol: md5
Privacy Protocol: des56
Group-name: group1
SNMPv3
Acl's step is 5
Subtree mask:
View Type:included
View status:active
Subtree mask:
View Type:excluded
View status:active
Subtree mask:
View Type:excluded
View status:active
MIB Subtree:snmpCommunityMIB
Subtree mask:
View Type:excluded
View status:active
device.
Beijing China

configuration.
host.
Target-host NO. 1
-----------------------------------------------------------
IP-address : 10.18.27.183
VPN instance : -
Port : 162
Type : inform
Version : v3
NMS type : NMS
-----------------------------------------------------------
Target-host NO. 2
-----------------------------------------------------------
IP-address : 10.18.27.184
VPN instance : -
Port : 162
Type : trap
Version : v3
NMS type : HW NMS
-----------------------------------------------------------
Run the display snmp-agent inform command. You can view the configuration of inform
notifications.
<HUAWEI> display snmp-agent inform
Global config: resend-times 3, timeout 15s, pending 39
Global status: current notification count 0
Target-host ID: Host name/VPN instance/IP-Address/Security name
targetHost_1_36305/-/1.2.1.2/public:
Config: resend-times 3, timeout 15s
Status: retries 0, pending 0, sent 0, dropped 0, failed 0, confirmed 0

--------------------------------------------------
Group name : public

Group name : public
Security name : 456

Group name : 123
Security model : USM
Security name : abc

Group name : def

Security model : USM
--------------------------------------------------
3.5 SNMP Configuration Examples

This section provides several configuration examples of SNMP. The configuration roadmap in
the examples helps you understand the configuration procedures. Each configuration example
provides information about the networking requirements, configuration notes, and configuration
roadmap.
3.5.1 Example for Configuring a Device to Communicate with an

NM Station by Using SNMPv1
This section provides an example to describe how to configure a device to communicate with
an NM station by using SNMPv1 and how to specify MIB objects that can be managed by the
NM station.
CAUTION
interface number. In the multi-chassis scenario, an interface is numbered in the format of chassis
As shown in Figure 3-7, two NM stations (NMS1 and NMS2) and the router are connected
across a public network. According to the network planning, NMS2 can manage every MIB
object except HGMP on the router, and NMS1 does not manage the router.
On the router, only the modules that are enabled by default are allowed to send alarms to NMS2.
This prevents an excess of unwanted alarms from being sent to NMS2. Excessive alarms make
fault location difficult.
Contact information of the equipment administrator needs to be configured on the router. This
helps the NMS administrator to contact the equipment administrator if a fault occurs.
Figure 3-7 Networking diagram for configuring a device to communicate with an NM station
by using SNMPv1
NMS1
1.1.1.1/24 GE1/0/0
IP Network 1.1.2.1/24
Router
NMS2
1.1.1.2/24

1. Enable the SNMP agent.
2. Configure the router to run SNMPv1.
3. Configure an ACL to allow NMS2 to manage every MIB object except HGMP on the
router.
4. Configure the trap function to allow the router to send alarms to NMS2.
5. Configure the contact information of the equipment administrator on the router.
6. Configure NMS2.
Data Preparation
l SNMP version
l Community name
l ACL number
l IP address of the NM station
l Contact information of the equipment administrator
Procedure
Step 1 Configure available routes between the router and the NM stations. Details for the configuration
procedure are not provided here.
Step 2 Enable the SNMP agent.
[~HUAWEI] snmp-agent
[~HUAWEI] commit
Step 3 Configure the router to run SNMPv1.

[~HUAWEI] snmp-agent sys-info version v1
[~HUAWEI] commit
Step 4 Configure the NM stations access rights.

# Configure an ACL to allow NMS2 to manage and disallow NMS1 from managing the
router.
[~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 a MIB view and allow NMS2 to manage every MIB object except HGMP on the
router.
[~HUAWEI] snmp-agent mib-view excluded allexthgmp 1.3.6.1.4.1.2011.6.7
[~HUAWEI] commit
# Configure a community name to allow NMS2 to manage the objects in the MIB view.

[~HUAWEI] snmp-agent community write adminnms2 mib-view allexthgmp acl 2001

[~HUAWEI] commit
Step 5 Configure the trap function.

[~HUAWEI] snmp-agent target-host trap address udp-domain 1.1.1.2 params
securityname 1.1.3.1
[~HUAWEI] snmp-agent trap enable
[~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.

For details on how to configure NMS2, see the relevant NMS configuration guide.
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
SNMPv1 SNMPv3
# Check information about the SNMP community name.

Community name:adminnms2
Group name:adminnms2
Acl:2001
# Check the configured ACL.

Basic ACL 2001, 2 rules
Acl's step is 5
rule 5 permit source 1.1.1.2 0.0.0.0
rule 6 deny source 1.1.1.1 0.0.0.0
# Check the MIB view.

<HUAWEI> display snmp-agent mib-view viewname allexthgmp
View name:allexthgmp
MIB Subtree:huaweiUtility.7
Subtree mask:
View Type:excluded
View status:active
# Check the target host.

Target-host NO. 1
-----------------------------------------------------------
IP-address : 1.1.1.2
VPN instance : -
Security name : 1.1.3.1
Port : 162
Type : trap
Version : v1
NMS type : NMS
-----------------------------------------------------------

# Check the contact information of the equipment administrator.

call Operator at 010-12345678
----End
Configuration Files
Configuration file of the router
#
acl number 2001
#
undo shutdown
ip address 1.1.2.1 255.255.255.0
#
interface loopback0
ip address 1.1.3.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.2.0 0.0.0.255
network 1.1.3.1 0.0.0.0
#
snmp-agent
snmp-agent local-engineid 800007DB03360102101100
snmp-agent community write adminnms2 mib-view allexthgmp acl 2001
#
snmp-agent sys-info contact call Operator at 010-12345678
snmp-agent sys-info version v1 v3
snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname
1.1.3.1
#
snmp-agent mib-view excluded allexthgmp hwCluster
#
#
return

NM Station by Using SNMPv2c
an NM station by using SNMPv2c and how to specify the MIB objects that can be managed by
the NM station.
CAUTION

This prevents an excess of unwanted alarms from being sent to NMS2. Excessive alarms can
make fault location difficult. Informs need to be used to ensure that alarms are received by NMS2
because alarms sent by the router have to travel across the public network to reach NMS2.
by using SNMPv2c
NMS1
1.1.1.1/24 GE1/0/0
Router
NMS2
1.1.1.2/24

2. Configure the router to run SNMPv2c.
router.
4. Configure the router to send informs to NMS2 to ensure alarm sending reliability.
5. Configure the contact information of the equipment administrator.
6. Configure NMS2.
Data Preparation
l SNMP version
l Community name
l ACL number

Procedure
Step 2 Enable the SNMP agent.
[~HUAWEI] commit
Step 3 Configure the router to run SNMPv2c.

[~HUAWEI] snmp-agent sys-info version v2c
[~HUAWEI] commit

SNMPv2c SNMPv3

router.
[~HUAWEI] acl 2001
# Configure a MIB view.

[~HUAWEI] commit
# Configure a community name to allow NMS2 to manage the objects in the MIB view.
[~HUAWEI] snmp-agent community write adminnms2 mib-view allexthgmp acl 2001
[~HUAWEI] commit

[~HUAWEI] snmp-agent target-host inform address udp-domain 1.1.1.2 params
securityname 1.1.2.1
[~HUAWEI] snmp-agent inform timeout 5 resend-times 6 pending 7
[~HUAWEI] commit

[~HUAWEI] commit
Step 7 Configure NMS2.

has taken effect.
SNMPv2c SNMPv3

# Check information about the SNMP community name.

Community name:adminnms2
Group name:adminnms2
Acl:2001

Acl's step is 5

Subtree mask:
View Type:excluded
View status:active

Target-host NO. 1
-----------------------------------------------------------
VPN instance : -
Port : 162
Type : trap
Version : v1
NMS type : NMS
-----------------------------------------------------------

----End
Configuration Files
#
acl number 2001
#
undo shutdown
ip address 1.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 1.1.2.0 0.0.0.255
#
snmp-agent

snmp-agent community write adminnms2 mib-view allexthgmp acl 2001

#
snmp-agent sys-info version v2c v3
snmp-agent target-host inform address udp-domain 1.1.1.2 params securityname
1.1.2.1
#
snmp-agent mib-view excluded allexthgmp hwCluster
#
snmp-agent inform timeout 5
snmp-agent inform resend-times 6
snmp-agent inform pending 7
#
return

NM Station by Using SNMPv3
an NM station by using SNMPv3 and how to specify the MIB objects that can be managed by
the NM station.
CAUTION
This prevents an excess of unwanted alarms from being sent to NMS2. Excessive alarms can
make fault location difficult.
The data transmitted between NMS2 and the router needs to be encrypted and the NMS
administrator needs to be authenticated because the data has to travel across the public network.

by using SNMPv3
NMS1
1.1.1.1/24 GE1/0/0
Router
NMS2
1.1.1.2/24

2. Configure the router to run SNMPv3.
router and configure data encryption.
4. Configure the trap function to allow the router to send alarms to NMS2.
5. Configure the contact information of the equipment administrator.
6. Configure NMS2.
Data Preparation
l SNMP version
l User group name
l User name and password
l Authentication and privacy algorithms
l ACL number
Procedure
Step 2 Configure the SNMP agent.


Step 3 Configure the router to run SNMPv3.

[~HUAWEI] snmp-agent sys-info version v3
[~HUAWEI] commit

SNMPv3

router.
[~HUAWEI] acl 2001
# 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 router and NMS2.
[~HUAWEI] snmp-agent usm-user v3 nms2-admin admin authentication-mode md5 87654321
privacy-mode des56 87654321
[~HUAWEI] snmp-agent group v3 admin privacy write-view allexthgmp acl 2001
[~HUAWEI] commit

[~HUAWEI] snmp-agent target-host trap address udp-domain 1.1.1.2 params
securityname 1.1.3.1 v3
[~HUAWEI] snmp-agent trap enable
Warning: All switches of SNMP trap/notification will be open. Continue? [Y/N]: Y
[~HUAWEI] commit

[~HUAWEI] commit
Step 7 Configure the NM station.

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: allexthgmp
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: des56,
Group-name: admin

Acl's step is 5

Subtree mask:
View Type:excluded
View status:active

Target-host NO. 1
-----------------------------------------------------------
VPN instance : -
Port : 162
Type : trap
Version : v3
NMS type : NMS
-----------------------------------------------------------

----End
Configuration Files
#
acl number 2001
#
undo shutdown
ip address 1.1.2.1 255.255.255.0
#

interface loopback0
ip address 1.1.3.1 255.255.255.255
#
ospf 1
area 0.0.0.0
network 1.1.2.0 0.0.0.255
network 1.1.3.1 0.0.0.0
#
snmp-agent
#
snmp-agent group v3 admin privacy write-view allexthgmp acl 2001
snmp-agent target-host trap address udp-domain 1.1.1.2 params securityname 1.1.3.1
v3
#
snmp-agent mib-view excluded allexthgmp hwHgmp
snmp-agent usm-user v3 nms2-admin admin authentication-mode md5 `,+VK;'MYJF=,/
<97^aP^1!! privacy-mode des56 `,+VK;'MYJF=,/<97^aP^1!!
#
return

Configuration Guide - System Management 4 Log Management
4 Log Management
About This Chapter
The log management function controls the output of log information.
4.1 Log Management Overview

Logs are real-time records of information about system operation status and internal errors. Log
management plays an important role in locating faults and assigning responsibility for problems.
4.2 Log Management Features that the NE5000E Supports
This section describes log management features that the NE5000E supports.
4.3 (Optional) Filtering Logs
This function allows you to filter out specified logs.
4.4 Setting the Maximum Number of Logs to Be Displayed
This section describes how to set the maximum number of logs to be displayed.
4.5 Setting the Maximum Number of Traps to Be Displayed
This section describes how to set the number of trap messages to be displayed.
4.6 Saving Logs to a Local Log File
This section describes how to save logs to a local log file.
4.7 Configuring Logs to Be Output to a Log Host
This section describes how to configure logs to be output to a specified log host.
4.8 Maintenance
The system generates logs or traps and send them to the information buffer for user query. To
delete information in the information buffer, run the following commands:
This section provides examples for implementing log management.

4.1 Log Management Overview

Logs are real-time records of information about system operation status and internal errors. Log
management plays an important role in locating faults and assigning responsibility for problems.
Log management refines log classifications and effectively filters output information. Log
management allows you to set the maximum number of logs to be displayed, save logs to a local
log file, and configure logs to be output to a log host.
4.2 Log Management Features that the NE5000E Supports

This section describes log management features that the NE5000E supports.
l Logs can be recorded and queried.

l The Syslog protocol defined in RFC 3164 is supported, and a Huawei device can send logs
to a maximum of eight log hosts at the same time.
The following part describes the log classification, levels, and format.
Log Naming
As shown in Table 4-1, logs are divided into the following types.
Table 4-1 Log naming
Naming Description
Method
currentDevLog.l Single diagnostic log file of the system

og
log.log Single log file of the system
Dev_SlotID_tim Log file in Dev_SlotID_time.log.zip format (When a single log file is a

e.log.zip larger than 8 MB, it will be compressed as a Dev_SlotID_time.log.zip
file.)
"SlotID" indicates a slot ID. "time" indicate the time when a compressed
file is generated.
log_SlotID_time. Log file in log_SlotID_time.log.zip format (When a single log file is a

log.zip larger than 8 MB, it will be compressed as a log_SlotID_time.log.zip
file.)
"SlotID" indicates a slot ID. "time" indicate the time when a compressed
file is generated.
Log Severity Levels

Logs are classified into eight levels by severity or urgency. The higher the log severity level,
the smaller the value. Table 4-2 lists log severity levels.

Table 4-2 Log severity levels

Severit Severity Description
y Value Level
0 Emergency System is unusable: A fatal fault occurs in the device, such as an

abnormally running program or unauthorized use of memory.
The system must restart.
1 Alert Action must be taken immediately: A serious fault occurs in a

device, such as memory usage reaching the upper limit. The fault
needs to be rectified immediately.
2 Critical Critical conditions: A critical fault occurs, such as memory usage

reaching the lower limit, the temperature reaching the lower
limit, BFD detecting an unreachable device, or an internal fault
in a device. The fault needs to be located and rectified.
3 Error Error conditions: A fault caused by an incorrect operation or

process occurs, such as an incorrect protocol packet received
from another device, a wrong command, or a wrong password.
4 Warning Warning conditions: An exception occurs, such as disabling of

a routing process, packet loss detected by BFD, or receipt of a
wrong protocol packet.
5 Notice Normal but significant conditions: A key operation is performed

to keep a device run properly, such as running the shutdown
command, neighbor discovery, or status change of the protocol
state machine.
6 Informational Informational messages: A common operation is performed to

keep a device run properly, such as running the display
command.
7 Debugging Debug-level messages: A routine operation is performed, and no

action is required.
Log Format
Figure 4-1 shows the format in which logs are output.
Figure 4-1 Log format

<Int_16>TIMESTAMP HOSTNAME %%ddAAA/B/CCC(l):VR=X-CID=ZZZ; YYYY
Table 4-3 describes the fields in a log.

Table 4-3 Log fields

Field Name Description
<Int_16> Leading character Indicates that a log will be sent to a log host. A log
to be saved on a local device does not have a
leading character.
TIMESTAMP Timestamp Indicates the time when a log is output. The value
is in the yyyy-mm-dd hh:mm:ss format:
l yyyy-mm-dd indicates the date.
l hh:mm:ss indicates the time. The value of hh
(hour) ranges from 00 to 23.
The timestamp and the host name are separated by
a space.
HOSTNAME Host name By default, it is HUAWEI.
%% Huawei identifier Indicates that the log is output by a Huawei

product.
dd Version number Indicates the version of the log format.
AAA Module name Indicates the name of the module that outputs the
log to the information center.
B Log severity level Indicates the log severity value.
CCC Description Describes the log type.
(l) Information type Identifies a user log.
VR=X- Virtual router X: virtual router ID.

CID=ZZZ information ZZZ: component ID.
YYYY Descriptor Indicates the log contents that are output to the
information center by each module. The descriptor
is filled in by each module every time a log is
output.
4.3 (Optional) Filtering Logs

This function allows you to filter out specified logs.
Context
After a specified log is filtered out, the router no longer records or displays this log, or outputs
this log to a log host.
Procedure
Step 1 Run:
system-view


Step 2 Run:
info-center filter-id { filter-id | bymodule-alias modname alias }
One or multiple logs specified in this command are filtered out. Log IDs or alias names in this
command must be separated by spaces.
Step 3 Run:
commit
----End
4.4 Setting the Maximum Number of Logs to Be Displayed

This section describes how to set the maximum number of logs to be displayed.
The system logs information about device operations in real time. You can view logs in the log
buffer to understand what happened during system operations.
Before setting the maximum number of logs to be displayed, complete the following tasks:
l Making sure that the device is powered on
l Ensuring that the device self-check succeeds
Procedure
Step 1 Run:
system-view

Step 2 Run:
info-center logbuffer size buffersize
The maximum number of logs to be displayed is set.

By default, a maximum of 512 logs are displayed.
----End

Run the display logbuffer [ starttime starttime-value [ endtime endtime-value ] | level
severity | size value ] * command to view logs.
<HUAWEI> display logbuffer size 5
May 1 2011 19:20:32 HUAWEI %%01ftpc/7/FTPC_SMPOI_USER_LOGIN(l):VR=0-
CID=2157193000;FTPC Component received new user login notification.
May 1 2011 19:20:32 HUAWEI %%01ftpc/7/FTPC_MSG_RCVD_TYPE(l):VR=0-
CID=2157193000;FTPC Component received a message (type 4).

May 1 2011 19:20:32 HUAWEI %%01ftpc/7/FTPC_MSG_RCVD(l):VR=0-CID=2157193000;FTPC

Component received a message (interface 1 subinterface 1).
May 1 2011 19:20:32 HUAWEI %%01tftpc/7/TFTPC_SMPOI_USER_LOGIN(l):VR=0-
CID=2157324073;TFTPC Component received new user login notification.
May 1 2011 19:20:32 HUAWEI %%01tftpc/7/TFTPC_MSG_RCVD_TYPE(l):VR=0-
CID=2157324073;TFTPC Component received a message (type 4).
4.5 Setting the Maximum Number of Traps to Be Displayed

This section describes how to set the number of trap messages to be displayed.
In the case of urgent and important events (such as the restart of the managed device), the device
generates logs and sends trap messages to the NMS through SNMP agent. Trap messages are
sent to the NMS from the managed device without any request. Users can view trap messages
on the device.
Before setting the number of trap messages to be displayed, complete the following tasks:
l Confirming that the device is powered on correctly and the self-test is successful
Procedure
Step 1 Run:
system-view

Step 2 Run:
info-center trapbuffer
Display of traps is enabled.

By default, display of traps is enabled.
Step 3 Run:
info-center trapbuffer size buffersize
The number of trap messages to be displayed is set.

By default, a maximum of 256 trap messages are displayed.
----End

Run the display trapbuffer [ size value ] command to view information about the trap buffer.
<HUAWEI> display trapbuffer size 3
Trapping buffer configuration and contents : enabled
Allowed max buffer size : 1024
Actual buffer size : 512
Dropped messages : 0
Overwritten messages : 0
Current messages : 187
May 1 2011 19:20:32 HUAWEI %%01STANDARD/6/linkup:VR=0-CID=0x807a271c-OID=1.3.6.

1.6.3.1.1.5.4;The interface status changes. (ifName=Ethernet3/0/5, AdminStatus=U

P, OperStatus=UP, Reason=Interface physical link is Up.)
1.6.3.1.1.5.4;The interface status changes. (ifName=Ethernet3/0/5.125, AdminStat
us=UP, OperStatus=UP, Reason=Interface physical link is Up.)
1.6.3.1.1.5.4;The interface status changes. (ifName=Ethernet3/0/5.124, AdminStat
us=UP, OperStatus=UP, Reason=Interface physical link is Up.)

This section describes how to save logs to a local log file.
The system records operation status to the log buffer in real time. Logs can be saved to a log file
by using the specified command. You can query the log file to understand what happened during
system operations.
Procedure
Step 1 In the user view, run:
save logfile
Logs are saved to a local log file.
If you need to save logs in the log buffer into a log file when the log buffer is not full or the timer
does not expire, run the save logfile command.
----End

After completing the configuration, run the display logfile path command to view the log file.
<HUAWEI>display logfile cfcard:/logfile/log_17_20110504041811.log.zip
2010-08-13 07:05:14 HUAWEI %%01cli/5/CLI_USER_LOGIN(l):VR=0-CID=2160731923;Common
username:root login from CONSOLE, channelid 32768, result :Login success.
2010-08-13 07:05:16 HUAWEI %%01cli/5/CLI_CMD_RECORD_NO_RESULT(l):VR=0-
CID=2160731923;Record command information. (Task=Common, AccessMode=CONSOLE,
User=root, Command="sy".)
User=root, Command="dis dev".)
User=root, Command="q".)
User=root, Command="save logfile ".)
User=root, Command="dis logfile cfcard:/oper_6301458_20100813_0.log ".)
User=root, Command="dis logfile cfcard:/oper_6301458_20100813_0.log level 6".)
Related Tasks
4.9.1 Example for Saving Logs to a Local Log File


This section describes how to configure logs to be output to a specified log host.
The system logs information about device operations in real time. After configuring logs to be
output to a log host, you can view logs saved on the log host to assist in understanding the
operation status of the device.
Before configuring logs to be output to a log host, complete the following tasks:
l Making sure that the device is powered on
l Ensuring that the device self-check succeeds
Configuration Procedures
Figure 4-2 Flowchart for configuring logs to be output to a log host

Enable the information
center
Specify a source interface

for sending logs to a log
host
Configure logs to be
output to a specified log
host
Mandatory procedure
Optional procedure
Related Tasks
4.9.2 Example for Configuring Logs to Be Output to a Log Host
4.7.1 Enabling the Information Center

The information center is enabled by default.
Context
The system outputs system information to a log host only after the information center is enabled.
If the system needs to classify and output large volumes of information, system performance
will be affected.

Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center enable
The information center is enabled.
By default, the information center is enabled.
Step 3 Run:
commit
----End
4.7.2 (Optional) Specifying a Source Interface for Sending Logs to

a Log Host
This section describes how to specify an interface for sending logs to a log host. This helps the
log host locate the router from which a log comes.
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center loghost source interface-type interface-number
An interface on the router is specified as the source interface for sending logs to the log host.
After the source interface is specified, if the router sends logs to the log host, the logs carry the
IP address of this interface as the source address. This helps the log host locate the router from
which the logs come, facilitating log search.
By default, the source interface is the interface that sends out logs.
Step 3 Run:
commit
----End
4.7.3 Configuring Logs to Be Output to a Specified Log Host

After configuring logs to be output to a specified log host, you can view logs saved on the log
host to assist in understanding the operation status of the device.

Context
The system logs device operations in real time. After enabling the information center, you can
specify the UDP port number, facility, and log severity level of a log host with a specified IP
address to output logs to the log host. This facilitates saving and querying logs, helps the network
administrator monitor device operations, and provides evidence for fault location.
Procedure
Step 1 Run:
system-view

Step 2 Configure logs to be output to a specified log host.
l To configure logs to be output to a log host on an IPv4 network, run:
info-center loghost ipv4-address [ vpn-instance vpn-InsName | facility local-
number | port port-number | level log-level ] *
l To configure logs to be output to a log host on an IPv6 network, run:

info-center loghost ipv6 ipv6-address [ facility local-number | port port-
number | level log-level ] *
By default, the device does not output logs to any log host.
The system can output logs to a maximum of eight log hosts at the same time. This allows backup
among log hosts.
Step 3 Run:
commit
----End

After configuring logs to be output to a specified log host, you can view the configuration.
Prerequisite
The configurations of outputting logs to a specified log host are complete.
Procedure
l Run the display this command in the system view to check the ID of the log to be filtered
out, IP address of a log host, and source interface for sending logs to the log host.
----End
Example
l Run the display this command. The command output shows the configuration for
outputting logs to a specified log host.
<HUAWEI> system view
[~HUAWEI] display this
#
info-center loghost source GigabitEthernet1/0/1

info-center loghost 123.1.1.1

#
4.8 Maintenance
The system generates logs or traps and send them to the information buffer for user query. To
delete information in the information buffer, run the following commands:
Context
CAUTION
Information stored by the information buffer cannot be restored after you clear them. Exercise
caution when running the commands.
Procedure
l To delete information in the log buffer, run the reset logbuffer command in the user view.
l To delete information in the trap buffer, run the reset trapbuffer command in the user
view.
----End

This section provides examples for implementing log management.
4.9.1 Example for Saving Logs to a Local Log File

This example describes how to save logs to a local log file.
CAUTION
On a single NE5000E, an interface is numbered in the following format: slot number/card
number/interface number. On an NE5000E cluster, an interface is numbered in the format of
chassis ID/slot number/card number/interface number, and a slot is numbered in the format of
chassis ID/slot number.
On the network shown in Figure 4-3, you can save logs on Router A into log files. A large
number of log files consume significant memory resources. To save memory resources, you can
upload log files to an FTP server. Maintenance personnel query and maintain logs saved on the
FTP server to understand the operation status of Router A and locate faults in Router A.

Figure 4-3 Networking diagram for saving logs to a local log file
10.2.1.1/16
GE1/0/0 IP network
RouterA FTP Server

10.1.1.1/16
1. Save logs to a log file.
2. Upload the log file to the FTP server.
Data Preparation
l IP address of the FTP server
l User name and password used on the FTP server
Procedure
Step 1 Configure a routing protocol to make the router and the FTP server reachable. (The configuration
details are not provided here.)
Step 2 Configure user name and password used on the FTP server. (The configuration details are not
provided here.)
Step 3 Save logs to a log file.
<RouterA> save logfile
Step 4 Upload the log file to the FTP server.

# Switch to the path of the log file.
<RouterA> cd cfcard:/logfile/
# Log in to the FTP server.

<RouterA> ftp 10.1.1.1
Trying to connect...
Press CTRL+K to abort
Connected to the server
220 FTP service ready.
User(ftp 10.1.1.1:(none)):huawei
331 Password required for huawei
Password:
230 User logged in.
# Upload the log file in binary mode to the FTP server.

[ftp] binary
[ftp] put log_17_20110504041811.log.zip
[ftp] quit

<RouterA>
# View the received logs on the FTP server. (The configuration details are not provided here.)
----End
Related Tasks
4.9.2 Example for Configuring Logs to Be Output to a Log Host

This example describes how to configure logs to be output to a log host.
CAUTION
On a single NE5000E, an interface is numbered in the following format: slot number/card
number/interface number. On an NE5000E cluster, an interface is numbered in the format of
chassis ID/slot number/card number/interface number, and a slot is numbered in the format of
chassis ID/slot number.
The router can generate a large number of logs, which may exceed limited storage space of the
router. To address this problem, a log host can be configured to store all logs.
On the network shown in Figure 4-4, the router is required to send logs to the log host Server
1. Server 2 is required to serve as a backup host for Server 1.
The configurations need to be performed on both the router and the log host.
Figure 4-4 Networking diagram of configuring logs to be output to a log host

10.1.1.1/24
Server1
POS1/0/0
172.168.0.1/24
Router
Server 2
10.2.1.1/24

1. Enable the information center.

2. Configure logs to be output to a specified log host.
3. Specify a source interface for sending logs to the log host.
4. Configure the log host.
Data Preparation
l IP address of a log host
Procedure
Step 1 Configure a routing protocol and an IP address for the router to make the router and log host
reachable. (The configuration details are not provided here.)
Step 2 Enable the information center.
[~HUAWEI] info-center enable
Step 3 Configure logs to be output to a specified log host.

# Specify Server 1 as the log host, and Server 2 as the backup log host.
[~HUAWEI] info-center loghost 10.1.1.1
[~HUAWEI] info-center loghost 10.1.1.2
Step 4 Specify a source interface for sending logs to the log host.
# Assign an IP address to Loopback 0 and specify Loopback 0 as the source interface for sending
logs to a log host.
[~HUAWEI] interface loopback 0
[~HUAWEI-loopback0] ip address 1.1.1.1 255.255.255.255
[~HUAWEI-loopback0] quit
[~HUAWEI] info-center loghost source loopback 0
Step 5 Run the commit command to commit the configuration.

Step 6 Configure the log host.
The log host is a host running the UNIX or LINUX operating system or a log software.
l If the host runs the UNIX or LINUX operating system, enable Syslog in the system to record
and collect log information.
The following part uses a host running the UNIX operating system as an example.
– Create a log file. Run the touch loghost.info command under /var/log to create a file
loghost.info, which is used to store information about the router.
– Edit the configuration file. Enter the information "loghost.info /var/log/router.log" in the
syslog.conf file in the /etc path. The information indicates that the log host is named
loghost, and the log information marked "info" is all recorded to the loghost.log file in
the /var/log path.
– Configure the syslog file in the /etc/sysconfig path. Change syslogd_options="-m o" to
syslogd_option="-1 -m o" to allow the system to record the log information on a remote
device.
– Run the service syslog restart command to enable Syslog.

l If the host runs a third party's log software, the log software can be configured to collect log
information.
For details about log configurations on Huawei iManager U2000, see the iManager U2000
Operation Guide for Common Features.
# View the received logs on the network management system. (The configuration details are not
provided here.)
----End
Configuration Files
#
info-center loghost source Loopback0
#
sysname HUAWEI
#
interface Loopback0
ip address 1.1.1.1 255.255.255.0
#
return
Related Tasks

Configuration Guide - System Management 5 Fault Management
5 Fault Management
About This Chapter
When a fault occurs on a device or network, the device sends relevant information to the fault
management (FM) module. The FM module then determines whether to generate and report
alarms.
5.1 Fault Management Overview

FM is used to enhance the network reliability.
5.2 FM Supported by the NE5000E
FM involves the alarm suppression, alarm filtering, alarm query, alarm clearing, and alarm
simulation functions, which help users rapidly and accurately complete the configuration.
5.3 Configuring FM
Users can configure FM on a device to use the alarm filtering, alarm delivery, and alarm
suppression functions.
5.4 Maintenance
You can use maintenance commands to collect statistics about faults and clear them after further
analysis.
This section provides an example for configuring FM.

5.1 Fault Management Overview

FM is used to enhance the network reliability.
FM monitors and reports the existing and potential faults for users to understand the running
status of the system. The FM functions are as follows:
l FM collects statistics about faults accurately and in real time.
l FM informs users of the faults after further analyzing the collected fault statistics.
l FM improves user experience by filtering out invalid alarms and presenting users with only
the alarms that they are concerned about.
5.2 FM Supported by the NE5000E

FM involves the alarm suppression, alarm filtering, alarm query, alarm clearing, and alarm
simulation functions, which help users rapidly and accurately complete the configuration.
With the network growth, the network becomes increasingly complex, and thus more network
configurations and applications are deployed. When a certain module on a device fails, multiple
alarms may be generated on one or more devices. The devices and NMS hosts, however, are
incapable of processing all alarms, causing alarm lost during the alarm transmission. As a result,
some alarms that users are concerned about cannot be displayed, which hinders network
management. FM is used to dynamically manage and report alarms generated on devices in a
centralized manner.
The NE5000E currently supports the following FM functions:
l Filtering out repeated alarms, service intermittency alarms, and flapping alarms
l Filtering out the alarms that users are not concerned about
l Displaying alarm configurations, active alarms, previously-generated alarms, and statistics
about alarms to present details about the network faults
l Clearing previously-generated alarms to simplify the alarm display
l Simulating and reporting alarms to check whether the terminal and NMS host are correctly
configured and whether the management link is reachable
5.3 Configuring FM
Users can configure FM on a device to use the alarm filtering, alarm delivery, and alarm
suppression functions.
Before configuring FM, complete the following tasks:
l Installing the router and powering it on properly
l Completing the alarm definition on the NE5000E
Choose one or more configuration tasks (excluding "Checking the Configuration") as needed.

Related Tasks
5.5.1 Example for Configuring FM
5.3.1 Setting the Alarm Severity

You can change the default alarm severity.
Procedure
Step 1 Run:
system-view

Step 2 Run:
alarm
The alarm management view is displayed.

Step 3 Run:
alarm name alarm-name severity severity
The alarm severity is set.

If you are concerned about certain types of alarms, you can set the highest severity for these
types of alarms and configure filtering conditions. In this manner, the system reports only these
types of alarms to the NMS.
Step 4 Run:
commit
----End
5.3.2 Configuring a Suppression Period for an Alarm

Users can configure a suppression period for an alarm to prevent the alarm from being reported
frequently.
Procedure
Step 1 Run:
system-view

Step 2 Run:
alarm

Step 3 Run:
suppression name alarm-name { cause-period cause-seconds | clear-period clear-
seconds }
A suppression period is configured for an alarm.

After a suppression period is configured for an alarm, the following operations are implemented:
l During this period, this alarm is not reported to the NMS immediately after it is generated.
If the alarm is generated but its clear alarm is not generated, the system reports this alarm to
the NMS host when the period expires.
l If both the alarm and its clear alarm are generated during this period, they are both deleted
from the alarm queue and will not be reported to the NMS host.
You can use the parameter cause-period cause-seconds to set the period after which a generated
alarm is reported.
You can use the parameter clear-period clear-seconds to set the period after which a generated
clear alarm is reported.
Step 4 Run:
commit
----End
5.3.3 Configuring Alarm Suppression

The system suppresses repeated alarms, persistent alarms, and service intermittency alarms by
default. Users can disable alarm suppression for alarms that they are concerned about, hardware
alarms, and ambient alarms.
Context
The impacts of alarm suppression on the system are as follows:
l When alarm suppression is enabled, alarm suppression takes effect, and you can configure
an alarm suppression period.
l When alarm suppression is disabled, alarm suppression does not take effect in the system.
By default, alarm suppression is enabled.
Procedure
Step 1 Run:
system-view
Step 2 Run:
alarm
Step 3 Run:
suppression enable
Alarm suppression is enabled.
To disable alarm suppression, you can run the undo suppression enable command.

CAUTION
Disable alarm suppression immediately after it is not required. Otherwise, a large number of
redundant alarms will be generated.
Step 4 Run:
commit
----End
5.3.4 Filtering Out All Alarms

Terminal users can filter out all alarms.
Context
Terminal users include command line users and NMS users. If terminal users do not expect any
alarms sent from the device, they can filter out all alarms.
Procedure
l Command line users run the undo terminal alarm command in the user view to filter out
all alarms.
l NMS users on the host named host-name perform the following operations to filter out all
alarms:
1. Run the system-view command to enter the system view.
2. Run the alarm command to enter the alarm management view.
3. Run the undo alarm snmp target-host host-name command to filter out all alarms.
----End
5.3.5 Configuring an Alarm Filtering Table to Filter Out Alarms

This section describes how to edit and apply an alarm filtering table. An alarm filtering table
can be used by different terminal users to filter out the alarms that they are not concern about.
Context
Terminal users include command line users and NMS users. Different users are concerned about
different types of alarms. Terminal users can configure an alarm filtering table to filter out the
unwanted alarms.
Flexible filtering rules can be defined in an alarm filtering table.
l Filtering out alarms with the specific severity, such as alarms with the severity lower than
Major
l Filtering out alarms that are generated for a specific service, such as alarms for the MPLS
service
l Filtering out alarms with specific names, such as an LDP session alarm

Different terminal users can share the same alarm filtering table, but each terminal user can use
only one alarm filtering table.
Procedure
Step 1 Run:
system-view

Step 2 Run:
alarm

Step 3 Run:
mask name mask-name
The alarm filtering table view is displayed.

Step 4 You can choose one or more of the following commands to filtering out specific alarms:
l Run the mask alarm-name alarm-name command to filter out a specific alarm.
To filter out multiple alarms with specific names, you need to run this command multiple
times. Run the undo mask alarm-name alarm-name command to cancel the configuration.
l Run the mask feature-name feature-name command to filter out an alarm for a specific
service.
To filter out multiple alarms for specific services, you need to run this command multiple
times. Run the undo mask feature-name feature-name command to cancel the
configuration.
l Run the mask severity severity command to filter out an alarm with specific severity.
The severity of an alarm can be Critical, Major, Minor, or Warning. To filter out multiple
alarms with specific levels of severity, you need to run this command multiple times. Run
the undo mask severity severity command to cancel the configuration.
Step 5 Run:
quit
Return to the alarm management view.

Step 6 Choose one of the following commands based on the specific terminal user type and function.
l Command line users run the terminal mask name mask-name command to filter out specific
alarms.
l NMS users on the host named host-name run the snmp target-host host-name mask
name mask-name command to filter out specific alarms.
Step 7 Run:
commit
----End
5.3.6 Saving Alarms to a Log File

This section describes how to save alarms to a log file.

The system records fault information to the log buffer in real time. After running the command
to save alarms to a log file, you can query the log file to locate the fault.
Procedure
Step 1 Run:
save logfile
Alarms are saved to a log file.
Alarms are saved to the local log file at a specific interval.
----End

After the configuration is complete, run the display logfile path command to view the contents
of the log file.
<HUAWEI> display logfile 1/17#cfcard:/logfile/alarm_15148817_20100311_0.log
2010-03-11 11:51:52 HUAWEI %%01haf/2/hwMemOverload(t):VR=0-CID=2147614737;Storage
utilization exceeded the prealarm threshold. (ChassisId=0, BoardId=1,
osNodeId=1)
2010-03-11 11:52:08 HUAWEI %%01haf/2/hwCpuOverload(t):VR=0-CID=2147614737;Cpu
utilization exceeded the prealarm threshold. (ChassisId=0, BoardId=1, osNodeId=1)
2010-03-11 11:55:42 HUAWEI %%01haf/5/hwCpuOverload(t):VR=0-CID=2147615743;Cpu
utilization exceeded the prealarm threshold. (ChassisId=0, BoardId=3, osNodeId=3)

After configuring FM, you can view information about the feature for which the alarm is
generated, alarm name, alarm ID, alarm severity, and alarm suppression period.
Prerequisite
The FM configurations are complete.
Procedure
l Run the display alarm information [ name alarm-name ] [ brief ] command to verify the
validity of the alarm suppression parameters.
----End
Example
Display the basic information about an alarm named PmThresholdAlarm.
<HUAWEI> display alarm information name pmthresholdalarm brief
feature : PMSERVER
alarmName : PmThresholdAlarm
alarmId : 177209348
severity : Major
cause suppress time : 1
clear suppress time : 1

5.4 Maintenance
You can use maintenance commands to collect statistics about faults and clear them after further
analysis.
5.4.1 Clearing Alarm Statistics

You can clear alarm statistics during routine maintenance.
Context
In routine maintenance, you can run the following commands in the alarm management view to
clear alarm statistics.
CAUTION
Alarm statistics cannot be restored after you clear them. Therefore, exercise caution when
running this command.
Procedure
Step 1 Run:
system-view

Step 2 Run:
alarm

Step 3 Run:
reset statistics [ name alarm-name ]
Alarm statistics are cleared.

The reset statistics command is used to clear all alarm statistics, and the reset statistics
name alarm-name command is used to clear statistics about specific alarms.
----End
5.4.2 Monitoring the Alarm Status

You can run the following commands in any view to understand the alarm status on the current
device.
Procedure
l Run:
display alarm information [ name alarm-name ] [ brief ]

The alarm configurations are displayed.
The keyword brief is configured in this command to display the basic information about
an alarm, such as the feature for which the alarm is generated, alarm name, alarm ID, alarm
severity, and alarm suppression period.If the keyword brief is not configured in this
command, the reason why this alarm is generated and rectification solution are displayed,
in addition to the basic information.
l Run:
display alarm statistics [ name alarm-name ]
Alarm statistics are displayed.
If an alarm name is specified in this command, only the statistics about the specified alarm
are displayed. If no alarm name is specified in this command, statistics about all alarms are
clarified and displayed.
----End

This section provides an example for configuring FM.
5.5.1 Example for Configuring FM

This section describes how to configure FM.
CAUTION
As shown in Figure 5-1, a user logs in to the Router.
Figure 5-1 Networking diagram for configuring FM

Router User
IP
Network
When a fault occurs on a network, FM can be configured to help users rapidly locate the fault
and rectify the fault.

l Configure a suppression period for an alarm
l Edit and applying an alarm filtering table
Data Preparation
l Alarm name
l Alarm suppression period
l Name of the alarm filtering table
l Alarm severity
l Name of the NMS host
Procedure
Step 1 Enter the alarm management view.
[~HUAWEI] alarm
Step 2 Configure the severity and suppression period of the alarm named hwOpticalInvalid.
# Set the severity of the alarm named hwOpticalInvalid to Critical.
[~HUAWEI-alarm] alarm name hwbfdSessReachLimit severity critical
# Set the generation period to 5s and clearing period to 15s for the alarm named hwOpticalInvalid
in alarm suppression.
[~HUAWEI-alarm] suppression name hwBfdSessReachLimit cause-period 5
[~HUAWEI-alarm] suppression name hwBfdSessReachLimit clear-period 15
[~HUAWEI-alarm] commit
After the configuration is complete, run the display alarm information name
hwBfdSessReachLimit command to verify the configuration.
[~HUAWEI-alarm] display alarm information name hwBfdSessReachLimit
alarmDictionaryQuery
--------------------------------------------------------------------------------
feature : BFD
alarmName : hwBfdSessReachLimit
alarmId : 152043522
severity : Critical
cause suppress time : 5
clear suppress time : 15
--------------------------------------------------------------------------------
Step 3 Edit the alarm filtering table.

# Create an alarm filtering table named mask1 and enter the mask1 view.
[~HUAWEI-alarm] mask name mask1
# Configure filtering rules.

[~HUAWEI-alarm-mask1] mask feature-name PMSERVER
[~HUAWEI-alarm-mask1] mask severity minor
[~HUAWEI-alarm-mask1] mask severity warning

[~HUAWEI-alarm-mask1] commit
# After the configuration is complete, run the display this command in the mask1 view to verify
the configuration.
[~HUAWEI-alarm-mask1] display this
mask alarm-name PmThresholdAlarm
mask severity Minor
mask severity Warning
return
Step 4 Apply the alarm filtering table.

# Configure the NMS host named target-host1 to use the alarm filtering table named mask1.
[~HUAWEI-alarm-mask1] quit
[~HUAWEI-alarm] snmp target-host target-host1 mask name mask1
[~HUAWEI-alarm] commit
# After the configuration is complete, run the display this command in the alarm management
view to verify the configuration.
[~HUAWEI-alarm] display this
snmp target-host target-host1 mask name mask1
----End
Example
#
sysname HUAWEI
#
alarm
suppression name hwBfdSessReachLimit cause-period 5
suppression name hwBfdSessReachLimit clear-period 15
alarm name hwBfdSessReachLimit severity Critical
snmp target-host target-host1 mask name mask1
#
mask name mask1
mask severity Minor
mask severity Warning
mask alarm-name PmThresholdAlarm
#
return
Related Tasks
5.3 Configuring FM

Configuration Guide - System Management 6 NetStream Configuration
6 NetStream Configuration
About This Chapter
NetStream is a technology that samples and releases traffic information on the network. By
collecting traffic statistics based on the traffic volume and resource consumption on the network,
NetStream helps users implement management and accounting on various services.
6.1 NetStream Overview
As the Internet develops rapidly, more bandwidth resources are provided from users and at the
same time a higher requirement for delicate network monitoring and management is raised. A
technology is needed to address such a requirement. NetStream is a technology that provides
highly granular per-flow statistics on network traffic. It classifies statistics about traffic flows
and resource usage on the network. NetStream can also help monitor and manage the network
based on the types of services and resources.
6.2 NetStream Features Supported by the NE5000E
This section describes the usage scenarios of NetStream features supported by the NE5000E and
available NetStream functions.
6.3 Collecting Statistics About IPv4 Original Flows
Before collecting statistics about IPv4 original flows, familiarize yourself with the applicable
environment, complete the pre-configuration tasks, and obtain the data required for the
configuration. This will help you complete the configuration task quickly and accurately.
6.4 Collecting Statistics About IPv4 Aggregated Flows
Before collecting statistics about IPv4 aggregated flows, familiarize yourself with the applicable
6.7 Collecting Statistics About MPLS IPv4 Packets

Collecting packet statistics on MPLS networks helps you to monitor MPLS network conditions.
6.9 Collecting Statistics About BGP/MPLS VPN Flows
Collecting traffic statistics on BGP/MPLS VPN networks helps users to monitor the BGP/MPLS
VPN network condition.
6.10 Maintaining NetStream
This section describes how to maintain NetStream.
This section provides NetStream configuration examples in different scenarios.

6.1 NetStream Overview

As the Internet develops rapidly, more bandwidth resources are provided from users and at the
same time a higher requirement for delicate network monitoring and management is raised. A
technology is needed to address such a requirement. NetStream is a technology that provides
highly granular per-flow statistics on network traffic. It classifies statistics about traffic flows
and resource usage on the network. NetStream can also help monitor and manage the network
based on the types of services and resources.
NetStream provides the following functions:
l Accounting
NetStream provides detailed accounting statistics, including the IP address, number of
packets, number of bytes, time, Type of Service (ToS), and application type. Based on the
collected statistics, the Internet Service Provider (ISP) can charge users flexibly based on
the resource usage (such as time periods, bandwidth, application, or QoS) and enterprises
can count their expenses or assign costs to make effective use of resources.
l Network planning and analysis
NetStream provides key information for advanced network management tools to optimize
the network design and planning. This helps to obtain the best network performance and
reliability with the lowest network operation cost.
l Network monitoring
NetStream provides real-time monitoring of network traffic. It uses the remote monitoring
(RMON), RMON-2, and flow-based analysis technology to visually represent the traffic
mode of a single router and all routers on the network, and provides functions such as
proactive fault detection, effective fault rectification, and rapid problem solution.
l Application monitoring and analysis
NetStream provides detailed network application information. For example, it allows the
network administrator to view the proportion of each application, such as Web, the File
Transfer Protocol (FTP), Telnet, and other TCP/IP applications, to communication traffic.
Based on the information, the Internet Content Provider (ICP) and ISP can properly plan
and allocate network application resources to meet users' requirements.
l Abnormal traffic detection
By analyzing NetStream flows, the NMS can detect abnormal traffic (such as different
types of attacks) on the network in real time. Based on alarm information on the NMS and
the association between the NMS and devices, network security can be guaranteed.
The implementation of NetStream requires three devices:

l NetStream Data Exporter (NDE): samples and outputs traffic statistics.
l NetStream Collector (NSC): collects and stores traffic statistics sent from the NDE.
l NetStream Data Analyzer (NDA): analyzes traffic statistics. The analysis result is used as
the reference for various functions, such as network accounting, network planning, network
monitoring, application monitoring, and analysis.
The NE5000E is used as an NDE to sample packets, aggregate flows, and output flows.
The following figure shows the relationship among the NDE, NSC, and NDA.

Figure 6-1 Role of each device in NetStream
RouterA NSC
NDA
RouterB NSC
6.2 NetStream Features Supported by the NE5000E

This section describes the usage scenarios of NetStream features supported by the NE5000E and
available NetStream functions.
Sampling and Statistics Collection of IPv4 Flows

The NE5000E supports the sampling and statistics collection of original IPv4 flows, including
unicast and multicast packets, packets discarded by the uRPF/RPF check, and fragmented
packets. Statistics about original IPv4 flows include the 7-tuple information, source AS number,
destination AS number, VPN ID, TCP flag, and BGP next hop.
Sampling and Statistics Collection of IPv6 Flows

The NE5000E supports the sampling and statistics collection of original IPv6 flows, including
unicast and multicast packets, packets discarded by the uRPF/RPF check, and fragmented
packets. Statistics about original IPv6 flows include the 7-tuple information, source AS number,
destination AS number, VPN ID, TCP flag, and BGP next hop.
Sampling and Statistics Collection of MPLS Flows

The NE5000E supports the sampling and statistics collection of MPLS (Multi-Protocol Label
Switching) flows, including the third-layer label and IP header of MPLS packets.
Sampling Modes
The NE5000E supports the fixed packet sampling. The sampling mode and sampling ratio can
be configured in the system view, interface view, or ACL view.
l Fixed packet sampling

In this mode, one packet is sampled every fix-packets-number packets. For example, if the
value specified by fix-packets-number is N, every Nth packet that passes through the
NetStream-enabled interface will be sampled.

Versions of Original and Aggregated Flows

The NE5000E allows flow statistics to be output in the form of original flows or aggregated
flows. The NE5000E supports three flow output formats: V5, V8, and V9. Original flows can
be output in V5 or V9 format and aggregated flows can be output in V8 or V9 format.
Aggregation of Original Flows

The NE5000E supports 12 IPv4 aggregation modes, 12 IPv6 aggregation modes, and one MPLS
aggregation mode.
NetStream Service Processing Modes

The NE5000E supports two NetStream service processing modes: distributed mode and
integrated mode.
l Distributed mode
In this mode, an LPU can sample packets, aggregate flows, and output flows independently.
l Integrated mode
In this mode, an LPU samples packets but takes no actions to NetStream flows. Instead, it
sends the NetStream flows to the NetStream processing board for aggregation and output.
Aging Modes
A NetStream flow can be aged in one of the following modes:
l Inactive time-based aging
The inactive time refers to the time period from when the last packet is cached on the LPU
to the current time. The inactive time can be set, and if the set value is exceeded, the system
ages flows in the buffer.
l Active time-based aging
The active time refers to the time period from when the first packet is cached on the LPU
to the current time. If the duration of flows in the buffer is longer than the active time, these
flows will be aged when new flows need to be cached.
l TCP disconnection-based aging
After a packet carrying the FIN or RST flag is transmitted over a TCP connection, the TCP
connection is torn down. When a packet carrying the FIN or RST flag is sampled and added
to an existing TCP flow, the system ages the TCP flow.
l Byte counts-based aging
Bytes of flows cached in the buffer are counted. If the flow bytes in a buffer exceed the
upper threshold, the buffer overflows. If the flow bytes cached in the buffer on the router
exceed the threshold, the system ages flows in the buffer.
l Forcible aging
Original flows cached in the buffer can be forcibly aged by using command lines.


As shown in Figure 6-2, carriers can enable NetStream on the router to obtain detailed network
application information. Such information can guide carriers in monitoring abnormal network
traffic, analyzing users' operation mode, and planning the network between ASs.
Statistics about original flows are collected based on the 7-tuple information of packets. The
NDE samples IPv4 flows passing through it, collects statistics about sampled flows, and
encapsulates the aged NetStream original flows into UDP packets and sends the packets to the
NSC for subsequent processing. Unlike collecting the statistics about aggregated flows,
collecting the statistics about original flows has less impact on the NDE performance. Original
flows consume more storage space and network bandwidth resources because the data volume
of original flows is far greater than that of aggregated flows.
Figure 6-2 Networking diagram of IPv4 flow statistics collection

NDA
NSC
NDA
NSC
Traffic
NDE NDE
Before collecting the statistics about IPv4 original flows, complete the following task:
l Configuring the static route or enabling an IGP to ensure that IP routes between nodes are
reachable
To collect the statistics about IPv4 original flows, perform the procedures as shown in the
following flowchart.

Figure 6-3 Flowchart of collecting the statistics about IPv4 original flows
Configure the netstream service
processing mode
Configure the export of original

streams
Adjust the AS field mode and

interface index type
Enable the statistics of TCP flags in

the original stream
Configure the sampling mode and

sampling ratio for IPv4 traffic
Mandatory procedure
Optional procedure
6.3.1 Specifying a NetStream Service Processing Mode

After performing packet sampling, each NetStream-enabled LPU sends sampled packets to the
NetStream service processing board for aggregation and output. If the NE5000E has more than
one NetStream service processing board, these NetStream services boards work in redundancy
mode for service backup and load balancing, which improves system reliability.
Context
NetStream services can be processed in either of the following modes:
l Distributed mode
In this mode, a single LPU can perform NetStream functions independently, including
packet sampling, flow aggregation, and flow output.
l Integrated mode
In this mode, the LPU only samples packets and sends sampled packets to the NetStream
service processing board. Flow aggregation and flow output are performed on the
NetStream service processing board. If the data volume collected by the router is beyond
the processing capability of a single NetStream service processing board, additional
NetStream service processing boards for load balancing can be installed.
The ip netstream sampler command has the same function as the ipv6 netstream sampler
command.
l The execution of either command takes effect on all packets and there is no need to
configure both of them. If it is required to configure both of them, ensure that sampling
modes and sampling ratios configured by the ip netstream sampler and ipv6 netstream
sampler commands are identical.

l Packets are sampled at the set sampling ratio, regardless of packet types. For example, if
the sampling ratio in fixed packet sampling mode is set to 1000:1, one packet will be
sampled every 1000 packets, regardless of these packets are IPv4 or IPv6 packets.
Procedure
l Configure the distributed NetStream service processing mode.
1. Run:
system-view

2. Run:
slot slot-id
The view of the slot where the LPU for NetStream sampling resides is displayed.
3. Run:
ip netstream sampler to slot self
The distributed NetStream service processing mode is configured.
4. Run:
commit

l Configure the integrated NetStream service processing mode.
1. Run:
system-view

2. Run:
slot slot-id
3. Run:
ip netstream sampler to slot slot-id1
The integrated NetStream service processing mode is configured and the NetStream
service processing board is specified.
4. (Optional) Run:
ip netstream sampler to slot slot-id2 backup
The integrated NetStream service processing mode is configured and the backup
NetStream service processing board is specified.
If there are several NetStream service processing boards, you can specify a master
service processing board and a backup service processing board as needed. For the
purpose of load balancing, LPUs that are dual homed to different NetStream service
processing boards can back up each other.
5. Run:
commit
----End

6.3.2 Outputting Original Flows

To ensure that original flows can be correctly output to the NMS, you need to configure the
aging time, output format, and source and destination addresses for original flows.
Procedure
Step 1 Run:
system-view

ip netstream export version { 5 | 9 } [ origin-as | peer-as ] [ bgp-nexthop ]
The output format of original flows is configured.
NetStream original flows can be output in either V5 or V9 format. V9 is not compatible with
V5.
The V9 format allows the output original flows to carry more variable statistics, expand newly-
defined flow elements more flexibly, and generate new records more easily.
The V5 format is fixed, and thus the system cost is low. In most cases, NetStream original flows
are output in V5 format. In any of the following situations, however, NetStream original flows
must be output in V9 format:
l NetStream original flows need to carry BGP next-hop information.
l Interface indexes carried in the output NetStream original flows need to be extended from
16 bits to 32 bits.
By default, NetStream original flows are output in V5 format.

ip netstream export template timeout-rate timeout-interval
The interval at which the template for outputting original flows in V9 format is refreshed.
By default, the output template of original flows is refreshed every 30 minutes.
Step 4 Run:
ip netstream export source ip-address
The source IP address is configured for original flows.
Step 5 Configure the destination IP address and UDP port number of the peer NSC for NetStream
original flows in the system or slot view.
l In the system view:
Run:
ip netstream export host ip-address port
The destination IP address and UDP port number of the peer NSC are configured for
NetStream original flows to be output.
l In the slot view:
1. Run:
slot slot-id

2. Run:
3. Run:
quit
A maximum of two destination IP addresses can be configured for NSC backup. If the router
already has two destination IP addresses, delete one of the existing destination IP addresses
before changing the destination IP address of the output NetStream original flows.
NOTE
If both the system view and slot view are configured with destination IP addresses, the destination IP address
on the slot view is preferred.
Step 6 (Optional) Configure parameters for aging original flows as needed.

l Run:
ip netstream timeout active active-interval
The active aging time is configured for NetStream original flows.

The default active aging time of NetStream original flows is 30 minutes.
l Run:
ip netstream timeout inactive inactive-interval
The inactive aging time is configured for NetStream original flows.

The default inactive aging time of NetStream original flows is 30 seconds.
Step 7 Run:
commit
----End
6.3.3 (Optional) Adjusting the AS Field Mode and Interface Index

Type
To enable the NSC to normally receive and parse NetStream packets output from the NDE,
ensure that the AS field modes and interface index types on the NDE are the same as that on the
NSC.
Context
ensure that the AS field modes and interface index types on the NDE and NSC are the same.
l AS field mode: As defined in the pertaining protocol, the length of the AS field in IP packets
is 16 bits. On networks in some areas, however, the length of the AS field in IP packets is
32 bits. If different AS field modes exist on a network, you need to convert the AS field
mode when configuring NetStream. Otherwise, NetStream cannot sample inter-AS traffic.

CAUTION
On a network where the 32-bit AS field mode is used, the NMS needs to identify the 32-
bit AS field. Otherwise, the NMS will fail to identify inter-AS traffic sent from devices.
l Interface index: The NMS uses the interface index carried in the NetStream packet output
from the NDE to query information about the interface from which the packet is output.
The interface index can be of 16 bits or 32 bits, which is determined by NMS devices of
different vendors. Therefore, the NDE needs to use a proper interface index type according
to the index parsing capability of the NMS. For example, if the NMS can parse a 32-bit
interface index, the interface index carried in the NetStream packet must be a 32-bit value.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip netstream as-mode { 16 | 32 }
The AS field mode is configured on the router.
By default, the AS field mode on the router is 16 bits.
Step 3 Run:
ip netstream export index-switch { 16 | 32 }
The type of the interface index carried in the NetStream packet output from the router is
configured.
By default, the interface index carried in the NetStream packet output from the router is of 16
bits. Before converting an interface index from 16 bits to 32 bits, ensure that the following
conditions are met:
l Original flows are output in V9 format.
l The NetStream packet format for all aggregated flows is V9.
----End
6.3.4 (Optional) Enabling Statistics Collection of TCP Flags

There are six flag bits (URG, ACK, PSH, RST, SYN, and FIN) in a TCP packet header. The
flag bits, together with the destination IP address, source IP address, destination port number,
and source port number of a TCP packet, identify the function and status of the TCP packet on
a TCP connection. By enabling statistics collection of TCP flags, you can extract the TCP-flag
information from network packets and send it to the NMS. The NMS checks the traffic volume
of each flag and determines whether the network is attacked by TCP packets.
Procedure
Step 1 Run:
system-view


Step 2 Run:
ip netstream tcp-flag enable
Statistics collection of TCP flags is enabled.

An original flow is created for each flag value. If statistics collection of TCP flags is enabled,
the number of original flows in the system will greatly increase. By default, statistics collection
of TCP flags is disabled.
Step 3 Run:
commit
----End
6.3.5 Sampling IPv4 Flows

You can enable NetStream to sample and analyze the incoming or outgoing flows on an interface
as needed.
Context
By default, NetStream enabled on an interface can sample and collect the statistics about the
following packets:
l Unicast packets
l Multicast packets
l Packets discarded by the uRPF/RPF check
l Fragmented packets (only the first fragment of each packet will be sampled)
NOTE
If a NetStream-enabled interface is bound to a VPN instance, all packets in the VPN instance will be
sampled.
Procedure
Step 1 Run:
system-view

ip netstream sampler fix-packets fix-packets-number { inbound | outbound }
The sampling mode and sampling ratio are configured globally.

By default, NetStream is disabled from packet sampling.
Step 3 Run:


The sampling mode and sampling ratio are configured for the interface.
NOTE
The sampling mode and sampling ratio configured in the system view are applicable to all interfaces on
the device. The sampling mode and sampling ratio configured in the interface view takes precedence over
those configured in the system view.
Step 5 Run:
ip netstream { inbound | outbound }
NetStream is enabled on the interface. Statistics about packets' BGP next-hop information can
also be collected. Original flows output in V5 format.
By default, NetStream is disabled from collecting the statistics about incoming and outgoing
unicast flows.
Step 6 Run:
commit
----End

In routine maintenance or after NetStream configurations are complete, you can run the
following commands in any view to view the running status of NetStream functions.
Procedure
l Run the display ip netstream cache origin slot slot-id command to check information
about the NetStream buffer.
l Run the display ip netstream statistics slot slot-id command to view statistics about
NetStream flows.
l Run the display netstream { all | global | interface interface-type interface-number }
command to check NetStream configurations in different views.
----End
Example
Run the display ip netstream cache origin slot 3 command. If NetStream is successfully
configured, you can view various statistics about IP packets cached in the NetStream buffer on
the router.
<HUAWEI> display ip netstream cache origin slot 3
Show information of IP and MPLS cache of slot 3 is starting.
get show cache user data success.
DstIf DstP Msk Pro Tos Flags Packets

SrcIf SrcP Msk
NextHop Direction
DstIP DstAs
SrcIP SrcAs
BGP: BGP NextHop TopLabelType
Label1 Exp1 Bottom1
Label2 Exp2 Bottom2

Label3 Exp3 Bottom3

TopLabelIpAddress VlanId
--------------------------------------------------------------------------
Unknown 20 0 6 0 0 1
Unknown 10 0
0.0.0.0 in
58.1.1.2 0
55.67.121.72 0
0.0.0.0 0
0 0 0
0 0 0
0 0 0
0.0.0.0 0
Run the display ip netstream statistics slot slot-id command, and you can view statistics about
NetStream flows.
[~HUAWEI] display ip netstream statistics slot 1
Netstream statistic information on slot 1:
--------------------------------------------------------------------------------
length of packets Number Protocol Number
--------------------------------------------------------------------------------
1 ~ 64 : 0 IPV4 : 97796860
65 ~ 128 : 32001407 IPV6 : 31457284
129 ~ 256 : 0 MPLS : 0
257 ~ 512 : 97252737 L2 : 0
513 ~ 1024 : 0 Total : 129254144
1025 ~ 1500 : 0
longer than 1500 : 0
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Aggregation Current Streams Aged Streams
Created Streams Exported Packets Exported Streams
--------------------------------------------------------------------------------
origin 510246 97773954
98284200 3986446 67875459
as 2 34
36 25 27
as-tos 2 34
36 25 27
protport 2 34
36 23 26
protporttos 2 34
36 26 29
srcprefix 60772 840324
901096 19736 787346
srcpretos 60786 825402
886188 19461 776353
dstprefix 2 33
35 24 26
dstpretos 2 32
34 24 26
prefix 60602 818776
879378 25830 773607
prefix-tos 60536 812587
873123 25589 766331
mpls-label 0 0
0 0 0
bgp-nhp-tos 2 31
33 23 25
index-tos 2 31
33 24 26
--------------------------------------------------------------------------------
srcprefix = source-prefix, srcpretos = source-prefix-tos,
dstprefix = destination-prefix, dstpretos = destination-prefix-tos,

protport = protocol-port, protporttos = protocol-port-tos,

all-aggre = all aggregation streams,
"---" means that the current board is not supported.
Run the display netstream { all | global | interface interface-type interface-number } command,
and you can check NetStream configurations in different views.
<HUAWEI> display netstream all
system
ip netstream timeout active 50
ip netstream timeout inactive 10
ip netstream export version 9 origin-as
ip netstream export source 10.1.1.1
ip netstream export host 100.1.1.3 10000
ip netstream aggregation as
export version 9
enable
slot 8
GigabitEthernet8/0/3
ip netstream sampler fix-packets 1000 inbound
Slot
Slot 8:ip netstream sampler to slot 1

Statistics collection of NetStream aggregated flows collects statistics about original flows with
the same attributes, whereas statistics collection of NetStream original flows collects statistics
about sampled packets. The data volume generated by aggregated flow statistics collection is
therefore greater than that generated by original flow statistics collection.


NDA
NSC
NDA
NSC
Traffic
NDE NDE
Before collecting statistics about IPv4 aggregated flows, complete the following tasks:
reachable
l Enabling statistics collection of NetStream original flows
To collect statistics about IPv4 aggregated flows, perform the procedures as described in the

Figure 6-5 Flowchart of collecting statistics about IPv4 aggregated flows

processing mode
Configure the aggregation modes

for original IPv4 streams
Configure the export of aggregated

streams


Mandatory procedure
Optional procedure

Context
l Distributed mode
l Integrated mode
command.

Procedure
1. Run:
system-view

2. Run:
slot slot-id
3. Run:
ip netstream sampler to slot self
4. Run:
commit

1. Run:
system-view

2. Run:
slot slot-id
3. Run:
ip netstream sampler to slot slot-id1
4. (Optional) Run:
ip netstream sampler to slot slot-id2 backup
5. Run:
commit
----End

6.4.2 Configuring an Aggregation Mode for IPv4 Flows

After an aggregation mode is configured, original flows with the same characteristics are
aggregated as one flow and output to the NSC to meet users' requirements.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip netstream aggregation { as | as-tos | bgp-nexthop-tos | destination-prefix |
destination-prefix-tos | index-tos | prefix | prefix-tos | protocol-port | protocol-
port-tos | source-prefix | source-prefix-tos }
The NetStream aggregation view is created.
NOTE
If the NetStream flow aggregation function is enabled on a device, the device classifies and aggregates
original flows based on certain rules and sends the aggregated flows to the NDA for analysis. Aggregating
original flows can reduce the consumption of network bandwidths, CPU resources, and storage space. Flow
characteristics based on which flows are aggregated vary according to flow aggregation modes. For
mapping relationships between aggregation modes and flow characteristics, see the following table.
Table 6-1 Mapping relationship between aggregation modes and characteristics
Aggregation mode Description
as NetStream flows with the same source AS number, destination

AS number, inbound interface index, and outbound interface
index are aggregated as one flow, and one aggregation record
is generated.
as-tos NetStream flows with the same source AS number, destination

AS number, inbound interface index, outbound interface
index, and ToS are aggregated as one flow and one aggregation
record is generated.
bgp-nexthop-tos NetStream flows with the same destination AS number, source

AS number, BGP next hop, inbound interface index, and
outbound interface index are aggregated as one flow and one
aggregation record is generated.
destination-prefix NetStream flows with the same destination AS number,

destination mask length, destination prefix, and outbound
interface index are aggregated as one flow and one aggregation
destination-prefix-tos NetStream flows with the same destination AS number,

destination mask length, destination prefix, ToS, and outbound

index-tos NetStream flows with the same inbound interface index,

outbound interface index, and ToS are aggregated as one flow
and one aggregation record is generated.
prefix NetStream flows with the same source AS number, destination

AS number, source mask length, destination mask length,
source prefix, destination prefix, inbound interface index, and
prefix-tos NetStream flows with the same source AS number, destination

source prefix, destination prefix, ToS, inbound interface index,
and outbound interface index are aggregated as one flow and
one aggregation record is generated.
protocol-port NetStream flows with the same protocol number, source port,
and destination port are aggregated as one flow and one
protocol-port-tos NetStream flows with the same protocol number, source port,
destination port, ToS, inbound interface index, and outbound
source-prefix NetStream flows with the same source AS number, source

mask length, source prefix, and inbound interface index are
aggregated as one flow and one aggregation record is
generated.
source-prefix-tos NetStream flows with the same source AS number, source

mask length, source prefix, ToS, and inbound interface index
are aggregated as one flow and one aggregation record is
generated.
Step 3 Run:
enable
Statistics collection of flows aggregated in a specified aggregation mode is enabled.

mask { source | destination } minimum mask-length
The length of the aggregate mask is set. The mask used by the system is the higher mask between
the mask in the FIB table and the set mask. If no aggregate mask is set, the system uses the mask
in the FIB table for flow aggregation.
NOTE
The aggregate mask takes effect only for aggregation modes of destination-prefix, destination-prefix-tos,
prefix, prefix-tos, source-prefix, and source-prefix-tos.
Step 5 Run:
commit

----End
6.4.3 Outputting Aggregated Flows

To ensure that aggregated flows are correctly output to the NMS, you need to configure the aging
time, output format, and source and destination addresses for aggregated flows.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The destination IP address is configured for aggregated flows.
If the destination IP address is configured in both the system view and the aggregation view, the
configuration in the aggregation view takes effect.
Step 3 Run:
ip netstream aggregation { as | as-tos | bgp-nexthop-tos | destination-prefix |
destination-prefix-tos | index-tos | mpls-label | prefix | prefix-tos | protocol-
port | protocol-port-tos | source-prefix | source-prefix-tos }
The IPv4 NetStream aggregation view is displayed.

export version { 8 | 9 }
The output format is configured for the aggregated flows.
Flows aggregated in as, as-tos, destination-prefix, destination-prefix-tos, prefix, prefix-tos,

protocol-port, protocol-port-tos, source-prefix, or source-prefix-tos mode are output in V8
format by default. You can specify the output format for aggregated flows as needed.
NOTE
The export version command does not make sense for flows aggregated in bgp-nhp-tos, or index-tos
mode. The default output format for these aggregated flows is V9.

template timeout-rate timeout-interval
The interval at which the template for outputting aggregated flows in V9 format is refreshed is
set.
By default, the output template of aggregated flows is refreshed every 30 minutes.
Step 6 Run:
ip netstream export source ip-address
The source IP address is configured for aggregated flows.

The source IP address configured in the aggregation view takes precedence over that configured
in the system view. If no source IP address is configured in the aggregation view, the source IP
address configured in the system view takes effect.
Step 7 Run:
NOTE
l You can configure two destination IP addresses in the system view and the IPv4 NetStream aggregation
view.
l The destination IP address configured in the system view takes precedence over that configured in the
NetStream aggregation view.
Step 8 (Optional) Configure parameters for aging aggregated flows as needed.

l Run:
ip netstream aggregation timeout active active-interval
The active aging time is configured for NetStream aggregated flows.

The default active aging time of NetStream aggregated flows is 5 minutes.
l Run:
ip netstream aggregation timeout inactive inactive-interval
The inactive aging time is configured for NetStream aggregated flows.

The default inactive aging time of NetStream aggregated flows is 300 seconds.
Step 9 Run:
commit
----End

Type
NSC.
Context

CAUTION
Procedure
Step 1 Run:
system-view
Step 2 Run:
ip netstream as-mode { 16 | 32 }
Step 3 Run:
ip netstream export index-switch { 16 | 32 }
configured.
conditions are met:
l The NetStream packet format for all aggregated flows is V9.
----End

as needed.
Context
following packets:
l Unicast packets
l Multicast packets

l Fragmented packets (only the first fragment of each packet will be sampled)
NOTE
sampled.
Procedure
Step 1 Run:
system-view

Step 3 Run:

NOTE
Step 5 Run:
ip netstream { inbound | outbound }
NetStream is enabled on the interface. Statistics about packets' BGP next-hop information can
also be collected. Original flows output in V5 format.
unicast flows.
Step 6 Run:
commit
----End

In routine maintenance or after pertaining configurations of NetStream are complete, you can
run the following commands in any view to check whether NetStream is enabled on the device.

Procedure
l Run the display ip netstream cache { as | as-tos | bgp-nexthop-tos | destination-prefix
| destination-prefix-tos | index-tos | mpls-label | prefix | prefix-tos | protocol-port |
protocol-port-tos | source-prefix | source-prefix-tos } slot slot-id command to view flows
aggregated in different modes in the buffer.
NetStream flows.
----End
Example
Run the display ip netstream cache destination-prefix slot 3 command. If the destination IP
address and prefix-aggregation mode are configured, you can view statistics about destination
addresses, AS numbers, masks, and prefixes of IP or MPLS packets in the NetStream flow buffer.
<HUAWEI> display ip netstream cache destination-prefix slot 3
DstIf DstAs Streams Packets Direction

SrcIf SrcAs
--------------------------------------------------------------------------------
PO4/2/0 0 1 5462 in
GI3/0/9 0
Run the display ip netstream statistics slot slot-id command, and you can view statistics about
NetStream flows.
[~HUAWEI] display ip netstream statistics slot 1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 ~ 64 : 0 IPV4 : 97796860
65 ~ 128 : 32001407 IPV6 : 31457284
129 ~ 256 : 0 MPLS : 0
257 ~ 512 : 97252737 L2 : 0
513 ~ 1024 : 0 Total : 129254144
1025 ~ 1500 : 0
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
origin 510246 97773954
98284200 3986446 67875459
as 2 34
36 25 27
as-tos 2 34
36 25 27
protport 2 34
36 23 26
protporttos 2 34
36 26 29
srcprefix 60772 840324
901096 19736 787346

srcpretos 60786 825402

886188 19461 776353
dstprefix 2 33
35 24 26
dstpretos 2 32
34 24 26
prefix 60602 818776
879378 25830 773607
prefix-tos 60536 812587
873123 25589 766331
mpls-label 0 0
0 0 0
bgp-nhp-tos 2 31
33 23 25
index-tos 2 31
33 24 26
--------------------------------------------------------------------------------
Run the display netstream { all | global | interface interface-type interface-number } command,
and you can check NetStream configurations in different views.
system
export version 9
enable
slot 8
Slot

Statistics about original flows are collected based on the 7-tuple information of packets. The
NDE samples IPv6 flows passing through it, collects statistics about sampled flows, and
encapsulates the aged NetStream original flows into UDP packets and sends the packets to the
NSC for subsequent processing. Unlike collecting the statistics about aggregated flows,
collecting the statistics about original flows has less impact on the NDE performance. Original

flows consume more storage space and network bandwidth resources because the data volume
of original flows is far greater than that of aggregated flows.

NDA
NSC
NDA
NSC
Traffic
NDE NDE
Before collecting the statistics about IPv6 original flows, complete the following task:
l Configuring parameters of the link layer protocol and IP addresses for interfaces to ensure
that the link layer protocol on the interfaces is Up
reachable
To collect the statistics about IPv6 original flows, perform the procedures as shown in the

Figure 6-7 Flowchart of collecting the statistics about IPv6 original flows

processing mode
Configure the export of original

streams

Enable the statistics of TCP flags in

the original stream

Mandatory procedure
Optional procedure

Context
l Distributed mode
l Integrated mode
command.

Procedure
1. Run:
system-view

2. Run:
slot slot-id
3. Run:
ipv6 netstream sampler to slot self
4. Run:
commit

1. Run:
system-view

2. Run:
slot slot-id
3. Run:
ipv6 netstream sampler to slot slot-id1
4. (Optional) Run:
ipv6 netstream sampler to slot slot-id2 backup
5. Run:
commit
----End

6.5.2 Outputting Original Flows

To ensure that original flows can be correctly output to the NMS, you need to configure the
aging time, output format, and source and destination addresses for original flows.
Context
IPv6 original flows can be output only in V9 format.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 netstream export version 9 [ origin-as | peer-as ] [ bgp-nexthop ]
The output format of original flows is configured.

ipv6 netstream export template timeout-rate timeout-interval
The interval at which the template for outputting original flows in V9 format is refreshed.
By default, the output template of original flows is refreshed every 30 minutes.
Step 4 Run:
ipv6 netstream export source ip-address
Step 5 Configure the destination IP address and UDP port number of the peer NSC for NetStream
original flows in the system or slot view.
l In the system view:
Run:
ipv6 netstream export host ip-address port
l In the slot view:
1. Run:
slot slot-id
2. Run:
3. Run:
quit

A maximum of two destination IP addresses can be configured for NSC backup. If the router
already has two destination IP addresses, delete one of the existing destination IP addresses
before changing the destination IP address of the output NetStream original flows.
Step 6 (Optional) Configure parameters for aging original flows as needed.

l Run:
ipv6 netstream timeout active active-interval
The active aging time is configured for NetStream original flows.

l Run:
ipv6 netstream timeout inactive inactive-interval
The inactive aging time is configured for NetStream original flows.

The default active aging time of NetStream original flows is 30 minutes and the default
inactive aging time is 30 seconds.
Step 7 Run:
commit
----End

Type
NSC.
Context
CAUTION

Procedure
Step 1 Run:
system-view

Step 2 Run:
ipv6 netstream as-mode { 16 | 32 }

Step 3 Run:
ipv6 netstream export index-switch { 16 | 32 }
configured.
conditions are met:
l Aggregated flows are output in V9 format.
----End
6.5.4 (Optional) Enabling Statistics Collection of TCP Flags in

Original Flows
There are six flag bits (URG, ACK, PSH, RST, SYN, and FIN) in a TCP packet header. The
flag bits, together with the destination IP address, source IP address, destination port number,
and source port number of a TCP packet, identifies the function and status of the TCP packet
on a TCP connection. By enabling statistics collection of TCP flags, you can extract the TCP-
flag information from network packets and send it to the NMS. The NMS checks the traffic
volume of each flag and determines whether the network is attacked by TCP packets.
Context
Do as follows on the router where TCP flag statistics are to be collected.
By enabling statistics collection of TCP flags, you can extract the TCP-flag information from
network packets and send it to the NMS. The NMS can thus determine whether there are flood
attacks on the network.
Procedure
Step 1 Run:
system-view

Step 2 Run:
ipv6 netstream tcp-flag enable
Statistics collection of TCP flags in original flows is enabled.

By default, statistics collection of TCP flags in original flows is disabled.
Step 3 Run:
commit
----End

as needed.
Context
following packets:
l Unicast packets
l Multicast packets
l Fragmented packets
NOTE
sampled.
Procedure
Step 1 Run:
system-view

ipv6 netstream sampler fix-packets fix-packets-number { inbound | outbound }
By default, NetStream is disabled from packet sampling. Instead, it collects the statistics about
each packet.
Step 3 Run:

each packet.

NOTE
command.
l The execution of either command takes effect on all packets and there is no need to configure
both of them. If it is required to configure both of them, ensure that sampling modes and
sampling ratios configured by the ip netstream sampler and ipv6 netstream sampler
commands are identical.
l Packets are sampled at the set sampling ratio, regardless of packet types. For example, if the
sampling ratio in fixed packet sampling mode is set to 1000:1, one packet will be sampled
every 1000 packets, regardless of these packets are IPv4 or IPv6 packets.
Step 5 Run:
ipv6 netstream { inbound | outbound }
NetStream is enabled on the interface.

Statistics about packets' BGP next-hop information can also be collected. Original flows output
in V5 format, however, cannot carry the BGP next-hop information.
unicast flows.
Step 6 Run:
commit
----End

following commands in any view to check whether NetStream is enabled on the device.
Prerequisite
NetStream configurations are complete.
Procedure
l Run the display ipv6 netstream cache origin slot slot-id command to view information
about the NetStream buffer.
l Run the display ipv6 netstream statistics slot slot-id command to view statistics about
NetStream flows.
----End
Example
Run the display ipv6 netstream cache origin slot 3 command. If NetStream is successfully
configured, you can view various statistics about IP packets cached in the NetStream buffer on
the router.

<HUAWEI> display ipv6 netstream cache origin slot 3

DstIf DstIP SrcIP Pro Tos Flags Packets
SrcIf DstP Msk AS SrcP Msk AS NextHop
BGP: BGP NextHop TopLabelType Direction
Label1 Exp1 Bottom1
Label2 Exp2 Bottom2
Label3 Exp3 Bottom3
TopLabelIpAddress
--------------------------------------------------------------------------
Null 10.10.1.1 10.10.1.2 1 1 0 2746
GI3/0/9 0 32 0 0 24 0 127.0.0.1
0.0.0.0 0 in
0 0 0
0 0 0
0 0 0
0.0.0.0
Run the display ipv6 netstream statistics slot slot-id command, and you can view statistics
about NetStream flows.
[~HUAWEI] display ipv6 netstream statistics slot 1
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 ~ 64 : 0 IPV4 : 11214946
65 ~ 128 : 544123 IPV6 : 0
129 ~ 256 : 0 MPLS : 0
257 ~ 512 : 10670823 L2 : 0
513 ~ 1024 : 0 Total : 11214946
1025 ~ 1500 : 0
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
origin 0 0
0 0 0
as 0 0
0 0 0
as-tos 0 0
0 0 0
protport 0 0
0 0 0
protporttos 0 0
0 0 0
srcprefix 0 0
0 0 0
srcpretos 0 0
0 0 0
dstprefix 0 0
0 0 0
dstpretos 0 0
0 0 0
prefix 0 0
0 0 0
prefix-tos 0 0
0 0 0
mpls-label 0 0
0 0 0
bgp-nhp-tos 0 0
0 0 0
index-tos 0 0

0 0 0
--------------------------------------------------------------------------------

Statistics collection of NetStream aggregated flows collects statistics about original flows with
the same attributes, whereas statistics collection of NetStream original flows collects statistics
about sampled packets. The data volume generated by aggregated flow statistics collection is
therefore greater than that generated by original flow statistics collection.

NDA
NSC
NDA
NSC
Traffic
NDE NDE
Before collecting statistics about IPv6 aggregated flows, complete the following tasks:
l Configuring parameters of the link layer protocol and IP addresses for interfaces to ensure
that the link layer protocol on the interfaces is Up

reachable
l Enabling statistics collection of NetStream original flows
To collect statistics about IPv6 aggregated flows, perform the procedures as described in the
Figure 6-9 Flowchart of collecting statistics about IPv6 aggregated flows

processing mode
Configure the aggregation modes

for original IPv6 streams
Configure the export of aggregated

streams


Mandatory procedure
Optional procedure

Context
l Distributed mode
l Integrated mode


command.
Procedure
1. Run:
system-view

2. Run:
slot slot-id
3. Run:
ipv6 netstream sampler to slot self
4. Run:
commit

1. Run:
system-view

2. Run:
slot slot-id
3. Run:
ipv6 netstream sampler to slot slot-id1
4. (Optional) Run:
ipv6 netstream sampler to slot slot-id2 backup

5. Run:
commit
----End
6.6.2 Configuring an Aggregation Mode for IPv6 Flows

After an aggregation mode is configured, original flows with the same characteristics are
aggregated as one flow and output to the NSC to meet users' requirements.
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 netstream aggregation { as | as-tos | bgp-nexthop-tos | destination-prefix |
destination-prefix-tos | index-tos | prefix | prefix-tos | protocol-port | protocol-
port-tos | source-prefix | source-prefix-tos }
The NetStream aggregation view is created.
NOTE
After collecting statistics about NetStream original flows, the system aggregates original flows into
aggregated flows based on certain rules, encapsulates aggregated flows into UDP packets, and sends UDP
packets after the aging timer expires. Aggregating original flows can reduce the consumption of network
bandwidths, CPU resources, and storage space. Characteristics based on which flows are aggregated vary
according to aggregation modes. The mapping relationship between characteristics and aggregation modes
is described in the following table.
Table 6-2 Mapping relationship between aggregation modes and characteristics
as NetStream flows with the same source AS number, destination

AS number, inbound interface index, and outbound interface
index are aggregated as one flow, and one aggregation record
is generated.
as-tos NetStream flows with the same source AS number, destination

AS number, inbound interface index, outbound interface
index, and ToS are aggregated as one flow and one aggregation
bgp-nexthop-tos NetStream flows with the same destination AS number, source

AS number, BGP next hop, inbound interface index, and

destination-prefix NetStream flows with the same destination AS number,

destination mask length, destination prefix, and outbound
destination-prefix-tos NetStream flows with the same destination AS number,

destination mask length, destination prefix, ToS, and outbound
index-tos NetStream flows with the same inbound interface index,

outbound interface index, and ToS are aggregated as one flow
and one aggregation record is generated.
prefix NetStream flows with the same source AS number, destination

source prefix, destination prefix, inbound interface index, and
prefix-tos NetStream flows with the same source AS number, destination

source prefix, destination prefix, ToS, inbound interface index,
and outbound interface index are aggregated as one flow and
one aggregation record is generated.
protocol-port NetStream flows with the same protocol number, source port,
and destination port are aggregated as one flow and one
protocol-port-tos NetStream flows with the same protocol number, source port,
destination port, ToS, inbound interface index, and outbound
source-prefix NetStream flows with the same source AS number, source

mask length, source prefix, and inbound interface index are
aggregated as one flow and one aggregation record is
generated.
source-prefix-tos NetStream flows with the same source AS number, source

mask length, source prefix, ToS, and inbound interface index
are aggregated as one flow and one aggregation record is
generated.
Step 3 Run:
enable
Statistics collection of flows aggregated in a specified aggregation mode is enabled.

mask { source | destination } minimum mask-length
The length of the aggregate mask is set.

The mask used by the system is the higher mask between the mask in the FIB table and the set
mask. If no aggregate mask is set, the system uses the mask in the FIB table for flow aggregation.
NOTE
The aggregate mask takes effect only for aggregation modes of destination-prefix, destination-prefix-tos,
prefix, prefix-tos, source-prefix, and source-prefix-tos.
Step 5 Run:
commit
----End
6.6.3 Outputting Aggregated Flows

To ensure that aggregated flows are correctly output to the NMS, you need to configure the aging
time, source address, and destination address for aggregated flows.
Context
IPv6 aggregated flows can be output only in V9 format.
Procedure
Step 1 Run:
system-view
Step 2 Run:
The destination IP address configured in the system view takes precedence over that configured
in the NetStream aggregation view.
Step 3 Run:
ipv6 netstream aggregation { as | as-tos | destination-prefix | destination-prefix-
tos | prefix | prefix-tos | protocol-port | protocol-port-tos | source-prefix |
source-prefix-tos }
The IPv6 NetStream aggregation view is displayed.

template timeout-rate timeout-interval
The interval at which the template for outputting aggregated flows in V9 format is refreshed is
set.
By default, the output template of aggregated flows is refreshed every 30 minutes.
Step 5 Run:
ipv6 netstream export source ip-address

The source IP address configured in the aggregation view takes precedence over that configured
in the system view. If no source IP address is configured in the aggregation view, the source IP
address configured in the system view takes effect.
Step 6 Run:
NOTE
l You can configure two destination IP addresses in the system view , the IPv4 NetStream aggregation
view and the IPv4 NetStream aggregation view.
l The destination IP address configured in the system view takes precedence over that configured in the
NetStream aggregation view.
Step 7 (Optional) Configure parameters for aging aggregated flows as needed.

l Run:
ipv6 netstream aggregation timeout active active-interval
The active aging time is configured for NetStream aggregated flows.

l Run:
ipv6 netstream aggregation timeout inactive inactive-interval
The inactive aging time is configured for NetStream aggregated flows.

The default active aging time of NetStream aggregated flows is 30 minutes and the default
inactive aging time is 300 seconds.
Step 8 Run:
commit
----End

Type
NSC.
Context

CAUTION
Procedure
Step 1 Run:
system-view
Step 2 Run:
ipv6 netstream as-mode { 16 | 32 }
Step 3 Run:
ipv6 netstream export index-switch { 16 | 32 }
configured.
conditions are met:
l Aggregated flows are output in V9 format.
----End

as needed.
Context
following packets:
l Unicast packets
l Multicast packets

l Fragmented packets
NOTE
sampled.
Procedure
Step 1 Run:
system-view

each packet.
Step 3 Run:

each packet.
NOTE
command.
l The execution of either command takes effect on all packets and there is no need to configure
both of them. If it is required to configure both of them, ensure that sampling modes and
sampling ratios configured by the ip netstream sampler and ipv6 netstream sampler
commands are identical.
l Packets are sampled at the set sampling ratio, regardless of packet types. For example, if the
sampling ratio in fixed packet sampling mode is set to 1000:1, one packet will be sampled
every 1000 packets, regardless of these packets are IPv4 or IPv6 packets.
Step 5 Run:
ipv6 netstream { inbound | outbound }
NetStream is enabled on the interface.
Statistics about packets' BGP next-hop information can also be collected. Original flows output
in V5 format, however, cannot carry the BGP next-hop information.

unicast flows.
Step 6 Run:
commit
----End

following commands in any view to check whether NetStream is enabled on the device.
Context
Run the following command to check the previous configuration.
Procedure
l Run the display ipv6 netstream cache { as | as-tos | destination-prefix | destination-
prefix-tos | prefix | prefix-tos | protocol-port | protocol-port-tos | source-prefix | source-
prefix-tos |mpls-label } slot slot-id command to view various aggregated flows in the
buffer.
l Run the display ipv6 netstream statistics slot slot-id command to view statistics about
NetStream flows.
----End
Example
Run the display ipv6 netstream cache destination-prefix slot 3 command. If the destination
IP address and prefix aggregation mode have been successfully configured, you can view
statistics about destination IP addresses, AS numbers, masks, and prefixes of IP or MPLS packets
in the buffer on the router.
<HUAWEI> display ipv6 netstream cache destination-prefix slot 3
DstIf DstAs DstMsk DstPre

SrcIf SrcAs SrcMsk SrcPre
Streams Packets Direction
--------------------------------------------------------------------------
GI5/0/10 0 64 1114::
GI5/0/0 0 128 1000::200:0:3701:5EA4
1 1 in
GI5/0/10 0 64 1114::
GI5/0/23 0 128 1000::200:0:3701:5EA4
1 1 out
Run the display ipv6 netstream statistics slot slot-id command, and you can view statistics
about NetStream flows.
[~HUAWEI] display ipv6 netstream statistics slot 1


--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
1 ~ 64 : 0 IPV4 : 11214946
65 ~ 128 : 544123 IPV6 : 0
129 ~ 256 : 0 MPLS : 0
257 ~ 512 : 10670823 L2 : 0
513 ~ 1024 : 0 Total : 11214946
1025 ~ 1500 : 0
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
origin 0 0
0 0 0
as 0 0
0 0 0
as-tos 0 0
0 0 0
protport 0 0
0 0 0
protporttos 0 0
0 0 0
srcprefix 0 0
0 0 0
srcpretos 0 0
0 0 0
dstprefix 0 0
0 0 0
dstpretos 0 0
0 0 0
prefix 0 0
0 0 0
prefix-tos 0 0
0 0 0
mpls-label 0 0
0 0 0
bgp-nhp-tos 0 0
0 0 0
index-tos 0 0
0 0 0
--------------------------------------------------------------------------------

If statistics about MPLS packets are collected on the P, the P sends statistics to inform the NSC
of the MPLS label-specific traffic volume.

Figure 6-10 Networking diagram of MPLS flow statistics collection

NDA
NSC
NDA
NSC
Traffic
NDE NDE
Context
Before collecting statistics about MPLS IPv4 packets, complete the following task:
l Enabling MPLS on the device and interfaces, and configuring the MPLS network
Procedure
Step 1 Run:
system-view
Step 2 Output statistics about MPLS IPv4 packets in the form of original flows or aggregated flows as
needed.
NOTE
MPLS original flows and aggregated flows can be output only in V9 format.
l Statistics about original flows
1. Run:
ip netstream mpls-aware { label-only | ip-only | label-and-ip }
Statistics collection of MPLS packets is enabled.

When sampling MPLS packets, choose one of the following sampling modes as needed:
– To sample only MPLS labels, not inner IP packets, configure label-only.
– To sample only inner IP packets, not MPLS labels, configure ip-only.
– To sample both MPLS labels and inner IP packets, configure label-and-ip.
2. For other configurations, see 6.3 Collecting Statistics About IPv4 Original Flows.

l Statistics about aggregated flows

1. Run:
system-view

2. Run:
ip netstream aggregation mpls-label
The NetStream aggregation view is displayed.

3. For other configurations, see 6.4 Collecting Statistics About IPv4 Aggregated
Flows.
----End

Run the following commands to check the previous configuration.
l Run the display ip netstream cache origin slot slot-id command to view information about
the NetStream buffer.
<HUAWEI> display ip netstream cache origin slot 6

SrcIf SrcP Msk
NextHop Direction
DstIP DstAs
SrcIP SrcAs
Label1 Exp1 Bottom1
Label2 Exp2 Bottom2
Label3 Exp3 Bottom3
--------------------------------------------------------------------------
Unknown 200 0 6 16 0 1253

GI6/0/0 100 0
0.0.0.0 in
193.1.1.2 0
193.1.1.59 0
0.0.0.0 0
0 0 0
0 0 0
0 0 0
0.0.0.0 0
GI6/0/0 200 0 6 16 0 1272

Unknown 100 0
0.0.0.0 out
193.1.1.2 0
193.1.1.28 0
0.0.0.0 0
0 0 0
0 0 0
0 0 0
0.0.0.0 0
NetStream flows.
<HUAWEI> display ip netstream statistics slot 6

------------------------------------------------------------------------------
--
------------------------------------------------------------------------------
--
1 ~ 64 : 0 IPV4 : 159655229
65 ~ 128 : 159655229 IPV6 : 0
129 ~ 256 : 0 MPLS : 0
257 ~ 512 : 0 L2 : 0
513 ~ 1024 : 0 Total : 159655229
1025 ~ 1500 : 0
------------------------------------------------------------------------------
--
------------------------------------------------------------------------------
--
------------------------------------------------------------------------------
--
origin 2 188
190 0 0
as 0 6
6 0 0
as-tos 0 0
0 0 0
protport 0 0
0 0 0
protporttos 0 0
0 0 0
srcprefix 0 0
0 0 0
srcpretos 0 0
0 0 0
dstprefix 0 0
0 0 0
dstpretos 0 0
0 0 0
prefix 0 5
5 0 0
prefix-tos 0 0
0 0 0
mpls-label 0 0
0 0 0
bgp-nhp-tos 0 0
0 0 0
index-tos 0 6
6 0 0
system
export version 9
enable
slot 8


Slot

If statistics about MPLS packets are collected on the P (NDE), the P sends statistics to inform
the NSC of the MPLS label-specific traffic volume.
Figure 6-11 Networking diagram of MPLS flow statistics collection

NDA
NSC
NDA
NSC
Traffic
NDE NDE
Context
Before collecting statistics about MPLS IPv6 packets, complete the following task:
l Enabling MPLS on the device and interfaces, and configuring the MPLS network
Procedure
Step 1 Run:
system-view

Step 2 Run:

ipv6 netstream mpls-aware { label-only | ip-only | label-and-ip }
Statistics collection of MPLS packets is enabled.
When sampling MPLS packets, choose one of the following sampling modes as needed:
l To sample only MPLS labels, not inner IP packets, configure label-only.

l To sample only inner IP packets, not MPLS labels, configure ip-only.
l To sample both MPLS labels and inner IP packets, configure label-and-ip.
Step 3 Output statistics about MPLS IPv6 packets in the form of original flows or aggregated flows as
needed. For detailed applications, see 6.5 Collecting Statistics About IPv6 Original Flows and
6.6 Collecting Statistics About IPv6 Aggregated Flows.
NOTE
MPLS original flows and aggregated flows can be output only in V9 format.
----End

Run the display ipv6 netstream cache origin slot 3 command. If NetStream is successfully
configured, you can view various statistics about MPLS packets cached in the NetStream buffer
on the router.
<HUAWEI> display ipv6 netstream cache origin slot 3

SrcIf SrcP Msk
NextHop Direction
DstIP DstAs
SrcIP SrcAs
Label1 Exp1 Bottom1
Label2 Exp2 Bottom2
Label3 Exp3 Bottom3
--------------------------------------------------------------------------
Unknown 0 0 59 0 0 1
GI5/0/0 0 0
0.0.0.0 in
1114::200:0:3A01:102 0
1000::200:0:3701:44AC 0
0.0.0.0 0
0 0 0
0 0 0
0 0 0
0.0.0.0 0
GI5/0/10 0 0 59 0 0 1
Unknown 0 0
0.0.0.0 out
1114::200:0:3A01:102 0
1000::200:0:3701:44AB

6.9 Collecting Statistics About BGP/MPLS VPN Flows

Collecting traffic statistics on BGP/MPLS VPN networks helps users to monitor the BGP/MPLS
VPN network condition.
As shown in Figure 6-12, statistics about MPLS flows sent from the P to the NSC inform the
NSC of the traffic volume and traffic type corresponding to each label. Such statistics, however,
cannot tell to which VPN each traffic belongs. In this case, the PE sends the meaning of each
label to the NSC so that the NSC can determine to which VPN the received traffic belongs. In
this manner, the NSC can analyze the traffic data of each VPN and display the result to users.
Figure 6-12 Networking diagram of collecting statistics about BGP/VPLS VPN flows
NSC NSA
MPLS statistics:
Out-label: 400
In-label: 1024
PE-address: 10.1.1.1
TAL information:
Router-id: 1.1.1.1
Label:1024
PE1 PE2
P
BGP/MPLS VPN
Context
Before collecting statistics about BGP/VPLS VPN flows, complete the following task:
l Deploying the BGP/MPLS VPN network
Procedure
l Enable statistics collection of MPLS flows on the P.
Follow the configuration procedures described in 6.7 Collecting Statistics About MPLS
IPv4 Packets or 6.8 Collecting Statistics About MPLS IPv6 Packets as needed.
l Enable the output of TAL options on the PE.
1. Run:
ip netstream export template option application-label

The output of TAL options is enabled, and the corresponding TAL option template is
sent to the NSC.
By default, the output of TAL options is disabled.
2. Run:
ip netstream export template option { refresh-rate packet-number | timeout-
rate timeout-interval }
The packet interval and time interval at which the TAL option template is refreshed
are set.
TAL option packets are separately output to the NSC in V9 format. To ensure that the
NSC can successfully parse the TAL option packets, it is required that the
corresponding TAL option template be sent to the NSC.
The TAL option template can be refreshed at both the fixed packet and time intervals.
Packet and time intervals can both be configured, without affecting each other.
– refresh-rate packet-number: indicates that the TAL option template is refreshed
at the fixed packet interval.
– timeout-rate timeout-interval: indicates that the TAL option template is refreshed
at the fixed time interval.
By default, the TAL option template is refreshed at intervals of 20 packets and 30
minutes.
----End

After packet statistics collection and output of NetStream flows are configured, run the display
ip netstream export option command in any view. You can view information about the output
option template.
<HUAWEI> display ip netstream export option
------------------------------------------------------
Option Data Succeeded Failed
------------------------------------------------------
l3vpn 100 0
6.10 Maintaining NetStream

This section describes how to maintain NetStream.
6.10.1 Aging Original Flows Forcibly

Original flows in the buffer in a specified slot can be aged forcibly so as to output original flows
or generate aggregated flows.

Context
CAUTION
Commands for aging IPv4 and IPv6 original flows are different. Therefore, use a proper
command as needed.
Before forcibly aging original flows in the buffer, run the undo ip netstream { inbound |
outbound } command or the undo ipv6 netstream { inbound | outbound } command in the
interface view to temporarily disable the sampling function. Otherwise, within 30 seconds after
the reset ip netstream cache command or the reset ipv6 netstream cache command is run,
sampled original flows are forcibly output without aggregation.
The sampling function can be re-enabled 30 seconds after the reset ip netstream cache
command or the reset ipv6 netstream cache command is run.
Procedure
l Run:
system-view

l Run:
reset ip netstream cache slot slot-id
IPv4 original flows in the buffer are forcibly aged.

l Run:
reset ipv6 netstream cache slot slot-id
IPv6 original flows in the buffer are forcibly aged.

----End
6.10.2 Monitoring the NetStream Operating Status

In routine maintenance, you can run the following command in any view to check the NetStream
operating status.
Procedure
l Run:
display ip netstream cache origin slot slot-id
Information about the NetStream flow buffer is displayed.

l Run:
display ip netstream statistics slot slot-id
Statistics about NetStream flows are displayed.

l Run:
display netstream { all | global | interface interface-type interface-number }
NetStream configurations in different views are displayed.

l Run:

display ip netstream cache { as | as-tos | bgp-nexthop-tos | destination-

prefix | destination-prefix-tos | index-tos | mpls-label | prefix | prefix-
tos | protocol-port | protocol-port-tos | source-prefix | source-prefix-tos }
slot slot-id
Information about various aggregated flows in the buffer is displayed.

l Run:
display ip netstream export option
Information about the output option template is displayed.

l Run:
display ipv6 netstream cache origin slot slot-id
Information about the NetStream flow buffer is displayed.

l Run:
display ipv6 netstream cache { as | as-tos | destination-prefix | destination-
prefix-tos | prefix | prefix-tos | protocol-port | protocol-port-tos | source-
prefix | source-prefix-tos |mpls-label } slot slot-id
Information about various aggregated flows in the buffer is displayed.

l Run:
display ipv6 netstream statistics slot slot-id
Statistics about NetStream flows are displayed.

----End

This section provides NetStream configuration examples in different scenarios.
6.11.1 Example for Collecting Statistics About Abnormal IPv4

Flows at the User Side
The NetStream traffic statistics collection function helps analyze the type and location of
abnormal traffic rapidly.
CAUTION
interface number. On the NE5000E cluster, an interface is numbered in the format of chassis
ID/slot number/card number/interface number. If the slot number is specified, the chassis ID of
the slot must also be specified.
As shown in Figure 6-13, NetStream can collect statistics about the source IP address,
destination IP address, port, and protocol information of network packets at the user side. Such
statistics help analyze users' behaviors and detect the worm-infected terminals, source and
destination of DoS/DDos attacks, source of junk mails, and unauthorized web sites. In addition,
NetStream allows users to rapidly identify the virus type and locate the IP address of abnormal
traffic. Based on other characteristics of NetStream flows, uses can take proper actions to filter
out virus-infected traffic and prevent it from spreading on the network.

Figure 6-13 Networking diagram of collecting statistics about abnormal IPv4 flows at the user
side
192.168.1.2/24 192.168.1.1/24
POS1/0/0 POS1/0/0
LAN IP backnone
PE
CE GE2/0/0
192.168.2.1/24
192.168.2.2/24
NSC&NDA
1. Configure PEs and CEs to communicate with each other over the network between them.
2. Configure NetStream to collect statistics about incoming and outgoing flows on the user-
side interface of the PE.
Data Preparation
l User-side interface of the PE
l Output format of NetStream flows
l Destination IP address, destination port number, and source IP address of NetStream flows
to be output
l Number of the slot where the NetStream service processing board resides (In this example,
the NetStream service processing board is in slot 4.)
Procedure
Step 1 Configure PEs and CEs to communicate with each other over the network between them.
# Configure the IP address and mask of each interface as described in Figure 6-13. Details for
the configuration procedure are not provided here.
Step 2 Enable the NetStream statistics collection function on POS 1/0/0 of the PE.
# Configure the LPU to process NetStream services in integrated mode.
<PE> system-view
[~PE] slot 1
[~PE-slot-1] ip netstream sampler to slot 4
[~PE-slot-1]quit
# Enable the statistics collection of TCP flags in original flows.

[~PE] ip netstream tcp-flag enable

# Configure the destination address, destination port number, and source address for NetStream
flows output in V5 format
[~PE] ip netstream export host 192.168.2.2 9001
[~PE] ip netstream export source 192.168.2.1
# Enable NetStream sampling and configure the fixed packet sampling mode.
[~PE] ip netstream sampler fix-packets 10000 inbound
[~PE] ip netstream sampler fix-packets 10000 outbound
[~PE] commit
# Configure NetStream to collect statistics about incoming and outgoing flows on POS 1/0/0 of
the PE.
[~PE] interface pos 1/0/0
[~PE-Pos1/0/0] undo shutdown
[~PE-Pos1/0/0] ip netstream inbound
[~PE-Pos1/0/0] ip netstream outbound
[~PE-Pos1/0/0] quit
[~PE] commit
Step 3 Verify the configuration result.

# Run the display ip netstream cache origin slot 4 command in the user view. You can view
information about various original flows in the NetStream flow buffer.
<PE> display ip netstream cache origin slot 4

SrcIf SrcP Msk
NextHop Direction
DstIP DstAs
SrcIP SrcAs
Label1 Exp1 Bottom1
Label2 Exp2 Bottom2
Label3 Exp3 Bottom3
--------------------------------------------------------------------------
Unknown 20 0 6 0 0 1
PO2/0/0 10 0
0.0.0.0 in
58.1.1.2 0
55.67.121.72 0
0.0.0.0 0
0 0 0
0 0 0
0 0 0
0.0.0.0 0
Unknown 20 0 6 0 0 1
PO1/0/0 10 0
0.0.0.0 in
58.1.1.2 0
55.67.121.70 0
0.0.0.0 0
0 0 0
0 0 0
0 0 0
0.0.0.0 0
PO2/0/0 20 0 6 0 0 1

PO1/0/0 10 0
0.0.0.0 out
58.1.1.2 0
55.67.121.68 0
0.0.0.0 0
0 0 0
0 0 0
0 0 0
0.0.0.0 0
----End
Configuration Files
l Configuration file of the CE
#
sysname CE
#
interface Pos 1/0/0
ip address 192.168.1.2 255.255.255.0
#
return
l Configuration file of the PE

#
slot 1
ip netstream sampler to slot 4
#
sysname PE
#
ip netstream tcp-flag enable
ip netstream sampler fix-packets 10000 outbound
#
interface gigabitethernet 2/0/0
ip address 192.168.2.1 255.255.255.0
#
interface Pos 1/0/0
ip address 192.168.1.1 255.255.255.0
ip netstream inbound
ip netstream outbound
#
return
6.11.2 Example for Collecting Statistics About IPv4 Flows

Aggregated Based on the AS Number
NetStream allows flows to be aggregated based on the AS number, which makes accounting or
management easier.
CAUTION

As shown in Figure 6-14, Router D connects network A and network B to the Wide Area
Network (WAN). Flows are sampled and aggregated on Router D and then sent to the NSC.
Figure 6-14 Networking diagram of collecting statistics about IPv4 flows aggregated based on
the AS number
NSC&NDA
RouterC
GE 1/0/0
RouterA 3.3.3.2/24
3.3.3.1/24
POS 1/0/0 GE 2/0/0
172.168.0.1/24
RouterD
A WAN
GE 1/0/0
POS 1/0/0 1.1.1.1/24
172.168.0.2/24 POS 2/0/0
172..1.1.2/24
172.1.1.1/24
POS 1/0/0
RouterB
B
1. Configure reachable routes between the egress router of the LAN and the WAN.
2. Configure reachable routes between the ingress router of the LAN and the NSC.
3. Configure the ingress router of the LAN to sent traffic statistics to the specified NSC.
4. Configure the ingress router of the LAN to sent traffic statistics to the inbound interface
on the NSC.
5. Aggregate sampled flows to reduce the data volume sent to the NSC.
6. Enable NetStream on the inbound interface of the ingress router.
Data Preparation
l IP address of each interface

l IP address of the NSC

l Output format of NetStream flows

l NetStream sampling ratio
Procedure
Step 1 Configure an IP address for the interface on each router. Details for the configuration procedure
are not provided here.
Step 2 Configure reachable routes between the WAN, router A, and router B.
# Configure reachable routes between router A and router D.
[~RouterA] ip route-static 1.1.1.1 24 pos 1/0/0
# Configure reachable routes between router B and router D.

[~RouterB] ip route-static 1.1.1.1 24 pos 1/0/0
[~RouterB] commit
Step 3 Configure reachable routes between router D and the NSC.

# Configure reachable routes between router D and router C.
[~RouterD] ip route-static 2.2.2.1 24 3.3.3.2
[~RouterD] commit
Step 4 Enable NetStream on router D.

# Configure the LPU on router D to process NetStream services in integrated mode.
[~RouterD] slot 1
[~RouterD-slot-1] ip netstream sampler to slot 4
[~RouterD-slot-1] return
# Enable the NetStream statistics function.

[~RouterD-GigabitEthernet1/0/0] ip netstream inbound
# Output aggregated flows in V9 format.

[~RouterD] ip netstream aggregation as
[~RouterD-aggregation-as] enable
[~RouterD-aggregation-as] ip netstream export host 2.2.2.1 3000
[~RouterD-aggregation-as] ip netstream export source 3.3.3.1
[~RouterD-aggregation-as] export version 9
# Enable the NetStream packet sampling function.

[~RouterD-GigabitEthernet1/0/0] ip netstream sampler fix-packets 1000 inbound
[~RouterD-GigabitEthernet1/0/0] quit
[~RouterD] commit

# View information about flows in the NetStream flow buffer on the router.
[~RouterD] display ip netstream cache as slot 4

DstIf DstAs Streams Packets Direction

SrcIf SrcAs
--------------------------------------------------------------------------
GI4/2/23 0 16105 16105 in
GI4/2/6 0
----End
Configuration Files
#
sysname RouterA
#
interface Pos1/0/0
link-protocol ppp
ip address 172.168.0.1 255.255.0.0
#
ip route-static 1.1.1.1 2555.255.0 POS1/0/0
#
return

#
sysname RouterB
#
interface Pos1/0/0
link-protocol ppp
ip address 172.1.1.1 255.255.0.0
#
ip route-static 1.1.1.1 2555.255.0 POS1/0/0
#
return

#
sysname RouterC
#
interface Pos1/0/0
link-protocol ppp
ip address 3.3.3.2 255.255.0.0
#
return

#
slot 2
#
sysname RouterD
#
interface Pos1/0/0
link-protocol ppp
ip address 172.168.0.2 255.255.255.0
#
interface Pos1/0/1
link-protocol ppp
ip address 172.1.1.2 255.255.255.0
#
ip address 1.1.1.1 255.255.255.0
#
ip address 3.3.3.1 255.255.255.0

#
enable
export version 9
#
return
6.11.3 Example for Collecting Statistics About MPLS Original

Flows
Collecting statistics about MPLS original flows can obtain flow information corresponding to
a specified label.
CAUTION
As shown in Figure 6-15, Router A, Router B, and Router C support MPLS and use OSPF as
the IGP protocol on the MPLS backbone network.
Local LDP sessions are established between Router A and Router B, and between Router B and
Router C. A remote LDP session is established between Router A and Router C. NetStream is
enabled on Router B to collect statistics about MPLS flows.
Figure 6-15 Networking diagram of collecting statistics about MPLS original flows
Loopback1 Loopback1 Loopback1
1.1.1.9/32 2.2.2.9/32 3.3.3.9/32
POS1/0/0 POS2/0/0 GE1/0/0 192.168.1.2/24
10.1.1.1/24 10.1.2.1/24 192.168.1.1/24
POS1/0/0 POS1/0/0
RouterA10.1.1.2/24 RouterB 10.1.2.2/24 RouterC
NSC&NDA
CE1 CE2

1. Configure the LDP session between every two Routers.

2. Configure the remote peer and its IP address on the two Routers that have established a
remote LDP session.
3. Configure the destination IP address, destination port number, and source IP address of
NetStream flows to be output.
Data Preparation
l IP addresses of interfaces on each router as shown in Figure 6-15, OSPF process 1, and
Area 0
l Remote peer of router A, whose name is router c and the IP address is 3.3.3.9.
l Remote peer of router C, whose name is router a and the IP address is 1.1.1.9.
Procedure
Step 1 Configure an IP address for each interface.
# Configure an IP address and a mask for each interface (including loopback interfaces) as
described in Figure 6-15. Details for the configuration procedure are not provided here.
Step 2 Configure the LDP session between every two Routers.
# Configure OSPF to advertise the host routes of the specified LSR ID and of the network
segments to which interfaces on the router are connected. Enable basic MPLS functions on each
router and its interfaces.
For configurations of the static MPLS TE tunnel, see the chapter "MPLS Basic Configurations"
in the HUAWEI NetEngine5000E Core Router Configuration Guide - MPLS.
Step 3 Enable NetStream on POS 1/0/0 of Router B.
# Configure the NetStream service processing mode on an LPU.
[~RouterB] slot 1
[~RouterB-slot-1] ip netstream sampler to slot 4
[~RouterB-slot-1] return
# Configure NetStream to collect statistics about incoming and outgoing packets on POS 1/0/0
of Router B.
[~RouterB] interface pos 1/0/0
[~RouterB-Pos1/0/0] ip netstream inbound
[~RouterB-Pos1/0/0] ip netstream outbound
[~RouterB-Pos1/0/0] quit
# Configure NetStream to sample both inner IP packets and labels of MPLS packets.
[~RouterB] ip netstream mpls-aware label-and-ip
flows output in V5 format.
[~RouterB] ip netstream export host 192.168.1.2 2100
[~RouterB] ip netstream export source 10.1.2.1

[~RouterB] ip netstream sampler fix-packets 10000 inbound
[~RouterB] ip netstream sampler fix-packets 10000 outbound
[~RouterB] commit

# Run the display ip netstream cache origin slot 4 command in the user view. You can view
information about the NetStream flow buffer and the statistics about output flows.
<RouterB> display ip netstream cache origin slot 4

SrcIf SrcP Msk
NextHop Direction
DstIP DstAs
SrcIP SrcAs
Label1 Exp1 Bottom1
Label2 Exp2 Bottom2
Label3 Exp3 Bottom3
--------------------------------------------------------------------------
Unknown 20 0 6 0 0 1
PO2/0/0 10 0
0.0.0.0 in
58.1.1.2 0
55.67.121.72 0
0.0.0.0 0
1011 2 1
0 0 0
0 0 0
1.1.1.9 0
Unknown 20 0 6 0 0 1
PO1/0/0 10 0
0.0.0.0 in
58.1.1.2 0
55.67.121.70 0
0.0.0.0 0
1001 2 1
0 0 0
0 0 0
10.1.1.9 0
PO2/0/0 20 0 6 0 0 1
PO1/0/0 10 0
0.0.0.0 out
58.1.1.2 0
55.67.121.68 0
0.0.0.0 0
1021 2 1
0 0 0
0 0 0
20.1.1.9 0
----End
Configuration Files

#
sysname RouterA
#
mpls lsr-id 1.1.1.9
#
mpls
lsp-trigger all
#
mpls ldp
#
mpls ldp remote-peer Routerc
remote-ip 3.3.3.9
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 1.1.1.9 0.0.0.0
#
return
#
slot 1
#
sysname RouterB
#
#
mpls lsr-id 2.2.2.9
#
mpls
lsp-trigger all
#
mpls ldp
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface Pos2/0/0
undo shutdown
link-protocol ppp
ip address 20.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0

network 10.1.1.0 0.0.0.255

network 20.1.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return

#
sysname RouterC
#
ip netstream mpls-aware label-and-ip
#
mpls lsr-id 3.3.3.9
#
mpls
lsp-trigger all
#
mpls ldp
#
mpls ldp remote-peer Routera
remote-ip 1.1.1.9
#
interface Pos1/0/0
undo shutdown
link-protocol ppp
ip address 20.1.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 20.1.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return
6.11.4 Example for Deploying NetStream on the BGP/MPLS IP VPN

Network
This section describes how to deploy NetStream on the BGP/MPLS IP VPN network to monitor
VPN service traffic.
CAUTION
With the development of L3VPN services, users and carriers increasingly demand higher Quality
of Service (QoS). After voice over IP and video over IP services are promoted, carriers and users
all tend to sign Service Level Agreements (SLAs). Deploying NetStream on the BGP/MPLS IP
VPN network allows users to analyze the LSP traffic between PEs and adjust the network
accordingly to better meet service requirements.

On the IPv4 BGP/MPLS IP VPN network shown in Figure 6-16:

l Packets with specified application labels are sampled on PE2 and sent to the NSC and NDA.
l Statistics collection of incoming and outgoing packets with specified application labels is
enabled on the P. Packets with specified application labels sent from the CE are sampled
and sent to the NSC and NDA.
l Traffic statistics are analyzed on the NSC and NDA to obtain users' traffic volume between
PEs.
Figure 6-16 Networking diagram of the BGP/MPLS IP VPN
NSC&NDA
172.3.1.2/24 192.168.2.2/24
POS3/0/0
172.3.1.1/24
GE1/0/0
POS1/0/0 POS2/0/0 192.168.2.1/24
Loopback1 172.1.1.2/24 172.2.1.1/24 Loopback1
1.1.1.9/32 POS3/0/0 POS3/0/0 3.3.3.9/32
GE1/0/0 172.1.1.1/24 172.2.1.2/24 GE2/0/0
10.2.1.2/24 PE1 P Loopback1 PE2 10.4.1.2/24
2.2.2.9/32
MPLS backbone
AS: 100
GE1/0/0 GE1/0/0
10.2.1.1/24 10.4.1.1/24
CE2 CE4
VPN-A VPN-A
AS: 65420 AS: 65440
1. Configure an IP address for each interface.

2. Configure the BGP/MPLS IP VPN.
3. Enable NetStream to sample packets with specified application labels on PE2.
4. Enable NetStream to collect statistics about incoming and outgoing packets with specified
application labels.
Data Preparation
l Output format for NetStream flows and the sampling interval

l Destination IP address, destination port number, and source IP address of NetStream flows
to be output
Procedure
Step 1 Configure an IP address for each interface.
Configure an IP address and a mask for each interface (including loopback interfaces) as
described in Figure 6-16. Details for the configuration procedure are not provided here.
Step 2 Configure the BGP/MPLS IP VPN.
For configuration details, see the chapter "BGP/MPLS IP VPN Configuration" in the HUAWEI
NetEngine5000E Core Router Configuration Guide - VPN.
Step 3 Enable NetStream to sample packets with specified application labels on PE2.
# Configure the LPU on PE2 to process NetStream services in integrated mode.

<PE2> system-view
[~PE2] slot 2
[~PE2-slot-2] ip netstream sampler to slot 4
[~PE2-slot-2] return
# Configure PE2 to send information about L3VPN application labels to the NMS.
[~PE2] ip netstream export template option application-label
[~PE2] ip netstream export version 9
[~PE2] ip netstream export host 192.168.2.2 9000
[~PE2] ip netstream export source 192.168.2.1
Step 4 Enable NetStream to collect statistics about incoming and outgoing packets with specified
application labels on the P.
# Configure the LPU on the P to process NetStream services in integrated mode.

<P> system-view
[~P] slot 2
[~P-slot-2] ip netstream sampler to slot 4
[~P-slot-2] quit
# Collect statistics about incoming and outgoing packets on POS 2/0/0 of the P.
[~P] interface Pos 2/0/0
[~P-Pos2/0/0] ip netstream inbound
[~P-Pos2/0/0] ip netstream outbound
[~P-Pos2/0/0] quit
# Configure NetStream to sample both inner IP packets and labels of MPLS packets.
[~P] ip netstream mpls-aware label-and-ip
[~P] ip netstream export version 9
[~P] ip netstream export host 192.168.2.2 9001
[~P] ip netstream export source 172.2.1.1

[~P] ip netstream sampler fix-packets 10000 inbound

[~P] ip netstream sampler fix-packets 10000 outbound
[~P] quit
# Run the display ip netstream cache origin slot 4 command in the user view. If the
configuration succeeds, you can view IP- and MPLS-related information about VPN packets
cached in the NetStream flow buffer.
<P> display ip netstream cache origin slot 4

SrcIf SrcP Msk
NextHop Direction
DstIP DstAs
SrcIP SrcAs
Label1 Exp1 Bottom1
Label2 Exp2 Bottom2
Label3 Exp3 Bottom3
--------------------------------------------------------------------------
Unknown 20 0 6 0 0 1
PO2/0/0 10 0
0.0.0.0 in
58.1.1.2 0
55.67.121.72 0
0.0.0.0 0
1011 2 1
0 0 0
0 0 0
1.1.1.9 0
Unknown 20 0 6 0 0 1
PO1/0/0 10 0
0.0.0.0 in
58.1.1.2 0
55.67.121.70 0
0.0.0.0 0
1001 2 1
0 0 0
0 0 0
10.1.1.9 0
PO2/0/0 20 0 6 0 0 1
PO1/0/0 10 0
0.0.0.0 out
58.1.1.2 0
55.67.121.68 0
0.0.0.0 0
1021 2 1
0 0 0
0 0 0
20.1.1.9 0
----End
Configuration Files
l Configuration file of PE1

#
sysname PE1
#
ip vpn-instance vpna
route-distinguisher 100:1
vpn-target 100:1 export-extcommunity
vpn-target 100:1 import-extcommunity
#
mpls lsr-id 1.1.1.9
#
mpls
#
ip binding vpn-instance vpna
ip address 10.2.1.2 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
ip address 172.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 1.1.1.9 255.255.255.255
#
bgp 100
peer 3.3.3.9 as-number 100
peer 3.3.3.9 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 3.3.3.9 enable
#
ipv4-family vpnv4
policy vpn-target
peer 3.3.3.9 enable
#
ipv4-family vpn-instance vpna
import-route direct
#
ospf 1
area 0.0.0.0
network 1.1.1.9 0.0.0.0
network 172.1.1.0 0.0.0.255
#
return
l Configuration file of the P
slot 2
#
sysname P
#
ip netstream mpls-aware label-and-ip
ip netstream export version 9
#
mpls lsr-id 2.2.2.9
#
mpls
lsp-trigger all
#
mpls ldp
#
interface Pos1/0/0
link-protocol ppp

ip address 172.1.1.2 255.255.255.0

mpls
mpls ldp
#
interface Pos2/0/0
link-protocol ppp
ip address 172.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface Pos3/0/0
link-protocol ppp
ip address 172.3.1.1 255.255.255.0
#
interface LoopBack1
ip address 2.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 172.1.1.0 0.0.0.255
network 172.2.1.0 0.0.0.255
network 2.2.2.9 0.0.0.0
#
return
l Configuration file of PE2
#
slot 2
#
sysname PE2
#
ip netstream export version 9
ip netstream export template option application-label
#
ip vpn-instance vpna
route-distinguisher 200:1
vpn-target 100:1 export-extcommunity
vpn-target 100:1 import-extcommunity
#
mpls lsr-id 3.3.3.9
#
mpls
lsp-trigger all
#
mpls ldp
#
ip binding vpn-instance vpna
ip address 10.3.1.2 255.255.255.0
#
interface Pos3/0/0
link-protocol ppp
ip address 172.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 3.3.3.9 255.255.255.255
#
bgp 100
peer 1.1.1.9 connect-interface LoopBack1
#
ipv4-family unicast

peer 1.1.1.9 enable

#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.9 enable
#
ipv4-family vpn-instance vpna
import-route direct
#
ospf 1
area 0.0.0.0
network 172.2.1.0 0.0.0.255
network 3.3.3.9 0.0.0.0
#
return
l Configuration file of CE2

#
sysname CE2
#
ip address 10.2.1.1 255.255.255.0
#
bgp 65420
#
ipv4-family unicast
import-route direct
peer 10.2.1.2 enable
#
return
l Configuration file of CE4

#
sysname CE4
#
ip address 10.4.1.1 255.255.255.0
#
bgp 65440
#
ipv4-family unicast
import-route direct
peer 10.4.1.2 enable
#
return


netengine5000e

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

netengine5000e

Uploaded by

Copyright:

Available Formats

HUAWEI NetEngine5000E Core Router

Configuration Guide - System

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2011-10-15) Huawei Proprietary and Confidential i

About This Document

Related Versions (Optional)

Product Name Version

HUAWEI NetEngine5000E V800R002C01

Indicates a hazard with a high level of risk, which if not

Indicates a hazard with a medium or low level of risk, which

Issue 01 (2011-10-15) Huawei Proprietary and Confidential ii

Indicates a potentially hazardous situation, which if not

Provides additional information to emphasize or supplement

Command Conventions (Optional)

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

[ x | y | ... ] Optional items are grouped in brackets and separated by

{ x | y | ... }* Optional items are grouped in braces and separated by

[ x | y | ... ]* Optional items are grouped in brackets and separated by

# A line starting with the # sign is comments.

Changes in Issue 01 (2011-10-15)

Issue 01 (2011-10-15) Huawei Proprietary and Confidential iii

About This Document.....................................................................................................................ii

Issue 01 (2011-10-15) Huawei Proprietary and Confidential iv

2.3.7 Checking the Configuration.....................................................................................................................25

Issue 01 (2011-10-15) Huawei Proprietary and Confidential v

Issue 01 (2011-10-15) Huawei Proprietary and Confidential vi

6.3.5 Sampling IPv4 Flows.............................................................................................................................135

Issue 01 (2011-10-15) Huawei Proprietary and Confidential vii

About This Chapter

1.1 Device Management Overview

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 1

1.1 Device Management Overview

Device Management Operations

1.2 Device Management Features Supported by the

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 2

1.3 Powering Off the Board

l Power off the SFU.

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 3

Checking the Configuration

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 4

1.4 Managing Online Devices

l Power on and start the router normally.

1.4.1 Checking Device Versions

l System software version

1.4.2 Viewing Basic Information About the Device

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 5

1.4.3 Checking Memory Usage

1.4.4 Checking CPU Usage

1.4.5 Checking Device Temperatures

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 6

l Current temperature status of a board

1.4.6 Checking Device Voltages

l Number of voltage sensors for the boards

1.4.7 Checking the Power Module

l Slot ID of the power module

Issue 01 (2011-10-15) Huawei Proprietary and Confidential 7

1.4.8 Checking the Fan Module

l Slot ID of the fan module

1.4.9 Restarting the Device