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

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

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

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

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

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

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

Interface Numbering Conventions
Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 04 (2013-07-10)
This version has the following updates:
The following information is modified:
l 8.2 iStack Features Supported by the Device
l 8.5.4 Configuring a Stack Port
iii
The following information is added:
l 4.4.5 (Optional) Enabling the Output of the Statistics About Repeatedly Generated
Logs
The following information is added:
l 2.4 Enabling Master/Slave Switchover
l 6.4 (Optional) Disabling the USB-based Deployment Function
Initial commercial release.
iv
Contents
About This Document.....................................................................................................................ii
1 Displaying the Device Status......................................................................................................1
1.1 Displaying Information About the device......................................................................................................................3
1.2 Displaying Versions.......................................................................................................................................................3
1.3 Displaying Power Supply Information...........................................................................................................................3
1.4 Displaying the Power......................................................................................................................................................4
1.5 Displaying the Temperature...........................................................................................................................................4
1.6 Displaying the Fan Status...............................................................................................................................................4
1.7 Displaying CPU Usage...................................................................................................................................................5
1.8 Displaying Memory Usage.............................................................................................................................................5
1.9 Displaying Interface Status.............................................................................................................................................6
1.10 Displaying Electronic Labels........................................................................................................................................7
1.11 Displaying System MAC Address................................................................................................................................7
1.12 Displaying the Current Configuration..........................................................................................................................7
1.13 Displaying Diagnostic Information..............................................................................................................................8
1.14 Displaying Health Status..............................................................................................................................................8
1.15 Displaying Information About a Transceiver on the Interface.....................................................................................9
2 Hardware Management..............................................................................................................10
2.1 Hardware Management Overview................................................................................................................................11
2.2 Backing Up Electronic Labels......................................................................................................................................11
2.3 Resetting a Device........................................................................................................................................................11
2.4 Enabling Master/Slave Switchover..............................................................................................................................12
2.5 Configuring the CPU Usage Alarm Threshold.............................................................................................................13
2.6 Configuring the Memory Usage Alarm Threshold.......................................................................................................13
2.7 Configuring the Interval for Updating Power Consumption Data...............................................................................14
2.8 Configuring the System Resource Mode......................................................................................................................15
3 Energy-Saving Management.....................................................................................................17
3.1 Energy-saving Management Overview........................................................................................................................18
3.2 Energy-saving Management Features Supported by the Device..................................................................................18
3.3 Configuring ALS..........................................................................................................................................................19
3.3.1 Enabling ALS on an Interface...................................................................................................................................19
3.3.2 (Optional) Setting the Restart Mode of the Laser......................................................................................................20
Configuration Guide - Device Management Contents
v
3.3.3 (Optional) Setting the ALS Pulse Interval and Width of the Laser...........................................................................21
3.3.4 Checking the Configuration.......................................................................................................................................22
3.4 Configuring the EEE Function.....................................................................................................................................22
3.5 Configuring an Energy-Saving Mode...........................................................................................................................23
3.6 Configuration Examples...............................................................................................................................................24
3.6.1 Example for Configuring ALS..................................................................................................................................24
4 Information Center Configuration...........................................................................................27
4.1 Introduction to the Information Center.........................................................................................................................28
4.2 Information Center Features Supported by the Device................................................................................................28
4.3 Default Configuration...................................................................................................................................................28
4.4 Configuring Log Output...............................................................................................................................................30
4.4.1 Enabling the Information Center...............................................................................................................................32
4.4.2 (Optional) Naming an Information Channel.............................................................................................................32
4.4.3 (Optional) Configuring Log Filtering........................................................................................................................33
4.4.4 (Optional) Setting the Timestamp Format of Logs ..................................................................................................33
4.4.5 (Optional) Enabling the Output of the Statistics About Repeatedly Generated Logs...............................................34
4.4.6 Configuring the Device to Output Logs to the Log Buffer.......................................................................................35
4.4.7 Configuring the Device to Output Logs to a Log File...............................................................................................35
4.4.8 Configuring the Device to Output Logs to the Console............................................................................................36
4.4.9 Configuring the Device to Output Logs to a Terminal..............................................................................................37
4.4.10 Configuring the Device to Output Logs to a Log Host...........................................................................................38
4.4.11 Checking the Configuration.....................................................................................................................................39
4.5 Configuring Trap Output..............................................................................................................................................39
4.5.3 (Optional) Configuring Trap Filtering.......................................................................................................................43
4.5.4 (Optional) Setting the Timestamp Format of Traps..................................................................................................43
4.5.5 Configuring the Device to Output Traps to the Trap Buffer.....................................................................................44
4.5.6 Configuring the Device to Output Traps to a Log File..............................................................................................44
4.5.7 Configuring the Device to Output Traps to the Console...........................................................................................45
4.5.8 Configuring the Device to Output Traps to a Terminal.............................................................................................46
4.5.9 Configuring the Device to Output Traps to a Log Host............................................................................................47
4.5.10 Configuring the Device to Output Traps to an SNMP Agent..................................................................................48
4.6 Configuring Debugging Message Output.....................................................................................................................49
4.6.3 (Optional) Setting the Timestamp Format of Debugging Messages.........................................................................52
4.6.4 Configuring the Device to Output Debugging Messages to the Console..................................................................52
4.6.5 Configuring the Device to Output Debugging Messages to the Terminal................................................................53
4.7 Maintaining the Information Center.............................................................................................................................55
vi
4.7.1 Clearing Statistics......................................................................................................................................................55
4.7.2 Monitoring the Information Center...........................................................................................................................55
4.8.1 Example for Outputting Logs to the Log File...........................................................................................................56
4.8.2 Example for Outputting Logs to a Log Host.............................................................................................................58
4.8.3 Example for Outputting Traps to the SNMP Agent..................................................................................................60
4.8.4 Example for Outputting Debugging Messages to the Console..................................................................................62
5 Fault Management Configuration............................................................................................64
5.1 Introduction to Fault Management...............................................................................................................................65
5.2 Default Configuration...................................................................................................................................................65
5.3 Configuring Alarm Management..................................................................................................................................65
5.3.1 Setting the Alarm Severity........................................................................................................................................65
5.3.2 Configuring the Alarm Reporting Delay Function....................................................................................................66
5.4 Maintenance..................................................................................................................................................................67
5.4.1 Clearing Alarms.........................................................................................................................................................68
5.4.2 Monitoring Alarms....................................................................................................................................................68
5.5.1 Example for Configuring Alarm Management..........................................................................................................69
6 USB-based Deployment Configuration..................................................................................71
6.1 USB-based Deployment Overview..............................................................................................................................72
6.2 Making an Index File....................................................................................................................................................72
6.3 Configuring USB-based Deployment...........................................................................................................................76
6.4 (Optional) Disabling the USB-based Deployment Function........................................................................................78
6.5 Configuration Example.................................................................................................................................................78
6.5.1 Example for Configuring USB-based Deployment...................................................................................................78
7 Mirroring Configuration............................................................................................................81
7.1 Packet Mirroring Overview..........................................................................................................................................82
7.2 Packet Mirroring Features Supported by the Device....................................................................................................82
7.3 Configuring Local Port Mirroring................................................................................................................................85
7.3.1 Configuring a Local Observing Port.........................................................................................................................85
7.3.2 Configuring a Mirrored Port......................................................................................................................................86
7.4 Configuring Remote Port Mirroring.............................................................................................................................87
7.4.1 Configuring a Remote Observing Port......................................................................................................................87
7.4.2 Configuring a Mirrored Port......................................................................................................................................88
7.5 Configuring Local Traffic Mirroring............................................................................................................................89
7.5.1 Configuring a Local Observing Port.........................................................................................................................89
7.5.2 Configuring a Traffic Classifier................................................................................................................................89
7.5.3 Configuring a Traffic Behavior.................................................................................................................................89
vii
7.5.4 Configuring a Traffic Policy......................................................................................................................................90
7.5.5 Applying a Traffic Policy..........................................................................................................................................91
7.6 Configuring Remote Traffic Mirroring........................................................................................................................91
7.6.1 Configuring a Remote Observing Port......................................................................................................................91
7.6.2 Configuring a Traffic Classifier................................................................................................................................92
7.6.3 Configuring a Traffic Behavior.................................................................................................................................92
7.6.4 Configuring a Traffic Policy......................................................................................................................................93
7.6.5 Applying a Traffic Policy..........................................................................................................................................93
7.7.1 Example for Configuring Local Port Mirroring........................................................................................................94
7.7.2 Example for Configuring Layer 2 Remote Port Mirroring........................................................................................95
7.7.3 Example for Configuring Layer 3 Remote Port Mirroring........................................................................................98
7.7.4 Example for Configuring Local Traffic Mirroring..................................................................................................100
8 iStack Configuration.................................................................................................................103
8.1 iStack Overview.........................................................................................................................................................104
8.2 iStack Features Supported by the Device...................................................................................................................105
8.3 Configuration Notes...................................................................................................................................................112
8.4 Default Configuration.................................................................................................................................................114
8.5 Configuring a Stack....................................................................................................................................................114
8.5.1 Configuring the Stack Domain ID...........................................................................................................................115
8.5.2 (Optional) Configuring the Stack ID.......................................................................................................................116
8.5.3 (Optional) Configuring the Stack Priority...............................................................................................................116
8.5.4 Configuring a Stack Port.........................................................................................................................................117
8.5.5 Restarting the Device...............................................................................................................................................120
8.5.6 (Optional) Configuring the Delay in Stack MAC Address Switchover..................................................................120
8.5.7 (Optional) Starting Fast Upgrade of Switches in a Stack........................................................................................121
8.6 (Optional) Configuring Dual-active Detection...........................................................................................................122
8.6.1 Configuring the DAD Mode....................................................................................................................................122
8.6.2 (Optional) Excluding Ports from Shutdown............................................................................................................123
8.6.3 (Optional) Restoring Blocked Ports........................................................................................................................124
8.7 Configuration Examples.............................................................................................................................................125
8.7.1 Example for Configuring a Stack with a Chain Topology......................................................................................125
8.7.2 Example for Configuring a Stack with a Ring Topology........................................................................................128
8.7.3 Example for Configuring DAD in Direct Mode......................................................................................................132
8.7.4 Example for Configuring DAD in Relay Mode......................................................................................................134
viii
1 Displaying the Device Status
About This Chapter
This chapter describes the functions of display commands and how to use the display commands
to view the device running status.
1.1 Displaying Information About the device
You can use the display commands to view component information about the device.
1.2 Displaying Versions
You can use the display commands to view version information about the device.
1.3 Displaying Power Supply Information
You can use the display commands to view power supply information about the device.
1.4 Displaying the Power
You can use the display commands to view the power of the device.
1.5 Displaying the Temperature
You can use the display commands to view the temperature of the device.
1.6 Displaying the Fan Status
This section describes how to check the fan status on a device.
1.7 Displaying CPU Usage
You can use the display commands to view CPU usage statistics and configurations.
1.8 Displaying Memory Usage
You can use the display commands to view memory usage statistics and threshold.
1.9 Displaying Interface Status
You can use the display commands to view the configuration and status of a specified interface.
1.10 Displaying Electronic Labels
You can use the display commands to view electronic labels.
1.11 Displaying System MAC Address
You can run the display commands to view the system MAC address.
1.12 Displaying the Current Configuration
You can use the display commands to view the current configuration of the device.
Configuration Guide - Device Management 1 Displaying the Device Status
1
1.13 Displaying Diagnostic Information
You can use the display commands to view diagnostic information for fault location.
1.14 Displaying Health Status
You can use the display commands to view the health status of the device.
1.15 Displaying Information About a Transceiver on the Interface
You can use the display commands to view information about the optical module of an interface,
including the specifications, manufacturer, and alarm information about the optical module.
2
1.1 Displaying Information About the device
You can use the display commands to view component information about the device.
Context
When a fault occurs on the device, you can view device information to check whether the device
is working properly.
Procedure
l Run
display device [ slot slot-id ]
The component information and device status are displayed.
----End
1.2 Displaying Versions
You can use the display commands to view version information about the device.
Context
You can view version information about the device to determine whether the device needs to be
upgraded or whether the upgrade succeeds.
Procedure
l Run:
display version [ slot slot-id ]
The version information of the device is displayed.
----End
1.3 Displaying Power Supply Information
You can use the display commands to view power supply information about the device.
Context
When a power supply fault occurs on the device, you can run the following command to view
information about power status.
Procedure
l Run:
display device power
The information about power status is displayed.
----End
3
1.4 Displaying the Power
You can use the display commands to view the power of the device.
Context
To learn about the power of the device, check the power information.
Procedure
l Run:
display device power system
The information about the power of the device is displayed.
----End
1.5 Displaying the Temperature
You can use the display commands to view the temperature of the device.
Context
A high or low temperature may damage the hardware. To learn about the temperature of the
device, use the display commands to view the temperature.
Procedure
l Run:
display device temperature { all | slot slot-id }
The temperature of the device is displayed.
----End
1.6 Displaying the Fan Status
This section describes how to check the fan status on a device.
Context
Devices can run properly when fans are working properly. Ineffective heat dissipation causes a
device to overheat and may damage the device hardware.
Procedure
l Run:
display device fan
The fan status is displayed.
----End
4
1.7 Displaying CPU Usage
You can use the display commands to view CPU usage statistics and configurations.
Context
CPU usage is an important index to evaluate device performance. A high CPU usage will cause
service faults, for example, BGP route flapping, frequent VRRP active/standby switchover, and
even failed device login. You can use the display commands to view CPU usage statistics and
configurations to check whether devices are working properly.
CPU usage configurations include the CPU usage alarm threshold and recovery threshold.
l When CPU usage reaches the alarm threshold, the system generates a CPU usage alarm.
l When CPU usage falls within the recovery threshold, the system generates a clear alarm.
Procedure
l Run:
display cpu [ slot slot-id ]
The CPU usage statistics is displayed.
l Run:
display cpu monitor { all | history [ slot slot-id ] | slot slot-id }
The CPU overloading status is displayed.
l Run:
display cpu threshold [ slot slot-id ]
The CPU usage configurations are displayed.
----End
1.8 Displaying Memory Usage
You can use the display commands to view memory usage statistics and threshold.
Context
Memory usage is an important index to evaluate device performance. A high memory usage will
cause service faults. You can use the display commands to view memory usage to check whether
devices are working properly.
You can view the memory usage alarm threshold to learn about the conditions for triggering
alarms.
l When memory usage reaches the alarm threshold, the system generates an alarm.
l When memory usage falls within the alarm threshold, the system generates a clear alarm.
Procedure
l Run:
display memory [ slot slot-id ]
5
The memory usage statistics is displayed.
l Run:
display memory threshold [ slot slot-id ]
The memory usage threshold is displayed.
----End
1.9 Displaying Interface Status
You can use the display commands to view the configuration and status of a specified interface.
Context
View the configuration of an interface.
l After performing operations in a interface view, you can view the configuration about this
interface to check whether the configuration is correct.
View the status of an interface.
l You can view the status of an interface to monitor the interface or locate interface faults.
Procedure
l View the configuration of a specified interface.
1. Run:
system-view
The system view is displayed.
2. Run:
interface interface-type interface-number
The interface view is displayed.
3. Run:
display this
The configuration of the current interface is displayed.
l View the status of an interface using either of the following methods.
Method 1:
1. Run:
display interface [ interface-type [ interface-number ] ]
The status of the specified interface is displayed.
Method 2:
1. Run:
system-view
2. Run:
3. Run:
6
display this interface
The status of the specified interface is displayed.
----End
1.10 Displaying Electronic Labels
You can use the display commands to view electronic labels.
Context
Electronic labels identify the hardware of devices.
Procedure
l Run:
display device elabel [ slot slot-id [ card card-id ] ] [ brief ]
The electronic labels of the device is displayed.
----End
1.11 Displaying System MAC Address
You can run the display commands to view the system MAC address.
Context
You can run the following commands to view the current system MAC address.
Procedure
l Run:
display system mac-address
The system MAC address is displayed.
----End
1.12 Displaying the Current Configuration
You can use the display commands to view the current configuration of the device.
Context
To learn about services currently running on the device, run the following command to view the
device configuration.
Procedure
l Run:
display current-configuration
7
The information of the current configuration is displayed.
----End
1.13 Displaying Diagnostic Information
You can use the display commands to view diagnostic information for fault location.
Context
When a fault occurs in the system or during routine maintenance, you can run the display
commands to collect the running information about all modules.
CAUTION
Viewing diagnostic information helps locate faults but may affect system performance. For
example, CPU usage may become high. Therefore, do not view diagnostic information when
the system is running properly.
Procedure
l Run:
display diagnostic-information [ [ module-name ] &<1-8> [ slot slot-id ] | file-
name ]
The diagnostic information is displayed.
----End
1.14 Displaying Health Status
You can use the display commands to view the health status of the device.
Context
To learn about the device temperature, power supply, fan information, CPU usage, memory
usage, and storage medium, use the fallowing command to view the health status.
Procedure
l Run:
display health
The health status of the device is displayed.
----End
8
1.15 Displaying Information About a Transceiver on the
Interface
You can use the display commands to view information about the optical module of an interface,
including the specifications, manufacturer, and alarm information about the optical module.
Context
When the optical module of an interface fails, run the following commands to view information
about the optical module.
Procedure
l Run:
display interface [ interface-type interface-number | slot slot-id ]
transceiver [ verbose ]
Information about a transceiver on the interface is displayed.
----End
9
2 Hardware Management
About This Chapter
Scientific hardware management reduces the operations performed on hardware resources,
including inserting, removing, installing and uninstalling the hardware, and improves hardware
resource reliability.
2.1 Hardware Management Overview
Scientific hardware management allows you to use commands to operate and manage hardware
resources, for example, reset devices, configure master/slave switchover the hardware resources.
2.2 Backing Up Electronic Labels
You can back up electronic labels to improve network maintenance efficiency.
2.3 Resetting a Device
When a device fails to be upgraded or cannot work properly, you may need to reset the device.
2.4 Enabling Master/Slave Switchover
To implement backup between master and standby switches in a stack with multiple switches,
enable the master/slave switchover function to allow the original standby switch to become the
new master switch.
2.5 Configuring the CPU Usage Alarm Threshold
You can configure the CPU usage alarm threshold to monitor CPU usage.
2.6 Configuring the Memory Usage Alarm Threshold
You can configure the memory usage alarm threshold to monitor memory usage.
2.7 Configuring the Interval for Updating Power Consumption Data
You can configure the interval for updating power consumption data to view power consumption
of the device during a period.
2.8 Configuring the System Resource Mode
You can configure the system resource mode to adjust the allocation of hardware resources.
Configuration Guide - Device Management 2 Hardware Management
10
2.1 Hardware Management Overview
Scientific hardware management allows you to use commands to operate and manage hardware
resources, for example, reset devices, configure master/slave switchover the hardware resources.
Scientific hardware management reduces the operations performed on hardware resources,
including inserting, removing, installing and uninstalling the hardware, and improves hardware
resource reliability.
2.2 Backing Up Electronic Labels
You can back up electronic labels to improve network maintenance efficiency.
Context
Electronic labels can help locate network faults and replace hardware in batches. Therefore,
backing up electronic labels is a must.
l When a network fault occurs, you can rapidly learn about hardware information using
electronic labels, which improves hardware maintenance efficiency. In addition, you can
efficiently analyze and trace the defects in the hardware by analyzing and collecting
electronic labels statistics on the faulty hardware.
l Before replacing hardware in batches, you can use the electronic labels recorded in the
archive systems of customers' devices to obtain accurate hardware deployment information.
Then you can evaluate the impact of hardware replacement and define policies to efficiently
replace hardware in batches.
Electronic labels can be backed up to the FTP server, TFTP server, or local flash memory. Before
backing up electronic labels to the FTP or TFTP server, ensure that there are reachable routes
between the device and FTP server (or TFTP server).
Procedure
l Run:
backup device elabel [ slot slot-id [ card card-id ] ] filename
Electronic labels are backed up to the flash memory.
l Run:
backup device elabel [ slot slot-id [ card card-id ] ] ftp ftp-server-address
filename username
Electronic labels are backed up to the FTP server.
l Run:
backup device elabel [ slot slot-id [ card card-id ] ] tftp tftp-server-
address filename
Electronic labels are backed up to the TFTP server.
----End
2.3 Resetting a Device
When a device fails to be upgraded or cannot work properly, you may need to reset the device.
11
Context
NOTE
Resetting a device will interrupt services on the device. When a device is not working properly, to prevent
services from being affected, rectify the fault rather than reset the device.
Procedure
Step 1 (Optional) Run:
display device [ slot slot-id ]
The device status is displayed.
Step 2 Run:
reset slot slot-id
The device is reset.
----End
2.4 Enabling Master/Slave Switchover
To implement backup between master and standby switches in a stack with multiple switches,
enable the master/slave switchover function to allow the original standby switch to become the
new master switch.
Context
In a stack containing multiple switches, you can manually perform a switchover between the
master and standby switches during software upgrade or system maintenance. After the master/
slave switchover is complete, the original master switch restarts and joins the stack, and the
original standby switch becomes the new master switch.
Before a master/slave switchover, check whether the stack is ready for a switchover. The master/
slave switchover can be performed only when the stack meets switchover requirements.
Procedure
display switchover state
Information about master and slave switchover is displayed, which helps check whether the stack
meets switchover requirements.
You can perform a master/slave switchover only when the Switchover State field displays Ready.
Step 2 Run:
system-view
Step 3 Run:
slave switchover enable
Master/slave device switchover is enabled.
12
By default, master/slave switchover is enabled.
Step 4 Run:
slave switchover
A master/slave switchover is performed.
----End
2.5 Configuring the CPU Usage Alarm Threshold
You can configure the CPU usage alarm threshold to monitor CPU usage.
Context
When the system has a large number of routes, many CPU resources will be used. This degrades
system performance and results in the delay in processing data or causes a high packet loss rate.
During data processing, if the device can generate an alarm when high CPU usage occurs, you
can effectively monitor CPU usage and optimize system performance to ensure system stability.
l CPU usage alarm threshold
When CPU usage reaches this threshold, the system generates an alarm.
l CPU usage alarm recovery threshold
When CPU usage falls within this threshold, the system generates a clear alarm.
Procedure
display cpu threshold [ slot slot-id ]
The CPU usage configuration is displayed.
Step 2 Run:
system-view
Step 3 Run:
set cpu threshold threshold-value [ restore restore-threshold-value ] [ slot slot-
id ]
The CPU usage alarm threshold and CPU usage alarm recovery threshold are set.
By default, the CPU usage alarm threshold is 95% and the CPU usage alarm recovery threshold
is 75%.
Step 4 Run:
commit
The configuration is committed.
----End
2.6 Configuring the Memory Usage Alarm Threshold
You can configure the memory usage alarm threshold to monitor memory usage.
13
Context
Memory usage is an important indicator to evaluate device performance. A high memory usage
will cause service faults. During data processing, if the device can generate an alarm when high
memory usage occurs, you can effectively monitor memory usage and optimize system
performance to ensure system stability.
l Memory usage alarm threshold
When memory usage reaches this threshold, the system generates an alarm.
l Memory usage alarm recovery threshold
When memory usage falls within this threshold, the system generates a clear alarm.
Procedure
display memory threshold [ slot slot-id ]
The memory usage configuration is displayed.
Step 2 Run:
system-view
Step 3 Run:
set memory threshold threshold-value [ restore restore-threshold-value ] [ slot
slot-id ]
The memory usage alarm threshold and memory usage alarm recovery threshold are set.
By default, the memory usage alarm threshold is 95% and the memory usage alarm recovery
threshold is 75%.
Step 4 Run:
commit
----End
2.7 Configuring the Interval for Updating Power
Consumption Data
You can configure the interval for updating power consumption data to view power consumption
of the device during a period.
Context
The average power consumption of a device is the average power consumption within a period
of time. To obtain real-time power consumption, set a short interval.
You can use the display device power system command to view power consumption data,
including the accumulative power consumption and average power consumption.
14
Procedure
display device power system
The interval for updating power consumption data is displayed.
Step 2 Run:
system-view
Step 3 Run:
set device power manage cycle cycle-id
The interval for updating power consumption data is set.
By default, power consumption data is updated at an internal of 1 hour.
Step 4 Run:
commit
----End
2.8 Configuring the System Resource Mode
You can configure the system resource mode to adjust the allocation of hardware resources.
Context
Services share chip resources. You can properly allocate chip resources to meet different service
requirements.
NOTE
Only the CE5850 supports the configuration of the system resource mode.
Procedure
Step 1 Run:
system-view
display system resource
The system resource mode is displayed.
Step 3 Run:
system resource { large-mac-table | standard | user-defined }
The system resource mode is set.
By default, the standard system resource mode is used.
15
Step 4 Run:
commit
----End
16
3 Energy-Saving Management
About This Chapter
You can configure the energy-saving management function to reduce device power consumption
and save energy.
3.1 Energy-saving Management Overview
As network scale enlarges, device power consumption increases enterprise operating expense.
Energy saving becomes the major concern in network construction. Devices use multiple energy-
saving technologies to reduce power consumption.
3.2 Energy-saving Management Features Supported by the Device
The device supports energy-saving features such as intelligent fan speed adjustment, Energy
Efficient Ethernet (EEE), and automatic laser shutdown (ALS).
3.3 Configuring ALS
The ALS function on an optical module controls laser sending and saves energy.
3.4 Configuring the EEE Function
You can configure the EEE function on the electrical interface to reduce power consumption.
3.5 Configuring an Energy-Saving Mode
You can configure an energy-saving mode for the device to reduce power consumption.
3.6 Configuration Examples
This section provides energy-saving management configuration examples including networking
requirements and configuration roadmap.
Configuration Guide - Device Management 3 Energy-Saving Management
17
3.1 Energy-saving Management Overview
As network scale enlarges, device power consumption increases enterprise operating expense.
Energy saving becomes the major concern in network construction. Devices use multiple energy-
saving technologies to reduce power consumption.
3.2 Energy-saving Management Features Supported by the
Device
The device supports energy-saving features such as intelligent fan speed adjustment, Energy
Efficient Ethernet (EEE), and automatic laser shutdown (ALS).
Intelligent Fan Speed Adjustment
The device adopts the intelligent fan speed adjustment technology to monitor the temperature
of key components. If a sensitive component overheats, the fan speed increases; when the
temperature falls back to its normal range, the fan speed decreases. In this way, the fan module
enables the device to run in normal temperature and reduces power consumption and noise.
ALS
The automatic laser shutdown (ALS) mechanism controls the pulse of the laser of an optical
module by detecting the Loss of Signal (LOS) on an optical interface. The ALS mechanism
protects operators against laser injury and saves energy.
When ALS is disabled, if the optical fiber link fails, data communication is interrupted. However,
the optical interface and the laser of an optical module are enabled. If the laser of an optical
module still sends pulses after data communication is interrupted, energy is wasted and eyes of
operators may be hurt.
When ALS is enabled, if the optical fiber link fails, the software automatically disables the laser
of an optical module from sending pulses on the optical interface after detecting the LOS on the
optical interface. When the faulty optical fiber link is recovered, the software detects that the
LOS of the optical interface is cleared and enables the laser to send pulses.
EEE
Energy Efficient Ethernet (EEE) dynamically adjusts the electrical interface power according
to network traffic volume.
When the EEE function is not configured on the electrical interface, the system provides power
for each interface. Even though an interface is idle, it consumes the same power as working
interfaces. After the EEE function is configured, the system reduces the power on an interface
when the interface is idle and restores the power when the interface starts to transmit data. This
reduces power consumption in the system.
Port Dormancy
In port dormancy mode, the physical layer (PHY) chip on the electrical interface enters the low
energy consumption mode to reduce power consumption. When interfaces are not connected,
18
major data transmission channels of the chip enter the dormancy state to save energy. When
interfaces are connected and traffic on the cable is detected, the PHY chip restores to normal
working state.
Shutting Down Idle Circuits and Components
The device shuts down circuits and components based on their usage to save energy. For
example, when the optical module is unavailable on the interface, the system closes circuits that
are not used. When the optical module is installed, circuits automatically open.
Powering off Redundant Power Modules
The device powers off redundant power modules based on rated power consumption or real-
time power consumption. This does not affect system power supply and saves energy. When the
rated power or real-time power increases, the device automatically powers on redundant power
modules. This ensures stable power supply.
Energy-saving Mode
Besides intelligent fan speed adjustment and ALS, the device saves energy through the energy-
saving mode.
The device supports the following energy-saving modes:
l User-defined mode: Users set the energy-saving mode as service requires.
l Standard mode: Default energy saving technologies are used, for example, intelligent fan
speed adjustment, ALS, port dormancy, EEE, and shutting down idle circuits and
components.
l Basic mode: The basic energy-saving mode uses technologies supported by the standard
mode and allows the device to power off redundant power modules based on rated power
consumption.
l Deep mode: The deep energy-saving mode uses technologies supported by the standard
consumption.
NOTE
The device supports only the standard mode.
3.3 Configuring ALS
The ALS function on an optical module controls laser sending and saves energy.
Pre-configuration Tasks
Before configuring ALS, complete the following task:
l Ensuring that the link layer protocol status on the interfaces is Up
3.3.1 Enabling ALS on an Interface
19
Context
The constraints on ALS are as follows:
l Only optical interfaces support ALS. Electrical interfaces do not support ALS.
l When optical interfaces transmit services unidirectionally, they do not support ALS.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
als enable
ALS is enabled on an interface.
By default, ALS is disabled on an interface.
Step 4 Run:
commit
----End
3.3.2 (Optional) Setting the Restart Mode of the Laser
Context
The laser of an optical module works in automatic restart mode or manual restart mode.
l Automatic restart mode: The laser automatically sends a pulse at an interval to detect
whether a link is restored. After the LOS is cleared, the laser sends pulses and data
communication is recovered.
l Manual restart mode: If the optical fiber link recovers, you must start the laser manually.
Then the laser sends a pulse to detect whether the link is recovered.
Procedure
l Configure automatic restart mode
1. Run:
system-view
2. Run:
interface interface-type interfacenumber
20
3. Run:
als restart mode automatic
The laser of the optical module is configured to work in automatic restart mode.
By default, a laser works in automatic restart mode.
4. Run:
commit
l Configure manual restart mode
1. Run:
system-view
2. Run:
3. Run:
als restart mode manual
The laser of the optical module is configured to work in manual restart mode.
4. Run:
commit
5. (Optional) Run:
als restart
The laser of the optical module is started manually.
NOTE
In manual restart mode, after the optical fiber link recovers, you must start the laser manually. The
laser then sends a pulse to detect whether the link is recovered.
----End
3.3.3 (Optional) Setting the ALS Pulse Interval and Width of the
Laser
Context
The ALS pulse interval refers to the duration in which a laser sends pulses; the ALS pulse width
refers to the period between rising edges of pulses.
A smaller pulse width and a greater pulse interval save more energy but the fiber link recovery
cannot be detected immediately. You can set a proper laser pulse interval and width to ensure
energy conservation, emission deduction, and timely detection of optical fiber link recovery.
Procedure
Step 1 Run:
system-view
21
Step 2 Run:
Step 3 Run:
als restart pulse interval pulse-interval
The ALS pulse interval of the laser is set.
By default, the ALS pulse interval is 100s.
Step 4 Run:
als restart pulse width pulse-width
The ALS pulse width of the laser is set.
By default, the ALS pulse width is 2s.
Step 5 Run:
commit
----End
3.3.4 Checking the Configuration
Procedure
l Run the display als { all | slot slot-id } command to check ALS configurations on the
device.
l Run the display als interface interface-type interface-number command to check ALS
configuration on a specified interface.
----End
3.4 Configuring the EEE Function
You can configure the EEE function on the electrical interface to reduce power consumption.
Context
After the EEE function is configured, the system reduces the power on an interface when the
interface is idle and restores the power when the interface starts to transmit data. This reduces
power consumption in the system.
NOTE
l Only the electrical interface supports the EEE function. The optical interface does not support the EEE
function.
l This function takes effect only after it is configured on both ends of a link.
l The interface must work in auto-negotiation mode.
22
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
undo negotiation disable
The interface is configured to work in auto-negotiation mode.
Step 4 Run:
eee enable
The EEE function is enabled on the interface.
By default, EEE is disabled on an interface.
Step 5 Run:
commit
----End
Checking the Configuration
l Run the display this command in a specified interface view to check whether the EEE
function is enabled on the interface.
3.5 Configuring an Energy-Saving Mode
You can configure an energy-saving mode for the device to reduce power consumption.
Context
The device supports the following energy-saving modes:
l User-defined mode: Users set the energy-saving mode as service requires.
l Standard mode: Default energy saving technologies are used, for example, intelligent fan
speed adjustment, ALS, port dormancy, EEE, and shutting down idle circuits and
components.
l Basic mode: The basic energy-saving mode uses technologies supported by the standard
consumption.
l Deep mode: The deep energy-saving mode uses technologies supported by the standard
consumption.
23
NOTE
The device supports only the standard mode.
Procedure
Step 1 Run:
system-view
Step 2 Run:
set device power manage mode mode
An energy-saving mode is configured for the device.
By default, the standard energy-saving mode is used.
Step 3 Run:
commit
----End
l Run the display device power system command to check the energy-saving mode of the
device.
This section provides energy-saving management configuration examples including networking
requirements and configuration roadmap.
3.6.1 Example for Configuring ALS
Networking Requirements
As shown in Figure 3-1, 10GE1/0/1 on SwitchA connects to 10GE1/0/1 on SwitchB through
the optical fiber.
When a link fails, the laser on the optical module is required to automatically stop sending pulses
and recover pulse sending after the link is recovered.
Figure 3-1 Networking diagram for configuring ALS
SwitchA SwitchB
10GE1/0/1 10GE1/0/1
24
Configuration Roadmap
The configuration roadmap is as follows:
1. Enable ALS on the interface so that the laser automatically stops sending pulses when a
link fails.
2. Set the restart mode of the laser to automatic restart mode so that the laser sends pulses
again after the link is recovered.
Procedure
Step 1 Configure ALS on the interface and the restart mode of the laser.
# Enable ALS on 10GE1/0/1 of SwitchA and set the restart mode of the laser to automatic restart.
<HUAWEI> system-view
[~HUAWEI] sysname SwitchA
[~HUAWEI] commit
[~SwitchA] interface 10ge 1/0/1
[~SwitchA-10GE1/0/1] als enable
[~SwitchA-10GE1/0/1] als restart mode automatic
[~SwitchA-10GE1/0/1] commit
# Enable ALS on 10GE1/0/1 of SwitchB and set the restart mode of the laser to automatic restart.
[~HUAWEI] sysname SwitchB
[~HUAWEI] commit
[~SwitchB] interface 10ge 1/0/1
[~SwitchB-10GE1/0/1] als enable
[~SwitchB-10GE1/0/1] als restart mode automatic
[~SwitchB-10GE1/0/1] commit
Step 2 Verify the configuration.
# Check ALS configurations on interfaces of SwitchA and SwitchB.
<SwitchA> display als interface 10ge 1/0/1
--------------------------------------------------------------------------------
Interface ALS Status Laser Status Restart Mode Interval(s) Widt
h(s)
--------------------------------------------------------------------------------
10GE1/0/1 Enable on Auto 100 2

--------------------------------------------------------------------------------
<SwitchB> display als interface 10ge 1/0/1
--------------------------------------------------------------------------------
Interface ALS Status Laser Status Restart Mode Interval(s) Widt
h(s)
--------------------------------------------------------------------------------
10GE1/0/1 Enable on Auto 100 2

--------------------------------------------------------------------------------
----End
Configuration file
l Configuration file of SwitchA
#
sysname SwitchA
#
interface 10GE1/0/1
25
als enable
#
return
l Configuration file of SwitchB
#
sysname SwitchB
#
interface 10GE1/0/1
als enable
#
return
26
4 Information Center Configuration
About This Chapter
The information center works as the information hub. It records system running information in
real time, which helps the network administrator and developers to monitor network operation
and analyze network faults.
4.1 Introduction to the Information Center
The information center records information generated by each module during device running,
including logs, traps, and debugging messages.
4.2 Information Center Features Supported by the Device
The information center outputs logs, traps, and debugging messages to different destinations
based on output rules.
4.3 Default Configuration
This section describes default parameter settings of the information center.
4.4 Configuring Log Output
Logs of a specific module can be output to the log buffer, log file, console, terminal, or log host.
4.5 Configuring Trap Output
Traps of a specific module can be output to the trap buffer, log file, console, terminal, log host,
or SNMP agent.
4.6 Configuring Debugging Message Output
Debugging messages of a specific module can be output to the console and terminal.
4.7 Maintaining the Information Center
This section describes how to maintain the information center.
This section provides several configuration examples of the information center, covering
networking requirements, configuration notes, and configuration roadmap.
Configuration Guide - Device Management 4 Information Center Configuration
27
4.1 Introduction to the Information Center
The information center records information generated by each module during device running,
including logs, traps, and debugging messages.
During routine maintenance or emergency troubleshooting, users or administrators want to learn
information generated during device running. You can configure the information center to
classify and filter information based on information types and severities so that information can
be flexibly output to different destinations such as the console, user terminal, and log host. By
doing this, users or network administrators can collect device information from different
destinations so that they can easily monitor the device running status and locate faults.
4.2 Information Center Features Supported by the Device
The information center outputs logs, traps, and debugging messages to different destinations
based on output rules.
Table 4-1 lists applicable scenarios of logs, traps, and debugging messages.
Table 4-1 Information center applicable scenarios
Informati
on Type
Applicable Scenario Output Direction
Log To monitor the device running
status, you can configure the device
to output logs to different
destinations. You can learn device
running status in real time by
collecting logs generated by the
device.
Logs can be output to the console,
remote terminal, log host, log buffer,
and log file.
Trap When an exception or a fault occurs
on the device, you can configure the
device to output traps to different
destinations. You can learn device
running status and locate the fault in
real time by collecting traps
generated by the device.
Traps can be output to the console,
remote terminal, log host, trap buffer,
SNMP agent, and log file.
Debugging
message
To learn internal tracing
information or debug the device,
you can configure the device to
output debugging messages to
different destinations.
Debugging messages can be output to
the console and remote terminal.

This section describes default parameter settings of the information center.
28
Table 4-2 Default parameter settings of the information center
Parameter Default Setting
Information center Enabled
Maximum number of logs in the log buffer 512
Maximum number of traps in the trap buffer 256
Log file size 8 MB
Maximum number of log files that can be
saved
200
Log host IP address None
Timestamp format date

Default Output Rules of Information Channels
Default output rules define information modules to which different types of information can be
output, lowest information severity, and information channels. See Table 4-3.
Table 4-3 Default output rules
Output
Channe
l
Module
Enable
d to
Output
Inform
ation
Log Trap Debugging
Message
Status Lowest
Output
Severit
y
Status Lowest
Output
Severit
y
Status Lowest
Output
Severit
y
0
(console
)
default
(all
modules
)
Enabled warning Enabled debuggi
ng
Enabled debuggi
ng
1
(remote
terminal)
default
(all
modules
)
Enabled warning Enabled debuggi
ng
Enabled debuggi
ng
2 (log
host)
default
(all
modules
)
Enabled informat
ional
Enabled debuggi
ng
Disabled debuggi
ng
3 (trap
buffer)
default
(all
modules
)
Disabled informat
ional
Enabled debuggi
ng
Disabled debuggi
ng
29
Output
Channe
l
Module
Enable
d to
Output
Inform
ation
Log Trap Debugging
Message
Status Lowest
Output
Severit
y
Status Lowest
Output
Severit
y
Status Lowest
Output
Severit
y
4 (log
buffer)
default
(all
modules
)
Enabled warning Disabled debuggi
ng
Disabled debuggi
ng
5
(SNMP
agent)
default
(all
modules
)
Disabled debuggi
ng
Enabled debuggi
ng
Disabled debuggi
ng
6
(channel
6)
default
(all
modules
)
Enabled debuggi
ng
Enabled debuggi
ng
Disabled debuggi
ng
7
(channel
7)
default
(all
modules
)
Enabled debuggi
ng
Enabled debuggi
ng
Disabled debuggi
ng
8
(channel
8)
default
(all
modules
)
Enabled debuggi
ng
Enabled debuggi
ng
Disabled debuggi
ng
9
(channel
9)
default
(all
modules
)
Enabled debuggi
ng
Enabled debuggi
ng
Disabled debuggi
ng

4.4 Configuring Log Output
Logs of a specific module can be output to the log buffer, log file, console, terminal, or log host.
Before enabling log output, complete the following task:
Starting the Switch
Configuration Process
Table 4-4 lists the configuration process for enabling log output.
30
Table 4-4 Configuration process for enabling log output
No. Configuration
Task
Description Remarks
1 4.4.1 Enabling the
Information
Center
You can configure the information
center only after the information center
is enabled.
By default, the information center is
enabled.
Steps 2 to 4 are
optional and can be
performed in any
sequence.
2 4.4.2 (Optional)
Naming an
Information
Channel
You can rename channels, which
facilitates memorization and usage.
3 4.4.3 (Optional)
Configuring Log
Filtering
If some logs are unnecessary,
configure the Switch not to output
these logs.
4 4.4.4 (Optional)
Setting the
Timestamp
Format of Logs
To adjust the time format and time
precision for information output,
configure the timestamp.
5 4.4.6 Configuring
the Device to
Output Logs to the
Log Buffer
To view logs in the log buffer,
configure the Switch to output logs to
the log buffer.
Steps 5 to 9 can be
configured in any
sequence. You can
configure the device
to output logs to one
or more destinations
according to your
needs.
6 4.4.7 Configuring
the Device to
Output Logs to a
Log File
After logs are output to a log file, you
can download the log file anytime to
monitor device running based on the
logs.
7 4.4.8 Configuring
the Device to
Output Logs to the
Console
After logs are output to the console,
you can view logs on the console (host
from which you can log in to the
Switch through the console interface)
to monitor device running.
8 4.4.9 Configuring
the Device to
Output Logs to a
Terminal
After logs are output to a user terminal,
you can view logs on the user terminal
(host from which you log in to the
Switch through STelnet) to monitor
device running.
9 4.4.10 Configuring
the Device to
Output Logs to a
Log Host
After configuring the Switch to output
logs to a log host, you can view logs
saved on the log host to monitor device
running.

31
4.4.1 Enabling the Information Center
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.4.2 (Optional) Naming an Information Channel
Context
You can rename channels, which facilitates memorization and usage.
NOTE
Channel names must be unique. It is recommended that channel names represent channel functions.
The following lists default channel names.
Table 4-5 Default channel names
Channel Number Default Channel Name
0 console
1 monitor
2 loghost
3 trapbuffer
4 logbuffer
5 snmpagent
6 channel6
7 channel7
8 channel8
9 channel9

32
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center channel channel-number name channel-name
A name is configured for the information channel with the specified number.
Step 3 Run:
commit
----End
4.4.3 (Optional) Configuring Log Filtering
Context
If some logs are unnecessary, configure the device not to output these logs. When the filtering
function is enabled, the information center does not send the specified logs that satisfy the
filtering condition to any channel. As a result, all output directions cannot receive the specified
logs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center filter-id { id | bymodule-alias modname alias }
The filtering function is configured for specified logs.
Step 3 Run:
commit
----End
4.4.4 (Optional) Setting the Timestamp Format of Logs
Context
To adjust the time format and time precision for information output, configure the timestamp.
Procedure
Step 1 Run:
system-view
33
Step 2 Run:
info-center timestamp log { { date | format-date | short-date } [ precision-time
{ second | tenth-second | millisecond } ] | boot | none }
The timestamp format of logs is configured.
By default, the timestamp format of logs is date.
Step 3 Run:
commit
----End
4.4.5 (Optional) Enabling the Output of the Statistics About
Repeatedly Generated Logs
Context
On the system, service modules generate logs and control the volume of generated logs. The
information center processes the received logs.
In some scenarios, service modules, such as ARP and VRRP, generate a large number of repeated
logs within a short period. In this situation, you can enable the output of the statistics about
repeatedly generated logs to protect the information center against the impact of the large log
volume.
NOTE
Logs that are generated consecutively and with identical log IDs and parameters can be regarded as
repeatedly generated logs.
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center statistic-suppress enable
The output of the statistics about repeatedly generated logs is enabled.
By default, the output of the statistics about repeatedly generated logs is enabled.
Step 3 Run:
commit
----End
34
4.4.6 Configuring the Device to Output Logs to the Log Buffer
Context
To view logs in the log buffer, configure the device to output logs to the log buffer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center logbuffer
The device is enabled to output information to the log buffer.
By default, the device is enabled to output logs to the log buffer.
Step 3 Run:
info-center logbuffer channel { channel-number | channel-name } [ size logbuffer-
size ]
The channel used by the device to output logs to the log buffer is specified.
By default, the device uses channel 4 to output logs to the log buffer.
Step 4 Run:
info-center source { module-name | default } channel { channel-number | channel-
name } log { state { off | on } | level severity }
*
A rule for outputting logs to a channel is set.
By default, channel 4 is enabled to output logs and the lowest log severity is warning.
info-center logbuffer size logbuffer-size [ channel { channel-number | channel-
name } ]
The maximum number of logs in the log buffer is set.
By default, a log buffer can store a maximum of 512 logs.
Step 6 Run:
commit
----End
4.4.7 Configuring the Device to Output Logs to a Log File
Context
After logs are output to a log file, you can view the log file anytime to monitor device running
based on the logs.
35
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center logfile channel { channel-number | channel-name }
A channel through which logs are output to a log file is specified.
By default, the device uses channel 9 to output logs to a log file.
Step 3 Run:
*
By default, channel 9 is enabled to output logs and the lowest log severity is debugging.
info-center logfile size size
The log file size is set.
By default, the log file size is 8 MB.
NOTE
l If the size of a log file generated on the device exceeds the configured log file size, the system
decompresses the log file into a zip file.
l You can run the save logfile command to manually save logs in the log file buffer to a log file.
info-center max-logfile-number filenumbers
The maximum number of log files that can be saved is set.
By default, a maximum of 200 log files can be saved.
If the number of log files generated on the Switch exceeds the limit, the system deletes the oldest
log file.
Step 6 Run:
commit
----End
4.4.8 Configuring the Device to Output Logs to the Console
Context
After logs are output to the console, you can view logs on the console (host from which you can
log in to the device through the console interface) to monitor device running.
36
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center console channel { channel-number | channel-name }
A channel through which logs are output to the console is specified.
By default, the device uses channel 0 to output logs to the console.
Step 3 Run:
*
Step 4 Run:
commit
Step 5 Run:
quit
Return to the user view.
Step 6 Run:
terminal monitor
Display of logs, traps, and debugging message output is enabled on the user terminal.
By default, terminal display is enabled.
Step 7 Run:
terminal logging
Log display is enabled on the user terminal.
By default, log display is disabled on the user terminal.
----End
4.4.9 Configuring the Device to Output Logs to a Terminal
Context
After logs are output to a user terminal, you can view logs on the user terminal (host from which
you log in to the device through Telnet) to monitor device running.
Procedure
Step 1 Run:
system-view
37
Step 2 Run:
info-center monitor channel { channel-number | channel-name }
A channel through which logs are output to a user terminal is specified.
By default, the Switch uses channel 1 to output logs to a user terminal.
Step 3 Run:
*
Step 4 Run:
commit
Step 5 Run:
quit
Step 6 Run:
terminal monitor
Step 7 Run:
terminal logging
Log display is enabled on the user terminal.
By default, log display is disabled on the user terminal.
----End
4.4.10 Configuring the Device to Output Logs to a Log Host
Context
After configuring the device to output logs to a log host, you can view logs saved on the log host
There is a reachable route between the device and the log host.
Procedure
Step 1 Run:
system-view
38
Step 2 Run:
info-center loghost ip-address [ channel { channel-number | channel-name } | vpn-
instance vpn-insname | facility local-number | port port-number | level info-level
| { local-time | utc } ]
*
The device is configured to output logs to a log host.
By default, the device does not output logs to a log host.
The device supports a maximum of eight log hosts to implement backup among log hosts.
Step 3 Run:
*
By default, channel 2 is enabled to output logs and the lowest log severity is informational.
info-center loghost source interface-type interface-number
The source interface used by the device to send logs to a log host is specified.
By default, the source interface is the interface that sends logs.
After the source interface is specified, the log host determines the device that sends messages.
The log host then can easily retrieve received messages.
Step 5 Run:
commit
----End
Procedure
l Run the display info-center channel [ channel-number | channel-name ] command to view
the channel configuration.
l Run the display logbuffer command to check logs recorded in the log buffer.
l Run the display logfile file-name [ offset ] command to check the log file.
----End
4.5 Configuring Trap Output
Traps of a specific module can be output to the trap buffer, log file, console, terminal, log host,
or SNMP agent.
Before enabling trap output, complete the following task:
39
Starting the Switch
Table 4-6 lists the configuration process for enabling trap output.
Table 4-6 Configuration process for enabling trap output
No. Name Description Remarks
Information Center
You can configure the
information center only
after the information
center is enabled.
By default, the
information center is
enabled.
Steps 2 to 4 are optional
and can be performed in
any sequence.
2 4.5.2 (Optional) Naming
an Information Channel
You can rename channels,
which facilitates
memorization and usage.
3 4.5.3 (Optional)
Configuring Trap
Filtering
If some traps are
unnecessary, configure the
Switch not to output these
traps.
4 4.5.4 (Optional) Setting
the Timestamp Format
of Traps
To adjust the time format
and time precision for
information output,
5 4.5.5 Configuring the
Device to Output Traps
to the Trap Buffer
To view traps in the trap
buffer, configure the
Switch to output traps to
the trap buffer.
Steps 5 to 10 can be
configured in any
sequence. You can
configure the device to
output traps to one or more
destinations according to
your needs.
to a Log File
After traps are output to a
log file, you can download
the log file anytime to
view traps generated by
the Switch to monitor
device running.
to the Console
After traps are output to
the console, you can view
traps on the console (host
from which you can log in
to the Switch through the
console interface) to
monitor device running.
40
No. Name Description Remarks
to a Terminal
After traps are output to a
user terminal, you can
view traps on the user
terminal (host from which
you log in to the Switch
through STelnet) to
monitor device running.
to a Log Host
After configuring the
Switch to output traps to a
log host, you can view
traps saved on the log host
to an SNMP Agent
When an exception or a
fault occurs on the
Switch, the network
administrator wants to
learn device running. You
can configure the Switch
to output traps to an NMS
server so that the network
administrator can monitor
the Switch in real time and
locate faults immediately.
Before configuring the
Switch to output traps to
an NMS server, configure
the Switch to output traps
to an SNMP agent. Then
the SNMP agent sends
traps to the NMS server.

Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center enable
Step 3 Run:
commit
41
----End
Context
NOTE
0 console
1 monitor
2 loghost
3 trapbuffer
4 logbuffer
5 snmpagent
6 channel6
7 channel7
8 channel8
9 channel9

Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
commit
----End
42
4.5.3 (Optional) Configuring Trap Filtering
Context
If some traps are unnecessary, configure the device not to output these traps. When the filtering
function is enabled, the information center does not send the specified traps that satisfy the
filtering condition to any channel. As a result, all output directions cannot receive the specified
traps.
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center filter-id { id | bymodule-alias modname alias }
The filtering function is configured for specified traps.
Step 3 Run:
commit
----End
4.5.4 (Optional) Setting the Timestamp Format of Traps
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center timestamp trap { { date | format-date | short-date } [ precision-time
{ second | tenth-second | millisecond } ] | boot | none }
The timestamp format of traps is set.
By default, the timestamp format of traps is date.
Step 3 Run:
commit
----End
43
4.5.5 Configuring the Device to Output Traps to the Trap Buffer
Context
To view traps in the trap buffer, configure the device to output traps to the trap buffer.
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center trapbuffer
The device is enabled to output traps to the trap buffer.
By default, the device is enabled to output traps to the trap buffer.
Step 3 Run:
info-center trapbuffer channel { channel-number | channel-name } [ size trapbuffer-
size ]
The channel used by the device to output traps to the trap buffer is specified.
By default, the device uses channel 3 to output traps to the trap buffer.
Step 4 Run:
name } trap { state { off | on } | level severity }
*
A rule for outputting traps to a channel is set.
By default, channel 3 is enabled to output traps and the lowest severity is debugging.
info-center trapbuffer size trapbuffer-size [ channel { channel-number | channel-
name } ]
The maximum number of traps in the trap buffer is set.
By default, the trap buffer can store a maximum of 256 traps.
Step 6 Run:
commit
----End
4.5.6 Configuring the Device to Output Traps to a Log File
Context
After traps are output to a log file, you can view the log file anytime to monitor device running
based on the traps.
44
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center logfile channel { channel-number | channel-name }
A channel through which traps are output to a log file is specified.
By default, the device uses channel 9 to output traps to a log file.
Step 3 Run:
*
info-center logfile size size
The log file size is set.
By default, the log file size is 8 MB.
NOTE
l If the size of a log file generated on the device exceeds the configured log file size, the system
decompresses the log file into a zip file.
l You can run the save logfile command to manually save traps in the log file buffer to a log file.
info-center max-logfile-number filenumbers
The maximum number of log files that can be saved is set.
By default, a maximum of 200 log files can be saved.
If the number of log files generated on the Switch exceeds the limit, the system deletes the oldest
log file.
Step 6 Run:
commit
----End
4.5.7 Configuring the Device to Output Traps to the Console
Context
After traps are output to the console, you can view traps on the console (host from which you
can log in to the device through the console interface) to monitor device running.
45
Procedure
Step 1 Run:
system-view
Step 2 Run:
A channel through which traps are output to the console is specified.
By default, the device uses channel 0 to output traps to the console.
Step 3 Run:
*
Step 4 Run:
commit
Step 5 Run:
quit
Step 6 Run:
terminal monitor
Step 7 Run:
terminal alarm
Traps display is enabled on the user terminal.
By default, traps display is disabled on the user terminal.
----End
4.5.8 Configuring the Device to Output Traps to a Terminal
Context
After traps are output to a user terminal, you can view traps on the user terminal (host from
which you log in to the device through Telnet) to monitor device running.
Procedure
Step 1 Run:
system-view
46
Step 2 Run:
A channel through which traps are output to a user terminal is specified.
By default, the device uses channel 1 to output traps to a user terminal.
Step 3 Run:
*
Step 4 Run:
commit
Step 5 Run:
quit
Step 6 Run:
terminal monitor
Step 7 Run:
terminal alarm
Traps display is enabled on the user terminal.
By default, traps display is disabled on the user terminal.
----End
4.5.9 Configuring the Device to Output Traps to a Log Host
Context
After configuring the device to output traps to a log host, you can view traps saved on the log
host to monitor device running.
There is a reachable route between the device and the log host.
Procedure
Step 1 Run:
system-view
47
Step 2 Run:
info-center loghost ip-address [ channel { channel-number | channel-name } | vpn-
instance vpn-insname | facility local-number | port port-number | level info-level
| { local-time | utc } ]
*
The device is configured to output traps to a log host.
By default, the device does not output traps to a log host.
The device supports a maximum of eight log hosts to implement backup among log hosts.
Step 3 Run:
*
info-center loghost source interface-type interface-number
The source interface used by the device to send logs to a log host is specified.
By default, the source interface is the interface that sends logs.
After the source interface is specified, the log host determines the device that sends messages.
The log host then can easily retrieve received messages.
Step 5 Run:
commit
----End
4.5.10 Configuring the Device to Output Traps to an SNMP Agent
Context
When an exception or a fault occurs on the device, the network administrator needs to learn the
device running status. You can configure the device to output traps to an NMS server so that the
network administrator can monitor the device in real time and locate faults immediately. Before
configuring the device to output traps to an NMS server, configure the device to output traps to
an SNMP agent. Then the SNMP agent sends traps to the NMS server.
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center snmp channel { channel-number | channel-name }
The channel used by the device to output traps to an SNMP agent is specified.
48
By default, the device uses channel 5 to output traps to an SNMP agent.
Step 3 Run:
*
Step 4 Run:
snmp-agent
The SNMP agent function is enabled.
By default, the SNMP agent function is disabled.
The SNMP agent can work properly and receive traps only when the SNMP agent function is
enabled.
NOTE
For details on how to configure the SNMP agent, see SNMP Configuration in the CloudEngine 6800&5800
Series Switches Configuration Guide - Network Management.
Step 5 Run:
commit
----End
Procedure
l Run the display logfile file-name [ offset ] command to check the log file.
l Run the display trapbuffer [ size value ] command to check traps recorded in the trap
buffer.
----End
4.6 Configuring Debugging Message Output
Debugging messages of a specific module can be output to the console and terminal.
Before enabling debugging message output, complete the following task:
Starting the Switch
49
CAUTION
Debugging occupies CPU resources on the device, affecting system running. After debugging,
run the undo debugging all command to disable it immediately.
Table 4-8 lists the configuration process for enabling debugging message output.
Table 4-8 Configuration process for enabling debugging message output
No. Configuration Task Description Remarks
Information Center
You can configure the
information center only
after the information
center is enabled.
By default, the
information center is
enabled.
Steps 2 and 3 are optional
and can be performed in
any sequence.
2 4.6.2 (Optional) Naming
an Information Channel
You can rename channels,
which facilitates
memorization and usage.
3 4.6.3 (Optional) Setting
the Timestamp Format
of Debugging Messages
To adjust the time format
and time precision for
information output,
Device to Output
Debugging Messages to
the Console
After debugging
messages are output to the
console, you can view
debugging messages on
the console (host from
which you can log in to the
through the console
interface) to monitor
device running.
Steps 4 to 5 can be
performed in any
sequence. You can
configure the device to
output debugging
messages to one or more
destinations according to
your needs.
Device to Output
Debugging Messages to
the Terminal
After debugging
messages are output to a
user terminal, you can
view debugging messages
on the user terminal (host
from which you log in to
the Switch through
STelnet) to monitor
device running.

50
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center enable
Step 3 Run:
commit
----End
Context
NOTE
0 console
1 monitor
2 loghost
3 trapbuffer
4 logbuffer
5 snmpagent
6 channel6
7 channel7
8 channel8
9 channel9

51
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
commit
----End
4.6.3 (Optional) Setting the Timestamp Format of Debugging
Messages
Context
Procedure
Step 1 Run:
system-view
Step 2 Run:
info-center timestamp debugging { { date | format-date | short-date } [ precision-
time { second | tenth-second | millisecond } ] | boot | none }
The timestamp format of debugging messages is set.
By default, the timestamp format of debugging messages is date.
Step 3 Run:
commit
----End
4.6.4 Configuring the Device to Output Debugging Messages to the
Console
Context
After debugging messages are output to the console, you can view debugging messages on the
console (host from which you can log in to the device through the console interface) to monitor
device running.
52
Procedure
Step 1 Run:
system-view
Step 2 Run:
A channel used by the device to output debugging messages to the console is specified.
By default, the device uses channel 0 to output debugging messages to the console.
Step 3 Run:
name } debug { state { off | on } | level severity }
*
A rule for outputting debugging messages to a channel is set.
By default, channel 0 is enabled to output debugging messages and the lowest severity is
debugging.
Step 4 Run:
commit
Step 5 Run:
quit
Step 6 Run:
terminal monitor
Step 7 Run:
terminal debugging
Debugging message display is enabled on the user terminal.
By default, debugging message display is disabled on the user terminal.
----End
4.6.5 Configuring the Device to Output Debugging Messages to the
Terminal
Context
After debugging messages are output to a user terminal, you can view debugging messages on
the user terminal (host from which you log in to the device through STelnet) to monitor device
running.
53
Procedure
Step 1 Run:
system-view
Step 2 Run:
A channel used by the device to output debugging messages to a user terminal is specified.
By default, the device uses channel 1 to output debugging messages to a user terminal.
Step 3 Run:
name } debug { state { off | on } | level severity }
*
A rule for outputting debugging messages to a channel is set.
By default, channel 1 is enabled to output debugging messages and the lowest severity is
debugging.
Step 4 Run:
commit
Step 5 Run:
quit
Step 6 Run:
terminal monitor
Step 7 Run:
terminal debugging
Debugging message display is enabled on the user terminal.
By default, debugging message display is disabled on the user terminal.
----End
Procedure
----End
54
4.7 Maintaining the Information Center
This section describes how to maintain the information center.
4.7.1 Clearing Statistics
Context
CAUTION
Statistics of the information center cannot be restored after you clear them. Exercise caution
when running the commands.
Procedure
l To clear the statistics of the information center, run the reset info-center statistics
command in the user view.
l To clear the statistics in the log buffer, run the reset logbuffer command in the user view.
l To clear the statistics in the trap buffer, run the reset trapbuffer command in the user view.
----End
4.7.2 Monitoring the Information Center
Procedure
l Run the display info-center command to view output configuration of the information
center.
l Run the display info-center statistics command to view statistics of the information center.
l Run the display logbuffer command to view logs recorded in the log buffer.
l Run the display logfile file-name [ offset ] command to view the log file.
l Run the display trapbuffer [ size value ] command to view traps recorded in the trap buffer.
----End
This section provides several configuration examples of the information center, covering
networking requirements, configuration notes, and configuration roadmap.
55
4.8.1 Example for Outputting Logs to the Log File
As shown in Figure 4-1, SwitchA connects to the FTP server through the network. There is a
reachable route between SwitchA and the FTP server. The network administrator wants to use
the FTP server to view logs generated by SwitchA and learn operations on SwitchA.
NOTE
FTP cannot secure secure file transfer. SFTP is recommended on networks that require high security.
Figure 4-1 Networking diagram for outputting logs to the log file
FTP Server
SwitchA
Network
10.1.1.1/16 10.2.1.1/16

1. Enable the information center.
2. Configure a channel and a rule for outputting logs to a log file so that logs are saved in the
log file.
3. Configure SwitchA to transfer the log file to the FTP server so that the network
administrator can use the FTP server to view logs generated by SwitchA.
Procedure
Step 1 Enable the information center.
[~HUAWEI] commit
[~SwitchA] info-center enable
[~SwitchA] commit
Step 2 Configure a channel and a rule for outputting logs to a log file.
# Configure a channel for outputting logs to a log file.
[~SwitchA] info-center logfile channel channel6
[~SwitchA] commit
NOTE
By default, channel 9 is used to send logs to a log file. If the default setting is used, skip this step.
# Configure a rule for outputting logs to a log file.
[~SwitchA] info-center source default channel channel6 log level warning
[~SwitchA] commit
56
Step 3 Configure SwitchA to transfer the log file to the FTP server.
# Log in to the FTP server with user name user1 and password pwd123.
<SwitchA> ftp 10.1.1.1
Trying 10.1.1.1 ...
Press CTRL + K to abort
Connected to 10.1.1.1.
220 VRPV8 FTP service ready.
User(10.1.1.1:(none)):user1
331 Password required for user1.
Enter password:
230 User logged in.
# Configure SwitchA to transfer the log file to the FTP server.
[ftp] put flash:/logfile/log.log
200 Port command okay.
150 Opening ASCII mode data connection for /log.log.
226 Transfer complete.
\ 100% [***********]
FTP: 7521956 byte(s) send in 3.1784917300 second(s) 2311.409Kbyte(s)/sec.
[ftp] quit
# View information recorded by the channel.
<SwitchA> display info-center
Information Center:enabled
Log host:
Console:
channel number : 0, channel name : console
Monitor:
channel number : 1, channel name : monitor
SNMP Agent:
channel number : 5, channel name : snmpagent
Log buffer:
enabled,max buffer size 1024, current buffer size 512,
current messages 18, channel number : 4, channel name : logbuffer
dropped messages 0, overwritten messages 0
Trap buffer:
current messages 36, channel number:3, channel name:trapbuffer
Logfile:
channel number : 6, channel name : channel6, language : English
Information timestamp setting:
log - date, trap - date, debug - date millisecond
# View the received log file on the FTP server. The configuration details are not mentioned here.
----End
Configuration Files
#
sysname SwitchA
#
info-center source default channel 6 log level warning
info-center logfile channel 6
#
return
57
4.8.2 Example for Outputting Logs to a Log Host
As shown in Figure 4-2, SwitchA connects to four log hosts. Log hosts are required to have
reliability and receive logs of different types and severities so that the network administrator can
monitor logs generated by different modules on SwitchA.
Figure 4-2 Networking diagram for outputting logs to a log host
VLANIF100
172.16.0.1/24
10GE1/0/1
SwitchA
Server1
Server 2
Server 4
Server 3
10.1.1.2/24 10.1.1.1/24
10.2.1.1/24
10.2.1.2/24

2. Configure SwitchA to send logs of notification generated by the ARP module to Server1,
and specify Server3 as the backup of Server1. Configure SwitchA to send logs of warning
generated by the AAA module to Server2, and specify Server4 as the backup of Server2.
3. Configure the log host on the server so that the network administrator can receive logs
generated by SwitchA on the log host.
Procedure
[~HUAWEI] commit
[~SwitchA] commit
Step 2 Configure a channel and a rule for outputting logs to a log host.
# Name a channel.
[~SwitchA] info-center channel 6 name loghost1
[~SwitchA] info-center channel 7 name loghost2
[~SwitchA] commit
# Configure a channel for outputting logs to a log host.
[~SwitchA] info-center loghost 10.1.1.1 channel loghost1
58
[~SwitchA] commit
# Configure a rule for outputting logs to a log host.
[~SwitchA] info-center source arp channel loghost1 log level notification
[~SwitchA] info-center source aaa channel loghost2 log level warning
[~SwitchA] commit
Step 3 Specify the source interface for sending logs.
# Specify the source interface for sending logs.
[~SwitchA] info-center loghost source vlanif 100
[~SwitchA] commit
Step 4 Configure the log host on the server.
The Switch can generate many logs, which may exceed the limited storage space of the
Switch. To address this problem, configure a log host to store all the logs.
The log host can run the Unix or Linux operating system or run third-party log software. For
details about the configuration procedure, see the relevant documentation.
# View the configured lost host.
Log host:
10.1.1.1, channel number 6, channel name loghost1,
language English , host facility local7
Console:
Monitor:
SNMP Agent:
channel number : 5, channel name : snmpagent
Log buffer:
Trap buffer:
logfile:
----End
Configuration Files
#
sysname SwitchA
#
info-center channel 6 name loghost1
59
info-center channel 7 name loghost2
info-center source arp channel 6 log level notification
info-center source aaa channel 7 log level warning
info-center loghost source Vlanif100
info-center loghost 10.1.1.1 channel 6
#
return
4.8.3 Example for Outputting Traps to the SNMP Agent
As shown in Figure 4-3, SwitchA connects to the NMS station. There is a reachable route
between SwitchA and the NMS station. The network administrator wants to view traps generated
by SwitchA on the NMS station to monitor device running and locate faults.
Figure 4-3 Networking diagram for outputting traps to the SNMP agent
NM Station SwitchA
10.1.1.2/24 10.1.1.1/24

2. Configure a channel and a rule for outputting traps to the SNMP agent so that the SNMP
agent can receive traps generated by SwitchA.
3. Configure SwitchA to output traps to the NMS station so that the NMS station can receive
traps generated by SwitchA.
Procedure
[~HUAWEI] commit
[~SwitchA] commit
Step 2 Configure a channel and a rule for outputting traps to the SNMP agent.
# Configure a channel for outputting traps to the SNMP agent.
[~SwitchA] info-center snmp channel channel7
[~SwitchA] commit
# Configure a rule for outputting traps to the SNMP agent.
60
[~SwitchA] info-center source arp channel channel7 trap level informational state
on
[~SwitchA] commit
NOTE
By default, the device uses the SNMP agent to output traps of all modules.
Step 3 Configure the SNMP agent to output traps to the NMS station.
# Enable the SNMP agent and set the SNMP version to SNMPv2c.
[~SwitchA] snmp-agent sys-info version v2c
[~SwitchA] commit
# Configure the trap function.
[~SwitchA] snmp-agent trap enable
[~SwitchA] snmp-agent community write adminnms123
[~SwitchA] snmp-agent target-host trap address udp-domain 10.1.1.1 params
securityname public
[~SwitchA] commit
[~SwitchA] quit
# View the output configuration of the information center.
Log host:
Console:
Monitor:
SNMP Agent:
channel number : 7, channel name : channel7
Log buffer:
Trap buffer:
logfile:
# View the channel used by the SNMP agent to output traps.
<SwitchA> display info-center channel 7
channel number:7, channel name:channel7
MODU_ID NAME ENABLE LOG_LEVEL ENABLE TRAP_LEVEL ENABLE
DEBUG_LEVEL
ffffffff default Y debugging Y debugging N debugging
00000859 ARP Y debugging Y informational N debugging
# View traps output to the NMS station by the SNMP agent.
<SwitchA> display snmp-agent target-host
Target-host NO. 1
---------------------------------------------------------------------------
Host-name : -
IP-address : 10.1.1.1
Source interface : -
VPN instance : -
Security name : %$%$>Oh`"sfiHSgR>SLWkM`3%tkb%$%$
61
Port : 162
Type : trap
Version : v1
Level : No authentication and privacy
NMS type : NMS
With ext-vb : No
Notification filter profile name : -
---------------------------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
snmp-agent
snmp-agent local-engineid 800007DB030A0B0C000003
#
snmp-agent sys-info version v2c
snmp-agent community write cipher %@%@0L%%$pI<#6z,oF3zc&U0,ULCJWa^>)*=-)r[4#-
p^+
25h[RMjYqfYysx,A5sw$F_SuNXk_VS%@%@
snmp-agent target-host trap address udp-domain 10.1.1.1 params securityname
ciph
er %$%$>Oh`"sfiHSgR>SLWkM`3%tkb%$%$
#
snmp-agent trap enable
#
info-center source arp channel 7 trap level informational
info-center snmp channel 7
#
return
4.8.4 Example for Outputting Debugging Messages to the Console
As shown in Figure 4-4, the PC connects to SwitchA through a console interface. It is required
that debugging messages of the ARP module be displayed on the PC.
Figure 4-4 Networking diagram for outputting debugging messages to the console
SwitchA
Console
PC

2. Configure a channel and a rule for outputting debugging messages to the console so that
the console can receive debugging messages generated by SwitchA.
62
3. Enable terminal display so that users can use the terminal to view debugging messages
generated by SwitchA.
Procedure
[~HUAWEI] commit
[~SwitchA] commit
Step 2 Configure a channel and a rule for outputting debugging messages to the console.
# Configure a channel for outputting debugging messages to the console.
[~SwitchA] info-center console channel console
[~SwitchA] commit
# Configure a rule for outputting debugging messages to the console.
[~SwitchA] info-center source arp channel console debug level debugging state on
[~SwitchA] commit
[~SwitchA] quit
Step 3 Enable terminal display.
<SwitchA> terminal monitor
Info: Current terminal monitor is on.
<SwitchA> terminal debugging
Info: Current terminal debugging is on.
Step 4 Debug the ARP module.
<SwitchA> debugging arp packet
# View the channel used by the Console to output debugging messages.
<SwitchA> display info-center channel 0
channel number:0, channel name:console
MODU_ID NAME ENABLE LOG_LEVEL ENABLE TRAP_LEVEL ENABLE
DEBUG_LEVEL
ffffffff default Y warning Y debugging Y debugging
00000859 ARP Y warning Y debugging Y debugging
----End
Configuration Files
#
sysname SwitchA
#
info-center source arp channel 0
#
return
63
5 Fault Management Configuration
About This Chapter
The fault management configuration allows users to collect fault information and locate faults
quickly and efficiently at the NMS side.
5.1 Introduction to Fault Management
By using fault management, users can efficiently manage and report alarms in a centralized
manner.
This section describes default parameter settings of the device.
5.3 Configuring Alarm Management
Alarm management includes setting alarm severities, and enabling alarm reporting delay.
5.4 Maintenance
This section describes how to monitor and clear alarms.
This section describes fault management configurations based on the configuration flowchart,
including networking requirements, configuration roadmap, and configuration procedure.
Configuration Guide - Device Management 5 Fault Management Configuration
64
5.1 Introduction to Fault Management
By using fault management, users can efficiently manage and report alarms in a centralized
manner.
With the rapid growth in network scales and complexity, more and more network configurations
and applied features are required. When a module on a device is faulty, a great number of alarms
may be generated on one or more devices. The alarms, however, may be lost when being sent
to the NMS due to limited capability of handling alarms on the devices or the NMS. As a result,
certain needed alarms cannot be displayed, which inconveniences network management. To
collect valid fault information on the NMS, configure the alarm severity, alarm reporting delay
function to efficiently manage and report alarms in a centralized manner.
This section describes default parameter settings of the device.
Table 5-1 Default configuration of fault management
Alarm reporting delay function Enabled

5.3 Configuring Alarm Management
Alarm management includes setting alarm severities, and enabling alarm reporting delay.
Before configuring alarm management, complete the following task:
Powering on the device and ensuring a successful self-check
5.3.1 Setting the Alarm Severity
Context
The system defines default alarm severity for each alarm. Users can change the alarm severity.
When receiving alarms reported by a device, the NMS can configure filtering rules to display
only alarms of a specified severity.
Alarm severities are defined as follows:
l Critical: indicates that a fault affecting services has occurred and it must be rectified
immediately. For example, a critical alarm is generated to notify users that a managed object
fails to work and the fault must be rectified.
l Major: indicates that services are being affected and related measures need to be taken
urgently. For example, a major alarm is generated to notify users that performance of a
65
managed object seriously degrades and all the capabilities of the managed object must be
restored.
l Minor: indicates that a fault occurs but does not affect services. To avoid more serious
faults that affect services, related measures must be taken.
l Warning: indicates that a potential or impending service-affecting fault is detected before
any significant effect has been felt. Take corrective actions to diagnose and rectify the fault.
Procedure
Step 1 Run:
system-view
Step 2 Run:
alarm
The alarm view is displayed.
display alarm information [ name alarm-name ]
The alarm severity is displayed.
Step 4 Run:
alarm alarm-name severity severity
The alarm severity is changed.
The system has defined default alarm severity for each alarm.
Step 5 Run:
commit
----End
5.3.2 Configuring the Alarm Reporting Delay Function
Context
When an alarm is reported repeatedly, users cannot locate faults in an efficient manner. After
the alarm reporting delay function is enabled and the delay is configured, a large number of
invalid alarms are prevented from being reported.
After the alarm reporting delay function is enabled,
l If no clear alarm is generated during the period, the alarm is reported to the NMS when the
period expires.
l If a clear alarm is generated during this period, the alarm and its clear alarm are both deleted
from the alarm queue and will not be reported to the NMS.
Procedure
Step 1 Run:
66
system-view
Step 2 Run:
alarm
Step 3 Run:
delay-suppression enable
The alarm reporting delay function is enabled.
By default, the alarm reporting delay function is enabled.
suppression alarm alarm-name { cause-period cause-seconds | clear-period clear-
seconds }
The delay in reporting alarms is configured.
The system defines a default delay in reporting alarms.
NOTE
l To set the delay in reporting an active alarm, select the cause-period parameter. To set the delay in reporting
a clear alarm, select the clear-period parameter.
l To view the default delay in reporting alarms, run the undo suppression alarm alarm-name { cause-
period | clear-period } and display alarm information [ name alarm-name ] commands in sequence.
Step 5 Run:
commit
----End
Context
l Run the display alarm information [ name alarm-name ] command to view the specified
alarm configuration.
l Run the display this command in the alarm view to view the alarm configuration.
5.4 Maintenance
This section describes how to monitor and clear alarms.
67
5.4.1 Clearing Alarms
Context
CAUTION
The cleared alarm statistics cannot be restored. Confirm the action before you run the command.
Procedure
l Clears hardware alarms.
Run:
clear device alarm hardware { all | index index | slot slot-id } { no-trap
| send-trap }
Hardware alarms are cleared.
l Clearing active alarms or alarm statistics.
1. Run:
system-view
2. Run:
alarm
3. Clearing alarms
Run:
clear alarm active { all | sequence-number sequence-number }
Active alarms are cleared.
Run:
reset statistics [ name alarm-name ]
The alarm statistics are cleared.
----End
5.4.2 Monitoring Alarms
Procedure
l Run:
display alarm active [ verbose ]
Active alarms are displayed.
l Run:
display alarm information [ name alarm-name ]
The alarm configuration is displayed.
l Run:
display alarm statistics [ name alarm-name ]
68
The alarm statistics are displayed.
l Run:
display device alarm hardware [ slot slot-id ]
The hardware alarms on the device are displayed.
l Run:
display alarm history [ verbose ]
The historical alarms are displayed.
----End
This section describes fault management configurations based on the configuration flowchart,
including networking requirements, configuration roadmap, and configuration procedure.
5.5.1 Example for Configuring Alarm Management
As shown in Figure 5-1, the route between the device and the NMS is reachable. Users want to
view alarms generated by the device on the NMS in real time. Users must monitor the LinkDown
alarm to ensure the normal interconnection of the device.
Figure 5-1 Networking for configuring alarm management
NM Station Switch
11.1.1.2/24 10.1.1.1/24
Network
1. Configure the alarm severity to critical, allowing users to monitor LinkDown alarms on
the NMS in real time based on the alarm filtering rules.s
2. Configure the alarm reporting delay function to prevent repetitive or flapping alarms from
being reported to the NMS.
Procedure
Step 1 Configure an SNMPv3 user and an NMS host.
[~HUAWEI] snmp-agent
[~HUAWEI] snmp-agent sys-info version v3
[~HUAWEI] snmp-agent group v3 group1 privacy
[~HUAWEI] snmp-agent usm-user v3 user1 group1 authentication-mode md5 pwd123456
privacy-mode des56 pri123456
[~HUAWEI] snmp-agent target-host host-name nms trap address udp-domain 10.1.1.1
69
params securityname user1 v3 privacy
[~HUAWEI] snmp-agent trap enable
[~HUAWEI] commit
Step 2 Set the severity for the linkDown alarm to critical.
[~HUAWEI] alarm
[~HUAWEI-alarm] alarm linkDown severity critical
[~HUAWEI-alarm] commit
Step 3 Enable the alarm reporting delay function.
[~HUAWEI-alarm] delay-suppression enable
[~HUAWEI-alarm] suppression alarm linkDown cause-period 5
[~HUAWEI-alarm] suppression alarm linkDown clear-period 15
[~HUAWEI-alarm] commit
NOTE
By default, the alarm reporting delay function is enabled.
# Run the display alarm information command to view the alarm configuration.
<HUAWEI> display alarm information name linkDown
--------------------------------------------------------------------------------
Feature : IFNET
AlarmName : linkDown
AlarmId : 0x8520003
Severity : Critical
Cause Suppress Time : 5
Clear Suppress Time : 15
--------------------------------------------------------------------------------
----End
Configuration Files
l Configuration file of the Switch
#
snmp-agent
snmp-agent local-engineid 800007DB0300259E957C20
snmp-agent sys-info version v3
snmp-agent group v3 group1 privacy
snmp-agent target-host host-name nms trap address udp-domain 10.1.1.1 params
sec
urityname user1 v3 privacy
snmp-agent usm-user v3 user1 group1 authentication-mode md5 %$%$Gmt[/c
{_mJqJJa00
s%J#,5,#%$%$ privacy-mode des56 %$%$@s`f)1@[WD3t^_M+)B+S,90'%$%$
#
snmp-agent trap enable
#
alarm
suppression alarm linkDown cause-period 5
suppression alarm linkDown clear-period 15
alarm linkDown severity Critical
#
return
70
6 USB-based Deployment Configuration
About This Chapter
USB-based deployment simplifies the deployment process, reduces the deployment costs, and
relieves users from software commissioning.
6.1 USB-based Deployment Overview
In site deployment, USB-based deployment allows you to save the upgrade files in a USB flash
drive, connect the USB flash drive to a device, and download the files from the USB flash drive
to complete the automatic upgrade and configuration.
6.2 Making an Index File
Before USB-based deployment, you must make an index file.
6.3 Configuring USB-based Deployment
To use USB-based deployment, you must create a USB-based deployment index file, copy the
index file to the root directory of a USB flash drive, copy deployment files to the directory
specified by the index file, and insert the USB flash drive into a device to start the USB-based
deployment process.
6.4 (Optional) Disabling the USB-based Deployment Function
6.5 Configuration Example
This topic provides a USB-based deployment example. The configuration example includes the
networking requirements, configuration roadmap and configuration procedure.
Configuration Guide - Device Management 6 USB-based Deployment Configuration
71
6.1 USB-based Deployment Overview
In site deployment, USB-based deployment allows you to save the upgrade files in a USB flash
drive, connect the USB flash drive to a device, and download the files from the USB flash drive
to complete the automatic upgrade and configuration.
As the network expands, more and more network devices are used and software commissioning
costs increase. USB-based deployment simplifies device deployment and reduces deployment
costs. This function enables devices to be upgraded or configured automatically.
6.2 Making an Index File
Before USB-based deployment, you must make an index file.
Procedure of Making an Index File
To edit the index file on the PC, perform the following operations:
1. Create a text file.
2. Edit the file based on the index file format.
3. Rename the file as smart_config.ini.
4. Copy the smart_config.ini file to the root directory of the USB flash drive.
Index File Format
The index file format is as follows:
BEGIN DC
[GLOBAL CONFIG]
SN=
EMS_ONLINE_STATE=
UPGRADEMODE=
[DEVICEn DESCRIPTION]
OPTION=
ESN=
MAC=
DIRECTORY=
SYSTEM-SOFTWARE=
SYSTEM-CONFIG=
SYSTEM-PAT=
END DC
Table 6-1 Fields in the index file
Field Description
BEGIN DC Start tag of the index file. This field cannot be modified.
GLOBAL CONFIG Start tag of the global configuration. This field cannot be
modified.
72
Field Description
SN Data change time in the format
YearMonthDay.HourMinuteSecond.
For example, the value 20110628.080910 indicates
2011-06-28 08:09:10.
NOTE
The SN field is a USB-based deployment flag. A device has a
default USB-based deployment flag. If the smart_config.ini file
exists in the USB flash drive, the device checks whether the default
USB-based deployment flag and the SN value in the
smart_config.ini file are the same. If they are different, the USB-
based deployment process is triggered. If the deployment
succeeds, the value of the default USB-based deployment flag on
the device is changed to the SN value in the smart_config.ini file.
EMS_ONLINE_STATE Whether the NMS is online, indicating whether a device
registers with the NMS after being deployed:
l YES: The device registers with the NMS.
l NO: The device does not register with the NMS.
The default value is NO.
NOTE
This field is optional. If this field does not exist or is empty, the
default value is used.
UPGRADEMODE Upgrade mode:
l AUTO: automatic mode
l MANU: manual mode
l DFT: production mode, which is used in production,
commissioning, and testing environment. In this mode,
only the system software version is upgraded.
The default value is AUTO.
NOTE
DEVICEn DESCRIPTION Start tag of the file description. n indicates the device
number and starts from 0.
OPTION Whether file information is valid:
l OK: valid
l NOK: invalid
The default value is OK.
NOTE
73
Field Description
ESN Serial number of a device. If the value of this field is
DEFAULT, the index file is applicable to all devices.
Otherwise, the index file is applicable to a specific device.
The default value is DEFAULT.
NOTE
MAC Device MAC address, in XXXX-XXXX-XXXX format. X
is a hexadecimal number. If the value of this field is
DEFAULT, the index file is applicable to all devices.
Otherwise, the index file is applicable to a specific device.
NOTE
DIRECTORY Path for storing deployment files.
l If the value is DEFAULT, the deployment files are
stored in the root directory of the USB flash drive.
l If the value is /abc, the deployment files are stored in
the abc directory.
NOTE
SYSTEM-SOFTWARE System software file with file name extension .cc.
NOTE
This field is optional.
SYSTEM-CONFIG Configuration file with file name extension .cfg or .zip.
NOTE
If this field has a value, the MAC field cannot be empty or default.
SYSTEM-PAT Patch file with file name extension .pat.
NOTE
END DC End tag of the index file.

Examples
Example 1
You need to create an index file for upgrading one device, and the requirements are as follows:
l Data is changed at 08:09:10 on June 28, 2011.
74
l The device does not register with the NMS.
l The device MAC address is 0018-0303-1234.
l The system software system-software.cc, the configuration file system-config.zip, and
the patch file system-pat.pat are stored in the root directory of the USB flash drive.
The index file that meets the preceding requirements is as follows:
BEGIN DC
[GLOBAL CONFIG]
SN=20110628.080910
EMS_ONLINE_STATE=NO
UPGRADEMODE=AUTO
[DEVICE0 DESCRIPTION]
OPTION=OK
ESN=DEFAULT
MAC=0018-0303-1234
DIRECTORY=DEFAULT
SYSTEM-SOFTWARE=system-software.cc
SYSTEM-CONFIG=system-config.zip
SYSTEM-PAT=system-pat.pat
END DC
Example 2
You need to create an index file for upgrading multiple devices to the same software version,
and the requirements are as follows:
l The system software system-software.cc is stored in the root directory of the USB flash
drive.
BEGIN DC
[GLOBAL CONFIG]
SN=20110628.080910
EMS_ONLINE_STATE=NO
UPGRADEMODE=AUTO
OPTION=OK
ESN=DEFAULT
MAC=DEFAULT
DIRECTORY=DEFAULT
END DC
Example 3
You need to create an index file for two devices with different description information, and the
requirements are as follows:
l The MAC address of the first device is 0018-0303-1234.
l The MAC address of the second device is 0018-0303-5678.
l The system software system-software.cc and the configuration file system-config.zip are
stored in the root directory of the USB flash drive. The first device does not need to load
the configuration file while the second device must load the configuration file.
75
BEGIN DC
[GLOBAL CONFIG]
SN=20110628.080910
EMS_ONLINE_STATE=NO
UPGRADEMODE=AUTO
OPTION=OK
ESN=DEFAULT
MAC=0018-0303-1234
DIRECTORY=DEFAULT
OPTION=OK
ESN=DEFAULT
MAC=0018-0303-5678
DIRECTORY=DEFAULT
SYSTEM-CONFIG=system-config.zip
END DC
6.3 Configuring USB-based Deployment
To use USB-based deployment, you must create a USB-based deployment index file, copy the
index file to the root directory of a USB flash drive, copy deployment files to the directory
specified by the index file, and insert the USB flash drive into a device to start the USB-based
deployment process.
Background Information
When using USB-based deployment, pay attention to the following points:
l The file system format of a USB flash drive must be FAT32 and its interface must be
standard USB2.0.
l Use a USB flash drive that is certificated by Huawei to ensure the compatibility between
the USB flash drive and devices.
l To write data to a USB flash drive, disable the write-protection function.
l Before USB-based deployment, ensure that the device can start properly and has sufficient
space for saving deployment files.
l Only one USB flash drive can be inserted into a device each time.
l USB-based deployment files include the index file, system software, configuration file, and
patch file. The index file is mandatory. At least one type of other files must exist.
l Do not power off the device during file copy; otherwise, the upgrade fails or even the device
cannot start.
l Do not remove the USB flash drive before the upgrade is complete; otherwise, the data in
the USB flash drive may be damaged.
l USB-based deployment cannot be used to deploy multiple stack devices simultaneously.
l The device has been powered on and the self-check is successful.
76
Procedure
1. Create an index file.
For details, see 6.2 Making an Index File.
2. Save the index file in the root directory of a USB flash drive, and copy deployment files to
the specified directory.
The DIRECTORY field in the index file specifies the path for storing deployment files.
l If the value is DEFAULT, the deployment files are stored in the root directory of the
USB flash drive.
l If the value is /abc, the deployment files are stored in the abc directory.
3. Insert the USB flash drive into a device to start the deployment process.
Based on the description information in the smart_config.ini file, the system first copies
deployment files from the USB flash drive to the default storage media (If the system failed
to copy files, the deployment indicator is steady red and the deployment failed), set the
system software and configuration file as files to be loaded during next system startup, and
automatically restarts.
l Observe the ACT indicator to determine the USB-based deployment status:
Steady green: USB-based deployment is successful.
Blinking green: USB-based deployment is in progress.
Steady red: USB-based deployment failed.
NOTE
Verify that USB-based deployment is successful and remove the USB flash drive. The USB-based
deployment process is complete.
l View the USB-based deployment reports to learn about the deployment result.
After the deployment is complete, the system generates the usbload_verify.txt or
usbload_error.txt files, containing the success information and error information
respectively. The report files are stored in the root directory of the USB flash drive.
The content and format of the usbload_verify.txt and usbload_error.txt files are as
follows:
===================================================
Time : 2011-10-29 10:30:50
MAC Address : 0e-0f-22-01-02-03
System Name : CE6850
Description : USB-based deployed succeeded.
===================================================
Table 6-2 USB-based deployment report description
Item Description
Time Date and time when the information is
generated.
MAC Address MAC address of a device.
System Name Device model.
77
Item Description
Description USB-based deployment report
information.

6.4 (Optional) Disabling the USB-based Deployment
Function
Context
By default, the USB-based deployment function is enabled on a device, and the device can be
upgraded once a qualified USB flash drive is connected to the device. To enhance device security
and avoid service interruption caused by unnecessary version upgrades, disable the USB-based
deployment. After the USB-based deployment function is disabled, the device cannot be
upgraded using any qualified USB flash drive.
Procedure
Step 1 Run:
system-view
The system view is displayed:
Step 2 Run:
set device usb-deployment disable
The USB-based deployment function is disabled.
By default, the USB-based deployment function is enabled.
Step 3 Run:
commit
----End
6.5 Configuration Example
This topic provides a USB-based deployment example. The configuration example includes the
networking requirements, configuration roadmap and configuration procedure.
6.5.1 Example for Configuring USB-based Deployment
A user must upgrade two devices without the software commissioning engineers being onsite.
The requirements are as follows:
l The device can start properly and has sufficient space for saving deployment files.
78
l The devices must be upgraded at 2011-06-28 08:09:10.
l The MAC address of the first device is 0018-0303-1234. The name of the system software
is V100R001C00.cc. No configuration file needs to be loaded.
l The MAC address of the second device is 0018-0303-5678. The name of the system
software is V100R001C00.cc. The configuration file config.zip must be loaded.
1. Create the index file smart_config.ini.
2. Save the smart_config.ini file in the root directory of a USB flash drive, and copy
deployment files to the directory specified by the index file.
3. Insert the USB flash drive into a device to start the deployment process.
Procedure
Step 1 Create the index file smart_config.ini.
# Create an index file and name it smart_config.ini. The content and format of the index file
are as follows:
BEGIN DC
[GLOBAL CONFIG]
SN=20110628.080910
EMS_ONLINE_STATE=NO
UPGRADEMODE=AUTO
OPTION=OK
MAC=0018-0303-1234
DIRECTORY=DEFAULT
SYSTEM-SOFTWARE=V100R001C00.cc
OPTION=OK
MAC=0018-0303-5678
DIRECTORY=DEFAULT
SYSTEM-SOFTWARE=V100R001C00.cc
SYSTEM-CONFIG=config.zip
END DC
Step 2 Save the smart_config.ini file in the root directory of a USB flash drive, and copy the
V100R001C00.cc and config.zip files to the directory specified by the index file.
Step 3 Insert the USB flash drive into the two devices in sequence.
Step 4 Observe the deployment indicator to monitor the USB-based deployment process:
l If any deployment file is not found, the deployment indicator is off.
l If deployment files are found but not valid, the deployment failed and the deployment
indicator is steady red.
l If deployment files are found and valid, the USB-based deployment starts and the deployment
indicator blinks green.
Based on the description information in the smart_config.ini file, the system first copies
deployment files from the USB flash drive to the default storage media (If the system failed
to copy files, the deployment indicator is steady red and the deployment failed), set the system
software and configuration file as files to be loaded during next system startup, and
automatically restarts.
79
l After the device restarts, the system checks the deployment status. If the deployment indicator
is steady green, USB-based deployment succeeds.If the deployment indicator is steady red,
USB-based deployment fails.
NOTE
Verify that USB-based deployment is successful and remove the USB flash drive. The USB-based
deployment process is complete.
l After the deployment is complete, the system generates the usbload_verify.txt or
usbload_error.txt files, containing the success information and error information
respectively. The report files are stored in the root directory of the USB flash drive.
----End
80
7 Mirroring Configuration
About This Chapter
Packet mirroring copies packets to a specified destination so that you can ayalyze packets to
monitor the network and rectify faults.
NOTE
The terms mirrored port, port mirroring, traffic mirroring, and mirroing in this manual are mentioned only
to describe the product's function of communication error or failure detection, and do not involve collection
or processing of any personal information or communication data of users.
7.1 Packet Mirroring Overview
Packet mirroring copies the packets on a mirrored port (source port) to an observing port
(destination port).
7.2 Packet Mirroring Features Supported by the Device
The device supports port mirroring and traffic mirroring.
7.3 Configuring Local Port Mirroring
After local port mirroring is configured, packets passing through mirrored ports are copied to a
local monitoring device for analysis and monitoring.
7.4 Configuring Remote Port Mirroring
After remote port mirroring is configured, packets passing through mirrored ports are copied to
a remote monitoring device for analysis and monitoring.
7.5 Configuring Local Traffic Mirroring
After local traffic mirroring is configured, specified packets passing through mirrored ports are
copied to a local monitoring device for analysis and monitoring.
7.6 Configuring Remote Traffic Mirroring
After remote traffic mirroring is configured, specified packets passing through mirrored ports
are copied to a remote monitoring device for analysis and monitoring.
This section provides several configuration examples of packet mirroring, including network
requirements, configuration roadmap, and configuration procedures.
Configuration Guide - Device Management 7 Mirroring Configuration
81
7.1 Packet Mirroring Overview
Packet mirroring copies the packets on a mirrored port (source port) to an observing port
(destination port).
During network maintenance, maintenance personnel need to capture and analyze packets (for
example, when there are suspicious attack packets). However, these operations always affect
packet forwarding.
Packet mirroring copies packets on a mirrored port to an observing port so that you can analyze
packets copied to the destination port by a monitoring device to monitor the network and rectify
faults.
Concepts
l Mirrored port
All the packets or packets matching the traffic classification rule passing through a mirrored
port are copied to an observing port.
l Observing port
An observing port is connected to a monitoring device and is used to export the packets
copied from a mirrored port.
7.2 Packet Mirroring Features Supported by the Device
The device supports port mirroring and traffic mirroring.
Mirroring Specifications
l A maximum of eight observing ports can be configured on the switch, and only one can be
used at one time. An observing port can mirror both incoming and outgoing traffic.
l The switch can mirror packets on multiple ports to one observing port.
l A port cannot be configured as both a mirrored port and an observing port. An Ethernet or
Eth-Trunk port can be configured as a mirrored port. An Eth-Trunk member port cannot
be configured as an observing port.
l In a stack, physical member interfaces do not support inter-chassis mirroring; the mirrored
port and physical member interface that functions as the observing port must be on the same
device.
l If the mirrored port is an access port, the outgoing packets mirrored to an observing port
carry VLAN tags, different from original packets.
l The following configurations for outgoing traffic do not take effect for mirrored traffic:
Configure an ACL in which the rule is deny.
Configure traffic policing.
Configure WRED profiles.
Configure the traffic shaping rate.
Configure the queue scheduling mode.
Outgoing packets discarded on the mirrored port are still mirrored to the observing port.
82
Port Mirroring
A packet passing through a mirrored port is copied and then sent to a specified observing port
for analysis and monitoring, as shown in Figure 7-1.
Figure 7-1 Networking diagram of port mirroring
Observing
port
Monitoring
device
Mirrored
port
Mirrored
port
Packet flow
Copied packet flow
Port

Port mirroring can be performed as follows:
l Inbound: mirroring the packets that are received by the mirrored port
l Outbound: mirroring the packets that are sent by the mirrored port
l Bidirectional: mirroring the packets that are received and sent by the mirrored port
Port mirroring is classified into local port mirroring and remote port mirroring:
l In local port mirroring, a monitoring device is directly connected to an observing port, as
shown in Figure 7-2.
Figure 7-2 Networking diagram of local port mirroring
Mirrored port
Observing port
Packet flow
Copied packet flow
Monitoring
device
Host Switch
l In remote port mirroring, the monitoring device and the observing port are connected
through a Layer 2 or Layer 3 network.
Remote switched port analyzer (RSPAN): The device encapsulates packets passing
through mirrored ports into VLAN packets, and the observing port broadcasts the
VLAN packets in the RSPAN VLAN to forward packets to the monitoring device, as
83
Figure 7-3 Networking diagram of Layer 2 RSPAN
SwitchA
Monitoring
device
SwitchB SwitchC
Host
Mirrored port
Observing port
Packet flow
Copied packet flow
Encapsulated Remote SPAN (ERSPAN): The device encapsulates mirrored packets
passing through mirrored ports into Generic Routing Encapsulation (GRE) packets and
forwards the GRE packets to the monitoring device through a Layer 3 IP network, as
NOTE
In ERSPAN mode, the device cannot decapsulate ERSPAN packets.
Figure 7-4 Networking diagram of Layer 3 ERSPAN
SwitchA
Monitoring
device
SwitchC
Host
IP network
Mirrored port
Observing port
Packet flow
Copied packet flow
Traffic Mirroring
Traffic mirroring is used to copy specified packets passing through a mirrored port to the
observing port for analysis and monitoring. In traffic mirroring, traffic policies containing the
traffic behavior are applied to mirrored ports. If packets passing through a mirrored port match
the traffic classification rule, the packets are copied to the observing port, as shown in Figure
7-5.
84
Figure 7-5 Schematic diagram of traffic mirroring
Port
Traffic classifier
Mirrored
port
Mirrored
port
Observing
port
Monitoring
device
Packet flow
Copied packet flow
Similar to port mirroring, traffic mirroring is also classified into local traffic mirroring and
remote traffic mirroring.
7.3 Configuring Local Port Mirroring
After local port mirroring is configured, packets passing through mirrored ports are copied to a
local monitoring device for analysis and monitoring.
Before configuring local port mirroring, complete the following task:
Ensuring that the link layer protocol status of ports is Up
7.3.1 Configuring a Local Observing Port
Context
In local mirroring, the monitoring device is directly connected to the observing port.
Procedure
Step 1 Run:
system-view
Step 2 Run:
observe-port [ observe-port-index ] interface interface-type interface-number
A local observing port is configured.
By default, no local observing port is configured.
85
Step 3 Run:
commit
----End
7.3.2 Configuring a Mirrored Port
Context
A mirrored port can be an Ethernet port or an Eth-Trunk port.
NOTE
l If an Eth-Trunk is configured as a mirrored port, its member ports cannot be configured as mirrored ports.
l If a member port of an Eth-Trunk is configured as a mirrored port, the Eth-Trunk cannot be configured as
a mirrored port.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
port-mirroring observe-port observe-port-index { both | inbound | outbound }
A mirrored port is configured.
In the preceding command, observe-port-index specifies an observing port index. The value of
this parameter must be the same as the value set in 7.3.1 Configuring a Local Observing
Port.
NOTE
To improve system performance, cancel the port mirroring configuration when you do not need to monitor
packets.
Step 4 Run:
commit
----End
Procedure
l Run the display observe-port command to check the observing port.
86
l Run the display port-mirroring command to check the port mirroring configuration.
----End
7.4 Configuring Remote Port Mirroring
After remote port mirroring is configured, packets passing through mirrored ports are copied to
a remote monitoring device for analysis and monitoring.
Before configuring remote port mirroring, complete the following tasks:
l Ensuring that the observing port can communicate with the monitoring device on a Layer
2 or Layer 3 network
7.4.1 Configuring a Remote Observing Port
Context
In remote mirroring, the monitoring device and the observing port are connected over a Layer
2 or Layer 3 network. Remote mirroring is classified into the following types:
l Layer 2 remote mirroring: The device encapsulates mirrored packets into VLAN packets
so that the mirrored packets can be transmitted to the remote monitoring device over a
Layer 2 network.
l Layer 3 remote mirroring: The device encapsulates mirrored packets into GRE packets so
that the mirrored packets can be transmitted to the remote monitoring device over a Layer
3 network.
Procedure
Step 1 Run:
system-view
Step 2 Configure a remote observing port.
l Run:
vlan vlan-id
A remote observing port is configured for Layer 2 remote mirroring.
l Run:
destination-ip dest-ip-address source-ip source-ip-address [ dscp dscp-value |
vlan vlan-id ]
*
By default, no remote observing port is configured.
Step 3 Run:
commit
87
----End
7.4.2 Configuring a Mirrored Port
Context
A mirrored port can be an Ethernet port or an Eth-Trunk port.
NOTE
l If an Eth-Trunk is configured as a mirrored port, its member ports cannot be configured as mirrored ports.
l If a member port of an Eth-Trunk is configured as a mirrored port, the Eth-Trunk cannot be configured as
a mirrored port.
Procedure
Step 1 Run:
system-view
Step 2 Run:
Step 3 Run:
port-mirroring observe-port observe-port-index { both | inbound | outbound }
A mirrored port is configured.
this parameter must be the same as the value set in 7.4.1 Configuring a Remote Observing
Port.
NOTE
The mirrored port cannot be added to the RSPAN VLAN.
To improve system performance, cancel the port mirroring configuration when you do not need to monitor
packets.
Step 4 Run:
commit
----End
Procedure
l Run the display port-mirroring command to check the port mirroring configuration.
----End
88
7.5 Configuring Local Traffic Mirroring
After local traffic mirroring is configured, specified packets passing through mirrored ports are
copied to a local monitoring device for analysis and monitoring.
Before configuring local traffic mirroring, complete the following task:
Ensuring that the link layer protocol status of ports is Up
7.5.1 Configuring a Local Observing Port
Context
In local mirroring, the monitoring device is directly connected to the observing port.
Procedure
Step 1 Run:
system-view
Step 2 Run:
A local observing port is configured.
By default, no local observing port is configured.
Step 3 Run:
commit
----End
7.5.2 Configuring a Traffic Classifier
Context
Configure complex traffic classification by selecting proper traffic classification rules. For
details, see Configuring a Traffic Classifier in the CloudEngine 6800&5800 Series Switches
Configuration Guide - QoS.
7.5.3 Configuring a Traffic Behavior
Context
By configuring the traffic behavior, the device mirrors all the packets matching traffic
classification rules to the observing interface.
89
Procedure
Step 1 Run:
system-view
Step 2 Run:
traffic behavior behavior-name
A traffic behavior is configured and its view is displayed.
Step 3 Run:
mirroring observe-port observe-port-index
Traffic matching the rules is mirrored to the specified observing port.
this parameter must be the same as the value set in 7.5.1 Configuring a Local Observing
Port.
Step 4 Run:
commit
----End
7.5.4 Configuring a Traffic Policy
Procedure
Step 1 Run:
system-view
Step 2 Run:
traffic policy policy-name
A traffic policy is created and its view is displayed.
Step 3 Run:
classifier classifier-name behavior behavior-name
The traffic policy is associated with the traffic classifier and the traffic behavior containing traffic
mirroring.
In the preceding command, classifier-name specifies a traffic classifier. The value of this
parameter must be the same as the value set in 7.5.2 Configuring a Traffic Classifier. The
behavior-name parameter specifies a traffic behavior. The value of this parameter must be the
same as the value set in 7.5.3 Configuring a Traffic Behavior.
Step 4 Run:
commit
----End
90
7.5.5 Applying a Traffic Policy
Context
You can apply a traffic policy bound to traffic behaviors and traffic classifiers to the system,
interface, or VLAN. For details, see Applying the Traffic Policy in the CloudEngine 6800&5800
Series Switches Configuration Guide - QoS.
Procedure
l Run the display traffic behavior [ behavior-name ] command to check the traffic behavior
configuration.
l Run the display traffic classifier [ classifier-name ] command to check the traffic classifier
configuration.
l Run the display traffic policy [ policy-name [ classifier classifier-name ] ] command to
check the traffic policy configuration.
l Run the display traffic-policy applied-record [ policy-name ] command to check the
application record of a specified mirroring policy.
----End
7.6 Configuring Remote Traffic Mirroring
After remote traffic mirroring is configured, specified packets passing through mirrored ports
are copied to a remote monitoring device for analysis and monitoring.
Before configuring remote traffic mirroring, complete the following tasks:
l Ensuring that the observing port can communicate with the monitoring device on a Layer
2 or Layer 3 network
7.6.1 Configuring a Remote Observing Port
Context
In remote mirroring, the monitoring device and the observing port are connected over a Layer
2 or Layer 3 network. Remote mirroring is classified into the following types:
l Layer 2 remote mirroring: The device encapsulates mirrored packets into VLAN packets
so that the mirrored packets can be transmitted to the remote monitoring device over a
Layer 2 network.
l Layer 3 remote mirroring: The device encapsulates mirrored packets into GRE packets so
that the mirrored packets can be transmitted to the remote monitoring device over a Layer
3 network.
91
Procedure
Step 1 Run:
system-view
l Run:
vlan vlan-id
l Run:
destination-ip dest-ip-address source-ip source-ip-address [ dscp dscp-value |
vlan vlan-id ]
*
By default, no remote observing port is configured.
Step 3 Run:
commit
----End
7.6.2 Configuring a Traffic Classifier
Context
Configure complex traffic classification by selecting proper traffic classification rules. For
details, see Configuring a Traffic Classifier in the CloudEngine 6800&5800 Series Switches
Configuration Guide - QoS.
7.6.3 Configuring a Traffic Behavior
Context
By configuring the traffic behavior, the device mirrors all the packets matching traffic
classification rules to the observing interface.
Procedure
Step 1 Run:
system-view
Step 2 Run:
traffic behavior behavior-name
A traffic behavior is configured and its view is displayed.
92
Step 3 Run:
mirroring observe-port observe-port-index
Traffic matching the rules is mirrored to the specified observing port.
this parameter must be the same as the value set in 7.6.1 Configuring a Remote Observing
Port.
Step 4 Run:
commit
----End
7.6.4 Configuring a Traffic Policy
Procedure
Step 1 Run:
system-view
Step 2 Run:
traffic policy policy-name
A traffic policy is created and its view is displayed.
Step 3 Run:
classifier classifier-name behavior behavior-name
The traffic policy is associated with the traffic classifier and the traffic behavior containing traffic
mirroring.
In the preceding command, classifier-name specifies a traffic classifier. The value of this
parameter must be the same as the value set in 7.6.2 Configuring a Traffic Classifier. The
behavior-name parameter specifies a traffic behavior. The value of this parameter must be the
same as the value set in 7.6.3 Configuring a Traffic Behavior.
Step 4 Run:
commit
----End
7.6.5 Applying a Traffic Policy
Context
You can apply a traffic policy bound to traffic behaviors and traffic classifiers to the system,
interface, or VLAN. For details, see Applying the Traffic Policy in the CloudEngine 6800&5800
Series Switches Configuration Guide - QoS.
93
Procedure
l Run the display traffic behavior [ behavior-name ] command to check the traffic behavior
configuration.
l Run the display traffic classifier [ classifier-name ] command to check the traffic classifier
configuration.
l Run the display traffic policy [ policy-name [ classifier classifier-name ] ] command to
check the traffic policy configuration.
l Run the display traffic-policy applied-record [ policy-name ] command to check the
application record of a specified mirroring policy.
----End
This section provides several configuration examples of packet mirroring, including network
requirements, configuration roadmap, and configuration procedures.
7.7.1 Example for Configuring Local Port Mirroring
As shown in Figure 7-6, HostA is connected to 10GE1/0/1 on SwitchA, and Server is directly
connected to 10GE1/0/2 on SwitchA.
Users want to use the monitoring device (Server) to monitor packets sent from HostA.
Figure 7-6 Networking diagram of local port mirroring
10GE1/0/2
SwitchA HostA
10GE1/0/1
Server
1. Configure 10GE1/0/2 on SwitchA as the local observing port so that Server can receive
mirrored packets.
2. Configure 10GE1/0/1 on SwitchA as the mirrored port to monitor packets passing through
the mirrored port.
Procedure
Step 1 Configure an observing port.
# Configure 10GE1/0/2 on SwitchA as the local observing port.
94
[~HUAWEI] commit
[~SwitchA] observe-port 1 interface 10ge 1/0/2
[~SwitchA] commit
Step 2 Configure a mirrored port.
# Configure 10GE1/0/1 on SwitchA as the mirrored port to monitor packets sent from HostA.
[~SwitchA-10GE1/0/1] port-mirroring observe-port 1 inbound
[~SwitchA-10GE1/0/1] quit
Step 3 Verify the configurations.
# Check the observing port configuration.
<SwitchA> display observe-port
----------------------------------------------------------------------
Index : 1
Interface: 10GE1/0/2
----------------------------------------------------------------------
# Check the mirrored port configuration.
<SwitchA> display port-mirroring
Port-mirror:
----------------------------------------------------------------------
Mirror-port Direction Observe-port
----------------------------------------------------------------------
1 10GE1/0/1 Inbound 10GE1/0/2
----------------------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
observe-port 1 interface 10GE1/0/2
#
interface 10GE1/0/1
port-mirroring observe-port 1 inbound
#
return
7.7.2 Example for Configuring Layer 2 Remote Port Mirroring
As shown in Figure 7-7, HostA is connected to 10GE1/0/2 on SwitchA, and Server is connected
to 10GE1/0/1 on SwitchC. SwitchA and SwitchC are connected over a Layer 2 network.
Users want to use the monitoring device (Server) to remotely monitor packets sent from HostA.
95
Figure 7-7 Networking diagram of Layer 2 remote port mirroring
10GE1/0/1
10GE1/0/1
10GE1/0/2
10GE1/0/2
VLAN2 VLAN2
SwitchA
SwitchB
SwitchC
10GE1/0/2 10GE1/0/1
HostA Server
1. Configure ports so that devices can communicate on Layer 2.
2. Configure 10GE1/0/1 on SwitchA as the remote observing port so that mirrored packets
can be forwarded to Server over the Layer 2 network.
3. Configure 10GE1/0/2 on SwitchA as the mirrored port to monitor packets passing through
the mirrored port.
Procedure
Step 1 Configure ports so that devices can communicate on Layer 2.
# Configure SwitchA.
[~HUAWEI] commit
[~SwitchA] vlan batch 2 to 3
[~SwitchA-10GE1/0/1] port link-type trunk
[~SwitchA-10GE1/0/1] port trunk allow-pass vlan 2
[~SwitchA-10GE1/0/2] port default vlan 3
[~SwitchA] commit
# Configure SwitchB.
[~HUAWEI] commit
[~SwitchB] vlan 2
[~SwitchB-vlan2] quit
[~SwitchB-10GE1/0/1] port link-type trunk
[~SwitchB-10GE1/0/1] port trunk allow-pass vlan 2
[~SwitchB-10GE1/0/1] quit
[~SwitchB-10GE1/0/2] port link-type trunk
[~SwitchB-10GE1/0/2] port trunk allow-pass vlan 2
[~SwitchB-10GE1/0/2] quit
[~SwitchB] commit
# Configure SwitchC.
96
[~HUAWEI] sysname SwitchC
[~HUAWEI] commit
[~SwitchC] vlan 2
[~SwitchC-vlan2] quit
[~SwitchC] interface 10ge 1/0/1
[~SwitchC-10GE1/0/1] port default vlan 2
[~SwitchC-10GE1/0/1] quit
[~SwitchC] interface 10ge 1/0/2
[~SwitchC-10GE1/0/2] port link-type trunk
[~SwitchC-10GE1/0/2] port trunk allow-pass vlan 2
[~SwitchC-10GE1/0/2] quit
[~SwitchC] commit
# Configure 10GE1/0/1 on SwitchA as the remote observing port.
[~SwitchA] observe-port 1 interface 10ge 1/0/1 vlan 2
[~SwitchA] commit
# Configure 10GE1/0/2 on SwitchA as the mirrored port.
[~SwitchA] commit
----------------------------------------------------------------------
Index : 1
Vlan : 2
----------------------------------------------------------------------
Port-mirror:
----------------------------------------------------------------------
----------------------------------------------------------------------
1 10GE1/0/2 Inbound 10GE1/0/1
----------------------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
vlan batch 2 to 3
#
observe-port 1 interface 10GE1/0/1 vlan 2
#
interface 10GE1/0/1
port link-type trunk
port trunk allow-pass vlan 2
#
interface 10GE1/0/2
97
port default vlan 3
#
return
l Configuration file of SwitchB
#
sysname SwitchB
#
vlan batch 2
#
interface 10GE1/0/1
#
interface 10GE1/0/2
#
return
l Configuration file of SwitchC
#
sysname SwitchC
#
vlan batch 2
#
interface 10GE1/0/1
port default vlan 2
#
interface 10GE1/0/2
#
return
7.7.3 Example for Configuring Layer 3 Remote Port Mirroring
As shown in Figure 7-8, HostA is connected to 10GE1/0/2 on SwitchA, and Server is connected
to 10GE1/0/2 on SwitchB. HostA can Server are connected over a Layer 2 network, and routes
between them are reachable.
Users want to use the monitoring device (Server) to remotely monitor packets sent from HostA.
98
Figure 7-8 Networking diagram of Layer 3 remote port mirroring
SwitchA
Server
10.2.1.1/24
Network
SwitchB
HostA
10.1.1.1/24
10GE1/0/2
10GE1/0/1
10GE1/0/2
1. Configure 10GE1/0/1 on SwitchA as the remote observing port so that mirrored packets
can be forwarded to Server over the Layer 3 network.
2. Configure 10GE1/0/2 on SwitchA as the mirrored port to monitor packets sent from HostA.
Procedure
# Configure 10GE1/0/1 on SwitchA as the Layer 3 remote observing port and set the destination
IP address to the Server IP address.
[~HUAWEI] commit
[~SwitchA] observe-port interface 10ge 1/0/1 destination-ip 10.2.1.1 source-ip
10.1.1.1
[~SwitchA] commit
# Configure 10GE1/0/2 on SwitchA as the mirrored port.
[~SwitchA] commit
----------------------------------------------------------------------
Index : 1
99
Vlan : 0
Dscp : 0
Src-Ip : 10.1.1.1
Dst-Ip : 10.2.1.1
Src-Mac : 00-25-9e-37-ee-a5
Dst-Mac : ff-ff-ff-ff-ff-ff
----------------------------------------------------------------------
Port-mirror:
----------------------------------------------------------------------
----------------------------------------------------------------------
1 10GE1/0/2 Inbound 10GE1/0/1
----------------------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
observe-port 1 interface 10GE1/0/1 destination-ip 10.2.1.1 source-ip 10.1.1.1
#
interface 10GE1/0/2
#
return
7.7.4 Example for Configuring Local Traffic Mirroring
As shown in Figure 7-9, HostA is connected to 10GE1/0/1 on SwitchA, and Server is directly
connected to 10GE1/0/2 on SwitchA.
Users want to use the monitoring device (Server) to monitor packets with the 802.1p priority of
6 sent from HostA.
Figure 7-9 Networking diagram of local traffic mirroring
10GE1/0/2
SwitchA HostA
10GE1/0/1
Server
1. Configure 10GE1/0/2 on SwitchA as the local observing port so that Server can receive
mirrored packets.
2. Configure a traffic classifier to match packets with the 802.1p priority of 6, and configure
a traffic behavior to mirror packets to the observing port.
100
3. Configure a traffic policy, bind the traffic classifier and traffic behavior to the traffic policy,
and apply the traffic policy to the inbound direction of 10GE1/0/1.
Procedure
Step 1 Configure an observing port.
# Configure 10GE1/0/2 on SwitchA as the observing port.
[~HUAWEI] commit
[~SwitchA] observe-port 1 interface 10ge 1/0/2
[~SwitchA] commit
Step 2 Configure a traffic classifier.
# Create a traffic classifier named c1 on SwitchA and set the traffic classification rule that only
packets with the 802.1p priority of 6 can be matched.
[~SwitchA] traffic classifier c1
[~SwitchA-classifier-c1] if-match 8021p 6
[~SwitchA-classifier-c1] commit
[~SwitchA-classifier-c1] quit
Step 3 Configure a traffic behavior.
# Create a traffic behavior named b1 on SwitchA and configure it.
[~SwitchA] traffic behavior b1
[~SwitchA-behavior-b1] mirroring observe-port 1
[~SwitchA-behavior-b1] commit
[~SwitchA-behavior-b1] quit
Step 4 Configure a traffic policy and apply the traffic policy to the interface.
# Create a traffic policy named p1 on SwitchA, bind the traffic classifier and traffic behavior to
the traffic policy, and apply the traffic policy to the inbound direction of 10GE1/0/1 to monitor
packets with the 802.1p priority of 6 sent from HostA.
[~SwitchA] traffic policy p1
[~SwitchA-trafficpolicy-p1] classifier c1 behavior b1
[~SwitchA-trafficpolicy-p1] commit
[~SwitchA-trafficpolicy-p1] quit
[~SwitchA-10GE1/0/1] traffic-policy p1 inbound
[~SwitchA] quit
# View the traffic classifier configuration.
<SwitchA> display traffic classifier c1
Traffic Classifier Information:
Classifier: c1
Operator: OR
Rule(s):
if-match 8021p 6
# View the traffic policy configuration.
<SwitchA> display traffic policy p1
Traffic Policy Information:
Policy: p1
Classifier: c1
101
Operator: OR
Behavior: b1
Mirroring observe-port 1
----End
Configuration Files
#
sysname SwitchA
#
observe-port 1 interface 10GE1/0/2
#
traffic classifier c1 type or
if-match 8021p 6
#
traffic behavior b1
mirroring observe-port 1
#
traffic policy p1
classifier c1 behavior b1
#
interface 10GE1/0/1
traffic-policy p1 inbound
#
return
102
8 iStack Configuration
About This Chapter
Multiple switches set up a stack to improve data forwarding capabilities and network reliability.
8.1 iStack Overview
Intelligent Stack (iStack) allows multiple stacking-capable switches to function as a single
logical switch.
8.2 iStack Features Supported by the Device
iStack features supported by the device include stack establishment, management, and
maintenance, dual-active detection, and fast stack upgrade.
8.3 Configuration Notes
This section describes precautions for configuring a stack.
This section describes the default configurations of a stack and common stack parameters.
8.5 Configuring a Stack
You can configure stack ports and parameters on member switches to set up a stack.
8.6 (Optional) Configuring Dual-active Detection
You can configure dual-active detection to detect and deal with a dual-active scenario when a
stack splits.
This section describes stack configuration examples, including networking requirements,
configuration roadmap, and configuration procedure.
Configuration Guide - Device Management 8 iStack Configuration
103
8.1 iStack Overview
Intelligent Stack (iStack) allows multiple stacking-capable switches to function as a single
logical switch.
Before a stack is set up, each switch is an independent entity and has its own IP address and
MAC address. You need to manage the switches separately. After a stack is set up, the switches
in the stack form a logical entity. You can use a single IP address to manage and maintain all
the switches in the stack as shown in Figure 8-1. A stack can transmit a large amount of data,
improve network reliability, and simplify network management.
Figure 8-1 iStack networking diagram
iStack
iStack Link
Concepts
Figure 8-2 shows the basic concepts involved in a stack.
Figure 8-2 Basic concepts involved in a stack
Domain 10
Master
Standby
Slave
Member ID = 1
Priority = 10
Member ID = 2
Priority = 20
Member ID = 3
Priority = 30
Stack port
Physical
member port
l Switch roles
Each switch in a stack is a member switch. Member switches are classified into the
following roles:
Master switch
The master switch manages the entire stack. A stack has only one master switch.
Standby switch
The standby switch is the backup to the master switch. A stack has only one standby
switch.
Slave switch
104
In a stack, all member switches except the master switch and standby switch are slave
switches.
l Stack domain
Switches that connect to each other using stack links to form a stack belong to a stack
domain. To meet various networking requirements, you can configure multiple stacks on
a network and use stack domain IDs to identify these stacks.
l Stack ID
A stack ID, also called a member ID, is used to identify and manage member switches in
a stack. All member switches in a stack have a unique stack ID.
l Stack priority
The stack priority is an attribute of member switches, which helps determine the role of
member switches in role election. A larger priority value indicates a higher priority. The
member switch with a higher stack priority has a higher probability of becoming the master
switch.
l Physical member port
Switches connect to each other to form a stack using physical member ports.
l Stack port
A stack port is a logical port that is bound to physical member ports to implement the
stacking function. Each member switch has two stack ports, which are named Stack-
Portn/1 and Stack-Portn/2. n specifies the stack ID of the member switch.
8.2 iStack Features Supported by the Device
iStack features supported by the device include stack establishment, management, and
maintenance, dual-active detection, and fast stack upgrade.
NOTE
Currently, four switches can form a stack. CE6800 or CE5800 series switches can only form a stack with switches
of the same series. CE6800 and CE5800 series switches cannot form a stack.
Setting Up a Stack
To use multiple switches to form a stack, connect physical member ports bound to the local stack
port to those bound to the neighbor stack port, as shown in Figure 8-3. A stack port can be bound
to multiple physical member ports to improve stack link bandwidth and reliability.
Figure 8-3 Stack networking diagram
iStack
iStack Link
Stack port Stack port
The stack contains multiple member switches, each of which has a role. During the setup of a
stack, member switches exchange packets to elect the master switch that manages the stack.
The rules for electing the master switch are as follows:
105
1. The switch that has started is preferred over the switch that is starting.
2. The switch with higher stack priority is preferred.
3. The switch with a later software version is preferred.
4. The switch with a smaller MAC address is preferred.
The election results are compared one by one. In the case of the same election result, the next
rule is used until the master switch is elected.
The master switch collects member information, calculates the stack topology, and synchronizes
the stack topology to all the other member switches.
l If member switches have the same stack ID, the master switch assigns a unique stack ID
to each of the member switches.
l When the master and slave switches use different software versions, slave switches
synchronize the software version with the master switch, restart, and then join the stack.
The master switch elects a standby switch from slave switches as the standby switch. When the
master switch fails, the standby switch takes over all services from the master switch.
The rules for electing the standby switch are as follows:
Connection Topology
A stack has two connection topologies: chain topology and ring topology, as shown in Figure
8-4.
A ring topology is more reliable than a chain topology. When a link fault occurs in the chain
topology, the stack splits. When a link fault occurs in the ring topology, a chain topology is
formed, which prevents stack services from being affected.
Figure 8-4 Stack connection topology
Chain topology Ring topology
Master Slave Standby
Standby Slave
iStack
iStack
Slave
Master Slave
Managing and Maintaining a Stack
After a stack is set up, all member switches function as one logical switch on the network, and
the master switch manages the resources of all remember switches. You can log in to the stack
106
through the management network interface or serial interface of any member switch to manage
and maintain the stack.
NOTE
When multiple management network ports are used in a stack, only one management network port can be used
for login.
After a switch joins a stack, the interface number is in the format stack ID/subcard ID/interface
sequence number.
Interface Configuration Combination
Physical member port configuration is saved in both the flash memory and configuration file of
a device. If the physical member port configuration in the flash memory is different from that
in the configuration file, for example, a new configuration file is specified, the physical member
port configuration in the flash memory combines with that in the configuration file. Rules for
combining the port configuration are as follows:
l Only the configurations of physical member ports are combined.
As shown in Figure 8-5, SwitchA and SwitchB form a stack. SwitchA functions as the
master switch and specifies a new configuration file. After the stack is set up, the port
configurations in the flash memory and configuration file of SwitchA are combined.
l If the port configurations in the flash memory and configuration file are different, the port
configuration in the configuration file takes effect.
In Figure 8-5, 10GE1/0/5 has the service configuration in the configuration file of SwitchA,
so the stack configuration of 10GE1/0/5 is deleted.
l The port configuration of the slave switch combines with that of the master switch, and the
port configuration of the master switch takes effect.
In Figure 8-5, the configuration of 10GE2/0/2 on SwitchA conflicts with the port
configuration of SwitchB. SwitchA functions as the master switch, so the port configuration
of SwitchA takes effect after the port configurations of SwitchA and SwitchB are combined.
l After a stack is set up, the slave switch synchronizes the configuration file of the master
switch to keep the same configuration as the master switch.
In Figure 8-5, after a stack is set up, the configuration file of SwitchB is consistent with
that of SwitchA.
107
Figure 8-5 Interface configuration combination
#
interface 10GE2/0/1
port mode stack
stack-port 2/1
#
interface 10GE2/0/2
port mode stack
stack-port 2/1
#
#
interface 10GE1/0/1
port mode stack
stack-port 1/1
#
interface 10GE1/0/5
port mode stack
stack-port 1/1
#
#
interface 10GE1/0/1
port mode stack
stack-port 1/1
#
interface 10GE1/0/2
port mode stack
stack-port 1/1
#
A stack
is formed
#
interface 10GE1/0/2
port mode stack
stack-port 1/1
#
interface 10GE2/0/2
port mode stack
#
interface 10GE1/0/5
eth-trunk 10
#
SwitchA Flash
SwitchA Configuration File
#
interface 10GE2/0/1
port mode stack
stack-port 2/1
#
interface 10GE2/0/2
port mode stack
stack-port 2/1
#
SwitchB Flash
SwitchB Configuration File
#
interface 10GE1/0/1
port mode stack
stack-port 1/1
#
interface 10GE1/0/2
port mode stack
stack-port 1/1
#
interface 10GE2/0/1
port mode stack
stack-port 2/1
#
interface 10GE2/0/2
port mode stack
#
interface 10GE1/0/5
eth-trunk 10
#
SwitchA Flash
#
interface 10GE2/0/1
port mode stack
stack-port 2/1
#
interface 10GE2/0/2
port mode stack
#
SwitchB Flash
SwitchA and SwitchB
Configuration File
Adding a Member Switch to a Stack
You can add a member switch to a stably running stack. Here, the member switch is added to
the stack when it is powered off. If the member switch with power on is added to the stack, a
stack merge occurs. In this situation, see Stack Merge. After the member switch is added, the
new member switch is elected as a slave switch, the original master and standby switches remain
unchanged, and the stack updates the topology.
108
Removing a Member Switch from a Stack
You can remove a member switch from a stack. The stack may be affected depending on the
role of the member switch that leaves the stack.
l If the master switch leaves the stack, the standby switch becomes the new master switch,
updates the stack topology, and specifies a new standby switch.
l If the standby switch leaves the stack, the master switch updates the stack topology and
specifies a new standby switch.
l If a slave switch leaves the stack, the master switch updates the stack topology.
l If both the master and standby switches leave the stack, all slave switches restart and form
another stack.
Stack Active/Standby Switchover
If the master switch is faulty or leaves the stack, the standby switch becomes the new master
switch, which then specifies a new standby switch and synchronizes data to the new standby
switch.
l When a stack is formed for the first time, the MAC address of the master switch is used as
the stack MAC address. If the master switch is faulty or leaves the stack, the MAC address
of the new master switch is used as the stack MAC address when the delay in stack MAC
address switchover is not configured.
l When the master switch is faulty or leaves the stack, the new master switch uses its own
MAC address as the stack MAC address, if the old master switch does not rejoin the
stack within the configured delay in stack MAC address switchover. If the old master switch
rejoins the stack within the delay in stack MAC address switchover, the old master switch
becomes a slave switch, and the stack MAC address remains unchanged. In this case, the
stack MAC address is the MAC address of a slave switch.
l When a slave switch (the owner of the stack MAC address) leaves a stack and does not
rejoin the stack within the delay in stack MAC address switchover, the master switch uses
its own MAC address as the stack MAC address.
Stack Merge
Two stacks can be merged into one stack. Then the superior switch between the master switches
of the two stacks is selected as the master switch of the new stack. The original stack containing
the new master remains the original device roles, and services in this stack are not affected.
Switches in the other stack restart, join the new stack as slave switches, and synchronize
configurations with the new master switch. Services of this stack are interrupted.
Stack Split
As shown in Figure 8-6, a stack splits into multiple stacks when some member switches are
removed from the running stack with power on or when the stack cable fail. A stack may split
into multiple stacks with the same configurations, which causes conflicts of IP addresses and
MAC addresses.
109
Figure 8-6 Stack split
Master Master
iStack 1 iStack 2
+ =
Master Standby
iStack Link
iStack
Dual-active Detection
Dual-active detection (DAD) is a method to detect a dual-active scenario and take recovery
action, ensuring network stability.
DAD has two modes:
l Direct mode
As shown in Figure 8-7, DAD is performed between member switches in a stack using a
dedicated direct link.
Figure 8-7 DAD in direct mode
SwitchA SwitchB
iStack
DAD Link
iStack Link
DAD packets
l Relay mode
As shown in Figure 8-8, DAD is configured on the inter-chassis Eth-Trunk in a stack, and
DAD in relay mode is configured on the proxy device.
NOTE
To enable DAD packets to be forwarded between Eth-Trunk member links, the proxy device must support
DAD in relay mode. All CloudEngine series switches support DAD in relay mode.
110
Figure 8-8 DAD in relay mode
SwitchA SwitchB
iStack
Relay
SwitchC
Eth-Trunk
DAD Link
iStack Link
DAD packets
The proxy device can be a stack. That is, two stacks can function as a proxy for each other,
as shown in Figure 8-9.
Figure 8-9 DAD relay between two stacks
Eth-Trunk10
SwitchA SwitchB
SwitchC SwitchD
Eth-Trunk20
DAD Link
iStack Link
DAD Packets
Domain 10
Domain 20
NOTE
To avoid interference to DAD in the two stacks, the two stacks must be configured with different domain
IDs and use different Eth-Trunk links as DAD links.
After a DAD link is configured, the master switch sends DAD packets over the DAD link. After
a stack splits into multiple stacks, the stacks compare information in received DAD packet with
local information. If the switch in a stack is elected as the master switch, the switch remains
Active and continues forwarding service packets. If the switch in a stack is elected as the standby
111
switch, the switch shuts down all its service ports except those excluded from shutdown, enters
the Recovery state, and stops forwarding service packets.
The rules for electing the master switch are as follows:
After the stack link recovers, the switch in Recovery state restarts and restores all the blocked
service ports.
Fast Stack Upgrade
Fast stack upgrade is a mechanism that minimizes service forwarding interruption during the
software upgrade of member switches in a stack. This mechanism reduces the impact of member
device upgrade on services.
During fast stack upgrade, the standby switch restarts using the new version, and the master
switch forwards data traffic. If the upgrade fails, the standby switch restarts and rolls back to
the previous version. After the standby switch is upgraded, it becomes the master switch and
forwards data traffic. The previous master switch restarts using the new version. After the
upgrade, the switch becomes the standby switch.
NOTE
Only the stack containing two member switches supports fast upgrade.
Figure 8-10 Fast upgrade of a stack
iStack Link
SwitchA
(Master)
SwitchB
(Standby)
iStack
8.3 Configuration Notes
This section describes precautions for configuring a stack.
Table 8-1 lists the notes to take when you configure a stack.
112
Table 8-1 Stack configuration notes
Item CE6850-48S4Q-EI CE6850-48T4Q-EI CE5850-48T4S2Q-
EI
Number of member
switches in a stack
4 4
Type of physical
member ports
48x10GE optical
interfaces and
4x40GE optical
interfaces
4x40GE optical
interfaces
4x10GE optical
interfaces and
2x40GE optical
interfaces
Type of cables used
to connect physical
member ports
Interface
type
High-speed cable for
connection
Fiber for connection
10GE optical
interface
SFP+ - SFP+ Optical module: SFP
+ optical module
Fiber: LC/PC fiber
40GE optical
interface
QSFP+ - QSFP+ Optical module:
QSFP+ optical
module
Fiber: MPO-MPO
fiber

Maximum number of
physical member
ports in a stack port
1 to 16 (10GE and
40GE optical
interfaces cannot
belong to the same
stack port.)
1 to 4 1 to 4 (10GE and
40GE optical
interfaces cannot
belong to the same
stack port.)

NOTE
l A stack can contain only devices of the same series. For example, CE6800 and CE5800 switches cannot
form a stack.
l When configuring 10GE optical interfaces as physical member ports, follow these rules: The number
of physical member ports in a stack port must be a multiple of 4. The physical member ports must have
consecutive IDs, and the last ID must be a multiple of 4. For example, interfaces with IDs 1 to 4, 5 to
8, or 1 to 8 can be added to the same stack port but interfaces with IDs 2 to 5 or 3 to 6 cannot. 10GE
optical interfaces can be used as physical member ports only when they have 10GE optical modules
installed. They cannot be used to set up a stack when having GE optical modules or GE copper modules
installed.
l 40GE optical interfaces cannot be configured as physical member ports after they are split into 10GE
optical interfaces.
l Use Huawei-certified optical or copper modules. Non-Huawei-certified optical or copper modules
cannot ensure transmission reliability and may affect service stability. Huawei is not responsible for
any problem caused by non-Huawei-certified optical or copper modules and will not fix such problems.
113
This section describes the default configurations of a stack and common stack parameters.
Table 8-2 Default stack configuration
The status of the CSS function Enabled
Stack ID 1
Stack priority 100

8.5 Configuring a Stack
You can configure stack ports and parameters on member switches to set up a stack.
Before configuring a stack, complete the following task:
l Confirming that the switches support the stacking function and starting the devices
114
Configuration Procedure
Figure 8-11 Flowchart for configuring a stack
Configure the stack ID
and priority
Configure a stack
domain
Power off and connect
the device using
cables
Mandatory step
Optional step
Configure a stack
interface
Power on and start
the device
8.5.1 Configuring the Stack Domain ID
Context
Switches that connect to each other using stack links to form a stack belong to a stack domain.
To meet various networking requirements, you can configure multiple stacks on a network and
use stack domain IDs to identify these stacks.
NOTE
Only the devices with the same stack domain ID can form a stack.
Procedure
Step 1 Run:
system-view
Step 2 Run:
stack
The stack management view is displayed.
Step 3 Run:
stack [ member { member-id | all } ] domain domain-id
115
The stack domain ID is configured for the member switch.
By default, no stack domain ID is configured for a device.
Step 4 Run:
commit
----End
8.5.2 (Optional) Configuring the Stack ID
Context
The stack ID can be used to identify and manage member switches in a stack. Each member
switch in a stack has a unique stack ID. If member switches have the same stack ID, the master
switch assigns a unique stack ID to each of the member switches.
Procedure
Step 1 Run:
system-view
Step 2 Run:
stack
Step 3 Run:
stack [ member member-id ] renumber new-member-id
A stack ID is set for the member switch.
By default, the stack ID of a device is 1.
Step 4 Run:
commit
----End
8.5.3 (Optional) Configuring the Stack Priority
Context
The stack priority helps determine the role of member switches in master switch election. A
larger priority value indicates a higher priority. The member switch with a higher stack priority
has a higher probability of becoming the master switch.
116
Procedure
Step 1 Run:
system-view
Step 2 Run:
stack
Step 3 Run:
stack [ member { member-id | all } ] priority priority-value
The stack priority is configured.
By default, the stack priority is 100.
Step 4 Run:
commit
----End
8.5.4 Configuring a Stack Port
Context
NOTE
If you connect devices using stack cables before configuring stack ports, the devices may restart because of the
stack merge, causing configuration loss. You are advised to perform the stack configuration and run the save
command to save the configuration before connecting devices using stack cables and restarting the devices.
During the setup of a stack, physical ports must be configured as physical member ports, which
are then added to a stack port. Multiple physical member ports can be added to a stack port to
improve stack link bandwidth and reliability.
When adding a physical port to a stack port, pay attention to the following points:
l Ports with common service configuration cannot be added to a stack port.
l Multiple physical member ports can be added to a stack port to implement stack link backup
and load balancing. This can improve link bandwidth and reliability.
l 10GE optical ports or 40GE optical ports can be added to a stack port, but GE or 10GE
electrical ports cannot.
l 10GE and 40GE ports cannot be added to the same stack port.
l When configuring 10GE optical ports as physical member ports, follow these rules: The
number of physical member ports in a stack port must be a multiple of 4. The physical
member ports must have consecutive IDs, and the last ID must be a multiple of 4. For
example, ports with IDs 1 to 4, 5 to 8, or 1 to 8 can be added to the same stack port but
ports with IDs 2 to 5 or 3 to 6 cannot.
l When a physical port in Up state is configured as a physical member port, a CRC alarm
may be generated on the interface, but physicals are not affected. If the physical port is
configured to transit to the error-down state when the number of received CRC error packets
117
exceeds the threshold, run the shutdown command to shut down the interface and then run
the undo shutdown command to return the interface to the Up state.
l After configuring a stack port, save the configuration to the configuration file for the next
startup. Otherwise, the configuration is lost during the next startup.
Procedure
Step 1 Create a stack port.
1. Run:
system-view
2. Run:
interface stack-port member-id/port-id
A stack port is created.
By default, no stack port is created.
3. Run:
commit
Step 2 Configure physical ports as physical member ports.
l In the stack management view
1. Run:
system-view
2. Run:
stack
3. Run:
port mode stack interface interface-type interface-number1 [ to interface-
number2 ]
Physical ports are configured as physical member ports.
4. Run:
commit
l In the interface view
1. Run:
system-view
2. Run:
3. Run:
port mode stack
Physical ports are configured as physical member ports.
118
4. Run:
commit
Step 3 Add physical member ports to a stack port.
l In the stack port view
1. Run:
system-view
2. Run:
The stack port view is displayed.
3. Run:
port member-group interface interface-type interface-number1 [ to interface-
number2 ]
Member ports are added to the stack port.
4. Run:
commit
l In the interface view
1. Run:
system-view
2. Run:
3. Run:
stack-port member-id/port-id
Physical member ports are added to the stack port.
4. Run:
commit
Step 4 (Optional) Set the load balancing mode for the stack port.
1. Run:
system-view
2. Run:
The stack port view is displayed.
3. Run:
load-balance { dst-ip | dst-mac | src-dst-ip | src-dst-mac | src-ip | src-mac }
The load balancing mode is configured for the stack port.
119
By default, the load balancing mode of a stack port is src-dst-ip.
----End
8.5.5 Restarting the Device
Context
After stack attributes, such as the stack domain ID, stack ID, and stack priority, are configured
on a device, the configuration takes effect after the device is restarted. After performing the stack
configuration, you can power off the device, connect the device using stack cables, and then
power on and start the device.
NOTE
Before rebooting device, please use save command to save configuration.
8.5.6 (Optional) Configuring the Delay in Stack MAC Address
Switchover
Context
In a stack, if the owner of the stack MAC address leaves the stack and does not rejoin the
stack within the delay in stack MAC address switchover, the master switch uses its own MAC
address as the new stack MAC address. If the member switch rejoins the stack within the delay,
its own MAC address is still the stack MAC address.
If all switches have the delay in stack MAC address switchover configured before they form a
stack, the delay configured on the master switch is used after a stack is formed, and the delay
configured on the other member switches remains the same as that of the master switch.
Procedure
Step 1 Run:
system-view
Step 2 Run:
stack
Step 3 Run:
stack mac-address switch-delay { delay-time | immediately }
The delay in stack MAC address switchover is configured.
By default, the delay in stack MAC address switchover is 10 minutes.
Step 4 Run:
commit
----End
120
8.5.7 (Optional) Starting Fast Upgrade of Switches in a Stack
Context
You can use commands to fast upgrade switches in a stack, which reduces the impact of device
upgrade on services.
NOTE
Only the stack containing two member switches supports fast upgrade.
A device connected to the stack must be connected to the two member switches using an Eth-Trunk in the
stack. Otherwise, data traffic may be interrupted.
During fast stack upgrade, the standby switch restarts using the new version, and the master
switch forwards data traffic. After the standby switch is upgraded, it becomes the master switch
and forwards data traffic. The previous master switch restarts using the new version. After the
upgrade, the switch becomes the standby switch.
Procedure
Step 1 Run:
startup system-software system-file all
The software package for the next startup is specified.
Step 2 Run:
system-view
Step 3 Run:
stack
Step 4 Run:
stack upgrade fast
Fast upgrade is configured for switches in a stack.
----End
Procedure
l Run the display stack [ member member-id ] command to check information about
member switches.
l Run the display stack configuration [ member member-id ] command to check the stack
configuration.
l Run the display stack topology command to check stack topology information.
----End
121
8.6 (Optional) Configuring Dual-active Detection
You can configure dual-active detection to detect and deal with a dual-active scenario when a
stack splits.
Before configuring dual-active (DAD), complete the following task:
l Setting up a stack.
8.6.1 Configuring the DAD Mode
Context
Two DAD modes are available:
l DAD in direct mode: DAD is performed between member switches in a stack using a
dedicated direct link.
l DAD in relay mode: DAD is performed between member switches in a stack using the
relay function.
NOTE
l In a stack, you can only configure DAD in direct mode or DAD in relay mode but cannot configure both
DAD in direct mode and DAD in relay mode.
l To ensure DAD reliability, configure four direct links or four relay channels to detect the Eth-Trunk interface.
In a dual-active scenario, if one direct link or one relay channel is in Up state, DAD can properly work.
Procedure
l Configure DAD in direct mode.
1. Run:
system-view
2. Run:
3. Run:
dual-active detect mode direct
DAD in direct mode is enabled on the interface.
By default, DAD in direct mode is disabled on an interface.
NOTE
After DAD in direct mode is configured on an interface, other services are not suggested being
configured on the interface.
4. Run:
commit
122
l Configure DAD in relay mode.
On a member switch
1. Run:
system-view
2. Run:
interface eth-trunk trunk-id
The Eth-Trunk interface view is displayed.
3. Run:
dual-active detect mode relay
DAD in relay mode is enabled on the Eth-Trunk interface.
By default, DAD in relay mode is disabled on an interface.
4. Run:
commit
On a specified proxy device
1. Run:
system-view
2. Run:
interface eth-trunk trunk-id
The Eth-Trunk interface view is displayed.
3. Run:
dual-active proxy
The relay function is enabled on the Eth-Trunk interface.
By default, the relay function is disabled on an interface.
4. Run:
commit
----End
8.6.2 (Optional) Excluding Ports from Shutdown
Context
When DAD detects a failure, all service ports of the member switch that fails master switch
election must be shut down to minimize the impact of the same MAC addresses and IP addresses
on the network. Some ports that only transparently transmit packets do not affect network
stability in a dual-active scenario. You can exclude these ports from shutdown. In dual-active
scenario, all service ports except those excluded from shutdown are in shutdown state.
123
Procedure
Step 1 Run:
system-view
Step 2 Run:
dual-active exclude interface interface-type interface-number1 [ to interface-
number2 ]
The specified ports are excluded from error-down.
By default, only physical member ports are excluded from error-down.
Step 3 Run:
commit
----End
8.6.3 (Optional) Restoring Blocked Ports
Context
If the master switch fails or is removed from the network before a CSS split fault is rectified,
restore the standby switch on which ports are in shutdown state so that the standby switch can
take over the master role. This minimizes the impact of the master switch fault on services.
Procedure
Step 1 Run:
system-view
Step 2 Run:
dual-active restore
Ports in shutdown state are restored.
Step 3 Run:
commit
----End
Procedure
Step 1 Run the display dual-active [ proxy ] command to check the detailed DAD configuration.
----End
124
This section describes stack configuration examples, including networking requirements,
configuration roadmap, and configuration procedure.
8.7.1 Example for Configuring a Stack with a Chain Topology
As the network size rapidly increases, more access interfaces must be provided on access
switches, and the network must be easy to manage and maintain. A single access switch cannot
meet these requirements. A stack can be set up to meet these requirements.
As shown in Figure 8-12, SwitchA, SwitchB, and SwitchC need to set up a stack with a chain
topology. 10GE1/0/1 and 10GE1/0/2 of SwitchA need to be added to stack port 1/1. 10GE1/0/1
and 10GE1/0/2 of SwitchB need to be added to stack port 1/1; 10GE1/0/3 and 10GE1/0/4 need
to be added to stack port 1/2. 10GE1/0/1 and 10GE1/0/2 of SwitchC need to be added to stack
port 1/1.
Figure 8-12 Stack with a chain topology
iStack Domain 10
SwitchA
SwitchB
10GE1/0/1
10GE1/0/2
iStack Link
Common Link
Eth-Trunk
Network
SwitchC
10GE1/0/1
10GE1/0/2
10GE1/0/1
10GE1/0/2
10GE1/0/3
10GE1/0/4
125
1. Configure a domain ID for SwitchA, SwitchB, and SwitchC to enable the three switches
to form a stack and differentiate the stack from other stacks on the network.
2. Configure stack ports on SwitchA, SwitchB, and SwitchC so that physical member ports
can forward data packets between the three member switches. A stack port can be bound
3. Use optical fibers to connect stack ports of the three switches and restart the three switches
to make the configuration take effect.
Procedure
Step 1 Configure stack parameters on SwitchA, SwitchB, and SwitchC.
# On SwitchA, set the domain ID to 10, the stack ID to 1, and the stack priority to 150.
[~HUAWEI] commit
[~SwitchA] stack
[~SwitchA-stack] stack domain 10
[~SwitchA-stack] stack renumber 1
[~SwitchA-stack] stack priority 150
[~SwitchA-stack] quit
[~SwitchA] commit
# On SwitchB, set the domain ID to 10 and the stack ID to 2.
[~HUAWEI] commit
[~SwitchB] stack
[~SwitchB-stack] stack domain 10
[~SwitchB-stack] stack renumber 2
[~SwitchB-stack] quit
[~SwitchB] commit
# On SwitchC, set the domain ID to 10 and the stack ID to 3.
[~HUAWEI] commit
[~SwitchC] stack
[~SwitchC-stack] stack domain 10
[~SwitchC-stack] stack renumber 3
[~SwitchC-stack] quit
[~SwitchC] commit
Step 2 Configure stack ports.
# On SwitchA, configure 10GE 1/0/1 and 10GE 1/0/2 as physical member ports and add them
to stack port 1/1.
[~SwitchA-stack] port mode stack interface 10ge 1/0/1 to 1/0/4
[~SwitchA] interface stack-port 1/1
[~SwitchA-Stack-Port1/1] port member-group interface 10ge 1/0/1 to 1/0/2
[~SwitchA-Stack-Port1/1] quit
[~SwitchA] commit
# On SwitchB, configure 10GE1/0/1 through 10GE1/0/4 as physical member ports. Add
10GE1/0/1 and 10GE1/0/2 to stack port 1/1, and add 10GE1/0/3 and 10GE1/0/4 to 1/2.
126
[~SwitchB-stack] port mode stack interface 10ge 1/0/1 to 1/0/4
[~SwitchB] interface stack-port 1/1
[~SwitchB-Stack-Port1/1] port member-group interface 10ge 1/0/1 to 1/0/2
[~SwitchB-Stack-Port1/1] quit
[~SwitchB] commit
# On SwitchC configure 10GE 1/0/1 and 10GE 1/0/2 as physical member ports and add them
to stack port 1/1.
[~SwitchC-stack] port mode stack interface 10ge 1/0/1 to 1/0/4
[~SwitchC] interface stack-port 1/1
[~SwitchC-Stack-Port1/1] port member-group interface 10ge 1/0/1 to 1/0/2
[~SwitchC-Stack-Port1/1] quit
[~SwitchC] commit
Step 3 Save the configurations of SwitchA, SwitchB and SwitchC, power off the three switches, connect
the stack link, and power on the three switches.
# Check stack information.
<SwitchA> display stack
------------------------------------------------------------
MemberID Role Mac Priority Device Type
------------------------------------------------------------
1 Master 0004-9f31-d520 150 CE6850-48T4Q-EI
2 Standby 0004-9f62-1f40 100 CE6850-48T4Q-EI
3 Slave 0004-9f69-a391 100 CE6850-48T4Q-EI
------------------------------------------------------------
NOTE
To cancel the stack configuration, perform the following operations:
1. Delete physical member interfaces from a stack interface.
l Run the undo port member-group interface interface-type interface-number1 [ to interface-
number2 ] command in the stack port view .
l Run the undo port member-group interface interface-type interface-number1 [ to interface-
number2 ] command in the interface view.
2. Restore physical member interfaces as service interfaces.
l Run the undo port mode stack interface interface-type interface-number1 [ to interface-number2 ]
command in the stack management view.
l Run the undo port mode stack command in the interface view.
3. Run the undo interface stack-port member-id/port-id command in the system view to delete the stack
interface.
4. Remove stack cables between switches. To restore the stack ID of a switch to 1, run the stack [ member
member-id ] renumber 1 command in the stack management view and restart the switch.
----End
Configuration Files
l Configuration file of the stack
#
sysname SwitchA
#
interface 10GE1/0/1
port mode stack
127
stack-port 1/1
#
interface 10GE1/0/2
port mode stack
stack-port 1/1
#
interface 10GE2/0/1
port mode stack
stack-port 2/1
#
interface 10GE2/0/2
port mode stack
stack-port 2/1
#
interface 10GE2/0/3
port mode stack
stack-port 2/2
#
interface 10GE2/0/4
port mode stack
stack-port 2/2
#
interface 10GE3/0/1
port mode stack
stack-port 3/1
#
interface 10GE3/0/2
port mode stack
stack-port 3/1
#
return
8.7.2 Example for Configuring a Stack with a Ring Topology
As the network size rapidly increases, more access interfaces must be provided on access
switches, and the network must be easy to manage and maintain. A single access switch cannot
meet these requirements. A stack can be set up to meet these requirements.
As shown in Figure 8-13, SwitchA, SwitchB, and SwitchC need to set up a stack with a ring
topology. On the switches, 10GE1/0/1 and 10GE1/0/2 need to be added to stack port 1/1, and
10GE1/0/3 and 10GE1/0/4 need to be added to stack port 1/2.
128
Figure 8-13 Stack with a ring topology
iStack Link
Common Link
Eth-Trunk
SwitchA SwitchB
iStack Domain 10
SwitchC
Network
10GE1/0/1
10GE1/0/2
10GE1/0/1
10GE1/0/2
1
0
G
E
1
/
0
/
3
1
0
G
E
1
/
0
/
4
1
0
G
E
1
/
0
/
3
1
0
G
E
1
/
0
/
4
1
0
G
E
1
/
0
/
1
1
0
G
E
1
/
0
/
2
1
0
G
E
1
/
0
/
3
1
0
G
E
1
/
0
/
4
1. Configure a domain ID for SwitchA, SwitchB, and SwitchC to enable the three switches
to form a stack and differentiate the stack from other stacks on the network.
2. Configure stack ports on SwitchA, SwitchB, and SwitchC so that physical member ports
can forward data packets between the three member switches. A stack port can be bound
3. Use optical fibers to connect stack ports of the three switches and restart the three switches
to make the configuration take effect.
Procedure
Step 1 Configure stack parameters on SwitchA, SwitchB, and SwitchC.
# On SwitchA, set the domain ID to 10, the stack ID to 1, and the stack priority to 150.
[~HUAWEI] commit
[~SwitchA] stack
129
[~SwitchA-stack] stack domain 10
[~SwitchA-stack] stack renumber 1
[~SwitchA-stack] stack priority 150
[~SwitchA] commit
# On SwitchB, set the domain ID to 10 and the stack ID to 2.
[~HUAWEI] commit
[~SwitchB] stack
[~SwitchB-stack] stack domain 10
[~SwitchB-stack] stack renumber 2
[~SwitchB] commit
# On SwitchC, set the domain ID to 10 and the stack ID to 3.
[~HUAWEI] commit
[~SwitchC] stack
[~SwitchC-stack] stack domain 10
[~SwitchC-stack] stack renumber 3
[~SwitchC] commit
Step 2 Configure stack ports.
# On SwitchA, configure 10GE1/0/1 through 10GE1/0/4 as physical member ports. Add
[~SwitchA] stack
[~SwitchA-stack] port mode stack port 10ge 1/0/1 to 1/0/4
[~SwitchA-stack] commit
[~SwitchA-Stack] commit
# On SwitchB, configure 10GE1/0/1 through 10GE1/0/4 as physical member ports. Add
[~SwitchB] stack
[~SwitchB-stack] port mode stack port 10ge 1/0/1 to 1/0/4
[~SwitchB-stack] commit
[~SwitchB-Stack] commit
# On SwitchC, configure 10GE1/0/1 through 10GE1/0/4 as physical member ports. Add
[~SwitchC] stack
[~SwitchC-stack] port mode stack port 10ge 1/0/1 to 1/0/4
[~SwitchC-stack] commit
130
[~SwitchC-Stack] commit
Step 3 Save the configurations of SwitchA, SwitchB and SwitchC, power off the three switches, connect
the stack link, and power on the three switches.
# Check stack information.
<SwitchA> display stack
------------------------------------------------------------
MemberID Role Mac Priority Device Type
------------------------------------------------------------
1 Master 0004-9f31-d520 150 CE6850-48T4Q-EI
2 Standby 0004-9f62-1f40 100 CE6850-48T4Q-EI
3 Slave 0004-9f69-a391 100 CE6850-48T4Q-EI
------------------------------------------------------------
----End
Configuration Files
#
sysname SwitchA
#
interface 10GE1/0/1
port mode stack
stack-port 1/1
#
interface 10GE1/0/2
port mode stack
stack-port 1/1
#
interface 10GE1/0/3
port mode stack
stack-port 1/2
#
interface 10GE1/0/4
port mode stack
stack-port 1/2
#
interface 10GE2/0/1
port mode stack
stack-port 2/1
#
interface 10GE2/0/2
port mode stack
stack-port 2/1
#
interface 10GE2/0/3
port mode stack
stack-port 2/2
#
interface 10GE2/0/4
port mode stack
stack-port 2/2
#
interface 10GE3/0/1
port mode stack
stack-port 3/1
#
interface 10GE3/0/2
port mode stack
131
stack-port 3/1
#
interface 10GE3/0/3
port mode stack
stack-port 3/2
#
interface 10GE3/0/4
port mode stack
stack-port 3/2
#
return
8.7.3 Example for Configuring DAD in Direct Mode
As shown in Figure 8-14, SwitchA and SwitchB form a stack. SwitchA is the master switch in
the stack. The stack IDs of SwitchA and SwitchB are 1 and 2 respectively. DAD in direct mode
needs to be configured on interfaces 10GE1/0/5 and 10GE2/0/5.
When the stack splits because of a stack link fault and there are two stacks with the same
configuration on the network, you can use DAD to reduce the impact of a stack split on the
network.
Figure 8-14 Networking diagram of DAD in direct mode
Network
iStack
SwitchA SwitchB
10GE1/0/5 10GE2/0/5
SwitchC
DAD Link
iStack Link
Common Link
Eth-Trunk
132
1. Configure DAD in direct mode on specified interfaces.
Procedure
Step 1 Configure DAD on interfaces.
# Configure DAD in direct mode on 10GE1/0/5.
[~HUAWEI] interface 10ge 1/0/5
[~HUAWEI-10GE1/0/5] dual-active detect mode direct
Warning: The interface will block common data packets, except BPDU packets. Cont
inue? [Y/N]: y
[~HUAWEI-10GE1/0/5] commit
# Configure DAD in direct mode on 10GE2/0/5.
[~HUAWEI] interface 10ge 2/0/5
[~HUAWEI-10GE2/0/5] dual-active detect mode direct
Warning: The interface will block common data packets, except BPDU packets. Cont
inue? [Y/N]: y
[~HUAWEI-10GE2/0/5] commit
# Check detailed DAD configuration.
<HUAWEI> display dual-active
Dual-active status: Normal
Dual-active detect mode: Direct
Dual-active direct detect interfaces configured:
10GE1/0/5 up
10GE2/0/5 up
Dual-active relay detect interfaces configured:
-
Excluded ports(configurable):
-
Excluded ports(can not be configured):
10GE1/0/1
10GE1/0/2
10GE1/0/3
10GE1/0/4
10GE2/0/1
10GE2/0/2
10GE2/0/3
10GE2/0/4
----End
Configuration Files
#
interface 10GE1/0/1
port mode stack
stack-port 1/1
#
interface 10GE1/0/2
port mode stack
stack-port 1/1
#
133
interface 10GE1/0/3
port mode stack
stack-port 1/1
#
interface 10GE1/0/4
port mode stack
stack-port 1/1
#
interface 10GE1/0/5
#
interface 10GE2/0/1
port mode stack
stack-port 2/1
#
interface 10GE2/0/2
port mode stack
stack-port 2/1
#
interface 10GE2/0/3
port mode stack
stack-port 2/1
#
interface 10GE2/0/4
port mode stack
stack-port 2/1
#
interface 10GE2/0/5
#
return
8.7.4 Example for Configuring DAD in Relay Mode
As shown in Figure 8-15, SwitchA and SwitchB form a stack. SwitchA and SwitchB connect
to SwitchC using Eth-Trunk10.
When the stack splits because of a stack link fault and there are two stacks with the same
configuration on the network, you can use DAD to reduce the impact of a stack split on the
network.
134
Figure 8-15 Networking diagram of DAD in relay mode
Network
SwitchA SwitchB
SwitchC
Eth-Trunk10
iStack
10GE1/0/5 10GE2/0/5
10GE1/0/1 10GE1/0/2
DAD Link
iStack Link
Common Link
Eth-Trunk
1. Configure DAD in relay mode on a specified Eth-Trunk interface.
2. Configure the relay function on the proxy device to allow the proxy device to forward DAD
protocol packets.
Procedure
Step 1 Configure DAD in relay mode on a specified Eth-Trunk interface.
# Configure DAD in relay mode on Eth-Trunk10.
[~HUAWEI] interface eth-trunk 10
[~HUAWEI-Eth-Trunk10] trunkport 10ge 1/0/5
[~HUAWEI-Eth-Trunk10] trunkport 10ge 2/0/5
[~HUAWEI-Eth-Trunk10] dual-active detect mode relay
[~HUAWEI-Eth-Trunk10] commit
Step 2 Configure the relay function on the proxy device.
# Configure the relay function on SwitchC.
135
[~HUAWEI] commit
[~SwitchC] interface eth-trunk 10
[~SwitchC-Eth-Trunk10] trunkport 10ge 1/0/1
[~SwitchC-Eth-Trunk10] trunkport 10ge 1/0/2
[~SwitchC-Eth-Trunk10] dual-active proxy
[~SwitchC-Eth-Trunk10] commit
# Check detailed DAD configuration.
<HUAWEI> display dual-active
Dual-active status: Normal
Dual-active detect mode: Relay
Dual-active direct detect interfaces configured:
-
Dual-active relay detect interfaces configured:
Eth-Trunk10
10GE1/0/5 up
10GE2/0/5 up
Excluded ports(configurable):
-
Excluded ports(can not be configured):
10GE1/0/1
10GE1/0/2
10GE1/0/3
10GE1/0/4
10GE2/0/1
10GE2/0/2
10GE2/0/3
10GE2/0/4
# Check information about SwitchC.
<SwitchC> display dual-active proxy
Dual-active proxy interfaces configured:
Eth-Trunk10
10GE1/0/1 up
10GE1/0/2 up
----End
Configuration Files
#
interface 10GE1/0/1
port mode stack
stack-port 1/1
#
interface 10GE1/0/2
port mode stack
stack-port 1/1
#
interface 10GE1/0/3
port mode stack
stack-port 1/1
#
interface 10GE1/0/4
port mode stack
stack-port 1/1
#
interface 10GE1/0/5
eth-trunk 10
#
interface 10GE2/0/1
136
port mode stack
stack-port 2/1
#
interface 10GE2/0/2
port mode stack
stack-port 2/1
#
interface 10GE2/0/3
port mode stack
stack-port 2/1
#
interface 10GE2/0/4
port mode stack
stack-port 2/1
#
interface 10GE2/0/5
eth-trunk 10
#
interface Eth-Trunk10
dual-active detect mode relay
#
return
l Configuration file of SwitchC
#
sysname SwitchC
#
interface 10GE1/0/1
eth-trunk 10
#
interface 10GE1/0/2
eth-trunk 10
#
interface Eth-Trunk10
dual-active proxy
#
return
137

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

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

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

Hochgeladen von

Copyright:

Verfügbare Formate

CloudEngine 6800&5800 Series Switches

Das könnte Ihnen auch gefallen