AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R009 CLI-based Configuration Guide - Network Management and Monitoring

Huawei AR Series Access Routers
V200R009
CLI-based Configuration Guide -

Network Management and
Monitoring
Issue 06
Date 2019-04-30
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2019. 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://e.huawei.com
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. i

CLI-based Configuration Guide - Network Management
and Monitoring About This Document
About This Document
Intended Audience
This document provides the basic concepts, configuration procedures, and configuration
examples in different application scenarios of the network management feature supported by
the device.
This document is intended for:
l Data configuration engineers

l Commissioning engineers
l Network monitoring engineers
l System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol Description
Indicates an imminently hazardous situation

which, if not avoided, will result in death or
serious injury.
Indicates a potentially hazardous situation

which, if not avoided, could result in death
or serious injury.

which, if not avoided, may result in minor
or moderate injury.

which, if not avoided, could result in
equipment damage, data loss, performance
deterioration, or unanticipated results.
NOTICE is used to address practices not
related to personal injury.
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. ii

Symbol Description
NOTE Calls attention to important information,

best practices and tips.
NOTE is used to address information not
related to personal injury, equipment
damage, and environment deterioration.
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. Several items or no item can be selected.
&<1-n> The parameter before the & sign can be repeated 1 to n

times.
# A line starting with the # sign is comments.
Interface Numbering Conventions

Interface numbers used in this manual are examples. In device configuration, use the existing
interface numbers on devices.
Security Conventions
l Password setting
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. iii

– When configuring a password, the cipher text is recommended. To ensure device

security, change the password periodically.
– When you configure a password in plain text that starts and ends with %@%@, @
%@%, %#%#, or %^%# (the password can be decrypted by the device), the
password is displayed in the same manner as the configured one in the
configuration file. Do not use this setting.
– When you configure a password in cipher text, different features cannot use the
same cipher-text password. For example, the cipher-text password set for the AAA
feature cannot be used for other features.
l Encryption algorithm
Currently, the device uses the following encryption algorithms: 3DES, AES, RSA,
SHA1, SHA2, and MD5. 3DES, RSA and AES are reversible, while SHA1, SHA2, and
MD5 are irreversible. The encryption algorithms DES/3DES/RSA (RSA-1024 or
lower)/MD5 (in digital signature scenarios and password encryption)/SHA1 (in digital
signature scenarios) have a low security, which may bring security risks. If protocols
allowed, using more secure encryption algorithms, such as AES/RSA (RSA-2048 or
higher)/SHA2/HMAC-SHA2, is recommended. The encryption algorithm depends on
actual networking. The irreversible encryption algorithm must be used for the
administrator password, SHA2 is recommended.
l Personal data
Some personal data may be obtained or used during operation or fault location of your
purchased products, services, features, so you have an obligation to make privacy
policies and take measures according to the applicable law of the country to protect
personal data.
l The terms mirrored port, port mirroring, traffic mirroring, and mirroring 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.
Declaration
l This manual is only a reference for you to configure your devices. The contents in the
manual, such as web pages, command line syntax, and command outputs, are based on
the device conditions in the lab. The manual provides instructions for general scenarios,
but do not cover all usage scenarios of all product models. The contents in the manual
may be different from your actual device situations due to the differences in software
versions, models, and configuration files. The manual will not list every possible
difference. You should configure your devices according to actual situations.
l The specifications provided in this manual are tested in lab environment (for example,
the tested device has been installed with a certain type of boards or only one protocol is
run on the device). Results may differ from the listed specifications when you attempt to
obtain the maximum values with multiple functions enabled on the device.
l In this document, public IP addresses may be used in feature introduction and
configuration examples and are for reference only unless otherwise specified.
l In this document, AR series access routers include
AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600.
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. iv

Mappings Between Product Software Versions and NMS

Versions
The mappings between product software versions and NMS versions are as follows.
AR Product eSight iManager U2000

Software Version
V200R009C00 V300R008C00 V200R017C60
Change History
Changes between document issues are cumulative. Therefore, the latest document version
contains all updates made to previous versions.
Changes in Issue 06 (2019-04-30)

This version has the following updates:
The following information is deleted:
l References for SNMP
l References for RMON and RMON2

The following information is modified:
l 8.6.1 Example for Configuring LSDP

l 11.3 Configuring the Device to Capture Packets

l 1.4 Licensing Requirements and Limitations for SNMP

The following information is added:
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. v

l 6.5.7 (Optional) Configuring LLDP Packet Authentication on an Interface

Initial commercial release.
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. vi

and Monitoring Contents
Contents
About This Document.....................................................................................................................ii

1 SNMP Configuration.................................................................................................................... 1
1.1 Overview of SNMP........................................................................................................................................................ 2
1.2 Understanding SNMP.....................................................................................................................................................3
1.2.1 SNMP Management Model......................................................................................................................................... 3
1.2.2 SNMPv1/SNMPv2c.....................................................................................................................................................5
1.2.3 SNMPv3...................................................................................................................................................................... 8
1.3 Application Scenarios for SNMP................................................................................................................................. 10
1.4 Licensing Requirements and Limitations for SNMP....................................................................................................11
1.5 Summary of SNMP Configuration Tasks..................................................................................................................... 12
1.6 Default Settings for SNMP...........................................................................................................................................13
1.7 Configuring a Device to Communicate with an NMS by Running SNMPv1..............................................................14
1.7.1 Configuring Basic SNMPv1 Functions..................................................................................................................... 15
1.7.2 (Optional) Restricting Management Rights of the NMS...........................................................................................17
1.7.3 (Optional) Configuring the Trap Function.................................................................................................................19
1.7.4 (Optional) Enabling the SNMP Extended Error Code Function............................................................................... 20
1.7.5 Verifying the Configuration.......................................................................................................................................21
1.8 Configuring a Device to Communicate with an NMS by Running SNMPv2c............................................................ 21
1.8.1 Configuring Basic SNMPv2c Functions................................................................................................................... 22
1.9 Configuring a Device to Communicate with an NMS by Running SNMPv3..............................................................28
1.9.1 Configuring Basic SNMPv3 Functions..................................................................................................................... 29
1.10 Checking SNMP Packet Statistics.............................................................................................................................. 36
1.11 Configuration Examples for SNMP............................................................................................................................36
1.11.1 Example for Configuring the Device to Communicate with the NM Station Using SNMPv1............................... 36
1.11.2 Example for Configuring the Device to Communicate with the NM Station Using SNMPv2c............................. 40
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. vii

1.11.3 Example for Configuring the Device to Communicate with the NM Station Using SNMPv3............................... 43
1.12 Troubleshooting SNMP.............................................................................................................................................. 47
1.12.1 The SNMP Host Cannot Connect to the NMS........................................................................................................ 47
1.12.2 NM Station Fails to Receive Traps Sent from the Host.......................................................................................... 48
2 RMON and RMON2 Configuration........................................................................................ 50

2.1 Overview of RMON and RMON2............................................................................................................................... 50
2.2 Understanding RMON and RMON2............................................................................................................................ 52
2.3 Licensing Requirements and Limitations for RMON.................................................................................................. 55
2.4 Configuring RMON......................................................................................................................................................55
2.4.1 Configuring RMON Statistics Collection..................................................................................................................55
2.4.2 Configuring RMON Alarm Functions.......................................................................................................................56
2.5 Configuring RMON2....................................................................................................................................................58
2.5.1 Configuring RMON2 Statistics Collection................................................................................................................58
2.6 Configuration Examples for RMON and RMON2.......................................................................................................60
2.6.1 Example for Configuring RMON..............................................................................................................................60
2.6.2 Example for Configuring RMON2............................................................................................................................63
3 TCP FPM Configuration............................................................................................................ 66

3.1 Overview of TCP FPM.................................................................................................................................................66
3.2 Understanding TCP FPM............................................................................................................................................. 67
3.3 Application Scenarios for TCP FPM............................................................................................................................69
3.4 Licensing Requirements and Limitations for TCP FPM.............................................................................................. 69
3.5 Default Settings for TCP FPM..................................................................................................................................... 69
3.6 Configuring TCP FPM................................................................................................................................................. 70
3.6.1 Enabling TCP FPM................................................................................................................................................... 70
3.6.2 (Optional) Enabling Reporting of TCP FPM Statistics to the Controller..................................................................70
3.7 Clearing TCP FPM Statistics........................................................................................................................................71
3.8 Configuration Examples for TCP FPM........................................................................................................................ 71
3.8.1 Example for Configuring TCP FPM......................................................................................................................... 72
4 IP FPM Configuration................................................................................................................ 74
4.1 Overview of IP FPM.....................................................................................................................................................74
4.2 Understanding IP FPM................................................................................................................................................. 75
4.2.1 Basic Concepts.......................................................................................................................................................... 75
4.2.2 Function Implementation...........................................................................................................................................77
4.3 Application Scenarios for IP FPM................................................................................................................................80
4.4 Licensing Requirements and Limitations for IP FPM..................................................................................................82
4.5 Default Settings for IP FPM......................................................................................................................................... 82
4.6 Configuring IP FPM..................................................................................................................................................... 83
4.6.1 Configuring the MCP................................................................................................................................................ 83
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. viii

4.6.2 Configuring the DCP................................................................................................................................................. 86

4.7 Monitoring the IP FPM Running Status....................................................................................................................... 91
4.8 Configuration Examples for IP FPM............................................................................................................................92
4.8.1 Example for Configuring IP FPM End-to-End Performance Measurement............................................................. 92
5 CWMP Configuration...............................................................................................................113
5.1 Overview of CWMP................................................................................................................................................... 113
5.2 Understanding CWMP................................................................................................................................................114
5.2.1 CWMP Network Model...........................................................................................................................................114
5.2.2 CWMP Implementation...........................................................................................................................................115
5.2.3 CPE Management.................................................................................................................................................... 119
5.3 Application Scenarios for CWMP.............................................................................................................................. 120
5.4 Licensing Requirements and Limitations for CWMP................................................................................................ 121
5.5 Default Settings for CWMP....................................................................................................................................... 121
5.6 Configuring CWMP................................................................................................................................................... 121
5.6.1 Enabling CWMP......................................................................................................................................................122
5.6.2 Configuring the CWMP Connection....................................................................................................................... 122
5.6.3 Configuring CWMP Authentication........................................................................................................................124
5.6.4 (Optional) Configuring the CWMP Uploading Function........................................................................................125
5.6.5 Verifying the Configuration.....................................................................................................................................126
5.7 Configuration Examples for CWMP.......................................................................................................................... 126
5.7.1 Example for Configuring CWMP............................................................................................................................126
5.8 Troubleshooting CWMP.............................................................................................................................................129
5.8.1 Failure to Manage CPE Using CWMP....................................................................................................................129
5.9 FAQ About CWMP.................................................................................................................................................... 130
5.9.1 How Can an AR Router Correctly Connect to an ACS?......................................................................................... 130
6 LLDP Configuration................................................................................................................. 131

6.1 Overview of LLDP..................................................................................................................................................... 131
6.2 Understanding LLDP..................................................................................................................................................132
6.2.1 LLDP Implementation............................................................................................................................................. 132
6.2.2 LLDP Frame Format............................................................................................................................................... 133
6.2.3 Transmission and Reception Mechanisms...............................................................................................................137
6.2.4 LLDP Networking................................................................................................................................................... 137
6.3 Licensing Requirements and Limitations for LLDP.................................................................................................. 139
6.4 Default Settings for LLDP..........................................................................................................................................139
6.5 Configuring Basic LLDP Functions........................................................................................................................... 139
6.5.1 Enabling LLDP........................................................................................................................................................140
6.5.2 (Optional) Disabling LLDP on an Interface............................................................................................................ 140
6.5.3 (Optional) Configuring an LLDP Management IP Address....................................................................................141
6.5.4 (Optional) Configuring LLDP Time Parameters..................................................................................................... 141
6.5.5 (Optional) Configuring the Interface Initialization Delay....................................................................................... 142
6.5.6 (Optional) Configuring the Type of TLVs that an Interface Can Send................................................................... 143
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. ix

6.5.7 (Optional) Configuring LLDP Packet Authentication on an Interface....................................................................144

6.6 Configuring the LLDP Alarm Function..................................................................................................................... 145
6.6.1 Setting the Delay in Sending Traps About Neighbor Information Changes........................................................... 145
6.6.2 Enabling the LLDP Trap Function.......................................................................................................................... 146
6.7 Maintaining LLDP......................................................................................................................................................146
6.7.1 Clearing LLDP Statistics......................................................................................................................................... 147
6.7.2 Monitoring LLDP Status......................................................................................................................................... 147
6.8 Configuration Examples for LLDP............................................................................................................................ 147
6.8.1 Example for Configuring LLDP on a Device that Has a Single Neighbor............................................................. 147
6.8.2 Example for Configuring LLDP on a Network with Link Aggregation Configured.............................................. 150
6.9 FAQ About LLDP.......................................................................................................................................................154
6.9.1 What Are LLDP Functions?.................................................................................................................................... 154
6.9.2 How Do I View LLDP Neighbors?......................................................................................................................... 154
6.9.3 What Interfaces Support LLDP?............................................................................................................................. 154
7 NQA Configuration.................................................................................................................. 155

7.1 Overview of NQA...................................................................................................................................................... 156
7.2 Understanding NQA................................................................................................................................................... 156
7.3 Test Mechanisms........................................................................................................................................................ 157
7.3.1 DHCP Test............................................................................................................................................................... 157
7.3.2 DNS Test..................................................................................................................................................................158
7.3.3 FTP Test...................................................................................................................................................................158
7.3.4 HTTP Test................................................................................................................................................................159
7.3.5 ICMP Jitter Test.......................................................................................................................................................160
7.3.6 ICMP Test................................................................................................................................................................161
7.3.7 LSP Ping Test.......................................................................................................................................................... 161
7.3.8 LSP Trace Test.........................................................................................................................................................162
7.3.9 SNMP Test...............................................................................................................................................................163
7.3.10 TCP Test................................................................................................................................................................ 163
7.3.11 Trace Test...............................................................................................................................................................164
7.3.12 UDP Test................................................................................................................................................................165
7.3.13 UDP Jitter Test.......................................................................................................................................................165
7.3.14 UDP Jitter (Hardware-based) Test.........................................................................................................................166
7.4 NQA Association Mechanism.................................................................................................................................... 167
7.5 Application Scenarios for NQA................................................................................................................................. 167
7.6 Summary of NQA Configuration Tasks..................................................................................................................... 168
7.7 Licensing Requirements and Limitations for NQA....................................................................................................168
7.8 Configuring the Response to UDP Tests Initiated by a Third-party Device or NMS Software.................................169
7.9 Configuring an NQA Test Instance............................................................................................................................ 170
7.9.1 Configuring a DHCP Test Instance......................................................................................................................... 171
7.9.2 Configuring a DNS Test Instance............................................................................................................................ 172
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. x

7.9.3 Configuring an FTP Download Test Instance......................................................................................................... 174

7.9.4 Configuring an FTP Upload Test Instance.............................................................................................................. 175
7.9.5 Configuring an HTTP Test Instance........................................................................................................................ 178
7.9.6 Configuring an ICMP Test Instance........................................................................................................................ 179
7.9.7 Configuring an ICMP Jitter Test Instance............................................................................................................... 182
7.9.8 Configuring an SNMP Query Test Instance............................................................................................................ 184
7.9.9 Configuring a TCP Test Instance.............................................................................................................................185
7.9.10 Configuring a Trace Test Instance......................................................................................................................... 187
7.9.11 Configuring a UDP Test Instance.......................................................................................................................... 189
7.9.12 Configuring a UDP Jitter Test Instance................................................................................................................. 191
7.9.13 Configuring a Hardware-based UDP Jitter Test Instance......................................................................................194
7.9.14 Configuring the LSP Ping Test.............................................................................................................................. 196
7.9.15 Configuring the LSP Trace Test............................................................................................................................ 199
7.9.16 Verifying the Configuration...................................................................................................................................201
7.10 Configuring the NQA Transmission Delay Threshold and Alarm Threshold..........................................................202
7.10.1 Configuring the Two-Way Transmission Delay Threshold................................................................................... 202
7.10.2 Configuring the One-Way Transmission Delay Threshold................................................................................... 203
7.10.3 Configuring Alarm Thresholds..............................................................................................................................204
7.11 Configuring the Trap Function................................................................................................................................. 205
7.11.1 Enabling the NQA Alarm Function....................................................................................................................... 205
7.11.2 Configuring the NQA Client to Send Traps When a Test Fails.............................................................................206
7.11.3 Configuring the NQA Client to Send Traps When a Probe Fails.......................................................................... 207
7.11.4 Configuring Trap Sending Upon Probe Result Changes....................................................................................... 207
7.11.5 Configuring the NQA Client to Send Traps After a Probe Succeeds.................................................................... 208
7.11.6 Configuring the NQA Client to Send Traps When the Transmission Delay Exceeds the Threshold....................208
7.11.7 Verifying the Configuration................................................................................................................................... 208
7.12 Configuring the NQA Client to Send Test Results to an FTP Server.......................................................................209
7.12.1 Configuring Parameters for Connecting to an FTP Server....................................................................................209
7.12.2 Enabling the Function of Saving NQA Test Results Through FTP.......................................................................210
7.12.3 (Optional) Configuring File Parameters for Saving Test Results Through FTP................................................... 211
7.12.4 (Optional) Enabling the NQA Client to Send Traps to the NMS After Test Results Are Sent to the FTP........... 211
7.13 Scheduling an NQA Test Instance............................................................................................................................212
7.13.1 Starting an NQA Test Instance.............................................................................................................................. 213
7.13.2 (Optional) Stopping an NQA Test Instance...........................................................................................................214
7.13.3 Checking Test Results............................................................................................................................................215
7.14 Clearing NQA Test Statistics....................................................................................................................................215
7.15 Configuration Examples for NQA............................................................................................................................216
7.15.1 Example for Configuring a DHCP Test Instance.................................................................................................. 216
7.15.2 Example for Configuring a DNS Test Instance..................................................................................................... 217
7.15.3 Example for Configuring an FTP Download Test Instance...................................................................................219
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xi

7.15.4 Example for Configuring an FTP Upload Test Instance....................................................................................... 221

7.15.5 Example for Configuring an HTTP Test Instance................................................................................................. 223
7.15.6 Example for Configuring an ICMP Test Instance................................................................................................. 225
7.15.7 Example for Configuring an ICMP Jitter Test.......................................................................................................226
7.15.8 Example for Configuring an SNMP Query Test Instance..................................................................................... 228
7.15.9 Example for Configuring a TCP Test Instance......................................................................................................230
7.15.10 Example for Configuring a Trace Test Instance.................................................................................................. 232
7.15.11 Example for Configuring a UDP Test Instance................................................................................................... 234
7.15.12 Example for Configuring a UDP Jitter Test Instance.......................................................................................... 235
7.15.13 Example for Configuring NQA to Check VoIP Service Jitter............................................................................. 238
7.15.14 Example for Configuring a Threshold for the NQA Alarm................................................................................ 240
7.15.15 Example for Sending Trap Massages to the NMS When the Threshold Is Exceeded.........................................242
7.15.16 Example for Configuring Test Results to Be Sent to the FTP Server................................................................. 246
7.15.17 Example for Configuring the LSP Ping Test for a Common Tunnel...................................................................248
7.15.18 Example for Configuring the LSP Trace Test for the TE Tunnel........................................................................251
7.15.19 Example for Configuring the LSP Trace Test for Checking the CR-LSP Hotstandby Tunnel........................... 254
7.16 Troubleshooting NQA.............................................................................................................................................. 258
7.16.1 A UDP Jitter Test Instance Fails to Be Started......................................................................................................258
7.16.2 A Drop Record Exists in the UDP Jitter Test Result............................................................................................. 259
7.16.3 A Busy Record Exists in the UDP Jitter Test Result............................................................................................. 260
7.16.4 A Timeout Record Exists in the UDP Jitter Test Result........................................................................................260
7.16.5 The UDP Jitter Test Result Is "Failed", "No Result", or "Packet Loss"................................................................261
7.17 FAQ About NQA......................................................................................................................................................262
7.17.1 How Can I View the Result of an NQA Test Instance?.........................................................................................262
8 LSDP Configuration................................................................................................................. 263

8.1 Overview of LSDP..................................................................................................................................................... 263
8.2 Understanding LSDP.................................................................................................................................................. 264
8.3 Application Scenarios for LSDP................................................................................................................................ 265
8.4 Licensing Requirements and Limitations for LSDP...................................................................................................266
8.5 Configuring LSDP...................................................................................................................................................... 266
8.6 Configuration Examples for LSDP.............................................................................................................................267
8.6.1 Example for Configuring LSDP.............................................................................................................................. 267
9 Service Diagnosis Configuration........................................................................................... 269

9.1 Overview of Service Diagnosis.................................................................................................................................. 269
9.2 Configuration Notes................................................................................................................................................... 270
9.3 Configuring Service Diagnosis...................................................................................................................................271
9.4 Maintaining Service Diagnosis...................................................................................................................................272
10 Mirroring Configuration........................................................................................................274
10.1 Overview of Mirroring............................................................................................................................................. 274
10.2 Understanding Mirroring.......................................................................................................................................... 275
10.2.1 Concepts................................................................................................................................................................ 275
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xii

10.2.2 Local Port Mirroring..............................................................................................................................................276

10.2.3 Flow Mirroring...................................................................................................................................................... 277
10.3 Licensing Requirements and Limitations for Mirroring...........................................................................................278
10.4 Configuring Mirroring.............................................................................................................................................. 280
10.4.1 Configuring Local Port Mirroring......................................................................................................................... 280
10.4.1.1 Configuring a Local Observing Port.................................................................................................................. 280
10.4.1.2 Configuring a Local Mirrored Port.....................................................................................................................280
10.4.1.3 Checking the Configuration................................................................................................................................281
10.4.2 Configuring Local Traffic Mirroring..................................................................................................................... 281
10.4.2.1 Configuring a Local Observing Port.................................................................................................................. 281
10.4.2.2 Configuring a Traffic Classifier..........................................................................................................................282
10.4.2.3 Checking the Configuration................................................................................................................................286
10.5 Configuration Examples for Mirroring.....................................................................................................................286
10.5.1 Example for Configuring 1:1 Local Port Mirroring.............................................................................................. 286
10.5.2 Example for Configuring N:1 Local Port Mirroring............................................................................................. 288
10.5.3 Example for Configuring Local Traffic Mirroring................................................................................................ 290
10.6 FAQ About Mirroring...............................................................................................................................................293
10.6.1 How Many Ports Can Mirror Traffic to One Observing Port?.............................................................................. 293
10.6.2 If Mirroring Is Configured on the Main Interface, Will the Traffic of the Sub-interface Be Mirrored to the
Observing Port?................................................................................................................................................................ 293
10.6.3 Can an Interface Be Configured as a Mirroring Port and an Observing Port at the Same Time?......................... 293
11 Packet Capture Configuration.............................................................................................. 294

11.1 Overview of Packet Capture..................................................................................................................................... 294
11.2 Licensing Requirements and Limitations for Packet Capture.................................................................................. 295
11.3 Configuring the Device to Capture Packets..............................................................................................................295
11.4 Configuration Examples for Packet Capture............................................................................................................ 296
11.4.1 Example for Configuring Packet Capture Function.............................................................................................. 296
12 NetStream Configuration.......................................................................................................298
12.1 Overview of NetStream............................................................................................................................................ 299
12.2 Understanding NetStream.........................................................................................................................................300
12.2.1 NetStream Implementation....................................................................................................................................300
12.2.2 NetStream Packet Sampling.................................................................................................................................. 302
12.2.3 NetStream Flows................................................................................................................................................... 303
12.2.4 NetStream Flow Aging.......................................................................................................................................... 303
12.2.5 NetStream Flow Statistics Exporting.................................................................................................................... 304
12.3 Application Scenarios for NetStream....................................................................................................................... 306
12.4 Licensing Requirements and Limitations for NetStream......................................................................................... 306
12.5 Default Settings for NetStream.................................................................................................................................307
12.6 Configuring Exporting of IPv4 Unicast Original Flow Statistics.............................................................................308
12.6.1 Configuring NetStream Sampling......................................................................................................................... 308
12.6.2 Configuring NetStream Flow Aging..................................................................................................................... 312
12.6.3 Configuring NetStream Original Flow Statistics Exporting..................................................................................313
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xiii

12.6.4 Configuring Versions for Exported Packets.......................................................................................................... 314

12.6.5 Configuring NetStream Statistics Collection........................................................................................................ 314
12.7 Configuring IPv4 Multicast Original Flow Statistics Exporting.............................................................................. 315
12.7.3 Configuring NetStream Original Flow Statistics Exporting..................................................................................320
12.8 Configuring IPv4 Aggregation Flow Statistics Exporting....................................................................................... 322
12.8.3 Configuring NetStream Aggregation Flow Statistics Exporting........................................................................... 327
12.9 Configuring IPv4 Flexible Flow Statistics Exporting.............................................................................................. 330
12.9.1 Configuring a Flexible Flow Statistics Template.................................................................................................. 330
12.9.4 Configuring NetStream Flexible Flow Statistics Exporting..................................................................................336
12.10 Configuring Exporting of Statistics about Flows That Fail the RPF Check.......................................................... 339
12.10.1 Configuring NetStream Sampling....................................................................................................................... 339
12.10.2 Configuring NetStream Flow Aging................................................................................................................... 343
12.10.3 Configuring NetStream RPF Check Failure Flow Statistics Exporting.............................................................. 344
12.10.4 Configuring Versions for Exported Packets........................................................................................................ 345
12.10.5 Configuring NetStream Statistics Collection...................................................................................................... 345
12.10.6 Verifying the Configuration.................................................................................................................................346
12.11 Configuring NetStream Interface Index Length..................................................................................................... 347
12.12 (Optional) Configuring the Function of Aggregating Site Visitor Traffic on an Interface.....................................347
12.13 Clearing NetStream Statistics................................................................................................................................. 348
12.14 Configuration Examples for NetStream................................................................................................................. 348
12.14.1 Example for Configuring IPv4 Original Flow Statistics Exporting.................................................................... 348
12.14.2 Example for Configuring IPv4 Aggregation Flow Statistics Exporting..............................................................351
12.14.3 Example for Configuring IPv4 Flexible Flow Statistics Exporting.................................................................... 354
13 IP Accounting Configuration................................................................................................ 358

13.1 Overview of IP Accounting...................................................................................................................................... 358
13.2 Licensing Requirements and Limitations for IP Accounting................................................................................... 360
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xiv

13.3 Configuring IP Accounting...................................................................................................................................... 360

13.3.1 (Optional) Configuring an IP Accounting Rule.................................................................................................... 360
13.3.2 (Optional) Configuring Statistics Table Upper Thresholds................................................................................... 361
13.3.3 (Optional) Configuring the Aging Time................................................................................................................361
13.3.4 Enabling IP Accounting.........................................................................................................................................362
13.4 Maintaining IP Accounting...................................................................................................................................... 363
13.4.1 Displaying IP Accounting Statistics...................................................................................................................... 363
13.4.2 Clearing IP Accounting Statistics..........................................................................................................................363
13.5 Configuration Examples for IP Accounting............................................................................................................. 364
13.5.1 Example for Configuring IP Accounting...............................................................................................................364
14 TWAMP Light Configuration............................................................................................... 367

14.1 Overview of TWAMP Light..................................................................................................................................... 367
14.2 Understanding TWAMP Light..................................................................................................................................368
14.3 Application Scenarios for TWAMP Light................................................................................................................ 370
14.4 Licensing Requirements and Limitations for TWAMP Light.................................................................................. 370
14.5 Default Settings for TWAMP Light..........................................................................................................................371
14.6 Configuring TWAMP Light......................................................................................................................................371
14.6.1 Configuring the TWAMP Light Responder...........................................................................................................371
14.6.2 Configuring the TWAMP Light Controller........................................................................................................... 372
14.7 Configuration Examples for TWAMP Light............................................................................................................ 374
14.7.1 Example for Configuring the TWAMP Light Service in Continual Mode............................................................374
14.7.2 Example for Configuring the TWAMP Light Service in On-Demand Mode........................................................376
15 AR and Controller Interconnection Configuration.......................................................... 379

15.1 Overview of AR and Controller Interconnection Configuration..............................................................................379
15.2 Understanding AR and Controller Interconnection Configuration.......................................................................... 380
15.3 Application Scenarios for AR and Controller Interconnection Configuration.........................................................381
15.4 Summary of AR and Controller Interconnection Configuration Tasks.................................................................... 381
15.5 Licensing Requirements and Limitations for AR and Controller Interconnection...................................................385
15.6 Connecting an AR to the Controller......................................................................................................................... 385
15.6.1 Configuring Network Connection Between Components of Routers and Controller Cloud Management Platform
.......................................................................................................................................................................................... 385
15.6.2 Connecting Routers to the Controller Cloud Management Platform.................................................................... 389
15.6.3 Adding an AR to the Controller............................................................................................................................ 389
15.6.4 (Optional) Enabling Reporting of Statistics to the Controller............................................................................... 390
15.7 Configuration Examples for AR and Controller Interconnection.............................................................................391
15.7.1 Example for Connecting AR routers to Controller Through Factory Setting....................................................... 391
15.7.2 Example for Connecting AR routers to Controller Through USB-based Deployment......................................... 393
15.7.3 Example for Connecting AR routers to Controller Through DHCP..................................................................... 396
15.7.4 Example for Connecting Routers (without OSP Daughter Card) to Controller.................................................... 398
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xv

15.7.5 Example for Connecting Routers (with OSP Daughter Card) to Controller......................................................... 400
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xvi

and Monitoring 1 SNMP Configuration
1 SNMP Configuration
About This Chapter
This chapter describes how to configure Simple Network Management Protocol (SNMP) to
manage network elements.
Context
The Simple Network Management Protocol (SNMP) is a standard network management
protocol widely used on TCP/IP networks. The SNMP framework uses a central computer
where the network management software is installed to manage network elements. This
central computer is called network management station (NMS). SNMP provides three SNMP
versions: SNMPv1, SNMPv2c, and SNMPv3. An SNMP system can run one or more SNMP
versions.
NOTE
A lack of authentication capabilities in SNMPv1 and SNMPv2c results in vulnerability to security threats, so
SNMPv3 is recommended.
1.1 Overview of SNMP

1.2 Understanding SNMP
1.3 Application Scenarios for SNMP
1.4 Licensing Requirements and Limitations for SNMP
1.5 Summary of SNMP Configuration Tasks
1.6 Default Settings for SNMP
1.7 Configuring a Device to Communicate with an NMS by Running SNMPv1
1.8 Configuring a Device to Communicate with an NMS by Running SNMPv2c
1.9 Configuring a Device to Communicate with an NMS by Running SNMPv3
1.10 Checking SNMP Packet Statistics
1.11 Configuration Examples for SNMP
1.12 Troubleshooting SNMP
Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. 1

1.1 Overview of SNMP
Definition
The SNMP is a standard network management protocol that is widely used on TCP/IP
networks. The SNMP framework uses a central computer where the network management
software is installed to manage network elements. This central computer is called a network
management station (NMS). SNMP offers simplicity and power.
l Simplicity: SNMP is applicable to small-scale networks that are sensitive to speed and
cost because it uses a polling mechanism and provides basic network management
functions. Moreover, most network devices support the UDP packets carrying SNMP
messages.
l Power: SNMP allows management information exchange between arbitrary devices on a
network, so that a network administrator can query information and locate faults on any
device.
Purpose
As network size rapidly develops and applications become more diversified, network
administrators face the following problems:
l The fast growth of network devices increases network administrators' workloads. In
addition, networks' coverage areas are constantly being expanded, making real-time
monitoring and fault location of network devices difficult.
l Various devices are located on networks, and the management interfaces that different
vendors provide use different standards. This makes network management complex.
SNMP was developed to address these problems. SNMP supports batch network device
management and implements unified management regardless of the differences in device
types and vendors.
Version Evolution
SNMPv1 is the initial version of the SNMP protocol. It is described in RFC 1157 drafted in
May 1990. RFC 1157 provides a systematic method for monitoring and managing networks.
However, SNMPv1 cannot ensure the security of networks because it is implemented based
on community names and provides only a few error codes.
In 1996, the Internet Engineering Task Force (IETF) released RFC 1901 in which SNMPv2c
is defined. SNMPv2c uses GetBulk and Inform operations and provides more error codes and
data types (including Counter64 and Counter32).
SNMPv2c still lacks security protection measures, so IETF released SNMPv3. SNMPv3
provides user security module (USM)-based encryption and authentication and a view-based
access control model (VACM).
Benefits
l Improves administrators' work efficiency. A network administrator can use SNMP to
query information, modify information, and locate faults on any device.

l Reduces management costs. SNMP provides a basic function set to manage devices that
have different management tasks, physical attributes, and network types.
l Reduces the impact of feature configuration operations on devices. SNMP is simple in
terms of hardware/software installation, packet type, and packet format.
1.2 Understanding SNMP
1.2.1 SNMP Management Model

An SNMP system consists of four key components: network management station (NMS),
agent, management object, and Management Information Base (MIB).
The NMS manages network elements on a network.
Each managed device contains an agent process, MIB, and multiple management objects. The
NMS interacts with the agent on a managed device. When receiving a command from the
NMS, the agent performs operations on the MIB in the managed device.
Figure 1-1 shows an SNMP management model.
Figure 1-1 SNMP management model
NMS
Agent
MIB
Management
object
Managed device
The components in an SNMP-managed system are as follows:
l NMS
The NMS is a manager on a network that uses SNMP to monitor and control network
devices. The NMS software runs on NMS servers to implement the following functions:
– Send requests to agents on managed devices to query or modify variables.
– Receive traps sent from agents on managed devices to learn device status.

l Agent
The agent is a process running on a managed device. The agent maintains data on the
managed device, responds to request packets from the NMS, and returns management
data to the NMS.
– Upon receiving a request packet from the NMS, the agent performs the required
operation on the MIB and sends the operation result to the NMS.
– When a fault or an event occurs on the managed device, the agent sends a
notification containing the current device status to the NMS.
l Management object
A management object is an object to be managed on a network device. A managed
device contains multiple management objects, for example, a hardware component and
parameters configured for the hardware or software (such as a route selection protocol).
l MIB
An MIB contains the variables that the managed device maintains and can be queried or
set by the agent. MIB defines the attributes of the managed device, including the name,
status, access rights, and data type of management objects.
An agent can use the MIB to:
– Learn device status.
– Set device status.
Similar to the Domain Name System (DNS), the SNMP MIB uses a tree structure with
its root on the top without a name. Figure 1-2 shows a part of the MIB, called an object
naming tree. Each object identifier (OID) maps a management object; for example, the
system OID is 1.3.6.1.2.1.1 and the interfaces OID is 1.3.6.1.2.1.2.
The OID tree facilitates information management and improves management efficiency.
With the OID tree, the network administrator can query information in a batch.
When configuring the agent, you can specify the MIB objects that the NMS can access in
MIB views. An MIB view is a subset of an MIB.

Figure 1-2 OID tree

root
ccitt(0) iso(1) Joint-iso-ccitt(2)
org(3)
dod(6)
internet(1)
Directory(1) mgmt(2) experimental(3) private(4)
mib(1) OID:1.3.6.1.2 enterprises(1)
system(1) interface(2) at(3) ip(4) icmp(5) tcp(6) udp(7) ...
... ... ... ... ... ... ...
1.2.2 SNMPv1/SNMPv2c
SNMPv1/SNMPv2c Packet Format
As shown in Figure 1-3, an SNMPv1/SNMPv2c packet is composed of the version,
community name, and SNMP Protocol Date Unit (PDU) fields.
Figure 1-3 SNMPv1/SNMPv2c packet format
IP UDP Community
Version SNMP PDU
header header name
The fields in an SNMPv1/SNMPv2c packet are as follows:

l Version: specifies the SNMP version. The value for SNMPv1 is 0 and for SNMPv2c is 1.
l Community name: used in the authentication of agents and NMSs. The community name
is a character string and can be defined by users. There are two types of community
names: read and write.
– Read community names are used for the GetRequest and GetNextRequest
operations.

– Write community names are used for the Set operation.

l SNMPv1/SNMPv2c PDU: includes the PDU type, request ID, and binding variable list.
– The SNMPv1 PDU includes GetRequest PDU, GetNextRequest PDU, SetRequest
PDU, Response PDU, and Trap PDU.
– The SNMPv2c PDU inherits the fields of SNMPv1 PDU and introduces the
GetBulkRequest PDU.
For simplification, the SNMP operations are described as the Get, GetNext, Set,
Response, Trap, and GetBulk operations.
SNMPv1/SNMPv2c Operations
As shown in Table 1-1, SNMPv1/SNMPv2c defines six types of operations for exchanging
information between the NMS and agents.
Table 1-1 SNMPv1/SNMPv2c operations

Operation Description
Get Retrieves one or several variables from the MIB of the agent process.
GetNext Retrieves the next variables in alphabetic order from the MIB of the
agent process.
Set Sets one or several variables in the MIB of the agent process.
Response Returns one or several variables. The agent performs this operation in
response to the GetRequest, GetNextRequest, SetRequest, and
GetBulkRequest operations. Upon receiving a Get or Set request from the
NMS, the agent queries or modifies the variables in the MIB, and returns
variables to the NMS.
Trap Notifies the NMS of a fault or event occurring on a managed device. This
operation is performed by the agent.
GetBulk Queries variables on managed devices in a batch. This operation is

performed by the NMS.
Working Mechanisms of SNMPv1/SNMPv2c

The working mechanisms of SNMPv1 and SNMPv2c are similar, as shown in Figure 1-4.
Figure 1-4 Basic operations

GetRequest
Response
GetNextRequest
Response
NMS SetRequest Agent
UDP Port162 Response UDP Port161
Trap

l Get
In this example, the NMS intends to use the read community name public to obtain the
value of the sysContact object on a managed device. The procedure is as follows:
a. The NMS sends a GetRequest packet to the agent. The fields in the packet are as
follows:
n Version: SNMP version that the NMS is using
n Community name: public
n PDU type: Get
n MIB object: sysContact
b. The agent authenticates the SNMP version and community name in the packet.
When authentication is successful, the agent encapsulates the sysContact value into
the PDU of a response packet and sends the response packet to the NMS. If the
agent fails to obtain the sysContact value, the agent returns an error message to the
NMS.
l GetNext
In this example, the NMS intends to use the community name public to obtain the value
of the sysName object (next to sysContact) on a managed device. The procedure is as
follows:
a. The NMS sends a GetNextRequest packet to the agent. The fields in the packet are
as follows:
n Community name: public
n PDU type: GetNext
When authentication is successful, the agent encapsulates the sysName value into
the PDU of a response packet and sends the response packet to the NMS. If the
agent fails to obtain the sysName value, the agent returns an error message to the
NMS.
l Set
In this example, the NMS intends to use the read community name private to set the
sysName object on a managed device to HUAWEI. The procedure is as follows:
a. The NMS sends a SetRequest packet to the agent. The fields in the packet are as
follows:
n Community name: private
n PDU type: Set
n Expected MIB object value: HUAWEI
When authentication is successful, the agent sets the sysContact object to the
expected value and sends a response packet to the NMS. If the setting fails, the
agent returns an error message to the NMS.

l Trap
Trap is a spontaneous activity of a managed device. The Trap operation is not a basic
operation that the NMS performs on the managed device. If a trap triggering condition is
met, a managed device sends a trap to the NMS to notify the NMS of the exception. For
example, when a managed device completes a hot start, the agent sends a warmStart trap
to the NMS.
The agent sends a trap to the NMS only when a module on the managed device meets the
trap triggering condition. This mechanism reduces management information exchange
between the NMS and managed devices.
Figure 1-5 shows the operations that are added in SNMPv2c.
Figure 1-5 Operations added in SNMPv2c
GetBulkRequest
Response
NMS Agent
UDP Port162 InformRequest UDP Port161
InformResponse
l GetBulk
A GetBulk operation is equal to consecutive GetNext operations. You can set the number
of GetNext operations to be included in one GetBulk operation.
1.2.3 SNMPv3
SNMPv3 Packet Format

SNMPv3 defines a new packet format, as shown in Figure 1-6.
Figure 1-6 SNMPv3 packet format
IP UDP Header Security Context Context

Version SNMP PDU
header header data parameters EngineID Name
The composition of an SNMPv3 packet is as follows:
l Version: specifies the SNMP version. The value for SNMPv3 is 2.

l Header: includes information such as the maximum message size that the transmitter
supports and the security mode of messages.
l Security parameters: includes the entity engine information, user name, authentication
parameter, and encryption information.

l Context EngineID: indicates the unique SNMP ID. This field and the PDU together
determine to which application the PDUs are to be sent.
l Context Name: determines the Context EngineID MIB view of the managed device.
l SNMPv3 PDU: includes the PDU type, request ID, and binding variable list. The
SNMPv3 PDU includes GetRequest PDU, GetNextRequest PDU, SetRequest PDU,
Response PDU, Trap PDU, and GetBulkRequest PDU.
SNMPv3 Architecture
SNMPv3 provides SNMPv3 entities through which all SNMP-enabled NMSs can manage
SNMP-enabled network elements. An SNMPv3 entity consists of SNMPv3 engines and
applications, and each SNMPv3 engine or application has multiple modules.
The modular architecture of the SNMPv3 entity has the following advantages:
l Strong adaptability: This architecture is adaptable for both simple and complex
networks.
l Simple management: This architecture consists of multiple independent sub-systems and
applications. When a fault occurs in an SNMP system, it is easy to locate the sub-system
where the fault originated based on the fault type.
l Good expansibility: Modules can be added to an SNMP entity to extend an SNMP
system. For example, a module can be added to the security subsystem to run a new
security protocol.
SNMPv3 improves security through the user security model (USM) and view-based access
control model (VACM):
l USM: provides a shared key between the NMS and agents to authenticate user identities
and encrypt data.
– Identify authentication: a process in which an agent (or NMS) determines whether a
received message is from an authorized NMS (or agent) and whether the message
has been modified during transmission. Keyed-Hashing for Message Authentication
Code (HMAC) uses the security hash function and key to generate message
authentication codes. The HMAC tool is widely used on the Internet. HMAC
mechanisms that SNMP uses include HWAC-MD5-96 and HWAC-SHA-96. The
hash function of HWAC-MD5-96 is MD5, which uses a 128-bit authKey to
generate keys. The hash function of HWAC-SHA-96 is SHA-1, which uses a 160-
bit authKey to generate keys.
– Data encryption: Like identity authentication, data encryption also requires the
network management station and the agent to use a shared key for encryption or
decryption. ESP encrypts the IP packet contents to prevent them from being
intercepted during transmission. Encryption algorithms are implemented using a
symmetric key system, which uses the same key to encrypt and decrypt data. SNMP
uses the following encryption algorithms:
n Data Encryption Standard (DES): encrypts 64-bit plain text by using a 56-bit
key.
n Advanced Encryption Standard (AES): encrypts plain text by using a key of
128 bits, 192 bits, or 256 bits.
l VACM: controls access of user groups or community names based on views. You must
pre-configure a view and specify its authority. Then, when you configure a user, user
group, or community, you must load this view to implement read/write restrictions or
trap functions.

SNMPv3 Mechanism
SNMPv3 has the same mechanism as SNMPv1 and SNMPv2c, except that SNMPv3 supports
identity authentication and encryption. The following uses the Get operation as an example to
describe the SNMPv3 mechanism.
As shown in Figure 1-7, an NMS intends to obtain the value of the sysContact object on a
managed device in authentication and encryption mode.
Figure 1-7 Get operation of SNMPv3
GetRequest without security parameters for

obtaining parameter values
Return corresponding parameter values
NMS GetRequest with security parameters Agent

UDP Port162 Response UDP Port161
1. The NMS sends a GetRequest packet without security parameters to the agent and
requests the values of Context EngineID, Context Name, and security parameter.
2. The agent returns a response that contains the requested parameters.
3. The NMS sends a GetRequest packet to the agent again. The fields in the packet are as
follows:
– Version: SNMPv3.
– Header: authentication and encryption modes.
– Security parameters: The NMS calculates the authentication and encryption
parameters in accordance with the security parameters obtained from the agent, and
fills the authentication, encryption, and security parameters in the corresponding
fields.
– PDU: The NMS fills the obtained Context EngineID and Context Name in the
corresponding fields. The PDU type is set to Get, the MIB object name is
sysContact, and the configured encryption algorithm is used to encrypt the PDU.
4. The agent authenticates the GetRequest packet sent from the NMS. When authentication
is successful, the agent decrypts the PDU. When encryption is successful, the agent
obtains the value of sysContact and encapsulates it in the response packet to the PDU.
The agent encrypts the PDU and sends the response packet to the NMS. If any of the
query, authentication, or encryption operations fail, the agent sends an error message to
the NMS.
1.3 Application Scenarios for SNMP
SNMP Application
The network administrator needs to configure and manage all devices on the network shown
in Figure 1-8; however, it is impossible for the network administrator to configure and

manage all the sparsely-located devices on site. These devices are from different vendors and
provide different management interfaces, which makes network management complex. To
reduce operation cost and improve work efficiency, the network administrator can use SNMP
to remotely manage, configure, and monitor network devices.
Figure 1-8 SNMP application
LAN
Agent
NMS LAN
IP Network
SNMP
LAN
Agent
LAN
To configure SNMP on the network, configure the NMS program on the management end and
agent on each managed device.
SNMP allows:
l The NMS to learn managed device status by sending requests to agents and control the
devices remotely.
l Each agent to report the managed device status and faults to the NMS in real time.
1.4 Licensing Requirements and Limitations for SNMP
Involved Network Elements

None
Licensing Requirements
SNMP is a basic feature of a router and is not under license control.
Feature Limitations
When deploying SNMP on the router, pay attention to the following:
l Users without administrator rights cannot view SNMP configurations.

l AR100&AR120 series (except AR129CV&AR129CVW&AR129CGVW-L) do not
support SNMP.

1.5 Summary of SNMP Configuration Tasks

This section compares SNMP versions in terms of their support for features and usage
scenarios to provide a reference for your SNMP version selection during network deployment.
The device supports SNMPv1, SNMPv2c, and SNMPv3. Table 1-2 lists the features
supported by SNMP, and Table 1-3 shows the support of different SNMP versions for the
features. Table 1-4 describes the usage scenarios of SNMP versions, which helps you choose
a proper version for the communication between an NMS and managed devices based on the
network operation conditions.
NOTE
When multiple NMSs using different SNMP versions manage the same device in a network SNMPv1,
SNMPv2c, and SNMPv3 are configured on the device for its communication with all the NMSs.
Table 1-2 Description of features supported by SNMP

Feature Description
Access control This function is used to restrict a user's device administration

rights. It gives specific users the rights to manage specified objects
on devices and therefore provides fine management.
Authentication and The authentication and privacy packets are transmitted between the
privacy NMS and managed devices. This prevents data packets from being
intercepted or modified, improving data sending security.
Error code Error codes help the administrator to identify and rectify faults. It is
easy for the administrator to manage the device if the error codes
are more with variety.
Trap Traps are sent from managed devices to the NMS. Traps help
administrator to know device faults.
The managed devices do not require the acknowledgement from
the NMS after sending traps.
GetBulk GetBulk allows an administrator to perform Get-Next operations in

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

Feature SNMPv1 SNMPv2c SNMPv3
Access control Access control Access control Access control

based on the based on the based on the user,
community name community name user group, and
and MIB view and MIB view MIB view

Feature SNMPv1 SNMPv2c SNMPv3
Authentication and Authentication Authentication Supported

privacy based on the based on the authentication and
community name community name privacy modes are
as follows:
Authentication
mode:
l MD5
l SHA
Encryption mode:
l DES56
l AES128
Error code 6 error codes 16 error codes 16 error codes

supported supported supported
Trap Supported Supported Supported
GetBulk Not supported Supported Supported
Table 1-4 Usage scenarios of different SNMP versions
Version Usage Scenario
SNMPv1 Applicable to small networks with simple networking and low

security requirements or small networks with good security and
stability, such as campus networks and small enterprise networks.
SNMPv2c Applicable to medium and large networks with low security

requirements or with good security (for example, VPNs) but on
which services are so busy that traffic congestion may occur.
SNMPv3 Applicable to networks of various scales, especially networks that

have strict security requirements and can be managed only by
authorized network administrators. For example, SNMPv3 can be
used if data between the NMS and managed device needs to be
transmitted over a public network.
If you plan to build a network, choose an SNMP version based on your usage scenario. If you
plan to expand or upgrade an existing network, choose an SNMP version to match the SNMP
version running on the NMS to ensure the communication between managed devices and the
NMS.
1.6 Default Settings for SNMP

Table 1-5 lists the default settings of SNMP.

Table 1-5 Default settings for SNMP
Parameter Default Setting
SNMP agent Disabled
SNMP trap receive None

host
SNMP version SNMPv3
SNMPv3 No authentication and no encryption

authentication and
encryption
1.7 Configuring a Device to Communicate with an NMS

by Running SNMPv1
Context
To allow a device to communicate with an NMS running SNMPv1, configure SNMPv1 on the
device. The SNMP parameters must be configured on both the managed device (agent) and
NMS. This section describes only the SNMP configurations on the agent side. For details
about SNMP configurations on an NMS, see the NMS operation guide.
A lack of authentication capabilities in SNMPv1 and SNMPv2c results in vulnerability to

security threats, so SNMPv3 is recommended.
Pre-configuration Tasks
Before configuring the router to communicate with an NMS through SNMPv1, configure a
routing protocol to ensure that a reachable route exists between the router and NMS.
Configuration Process
When you configure the router to communicate with the NMS using SNMPv1, only
Configuring Basic SNMPv1 Functions is mandatory and the optional steps are performed in
any sequence.
After the SNMP basic functions are configured, the router and NMS can communicate with
each other.
l The NMS using the specified community name can access the Viewdefault view. The
internet MIB (OID: 1.3.6.1) and the lagMIB (OID: 1.2.840.10006.300.43) can be
operated in this view.
l The managed device sends traps generated by the modules that are enabled by default to
the NMS.
The following are more configurations related to SNMPv1:

l To allow the NMS that uses the specified community name to manage specified objects
on the device, perform the operations in Restricting Management Rights of the NMS.

l To allow a specified module on the managed device to report traps to the NMS, perform
the operations in Configuring the Trap Function.
l If the NMS and managed device are both Huawei products, perform the operations in
Enabling the SNMP Extended Error Code Function to allow the device to send more
types of error codes. This allows more specific error identification and facilitates your
fault location and rectification.
1.7.1 Configuring Basic SNMPv1 Functions

Context
For the configuration of basic SNMP functions, Step 1, Step 5, Step 6, Step 7 and Step 8 are
mandatory steps. After the configuration is complete, basic SNMP communication can be
established between the NMS and managed device.
Procedure
Step 1 Run system-view
The system view is displayed.
Step 2 (Optional) Run snmp-agent server-source { -a [ ipv6 ] source-ip-address | -i [ ipv6 ]
interface-type interface-number }
The source IP address used by the SNMP server to send packets is specified.
By default, the SNMP server uses source IP address 0.0.0.0 to send packets.
If the default value 0.0.0.0 is not changed, the device selects a source IP address according to
routing entries to send packets. When an ACL is configured to filter incoming and outgoing
packets on a device, the ACL rules are configured based on interface IP addresses, and packet
filtering is affected by interface status. You can select a stable interface as the source
interface, for example, the loopback interface. Setting the source or destination address in an
ACL rule as a stable interface's address can simplify the configurations of ACL rules and
security policies. In addition, packet filtering will not be affected by interface IP addresses
and interface status, and device security is improved.
Step 3 (Optional) Run snmp-agent
The SNMP agent is enabled.
By default, the SNMP agent is disabled. Executing the snmp-agent command can enable the
SNMP Agent no matter whether a parameter is specified in the command.
Step 4 (Optional) Run snmp-agent source loopback
A Loopback interface is configured as the source interface that sends packets.
By default, the source interface for sending packets is a physical outbound interface.
After the NMS sends a get operation request to the device, the device replies with a response
packet. The response packet carries source interface information. The device uses the IP
address of this interface as the source address of packets. When an ACL is configured on the
NMS to filter the packets sent from the device, the ACL rules vary according to source
interface IP addresses, and communication may be affected by interface status. After a
Loopback interface is configured as the source interface for response packets, the impact of
source address difference and interface status can be avoided by specifying the source address

in an ACL rule as this Loopback interface address. This configuration allows the device to
filter outgoing packets and protect security. In addition, the configurations of ACL rules and
security policies are simplified.
Step 5 Run snmp-agent sys-info version v1
The SNMP version is set to SNMPv1.
By default, the device supports SNMPv3. After you set the SNMP version to SNMPv1, the
device supports both SNMPv1 and SNMPv3, and can be managed by NMSs running
SNMPv1 and SNMPv3.
Step 6 Run snmp-agent community { read | write } community-name
The read/write community name is set.
By default, no read/write community name is configured.
By default, the complexity check for community names is enabled. The complexity
requirements are as follows:
l The community name contains at least six characters.
l The community name must be a combination of at least two of the following: uppercase
letters, lowercase letters, digits, and special characters (excluding spaces). If the string is
enclosed in double quotation marks (" "), the string can contain spaces.
If the check fails, the community name cannot be configured.
To change the access right of the NMS, see Restricting Management Rights of the NMS.
Ensure that the community name of the NMS is the same as that set on the agent. If the NMS
and the agent use different community names, the NMS cannot access the agent.
The configured community names are stored in cipher text in the configuration file. To save
the community name in the configuration file as plain text, run the snmp-agent community
simple { read | write } community-name [ mib-view view-name | acl acl-number ]*
command.
Step 7 Run snmp-agent target-host trap-paramsname paramsname v1 securityname
securityname [ binding-private-value ] [ private-netmanager ]
Parameters for sending trap messages are set.
By default, the parameters for sending trap messages are not set.
Step 8 Run snmp-agent target-host trap-hostname hostname address { ipv4-addr [ udp-port udp-
portid ] [ public-net | vpn-instance vpn-instance-name ] | ipv6 ipv6-addr [ udp-port udp-
portid ] } trap-paramsname paramsname [ notify-filter-profile profile-name ]
The target host for receiving trap messages and error codes is specified.
By default, the target host for receiving trap messages and error codes is not specified.
NOTE
Before configuring a device to send traps, confirm that the information center has been enabled. If the
information center is not enabled, run the info-center enable command to enable it.
Note the following when running the command:

l The default destination UDP port number is 162. To ensure secure communication
between the NMS and managed devices, run the udp-port command to change the UDP
port number to a non-well-known port number.

l If traps sent from the managed device to the NMS need to be transmitted over a public
network, the public-net parameter needs to be configured. If traps sent from the
managed device to the NMS need to be transmitted over a private network, the vpn-
instance vpn-instance-name parameter needs to be configured to specify a VPN that will
take over the transmission task.
Step 9 (Optional) Run snmp-agent sys-info { contact contact | location location }
The equipment administrators contact information or location is configured.
By default, the vendor's contact information is "R&D Shenzhen, Huawei Technologies

Co.,Ltd." The default location is "Shenzhen China."
This step is required for the NMS administrator to view contact information and locations of
the equipment administrator when the NMS manages many devices. This helps the NMS
administrator to contact the equipment administrators for fault location and rectification.
To configure both the equipment administrators contact information and location, run the
snmp-agent sys-info command twice.
----End
1.7.2 (Optional) Restricting Management Rights of the NMS
Context
When multiple NMSs using the same community name manage one device, perform this
configuration based on the site requirements.
Scenario Steps
All NMSs using this community name No action required

access the ViewDefault view.
Only the specified NMSs using this Step 1, Step 3

community name access the
ViewDefault view.
All NMSs using this community name Step 1, Step 2, Step 3

access the specified objects on the
managed device.
Only the specified NMSs using this Step 1, Step 2, Step 3

community name access the specified
objects on the managed devices.
The NMS can connect to only the Step 1, Step 4

specified physical interfaces on the
managed device.
NOTE
The ViewDefault view are the 1.3.6.1 view and 1.2.840.10006.300.43 view.
When an ACL is used to control the NMS access rights, the constraints are as follows:

l When the ACL rule is permit, the NMS with the source IP address specified in this rule
can access the local device.
l When the ACL rule is deny, the NMS with the source IP address specified in this rule
cannot access the local device.
l If a packet does not match an ACL rule, the NMS that sends the packet cannot access the
local device.
l When no ACL rule is configured, all NMSs can access the local device.
Procedure
Step 2 Run snmp-agent mib-view view-name { exclude | include } subtree-name [ mask mask ]
A MIB view is created, and manageable MIB objects are specified.
By default, an NMS has right to access the objects in the ViewDefault view.
If both the included and excluded parameters are configured for MIB objects that have an
inclusion relationship, whether to include or exclude the lowest MIB object will be
determined by the parameter configured for the lowest MIB object. For example, the snmpV2,
snmpModules, and snmpUsmMIB objects are from top down in the MIB table. If the
excluded parameter is configured for snmpUsmMIB objects and included is configured for
snmpV2, snmpUsmMIB objects will still be excluded.
Step 3 Configure NMS filtering based on community name.
1. (Optional) Configure the basic ACL.
Before configuring the access control rights, you must create a basic ACL. For the
creation procedure, see "ACL Configuration" in the Huawei AR Series Access Routers
Configuration Guide-Security.
2. Run the snmp-agent community { read | write } community-name [ mib-view view-
name | acl acl-number ] * command to specify the NMS's access right.
By default, the created community name allows the NMS to access the ViewDefault
view.
– To grant only the read permission to low-level administrators, specify the parameter
read. To grant the read and write permissions to high-level administrators, specify
the parameter write.
– If the NMSs using this community name can access the ViewDefault view, the
parameter mib-view view-name is not required.
– If all NMSs using this community name manage specified objects on the managed
devices, the acl acl-number parameter is not required.
– If some NMSs using this community name manage specified objects on the
managed devices, the acl and mib-view parameters must be configured.
NOTE
If both community name and ACL are configured, the NMS checks the community name and then
the ACL before accessing the device.
Step 4 Run snmp-agent permit interface { interface-type interface-number } &<1-5>

Physical interfaces on the device to which the NMS can connect are specified.
By default, the NMS can connect to all the physical interfaces on the device.
----End
Follow-up Procedure
After the access right is configured, especially after the IP address of the NMS is specified, if
the IP address changes (for example, the NMS changes its location, or IP addresses are
reallocated due to network adjustment), you need to change the IP address of the NMS in the
ACL. Otherwise, the NMS cannot access the device.
1.7.3 (Optional) Configuring the Trap Function

Context
Users can enable the trap function for a specified module. The interface status trap is
generated when the interface status changes. You need to enable the trap function for the ifnet
module globally and enable the trap function on the specified interface.
Procedure
Step 2 Enable the trap function.
Enable the trap function for a module.
l To enable the trap function of all modules, run the snmp-agent trap enable command.
l To enable the trap function of a specified module, run the snmp-agent trap enable
feature-name command.
l To restore the trap functions of all modules to the default status, run the undo snmp-
agent trap enable or undo snmp-agent trap disable command.
Enable the trap function for an interface.
Run the snmp-agent trap enable feature-name ifnet trap-name { linkdown | linkup }
command to enable interface status trap globally.
By default, the trap function is disabled on all interfaces. When the linkdown and linkup
parameters are configured for ifnet module, the device sends a trap to the NMS upon an
interface status change. When an interface frequently sends traps to the NMS because of
frequent status changes, you can disable the interface status trap function on the interface to
reduce the NMS loads. The procedure is as follows:
1. Run the interface interface-type interface-number command to enter the interface view.
2. Run the undo enable snmp trap updown command to disable the interface status trap
function.
3. Run the quit command to return to the system view.
Step 3 Run snmp-agent notify-filter-profile { exclude | include } profile-name oid-tree
A trap filtering rule is created or updated.

By default, traps are not filtered.

Step 4 Run snmp-agent trap source interface-type interface-number
The source interface for sending traps is specified.
By default, source interface of traps is not set. After the source interface is specified, the IP
address of the source interface is used as the source IP address for sending traps. This helps
the NMS identify the trap source. The source interface that sends traps must have an IP
address; otherwise, the commands will fail to take effect. To ensure device security, it is
recommended that you set the source IP address to the local loopback address.
The source interface set on the router must be consistent with that specified on the NMS.
Otherwise, the NMS does not accept the traps sent from the router.
Step 5 Run snmp-agent trap queue-size size
The queue length of traps sent to the target host is set.
The default queue length of traps sent to the target host is 100.
The queue length depends on the number of generated traps. If the router frequently sends
traps to the NMS, set a longer queue length to prevent traps from being lost.
Step 6 Run snmp-agent trap life seconds
The lifetime of traps is set.
The default lifetime of traps is 120 seconds.
The lifetime of each trap depends on the number of generated traps. If the router frequently
sends traps to the NMS, set a longer lifetime to prevent traps from being lost.
----End
1.7.4 (Optional) Enabling the SNMP Extended Error Code

Function
Context
If the NMS and managed device are Huawei devices, error codes are extended and more
scenarios are defined after the function of sending extended error codes is enabled. As a
result, users are enabled to locate and troubleshoot faults quickly and accurately.
Procedure
Step 2 Run snmp-agent extend error-code enable
The extended error code function is enabled.
By default, SNMP sends only standard error codes. More error codes will be sent to the NMS
after the extended error code function is enabled.
----End

1.7.5 Verifying the Configuration
Prerequisites
The configurations of basic SNMPv1 functions are complete.
Procedure
l Run the display snmp-agent community { read | write } command to check
community names.
l Run the display snmp-agent sys-info version command to check the enabled SNMP
version.
l Run the display acl acl-number command to check ACL rules.
l Run the display snmp-agent mib-view command to check MIB views.
l Run the display snmp-agent sys-info contact command to check the administrator's
contact information.
l Run the display snmp-agent sys-info location command to check the location of the
router.
l Run the display current-configuration | include trap command to check the
configuration of the trap function.
l Run the display snmp-agent trap all command to check current and default status of all
traps of all features.
l Run the display snmp-agent trap-source command to check the source interface for
sending traps.
l Run the display snmp-agent target-host command to check information about the
target host.
l Run the display snmp-agent extend error-code status command to check whether the
device is enabled to send extended error codes to the NMS.
----End

by Running SNMPv2c
Context
To allow a device to communicate with an NMS running SNMPv2c, configure SNMPv2c on
the device. The SNMP parameters must be configured on both the managed device (agent)
and NMS. This section describes only the SNMP configurations on the agent side. For details
A lack of authentication capabilities in SNMPv1 and SNMPv2c results in vulnerability to

security threats, so SNMPv3 is recommended.
Before configuring a device to communicate with an NMS by running SNMPv2c, configure a
routing protocol to ensure that at least one route exists between router and NMS.

When you configure a device to communicate with the NMS using SNMPv2c, Configuring
Basic SNMPv2c Functions is mandatory and optional steps can be performed in any
sequence.
After the SNMP basic functions are configured, the router and NMS can communicate with
each other.
the NMS.
The following are more configurations related to SNMPv2c:

l To allow an NMS that uses a specified community name to manage specified objects on
the device, perform the operations in Restricting Management Rights of the NMS.
Enabling the SNMP Extended Error Code Function to allow the managed device to
send more types of error codes. More error codes facilitate your fault location and
rectification.
1.8.1 Configuring Basic SNMPv2c Functions
Context
For the configuration of basic SNMP functions, Step 1, Step 4, Step 5, Step 6 and Step 7 are
mandatory steps. After the configurations are complete, the NMS and managed device can
communicate with each other using SNMP.
Procedure


Step 4 Run snmp-agent sys-info version v2c
The SNMP version is set to SNMPv2c.
By default, the device supports SNMPv3. If the SNMP version is set to SNMPv2c, the device
supports both SNMPv2c and SNMPv3, and can be managed by NMSs running SNMPv2c and
SNMPv3.
Step 5 Run snmp-agent community { read | write } community-name
The read/write community name is set.
By default, no read/write community name is configured.
By default, the complexity check for community names is enabled. The complexity
requirements are as follows:
l The community name contains at least six characters.
l The community name must be a combination of at least two of the following: uppercase
letters, lowercase letters, digits, and special characters (excluding spaces). If the string is
enclosed in double quotation marks (" "), the string can contain spaces.
If the check fails, the community name cannot be configured.
To change the access right of the NMS, see Restricting Management Rights of the NMS.
Ensure that the community name of the NMS is the same as that set on the agent. If the NMS
and the agent use different community names, the NMS cannot access the agent.
The configured community names are stored in cipher text in the configuration file. To save
the community name in the configuration file as plain text, run the snmp-agent community
simple { read | write } community-name [ mib-view view-name | acl acl-number ]*
command.
Step 6 Run snmp-agent target-host trap-paramsname paramsname v2c securityname

securityname [ binding-private-value ] [ private-netmanager ]
Parameters for sending traps are set.
A host is specified to receive traps and error codes.
NOTE
Before configuring a device to send traps, confirm that the information center has been enabled. To enable the
information center, run the info-center enable command.
Note the following points when running the commands:

between the NMS and managed devices, change the UDP port number to a non-well-
known port number by using the udp-port command.


----End
Context
When multiple NMSs using the same community name manage one device, perform this
Scenario Steps
All NMSs using this community name No action required

access the ViewDefault view.
Only the specified NMSs using this Step 1, Step 3

community name access the
ViewDefault view.
All NMSs using this community name Step 1, Step 2, Step 3

access the specified objects on the
managed device.
Only the specified NMSs using this Step 1, Step 2, Step 3

community name access the specified
The NMS can connect to only the Step 1, Step 4

specified physical interfaces on the
managed device.
NOTE
The ViewDefault view are the 1.3.6.1 view and 1.2.840.10006.300.43 view.

local device.
Procedure
Step 3 Configure NMS filtering based on community name.
1. (Optional) Configure the basic ACL.
Before configuring the access control rights, you must create a basic ACL. For the
creation procedure, see "ACL Configuration" in the Huawei AR Series Access Routers
2. Run the snmp-agent community { read | write } community-name [ mib-view view-
name | acl acl-number ] * command to specify the NMS's access right.
By default, the created community name allows the NMS to access the ViewDefault
view.
– To grant only the read permission to low-level administrators, specify the parameter
read. To grant the read and write permissions to high-level administrators, specify
the parameter write.
– If the NMSs using this community name can access the ViewDefault view, the
parameter mib-view view-name is not required.
– If all NMSs using this community name manage specified objects on the managed
devices, the acl acl-number parameter is not required.
– If some NMSs using this community name manage specified objects on the
managed devices, the acl and mib-view parameters must be configured.
NOTE
If both community name and ACL are configured, the NMS checks the community name and then
the ACL before accessing the device.

----End
Follow-up Procedure
After the access right is configured, especially after the IP address of the NMS is specified, if
the IP address changes (for example, the NMS changes its location, or IP addresses are
reallocated due to network adjustment), you need to change the IP address of the NMS in the
ACL. Otherwise, the NMS cannot access the device.

Context
Procedure
function.


----End

Function
Context
Procedure
----End


Prerequisites
The configurations of basic SNMPv2c functions are complete.
Procedure
l Run the display snmp-agent community { read | write } command to check
community names.
version.
router.
l Run the display current-configuration | include trap command to check trap
configuration.
sending traps.
target host.
function that the device sends extended error codes to the NMS is enabled.
----End

by Running SNMPv3
To allow a device to communicate with an NMS running SNMPv3, configure SNMPv3 on the
device. The SNMP parameters must be configured on both the managed device (agent) and
NMS. This section describes only the SNMP configurations on the agent side. For details
Before configuring a device to communicate with an NMS by running SNMPv3, configure a
routing protocol to ensure that at least one route exists between router and NMS.
When you configure the device to communicate with the NMS using SNMPv3, Configuring
Basic SNMPv3 Functions is mandatory and optional steps can be performed in any
sequence.

After the SNMP basic functions are configured, the NMS can communicate with managed
devices.
the NMS.
The following are more configurations related to SNMPv3:
l To allow an NMS that uses a specified community name to manage specified objects on
the device, perform the operations in Restricting Management Rights of the NMS.
Enabling the SNMP Extended Error Code Function to allow the managed device to
send more types of error codes. More error codes facilitate your fault location and
rectification.
1.9.1 Configuring Basic SNMPv3 Functions

Precaution
When configuring security levels, ensure that the target host has the highest security level,
users have the middle security level, and user groups have the lowest security level.
SNMPv3 uses the following security levels, which are listed in a descending order:
l privacy: authentication and encryption
l authentication: only authentication
l none: no authentication and no encryption
For example, if the security level of a user group is privacy, the security levels of users and
trap host must be privacy; if the security level of a user group is authentication, the security
levels of users and trap host can be privacy or authentication.
Procedure

Step 4 (Optional) Run snmp-agent sys-info version v3
The SNMP version is set.
By default, the device supports SNMPv3.
Step 5 (Optional) Run snmp-agent local-engineid { engineid | sysname }
An engine ID is set for the local SNMP entity.
By default, the device automatically generates an engine ID using the internal algorithm. The
engine ID is composed of enterprise number and the device information.
If you change an automatically generated engine ID to a manually set one, the SNMPv3 user
matching the engine ID is deleted.
Step 6 Run snmp-agent group v3 group-name { authentication | noauth | privacy } [ notify-view
notify-view ]
An SNMPv3 user group is configured.
If the NMS or network devices are in an insecure environment (for example, the network is
vulnerable to attacks), authentication or privacy can be configured in the command to
enable data authentication or privacy.
NOTE
l Specify the parameter notify-view notify-view when the device needs to send a trap to the NMS.
l Allow different user groups to use the same group name. The groups with the same name can use
different authentication modes, for example, authentication + encryption and non-authentication + non-
encryption. You can select authentication modes as required.
l Configuring different modes for the groups with the same name may lead to misoperations or an
unexpected authentication result. In addition, if one authentication mode is set to non-authentication +
non-encryption, there will be a security risk.
Step 7 Run snmp-agent usm-user v3 user-name [ group group-name | acl acl-number ] *

A user is added to the SNMPv3 user group.
Step 8 Run snmp-agent usm-user v3 user-name authentication-mode { md5 | sha }
An authentication password is configured for the SNMPv3 user.
MD5 encryption algorithm cannot ensure security, and SHA encryption algorithm is
recommended.
Step 9 Run snmp-agent usm-user v3 user-name privacy-mode { aes128 | des56 }
An encryption password is configured for the SNMPv3 user.
After a user is added to the user group, the NMS that uses the name of the user can access the
objects in the ViewDefault view (OID: 1.3.6.1 and OID: 1.2.840.10006.300.43). If you

change an automatically generated engine ID to a manually set one, the SNMPv3 user
matching the engine ID is deleted.
If authentication and privacy have been enabled for the user group, the following
authentication and privacy modes can be configured for the data transmitted on the network.
AES128 algorithm is recommended as it improves data transmission security.
Step 10 Run snmp-agent target-host trap-paramsname paramsname v3 securityname

securityname { authentication | noauthnopriv | privacy } [ binding-private-value ]
[ private-netmanager ]
Parameters for sending traps are set.
The target host for receiving traps and error codes is specified.
NOTE
Before configuring a device to send traps, confirm that the information center has been enabled. To enable the
information center, run the info-center enable command.
Note the following points when running the commands:
between the NMS and managed devices, change the UDP port number to a non-well-
known port number by running the udp-port command.

----End
Context
When multiple NMSs in the same SNMPv3 user group manage one device, perform this

Scenario Steps
All NMSs in this SNMPv3 user No action required

group access the ViewDefault
view.
Only the specified NMSs in this Step 1, Step 2, Step 4 (based on the user group)
SNMPv3 user group access the
ViewDefault view. Step 1, Step 5, Step 6 (based on the user)
Step 1, Step 2, Step 4, Step 5, Step 6 (based on the

user group and user)
All NMSs in this SNMPv3 user Step 1, Step 3, Step 4

group access the specified
The specified NMSs in this Step 1, Step 2, Step 3, Step 4 (based on the user
SNMPv3 user group access the group)
specified objects on the managed
devices. Step 1, Step 3, Step 4, Step 5, Step 6 (based on the
user)
Step 1, Step 2, Step 3, Step 4, Step 5, Step 6 (based

on the user group and user)
The NMS can connect to only Step 1, Step 7

the specified physical interfaces
on the managed device.
local device.
Procedure
Step 2 Configure a basic ACL for an SNMP user group to allow only the NMS matching the ACL to
access the managed device.
For the creation procedure, see "ACL Configuration" in the Huawei AR Series Access Routers

Step 4 Run snmp-agent group v3 group-name { authentication | noauth | privacy } [ read-view

read-view | write-view write-view | notify-view notify-view | acl acl-number ] *
The write-read right is configured for a user group.
By default, the read-only view of an SNMP user group is the ViewDefault view, and the
names of the read-write view and inform view are not specified.
To configure the NMS to receive traps specified by notify-view, you must first configure a
target host for receiving traps.
Step 5 Configure a basic ACL for an SNMP user to allow only the NMS matching the ACL to access
the managed device.
For the creation procedure, see "ACL Configuration" in the Huawei AR Series Access Routers
Step 6 Run snmp-agent usm-user v3 user-name [ group group-name | acl acl-number ] *
Authentication and encryption are configured for SNMPv3 users in the specified user group.
l To allow all NMSs using the same SNMPv3 user name to access the agent, do not
specify the acl parameter.
l To allow only the specified NMSs using this user name to access the agent, configure the
acl parameter.
----End
Follow-up Procedure
If the NMS allowed to access the managed device changed its IP address due to a reason, for
example, location change or IP address reallocation, change the IP address in the ACL rule
accordingly; otherwise, the NMS cannot access the managed device.
Context

Procedure
function.


----End

Function
Context
Procedure
----End

Prerequisites
The configurations of basic SNMPv3 functions are complete.
Procedure
l Run the display snmp-agent usm-user [ user-name ] command to check user
information.
l Run the display snmp-agent group [ group-name ] command to check information
about the SNMP user group.
version.

router.
l Run the display current-configuration | include trap command to check trap
configuration.
sending traps.
target host.
function that the device sends extended error codes to the NMS is enabled.
----End
1.10 Checking SNMP Packet Statistics

Procedure
l Run the display snmp-agent statistics command to check SNMP packet statistics.
----End
1.11 Configuration Examples for SNMP
1.11.1 Example for Configuring the Device to Communicate with

the NM Station Using SNMPv1
Networking Requirements
As shown in Figure 1-9, NMS1 and NMS2 manage devices on the existing network. Since
the network is small and has high security, devices are configured to communicate with the
NM station using SNMPv1.
A router is added to the network for capacity expansion and monitored by the NMSs. Users
want to monitor the router using current network resources. To allow the NMS administrator
quickly contact a device administrator to locate and troubleshoot faults on the router, contact
information about the device administrator is required to be configured on the device. Based
on users' service requirements, the NMS is restricted to manage only DNS nodes on the
router.

Figure 1-9 Networking diagram for configuring the device to communicate with the NM
station using SNMPv1
NMS1
10.1.1.1/24
IP Network GE1/0/0
10.1.2.1/24
Router
NMS2
10.1.1.2/24
Configuration Roadmap
Since the network is small and has high security, SNMPv1 can be enabled on the new device.
To reduce the workload of the NM station, NMS2 is used to manage the router. NMS1 does
not manage the router.
The configuration roadmap is as follows:
1. Configure SNMPv1 on the router.
2. Configure user access rights to enable NMS2 to manage DNS nodes on the router.
3. Configure the trap function on the router to send alarms generated on the router to
NMS2. Only modules that are enabled by default can send alarms, which helps locate
alarms and prevent unwanted alarms.
4. Configure contact information about the router administrator to quickly troubleshoot
faults when the router fails.
5. Configure the NM station (only NMS2).
Procedure
Step 1 Configure the IP address and route on the router and ensure the route between the device and
the NMS is reachable.
<Huawei> system-view
[Huawei] sysname Router
[Router] interface gigabitethernet 1/0/0
[Router-GigabitEthernet1/0/0] ip address 10.1.2.1 24
[Router-GigabitEthernet1/0/0] quit
[Router] ospf
[Router-ospf-1] area 0
[Router-ospf-1-area-0.0.0.0] network 10.1.2.0 0.0.0.255
[Router-ospf-1-area-0.0.0.0] quit
[Router-ospf-1] quit
Step 2 Enable the SNMP agent.

[Router] snmp-agent
Step 3 Configure SNMPv1 on the Router.

[Router] snmp-agent sys-info version v1
Step 4 Configure access rights of the NM station.

# Configure ACLs, enable NMS2 to manage the Router, and disable NMS1 from managing
the Router.

[Router] acl 2001

[Router-acl-basic-2001] rule 5 permit source 10.1.1.2 0.0.0.0
[Router-acl-basic-2001] rule 6 deny source 10.1.1.1 0.0.0.0
[Router-acl-basic-2001] quit
# Configure a MIB view.

[Router] snmp-agent mib-view dnsmib include 1.3.6.1.4.1.2011.5.25.194
# Configure the source interface from which traps are sent.

[Router] snmp-agent trap source gigabitethernet 1/0/0
# Configure an SNMP community name and reference the configured ACLs and the MIB
view.
[Router] snmp-agent community write adminnms2 mib-view dnsmib acl 2001
Step 5 Configure the trap function.

[Router] snmp-agent target-host trap-paramsname trapnms2 v1 securityname adminnms2
[Router] snmp-agent target-host trap-hostname nms2 address 10.1.1.2 trap-
paramsname trapnms2
[Router] snmp-agent trap queue-size 200
[Router] snmp-agent trap life 60
[Router] snmp-agent trap enable
Step 6 Configure contact information about the device administrator.

[Router] snmp-agent sys-info contact call Operator at 010-12345678
Step 7 Configure the NM station (NMS2).

Set read and write community names on the NMS that uses SNMPv1. For configurations of
the NMS, refer to related configuration guides.
NOTE
Authentication parameter configuration of the NMS must be the same as that of the device. If the
authentication parameter configuration of the NMS is different from that of the device, the NMS cannot
manage the device. If only the write community name is configured on the device, the read and write
community names on the NMS must be the same as the write community name configured on the
device.
Step 8 Verify the configuration.

After the configuration is complete, run the following commands to verify that the
configurations have taken effect.
# Check the configured SNMP version.
<Router> display snmp-agent sys-info version
SNMP version running in the system:
SNMPv1
# View the community names.

<Router> display snmp-agent community write
Community name: %^%#$X!5#d+t+OJOXL1[{O2!&Fe&0UZv'@a;R/`Y+kK$4BUGFe)&2YLuM/kMF!
HPG5Mzz3DXe2&F%^%#
Storage type: nonVolatile

View name: dnsmib
Acl: 2001
Total number is 1
# Check the configuration of ACLs.

<Router> display acl 2001

Basic ACL 2001, 2 rules

Acl's step is 5
rule 5 permit source 10.1.1.2 0
rule 6 deny source 10.1.1.1 0
# Display the MIB view.

<Router> display snmp-agent mib-view dnsmib
View name: dnsmib
MIB subtree: hwDnsMIB
Subtree mask:
View type: included
View status: active
# Check the target host for alarms.

<Router> display snmp-agent target-host
Traphost list:
Target host name: nms2
Traphost address: 10.1.1.2
Traphost portnumber: 162
Target host parameter: trapnms2
Total number is 1
Parameter list trap target host:

Parameter name of the target host: trapnms2
Message mode of the target host: SNMPV1
Trap version of the target host: v1
Security name of the target host: %^%#_=XqAFC_94uCS,3'<gYC*ZU6%^%#
Total number is 1
# Check contact information about the device administrator.

<Router> display snmp-agent sys-info contact
The contact person for this managed node:
call Operator at 010-12345678
----End
Configuration Files
Configuration file of the Router
#
sysname Router
#
acl number 2001
#
interface GigabitEthernet1/0/0
ip address 10.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
#
snmp-agent local-engineid 800007DB03548998F3A458
snmp-agent community write %^%#$X!5#d+t+OJOXL1[{O2!&Fe&0UZv'@a;R/`Y+kK
$4BUGFe)&2YLuM/kMF!HPG5Mzz3DXe2&F%^%# mib-view dnsmib acl 2001
snmp-agent sys-info contact call Operator at 010-12345678
snmp-agent sys-info version v1
snmp-agent target-host trap-hostname nms2 address 10.1.1.2 udp-port 162 trap-
paramsname trapnms2
snmp-agent target-host trap-paramsname trapnms2 v1 securityname %^
%#_=XqAFC_94uCS,3'<gYC*ZU6%^%#

snmp-agent mib-view dnsmib include hwDnsMIB

snmp-agent trap source gigabitethernet 1/0/0
snmp-agent trap enable
snmp-agent trap queue-size 200
snmp-agent trap life 60
snmp-agent
#
return

the NM Station Using SNMPv2c
the network is small and has high security and a high service traffic volume, devices are
configured to communicate with the NMS using SNMPv2c. A router is added to the network
for capacity expansion and monitored by the NMSs.
Users want to monitor the router using current network resources. To allow the NMS
administrator quickly contact a device administrator to locate and troubleshoot faults on the
router, contact information about the device administrator is required to be configured on the
device. Based on users' service requirements, the NMS is restricted to manage only DNS
nodes on the router.
station using SNMPv2c
NMS1
10.1.1.1/24
IP Network GE1/0/0
10.1.2.1/24
Router
NMS2
10.1.1.2/24
Since the network is small and has high security and a high service traffic volume, SNMPv2c
can be enabled on the new device. To reduce the workload of the NM station, NMS2 is used
to manage the router. NMS1 does not manage the router.
1. Configure SNMPv2c on the router.
4. Configure contact information for the router administrator to quickly troubleshoot faults
when the router fails.

Procedure
[Router] ospf

[Router] snmp-agent
Step 3 Configure SNMPv2c on the Router.

[Router] snmp-agent sys-info version v2c
# Configure ACLs, enable NMS2 to manage the router, and disable NMS1 from managing the
router.
[Router] acl 2001


# Configure an SNMP community name and reference the configured ACLs and the MIB
view.
[Router] snmp-agent community write adminnms2 mib-view dnsmib acl 2001

[Router] snmp-agent target-host trap-paramsname trapnms2 v2c securityname
adminnms2
paramsname trapnms2
Step 6 Check contact information about the device administrator.

Set read and write community names on the NMS that uses SNMPv2. Set the timeout period
and the maximum number of retries. For configurations of the NMS, refer to related
configuration guides.

NOTE
manage the device. If only the write community name is configured on the device, the read and write
community names on the NMS must be the same as the write community name configured on the
device.

# Check the configured SNMP version.
<Router> display snmp-agent sys-info version
SNMP version running in the system:
SNMPv2c
# View the community names.

<Router> display snmp-agent community write
Community name:
View name: dnsmib
Acl: 2001
Total number is 1
# Check the configuration of ACLs.

Acl's step is 5
rule 5 permit source 10.1.1.2 0 (1 matches)

View name: dnsmib
Subtree mask:
View type: included
View status: active

Traphost list:
Total number is 1

Message mode of the target host: SNMPV2C
Trap version of the target host: v2c
Security name of the target host:
Total number is 1



----End
Configuration Files
#
sysname Router
#
acl number 2001
#
ip address 10.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
#
snmp-agent community write %@%@$X!5#d+t+OJOXL1[{O2!&Fe&0UZv'@a;R/`Y+kK
$4BUGFe)&2YLuM/kMF!HPG5Mzz3DXe2&F%@%@ mib-view dnsmib acl 2001
snmp-agent sys-info version v2c
paramsname trapnms2
snmp-agent target-host trap-paramsname trapnms2 v2c securityname %@
%@_=XqAFC_94uCS,3'<gYC*ZU6%@%@
#
return

the NM Station Using SNMPv3
the network is large and has low security, devices are configured to communicate with the
NM station using SNMPv3. Authentication and encryption functions are configured to
enhance network security. A router is added to the network for capacity expansion and
monitored by the NMSs.
Users want to monitor the router using current network resources. To allow the NMS
administrator quickly contact a device administrator to locate and troubleshoot faults on the
device, contact information about the device administrator is required to be configured on the
device. Based on users' service requirements, the NMS is restricted to manage only DNS
nodes on the router.

station using SNMPv3
NMS1
10.1.1.1/24
IP Network GE1/0/0
10.1.2.1/24
Router
NMS2
10.1.1.2/24
Since the network has a small scale and high security but has a high service traffic volume,
SNMPv3 can be enabled on the new device. To reduce the workload of the NM station,
NMS2 is used to manage the router. NMS1 does not manage the router.
1. Configure SNMPv3 on the router.
4. Check contact information about the router administrator to quickly troubleshoot faults
when the router fails.
Procedure
[Router] ospf

[Router] snmp-agent
Step 3 Configure SNMPv3 on the Router.

[Router] snmp-agent sys-info version v3

# Configure ACLs, enable NMS2 to manage the Router, and disable NMS1 from managing
the Router.

[Router] acl 2001



# Configure users and user groups and authenticate and encrypt data.
[Router] snmp-agent usm-user v3 testuser group testgroup

[Router] snmp-agent usm-user v3 testuser authentication-mode sha
Please configure the authentication password (<8-64>)
Enter Password:
Confirm password:
[Router] snmp-agent usm-user v3 testuser privacy-mode aes128
Please configure the privacy password (<8-64>)
Enter Password:
Confirm password:
[Router] snmp-agent group v3 testgroup privacy write-view dnsmib notify-view
dnsmib acl 2001

[Router] snmp-agent target-host trap-paramsname trapnms2 v3 securityname testuser
privacy
paramsname trapnms2
Step 6 Check contact information about the device administrator.


Set users and user groups on the NMS that uses SNMPv3. For configurations of the NMS,
refer to related configuration guides.
NOTE
manage the device.

# View user information.
<Router> display snmp-agent group testgroup
Group name: testgroup

Security model: v3 AuthPriv
Readview: ViewDefault
Writeview: dnsmib
Notifyview: dnsmib
Acl: 2001

# View user information.

<Router> display snmp-agent usm-user
User name: testuser
Engine ID: 800007DB03548998F3A458
Group name: testgroup
Authentication mode: md5, Privacy mode: aes128
User status: active
Total number is 1
# Check the ACLs.

ACL's step is 5
rule 5 permit source 10.1.1.2 0 (1 matches)

View name: dnsmib
Subtree mask:
View type: included
View status: active

Traphost list:
Total number is 1

Message mode of the target host: SNMPV3
Trap version of the target host: v3
Security name of the target host: %@%@_=XqAFC_94uCS,3'<gYC*ZU6%@%@
Security level of the target host: privacy
Total number is 1

----End
Configuration Files
#
sysname Router
#
acl number 2001
#

ip address 10.1.2.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.1.2.0 0.0.0.255
#
snmp-agent sys-info version v3
snmp-agent group v3 testgroup privacy write-view dnsmib notify-view dnsmib acl
2001
paramsname trapnms2
snmp-agent target-host trap-paramsname trapnms2 v3 securityname %@
%@_=XqAFC_94uCS,3'<gYC*ZU6%@%@ privacy
snmp-agent usm-user v3 testuser
snmp-agent usm-user v3 testuser group testgroup
snmp-agent usm-user v3 testuser authentication-mode sha %@%@J>K4RVS=3Px}z#*
+8Qd*"9#Z%@%@
snmp-agent usm-user v3 testuser privacy-mode aes128 %@%@6LH%$%$6LH;^TF:RCg_|
2'%yau%@%@
snmp-agent
#
return
1.12 Troubleshooting SNMP
1.12.1 The SNMP Host Cannot Connect to the NMS
Fault Description
The SNMP host cannot connect to the NMS.
Procedure
Check whether the SNMP configuration on the host is correct according to the following
table.
Table 1-6 SNMP configuration
Item Method Procedure
Check whether the Run the display If the host does not support the SNMP
host supports the snmp-agent sys- version, run the snmp-agent sys-info
SNMP version used info version version command to set the SNMP version
by the NMS for command to view on the host.
sending a login the SNMP version
request. of the host.

Item Method Procedure
View the community Run the display If the community string used by the NMS
string configured on snmp-agent for sending a login request is different from
the host. community that configured on the host, run the snmp-
command. agent community command to configure a
read-write community string, which must be
the same as that configured on the host.
If SNMPv3 is used, l Run the display If information is incorrect, modify the

check whether snmp-agent configurations.
information about the group l Run the snmp-agent group command to
SNMP user group command to view information about the SNMPv3
and users is correct. view user group.
information
about the l Run the snmp-agent usm-user
SNMPv3 user command to view information about the
group. SNMPv3 user.
1.12.2 NM Station Fails to Receive Traps Sent from the Host
Fault Description
The NM station fails to receive alarms sent from the host.
Procedure
Check whether the target host of SNMP traps on the router is correctly configured.
If the target host of SNMP traps is configured incorrectly, see the following configuration
examples.
Table 1-7 Typical configuration of the host that sends traps

Configuration Example Command
Configure a host for <Huawei> system-view

[Huawei] snmp-agent sys-info version v2c
sending trap messages. The [Huawei] snmp-agent target-host trap-paramsname abc
host uses SNMPv2c and v2c securityname huawei
contain no VPN instance [Huawei] snmp-agent target-host trap-hostname aaa
address 192.168.1.1 trap-paramsnam abc
information. The port
number is 162 by default,
the security name is
huawei, and the IP address
is 192.168.1.1.

Configuration Example Command
Configures an SNMPv3 # Configure a MIB view.

user named huawei that <Huawei> system-view
[Huawei] snmp-agent mib-view Huawei_view include iso
belongs to the user group
named huawei_group. The # Configure a user group.
[Huawei] snmp-agent group v3 huawei_group noauth
alarm right (Notify-view) read-view Huawei_view write-view Huawei_view notify-
for the SNMPv3 user is view Huawei_view
Huawei_view, which
# Configure users.
indicates that the user has [Huawei] snmp-agent usm-user v3 huawei group
the right to access all the huawei_group
nodes under the ISO
through SNMP.
Configure a host for <Huawei> system-view

[Huawei] snmp-agent target-host trap-paramsname abc
sending trap messages. The v3 securityname huawei authentication
host uses SNMPv3 and [Huawei] snmp-agent target-host trap-hostname aaa
contain no VPN instance address 192.168.1.1 trap-paramsname abc
information. The port
number is 162 by default,
the security name is
huawei, and the IP address
is 192.168.1.1 (huawei
must be a real user).
Check the status of the trap # Check the status of the trap function.
function. If the trap [Huawei] display snmp-agent trap all
function is disabled, enable # Enable the trap function.
the trap function. [Huawei] snmp-agent trap enable

and Monitoring 2 RMON and RMON2 Configuration
2 RMON and RMON2 Configuration
About This Chapter
This chapter describes how to configure Remote Network Monitoring (RMON) and RMON2.
2.1 Overview of RMON and RMON2

2.2 Understanding RMON and RMON2
2.3 Licensing Requirements and Limitations for RMON
2.4 Configuring RMON
2.5 Configuring RMON2
2.6 Configuration Examples for RMON and RMON2
2.1 Overview of RMON and RMON2
RMON
Remote Network Monitoring (RMON) and RMON2 implementation is based on SNMP and
uses the same network management station (NMS) as SNMP to manage network elements.
RMON, defined by IETF, is a widely used network management protocol. It provides packet
statistics and alarm functions for Ethernet interfaces. The management devices use RMON to
remotely monitor and manage network elements. RMON2 is an enhancement of RMON.
Currently, the device can collect and analyze statistics on IP packets.
SNMP collects statistics about network communication by using the agent software
embedded in the managed devices. The NMS polls the agent to provide network
communication information. The agent then searches the Management Information Base
(MIB) and returns the required information to the NMS. The NMS can manage the network
based on returned information. The MIB counter only records the statistics, but cannot
analyze history information about routine communication. To display traffic volume and
changes on a whole day, the NMS has to keep on polling and analyze network traffic based on
the obtained information.
SNMP polling has the following disadvantages:

l Occupies a large number of network resources. Polling generates many communication

packets. On a large-sized network, congestion may occur or even the network is blocked.
Therefore, SNMP is not applicable to large-sized networks and cannot recycle large
amount of data, such as routing information.
l Increases the burden of network administrators. The network administrators are
responsible for collecting all data using the NMS software. It is difficult for an
administrator to monitor more than three network segments.
IETF develops RMON to improve usability of network management information and lighten
the burden on the NMS and network administrators. Compared with SNMP, RMON is more
applicable to large-sized networks and can monitor traffic on one or multiple network
segments. The characteristics of RMON are as follows:
l SNMP is the basis of RMON, and RMON is an enhancement of SNMP.
RMON is implemented based on the SNMP structure and compatible with SNMP. It
consists of NMS and agents. Network administrators can use the SNMP NMS to
implement RMON without additional training.
l RMON enables SNMP to monitor remote network devices effectively and actively.
Using RMON, managed devices automatically send traps when alarm thresholds are
exceeded. Therefore, the management devices do not need to obtain MIB variables by
continuous polling and comparison. The RMON reduces traffic volume between the
management and managed devices, and allows large-size networks to be more easily and
effectively managed.
RMON defines multiple monitors to collect network management information in either of the
following ways:
l The NMS obtains management information directly from the RMON probe and controls
network resources. This allows the NMS to obtain all RMON MIB information.
l A RMON agent is embedded into a network device, so that the device can provide the
RMON probe function. The NMS uses SNMP protocol to exchange data with the
RMON agent and collect network management information. Due to the limitation on
resources, the NMS can only obtain information about statistics, history, alarms, and
events groups.
Huawei devices have embedded RMON agent. The management device can obtain
information including traffic volume, error packet statistics, and performance statistics of the
entire network segment connected to the interfaces on the managed devices to implement
network monitoring.
RMON2
RMON2 is an extension of RMON, and has the same mechanism as RMON.
RMON and RMON2 both monitor traffic on Ethernet links; however, RMON monitors traffic
at only MAC layer and RMON2 monitors traffic at the upper layers above MAC layer.
RMON2 codes and decodes data packets from Layer 3 to Layer 7 of the OSI model. In
RMON2, the RMON agents provide two major functions:
l Monitor traffic based on network layer protocols and addresses, including IP protocol.
This enables the agent to learn its connected external LAN network segment and monitor
traffic flowing to the LAN through the switch.
l Record the incoming and outgoing traffic of the specific application, such as email, FTP,
and WWW because it can decode and monitor the traffic.

The RMON agent on Huawei devices can collect statistics about IP packets on the network
segments connected to the managed devices, and monitors traffic flowing to these interfaces
from the hosts on the network segments.
2.2 Understanding RMON and RMON2
RMON
Before configuring RMON, you must understand concepts of four groups (statistics, history,
alarm, and event) and Huawei-defined extended alarm group. Before configuring RMON2,
you must understand the concepts of protocolDir and nlHost.
RMON provides packet statistics and alarm functions. The management devices use RMON
to remotely monitor and manage network elements.
RMON uses statistics group and history group to provide Ethernet statistics and history
statistics functions.
l Ethernet statistics (statistics group in RMON MIB): collects basic statistics on each
monitored network. The system keeps on collecting traffic statistics and distribution of
each type of packets on a network segment. Additionally, the system can count the
number of error packets of different types, collisions, CRC error packets, undersized (or
large) packets, broadcast and multicast packets, bytes received, and packets received.
l History statistics (history group in RMON MIB): periodically samples and records
network statistics. The system can periodically collect statistics on each type of traffic,
including bandwidth usage, number of error packets, and total number of packets.
RMON alarm functions include event definition function and alarm threshold setting function.
l Event definition (event group in RMON MIB): controls the events and notifications sent
from the device and provides all events related to RMON agent. When an event occurs,
the system records a log or sends a trap to the NMS.
l Alarm threshold setting (alarm group in RMON MIB): monitors the specified alarm
variables (OID of an object). Based on the user-defined thresholds and sampling time,
the system periodically obtains the specified alarm variables. When the alarm variables
values reach or exceed the rising threshold, a rising threshold alarm event is triggered.
When the alarm variables values reach or fall below the falling threshold, a falling
threshold alarm event is triggered. The RMON agent records the monitored status in log
or sends a trap to the NMS.
RMON standard defines multiple RMON groups. The router supports the Huawei-defined
extended alarm, statistics, history, alarm, and event groups. Details about the groups are as
follows:
l Statistics group
The statistics group keeps on collecting statistics on each type of traffic on Ethernet
interfaces and records statistics results in the etherStatsTable for later retrieval. Traffic
statistics include the number of network collisions, CRC error packets, undersized (or
large) data packets, broadcast packets, multicast packets, received bytes, and received
packets.
After a statistics entry is created on an interface, the statistics group starts collecting
statistics on the packets. The statistics are accumulated.

l History group
The history group periodically collects network status statistics and stores them for
future use.
The history group provides two tables:
– historyControlTable: sets control information such as the sampling interval.
– etherHistoryTable: stores network statistics collected by the history group and
provides the network administrator with history statistics such as the traffic on a
network segment, error packets, broadcast packets, bandwidth usage, and collisions.
l Event group
The defined events are used for the configuration options of alarm group and extended
alarm group. When alarm conditions are met, an event is triggered. RMON event
management is to add events to the specified rows in the event table, and the following
options are supported:
– log: only send log
– trap: only send trap to the NMS
– log-trap: send both log and trap
– none: take no action
l Alarm group
An alarm group presets a set of thresholds for alarm variables, which can be objects in a
local MIB. Based on the user-defined alarmTable, the system periodically obtains the
specified alarm variables. When the alarm variables values reach or exceed the rising
threshold, a rising threshold alarm event is triggered. When the alarm variables values
reach or fall below the falling threshold, the system takes actions according to the action
configuration.
l Extended alarm group
Based on RFC, the extended alarm group has the following new function: set alarm
object and keepalive time using expressions. This group provides the prialarmTable.
Compared with the alarm table defined in RFC, the extended alarm table has the
following new options:
– Extended alarm variable expression. It is the arithmetic expression composed of
alarm variables OIDs (+, -, *, /, or brackets).
– Descriptions of extended alarm entries
– Sampling interval variables
– Extended alarm types: Forever or Cycle. If Cycle is set, no alarm is generated and
the entry is deleted after the specified cycle period expires.
Each entry has a lifetime. When an entry's status is not valid, the entry can exist for a certain
period before it is deleted. The entry is deleted when the lifetime decreases to 0. Table 2-1
shows the capacity of each table and the maximum lifetime of an entry in each table.
Table 2-1 Lifetime of entries in each table

Table Table Size (Bytes) Maximum Lifetime
(Seconds)
etherStatsTable 100 600
historyControlTable 100 600

Table Table Size (Bytes) Maximum Lifetime

(Seconds)
alarmTable 60 6000
eventTable 60 600
logTable 600 -
prialarmTable 60 6000
NOTE
Each entry in the historyControlTable corresponds to a maximum of 10 history records in the

etherHistoryTable. When more than 10 records are generated, the old ones are overwritten.
No maximum lifetime is specified for the entries in logTable. Each event entry in logTable corresponds
to up to 10 logs. When more than 10 logs are generated, the old ones are overwritten.
When an LPU is removed, the etherStatsTable and historyControlTable status is changed to

invalid and the lifetime of entries in the etherStatsTable and historyControlTable is set to 1200
seconds. When the lifetime decreases to 0, the entry is deleted.
When an LPU is inserted, the corresponding entry status is changed to valid.
RMON2
Currently, the router provides two RMON2 MIB groups: protocolDir and nlHost, and the
RMON agent can collect statistics on IP packets. The RMON agent supports three tables:
protocolDirTable, hostTable, and hostControlTable.
The hostTable uses customized indexes to invoke the protocolDirTable and hostControlTable.
The hostTable does not need to be configured when you configure RMON2 traffic statistics
function. After the protocolDirTable and hostControlTable are configured, the hostTable
automatically collect traffic statistics.
l protocolDirTable
Lists the protocols that the RMON agent can resolve and collect statistics on. Each
protocol occupies a row. The protocols include network-layer, transport-layer, and upper-
layer protocols.
l hostTable
Collects traffic statistics on each host and analyzes incoming and outgoing data packets
on interfaces based on IP addresses.
l hostControlTable
Is classified into network-layer hostControlTable and application-layer hostControlTable.
The hostControlTable defines the statistics monitoring interface and records the number
of frames received by the interface but are not recorded into the nlHost table.
Additionally, this table records the number of times entries are added and deleted and the
maximum number of entries in nlHostTable.
Currently, the router supports only network-layer hostControlTable, so it does not control
application-layer host groups. Therefore, only IP protocols can be configured in the
protocolDirTable.

2.3 Licensing Requirements and Limitations for RMON

None
RMON is a basic feature of a router and is not under license control.
Feature Limitations
None
2.4 Configuring RMON
RMON collects traffic statistics and monitors network status on the specified network
segment.
Before configuring RMON, complete the following tasks:
l Configure Ethernet interface parameters.
l Configure basic SNMP functions.
The RMON statistics function and RMON alarm function can be configured in any sequence.
However, if the alarm variables configured in RMON alarm function are MIB variables
defined in the statistics group or history group, the Ethernet statistics function or history
statistics function must be configured on the monitored Ethernet interface first. Otherwise,
alarm entries cannot be created.
2.4.1 Configuring RMON Statistics Collection

Context
RMON statistics include Ethernet statistics and history statistics. The Ethernet and history
statistics collections apply to different scenarios:
l To keep on collecting traffic statistics on an Ethernet interface, configure Ethernet
statistics collection. Ethernet statistics include the number of network collisions, CRC
error packets, undersized (or large) data packets, broadcast packets, multicast packets,
received bytes, and received packets.
l To store the statistics on the specified interface for later retrieval, configure history
statistics collection. History statistics include bandwidth usage, number of error packets,
and total number of packets.

Procedure
l Configure Ethernet statistics collection.
a. Run system-view
b. Run interface interface-type interface-number
The interface view is displayed.
c. Run rmon-statistics enable
RMON statistics collection is enabled on an interface.
d. Run rmon statistics entry-number [ owner owner-name ]
A statistics table is created and an entry is added to the table.
l Configure history statistics collection.
a. Run system-view
b. Run interface interface-type interface-number
c. Run rmon-statistics enable
RMON statistics collection is enabled on an interface.
d. Run rmon history entry-number buckets number interval sampling-interval
[ owner owner-name ]
A history control table is created and an entry is added to the table.
NOTE
l As recommended by the RMON standard, each monitored interface should have more than two
history control entries. One entry is sampled every 30 seconds while another entry is sampled every
30 minutes.
l The short sampling interval enables a monitor for sudden changes of traffic modes, and the long
sampling interval is applicable if the interface status is relatively stable.
l Each history control table stores 10 records. When more than 10 records are generated, the old ones
are overwritten.
l To reduce the impact of RMON on system performance, the sampling interval of the history control
table should be longer than 10 seconds. In addition, an interface cannot be configured with too
many entries for the history control table and alarm table.
l If RMON statistics collection is not enabled on an interface, the number of records in the RMON
statistics table and history table are 0.
----End
2.4.2 Configuring RMON Alarm Functions

Context
RMON alarm functions include event definition function and alarm threshold setting function.
To monitor the system running status, configure the alarm threshold setting function. When an
error occurs in the system, the related event is triggered. The event definition function can
determine whether to log the event or send a trap to the NMS.

NOTE
If the alarm variables configured in RMON alarm function are MIB variables defined in the statistics group or
history group, the Ethernet statistics function or history statistics function must be configured on the
monitored Ethernet interface first.
Procedure
Step 2 Configure event definition function.
Run the rmon event entry-number [ description string ] { log | trap object | log-trap object |
none } [ owner owner-name ] command to create an event table and add an entry to the table.
Step 3 Configure alarm threshold function.
(Optional) Run the snmp-agent trap enable feature-name rmon [ trap-name

{ fallingalarm | risingalarm | rmon_pri_fallingalarm | rmon_pri_risingalarm } ]
command to enable the alarm function for the RMON module.
By default, all alarms for the RMON module are enabled. If only one or some event alarms
need to be enabled, run the snmp-agent trap enable feature-name rmon trap-name
command.
1. Run the rmon alarm entry-number alarm-OID sampling-time { absolute | changeratio |

delta } rising-threshold threshold-value1 event-entry1 falling-threshold threshold-
value2 event-entry2 [ owner owner-name ] command to create an alarm table and add an
entry to the table.
2. Run the rmon prialarm entry-number prialarm-formula description-string sampling-
interval { absolute | changeratio | delta } rising-threshold threshold-value1 event-
entry1 falling-threshold threshold-value2 event-entry2 entrytype { cycle entry-period |
forever } [ owner owner-name ] command to create an extended alarm table and add an
entry to the table.
If the events (event-entry1, event-entry2) corresponding to alarm rising threshold and

falling threshold are not configured in the event table, no alarm will be generated even if
the alarm conditions are met. In this situation, the alarm record status is undercreation,
but not valid.
After either of the events is configured, the alarm will be generated when the alarm
conditions are met and the alarm status is valid. If an incorrect alarm variable is created,
for example, an inexistent OID is specified, the alarm is in the undercreation state and no
alarm is generated.
----End
Prerequisites
The RMON configurations are complete.

Procedure
l Run the display rmon alarm [ entry-number ] command to view RMON alarm
configurations.
l Run the display rmon event [ entry-number ] command to view RMON event
configurations.
l Run the display rmon eventlog [ entry-number ] command to view details about RMON
event logs.
l Run the display rmon history [ interface-type interface-number ] command to view
RMON history sampling records.
l Run the display rmon prialarm [ entry-number ] command to view RMON extended
alarm configurations.
l Run the display rmon statistics [ interface-type interface-number ] command to view
RMON Ethernet statistics.
l Run the display snmp-agent trap feature-name rmon all command to view the status
of all traps about the RMON module.
----End
2.5 Configuring RMON2
RMON2 collects statistics on IP packets on the specified interface.
Before configuring RMON2, configure Ethernet interface parameters.
2.5.1 Configuring RMON2 Statistics Collection
Context
RMON2 collects statistics about traffic on a specified interface, including the source/
destination hosts and traffic passing the interface from each host on the network.
RMON2 supported by the router can collect statistics on IP packets on the specified
interfaces.
Procedure
Step 2 Run rmon2 hlhostcontroltable index ctrl-index [ datasource interface interface-type
interface-number ] [ maxentry maxentry-value ] [ owner owner-name ] [ status { active |
inactive } ]
A host control table is created and an entry is added to the table.
If the host control table contains too many entries, system performance is degraded. The
default settings of host control table are recommended. By default, a host control table
contains a maximum of 50 entries.

When creating an entry, specify the datasource interface parameter to identify the interface,
which specifies the subnet. The parameter value, namely, the interface index, is the data
source defining the entry. In the command, the data source is represented by interface type
and number. Only one entry can be created for each interface in the host control table.
The parameter status in the display rmon2 hlhostcontroltable command output matches the
hlhostcontrolstatus value, which indicates the entry status.
l When the hlhostcontrolstatus value is set to inactive, all related entries in the host table
are deleted automatically.
l When the hlhostcontrolstatus value is set to active, you cannot change the
hlhostcontroldatasource and hlhostcontrolnlmaxdesiredentries values.
l If an interface that corresponds to the hlhostcontroldatasource in an entry is deleted, the
entry is deleted at the same time.
Step 3 Run rmon2 protocoldirtable protocoldirid protocol-id parameter parameter-value [ descr
description-string ] [ host { notsupported | supportedon | supportedoff } ] [ owner owner-
name ] [ status { active | inactive } ]
A protocol directory table is created and an entry is added to the table.
RMON2 collects only statistics on IP packets on an Ethernet interface. A protocol occupies an
entry, so there is only one entry in the table.
When running the rmon2 protocoldirtable command, you must set the description and
protocols supported by the host. That is, the descr and host parameters are mandatory.
The parameter status in the display rmon2 protocoldirtable command output matches the
protocolDirStatus value, which indicates the entry status.
l When the status parameter is set to active, the descr value cannot be modified. The
value of host (corresponding to the protocolDirHostConfig value, indicating the protocol
directory host configuration) can be modified. This parameter indicates whether to
monitor the network-layer host table of the protocol.
– If the host value is set to notsupported, the host value cannot be modified.
– If the host value is not notsupported, the value can be switched between
supportedon and supportedoff.
– When the host value is changed from supportedon to supportedoff, the
corresponding entry in the host control table is deleted.
l When the status is inactive, all related entries in the host table are deleted.
----End

Procedure
l Run the display rmon2 protocoldirtable command to view information about the
protocol directory table.
l Run the display rmon2 hlhostcontroltable [ index ctrl-index ] [ verbose ] command to
view information about the host control table.
l Run the display rmon2 nlhosttable [ hostcontrolindex ctrl-index ] [ hostaddress ip-
address ] command to view information about the host table.
----End

2.6 Configuration Examples for RMON and RMON2
2.6.1 Example for Configuring RMON

As shown in Figure 2-1, a subnet connects to the network through GE2/0/0. The router
monitors the subnet, including:
l Collecting real-time and history statistics on traffic and each type of packets
l Recording logs when the traffic volume per minute exceeds the threshold
l Monitoring broadcast and multicast traffic volume on the subnet and reporting alarm to
the NMS when the traffic volume exceeds the threshold
Figure 2-1 Networking diagram of RMON configuration
NMS
10.1.1.1/24 GE1/0/0 GE2/0/0
10.2.2.1/24 10.3.3.1/24
Network
Router
To collect real-time and history statistics on traffic and each type of packets, configure the
RMON statistics function. To report alarms to the NMS when traffic volume exceeds the
threshold, configure the RMON alarm function.
1. Configure IP addresses for router interfaces.
2. Configure a reachable route between the router and NMS.
3. Run the SNMP commands to set the router can send traps to the NMS.
4. Enable RMON statistics function and configure the statistics table and history control
table.
5. Configure the event table, alarm table, and extended alarm table.
Procedure
Step 1 Configure IP addresses and reachable route for router interfaces.
[Router] ospf

Step 2 Enable the router to send traps to the NMS.

# Enable SNMP to send traps.
# Specify the NMS that receives the traps.

[Router] snmp-agent target-host trap-paramsname hw v1 securityname public
[Router] snmp-agent target-host trap-hostname hwnm address 10.1.1.1 trap-
paramsname hw
Step 3 Configure RMON statistics function.

# Enable the RMON statistics function on the interface.
[Router-GigabitEthernet2/0/0] rmon-statistics enable
# Configure the statistics table.

[Router-GigabitEthernet2/0/0] rmon statistics 1 owner Test300
# Configure the history control table. Sample traffic on the subnet every 30 seconds and save
the latest 10 records
[Router-GigabitEthernet2/0/0] rmon history 1 buckets 10 interval 30 owner Test300
Step 4 Configure RMON alarm function.

# Configure the event table. Configure the router to record logs for RMON event 1 and send
traps to the NMS for RMON event 2.
[Router] rmon event 1 log owner Test300
[Router] rmon event 2 description forUseofPrialarm trap public owner Test300
# Configure the alarm table. Set the sampling interval and the threshold for triggering event 1
(OID is 1.3.6.1.2.1.16.1.1.1.6.1).
[Router] rmon alarm 1 1.3.6.1.2.1.16.1.1.1.6.1 30 absolute rising-threshold 500 1
falling-threshold 100 1 owner Test300
# Configure the extended alarm table. Sample broadcast and multicast packets every 30
seconds. When the number of sampled packets exceeds 1000 or decreases to 0, event 2 is
triggered. That is, the device sends a trap to the NMS.
[Router] rmon prialarm 1 .1.3.6.1.2.1.16.1.1.1.6.1+.1.3.6.1.2.1.16.1.1.1.7.1
sumofbroadandmulti 30 delta rising-threshold 1000 2 falling-threshold 0 2
entrytype forever owner Test300

# View traffic volume on the subnet.
<Router> display rmon statistics gigabitethernet 2/0/0
Statistics entry 1 owned by Test300 is VALID.
Interface : GigabitEthernet2/0/0<ifEntry.402653698>
Received :
octets :142915224 , packets :1749151
broadcast packets :11603 , multicast packets:756252
undersize packets :0 , oversize packets:0

fragments packets :0 , jabbers packets :0

CRC alignment errors:0 , collisions :0
Dropped packet (insufficient resources):1795
Packets received according to length (octets):
64 :150183 , 65-127 :150183 , 128-255 :1383
256-511:3698 , 512-1023:0 , 1024-1518:0
# View the sampling records. Only the last sampling record can be displayed using the
command line. To view all the history records, use special NMS software.
<Router> display rmon history gigabitethernet 2/0/0
History control entry 1 owned by Test300 is VALID
Samples Interface :GigabitEthernet2/0/0<ifEntry.402653698>
Sampling interval :30(sec) with 10 buckets max
Last Sampling time :0days 00h:19m:43s
Latest sampled values:
octets :654 , packets :7
broadcast packets :7 , multicast packets :0
undersize packets :0 , oversize packets :0
CRC alignment errors :0 , collisions :0
Dropped packet: :0 , utilization :0
History record:
Record No.1 (Sample time: 6days 01h:35m:22s)
octets :0 , packets :0
broadcast packets :0 , multicast packets :0
undersize packets :0 , oversize packets :0
CRC alignment errors :0 , collisions :0
Dropped packet: :0 , utilization :0
# View the RMON event configurations.

<Router> display rmon event
Event table 1 owned by Text300 is VALID.
Description: null.
Will cause log when triggered, last triggered at 0days 01h:33m:46s.
Event table 2 owned by Test300 is VALID.
Description: forUseofPrialarm.
Will cause snmp-trap when triggered, last triggered at 0days 01h:38m:54s.
# View the RMON alarm configurations.

<Router> display rmon alarm 1
Alarm table 1 owned by Test300 is VALID.
Samples absolute value : 1.3.6.1.2.1.16.1.1.1.6.1 <etherStatsBroadcastPkts.1>
Sampling interval : 30(sec)
Rising threshold : 500(linked with event 1)
Falling threshold : 100(linked with event 1)
When startup enables : risingOrFallingAlarm
Latest value : 1975
# View the RMON extended alarm configurations.

<Router> display rmon prialarm 1
Prialarm table 1 owned by Test300 is VALID.
Samples delta value : .1.3.6.1.2.1.16.1.1.1.6.1+.1.3.6.1.2.1.16.1.1.1.7.1
Sampling interval : 30(sec)
Rising threshold : 1000(linked with event 2)
Falling threshold : 0(linked with event 2)
When startup enables : risingOrFallingAlarm
This entry will exist : forever
Latest value : 16
# View the event logs.

<Router> display rmon eventlog
Event table 1 owned by Text300 is VALID.
Generates eventLog 1.1 at 0days 01h:33m:46s.
Description: The 1.3.6.1.2.1.16.1.1.1.6.1 defined in alarm table 1,

less than or equal to 100 with alarm value 0. Alarm sample type is
absolute.
----End
Configuration Files
Configuration file of the router
#
sysname Router
#
ip address 10.2.2.1 255.255.255.0
#
ip address 10.3.3.1 255.255.255.0
rmon-statistics enable
rmon statistics 1 owner Test300
rmon history 1 buckets 10 interval 30 owner Test300
#
ospf 1
area 0.0.0.0
network 10.2.2.0 0.0.0.255
network 10.3.3.0 0.0.0.255
#
snmp-agent target-host trap-hostname hwnm address 10.1.1.1 udp-port 162 trap-
paramsname hw
snmp-agent target-host trap-paramsname hw v1 securityname %@%@_=XqAFC_94uCS,
3'<gYC*ZU6%@%@
#
rmon event 1 description null log owner Test300
rmon event 2 description forUseofPrialarm trap public owner Test300
rmon alarm 1 1.3.6.1.2.1.16.1.1.1.6.1 30 absolute rising-threshold 500 1 falling-
threshold 100 1 owner Test300
rmon prialarm 1 .1.3.6.1.2.1.16.1.1.1.6.1+.1.3.6.1.2.1.16.1.1.1.7.1
sumofbroadandmulti 30 delta rising-threshold 1000 2 falling-threshold 0 2
entrytype forever owner Test300
#
return
2.6.2 Example for Configuring RMON2

As shown in Figure 2-2, a subnet is connected to the network through GE2/0/0 on the router.
IP packet statistics function needs to be configured on GE2/0/0 of the router.

Figure 2-2 RMON2 network
COM
NMS
10.1.1.1/24 Console IP: 10.3.3.10/32
Network LAN
GE2/0/0
Router 10.3.3.3/24
IP: 10.3.3.5/32
RMON2 can collect statistics on IP packets on interfaces. You can run RMON2 to remotely
monitor traffic on networks using an SNMP NMS or command line. This example describes
the command line way.
1. Configure IP addresses for router interfaces.
2. Configure the host control table and protocol directory table.
Procedure
Step 1 Configure IP addresses for router interfaces.
Step 2 Configure RMON2 traffic statistics function.

# Configure the host control table. Set the index to 123 and maximum number of entries in the
table to 100.
[Router] rmon2 hlhostcontroltable index 123 datasource interface gigabitethernet
2/0/0 maxentry 100 owner china status active
# Configure the protocol directory table. The protocol ID is fixed at 8.0.0.0.1.0.0.8.0,

parameter is fixed at 2.0.0, and host value is fixed at suppurtedon (collecting statistics on
these protocol packets).
[Router] rmon2 protocoldirtable protocoldirid 8.0.0.0.1.0.0.8.0 parameter 2.0.0
descr IP host supportedon owner china status active

# View traffic on a host by specifying the host IP address.
<Router> display rmon2 nlhosttable hostcontrolindex 123 hostaddress 10.3.3.10
Abbreviation:
HIdx - hlHostControlIndex
Addr - nlHostAddress
InPkts - nlHostInPkts

OutPkts - nlHostOutPkts
InOctes - nlHostInOctets
OutOctes - nlHostOutOctets
OutMac - nlHostOutMacNonUnicastPkts
HIdx Addr InPkts OutPkts InOctes OutOctes OutMac
123 10.3.3.10 0 78 0 1046 78
# View information about the host control table. You can see the number of added entries,
deleted entries, and total entries on the interface.
<Router> display rmon2 hlhostcontroltable
Abbreviation:
index - hlhostcontrolindex
datasource - hlhostcontroldatasource
droppedfrm - hlhostcontrolnldroppedframes
inserts - hlhostcontrolnlinserts
Deletes - hlHostControlNlDeletes
maxentries - hlhostcontrolnlmaxdesiredentries
status - hlhostcontrolstatus
index datasource droppedfrm inserts Deletes maxentries status
123 GE2/0/0 0 19 0 100 active
----End
Configuration Files
#
sysname Router
#
ip address 10.3.3.3 255.255.255.0
#
rmon2 protocoldirtable protocoldirid 8.0.0.0.1.0.0.8.0 parameter 2.0.0 descr IP
host supportedon owner china status active
rmon2 hlhostcontroltable index 123 datasource interface GigabitEthernet2/0/0
maxentry 100 owner china status active
#
return

and Monitoring 3 TCP FPM Configuration
3 TCP FPM Configuration
About This Chapter
3.1 Overview of TCP FPM

3.2 Understanding TCP FPM
3.3 Application Scenarios for TCP FPM
3.4 Licensing Requirements and Limitations for TCP FPM
3.5 Default Settings for TCP FPM
3.6 Configuring TCP FPM
3.7 Clearing TCP FPM Statistics
3.8 Configuration Examples for TCP FPM
3.1 Overview of TCP FPM
Definition
TCP Flow Performance Measurement (FPM) is a real-time network performance monitoring
and measurement technology that can measure statistics on TCP application performance,
such as network delay and TCP connection packet loss rate.
Purpose
With the increase of number and complexity of network applications, application servers
encounter many problems, for example, a long delay of application programs. Such problems
affect user experience and may be caused by the slow processing speed of the background
database. The network delay and TCP connection packet loss rate measured by TCP FPM
reflect the network quality, and are the basis for network or service optimization.

3.2 Understanding TCP FPM
Network Model
Figure 3-1 TCP FPM network model
The TCP FPM network model shown in Figure 3-1 includes the following roles:
l Application Client: a device that provides applications to users, such as PC.
l Application Server: a device that provides services to clients, such as file server.
l Router: a device that collects statistics on network performance such as network delay
and packet loss rate.

Working Process
Figure 3-2 TCP FPM measurement flowchart
1. The Application Client sends a request packet, and the Router identifies that the packet is
the SYN packet in the first handshake, obtains source and destination IP addresses,
creates a bidirectional flow table, and records the timestamp. The Router then transmits
the packet to the Application Server.
2. After receiving the request packet, the Application Server sends a response packet. The
Router identifies that the packet is the SYN-ACK packet in the second handshake based
on the table, records the time, and transmits the response packet to the Application
Client. In this case, TCP_SND is calculated.
3. After receiving the response packet, the Application Client sends a packet again. The
Router identifies that the packet is the ACK packet in the third handshake based on the
table, and records the time. In this case, TCP_CND is calculated.
4. The Router collects statistics on network performance such as network delay and packet
loss rate for you to understand network quality.
– TCP Server Network Delay (TCP_SND): Network delay of the server.
– TCP Server Network Delay (TCP_SND): Network delay of the client.

– Data Server Network Delay (DATA_SND): Response delay, that is, the time
difference between the data request sent by the client and the response sent by the
first server.
– Application Delay (AD): Response delay of an application, that is, the delay
generated by the application server (AD = DATA_SND – TCP_SND).
– Packet loss rate: TCP application packet loss is calculated based on TCP
retransmission. For a TCP flow, the TCP sequence numbers of retransmitted packet
and lost packet are the same. That is, the packet loss rate is (the number of
retransmitted packets/the number of sent packets).
3.3 Application Scenarios for TCP FPM

In Figure 3-3, the application client is connected to the network through a router, and an
application server is deployed to provide service to the application client. A user operates
TCP applications on the application client, for example, website visiting, remote Telnet login,
and FTP file operation. The user wants to know the network statistics such as network delay
and packet loss rate of TCP applications, so the user enables TCP FPM on the router to collect
network statistics in real time. Based on the network statistics, the user can promptly optimize
the network.
Figure 3-3 Application scenario for TCP FPM
3.4 Licensing Requirements and Limitations for TCP FPM

None
TCP FPM is a basic feature of a router and is not under license control.
Feature Limitations
Ethernet interfaces do not support TCP FPM when working as Layer 2 interfaces. Therefore,
the interfaces must be added to VLANIF interfaces or the interface mode must be switched to
Layer 3.
3.5 Default Settings for TCP FPM

Table 3-1 lists the default settings for TCP FPM.

Table 3-1 Default settings for TCP FPM

TCP FPM function Disabled
Reporting TCP FPM statistics to the Disabled

controller
Interval for reporting TCP FPM statistics to 60s

the controller
3.6 Configuring TCP FPM
3.6.1 Enabling TCP FPM
Context
After TCP FPM is enabled, you can view the delay and packet loss rate of application
programs, and then optimize the network according to the network performance statistics.
Procedure
Step 2 Run interface interface-type interface-number
Step 3 Run tcp fpm enable
TCP FPM is enabled.
By default, the TCP FPM function is disabled.
----End
3.6.2 (Optional) Enabling Reporting of TCP FPM Statistics to the

Controller
Context
TCP FPM statistics can be displayed in two methods:
l CLI: Run the display tcp fpm session command to view TCP FPM statistics.
l Controller: Display TCP FPM statistics on the GUI. This method provides visual
statistics display. However, it can only be used in the SD-WAN solution, in which a
controller is used. For how to configure TCP FPM and view TCP FPM statistics on the
controller, see the documents of SD-WAN solution.

Procedure
Step 2 Run pm report tcp fpm enable
The function of reporting TCP FPM statistics to the controller is enabled.
By default, TCP FPM statistics are not reported to the controller.
Step 3 Run tcp fpm report time value
The interval for reporting TCP FPM statistics to the controller is set.
By default, the interval for reporting TCP FPM statistics to the controller is 60s.
----End
Procedure
l Run the display tcp fpm session { all | number } command to view TCP FPM statistics.
----End
3.7 Clearing TCP FPM Statistics
Context
To understand the quality of the network running TCP applications, clear existing TCP FPM
statistics first, and then collect new statistics. From the latest statistics, you can know the
network status in real time.
Statistics cannot be restored after being cleared. Exercise caution when you run the following
commands.
Procedure
Step 1 Run the system-view command to enter the system view.
Step 2 Run the reset tcp fpm session all command to clear TCP FPM statistics.
----End
3.8 Configuration Examples for TCP FPM

3.8.1 Example for Configuring TCP FPM
In Figure 3-4, the application client is connected to the network through a router, and an
application server is deployed to provide service to the application client. A user operates
TCP applications on the application client, for example, website visiting, remote Telnet login,
and FTP file operation. The user wants to know the network statistics such as network delay
and packet loss rate of TCP applications, so the user enables TCP FPM on the router to collect
network statistics in real time. Based on the network statistics, the user can promptly optimize
the network.
Figure 3-4 TCP FPM application
1. Enable TCP FPM on GE0/0/1.
2. View TCP FPM statistics.
Procedure
Step 1 Enable TCP FPM on GE0/0/1.
[Router] interface GigabitEthernet 0/0/1
[Router-GigabitEthernet0/0/1] tcp fpm enable
[Router-GigabitEthernet0/0/1] sa application-statistic enable

# Run the display tcp fpm session all command on the router to view TCP FPM statistics.
Loss(%) indicates the packet loss rate, CND indicates the network time on client, and SND
indicates the network time on server.
<Router> display tcp fpm session all
Index DstIP(Port) SrcIP(Port) Loss(%) SND CND RT
Application
1 10.1.3.1(2053) 10.1.1.1(3351) 0 12 4 0 FTP
----End
Configuration Files
Router configuration file
#
sysname Router
#

ip address 10.1.2.1 255.255.255.0

tcp fpm enable
sa application-statistic enable
#
return

and Monitoring 4 IP FPM Configuration
4 IP FPM Configuration
About This Chapter
IP Flow Performance Measurement (FPM) is a Huawei proprietary feature that measures

packet loss rate and delay of end-to-end service packets transmitted on an IP network to
determine network performance. This feature is easy to deploy and provides an accurate
assessment of network performance.
4.1 Overview of IP FPM

4.2 Understanding IP FPM
4.3 Application Scenarios for IP FPM
4.4 Licensing Requirements and Limitations for IP FPM
4.5 Default Settings for IP FPM
4.6 Configuring IP FPM
4.7 Monitoring the IP FPM Running Status
4.8 Configuration Examples for IP FPM
4.1 Overview of IP FPM

Definition
IP Flow Performance Measurement (FPM) is a Huawei proprietary feature that measures
packet loss rate and delay of end-to-end service packets transmitted on an IP network to
determine network performance. This feature is easy to deploy and provides an accurate
assessment of network performance.
Purpose
As IP services are more widely adopted, fault diagnosis and end-to-end service quality
analysis are becoming an increasingly pressing concern for carriers. However, absence of
effective measures prolongs fault diagnosis and increases the workload. Currently, carriers use

Network quality analysis (NQA) to measure the quality of services running on IP radio access
networks (RANs).
However, NQA cannot implement Layer 3 end-to-end performance measurement due to the
following problems:
l NQA measures network performance by determining the packet loss rate of simulated
packets, but not actual service packets transmitted on networks. The performance
counters collected by NQA may not represent the actual service quality, and therefore
cannot serve as a solid reference for network performance analysis.
l NQA does not support end-to-end performance measurement across network layers, and
cannot monitor or measure network performance in multipath IP networks.
IP FPM does not have any of these shortcomings. IP FPM directly measures service packets
to assess IP network performance and monitors services in real time for network diagnosis.
Benefits
l Allows carriers to use the network management system (NMS) to monitor the network
running status to determine whether the network quality complies with the service level
agreement (SLA).
l Allows carriers to promptly adjust services based on measurement results to ensure
proper transmission of voice and data services, improving user experience.
4.2 Understanding IP FPM

4.2.1 Basic Concepts
IP FPM Model
The IP Flow Performance Measurement (FPM) model describes how service flows are
measured to obtain the packet loss rate and delay. In statistical terms, the statistical objects are
the service flows, and the statistical calculations determine the packet loss rate and delay of
the service flows traveling across the transit network. Service flow statistical analysis is
performed on the ingress and egress of the transit network.
The IP FPM model is composed of three objects: target flows, the transit network, and the
statistical system. The statistical system is further classified into the Target Logical Port
(TLP), Data Collecting Point (DCP), and Measurement Control Point (MCP).Figure 4-1
shows the IP FPM model.
Figure 4-1 IP FPM model

l Target flow
Target flows must be pre-defined.
One or more fields in IP headers can be specified to identify target flows. The field can
be the source IP address or prefix, destination IP address or prefix, protocol type, source
port number, destination port number, or type of service (ToS). The more fields
specified, the more accurately flows can be identified. Specifying as many fields as
possible is recommended to maximize the measurement accuracy.
l Transit network
The transit network only bears target flows. The target flows are not generated or
terminated on the transit network. The transit network can be a Layer 2 (L2), Layer 3
(L3), or L2+L3 hybrid network. Each node on the transit network must be reachable at
the network layer.
l TLP
TLPs are interfaces on the edge nodes of the transit network. TLPs perform the
following actions:
– Compile statistics on the packet loss rate and delay.
– Generate statistics, such as the number of packets sent and received, traffic
bandwidth, and timestamp.
An In-Point-TLP collects statistics about service flows it receives. An Out-Point-TLP
collects statistics about service flows it sends.
l DCP
DCPs are edge nodes on the transit network. DCPs perform the following actions:
– Manage and control TLPs.
– Collect statistics generated by TLPs.
– Report the statistics to an MCP.
l MCP
MCPs can be any nodes on the transit network. MCPs perform the following actions:
– Collect statistics reported by DCPs.
– Summarize and calculate the statistics.
– Report measurement results to user terminals or the network management system
(NMS).
Color Bits
The color bit is also called characteristics bit. In IP FPM, there are color bits for packet loss
measurement and for delay measurement. The color bits indicate that a service packet is used
for packet loss measurement or delay measurement.
Figure 4-2 shows the possible color bits in the IPv4 packet header.

Figure 4-2 IPv4 packet header format
l The third to seventh bits in the ToS field are seldom used in actual applications. These
bits, if available, can be used as color bits for service packets.
l Bit 0 in the Flags field is reserved and can be directly used as a color bit.
If two or more bits in the IPv4 packet header have not been planned for other purposes, they
can be used for packet loss and delay measurement at the same time. If only one bit in the
IPv4 packet header has not been planned, it can be used for either packet loss or delay
measurement in one IP FPM instance.
4.2.2 Function Implementation
Function Overview
IP FPM measures the packet loss rate and delay of multipoint-to-multipoint (MP2MP) service
flows traveling across the transit network.
Table 4-1 lists the IP FPM types and usage scenarios.
Table 4-1 IP FPM types
Type Scenario
Continuous end-to- To detect network performance degradation in a timely manner, use

end performance this mode. This mode displays continuous network running status.
measurement
On-demand end-to- When network performance degrades or users want to monitor the
end performance performance of a specified service flow, use this mode. This mode
measurement displays detailed performance statistics in recent time.
The device supports the following IP FPM functions:

l Packet loss measurement
– Point-to-point packet loss measurement measures packet loss on a link between two
devices to determine the link quality.
– Multipoint-to-multipoint packet loss measurement measures packet loss on links
between multiple devices to determine the link quality.

l Delay measurement
– Point-to-point two-way delay measurement measures two-way delay on a link
between two devices to determine the link quality.
Implementation
On a transit network with boundaries, flows enter and leave the network through some
boundary devices. In Figure 4-3, the number of packets entering the ingress interfaces on
Routers is PI, and the number of packets leaving the egress interfaces on Routers is PE.
Figure 4-3 IP FPM measurement diagram
In a specified period, the number of lost packets is the difference between the number of
packets entering a transit network and the number of packets leaving the transit network.
l The total number of ingress packets is PI = PI(1) + PI(2) + PI(3).
l The total number of egress packets is PE = PE(1) + PE(2) + PE(3).
Within a measurement interval, the delay is the time difference between a flow enters and
leaves a network.
Packet loss measurement
Packet loss measurement calculates the difference between the number of packets entering a
transit network and the number of packets leaving the transit network within a measurement
interval.
Figure 4-4 shows a typical network end-to-end performance measurement model. Service
packets enter the network from RouterA and leave the network from RouterB.

Figure 4-4 Packet loss measurement diagram
PI1 Ingress Egress PE2

IP/MPLS
RouterA RouterB
RouterA
0 1 1 1 1 1 0 0 0 0 0 1 1 1 1 1 0
RouterB
0 1 1 1 1 1 0 0 0 0 1 0 1 1 1 1 0
time t5 t4 t3 t2 t1 t0
1. t0: RouterA sets the packet loss color bit to 1 for incoming service packets in the first
interval and starts counting all service packets with the packet loss color bit as 1.
2. t1: RouterB starts receiving service packets with the packet loss color bit as 1 in the first
interval and starts counting these service packets.
3. t2: RouterA finishes counting the incoming service packets with the packet loss color bit
as 1 in the first interval and obtains the total number of these service packets PI(1).
RouterA then sets the packet loss color bit to 0 for incoming service packets in the
second interval and starts counting all service packets with the packet loss color bit as 0.
4. t3: RouterB finishes receiving service packets with the packet loss color bit as 1 in the
first interval and obtains the total number of these service packets PE(2).
NOTE
RouterB starts receiving service packets with the packet loss color bit as 1 from t1. When the internal
timer passes a measurement interval (at t3), RouterB determines that receiving of the service packets
with the packet loss color bit as 1 in this interval is finished, but does not determine the finish of service
packet receiving when it receives a service packet with a non-1 color bit. This mechanism prevents the
impact of packet unsequencing on service packet statistics, to ensure the accurate service packet
counting within an interval.
5. t4: RouterA sets the packet loss color bit to 1 for incoming service packets in the third
interval and starts counting all service packets with the packet loss color bit as 1.
6. t5: RouterB starts receiving service packets with the packet loss color bit as 1 in the third
interval and starts counting these service packets.
RouterB obtains the number of received service packets with the packet loss color bit as 1 in
the first interval any time between t3 and t5. The formula is LostPacket = PI(1) - PE(2).
Delay measurement
Delay is the difference between a service flow enters and leaves a network.
In IP FPM, a device samples service packets, records the actual forwarding time of service
packets, and calculates the transmission delay of the service flow.

Figure 4-5 Delay measurement diagram
Figure 4-5 shows the delay measurement diagram.

l For packets sent from RouterA to RouterB:
– t1: RouterA sets the delay color bit to 1 for specified incoming service packets and
obtains the timestamp t1.
– t2: RouterB starts receiving the service packets with the delay color bit as 1 and
l For packets sent from RouterB to RouterA:
– t3: RouterB sets the delay color bit to 1 for specified incoming service packets and
– t4: RouterA starts receiving the service packets with the delay color bit as 1 and
The two-way delay is: 2d = (t2 - t1) + (t4 - t3) = (t4 - t1) - (t3 - t2)
4.3 Application Scenarios for IP FPM

End-to-End Packet Loss Measurement
In Figure 4-6, the target flow enters the network through RouterA and leaves the network
through RouterB. The target flow enters the network through one interface and leaves through
another interface. IP FPM end-to-end packet loss measurement can be deployed on RouterA
and RouterB to measure the packet loss rate on the network.

Figure 4-6 End-to-end packet loss measurement (1)
In-Point Out-Point
Ingress Egress
RouterA RouterB
Transit Network
Target flow
In Figure 4-7, all Huawei devices form an end-to-end network. The ingress and egress
interfaces of the target flow reside on multiple network edge devices. The number of all
packets entering the network should be the same as the number of packets leaving the
network. IP FPM end-to-end packet loss measurement can be deployed on RouterA, RouterB,
RouterC, and RouterD to measure the packet loss rate on the network.
Figure 4-7 End-to-end packet loss measurement (2)
In-Point/Ingress Out-Point/Egress
RouterB
RouterC
In-Point/Ingress Out-Point/Egress
Transit Network
RouterD
RouterA
Target flow
End-to-End Delay Measurement

In Figure 4-8, a specified service flow is forwarded from RouterA to RouterB and from
RouterB to RouterA on an end-to-end network. In IP FPM, a device samples service packets,
records the actual forwarding time of service packets, and calculates the transmission delay of
the service flow.

Figure 4-8 End-to-end delay measurement
t1 t2
t4 RouterA RouterB t3
Transit Network
Target flow
4.4 Licensing Requirements and Limitations for IP FPM

None
Feature Limitations
l IP FPM depends on NTP clock synchronization. If clocks are not synchronized, statistics
cannot be collected or the statistical result is abnormal.
l IP FPM does not support the SD-WAN solution in which double gateways and three
upstream WAN ports are deployed.
l IP FPM delay measurement is not reliable. When the packet loss rate on a link is high,
there is a possibility that the detection result is inaccurate.
l In the SD-WAN solution, IP FPM detection result can be reported to the SPR. It takes
more than 20s to report detection results for the first time.
4.5 Default Settings for IP FPM

Table 4-2 lists default settings in IP FPM.
Table 4-2 Default settings for IP FPM

On-demand two-way Disabled

delay measurement
for an IP FPM
instance
Measurement 10 seconds
interval for an IP
FPM instance
IP FPM instance Not created

On-demand packet 10 minutes

loss measurement
interval
on-demand two-way 10 minutes

delay measurement
interval
On-demand packet Disabled

loss measurement for
an IP FPM instance
Global Data Disabled

Collecting Point
(DCP) and
Measurement
Control Point (MCP)
functions
UDP port for an 65030

MCP to
communicate with a
DCP in IP FPM
statistical system.
Alarm function of Closed

the IP FPM module
Measurement point Not configured

of an IP FPM
instance
Alarm description Empty
4.6 Configuring IP FPM

4.6.1 Configuring the MCP
The MCP is the controller in the IP FPM system. It collects, summarizes, and calculates
performance statistics, and reports measurement results to user terminals or the NMS.
Context
Figure 4-9 shows a typical networking for IP FPM end-to-end performance measurement.
The target flow enters the transit network through RouterA, travels through RouterB, and
leaves the transit network through RouterC. To monitor the transit network performance in
real time or check whether a fault occurs on the transit network, configure IP FPM end-to-end
performance measurement on RouterA and RouterC.

Figure 4-9 Networking diagram for IP FPM end-to-end performance measurement
TLP310
MCP Transit Network Out-point
DCP1 DCP3 Egress
TLP100 RouterA RouterB RouterC

In-point
Ingress
Forward Target Flow
In Figure 4-9, RouterA is configured as the MCP to collect performance statistics reported by
DCP1 and DCP3, summarize and calculate the statistics, and report measurement results to
user terminals or the NMS.
Perform the following operations on RouterA to configure it as the MCP.
Procedure
Step 2 Run nqa ipfpm mcp
The MCP function is enabled globally, and the IPFPM-MCP view is displayed.
By default, the MCP function is disabled globally.
Step 3 Run mcp id mcp-id
An MCP ID is configured.
By default, an MCP has no ID. It is recommended that you use the Router ID of the device as
the MCP ID.
The MCP ID must be an IP address reachable to DCPs. The MCP ID must be the same as
those specified in the IP FPM instances associated with DCPs using the mcp mcp-id [ port
port-number ] command. If you change the MCP ID, you must also change the MCP IDs
specified in the IP FPM instances associated with the DCPs. Otherwise, DCPs cannot
communicate with the MCP.
Step 4 (Optional) Run protocol udp port port-number
A UDP port number is specified on the MCP for the MCP to communicate with DCPs.
The UDP port number specified on the MCP must be the same as those specified in the IP
FPM instances associated with DCPs using the mcp mcp-id [ port port-number ] [ vpn-
instance vpn-instance-name ] [ net-manager-vpn ] command. If you change the UDP port
number on the MCP, you must also change the UDP port numbers specified in the IP FPM

instances associated with the DCPs. Otherwise, DCPs cannot report statistics collected from
TLPs to the MCP.
Step 5 (Optional) Run authentication-mode hmac-sha256 key-id key-id [ cipher ] password
The authentication mode and password are configured on the MCP.
By default, no authentication mode or password is configured on an MCP.
You need to enable the authentication function when configuring IP FPM on networks that
require high security. After the same authentication mode and password are configured on the
MCP and DCPs, the MCP receives packets only from authenticated DCPs, improving
network security and reliability of network performance measurement.
The authentication mode and password configured on an MCP must be the same as those
configured for all DCPs associated with the MCP using the authentication-mode hmac-
sha256 key-id key-id [ cipher ] password command. Otherwise, the MCP cannot receive
statistics reported by the DCPs.
Step 6 Run instance instance-id
An IP FPM instance is created, and the instance view is displayed.
By default, no IP FPM instance is created.
In the IP FPM system, the IP FPM instance ID specified by the instance-id parameter must be
unique in the management domain of the MCP to which the instance belongs. You must
configure the same IP FPM instance on an MCP and all DCPs associated with the MCP
simultaneously. Otherwise, IP FPM end-to-end performance measurement does not take
effect.
NOTE
After the configuration changes, you need to run the measure disable command to disable measurement of
all indicators in a measurement instance on the MCP, and then run the measure enable command to enable
measurement of all indicators in a measurement instance on the MCP. Otherwise, the statistics may fail to be
collected.
By default, measurement of all indicators is enabled in a measurement instance on the MCP.
You are advised to enable packet loss measurement on the DCP and then enable measurement on the MCP.

The authentication mode and password are configured in the IP FPM instance.
By default, no authentication mode or password is configured in an IP FPM instance.
You need to enable the authentication function when configuring IP FPM on networks that
require high security. After the same authentication mode and password are configured on the
MCP and DCPs, the MCP receives packets only from authenticated DCPs, improving
network security and reliability of network performance measurement.
Step 8 (Optional) Run description text
A description is configured for the IP FPM instance.
By default, no description is configured for an IP FPM instance.
An IP FPM instance can be identified only by an ID in integer format. The description of an
IP FPM instance helps you understand services and functions monitored by the instance and
avoid misuses of the instance.

Step 9 Run dcp dcp-id

A DCP ID is specified in the IP FPM instance.
By default, no DCP ID is specified in an IP FPM instance on an MCP.
The DCP ID in an IP FPM instance must be the same as those specified on DCPs using the
dcp id dcp-id command. Otherwise, the MCP cannot receive statistics reported by the DCPs.
----End
4.6.2 Configuring the DCP

DCPs are the executors in the IP FPM system. They control and manage TLPs, collect
performance statistics, and report the statistics to the MCP.
Context
Figure 4-10 shows a typical networking for IP FPM end-to-end performance measurement.
The target flow enters the transit network through RouterA, travels through RouterB, and
leaves the transit network through RouterC. To monitor the transit network performance in
real time or check whether a fault occurs on the transit network, configure IP FPM end-to-end
performance measurement on RouterA and RouterC.
Figure 4-10 Networking diagram for IP FPM end-to-end performance measurement
TLP310
MCP Transit Network Out-point
DCP1 DCP3 Egress
TLP100 RouterA RouterB RouterC

In-point
Ingress
Forward Target Flow
In Figure 4-10, RouterA and RouterC are configured as DCPs to control and manage TLP100
and TLP310 respectively, collect performance statistics, and report the statistics to the MCP.
Perform the following operations on RouterA and RouterC to configure them as DCPs.
Procedure
Step 2 Run nqa ipfpm dcp
The DCP function is enabled globally, and the IPFPM-DCP view is displayed.

Step 3 Run dcp id dcp-id
A DCP ID is configured.
By default, a DCP has no ID. It is recommended that you use the Router ID of the device as
the DCP ID.
The DCP ID must be the same as that specified in the IP FPM instance of the MCP using the
dcp dcp-id command. Otherwise, the MCP cannot receive statistics reported by the DCP.
The authentication mode and password are configured on the DCP.
By default, no authentication mode or password is configured on a DCP.
The authentication mode and password configured on a DCP must be the same as those
configured on the MCP to which the DCP belongs using the authentication-mode hmac-
sha256 key-id key-id [ cipher ] password command. Otherwise, the MCP cannot receive
statistics reported by the DCP.
Step 5 (Optional) Run color-flag loss-measure { tos-bit tos-bit | flags-bit0 } delay-measure { tos-
bit tos-bit | flags-bit0 | none }
The IP FPM color bit is configured.
By default, the color bit for IP FPM packet loss measurement is bit 6 in the type of service
(ToS) field of the IP packet header, the color bit for IP FPM delay measurement is bit 7 in the
ToS field of the IP packet header, The default settings are recommended.
When deploying IP FPM, ensure that packet loss and delay measurement use different color
bits, and the color bits for packet loss and delay measurement have not been used in other
measurement tasks.
In MPLS scenario, the ToS field of the IP packet header cannot be used as the IP FPM color
bit. You can use bit 0 in the Flags field of the IP packet header as the IP FPM color bit.
NOTE
Currently, IP FPM can detect traffic on both the LAN side and WAN side. However, IP FPM color bit is a
global configuration in the IPFPM-DCP view and detection of the traffic on both sides cannot be configured
manually.
Step 6 Run mcp mcp-id [ port port-number ] [ vpn-instance vpn-instance-name | net-manager-

vpn ]
The MCP ID for all IP FPM instances on the DCP is specified.
The UDP port number specified on the DCP must be the same as that specified on the MCP
using the protocol udp port port-number command. Otherwise, the DCP cannot report
statistics collected from TLPs to the MCP.
If you want the DCP to report statistics to the MCP through a specified VPN or management
VPN, ensure that the corresponding VPN instance has been created on the DCP before
specifying the vpn-instance vpn-instance-name or net-manager-vpn parameter in the
command.
Step 7 Run instance instance-id
An IP FPM instance is created, and the instance view is displayed.

In the IP FPM system, the IP FPM instance ID specified by the instance-id parameter must be
unique in the management domain of the MCP to which the instance belongs. You must
configure the same IP FPM instance on DCPs and the MCP to which the DCPs belong.
Otherwise, IP FPM end-to-end performance measurement does not take effect.
Step 8 (Optional) Run mcp mcp-id [ port port-number ] [ vpn-instance vpn-instance-name | net-
manager-vpn ]
The MCP ID for all IP FPM instances on the DCP is specified.
The UDP port number specified on the DCP must be the same as that specified on the MCP
using the protocol udp port port-number command. Otherwise, the DCP cannot report
statistics collected from TLPs to the MCP.
If you want the DCP to report statistics to the MCP through a specified VPN or management
VPN, ensure that the corresponding VPN instance has been created on the DCP before
specifying the vpn-instance vpn-instance-name or net-manager-vpn parameter in the
command.
Step 9 (Optional) Run description text
A description is configured for the IP FPM instance.
By default, no description is configured for an IP FPM instance, and an IP FPM instance can
be identified only by an ID in integer format.
The description of an IP FPM instance helps you understand services and functions monitored
by the instance and avoid misuses of the instance.
Step 10 (Optional) Run interval { 10 | 60 | 600 }
The measurement interval of the IP FPM instance is configured.
By default, the measurement interval of an IP FPM instance is 10s.
NOTE
To ensure statistics accuracy, it is recommended that you disable packet loss or delay measurement in
the IP FPM instance view before modifying the measurement interval of the instance, and enable the
measurement function after the modification.
Step 11 Configure the target flow features in the IP FPM instance. Choose either of the following
methods based on the target flow type.
Configure forward or backward target flow features.

l When protocol is specified as TCP or UDP, the command for configuring the forward
target flow features is as follows:
flow forward { protocol { tcp | udp } { source-port src-port-number1 [ to src-port-
number2 ] | destination-port dest-port-number1 [ to dest-port-number2 ] } * | dscp
dscp-value | source src-ip-address [ src-mask-length ] | destination dest-ip-address
[ dest-mask-length ] } *
l When protocol is specified as TCP or UDP, the command for configuring the backward
target flow features is as follows:
flow backward { protocol { tcp | udp } { source-port src-port-number1 [ to src-port-
number2 ] | destination-port dest-port-number1 [ to dest-port-number2 ] } * | dscp

l When protocol is specified as any protocol other than TCP or UDP, the command for
configuring the forward target flow features is as follows:
flow forward { protocol protocol-number | dscp dscp-value | source src-ip-address
[ src-mask-length ] | destination dest-ip-address [ dest-mask-length ] } *
configuring the backward target flow features is as follows:
flow backward { protocol protocol-number | dscp dscp-value | source src-ip-address
Configure the symmetrical bidirectional target flow features.
l When protocol is specified as TCP or UDP, the command for configuring the target flow
features is as follows:
flow bidirectional { protocol { tcp | udp } { source-port src-port-number1 [ to src-
port-number2 ] | destination-port dest-port-number1 [ to dest-port-number2 ] } * | dscp
NOTE
Currently, the IP FPM system supports port range matching. If you do not specify the IP address for a
packet, ensure that the source port number and destination port number of the packet do not match the
port range simultaneously. Otherwise, the port range is incorrectly matched and the statistics fail to be
collected.
configuring the target flow features is as follows:
flow bidirectional { protocol protocol-number | dscp dscp-value | source src-ip-address
To configure the application matching information of the target flow, use the following
command:
flow application application-name
NOTE
l When configuring the bidirectional target flow in the IP FPM instance, pay attention to the following
points:
– If the bidirectional target flow is asymmetrical, you need to specify the forward and backward
parameters to configure forward and backward target flow features.
– If the bidirectional target flow is symmetrical, you only need to specify the bidirectional parameter
to configure one bidirectional flow. By default, the forward flow features are used as features of this
bidirectional flow, and the backward flow features mirror to the forward flow features. Note that if
the specified target flow is a symmetrical bidirectional flow, you must configure both the src-ip-
address and dest-ip-address parameters to specify the source and destination IP addresses of the
target flow.
l To make the application protocol of the target flow configured for a specified application in an IP FPM
instance take effect, you need to specify bidirectional, forward, or backward to configure any flow
characteristic of bidirectional target flow, forward target flow, and backward target flow. In addition, you
need to run the sa application-statistic enable command on the interface to enable SAC before using the
IP FPM function.
Step 12 Run tlp tlp-id { in-point ingress | out-point egress }

TLPs of the IP FPM instance and their roles are configured.
TLPs are the measurement points along the target flow in the IP FPM instance. They compile
and generate statistics. TLPs in the IP FPM instances are classified into In-Point-TLPs (in-

point indicates an In-Point-TLP on which the system adds the color bit to a target flow) and
Out-Point-TLPs (out-point indicates an Out-Point-TLP on which the system removes the
color bit from a target flow.) In Figure 4-10, TLP100 and TLP310 on the network are the In-
Point-TLP and Out-Point-TLP, respectively.
NOTE
If you want to exclude RouterA and RouterC when measuring the transit network performance,
configure the downlink port on RouterA as an In-Point-TLP on which the system adds the color bit to a
target flow, and configure the uplink port on RouterC as an Out-Point-TLP on which the system removes
the color bit from a target flow.
Step 13 Run quit

Return to the IPFPM-DCP view.
Step 14 Run quit
Return to the system view.
Step 15 Bind an interface to a TLP.
1. Run interface interface-type interface-name
The view of the interface to be bound to a TLP is displayed.
2. Run ipfpm tlp tlp-id
A Layer 3 interface on the device is bound to a TLP.
Step 16 Enable IP FPM end-to-end performance measurement.
1. Run system-view
2. Run nqa ipfpm dcp
The IPFPM-DCP view is displayed.
3. Run instance instance-id
The IP FPM instance view is displayed.
4. Enable packet loss measurement. Choose either of the following commands based on
actual requirements:
– Run loss-measure enable time-range { 5 | 10 | 15 | 30 }
On-demand packet loss measurement is enabled.
By default, the interval for on-demand packet loss measurement is 10 minutes.
– Run loss-measure enable continual
Continuous packet loss measurement is enabled.
5. Enable delay measurement.
If the target flow is bidirectional, choose either of the following commands based on
actual requirements:
– Run delay-measure enable two-way tlp tlp-id1 [ tlp-id2 ] [ time-range { 5 | 10 |
15 | 30 } ]
On-demand two-way delay measurement is enabled.
By default, the interval for on-demand packet loss measurement is 10 minutes.
– Run delay-measure enable two-way tlp tlp-id1 [ tlp-id2 ] continual
Continuous two-way delay measurement is enabled.

NOTE
After the DCP configuration changes, you need to run the undo loss-measure enable command to
disable packet loss measurement for an IP FPM instance, and then run the loss-measure enable
command to enable packet loss measurement for an IP FPM instance on the DCP. Otherwise, the
statistics may fail to be collected.
By default, packet loss measurement is disabled for an IP FPM instance.
You are advised to enable packet loss measurement on the DCP and then enable measurement on the
MCP.
Note that data may be inaccurate in the first two periods after measurement is enabled. As a result, the
statistical result is unreliable.
----End

This section describes how to view the configuration and status of the MCP, DCPs, and TLPs
to check whether IP FPM end-to-end performance measurement is configured successfully.
Prerequisites
Configurations of IP FPM end-to-end performance measurement have been completed.
Procedure
l Run the display ipfpm mcp command to check the MCP configuration and status in the
IP FPM system.
l Run the display ipfpm dcp command to check the DCP configuration in the IP FPM
system.
l Run the display ipfpm statistic-type { loss | twoway-delay } instance instance-id
command to check performance statistics in a specified IP FPM instance in the IP FPM
system.
l Run the display ipfpm instance application command to view information about the
applications detected in IP FPM instances.
----End
4.7 Monitoring the IP FPM Running Status

Context
You can run the following display command in any view to check IP FPM performance
statistics and monitor the IP FPM running status in routine maintenance.
Procedure
l Run the display ipfpm statistic-type { loss | twoway-delay } instance instance-id
command in any view to check performance statistics in a specified IP FPM instance in
the IP FPM system.
----End

4.8 Configuration Examples for IP FPM
4.8.1 Example for Configuring IP FPM End-to-End Performance

Measurement
This section provides an example for configuring IP FPM end-to-end packet loss and delay
measurement on an IP Radio Access Network (IP RAN) network.
As networks rapidly develop and applications become diversified, various value-added
services are widely used. Link connectivity and network performance influence network
quality. Therefore, performance monitoring is especially important for service transmission.
l For example, users will not sense any change in voice quality if the packet loss rate on
voice links is lower than 5%. However, when the packet loss rate is higher than 10%,
user experience obviously degrades.
l The real-time services such as Voice over Internet Protocol (VoIP), online gaming, and
online video require the delay lower than 100 ms. Some delay-sensitive services even
require that the delay be lower than 50 ms. Otherwise, user experience will degrade.
To meet high requirements for voice, online gaming, and online video on the network, carriers
should be able to monitor the packet loss and delay of the links. They can adjust the links if
service quality decreases.
The IP RAN in Figure 4-11 carries voice services. A voice service flow is a bidirectional
symmetrical flow, so is divided into two unidirectional flows logically. The forward service
flow enters the network through the UPE, travels across SPEs, and leaves the network through
the NPE. The backward service flow enters the network through the NPE, also travels across
SPEs, and leaves the network through the UPE.
Figure 4-11 IP FPM networking

Loopback1
SPE1
GE
0/0
0 /1
Loopback1 /0/0 /0/
GE0/0/2
0 Loopback1
GE
0 GE GE RNC
GE1/0/0 0/0 GE0/0/2
/ 1
GE0/0/2
/0
G
NodeB TLP100 UPE E0/ E 0/0 NPE
0/1 GE G TLP310
In-point 0/0 /0 Out-point
Ingress
/1
E 0/0
G Egress
SPE2
Loopback1
Forward Target Flow
Backward Target Flow

Table 4-3 IP FPM Parameter Configuration

Device (Role) Interface Peer Device (Role) IP Address
UPE (DCP1/MCP) Loopback1 - 1.1.1.1/32
GE1/0/0 NodeB 10.1.1.1/24
GE0/0/0 SPE1 172.16.1.1/24
GE0/0/1 SPE2 172.16.2.1/24
SPE1 Loopback1 - 2.2.2.2/32
GE0/0/0 UPE (DCP1/MCP) 172.16.1.2/24
GE0/0/1 NPE (DCP2) 172.16.4.1/24
GE0/0/2 SPE2 172.16.3.1/24
SPE2 Loopback1 - 3.3.3.3/32
GE0/0/0 NPE (DCP2) 172.16.5.1/24
GE0/0/1 UPE (DCP1/MCP) 172.16.2.2/24
GE0/0/2 SPE1 172.16.3.2/24
NPE (DCP2) Loopback1 - 4.4.4.4/32
GE0/0/0 SPE2 172.16.5.2/24
GE0/0/1 SPE1 172.16.4.2/24
GE0/0/2 RNC 10.2.1.1/24
1. Configure an IP address and a routing protocol for each interface so that all devices can
communicate at the network layer. This example uses Open Shortest Path First (OSPF)
as the routing protocol.
2. Configure Multiprotocol Label Switching (MPLS) and public network tunnels to carry
L3VPN services. In this example, RSVP-TE tunnels are established between the UPE
and SPEs, and LDP-LSP tunnels are established between the SPEs and between the
SPEs and NPE.
3. Create a VPN instance on the UPE and NPE, and import local direct routes on the UPE
and NPE.
4. Establish Multiprotocol Interior Border Gateway Protocol (MP-IBGP) peer relationships
between the UPE and SPEs, and between the NPE and SPEs.
5. Configure SPEs as route reflectors (RRs) and specify the UPE and NPE as RR clients.
6. Configure VPN fast route (FRR) on the UPE and NPE to improve network reliability.
7. Configure Network Time Protocol (NTP) to implement clock synchronization among the
UPE, SPEs, and NPE.

8. Configure continuous packet loss and delay measurement on the link between the UPE
and NPE to collect packet loss and delay statistics at intervals.
Data Preparation
To complete the configuration, you need the following data:
l IP address of each interface listed in Table 4-3.
l IGP (OSPD), process ID (1), and area ID (0).
l Label switching router (LSR) IDs of the UPE (1.1.1.1), SPE1 (2.2.2.2), SPE2 (3.3.3.3),
and NPE (4.4.4.4).
l Tunnel interface names (Tunnel0/0/0), tunnel IDs (100), and tunnel interface addresses
(loopback interface addresses) for forward and backward tunnels between the UPE and
SPE1. Tunnel interface names (Tunnel0/0/1), tunnel IDs (200), and tunnel interface
addresses (loopback interface addresses) for forward and backward tunnels between the
UPE and SPE2. Tunnel policy names (policy1) for the tunnels between the UPE and
SPEs and tunnel selector names (BindTE) on the SPEs.
l Name of the VPN instance (vpna), RD (100:1), and VPN target (1:1) created on the UPE
and NPE
l UPE functions as the NTP master clock, and its clock stratum is 1; the clock
synchronization interval for the UPE, SPE, and NPE is 180s; the time difference (offset)
between the clocks of server and client is 50s; the maximum polling time is 64s.
l UPE's DCP ID and MCP ID (both 1.1.1.1); NPE's DCP ID (4.4.4.4).
l IP FPM instance ID (1) and statistical period (10s).
l Forward target flow's source IP address (10.1.1.2) and destination IP address (10.2.1.2);
backward target flow's source IP address (10.2.1.2) and destination IP address (10.1.1.2).
l Measurement points (TLP100 and TLP310).
l The third and forth color bits in the Type of Service (ToS) field of an IPv4 packet header
are used for packet loss measurement and delay measurement respectively.
NOTE
You can use several fixed bits of the IPv4 packet header as the color bits, including the third to
seventh bits in the ToS field and bit 0 in the Flags field. If two or more bits in packets are reserved,
IP FPM can measure both packet loss rate and delay. If only one bit is reserved, IP FPM can only
measure either packet loss rate or delay.
For details on IP FPM color bits, see Color Bits.
l Authentication mode (HMAC-SHA256), password (Huawei-123), key ID (1), and UDP
port number (2048) on the UPE and NPE.
Procedure
Step 1 Configure an IP address for each interface.
Configure an IP address for each interface according to Table 4-3 and create a loopback
interface on each node. For configuration details, see Configuration Files in this section.
Step 2 Configure OSPF.
Configure the OSPF protocol on each device so that the devices can communicate at the
network layer. For configuration details, see Configuration Files in this section.
Step 3 Configure basic MPLS functions and public network tunnels.

l Configure basic MPLS functions and enable MPLS TE, RSVP-TE, and Constrained
Shortest Path First (CSPF).
# Configure the UPE.
[UPE] mpls lsr-id 1.1.1.1
[UPE] mpls
[UPE-mpls] mpls te
[UPE-mpls] mpls rsvp-te
[UPE-mpls] mpls te cspf
[UPE-mpls] quit
[UPE] interface gigabitethernet 0/0/0
[UPE-GigabitEthernet0/0/0] mpls
[UPE-GigabitEthernet0/0/0] mpls te
[UPE-GigabitEthernet0/0/0] mpls rsvp-te
[UPE-GigabitEthernet0/0/0] quit
[UPE-GigabitEthernet0/0/1] mpls
[UPE-GigabitEthernet0/0/1] mpls te
[UPE-GigabitEthernet0/0/1] mpls rsvp-te
[UPE] ospf 1
[UPE-ospf-1] opaque-capability enable
[UPE-ospf-1] area 0
[UPE-ospf-1-area-0.0.0.0] mpls-te enable
[UPE-ospf-1-area-0.0.0.0] quit
[UPE-ospf-1] quit
# Configure SPE1.
[SPE1] mpls lsr-id 2.2.2.2
[SPE1] mpls
[SPE1-mpls] mpls te
[SPE1-mpls] mpls rsvp-te
[SPE1-mpls] mpls te cspf
[SPE1-mpls] quit
[SPE1] mpls ldp
[SPE1-mpls-ldp] quit
[SPE1] interface gigabitethernet 0/0/0
[SPE1-GigabitEthernet0/0/0] mpls
[SPE1-GigabitEthernet0/0/0] mpls te
[SPE1-GigabitEthernet0/0/0] mpls rsvp-te
[SPE1-GigabitEthernet0/0/0] quit
[SPE1-GigabitEthernet0/0/2] mpls ldp
[SPE1] ospf 1
[SPE1-ospf-1] opaque-capability enable
[SPE1-ospf-1] area 0
[SPE1-ospf-1-area-0.0.0.0] mpls-te enable
[SPE1-ospf-1-area-0.0.0.0] quit
[SPE1-ospf-1] quit
# Configure SPE2.
[SPE2] mpls lsr-id 3.3.3.3
[SPE2] mpls
[SPE2-mpls] mpls te
[SPE2-mpls] mpls rsvp-te
[SPE2-mpls] mpls te cspf
[SPE2-mpls] quit
[SPE2] mpls ldp
[SPE2-mpls-ldp] quit
[SPE2-GigabitEthernet0/0/1] mpls te
[SPE2-GigabitEthernet0/0/1] mpls rsvp-te
[SPE2-GigabitEthernet0/0/2] mpls ldp

[SPE2] ospf 1
[SPE2-ospf-1] opaque-capability enable
[SPE2-ospf-1] area 0
[SPE2-ospf-1-area-0.0.0.0] mpls-te enable
[SPE2-ospf-1-area-0.0.0.0] quit
[SPE2-ospf-1] quit
# Configure the NPE.

[NPE] mpls lsr-id 4.4.4.4
[NPE] mpls
[NPE-mpls] quit
[NPE] mpls ldp
[NPE-mpls-ldp] quit
[NPE] interface gigabitethernet 0/0/0
[NPE-GigabitEthernet0/0/0] mpls
[NPE-GigabitEthernet0/0/0] mpls ldp
[NPE-GigabitEthernet0/0/0] quit
[NPE-GigabitEthernet0/0/1] mpls
[NPE-GigabitEthernet0/0/1] mpls ldp
l Enable the egress node of each unidirectional tunnel to assign labels to the penultimate
hop.
[UPE] mpls
[UPE-mpls] label advertise non-null
[UPE-mpls] quit
# Configure SPE1.
[SPE1] mpls
[SPE1-mpls] label advertise non-null
[SPE1-mpls] quit
# Configure SPE2.
[SPE2] mpls
[SPE2-mpls] label advertise non-null
[SPE2-mpls] quit
l Configure MPLS TE tunnel interfaces.

[UPE] interface tunnel 0/0/0
[UPE-Tunnel0/0/0] ip address unnumbered interface loopback 1
[UPE-Tunnel0/0/0] tunnel-protocol mpls te
[UPE-Tunnel0/0/0] destination 2.2.2.2
[UPE-Tunnel0/0/0] mpls te tunnel-id 100
[UPE-Tunnel0/0/0] mpls te signal-protocol rsvp-te
[UPE-Tunnel0/0/0] mpls te reserved-for-binding
[UPE-Tunnel0/0/0] mpls te commit
[UPE-Tunnel0/0/0] quit
[UPE] interface tunnel 0/0/1
[UPE-Tunnel0/0/1] ip address unnumbered interface loopback 1
[UPE-Tunnel0/0/1] tunnel-protocol mpls te
[UPE-Tunnel0/0/1] destination 3.3.3.3
[UPE-Tunnel0/0/1] mpls te tunnel-id 200
[UPE-Tunnel0/0/1] mpls te signal-protocol rsvp-te
[UPE-Tunnel0/0/1] mpls te reserved-for-binding
[UPE-Tunnel0/0/1] mpls te commit
[UPE-Tunnel0/0/1] quit
# Configure SPE1.
[SPE1] interface tunnel 0/0/0
[SPE1-Tunnel0/0/0] ip address unnumbered interface loopback 1
[SPE1-Tunnel0/0/0] tunnel-protocol mpls te
[SPE1-Tunnel0/0/0] destination 1.1.1.1
[SPE1-Tunnel0/0/0] mpls te tunnel-id 100
[SPE1-Tunnel0/0/0] mpls te signal-protocol rsvp-te
[SPE1-Tunnel0/0/0] mpls te reserved-for-binding

[SPE1-Tunnel0/0/0] mpls te commit

[SPE1-Tunnel0/0/0] quit
# Configure SPE2.
[SPE2] interface tunnel 0/0/1
[SPE2-Tunnel0/0/1] ip address unnumbered interface loopback 1
[SPE2-Tunnel0/0/1] tunnel-protocol mpls te
[SPE2-Tunnel0/0/1] destination 1.1.1.1
[SPE2-Tunnel0/0/1] mpls te tunnel-id 200
[SPE2-Tunnel0/0/1] mpls te signal-protocol rsvp-te
[SPE2-Tunnel0/0/1] mpls te reserved-for-binding
[SPE2-Tunnel0/0/1] mpls te commit
[SPE2-Tunnel0/0/1] quit
l Configure tunnel policies.

[UPE] tunnel-policy policy1
[UPE-tunnel-policy-policy1] tunnel binding destination 2.2.2.2 te tunnel 0/0/0
[UPE-tunnel-policy-policy1] tunnel binding destination 3.3.3.3 te tunnel 0/0/1
[UPE-tunnel-policy-policy1] quit
# Configure SPE1.
[SPE1] tunnel-policy policy1
[SPE1-tunnel-policy-policy1] tunnel binding destination 1.1.1.1 te tunnel
0/0/0
[SPE1-tunnel-policy-policy1] quit
# Configure SPE2.
[SPE2] tunnel-policy policy1
[SPE2-tunnel-policy-policy1] tunnel binding destination 1.1.1.1 te tunnel
0/0/1
[SPE2-tunnel-policy-policy1] quit
Step 4 Create a VPN instance on the UPE and NPE, and import local direct routes on the UPE and
NPE.
[UPE] ip vpn-instance vpna
[UPE-vpn-instance-vpna] ipv4-family
[UPE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[UPE-vpn-instance-vpna-af-ipv4] vpn-target 1:1
[UPE-vpn-instance-vpna-af-ipv4] quit
[UPE-vpn-instance-vpna] quit
[UPE-GigabitEthernet1/0/0] ip binding vpn-instance vpna
[UPE-GigabitEthernet1/0/0] ip address 10.1.1.1 24
[UPE] bgp 100
[UPE-bgp] ipv4-family vpn-instance vpna
[UPE-bgp-vpna] import-route direct
[UPE-bgp-vpna] quit
[UPE-bgp] quit

[NPE] ip vpn-instance vpna
[NPE-vpn-instance-vpna] ipv4-family
[NPE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[NPE-vpn-instance-vpna-af-ipv4] vpn-target 1:1
[NPE-vpn-instance-vpna-af-ipv4] quit
[NPE-vpn-instance-vpna] quit
[NPE-GigabitEthernet0/0/2] ip binding vpn-instance vpna
[NPE-GigabitEthernet0/0/2] ip address 10.2.1.1 24
[NPE] bgp 100
[NPE-bgp] ipv4-family vpn-instance vpna

[NPE-bgp-vpna] import-route direct

[NPE-bgp-vpna] quit
[NPE-bgp] quit
Step 5 Configure MP-IBGP peer relationships between the UPE and SPEs, and between the NPE and
SPEs.
[UPE] bgp 100
[UPE-bgp] router-id 1.1.1.1
[UPE-bgp] peer 2.2.2.2 as-number 100
[UPE-bgp] peer 2.2.2.2 connect-interface loopback 1
[UPE-bgp] peer 3.3.3.3 as-number 100
[UPE-bgp] peer 3.3.3.3 connect-interface loopback 1
[UPE-bgp] ipv4-family vpnv4
[UPE-bgp-af-vpnv4] peer 2.2.2.2 enable
[UPE-bgp-af-vpnv4] peer 3.3.3.3 enable
[UPE-bgp-af-vpnv4] quit
[UPE-bgp] quit
# Configure SPE1.
[SPE1] bgp 100
[SPE1-bgp] router-id 2.2.2.2
[SPE1-bgp] peer 1.1.1.1 as-number 100
[SPE1-bgp] peer 1.1.1.1 connect-interface loopback 1
[SPE1-bgp] ipv4-family vpnv4
[SPE1-bgp-af-vpnv4] undo policy vpn-target
[SPE1-bgp-af-vpnv4] peer 1.1.1.1 enable
[SPE1-bgp-af-vpnv4] quit
[SPE1-bgp] quit
The configuration for SPE2 is similar to that for SPE1. For configuration details, see
Configuration Files in this section.
[NPE] bgp 100
[NPE-bgp] router-id 4.4.4.4
[NPE-bgp] peer 2.2.2.2 as-number 100
[NPE-bgp] peer 2.2.2.2 connect-interface loopback 1
[NPE-bgp] peer 3.3.3.3 as-number 100
[NPE-bgp] peer 3.3.3.3 connect-interface loopback 1
[NPE-bgp] ipv4-family vpnv4
[NPE-bgp-af-vpnv4] peer 2.2.2.2 enable
[NPE-bgp-af-vpnv4] peer 3.3.3.3 enable
[NPE-bgp-af-vpnv4] quit
[NPE-bgp] quit
Step 6 Configure SPEs as RRs and specify the UPE and NPE as RR clients. The following example
uses SPE1.
[SPE1] bgp 100
[SPE1-bgp-af-vpnv4] peer 1.1.1.1 reflect-client
[SPE1-bgp-af-vpnv4] peer 1.1.1.1 next-hop-local
[SPE1-bgp-af-vpnv4] peer 4.4.4.4 reflect-client
[SPE1-bgp-af-vpnv4] peer 4.4.4.4 next-hop-local
[SPE1-bgp] quit
Step 7 Configure a tunnel policy on the UPE and a tunnel selector on each SPE to bind the TE
tunnels between the UPE and SPEs.

# Configure a tunnel policy on the UPE.

[UPE] ip vpn-instance vpna
[UPE-vpn-instance-vpna] ipv4-family
[UPE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1
[UPE-vpn-instance-vpna-af-ipv4] tnl-policy policy1
[UPE-vpn-instance-vpna-af-ipv4] quit
[UPE-vpn-instance-vpna] quit
# As no VPN instance is configured on SPEs, configure tunnel selectors on the SPEs bind TE
tunnels. The following example uses SPE1.
[SPE1] tunnel-selector bindTE permit node 10
[SPE1-tunnel-selector] apply tunnel-policy policy1
[SPE1-tunnel-selector] quit
[SPE1] bgp 100
[SPE1-bgp-af-vpnv4] tunnel-selector bindTE
The configuration for SPE2 is similar to that for SPE1. For configuration details, see
Configuration Files in this section.
Step 8 Configure VPN FRR on the UPE and NPE to improve network reliability.
# Configure the VPN FRR function on the UPE and NPE. The following example uses UPE.
[UPE] bgp 100
[UPE-bgp] ipv4-family vpn-instance vpna
[UPE-bgp-vpna] auto-frr
[UPE-bgp-vpna] quit
[UPE-bgp] quit
After completing the configurations, run the display bgp vpnv4 vpn-instance vpna routing-
table command on the UPE and NPE to view detailed information about received routes.
[UPE] display bgp vpnv4 vpn-instance vpna routing-table
BGP Local router ID is 1.1.1.1

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
VPN-Instance vpna, Router ID 1.1.1.1:
Total Number of Routes: 4

Network NextHop MED LocPrf PrefVal Path/Ogn
*> 10.1.1.0/24 0.0.0.0 0 0 ?

*> 10.1.1.1/32 0.0.0.0 0 0 ?
*>i 10.2.1.0/24 2.2.2.2 0 100 0 ?
* i 4.4.4.4 0 100 0 ?
[NPE] display bgp vpnv4 vpn-instance vpna routing-table
BGP Local router ID is 4.4.4.4

Status codes: * - valid, > - best, d - damped,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
VPN-Instance vpna, Router ID 4.4.4.4:
Total Number of Routes: 4

Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 10.1.1.0/24 2.2.2.2 0 100 0 ?

* i 4.4.4.4 0 100 0 ?
*> 10.2.1.0/24 0.0.0.0 0 0 ?
*> 10.2.1.1/32 0.0.0.0 0 0 ?

The command output shows that both the UPE and NPE preferentially select the routes
advertised by SPE1 and use UPE-SPE1-NPE as the primary path.
Step 9 Configure NTP to implement clock synchronization among the UPE, SPE1, and NPE.
[UPE] ntp-service refclock-master 2
# Configure SPE1.
[SPE1] ntp-service unicast-server 172.16.1.1

[NPE] ntp-service unicast-server 172.16.4.1
After completing the configurations, run the display ntp-service status command on the
UPE, SPE1, and NPE to view information about clock synchronization.
Check the NTP status on the UPE. The command output shows that the clock status is
synchronized, which means that synchronization is complete.
[UPE] display ntp-service status
clock status: synchronized
clock stratum: 2
reference clock ID: LOCAL(0)
nominal frequency: 100.0000 Hz
actual frequency: 100.0000 Hz
clock precision: 2^18
clock offset: 0.0000 ms
root delay: 0.00 ms
root dispersion: 10.95 ms
peer dispersion: 10.00 ms
reference time: 16:46:27.496 UTC Jun 24 2017(DCF915E3.7F2A9D62)
Check the NTP status on SPE1. The command output shows that the clock status is
synchronized, which means that synchronization is complete. The clock stratum is 2, lower
than that of the UPE.
[SPE1] display ntp-service status
clock stratum: 3
reference clock ID: 172.16.1.1
nominal frequency: -nan Hz
actual frequency: -nan Hz
clock offset: -1.1605 ms
root delay: 1.51 ms
root dispersion: -nan ms
reference time: 16:45:53.064 UTC Jun 24 2017(DCF915C1.107314CA)
Check the NTP status on the NPE. The command output shows that the clock status is
synchronized, which means that synchronization is complete. The clock stratum is 3, lower
than that of the UPE.
[NPE] display ntp-service status
clock stratum: 4
reference clock ID: 172.16.4.1
nominal frequency: 100.0000 Hz
actual frequency: 100.0000 Hz
clock offset: 0.0025 ms
root delay: 2.46 ms
root dispersion: 32.52 ms
reference time: 16:47:26.933 UTC Jun 24 2017(DCF9161E.EEE8F29D)
Step 10 Configure continuous packet loss and delay measurement on the link between the UPE and
NPE. Configure the NPE as the DCP and TLP 310 on the NPE; configure the UPE as the
DCP and also an MCP and configure TLP 100 on the UPE.


l Configure the MCP.
[UPE] nqa ipfpm mcp
[UPE-nqa-ipfpm-mcp] mcp id 1.1.1.1
[UPE-nqa-ipfpm-mcp] protocol udp port 2048
[UPE-nqa-ipfpm-mcp] authentication-mode hmac-sha256 key-id 1 cipher Huawei-123
[UPE-nqa-ipfpm-mcp] instance 1
[UPE-nqa-ipfpm-mcp-instance-1] dcp 1.1.1.1
[UPE-nqa-ipfpm-mcp-instance-1] dcp 4.4.4.4
[UPE-nqa-ipfpm-mcp-instance-1] quit
[UPE-nqa-ipfpm-mcp] quit
After completing the configurations, run the display ipfpm mcp command on the UPE.
The command output shows MCP configurations and status on the UPE.
[UPE] display ipfpm mcp
Specification Information:
Max Instance Number :4000
Max DCP Number Per Instance :1000
Configuration Information:
MCP ID :1.1.1.1
Status :Active
Protocol Port :2048
Current Instance Number :1
l Configure the DCP.

[UPE] nqa ipfpm dcp
[UPE-nqa-ipfpm-dcp] dcp id 1.1.1.1
[UPE-nqa-ipfpm-dcp] authentication-mode hmac-sha256 key-id 1 cipher Huawei-123
[UPE-nqa-ipfpm-dcp] color-flag loss-measure tos-bit 3 delay-measure tos-bit 4
[UPE-nqa-ipfpm-dcp] mcp 1.1.1.1 port 2048
[UPE-nqa-ipfpm-dcp] instance 1
[UPE-nqa-ipfpm-dcp-instance-1] interval 10
[UPE-nqa-ipfpm-dcp-instance-1] flow bidirectional source 10.1.1.2 destination
10.2.1.2
[UPE-nqa-ipfpm-dcp-instance-1] tlp 100 in-point ingress
[UPE-nqa-ipfpm-dcp-instance-1] quit
[UPE-nqa-ipfpm-dcp] quit
After completing the configurations, run the display ipfpm dcp command on the UPE.
The command output shows DCP configurations on the UPE.
[UPE] display ipfpm dcp
Specification Information(Main Board):
Max 10s Instance Number :16384
Max TLP Number :2048
Max TLP Number Per Instance :16
Specification Information(IO Board):

Board ID:1
Max non-1s Instance Number :2048
DCP ID : 1.1.1.1
Loss-measure Flag : tos-bit3
Delay-measure Flag : tos-bit4
Authentication Mode : hmac-sha256
Test Instances MCP ID : 1.1.1.1
Test Instances MCP Port : 2048
Current Instance Number : 1
l Bind the TLP to an interface.

[UPE] interface GigabitEthernet1/0/0
[UPE-GigabitEthernet1/0/0] ipfpm tlp 100
l Enable packet loss and delay measurement.

[UPE] nqa ipfpm dcp

[UPE-nqa-ipfpm-dcp] instance 1
[UPE-nqa-ipfpm-dcp-instance-1] loss-measure enable continual
[UPE-nqa-ipfpm-dcp-instance-1] delay-measure enable two-way tlp 100 continual
[UPE-nqa-ipfpm-dcp-instance-1] quit
[UPE-nqa-ipfpm-dcp] quit

l Configure the DCP.
[NPE] nqa ipfpm dcp
[NPE-nqa-ipfpm-dcp] dcp id 4.4.4.4
[NPE-nqa-ipfpm-dcp] authentication-mode hmac-sha256 key-id 1 cipher Huawei-123
[UPE-nqa-ipfpm-dcp] color-flag loss-measure tos-bit 3 delay-measure tos-bit 4
[NPE-nqa-ipfpm-dcp] mcp 1.1.1.1 port 2048
[NPE-nqa-ipfpm-dcp] instance 1
[NPE-nqa-ipfpm-dcp-instance-1] interval 10
[NPE-nqa-ipfpm-dcp-instance-1] flow bidirectional source 10.1.1.2 destination
10.2.1.2
[NPE-nqa-ipfpm-dcp-instance-1] tlp 310 out-point egress
[NPE-nqa-ipfpm-dcp-instance-1] quit
[NPE-nqa-ipfpm-dcp] quit
After completing the configurations, run the display ipfpm dcp command on the NPE.
The command output shows DCP configurations on the NPE.
[NPE] display ipfpm dcp
Specification Information(Main Board):
Max TLP Number Per Instance :16
Specification Information(IO Board):

Board ID:1
Max non-1s Instance Number :2048
DCP ID : 4.4.4.4
Loss-measure Flag : tos-bit3
Delay-measure Flag : tos-bit4
Authentication Mode : hmac-sha256
Test Instances MCP ID : 1.1.1.1
Test Instances MCP Port : 2048
Current Instance Number : 1
l Bind the TLP to an interface.

[NPE] interface gigabitethernet0/0/2
[NPE-GigabitEthernet0/0/2] ipfpm tlp 310
l Enable packet loss and delay measurement.

[NPE] nqa ipfpm dcp
[NPE-nqa-ipfpm-dcp] instance 1
[NPE-nqa-ipfpm-dcp-instance-1] loss-measure enable continual
[NPE-nqa-ipfpm-dcp-instance-1] delay-measure enable two-way tlp 310 continual

Run the display ipfpm statistic-type { loss | twoway-delay } instance instance-id command
on the UPE to view the performance statistics for a specified IP FPM instance.
l # View the packet loss statistics for IP FPM instance 1.
[UPE] display ipfpm statistic-type loss instance 1
Latest loss statistics of forward flow:
Unit: p - packet, b - byte
------------------------------------------------------------------------------
------------

Period Loss(p) LossRatio(p) Loss(b)

LossRatio(b)
------------------------------------------------------------------------------
------------
136118757 20 20.000000%
2000 20.000000%
136118756 20 20.000000%
2000 20.000000%
136118755 20 20.000000%
2000 20.000000%
136118753 20 20.000000%
2000 20.000000%
136118752 20 20.000000%
2000 20.000000%
136118751 20 20.000000%
2000 20.000000%
136118750 20 20.000000%
2000 20.000000%
136118749 20 20.000000%
2000 20.000000%
136118748 20 20.000000%
2000 20.000000%
136118747 20 20.000000%
2000 20.000000%
136118746 20 20.000000%
2000 20.000000%
136118745 20 20.000000%
2000 20.000000%
Latest loss statistics of backward flow:

Unit: p - packet, b - byte
------------------------------------------------------------------------------
------------
Period Loss(p) LossRatio(p) Loss(b)
LossRatio(b)
------------------------------------------------------------------------------
------------
136118757 20 20.000000%
2000 20.000000%
136118756 20 20.000000%
2000 20.000000%
136118755 20 20.000000%
2000 20.000000%
136118753 20 20.000000%
2000 20.000000%
136118752 20 20.000000%
2000 20.000000%
136118751 20 20.000000%
2000 20.000000%
136118750 20 20.000000%
2000 20.000000%
136118749 20 20.000000%
2000 20.000000%
136118748 20 20.000000%
2000 20.000000%
136118747 20 20.000000%
2000 20.000000%
136118746 20 20.000000%
2000 20.000000%
136118745 20 20.000000%
2000 20.000000%
l # View the two-way delay statistics for IP FPM instance 1.

[UPE] display ipfpm statistic-type twoway-delay instance 1
Latest two-way delay statistics:
--------------------------------------------------
Period Delay(usec) Delay
Variation(usec)
--------------------------------------------------
136118757 800 0

136118756 800 0
136118755 800 0
136118753 800 0
136118752 800 0
136118751 800 0
136118750 800 0
136118749 800 0
136118748 800 0
136118747 800 0
136118746 800 0
136118745 800 0
----End
Configuration Files
l UPE configuration file
#
sysname UPE
#
ip vpn-instance
vpna
ipv4-
family
route-distinguisher
100:1
tnl-policy
policy1
vpn-target 1:1 export-
extcommunity
vpn-target 1:1 import-
extcommunity
#
mpls lsr-id
1.1.1.1
mpls
mpls
te
label advertise non-
null
mpls rsvp-
te
mpls te
cspf
#
ntp-service refclock-master
2
#
interface
GigabitEthernet0/0/0
undo
shutdown
ip address 172.16.1.1
255.255.255.0
mpls
mpls
te
mpls rsvp-
te
#

undo
shutdown
255.255.255.0
mpls
mpls
te
mpls rsvp-
te
#
interface
undo
shutdown
ip binding vpn-instance
vpna
ip address 10.1.1.1
255.255.255.0
ipfpm tlp
100
#
interface
LoopBack1
ip address 1.1.1.1
255.255.255.255
#
interface
Tunnel0/0/0
ip address unnumbered interface
LoopBack1
tunnel-protocol mpls
te
destination
2.2.2.2
mpls te tunnel-id
100
mpls te reserved-for-binding
mpls te commit
#
interface
Tunnel0/0/1
LoopBack1
te
destination
3.3.3.3
mpls te tunnel-id
200
mpls te commit
#
bgp
100
router-id
1.1.1.1
peer 2.2.2.2 as-number
100
peer 2.2.2.2 connect-interface
LoopBack1


100
LoopBack1
ipv4-family
unicast
undo
synchronization
peer 2.2.2.2
enable
peer 3.3.3.3
enable
ipv4-family
vpnv4
policy vpn-
target
peer 2.2.2.2
enable
peer 3.3.3.3
enable
ipv4-family vpn-instance
vpna
import-route
direct
auto-
frr
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 1.1.1.1
0.0.0.0
network 172.16.1.0
0.0.0.255
network 172.16.2.0
0.0.0.255
mpls-te
enable
#
tunnel-policy
policy1
tunnel binding destination 2.2.2.2 te
Tunnel0/0/0
Tunnel0/0/1
#
nqa ipfpm
dcp
dcp id
1.1.1.1
mcp 1.1.1.1 port
2048
authentication-mode hmac-sha256 key-id 1 cipher %#%#wby+WKE/g70T
%D;W4(K9o"":C.B^K~/1(WXD1lLB%#%#

color-flag loss-measure tos-bit 3 delay-measure tos-bit 4

instance 1
flow bidirectional source 10.1.1.2 destination 10.2.1.2
tlp 100 in-point ingress
loss-measure enable continual
delay-measure enable two-way tlp 100 continual
#
nqa ipfpm
mcp
mcp id
1.1.1.1
protocol udp port
2048
authentication-mode hmac-sha256 key-id 1 cipher %^%#\8u;Ufa-'-+mtJG0r#:
00dV[Kds2oUW4(K9o"":CKE/gs%^%#
instance
1
dcp
1.1.1.1
dcp
4.4.4.4
return
l SPE1 configuration file
#
sysname SPE1
#
tunnel-selector bindTE permit node

10
apply tunnel-policy
policy1
#
mpls lsr-id
2.2.2.2
mpls
mpls
te
label advertise non-
null
mpls rsvp-
te
mpls te
cspf
#
mpls
ldp
#
ntp-service unicast-server
172.16.1.1
#
interface
undo
shutdown
255.255.255.0
mpls

mpls
te
mpls rsvp-
te
#
interface
undo
shutdown
255.255.255.0
mpls
mpls
ldp
#
interface
undo
shutdown
255.255.255.0
mpls
mpls
ldp
#
interface
LoopBack1
ip address 2.2.2.2
255.255.255.0
#
interface
Tunnel0/0/0
LoopBack1
te
destination
1.1.1.1
mpls te tunnel-id
100
mpls te commit
#
bgp
100
router-id
2.2.2.2
100
LoopBack1
100
LoopBack1
100
LoopBack1

ipv4-family
unicast
undo
synchronization
peer 1.1.1.1
enable
peer 3.3.3.3
enable
peer 4.4.4.4
enable
ipv4-family
vpnv4
undo policy vpn-
target
tunnel-selector
bindTE
peer 1.1.1.1
enable
peer 1.1.1.1 reflect-
client
peer 1.1.1.1 next-hop-
local
peer 3.3.3.3
enable
peer 4.4.4.4
enable
peer 4.4.4.4 reflect-
client
peer 4.4.4.4 next-hop-
local
#
ospf
1
opaque-capability
enable
area
0.0.0.0
network 2.2.2.2
0.0.0.0
network 172.16.1.0
0.0.0.255
network 172.16.3.0
0.0.0.255
network 172.16.4.0
0.0.0.255
mpls-te
enable
#
tunnel-policy
policy1
Tunnel0/0/0
#
return
l SPE2 configuration file
#
sysname SPE2
#
tunnel-selector bindTE permit node 10
apply tunnel-policy policy1
#
mpls lsr-id 3.3.3.3

mpls
mpls te
label advertise non-null
mpls rsvp-te
mpls te cspf
#
mpls ldp
#
undo shutdown
ip address 172.16.5.1 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 172.16.2.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
undo shutdown
ip address 172.16.3.2 255.255.255.0
mpls
mpls te
mpls ldp
#
interface LoopBack1
ip address 3.3.3.3 255.255.255.255
#
interface Tunnel0/0/1
ip address unnumbered interface LoopBack1
tunnel-protocol mpls te
destination 1.1.1.1
mpls te tunnel-id 200
mpls te commit
#
bgp 100
router-id 3.3.3.3
peer 1.1.1.1 as-number 100
peer 1.1.1.1 connect-interface LoopBack1
#
ipv4-family unicast
undo synchronization
peer 1.1.1.1 enable
peer 2.2.2.2 enable
peer 4.4.4.4 enable
#
ipv4-family vpnv4
undo policy vpn-target
tunnel-selector bindTE
peer 1.1.1.1 enable
peer 1.1.1.1 reflect-client
peer 1.1.1.1 next-hop-local
peer 2.2.2.2 enable
peer 4.4.4.4 enable
peer 4.4.4.4 reflect-client
peer 4.4.4.4 next-hop-local
#
ospf 1
opaque-capability enable
area 0.0.0.0
network 3.3.3.3 0.0.0.0

network 172.16.2.0 0.0.0.255

network 172.16.3.0 0.0.0.255
network 172.16.5.0 0.0.0.255
mpls-te enable
#
tunnel-policy policy1
tunnel binding destination 1.1.1.1 te Tunnel0/0/1
#
return
l NPE configuration file
#
sysname NPE
#
ip vpn-instance vpna
ipv4-family
route-distinguisher 100:1
vpn-target 1:1 export-extcommunity
vpn-target 1:1 import-extcommunity
#
mpls lsr-id 4.4.4.4
mpls
#
mpls ldp
#
ntp-service unicast-server 172.16.4.1
#
undo shutdown
ip address 172.16.5.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip address 172.16.4.2 255.255.255.0
mpls
mpls ldp
#
undo shutdown
ip binding vpn-instance vpna
ip address 10.2.1.1 255.255.255.0
ipfpm tlp 310
#
interface LoopBack1
ip address 4.4.4.4 255.255.255.255
#
bgp 100
router-id 4.4.4.4
#
ipv4-family unicast
undo synchronization
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpnv4
policy vpn-target
peer 2.2.2.2 enable
peer 3.3.3.3 enable
#
ipv4-family vpn-instance vpna
import-route direct
auto-frr
#
ospf 1

area 0.0.0.0
network 4.4.4.4 0.0.0.0
network 172.16.4.0 0.0.0.255
network 172.16.5.0 0.0.0.255
#
nqa ipfpm dcp
dcp id 4.4.4.4
mcp 1.1.1.1 port 2048
authentication-mode hmac-sha256 key-id 1 cipher %^%#;\VV*UAUfP'8+uS{,4v
+1GjvKE/g70T%D;Ufa-'-+mtJG%^%#
color-flag loss-measure tos-bit 3 delay-measure tos-bit 4
instance 1
flow bidirectional source 10.1.1.2 destination 10.2.1.2
tlp 310 out-point egress
loss-measure enable continual
delay-measure enable two-way tlp 310 continual
#
return

and Monitoring 5 CWMP Configuration
5 CWMP Configuration
About This Chapter
This chapter describes the basic concept, configuration procedures, and configuration
examples of CWMP.
5.1 Overview of CWMP

This section describes the definition, background, and functions of CWMP.
5.2 Understanding CWMP
This section describes the implementation of CWMP.
5.3 Application Scenarios for CWMP
This section describes the applicable scenario of CWMP.
5.4 Licensing Requirements and Limitations for CWMP
This section provides the points of attention when configuring CWMP.
5.5 Default Settings for CWMP
The following table describes the default settings for CWMP.
5.6 Configuring CWMP
This section describes how to configure CWMP.
5.7 Configuration Examples for CWMP
This chapter provides configuration examples for CWMP.
5.8 Troubleshooting CWMP
This topic describes the common CWMP configuration error, including the fault symptoms
and troubleshooting procedure.
5.9 FAQ About CWMP
5.1 Overview of CWMP

This section describes the definition, background, and functions of CWMP.

Definition
On a DSL network, device management is difficult because there are many user-side devices
distributed at different locations. CWMP defines that the customer premises equipment (CPE)
is remotely managed by an auto-configuration server (ACS). CWMP facilitates CPE
management, reduces maintenance and operation costs, and improves troubleshooting
efficiency.
CWMP, also called Technical Report 069 (TR-069), is a technical specification drafted by the
Digital Subscriber's Line forum (DSL forum, which was later renamed as Broadband Forum).
Purpose
CWMP provides methods to manage and configure home network devices on the next
generation network. Currently, terminal management faces the following problems:
l Different vendors manage their terminals in different ways.
Terminal vendors manage their terminals by using different protocols such as the Optical
Network Terminal Management and Control Interface (OMCI) and Embedded
Operations Channel (EOC) protocols. Carriers must integrate these vendors' network
management systems multiple times to implement unified management.
l Various terminals lead to complex terminal management.
With emergence of new access technologies, various terminals are developed, such as
access points (APs), optical network terminals (ONTs), and shared risk groups (SRGs),
which are difficult to manage.
l Troubleshooting is difficult because of a large number of terminals.
On a network, most faults occur on the user side, where a large number of terminals are
scattered; therefore, troubleshooting is difficult.
To solve the preceding problems, CWMP defines a mechanism to manage the CPE by an
ACS. This facilitates CPE management, reduces maintenance and operation costs, and
improves troubleshooting efficiency.
5.2 Understanding CWMP

This section describes the implementation of CWMP.
5.2.1 CWMP Network Model

Figure 5-1 shows the CWMP network model.
Figure 5-1 CWMP network model
Internet
CPE ACS
A CWMP network model contains:

l ACS: manages and maintains CPEs on the network.

l CPE: managed by the ACS.
NOTE
A router is deployed as a CPE.
5.2.2 CWMP Implementation
CWMP Process
Figure 5-2 shows the CWMP working process when the ACS changes a parameter value on
the CPE.
Figure 5-2 CWMP process
CPE ACS
1 Open connection
2 SSL initiation
Session
initiation
3 phase
HTTP post
Inform requst
4 HTTP response
Inform response
5 HTTP post (empty)
6 HTTP response
Communication
GetParameterValues requst
phase
7 HTTP post
GetParameterValues response
8 HTTP response
SetParameterValues requst
9 HTTP post
SetParameterValues response
10
Session
HTTP response (empty)
termination
phase
11
Close connection
The CWMP process is as follows:

1. A CPE initiates a session.

If an ACS initiates a session, it sends a Connect request to the CPE (which functions as
an HTTP server) to set up a session.
2. The CPE and ACS use Security Socket Layer (SSL) protocol to set up a secure
connection.
3. The CPE invokes the Remote Procedure Call (RPC) method Inform to send an Inform
request to the ACS, reporting device information and requesting a CWMP connection.
4. After the CPE is authenticated, the ACS sends an Inform response. The Inform method is
complete and the CWMP connection is set up.
5. The CPE sends an empty HTTP post message to the ACS, indicating that the CPE does
not invoke any more RPC methods supported by the ACS.
6. The ACS invokes the GetParameterValues method to query CPE parameters.
7. The CPE sends a GetParameterValues response containing the queried parameters to the
ACS. The GetParameterValues method is complete.
8. The ACS invokes the SetParameterValues method to set CPE parameters.
9. The CPE sends a SetParameterValues response containing the parameter settings to the
ACS. The SetParameterValues method is complete.
10. The ACS sends an empty HTTP response to the CPE, indicating that the ACS does not
invoke any more RPC methods supported by the CPE.
11. The CPE terminates the connection.
As shown in Figure 5-2, the CWMP session goes through three phases.
Session initiation phase
A session can be initiated by a CPE or an ACS.

l A CPE initiates a session in the following scenarios:
– After startup, the CPE searches for an ACS based on the local configuration or the
ACS URL allocated by the Dynamic Host Configuration Protocol (DHCP) server,
and then initiates a session.
– The CPE is configured to send Inform messages at intervals. The CPE will
automatically send an Inform message to initiate a session when the interval arrives
(1 hour for example).
– The CPE is configured to send Inform messages at a specified time. The CPE will
automatically send an Inform message at the time to initiate a session.
– If session setup is interrupted unexpectedly and the number of CPE auto-connection
retries has not reached the upper limit, the CPE automatically sets up a new
connection.
l An ACS initiates a session.
An ACS can send a Connect request to a CPE at any time. After the CPE authenticates
the request, a session between the CPE and the ACS is set up.
The prerequisite for this method is that the CPE and the ACS have communicated with
each other before. During the first communication between the CPE and the ACS, the
ACS saves the CPE IP address in the address list. Then it can initiate a session in
subsequent communication with the CPE.
CWMP uses security mechanisms to protect communication between a CPE and an ACS. The
security mechanisms prevent the transactions between the CPE and the ACS from being

tampered and ensure confidentiality of the transactions. CWMP supports the following
security mechanisms:
l CPE and ACS authentication:
– CPE authentication on the ACS side: A CPE sends an Inform request based on the
ACS URL configured locally to communicate with an ACS. After the CPE is
authenticated (the ACS user name and password in the Inform request are the same
as those configured on the ACS), a session is set up between the CPE and the ACS.
– ACS authentication on the CPE side: An ACS sends an Inform reques containing a
CPE IP address to communicate with a CPE. After the ACS is authenticated (the
CPE user name and password in the HTTP request are the same as those configured
on the CPE), a session is set up between the CPE and the ACS.
l Security Socket Layer (SSL) authentication:
It ensures transaction confidentiality and data integrity and enables the CPE and ACS to
authenticate each other using certificates.
SSL operates independently of application-layer protocols. Any types of application-
layer protocols (including HTTP, FTP, and Telnet) can set up connections based on SSL.
SSL finishes data encryption, key negotiation, and server authentication before the
application-layer protocols set up connections. Therefore, all data transmitted by the
application-layer protocols is encrypted.
NOTE
Certificate contains personal or an enterprise's information and public key:

l Public key: The two ends share a public key to encrypt data and verify signatures.
l Private key: Each end has a private key to decrypt data and sign signature.
l Signature: Information containing a signature cannot be modified by anyone except the
creator. It ensures data security and integrity.
Communication phase
After a session is initiated, a CPE or an ACS can send requests to each other to perform
operations. For example, the ACS can query and set CPE parameters, and the CPE can upload
files to or download files from the file server specified by the ACS.
Session termination phase
Only a CPE can terminate a session.
If the ACS and CPE have sent all necessary requests and received all responses, the CPE
terminates the session.
CWMP Operation Methods

An ACS manages and monitors a CPE by performing a series of operations. These operations
are called RPC methods in CWMP.
CWMP supports the following standard RPC methods:
l Generic method: Both the CPE and the ACS must support this method. Table 5-1
describes a generic method, which can be invoked by both the CPE and the ACS.

Table 5-1 Generic method

Method Description
GetRPCMethods Used to obtain RPC methods supported by the CPE and the
ACS.
l CPE methods: The CPE must support these methods. Table 5-2 lists the CPE methods,
which can be invoked only by the ACS.
Table 5-2 CPE methods

Method Description
SetParameterVal- Used by an ACS to set CPE parameters.

ues
GetParameterVal- Used by an ACS to obtain CPE parameter values.

ues
GetParameterNam Used by an ACS to discover accessible parameters of a CPE.

es
SetParameterAttri- Used by an ACS to set attributes of CPE parameters.

butes
GetParameterAttri- Used by an ACS to obtain CPE parameter attributes.

butes
AddObject Used by an ACS to create instances for a multi-instance object

in the CPE data model.
DeleteObject Used by an ACS to delete instances of a multi-instance object

from the CPE data model.
Download Used by an ACS to request a CPE to download a file from a

specified URL and use the downloaded file to replace the local
file on the CPE.
Upload Used by an ACS to request a CPE to upload a file to a specified

URL.
Reboot Used by an ACS to remotely restart a CPE when the CPE is

faulty or the CPE software is upgraded.
FactoryReset Used by an ACS to restore the factory settings of a CPE.
ScheduleInfrom Used by an ACS to set the delay after which the CPE sends an
inform message.
l ACS methods: The ACS must support these methods. Table 5-3 lists the ACS methods,
which can be invoked only by the CPE.

Table 5-3 ACS methods

Method Description
Inform Used by a CPE to send an Inform message to an ACS when the

CPE needs to initiate a session with the ACS or periodically
send local information to the ACS, or when the CPE bottom-
layer configuration changes.
TransferComplete Used by a CPE to notify an ACS that requested file download or

upload is complete no matter whether the file is successfully
downloaded or uploaded.
5.2.3 CPE Management

CWMP provides many CPE management functions, which improve CPE operation efficiency
and decrease network management problems. Main CPE management functions include:
l Automatic configuration
l File management
l Status and performance monitoring
l Fault diagnosis
Automatic Configuration
CWMP enables an ACS to automatically configure CPEs. When a CPE has set up a session
with an ACS, the ACS automatically delivers configurations to the CPE. Automatic
configuration parameters include:
l URL: address of the ACS
l Username: user name used by the CPE to set up a session with the ACS
l Password: password used by the CPE to set up a session with the ACS
l PeriodicInformEnable: indicates whether Inform messages are sent automatically
l PeriodicInformInterval: interval at which Inform messages are sent
l PeriodicInformTime: time when Inform messages are sent
l ConnectionRequestUsername: CPE user name
l ConnectionRequestPassword: CPE password
File Management
CWMP enables CPEs to:
l Upload files
A CPE can upload the configuration file and log files to the server specified by an ACS
to back up important data.
l Download files
A CPE can use HTTP, HTTPS, or FTP to download web page files, configuration files,
system software packages, patch files, license files, and any other files from a file server
specified by an ACS. After downloading a file, the CPE checks the validity of the file
and processes the file according to the check result. For example, if the downloaded file

is a configuration file, the CPE automatically specifies it as the configuration file for
next startup and sends the download result (succeeded or failed) to the ACS.
NOTE
l Currently, the CPE does not support file download using digital signature.
l To download a file using HTTPS, the CPE must set up a Secure Sockets Layer (SSL) connection to
the ACS.
Status and Performance Monitoring

CWMP enables an ACS to monitor the status and performance parameters of the connected
CPEs. Performance and functions vary with CPEs. Therefore, an ACS must be able to
identify performance of different CPEs and monitor configurations and configuration changes
of each CPE.
CWMP allows network administrators to define monitoring parameters and obtain the CPE
status and statistics using an ACS.
NOTE
Currently, the CPE does not support the data model defined in TR-143 among all technical
specifications that define status and performance monitoring.
Fault Diagnosis
CWMP enables an ACS to diagnose CPE faults using methods such as ping, traceroute,
asynchronous transfer mode (ATM) loopback, and digital subscriber line (DSL) detection.
5.3 Application Scenarios for CWMP

This section describes the applicable scenario of CWMP.
As shown in Figure 5-3, enterprise branches connect to the Internet through the enterprise
gateway router. CWMP is deployed between the enterprise headquarters and branches. The
router functions as a CPE. The enterprise headquarters control and manage the router using an
ACS. After connecting to the router, the ACS manages the system startup file and
configuration file for the router, configures the router, monitors the router status and
performance, and diagnoses router faults.
Figure 5-3 Applicable scenario of CWMP
Internet
Router ACS
Enterprise Enterprise
branches headquarters
CWMP

5.4 Licensing Requirements and Limitations for CWMP

This section provides the points of attention when configuring CWMP.

None
CWMP is a basic feature of a router and is not under license control.
Feature Limitations
NOTE
The AR120 series (except AR129CV, AR129CVW and AR129CGVW-L) do not support CWMP.
5.5 Default Settings for CWMP

The following table describes the default settings for CWMP.
Default settings for CWMP

CWMP function Disabled
Function for the CPE to periodically send Disabled

Inform messages
Interval at which the CPE sends Inform 600 seconds

messages
Maximum number of connection reattempts 3
Close-wait timer of the CPE 30 seconds
5.6 Configuring CWMP

This section describes how to configure CWMP.
Before configuring CWMP, complete the following tasks:
l Ensuring that there is a reachable route between the router and the ACS

To configure CWMP, perform the following operations in sequence. You can choose whether
to perform optional operations based on site requirements.
5.6.1 Enabling CWMP
Context
The CWMP configurations take effect only after the CWMP function is enabled.
Procedure
Step 2 Run cwmp
The CWMP view is displayed.
Step 3 Run cwmp enable
The CWMP function is enabled.
By default, the CWMP function is disabled.
----End
5.6.2 Configuring the CWMP Connection
Context
To allow the ACS to manage the CPE, set up a connection between the ACS and the CPE.
Procedure
Step 2 Run cwmp
Step 3 Run cwmp acs url url
The ACS's URL to which the CPE connects is specified.
To use the HTTPS URL, you must configure SSL authentication.
NOTE
You can also configure a DHCP option to specify the ACS URL. However, if DHCP packets carrying
this option are interrupted, the ACS URL will leak, causing security risk. Use this method only in a
secure network environment.
Step 4 (Optional) Run cwmp permit interface { interface-type interface-number } &<1-5>

Physical interfaces on the CPE to which the ACS can connect are specified.
By default, the ACS can connect to all the physical interfaces on the CPE.
Step 5 (Optional) Run cwmp cpe connect interface interface-type interface-number
The CWMP connection interface is specified.
Generally, a CPE obtains a CWMP connection interface from all the interfaces to which the
ACS have reachable routes. If the obtained interface does not connect the CPE to the ACS,
CWMP connection fails to be set up. Therefore, a CWMP connection interface needs to be
specified manually.
Step 6 (Optional) The CPE can use the following methods to send inform messages:
l Sending inform messages periodically
1. Run cwmp cpe inform interval enable
The CPE is enabled to periodically send inform messages.
By default, the CPE does not periodically send inform messages.
2. Run cwmp cpe inform interval seconds
The interval at which a CPE sends inform messages is set.
By default, a CPE sends an inform message every 30 seconds.
l Sending an inform message at a specified time
1. Run cwmp cpe inform time time
The time when a CPE sends an inform message is set.
By default, no time is specified for the CPE to send an inform message.
NOTE
You can configure either one or both methods.
Step 7 (Optional) Run cwmp cpe inform product-class device-type

The actual product type of the CPE is added to the session initiated by the CPE to the ACS.
By default, the session initiated by the CPE to the ACS contains the product type
AccessRouter.
Step 8 (Optional) Run cwmp cpe connect retry times
The maximum number of attempts the CPE can make to retry a connection is set.
By default, the maximum number of attempts is 3.
Step 9 (Optional) Run cwmp cpe wait timeout seconds
The connection timeout interval is configured for the CPE. If no data is transmitted within the
timeout interval, the connection between the CPE and ACS is torn down.
By default, connection timeout interval is 30 seconds.
Step 10 (Optional) Run cwmp ip-change inform disable
The device is disabled from informing the ACS of an IP address change event.
By default, when the IP address of a device changes, the device does not inform the ACS of
this event.

NOTE
This command takes effect only on IP addresses reachable to the ACS.
----End
5.6.3 Configuring CWMP Authentication

Context
CWMP uses security mechanisms to protect communication between a CPE and an ACS. The
security mechanisms prevent the transactions between the CPE and the ACS from being
tampered and ensure confidentiality of the transactions.
The CWMP supports the following authentication mechanisms:
l CPE and ACS authentication
l SSL authentication
When the ACS URL is in the HTTPS format, the CPE and ACS must authenticate each
other, and the SSL connection is set up only after the CPE and ACS are authenticated. It
ensures the confidentiality of communication between the ACS and the CPE and data
integrity.
When a CPE needs to use an SSL policy to authenticate ACS, configure client SSL
authentication. When an ACS needs to set up an HTTPS connection, configure a server
SSL policy.
Procedure
l Configure CPE and ACS authentication.
a. Run system-view
b. Run cwmp
c. Configure ACS authentication.
i. Run cwmp acs username username
The user name used to connect the CPE to the ACS is configured.
ii. Run cwmp acs password cipher
The password used to connect the CPE to the ACS is configured.
d. Configure CPE authentication.
i. Run cwmp cpe username username
The user name used to connect the ACS to the CPE is configured.
ii. Run cwmp cpe password cipher
The password used to connect the ACS to the CPE is configured.
l Configure SSL authentication.
a. Run system-view
b. Run cwmp


c. Run cwmp ssl-client { client-root-cert rootcert-path1 [ rootcert-path2 ] | ssl-
policy policy-name }
The CPE is configured to validate the certificate from the ACS.
NOTE
l The system time must be correctly set; otherwise, certificate validation may fail. To use a
new certificate, uninstall the existing certificate first.
l Before configuring a CPE to authenticate the ACS using an SSL policy, run the ssl
policy policy-name type client command to configure the SSL policy on the CPE.
l Bind the server SSL.
a. Run system-view

b. Run cwmp

c. Run cwmp ssl-server ssl-policy policy-name
An SSL policy is bound to CWMP.
NOTE
When an ACS needs to set up an HTTPS connection, run the cwmp ssl-server ssl-policy
policy-name command to configure a server SSL policy.
----End
5.6.4 (Optional) Configuring the CWMP Uploading Function
Context
After a connection is set up between the CPE and the ACS, you can configure the CPE to
upload the currently loaded configuration file to the ACS. This function is used to back up
configuration files.
Procedure
Step 2 Run cwmp
Step 3 (Optional) Run cwmp escape-character
A character to be translated is added.
NOTE
l Currently, only 30 characters to be translated are supported. If more than 30 characters to be translated are
configured, an error message is displayed.
l To make character translation take effect, run the cwmp escape-character enable command.

Step 4 (Optional) Run cwmp escape-character enable

The character translation function is enabled.
By default, character translation is disabled.
Step 5 Run cwmp request upload current-configuration
The CPE is configured to upload the currently loaded configuration file to the ACS.
----End

Prerequisites
All the CWMP configurations are complete.
Procedure
l Run the display cwmp configuration command to check CWMP configurations on the
router.
l Run the display cwmp password command to check CWMP password on the router.
l Run the display cwmp status command to check CWMP status on the router.
l Run the display cwmp request upload status command to check the status of
configuration file uploading from the router to the ACS.
----End
5.7 Configuration Examples for CWMP

This chapter provides configuration examples for CWMP.
5.7.1 Example for Configuring CWMP

As shown in Figure 5-4, multiple hosts in Enterprise A access an enterprise gateway router.
The router connects to the Internet.
The enterprise headquarters want to upgrade router software and hardware, download
configuration files to the router automatically, and restart the router remotely during upgrade
or troubleshooting. The CWMP function needs to be configured on the router to provide these
functions.
Figure 5-4 The ACS manages the router by using CWMP

ACS
Router GE1/0/0 10.2.1.1/24
10.1.1.1/24 Internet
Branch Headquarters

To meet the enterprise requirements, configure CWMP:
1. To ensure that the CPE can initiate a connection to the ACS, configure the CWMP
connection on the router.
2. To ensure connection security, configure CWMP authentication on the router.
Procedure
Step 1 Configure the router IP address and route based on Figure 5-4 and ensure that the route is
reachable.
[Router] ospf 1
Step 2 Enable the CWMP function on the router.

[Router] cwmp
[Router-cwmp] cwmp enable
Step 3 Configure the CWMP connection of the router.

# Configure the URL used by the router to connect to the ACS.
[Router-cwmp] cwmp acs url http://10.2.1.1/acs
# Configure the interface on the router to connect to the ACS.

[Router-cwmp] cwmp cpe connect interface gigabitethernet 1/0/0
# Enable the router to send Inform messages.

[Router-cwmp] cwmp cpe inform interval enable
# Set the interval at which the router sends Inform messages to 1000 seconds.
[Router-cwmp] cwmp cpe inform interval 1000
# Set the maximum number of connection attempts to 5.

[Router-cwmp] cwmp cpe connect retry 5
# Set the close-wait timer of the router to 100 seconds.

[Router-cwmp] cwmp cpe wait timeout 100
Step 4 Configure the CWMP authentication of the router.

# Set parameters for authenticating the router.
[Router-cwmp] cwmp acs username newacsname
[Router-cwmp] cwmp acs password cipher
Enter Password(<6-255>):
Confirm password:
# Set parameters for authenticating the ACS.

[Router-cwmp] cwmp cpe username newcpename

[Router-cwmp] cwmp cpe password cipher
Enter Password(<6-255>):
Confirm password:
[Router-cwmp] quit
# You can see the CWMP function status, URL of the ACS, user name and password, Inform
message sending status, interval for sending Inform messages, time when an Inform message
is sent, close-wait timer, and maximum number of connection attempts.
[Router] display cwmp configuration
CWMP is enabled
ACS URL: http://10.2.1.1/acs
ACS username: newacsname
ACS password: %@%@u<GgDA|}*!%lp>R@.[/M"e0_%@%@
Inform enable status: enabled
Inform interval: 1000s
Inform time: -
Wait timeout: 100s
Reconnection times: 5
# You can see the CWMP function status, URL of the ACS, user name and password, method
to obtain the URL of the ACS, status of the connection between the CPE and the ACS, and
time when the last connection is set up.
[Router] display cwmp status
CWMP is enabled
ACS URL: http://10.2.1.1/acs
ACS information is set by: user
ACS username: newacsname
ACS password: %@%@u<GgDA|}*!%lp>R@.[/M"e0_%@%@
Connection status: connected
Time of last successful connection: 2012-09-28 21:10:22+00:00
----End
Configuration Files
#
sysname Router
#
ip address 10.1.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
#
cwmp
cwmp enable
cwmp cpe inform interval enable
cwmp acs url http://10.2.1.1/acs
cwmp acs username newacsname
cwmp acs password cipher %@%@u<GgDA|}*!%lp>R@.[/M"e0_%@%@
cwmp cpe username newcpename
cwmp cpe password cipher %@%@^<d}J,qcv&zbd}H2:,wL"eTh%@%@
cwmp cpe inform interval 1000
cwmp cpe connect retry 5
cwmp cpe wait timeout 100
cwmp cpe connect interface GigabitEthernet1/0/0
#
return

5.8 Troubleshooting CWMP

This topic describes the common CWMP configuration error, including the fault symptoms
and troubleshooting procedure.
5.8.1 Failure to Manage CPE Using CWMP
Symptoms
The fault symptoms are as follows:
l The router cannot set up a connection with the ACS.
l The ACS fails to issue configurations to the router.
Procedure
Step 1 Check that there is a reachable route between the router and ACS.
Run the ping command on the router to ping the ACS.
l If the ping fails, check the route configuration.
l If the router can ping the ACS, go to step 2.
Step 2 Verify the CWMP settings on the router.

Run the display cwmp configuration command to check whether the CWMP function is
enabled and the ACS's URL, user name, and password are correctly set.
<Huawei> display cwmp configuration
CWMP is enabled
ACS URL: http://www.acs.com:80/acs
ACS username: hwcpe
ACS password: %$%$gw1.QU~4M1I@RDF>b/VP,@7.%$%$
Inform enable status: disabled
Inform interval: 600s
Inform time: -
Wait timeout: 30s
Reconnection times: 3
If the CWMP settings are incorrect, modify them based on Table 5-4, and run the undo
cwmp enable and cwmp enable commands to re-enable the CWMP function.
Table 5-4 CWMP settings
Item Method
Enable the CWMP Run the cwmp enable command in the CWMP view.
function.
Configure the URL used Run the cwmp acs url url command in the CWMP view.
by the router to connect to
the ACS.
Configure the user name Run the cwmp acs username username command in the
used by the router to CWMP view.
connect to the ACS.

Item Method
Configure the ACS's Run the cwmp acs password cipher command in the CWMP
password used by the view.
router to connect to the
ACS.
----End
5.9 FAQ About CWMP
5.9.1 How Can an AR Router Correctly Connect to an ACS?

1. Ensure that the AR router can ping the ACS successfully.
2. Ensure that the AR router is configured with the same URL as the ACS.
3. Run the undo cwmp enable command and then the cwmp enable command in the
CWMP view of the AR router to trigger a session connection.
4. If no connection is established, the AR router and ACS may fail to exchange packets.
Capture packets on the ACS to locate the packet exchange failure. After the packet
exchange failure is rectified, perform step 3 again to trigger a session connection.

and Monitoring 6 LLDP Configuration
6 LLDP Configuration
About This Chapter
This chapter describes how to configure The Link Layer Discovery Protocol (LLDP) to obtain
details about the network topology, changes in the topology, and detect incorrect
configurations on the network.
6.1 Overview of LLDP
6.2 Understanding LLDP
6.3 Licensing Requirements and Limitations for LLDP
6.4 Default Settings for LLDP
6.5 Configuring Basic LLDP Functions
When LLDP is configured on devices, the NMS can obtain detailed information such as the
network topology, device interface status, and management address.
6.6 Configuring the LLDP Alarm Function
This section describes how to configure the LLDP alarm function on a network device, so that
the device can send alarms to the NMS when information about neighbors changes.
6.7 Maintaining LLDP
6.8 Configuration Examples for LLDP
6.9 FAQ About LLDP
6.1 Overview of LLDP
Definition
The Link Layer Discovery Protocol (LLDP) is a standard Layer 2 topology discovery protocol
defined in IEEE 802.1ab. LLDP allows a device to send local management information such
as management IP address, device ID, and port ID to neighbors. Neighbors save the received
information in their management information bases (MIBs). The network management system
(NMS) can search required information in MIBs to determine link status.

Purpose
An NMS must be capable of managing network devices of different types with complex
configurations. Most NMSs can detect Layer 3 network topologies, but cannot detect detailed
Layer 2 topologies or detection conflicts in configurations. A vendor-neutral protocol is
required to exchange Layer 2 information between network devices.
LLDP provides a standard link-layer discovery method. Layer 2 information obtained through
LLDP allows the NMS to detect the topology of neighboring devices, and display paths
between clients, switches, routers, application servers, and network servers. The NMS can
also detection conflicts in configurations between network devices and identify causes of
network connection failures. With an NMS, enterprise users can monitor the link status on
devices running LLDP and quickly locate network faults.
6.2 Understanding LLDP
6.2.1 LLDP Implementation

LLDP collects and sends local device information to remote devices. The local device saves
information received from remote devices to MIBs. Figure 6-1 shows how LLDP is
implemented.
Figure 6-1 LLDP block diagram
Organizationally Organizationally
defined local device defined remote device PTOPO
LLDP MIB extension LLDP MIB extension MIB
(Optional) (Optional) (Optional)
Entity MIB
LLDP local system LLDP remote system (Optional)
MIB MIB
Interface
MIB
(Optional)
Other MIBs
LLDP (Optional)
LLDP agent frames
( )
LLDP
Local device Remote device
information information
LLDP is implemented as follows:

1. The LLDP module uses an LLDP agent to interact with the Physical Topology MIB,
Entity MIB, Interfaces MIB, and other MIBs to update the LLDP local system MIB and
LLDP local organizationally defined extended MIB.

2. The LLDP agent encapsulates local device information into LLDP frames and sends the
LLDP frames to remote devices.
3. After receiving LLDP frames from remote devices, the LLDP agent updates the LLDP
remote system MIB and LLDP remote organizationally defined extended MIB.
4. By exchanging LLDP frames with remote devices, the local device can obtain
information about remote devices, including remote interfaces connected to the local
device and MAC addresses of remote devices.
The LLDP local system MIB stores local device information, including the device ID, port
ID, system name, system description, port description, and management address.
The LLDP remote system MIB stores neighbor information, including the device ID, port ID,
system name, system description, port description, and management address of each neighbor.
An LLDP agent performs the following tasks:

l Maintains the LLDP local system MIB and LLDP remote system MIB.
l Obtains and sends LLDP local system MIB information to remote devices when the local
device status changes. An LLDP agent also obtains and sends LLDP local system MIB
information to remote devices at periodic intervals if the local device status does not
change.
l Identifies and processes received LLDP frames.
l Sends LLDP traps to the NMS when information in the LLDP local system MIB or
LLDP remote system MIB changes.
6.2.2 LLDP Frame Format

An LLDP frame is an Ethernet frame encapsulated with an LLDP data unit (LLDPDU).
Figure 6-2 shows the LLDP frame format.
Figure 6-2 LLDP frame format

DA Type
SA LLDPDU FCS
0x0180-C200-000E 0x88CC
6 bytes 6 bytes 2 bytes 46-1500 bytes 4 bytes
An LLDP frame contains the following fields:
l DA: destination MAC address, a fixed multicast MAC address 0x0180-C200-000E

l SA: source MAC address, the MAC address of the sender
l Type: packet type, 0x88CC in LLDP frames
l LLDPDU: LLDP data unit, body of an LLDP frame
l FCS: frame check sequence.
LLDPDU
An LLDPDU contains local device information and is encapsulated in an LLDP frame. Each
LLDPDU consists of several information elements known as Type, Length, and Value (TLV)
fields. The local device encapsulates its local information in TLVs, constructs an LLDPDU
with several TLVs, and encapsulates the LLDPDU in the data field of an LLDP frame. Figure
6-3 shows the LLDPDU structure.

Figure 6-3 LLDPDU structure
Chassis ID TLV Port ID TLV Time to Live TLV Optional TLV ... Optional TLV End of LLDPDU TLV
As shown in Figure 6-3, an LLDPDU has four mandatory TLVs: Chassis ID TLV, Port ID
TLV, Time to Live TLV, and End of LLDPDU TLV. Other TLVs are optional, and a device
can determine whether to encapsulate them in an LLDPDU.
When LLDP is disabled on an interface or an interface is shut down, the interface sends a
shutdown LLDPDU to the neighbors. In the shutdown LLDPDU, the value of the Time to
Live TLV is 0. A shutdown LLDPDU contains no optional TLVs.
TLV Structure
An LLDPDU is formed by TLVs, and each TLV is an information element.
Figure 6-4 shows the structure of a TLV.
Figure 6-4 TLV structure
TLV Type TLV Length TLV Value
7 bits 9 bits 0-511 bytes

TLV header
A TLV contains the following fields:
l TLV Type (7 bits): type of a TLV. Each TLV type has a unique value. For example, the
value of End of LLDPDU TLV is 0, and the value of Chassis ID TLV is 1.
l TLV Length (9 bits): size of a TLV.
l TLV Value (0-511 bytes): The first bit indicates the sub-type of a TLV, and the other bits
are the TLV content.
TLV Type
LLDPDUs can encapsulate basic TLVs, TLVs defined by the IEEE 802.1 working groups,
TLVs defined by IEEE 802.3 working groups, and Media Endpoint Discovery (MED) TLVs.
Basic TLVs are used for basic device management. The TLVs defined by the IEEE 802.1 and
IEEE 802.3 working groups, and MED TLVs defined by other organizations are used for
enhanced device management functions. A device determines whether to encapsulate
organizationally specific TLVs.
l Basic TLVs
Four basic TLVs are mandatory in LLDP implementation and must be encapsulated in an
LLDPDU.

Table 6-1 Basic TLVs

TLV Description Mandatory
Chassis ID TLV Bridge MAC address of the device Yes

sending an LLDPDU.
Port ID TLV Port from which an LLDPDU is sent. Yes

l If an LLDPDU does not contain
any MED TLVs, the Port ID TLV
identifies the port name.
l If an LLDPDU contains a MED
TLV, the Port ID TLV identifies
the port MAC address. If the port
has no MAC address, the Port ID
TLV identifies the bridge MAC
address.
Time To Live TLV Time to live (TTL) of the local Yes

device information stored on the
neighbor device.
End of LLDPDU TLV End of an LLDPDU. Yes
Port Description TLV Character string that describes the No

port sending an LLDPDU.
System Name TLV System name. No
System Description Character string that describes the No

TLV system.
System Capabilities Main functions of the system and the No

TLV functions that have been enabled.
Management Address Address used by the NMS to identify No

TLV and manage the local device.
Management IP addresses uniquely
identify network devices, facilitating
layout of the network topology and
network management.
l TLVs defined by the IEEE 802.1 working group
Table 6-2 TLVs defined by the IEEE 802.1 working group

TLV Description
Port VLAN ID TLV VLAN ID of a port.
Port And Protocol VLAN ID Protocol VLAN ID of a port.

TLV
VLAN Name TLV Name of the VLAN on a port.

TLV Description
Protocol Identity TLV Protocol types that a port supports.
l TLVs defined by the IEEE 802.3 working group
Table 6-3 TLVs defined by the IEEE 802.3 working group
TLV Description
Link Aggregation TLV Specifies whether a port supports link aggregation

and has link aggregation enabled.
MAC/PHY Configuration/ Rate and duplex mode of a port, whether the port
Status TLV supports auto-negotiation, and whether auto-
negotiation is enabled on the port.
Maximum Frame Size TLV Maximum frame length that a port supports. The
value is the maximum transmission unit (MTU) of
the port.
Power Via MDI TLV Power capabilities of a port, for example, whether a
port supports PoE and whether a port supplies or
demands power.
l MED TLVs
MED TLVs are related to voice over IP (VoIP) applications and provide functions such
as basic configuration, network policy configuration, address management, and directory
management. These TLVs meet the requirements of voice device manufacturers for cost
efficiency, easy deployment, and easy management. Use of these TLVs allows the
deployment of voice devices on an Ethernet network, which is convenient for
manufacturers, sellers, and users of voice devices.
Table 6-4 LLDP-MED TLVs
TLV Description
LLDP-MED Capabilities TLV Type of a device and types of LLDP-MED TLVs that
can be encapsulated in an LLDPDU.
Inventory TLV Manufacturer of the device.
Location Identification TLV Location of the local device.
Network Policy TLV VLAN ID, Layer 2 priority, and DSCP of a voice
VLAN.
Extended Power-via-MDI Power capability of the system.

TLV
Hardware Revision TLV Hardware version of a media endpoint (ME). This

TLV can only be queried on the local device and
cannot be sent to neighbor devices.

TLV Description
Firmware Revision TLV Firmware version of an ME device. This TLV can

only be queried on the local device and cannot be
sent to neighbor devices.
Software Revision TLV Software version of an ME device. This TLV can

only be queried on the local device and cannot be
sent to neighbor devices.
Serial Number TLV Serial number of an ME device. This TLV can only
be queried on the local device and cannot be sent to
neighbor devices.
Model Name TLV Model name of an ME device. This TLV can only be
queried on the local device and cannot be sent to
neighbor devices.
Asset ID TLV Asset identifier of an ME device. This TLV can only

be queried on the local device and cannot be sent to
neighbor devices.
6.2.3 Transmission and Reception Mechanisms

LLDP frame transmission
After LLDP is enabled on a device, the device periodically sends LLDP frames to neighbors.
When the local configuration changes, the device sends LLDP frames to notify neighbors of
the changes. To reduce the number of LLDP frames sent when the local information changes
frequently, the device waits for a period before sending the next LLDP frame.
LLDP frame reception
An LLDP-capable device checks the validity of received LLDP frames and the TLVs in those
frames. When determining that an LLDP frame and its TLVs are valid, the local device saves
neighbor information and sets the aging time of neighbor information on the local device to
the TTL value carried in the received LLDPDU. If the TTL value carried in the received
LLDPDU is 0, the neighbor information ages out immediately.
6.2.4 LLDP Networking

LLDP has the following networking modes:
l Single-neighbor networking
In this networking mode, interfaces between two switches or interfaces between a switch
and a media endpoint (ME) are directly connected, and each interface has only one
neighbor. As shown in Figure 6-5, RouterA is directly connected to RouterB and ME,
and each interface on the switches has only one neighbor.

Figure 6-5 Single-neighbor networking
NMS
Network
SNMP
SNMP
RouterA
U
PD
D
LL
RouterB ME
LLDP interface SNMP packet
NMS: Network Management System LLDPDU packet
l Link aggregation networking

In this networking mode, interfaces between two switches are directly connected and
bundled into a link aggregation group, and each interface in a link aggregation group has
only one neighbor. As shown in Figure 6-6, the interfaces between RouterA and
RouterB are bundled into a link aggregation group, and each interface has only one
neighbor.
Figure 6-6 Link aggregation networking

SNMP NMS
Network
SNMP
LLDPDU
Eth-Trunk
Enterprise User RouterA RouterB Enterprise User


6.3 Licensing Requirements and Limitations for LLDP

None
Licensing requirements
LLDP is a basic feature of a router and is not under license control.
Feature Limitations
None
6.4 Default Settings for LLDP

Table 6-5 lists the default settings for the LLDP configuration parameters.
Table 6-5 Default settings for LLDP
LLDP Disabled globally
Interval for sending LLDP packets 30 seconds
Delay in sending LLDP packets 2 seconds
Hold time multiplier of device information 4

on neighbors
Delay in initializing interfaces 2 seconds
Delay in sending a notification after 5 seconds

neighbor information changes
Type of the type-length-values (TLVs) that All types of TLVs except the Location
an interface can send Identification TLV
Standard with which the 802.3 Power via 802.1 ab

MDI TLV sent by the interface complies
6.5 Configuring Basic LLDP Functions

When LLDP is configured on devices, the NMS can obtain detailed information such as the
network topology, device interface status, and management address.

Before configuring LLDP, ensure that a reachable route exists between the local device and
NMS, and configure the Simple Network Management Protocol (SNMP).
6.5.1 Enabling LLDP

Context
LLDP enables a device to send LLDP packets with local system information to neighbors and
parse LLDP packets received from neighbors. The NMS obtains Layer 2 connection status
from the device to analyze the network topology.
Procedure
Step 2 Run lldp enable
LLDP is enabled globally.
By default, LLDP is disabled globally.
----End
6.5.2 (Optional) Disabling LLDP on an Interface
Context
LLDP can be enabled in the system view and the interface view.
l When LLDP is enabled in the system view, LLDP is enabled on all interfaces.
l When LLDP is disabled in the system view, LLDP is disabled on all interfaces.
l An interface can send and receive LLDP packets only after LLDP is enabled in both the
system view and the interface view.
l After LLDP is disabled globally, the commands for enabling and disabling LLDP on an
interface do not take effect.
l If LLDP needs to be disabled on some interfaces, first enable LLDP globally, and run the
undo lldp enable command on these interfaces. To re-enable LLDP on these interfaces,
run the lldp enable command in the views of these interfaces.
NOTE
l Only physical interfaces support LLDP. Logical interfaces such as the VLANIF and Eth-Trunk
interfaces do not support LLDP.
l On an Eth-Trunk, LLDP can only be enabled on member interfaces. LLDP status of a member
interface does not affect that of another.
Procedure


Step 3 Run undo lldp enable
LLDP is disabled on the interface.
----End
6.5.3 (Optional) Configuring an LLDP Management IP Address
Context
The management address of a device is carried in the Management Address TLV field of the
LLDP packet. The NMS uses management addresses to identify and manage devices.
If no management address is configured or an invalid management address is configured, the
system sets an IP address in the address list as the management address. The system selects
the IP address in the following sequence: loopback interface address, management port
address, and VLANIF interface address. Among the IP addresses of the same type, the system
selects the smallest one. If the system fails to find a management IP address, the bridge MAC
address is used as the management address.
Procedure
Step 2 Run lldp management-address ip-address
The LLDP management address is configured.
The value of ip-address must be a valid unicast IP address existing on the device.
----End
6.5.4 (Optional) Configuring LLDP Time Parameters
Context
Interval for sending LLDP packets
When the LLDP status of a device remains unchanged, the device sends LLDP packets to its
neighbors at certain intervals.
Consider the value of delay when adjusting the value of interval because it is restricted by
delay.
l The value of interval must be in the range of 5 to 32768.
l The value of interval must be equal to or greater than four times the value of delay.
Therefore, if you want to set interval to be less than four times the value of delay, first
reduce the delay value to be equal to or less than one-fourth of the new interval value,
and then reduce the interval value.
Delay in sending LLDP packets

If the device status changes frequently, a delay is required before the device can send an
LLDP packet to its neighbors.
Consider the value of interval when adjusting the value of delay because it is restricted by
interval.
l The value of delay ranges from 1 to 8192. Decreasing the value of delay is not restricted
by the value of interval.
l The value of delay must be less than or equal to one-fourth of interval. Therefore, if you
want to set delay to be greater than one-fourth the value of interval, first increase the
interval value to four times the new delay value, and then increase the delay value.
Hold time multiplier of device information on neighbors
The hold time multiplier is used to calculate the Time to Live (TTL), which determines how
long device information can be saved on the neighboring devices. You can specify the hold
time of device information on the neighboring devices. After receiving an LLDP packet, a
neighbor updates the aging time of the device information from the sender based on the TTL.
The storage time calculation formula is: TTL = Min (65535, (interval x hold)).
l TTL is the hold time of device information. It is the smaller value between 65535 and
(interval x hold).
l interval indicates the interval at which the device sends LLDP packets to neighbors.
l hold indicates the hold time multiplier of device information on neighbors. The value
ranges from 2 to 10.
Procedure
Step 2 Run lldp message-transmission interval interval
The interval for sending LLDP packets is set.
The default interval for sending LLDP packets is 30 seconds.
Step 3 Run lldp message-transmission delay delay
The delay in sending LLDP packets is set.
The default delay in sending LLDP packets is 2 seconds.
Step 4 Run lldp message-transmission hold-multiplier hold
The hold time multiplier of device information stored on neighbors is set.
The default hold time multiplier is 4.
----End
6.5.5 (Optional) Configuring the Interface Initialization Delay

Context
Interface initialization delay refers to the delay before LLDP is re-enabled on an interface.
The delay suppresses the topology flapping caused by frequent LLDP status changes.
Procedure
Step 2 Run lldp restart-delay delay
The interface initialization delay is set.
The default delay is 2 seconds.
----End
6.5.6 (Optional) Configuring the Type of TLVs that an Interface

Can Send
Context
LLDPDUs can encapsulate basic TLVs, TLVs defined by the IEEE 802.1 working groups,
TLVs defined by IEEE 802.3, and Media Endpoint Discovery (MED) TLVs.
l When the supported TLVs are basic TLVs, TLVs in the IEEE 802.1 format, and TLVs in
the IEEE 802.3 format, the lldp tlv-enable command with the all parameter advertises
all TLVs. When the supported TLVs are MED TLVs, the lldp tlv-enable command with
the all parameter advertises all TLVs except Location Identification TLV.
If the all parameter is not specified, only one type of TLV can be sent. To send multiple
types of TLVs, run this command multiple times.
l You can specify other types of MED TLVs only after specifying the MED Capabilities
TLV.
To disable the MED Capabilities TLV, first disable the other types of MED TLVs.
To disable the MAC/PHY Configuration/Status TLVs, first disable the MED Capabilities
TLV.
l The 802.3 MAC/PHY Configuration/Status TLVs are automatically advertised after the
MED Capabilities TLV is advertised.
l If you disable the MED TLVs using the command with the all parameter, the 802.3
MAC/PHY Configuration/Status TLVs are not disabled automatically.
Procedure

Step 3 Run the following commands to set the type of TLVs to be advertised on the interface:
l To configure the interface to advertise basic TLVs, run the lldp tlv-enable basic-tlv { all
| management-address | port-description | system-capability | system-description |
system-name } command.
l To configure the interface to advertise TLVs defined by the IEEE 802.1, run the lldp tlv-
enable dot1-tlv { all | port-vlan-id | protocol-vlan-id [ vlan-id ] | vlan-name [ vlan-id ]
| protocol-identity } command.
l To configure the interface to advertise TLVs defined by the IEEE 802.3, run the lldp tlv-
enable dot3-tlv { all | link-aggregation | mac-physic | max-frame-size | power }
command.
l To configure the interface to advertise MED TLVs, run the lldp tlv-enable med-tlv { all
| capability | inventory | location-id { civic-address device-type country-code { ca-type
ca-value } &<1-10> | elin-address Tel-Number } | network-policy | power-over-
ethernet } command.
By default, an interface advertises all types of TLVs except the Location Identification TLV.
Step 4 Run lldp dot3-tlv power { 802.1ab | 802.3at }
The standard with which the 802.3 Power via MDI TLV sent by the interface complies is set.
By default, the 802.3 Power via MDI TLV conforms to 802.1 ab.
NOTE
Before selecting a format for the 802.3 Power via MDI TLV, you must know which TLV format the
neighbors support. The TLV format on the local device must be also supported by the neighbors.
----End
6.5.7 (Optional) Configuring LLDP Packet Authentication on an

Interface
Context
To ensure security of LLDP interfaces, configure LLDP packet authentication on these
interfaces. The interfaces can be connected only when the password in LLDP packets sent
from the peer end is the same as that configured on these interfaces.
Procedure
Step 2 Run lldp enable
LLDP is enabled globally.
By default, LLDP is disabled globally.
Step 4 Run lldp tlv-enable private-tlv authentication

LLDP packet authentication is enabled.

By default, LLDP packet authentication is disabled.
----End
Procedure
l Run the display lldp local [ interface interface-type interface-number ] command to
view LLDP local information on a specified interface or all interfaces.
l Run the display lldp neighbor [ interface interface-type interface-number ] command
to view neighbor information in the system or on an interface.
l Run the display lldp neighbor brief command to view brief information about
neighbors.
l Run the display lldp tlv-config [ interface interface-type interface-number ] command
to view TLV types supported by the entire system or an interface.
----End
6.6 Configuring the LLDP Alarm Function

This section describes how to configure the LLDP alarm function on a network device, so that
the device can send alarms to the NMS when information about neighbors changes.
Before configuring the LLDP alarm function, configure reachable routes between devices and
the NMS, and set SNMP parameters.
6.6.1 Setting the Delay in Sending Traps About Neighbor

Information Changes
Context
When neighbor information changes frequently, a delay in sending traps about neighbor
information changes prevents the device from sending traps to the NMS too frequently, thus
suppressing topology flapping.
The configured delay applies only to the traps of changes in the number of added neighbors,
deleted neighbors, neighbors that are aged out, and neighbors whose information is deleted.
Procedure
Step 2 Run lldp trap-interval interval
The delay in sending neighbor change traps to the NMS is set.

The default delay in sending neighbor change traps to the NMS is 5 seconds.
----End
6.6.2 Enabling the LLDP Trap Function
Context
The LLDP trap function allows a device to send traps to the NMS in one of the following
cases:
l The LLDP function is enabled or disabled globally.
l The local management address changes.
l A neighbor is added, deleted, aged out, or packets from the neighbor are discarded.
NOTE
l The LLDP trap function applies to all interfaces. The LLDP trap function takes effect regardless
whether LLDP is enabled globally.
l If the network topology is unstable, disable the LLDP trap function to prevent frequent trap sending.
l To set the interval for sending neighbor change traps to the NMS, run the lldp trap-interval
commands. If neighbor information changes frequently, extend the interval to reduce the number of
traps, thus suppressing network topology flapping.
Procedure
Step 2 Run snmp-agent trap enable feature-name lldptrap [ trap-name { hwlldpdisabled |

hwlldpenabled | hwlldplocmanipaddrchange | lldpremtableschange } ]
The LLDP trap function is enabled.
By default, the LLDP trap function is enabled.
----End
Procedure
l Run the display snmp-agent trap feature-name lldptrap all command to view status
of all traps on the LLDP module.
l Run the display lldp local [ interface interface-type interface-number ] command to
view LLDP status in the system or on an interface.
----End
6.7 Maintaining LLDP

6.7.1 Clearing LLDP Statistics
Context
Statistics cannot be restored after being cleared. Therefore, exercise caution when you run the
following commands.
Procedure
l Run the reset lldp statistics [ interface interface-type interface-number ] command in
the user view to clear LLDP packet statistics in the system or on an interface.
l Run the lldp clear neighbor [ interface interface-type interface-number ] command in
the user view to clear neighbor information in the system or on an interface.
----End
6.7.2 Monitoring LLDP Status
Context
In routine maintenance, you can run the following commands in any view to check the LLDP
status.
Procedure
l Run the display lldp statistics [ interface interface-type interface-number ] command to
view statistics about sent and received LLDP packets in the system or on an interface.
----End
6.8 Configuration Examples for LLDP
6.8.1 Example for Configuring LLDP on a Device that Has a

Single Neighbor
As shown in Figure 6-7, RouterA and RouterB are directly connected; RouterA and ME are
directly connected. The NMS has reachable routes to RouterA and RouterB, and SNMP
configuration has been complete.
A network administrator wants to use the NMS to obtain communication information between
RouterA and ME, and between RouterA and RouterB, as well as the traps about function
changes on RouterA and RouterB. According to the preceding information, network

administrator can know the detailed network topology and whether configuration conflicts
exist on the network.
Figure 6-7 Single-neighbor network
NMS
Network
SNMP
SNMP
Ethernet2/0/0 RouterA IP:10.10.10.1
Ethernet2/0/1
U
PD
Ethernet2/0/0
D
LL
RouterB
IP:10.10.10.2 ME
The LLDP function can meet the network administrator's requirement. The configuration
roadmap is as follows:
1. Enable global LLDP on RouterA and RouterB.
2. Configure management IP addresses for RouterA and RouterB.
3. Enable the LLDP trap function on RouterA and RouterB so that trap messages can be
sent to the NMS in a timely manner.
Procedure
Step 1 Enable global LLDP on RouterA and RouterB.
# Configure RouterA.
[Huawei] sysname RouterA
[RouterA] lldp enable
# Configure RouterB.
[Huawei] sysname RouterB
[RouterB] lldp enable
Step 2 Configure management IP addresses for RouterA and RouterB.
[RouterA] lldp management-address 10.10.10.1
[RouterB] lldp management-address 10.10.10.2

Step 3 Enable the LLDP trap function on RouterA and RouterB.

[RouterA] snmp-agent trap enable feature-name lldptrap
[RouterB] snmp-agent trap enable feature-name lldptrap
Step 4 Verify the configurations.

l Check RouterA.
# Check the RouterA configuration.
<RouterA> display lldp local
System information
Chassis type :macAddress
Chassis ID :00e0-11fc-1710
System name :RouterA
System description :Huawei AR2240 Huawei Versatile Routing Platform Software
VRP (R) software,Version 5.130 (AR2240 V200R009)
Copyright (C) 2011-2013 Huawei Technologies Co., Ltd
System capabilities supported :bridge
System capabilities enabled :bridge
LLDP Up time :2012/05/8 11:40:49
MED system information

Device class :Network Connectivity
(MED inventory information of master board)
HardwareRev :AR01SRU1A VER.A
FirmwareRev :NA
SoftwareRev :V200R009
SerialNum :NA
Manufacturer name :HUAWEI TECH CO., LTD
Model name :NA
Asset tracking identifier :NA
System configuration
LLDP Status :enabled (default is disabled)
LLDP Message Tx Interval :30 (default is 30s)
LLDP Message Tx Hold Multiplier :4 (default is 4)
LLDP Refresh Delay :2 (default is 2s)
LLDP Tx Delay :2 (default is 2s)
LLDP Notification Interval :5 (default is 5s)
LLDP Notification Enable :enabled (default is enabled)
Management Address :IP: 10.10.10.1 MAC: 00e0-11fc-1710
Remote Table Statistics:

Remote Table Last Change Time :0 days, 5 hours, 57 minutes, 32 seconds
Remote Neighbors Added :15
Remote Neighbors Deleted :13
Remote Neighbors Dropped :0
Remote Neighbors Aged :0
Total Neighbors :2
Port information:
Interface Ethernet2/0/0:
LLDP Enable Status :enabled (default is disabled)
Total Neighbors :1
Port ID subtype :interfaceName

Port ID :Ethernet2/0/0
Port description :HUAWEI, AR Series,Ethernet2/0/0 Interface
---- More ----
# Check neighbor information for RouterA.

<RouterA> display lldp neighbor interface ethernet 2/0/0
Ethernet2/0/0 has 1 neighbors:

Neighbor index : 1
Port ID type :interfaceName
System name :RouterB
Copyright (C) 2011-2013 Huawei
Technologies Co., Ltd
Management address type :ipV4
Management address : 10.10.10.2
Expired time :104s
---- More ----
l Check RouterB.
Refer to the steps for checking RouterA.
----End
Configuration Files
l RouterA configuration file
#
sysname RouterA
#
lldp enable
#
lldp management-address 10.10.10.1
#
return
l RouterB configuration file

#
sysname RouterB
#
lldp enable
#
#
return
6.8.2 Example for Configuring LLDP on a Network with Link

Aggregation Configured
As shown in Figure 6-8, RouterA and RouterB are connected through an Eth-Trunk. Routes
between the NMS and routers are reachable, and SNMP is configured.
A network administrator wants to obtain Layer 2 information about RouterA and RouterB to
know the detailed network topology and configuration conflicts.

Figure 6-8 Network with link aggregation configured

SNMP NMS
Network
SNMP
LLDPDU
Eth-Trunk
Enterprise User RouterA RouterB Enterprise User

IP:10.10.10.1 IP:10.10.10.2

The LLDP function can meet the network administrator's requirement. The configuration
roadmap is as follows:
1. Add physical interfaces on RouterA and RouterB to the Eth-Trunk.
2. Enable global LLDP on RouterA and RouterB.
3. Configure management IP addresses for RouterA and RouterB.
Procedure
Step 1 Add physical interfaces on RouterA and RouterB to the Eth-Trunk.
[RouterA] vlan batch 100
[RouterA] interface eth-trunk 1
[RouterA-Eth-Trunk1] trunkport ethernet 2/0/0 to 2/0/2
[RouterA-Eth-Trunk1] port link-type trunk
[RouterA-Eth-Trunk1] port trunk allow-pass vlan 100
[RouterA-Eth-Trunk1] quit
[RouterB] vlan batch 100
[RouterB] interface eth-trunk 1
[RouterB-Eth-Trunk1] trunkport ethernet 2/0/0 to 2/0/2
[RouterB-Eth-Trunk1] port link-type trunk
[RouterB-Eth-Trunk1] port trunk allow-pass vlan 100
[RouterB-Eth-Trunk1] quit
Step 2 Enable global LLDP on RouterA and RouterB.

[RouterA] lldp enable

[RouterB] lldp enable
Step 3 Configure management IP addresses for RouterA and RouterB.
# Configure RouterA. Assume that the Loopback address of RouterA is 10.10.10.1/32.

[RouterA] lldp management-address 10.10.10.1
# Configure RouterB. Assume that the Loopback address of RouterB is 10.10.10.1/32.

[RouterB] lldp management-address 10.10.10.2
Step 4 Verify the configurations.

l Check the RouterA configuration.
# Check whether the physical interfaces have been added to Eth-Trunk1.
[RouterA] display eth-trunk 1
Eth-Trunk1's state information is:
WorkingMode: NORMAL Hash arithmetic: According to SA-XOR-DA
Least Active-linknumber: 1 Max Bandwidth-affected-linknumber: 8
Operate status: up Number Of Up Port In Trunk: 3
------------------------------------------------------------------------------
--
PortName Status Weight
Ethernet2/0/0 Up 1
Ethernet2/0/1 Up 1
Ethernet2/0/2 Up 1
# View the LLDP configurations.

<RouterA> display lldp local
System information
System name :RouterA
Copyright (C) 2011-2013 Huawei Technologies Co., Ltd
LLDP Up time :2012/5/8 11:40:49
MED system information

Device class :Network Connectivity
(MED inventory information of master board)
HardwareRev :AR01SRU1A VER.A
FirmwareRev :NA
SoftwareRev :V200R009
SerialNum :NA
Manufacturer name :HUAWEI TECH CO., LTD
Model name :NA
Asset tracking identifier :NA
System configuration
LLDP Status :enabled (default is disabled)
LLDP Message Tx Interval :30 (default is 30s)
LLDP Message Tx Hold Multiplier :4 (default is 4)
LLDP Refresh Delay :2 (default is 2s)
LLDP Tx Delay :2 (default is 2s)
LLDP Notification Interval :5 (default is 5s)
LLDP Notification Enable :enabled (default is enabled)
Management Address :IP: 10.10.10.1 MAC: 00e0-11fc-1710
Remote Table Statistics:

Remote Table Last Change Time :0 days, 5 hours, 57 minutes, 32 seconds
Remote Neighbors Added :15
Remote Neighbors Deleted :13
Remote Neighbors Dropped :0
Remote Neighbors Aged :0
Total Neighbors :2

Port information:
Interface Ethernet2/0/0:
LLDP Enable Status :enabled (default is disabled)
Total Neighbors :1
Port ID subtype :interfaceName

---- More ----
# Check neighbor information for RouterA.

[RouterA] display lldp neighbor brief
Local Intf Neighbor Dev Neighbor Intf Exptime
Eth2/0/0 RouterB Eth2/0/0 115
l Check the RouterB configuration.

Refer to the steps for checking RouterA.
----End
Configuration Files
#
sysname RouterA
#
vlan batch 100
#
lldp enable
#
interface Eth-Trunk1
port link-type trunk
port trunk allow-pass vlan 100
#
interface Ethernet2/0/0
eth-trunk 1
#
eth-trunk 1
#
eth-trunk 1
#
#
return

#
sysname RouterB
#
vlan batch 100
#
lldp enable
#
interface Eth-Trunk1
port link-type trunk
port trunk allow-pass vlan 100
#
eth-trunk 1
#
eth-trunk 1

#
eth-trunk 1
#
#
return
6.9 FAQ About LLDP
6.9.1 What Are LLDP Functions?

Link Layer Discovery Protocol (LLDP) is specified in standards document IEEE 802.1AB.
LLDP identifies the interfaces on devices and the interfaces connected to other devices. It
shows the path between a client, a switch, a router, an application server, and a network
server.
6.9.2 How Do I View LLDP Neighbors?

Run the display lldp neighbor [ interface interface-type interface-number ] command to
view information about neighboring devices of all interfaces or a specified interface.
Run the display lldp neighbor brief command to view brief information about neighbors of
the device.
6.9.3 What Interfaces Support LLDP?

In V200R002C00 and earlier versions, only Layer 2 Ethernet interfaces on AR series routers
support LLDP. In V200R002C01 and later versions, Layer 2 and Layer 3 Ethernet interfaces
on AR series routers support LLDP.

and Monitoring 7 NQA Configuration
7 NQA Configuration
About This Chapter
This chapter describes how to configure the Network Quality Analysis (NQA) to monitor the
network operating status and collect network operation indexes in real time.
7.1 Overview of NQA
7.2 Understanding NQA
7.3 Test Mechanisms
7.4 NQA Association Mechanism
7.5 Application Scenarios for NQA
7.6 Summary of NQA Configuration Tasks
7.7 Licensing Requirements and Limitations for NQA
This section provides the points of attention when configuring NQA.
7.8 Configuring the Response to UDP Tests Initiated by a Third-party Device or NMS
Software
When a device connects to third-party device or NMS software and needs to respond to the
UDP-Echo or UDP-Jitter packets sent from the third-party device or NMS software, configure
this function.
7.9 Configuring an NQA Test Instance
7.10 Configuring the NQA Transmission Delay Threshold and Alarm Threshold
7.11 Configuring the Trap Function
7.12 Configuring the NQA Client to Send Test Results to an FTP Server
7.13 Scheduling an NQA Test Instance
7.14 Clearing NQA Test Statistics
7.15 Configuration Examples for NQA
7.16 Troubleshooting NQA
7.17 FAQ About NQA

7.1 Overview of NQA
Definition
Network Quality Analysis (NQA) measures network performance and collects statistics on
delay, jitter, and packet loss ratio. NQA monitors network quality of service (QoS) in real
time and locates and diagnoses network faults.
Purpose
To visualize the quality of network services and allow users to check whether the quality of
network services meets requirements, the following measures must be taken:
l Collect data on network devices to describe the quality of network services.
l Deploy probe devices to monitor the quality of network services.
To carry out the preceding measures, devices must provide statistical parameters such as
delay, jitter, and packet loss ratio. This requires dedicated probe devices, which increases
operation costs.
NQA can precisely test the network operating status and output statistics without using
dedicated probe devices, effectively reducing costs.
NQA measures the performance of different protocols running on the network. It allows you
to collect network operation indexes on the following in real time:
l Total HTTP connection delay
l TCP connection delay
l DNS resolution delay
l File transmission speed
l FTP connection delay
l DNS resolution error rate
7.2 Understanding NQA

Constructing a test instance
NQA requires two test ends: an NQA client and an NQA server (also called the source and
destination, respectively). The NQA client initiates NQA tests, which you can configure
through the command line or the network management system (NMS). NQA then places the
test instances into test queues for scheduling.
Starting a test instance
The user can choose to start an NQA test instance immediately, at a specified time, or after a
delay. The test instance waits the specified amount of time and then generates a test packet in
accordance with the test type. If the size of the test packet is smaller than the minimum size
required by the protocol, the test packet is padded to the minimum size.
Processing a test instance

In an NQA test instance, the operating status of the protocol is determined based on the
response packets. The client adds a timestamp to the test packet according to the local system
time before sending the packet to the server. After receiving the test packet, the server sends a
response packet to the client. The client receives the response packet and again adds a
timestamp according to the current local system time. The client then calculates the round-trip
time (RTT) of the test packet based on the two timestamps.
NOTE
In a jitter test instance, both the client and server add a timestamp to the sent and received packets
according to the local system time. This allows the client to calculate the jitter.
You can view the test results to learn about the operating status and service quality of the
network.
7.3 Test Mechanisms
7.3.1 DHCP Test

An NQA DHCP test is performed using User Datagram Protocol (UDP) packets. The NQA
client simulates a DHCP client to initiate a DHCP request on a specified interface. According
to whether the interface obtains an IP address, you can determine whether DHCP servers are
available on the network segment where the interface resides and measure the time the
interface takes to obtain an IP address.
Figure 7-1 shows the process of a DHCP test:
1. The client (RouterA) broadcasts a DHCP Discovery packet through the interface that
needs to obtain an IP address to query a DHCP server. The Discovery packet is broadcast
to the network segment where the interface resides.
2. After receiving the Discovery packet, the DHCP server (RouterB) returns a DHCP Offer
packet carrying its own IP address, to the client.
3. The client broadcasts a DHCP Request packet to the network segment where the
interface resides. The Request packet contains the IP address of the DHCP server.
4. After receiving the Request packet, the DHCP server returns a DHCP ACK packet
carrying an IP address assigned to the interface.
After receiving the DHCP ACK packet, the client calculates the time taken to obtain an
IP address from the DHCP server by subtracting the time the client sends the Discovery
packet from the time the client receives the ACK packet.
Figure 7-1 DHCP test scenario
RouterA RouterB
DHCP Client DHCP Server
A DHCP test only uses an interface to send DHCP packets and releases the DHCP lease after
obtaining an IP address for the interface. Therefore, the DHCP test does not consume address
resources of the DHCP server. The interface used in a DHCP server must be in Up state.

The DHCP test results and historical records are collected in test instances. You can run
commands to view the test results and historical records.
7.3.2 DNS Test
The NQA DNS test is performed using the User Datagram Protocol (UDP) packets. The NQA
client simulates a DNS client and sends a DNS request to a specified Dynamic Host
Configuration Protocol (DHCP) server. This test helps you determine DNS server availability
and measure DNS resolution speed.
Figure 7-2 shows the process of a DNS test:
1. The DNS client (RouterA) sends a DNS query packet to the DNS server, requesting the
server to resolve a specified DNS name.
2. The DNS server receives the query packet, constructs a response packet, and sends it to
the client.
3. RouterA receives the response packet and calculates the time between when it sent the
query packet and when it received the response packet.
Figure 7-2 Network for DNS test

server.com
PC
RouterA
Network
DNS Server
A DNS test only simulates the DNS resolution process. It does not save the mapping between
domain names and IP addresses.
However, DNS test results and historical records are collected in test instances. You can run
7.3.3 FTP Test
The NQA FTP test is performed using TCP. It helps you determine whether an FTP client can
establish a connection with a specified FTP server and measure the time taken to download a
specified file from or upload a specified file to the server.
The NQA FTP test obtains the minimum, maximum, and average time of the following:
l Control connection setup

This is the time taken by the client (RouterA) to set up a TCP control connection with
the FTP server through the three-way handshake and to exchange signals through the
control connection.
l Data connection setup
This is the time taken by the client to download a specified file from or upload a
specified file to the FTP server through the data connection.

Figure 7-3 Network for FTP test

RouterA
FTP Client FTP Server
With an FTP test, the following information can be calculated based on the packets from
clients:
l Minimum, maximum, and average time to set up a control connection
l Minimum, maximum, and average time to set up a data transmission connection
FTP supports file uploads and downloads. During a file download test, the downloaded file is
not actually saved to the local file system. The test only calculates the time taken to download
the file, after which it automatically releases the occupied memory. During a file upload test, a
test file (with fixed size and contents), not local files, is uploaded to the FTP server. The name
of the file to be uploaded is specified by the user and the data in the file is specified by the
system. If a file with the specified name already exists on the server, the existing file is
overwritten. The uploaded file is not deleted after the FTP test. FTP tests are independent of
the local file system.
FTP test results and historical records are collected in test instances. You can run commands
to view the test results and historical records.
7.3.4 HTTP Test

The NQA HTTP test detects whether the client can set up a connection with a specified HTTP
server. This helps you determine whether a device provides HTTP service and measure the
time taken to set up a connection with it.
The NQA HTTP test allows you to determine the minimum, maximum, and total time of the
following:
l DNS resolution
This is the time between when the client (RouterA) sends a DNS packet to the server and
the time when the client receives a DNS resolution packet.
l TCP connection setup
This is the time taken to set up a TCP connection between the client and the HTTP
server through the three-way handshake.
l TCP transaction
This is the time between when the client sends an HTTP GET or POST packet to the
server and the time the client receives a response packet.

Figure 7-4 Network for HTTP test
server.com
HTTP Server
RouterA
Network
HTTP Client
DNS Server
With an HTTP test, the following information can be calculated based on the packets from
clients:
l Minimum, maximum, and total time of DNS resolution
l Minimum, maximum, and total time to set up a TCP connection
l Minimum, maximum, and total HTTP transaction time
HTTP test results and historical records are collected in test instances. You can run commands
7.3.5 ICMP Jitter Test

The ICMP jitter test uses ICMP packets to determine the delay, jitter, and packet loss ratio
based on the timestamps in test packets. Jitter is the interval for receiving two consecutive
packets minus the interval for sending the two packets.
The ICMP jitter test process is as follows:
1. The source (RouterA) sends packets to the destination (RouterB) at a specified interval.
2. The destination receives the packets, adds a timestamp to them, and sends them back to
the source.
3. The source receives the packets and calculates the jitter by subtracting the interval at
which consecutive packets are sent from the interval at which the destination receives
them.
Figure 7-5 Network for ICMP jitter test
Network
RouterA RouterB
The following indexes are calculated based on the information received from the source:
l The maximum, minimum, and average jitter of the packets from the source to the
destination and from the destination to the source.
l The maximum unidirectional delay from the source to the destination or from the
destination to the source.

ICMP jitter test results and historical records are collected in test instances. You can run
7.3.6 ICMP Test
The NQA Internet Control Message Protocol (ICMP) test detects whether there are reachable
routes from the source to the destination. It has a similar function to the ping command, but
provides more output information, including:
l The system saves the results of the latest five tests by default.
l The output includes the average delay, the packet loss rate, and the time the last packet is
correctly received.
The ICMP test process is as follows:

1. The source (RouterA) constructs an ICMP Echo Request packet and sends it to the
destination (RouterB).
2. The destination receives the ICMP Echo Request packet and responds with an ICMP
Echo Reply packet.
Figure 7-6 Network for ICMP test
Network
RouterA RouterB
After receiving a packet, the source calculates the time taken for communication between the
source and the destination by subtracting the time the source sends the request packet from the
time the source receives the reply packet.
The ICMP test results and historical records are collected in test instances. You can run
7.3.7 LSP Ping Test
The NQA label-switched paths (LSP) ping test checks the reachability of Label Distribution
Protocol (LDP) LSPs or traffic engineering (TE) LSPs.
Figure 7-7 shows the process of an LSP ping test:
1. The source (PE-A) constructs a Multiprotocol Label Switching (MPLS) Echo Request
packet whose destination IP field is an IP address on the address block 127.0.0.0/8. The
source then searches for the corresponding Label Distribution Protocol (LDP) LSP based
on the configured remote label switching router (LSR) ID. The source forwards the
packet through that LDP LSP in the MPLS domain. For a TE LSP, the packet can be sent
from a tunnel interface and then forwarded along a specified constraint-based routed LSP
(CR-LSP).
2. The destination (PE-B) egress monitors port 3503 and sends an MPLS Echo Reply
packet to the source.

Figure 7-7 Network for LSP ping test
MPLS
Backbone
Loopback0 Loopback0 Loopback0
PE-A P PE-B
PW
CE-A CE-B
After receiving a reply packet, the source calculates the time taken for communication
between the source and the destination by subtracting the time the source sends the request
packet from the time the source receives the reply packet. The test result reflects the MPLS
network operating status.
LSP ping test results and historical records are collected in test instances. You can run
7.3.8 LSP Trace Test

The NQA LSP trace test detects the forwarding paths of LDP LSPs or TE LSPs and collects
statistics about each device along a forwarding path.
Figure 7-8 shows the process of an LSP trace test:
1. The source (PE-A) constructs a MPLS Echo Request packet whose destination IP field is
an IP address on the 127.0.0.0/8 block. The source then searches for the corresponding
LSP. For a TE LSP, the packet can be sent from a tunnel interface and then forwarded
along a specified CR-LSP.
The MPLS Echo Request packet should contain the downstream mapping type-length-
value (TLV) that carries LSP downstream information on the current node, including
next-hop IP address and outbound label. The TTL of the first MPLS Echo Request
packet is 1.
2. The MPLS Echo Request packet is forwarded through the specified LSP in the MPLS
domain. When the first hop of the LSP receives the packet, its TTL decreases to 0 and it
times out. The first hop then returns an MPLS Echo Reply packet.
3. The source continues to send MPLS Echo Request packets, with the TTL increasing by 1
each time. This process is repeated until all the LSRs along the LSP have returned their
responses.

Figure 7-8 Network for LSP trace test
MPLS
Backbone
PE-A P PE-B
PW
CE-A CE-B
According to the reply packet received from each hop, the source obtains the LSP forwarding
path from the source to the destination and collects statistics about each device along the
forwarding path. The test result shows the LSP forwarding path from the source to the
destination.
The LSP trace test results and historical records are collected in test instances. You can run
7.3.9 SNMP Test

The NQA Simple Network Management (SNMP) test is performed using UDP. It measures
the time taken for communication between an NQA client and an SNMP agent.
The SNMP test process is as follows:
1. The source (RouterA) sends a request packet to the SNMP agent (RouterC) to obtain the
system time.
2. Upon receiving the request packet, the SNMP agent queries the system time, constructs a
reply packet, and sends it to the source.
After receiving the reply packet, the source calculates the time taken for communication
between the source and the SNMP agent by subtracting the time the source sends the
request packet from the time the source receives the reply packet. The test result reflects
SNMP performance on the network.
Figure 7-9 Network for SNMP test

RouterA RouterB RouterC
SNMP Agent
SNMP test results and historical records are collected in test instances. You can run
7.3.10 TCP Test

The NQA TCP test measures the time taken to set up a TCP connection between an NQA
client and a TCP server through the three-way handshake.
The TCP test process is as follows:
1. The source (RouterA) sends a TCP SYN packet to the destination (RouterB) to set up a
TCP connection.
2. The destination receives the TCP SYN packet and responds with a TCP SYN-ACK
packet.
3. The source receives the SYN-ACK packet and sends an ACK packet to the destination.
The connection is now established and the source can calculate the time taken.
Figure 7-10 TCP test scenario

RouterA RouterB
Router A calculates the time taken to set up the TCP connection with router B by subtracting
the time router A sends the TCP SYN packet to the time router A receives the TCP SYN
ACK packet. The test result reflects TCP performance on the network.
Frequent TCP tests will consume too many resources and affect running services on the
device.
TCP test results and historical records are collected in test instances. You can run commands
7.3.11 Trace Test

The NQA trace test detects the forwarding path between the source and the destination and
collects statistics about each device along the forwarding path. It has a similar function to the
tracert command, but provides more output information, including:
l Average delay
l Packet loss ratio
l Time of receiving the last packet
The trace test process is as follows:
1. The source (RouterA) constructs a UDP packet, with the time-to-live (TTL) set to 1 and
sends it to the destination (RouterD).
2. When the first-hop router (RouterB) receives the UDP packet, its TTL decreases to 0.
The first-hop router discards the UDP packet and returns an ICMP Time Exceeded
packet.
3. The source obtains the IP address of the first-hop router from this ICMP Time Exceeded
packet. It then constructs another UDP packet with the TTL set to 2.
4. When the second-hop router (RouterC) receives the UDP packet, its TTL decreases to 0.
The second-hop router discards the UDP packet and returns an ICMP Time Exceeded
packet.
5. The source continues to send UDP packets, with the TTL increasing by 1 each time. This
process is repeated until the packet reaches the destination, which then returns an ICMP
Port Unreachable packet to the source.

Figure 7-11 Network for Trace test
RouterA RouterB RouterC RouterD
According to the ICMP packet received from each hop, the source obtains information about
the forwarding path from the source to the destination and statistics about each device along
the forwarding path. The test result shows the forwarding path from the source to the
destination.
Trace test results and historical records are collected in test instances. You can run commands
7.3.12 UDP Test
The NQA UDP test measures the time taken for communication between an NQA client and a
UDP server.
The UDP test process is as follows:
1. The source (RouterA) constructs a UDP packet and sends it to the destination (RouterC).
2. The destination receives the packet and returns it to the source.
After receiving the UDP packet, the source calculates the time taken for communication
between the source and the destination by subtracting the time the source sends the UDP
packet from the time the source receives the UDP packet. The test result reflects UDP
performance on the network.
Figure 7-12 Network for UDP test

UDP test results and historical records are collected in test instances. You can run commands
7.3.13 UDP Jitter Test
The UDP jitter test is performed using UDP packets to determine the delay, jitter, and packet
loss ratio based on the timestamps in test packets. Jitter is the interval for receiving two
consecutive packets minus the interval for sending the two packets.
The UDP jitter test process is as follows:
1. The source (RouterA) sends packets to the destination (RouterB) at a specified interval.
2. The destination receives packets, adds a timestamp to them, and sends them back to the
source.
3. The source receives the returned packets and calculates the jitter by subtracting the
interval at which consecutive packets were sent from the interval at which the destination
received them.

Figure 7-13 Network for UDP jitter test
Network
RouterA RouterB
The following data can be calculated based on information in the packets received by the
source:
l Maximum, minimum, and average jitter of the packets from the source to the destination
and from the destination to the source.
l Maximum unidirectional delay from the source to the destination or from the destination
to the source.
In a UDP jitter test, the maximum number of test packets sent each time is configurable. It is
the number of jitter tests (probe-count) multiplied by the number of test packets sent each
time (jitter-packetnum).
You can also set the number of consecutive packets to be sent in a single test instance. This
setting allows you to simulate actual traffic for a specified period of time. For example, if you
set the source to send 3,000 UDP packets at an interval of 20 ms, this would simulate G.711
traffic for 1 minute.
UDP jitter test results and historical records are collected in test instances. You can run
7.3.14 UDP Jitter (Hardware-based) Test
A UDP jitter (hardware-based) test is performed using UDP packets and is a supplement to
the UDP jitter. This test has the following advantages:
l Reduces the interval for sending packets. The minimum interval for sending packets can
be 10 ms.
l Increases the number of concurrent test instances.
l Improves the accuracy of delay and jitter calculation.
These advantages enable the UDP jitter (hardware-based) test to accurately reflect the
network status and improve device efficiency.
Table 7-1 Differences between UDP jitter and UDP jitter (hardware-based)
Comparison UDP Jitter UDP Jitter (Hardware-

based)
Interval for sending The minimum value is 20 The minimum value is 10 ms.
packets ms.
Jitter calculation Timestamps are added to Timestamps are added to

packets on the MPU. packets on the LPU, which is
more precise.

Figure 7-14 UDP jitter (hardware-based) test scenario
Network
RouterA RouterB
The UDP jitter (hardware-based) test results and historical records are collected in test
instances. You can run commands to view the test results and historical records.
7.4 NQA Association Mechanism

NQA provides test results for other modules so that other modules can take measures
according to test results. Currently, NQA can be associated with the Virtual Router
Redundancy Protocol (VRRP), static routes, backup interfaces, IGMP Proxy, IP address pool,
DNS Server, and policy-based routing (PBR).
The following uses a static route as an example.
In this example, there is a static route with next hop 192.168.0.88. Association between the
NQA module and application module determines the validity of the static route in real time. If
the NQA module finds that next hop 192.168.0.88 is unreachable, it notifies the static route
module. The static route module then determines whether the static route is invalid.
7.5 Application Scenarios for NQA
Performing Network Diagnosis

Networks often encounter such problems as intermittent network disconnections, failure to
access websites, slow Internet access, and slow file downloading. When these occur, you can
locate the fault by collecting statistics about network devices. These statistics must be
provided by the devices.
Figure 7-15 Performing network diagnosis
VPN Site Network VPN Site
CE PE PE CE
In the example shown in Figure 7-15, users in different places connect to each other over a
VPN. They find, for instance, that the network intermittently disconnects and the connection
is slow.
In this situation, you can deploy NQA on PEs to analyze network quality. Perform an ICMP
test between the PEs and CEs to check the continuity of the network. After confirming that
the network is correctly connected, perform a jitter test to measure network jitter. Then
perform the same tests between the PEs. Analyze the test data and the faults that users
encounter to locate the source of these faults.

Learning About Network Service Quality

In Figure 7-16, you can perform an NQA test on a switch to obtain statistics about the
network operating status. This provides information about network service quality.
Figure 7-16 Learning about network service quality
NM Station
Network
User Router
7.6 Summary of NQA Configuration Tasks
Configuring Basic NQA Test Functions

You can perform an NQA test by 7.9 Configuring an NQA Test Instance and 7.13
Scheduling an NQA Test Instance.
Configuring Extended NQA Test Functions

The following extended NQA functions are optional in NQA configuration:
l 7.10 Configuring the NQA Transmission Delay Threshold and Alarm Threshold
l 7.11 Configuring the Trap Function
l 7.12 Configuring the NQA Client to Send Test Results to an FTP Server
Supporting Third-Party NQA Tests

You can enable the device to respond to UDP-Echo packets sent by a third-party device or
NMS by 7.8 Configuring the Response to UDP Tests Initiated by a Third-party Device or
NMS Software.
7.7 Licensing Requirements and Limitations for NQA

This section provides the points of attention when configuring NQA.

None
NQA is a basic feature of a router and is not under license control.

Feature Limitations
Pay attention to the following points when configuring NQA:
l If an Eth-Trunk is configured as a mirrored port, its member ports cannot be configured
as mirrored ports. To configure a member port as a mirrored port, delete it from the Eth-
Trunk first.
The frequency value must comply with the following rules:
– In the DHCP, DNS, FTP, HTTP, or Trace test instance, the frequency value must be
larger than the product of timeout and probe-count.
– In the ICMP, SNMP, TCP, or UDP test instance, the frequency value must be larger
than the product of intervaland probe-count.
– In the Jitter test instance:
frequency > probe-count × jitter-packetnum × interval + timeout
– In the hardware-based Jitter test instance:
frequency > probe-count × jitter-packetnum × interval + 6200 + (5 × timeout/3)
The unit of 6200 is ms.
– may be returned if the following condition is true: Interval at which the NQA test is
automatically performed ≤ (Number of sent packets -1) x Interval + Timeout period
+ 1. For a test instance with jitter-packetnum configured, the number of sent packets
is Probe-count x jitter-packetnum.
l If multiple outbound interfaces exist and you want to trace the next hop or remote tracing
address of one outbound interface using NQA, you must specify source-interface.
Otherwise, network flapping occurs.
l If a large number of NQA test instances are configured, run the start delay command to
specify a delay in performing NQA test instances and then start the NQA test instances.
In this way, these NQA test instances can be concurrently executed in batches. You are
advised to execute about 200 NQA test instances concurrently at most.
l When the hardware forwarding engine on an LPU is not configured to send packets, you
need to run the packet-type command on the client to configure CPCAR values.
l When the hardware forwarding engine on an LPU is configured to send packets, run the
interval milliseconds command to set the interval for sending packets to less than 1
second.
7.8 Configuring the Response to UDP Tests Initiated by a

Third-party Device or NMS Software
When a device connects to third-party device or NMS software and needs to respond to the
UDP-Echo or UDP-Jitter packets sent from the third-party device or NMS software, configure
this function.
Prerequisites
The parameters of UDP tests have been set on the third-party device or NMS software.

Procedure
Step 2 Run ip nqa-compatible responder [ vpn-instance vpn-instance-name ] enable
The device is enabled to respond to UDP-Echo or UDP-Jitter packets sent by a third-party
device or NMS software.
By default, the device is disabled from responding to UDP-Echo or UDP-Jitter packets sent
by a third-party device or NMS software.
Step 3 Use either of the following methods to configure the response to UDP-Echo or UDP-Jitter
packets sent from the third-party device or NMS software. If Step 2 configure vpn-instance,
it just suports the method b.
1. Run the ip nqa-compatible auto command to configure the device to automatically
respond to the UDP-Echo or UDP-Jitter packets sent by the third-party device or NMS
software.
By default, the device does not automatically respond to the UDP-Echo or UDP-Jitter
packets sent by the third-party device or NMS software.
2. Run the ip nqa-compatible { device | network-management } udp ip-address [ vpn-
instance vpn-instance-name ] port-number [ tos-value ] command to specify the IP
address, port number, and service type of the response to the UDP-Echo or UDP-Jitter
packets sent from the third-party device or NMS software.
By default, the IP address, port number, and service type of the response to the UDP-
Echo or UDP-Jitter packets sent by the third-party device or NMS software are not
specified.
NOTE
If the configured port number is 7, 13, or 19, run the undo anti-attack udp-flood enable
command to disable UDP Flood attack defense. Otherwise, the device discards UDP-Echo or
UDP-Jitter packets.
If the configured port number is occupied by another process, this command will not take effect.
----End
Verifying the Configuration

l Run the display current-configuration | include ip nqa-compatible command to
display the configuration of response to the UDP-Echo or UDP-Jitter packets sent by the
third-party device or NMS software.
l Run the display ip nqa-compatible responder statistics command to display statistics
on the NQA handshake packets sent from the third-party device or NMS software.
7.9 Configuring an NQA Test Instance

You can configure an NQA test instance to perform an NQA test of a specified type.
Before configuring the NQA test instance, complete the following tasks:

l Ensure that the device is running properly.

l Configure routing to ensure reachable routes between devices involved in the test.
NOTE
The pre-configuration tasks differ from different test instances. For details, see the configuration of each
test instance.
The following optional test instances are independent of each other:
7.9.1 Configuring a DHCP Test Instance
Context
Before configuring a DHCP test instance, configure a DHCP server or DHCP Relay, and
ensure reachable routes between the DHCP client and the DHCP server or the DHCP Relay.
Through the DHCP test, you can obtain the following information:
l Time for a DHCP client to set up a connection with a DHCP server
l Time for a DHCP client to obtain its IP address
NOTE
The NQA client also functions as the DHCP client. Perform the following steps on the NQA client.
The timeout, probe-count, and frequency commands constrain each other; therefore, properly set the
values when running the three commands. Improper command settings may lead to test failure.
l On a network with poor quality and low transmission rate, increase the timeout value to ensure that
the response to NQA detection packets can be received.
l On a network with low reliability, increase the probe-count value because multiple detection
packets may need to be sent to ensure successful detection.
l The frequency value must be larger than the product of timeout and probe-count.
Procedure
Step 3 Run ip address dhcp-alloc
The DHCP client is enabled.
Step 4 Run quit
Exit from the interface view.
Step 5 Run nqa test-instance admin-name test-name
An NQA test instance is created, and the NQA view is displayed.
Step 6 Run test-type dhcp

The test type is set to DHCP.
NOTE
The test cannot be started after multiple NQA DHCP test instances are configured.
Step 7 Run source-interface interface-type interface-number
The source interface that sends DHCP request packets is specified.
NOTE
Do not configure DHCP on the interface that sends DHCP request packets; otherwise, NQA DHCP test
instance will fail.
Step 8 (Optional) Run the following commands as required to configure parameters for the DHCP
test.
l Run description string
A description is configured for the test instance.
l Run frequency interval
The test period is set for the NQA test instance.
l Run timeout time
The timeout period of a probe is set for the NQA test instance.
By default, the timeout period of a DHCP probe is 15 seconds.
NOTE
In a DHCP test, the NAQ client may need to wait 10 seconds for the response after sending a
probe packet. By default, the timeout period of a probe is 15 seconds. If you need to change the
timeout period, you are advised to set the timeout period longer than 10 seconds.
l Run probe-count number
The number of probes in a test is set.
l Run records history number
The maximum number of historical records is set for the NQA test instance.
l Run records result number
The maximum number of result records is set for the NQA test instance.
l Run agetime hh:mm:ss
The aging time is set for the NQA test instance.
l Run fail-percent percent
The failure percentage is set for the NQA test instance.
----End
7.9.2 Configuring a DNS Test Instance
Context
Before configuring a DNS test instance, configure a DNS server and ensure reachable routes
between the DNS client and the DNS server.
A DNS test can detect the speed at which a DNS name is resolved into an IP address.

NOTE
The NQA client also functions as the DHCP client. Perform the following steps on the NQA client.
The timeout and frequency commands constrain each other; therefore, properly set the values when
running the two commands. Improper command settings may lead to test failure.
l The frequency value must be larger than the timeout value.
Procedure
Step 2 Run dns resolve
Dynamic DNS resolution is enabled.
By default, dynamic DNS resolution is disabled.
Step 4 Run test-type dns
The test type is set to DNS.
Step 5 Run destination-address url urlstring
The name of the destination host is configured.
Step 6 (Optional) Run the following commands as required to configure parameters for the DNS test.
l Run timeout time
By default, the timeout period of a DNS probe is 3 seconds.
l Run source-address { ipv4 ip-address | ipv6 ipv6-address }
The source IP address is configured.
ip-address and ipv6-address are similar to -a in the ping command and -a in the ping
ipv6 command respectively.
l Run dns-server ipv4 ip-address

The DNS server address is configured.
----End
7.9.3 Configuring an FTP Download Test Instance
Context
Before configuring an FTP download test instance, configure the FTP user name, password,
and the login directory for the FTP server, and ensure reachable routes between the FTP client
and the FTP server.
Pay attention to the following points for an FTP download test:
l The local device functions as an FTP client to download the specified file from the FTP
server.
l An FTP download test can obtain statistics about each FTP phase, including the time
spent in setting up an FTP control connection and the time spent in transmitting data.
NOTE
The NQA client also functions as the FTP client. Perform the following steps on the NQA client.
Procedure
Step 3 Run test-type ftp
The test type is set to FTP.

Step 4 Run destination-address ipv4 ipv4-address
The destination address is configured.
Step 5 (Optional) Run the following commands as required to configure parameters for the FTP test.
l Run timeout time

By default, the timeout period of a FTP probe is 15 seconds.

l Run destination-port port-number
The destination port number is configured.
l Run source-address ipv4 ipv4-address
l Run source-port port-number
The source port number is configured.
l Run ttl number
The TTL value in the NQA test packet is set.
l Run sendpacket passroute
The NQA test instance is configured to send packets without searching the routing table.
l Run tos value
Type of Service (TOS) is set for the test packet.
l Run ftp-filesize size
The file size is set for the FTP test instance.
l Run vpn-instance vpn-instance-name
The VPN instance name is configured.
Step 6 Run ftp-operation get
The FTP operation type is set to Get.
Step 7 Run ftp-username name
The FTP user name is configured.
Step 8 Run ftp-password { password | cipher cipher-password }
The FTP password is configured.
Step 9 Run ftp-filename file-name
The file name and file path are configured for the FTP test instance.
NOTE
During the FTP test, select a file of a small size. If the file is too large, the test may fail because of
timeout.
The file download operation cannot save the file to the local file system, but only count the time taken to
download the file. The system releases the memory immediately after obtaining the data.
----End
7.9.4 Configuring an FTP Upload Test Instance

Context
Before configuring an FTP upload test, configure the FTP user name, password, and the login
directory for the FTP server, and ensure reachable routes between the FTP client and the FTP
server.
Pay attention to the following points for an FTP upload test:

l The local device functions as an FTP client to upload a specified file to the FTP server.
l An FTP upload test can obtain statistics about each FTP phase, including the time spent
in setting up an FTP control connection and the time spent in transmitting data.
l You can specify the file or the number of bytes to be uploaded. If the number of bytes is
specified, the FTP client can generate test files automatically for uploading.
NOTE
The NQA client also functions as the FTP client. Perform the following steps on the NQA client.
Procedure
Step 3 Run test-type ftp
The test type is set to FTP.
Step 5 (Optional) Run the following commands as required to configure parameters for the FTP test.
l Run timeout time
By default, the timeout period of a FTP probe is 15 seconds.


l Run ttl number
l Run tos value
Step 6 Run ftp-operation put
The FTP operation type is set to Put.
Step 7 Run ftp-username name
The FTP user name is configured.
Step 8 Run ftp-password { password | cipher cipher-password }
The FTP password is configured.
Step 9 (Optional) Use one of the following methods to upload the specified file.
l To upload the specified file, run the ftp-filename file-name command.
NOTE
– If no file path is specified, the system searches for the file in the current path. If the specified
file name does not exist, the system generates a file with the specified file name and sets the
file size to 1 MB.
– The file name cannot contain such characters as tilde (~), asterisk (*), slash (/), backslash (\),
apostrophe ('), quotation mark ("), and comma (,), but the file path can contain these
characters.
– The file name can contain a file name extension but cannot contain only the file name
extension, for example, .txt
l To upload a file of a specified size, run the ftp-filesize size command. The NQA client
(also the FTP client) automatically generates a file named nqa-ftp-test.txt for uploading.
NOTE
During the FTP test, select a file of a small size. If the file is too large, the test may fail because of
timeout.
The file uploading operation cannot save the local file to the FTP server, but upload the file in the
fixed size and content. You need to configure the file name. The data is specified by the system. If
the file name is the same as that in the FTP server, the uploaded file overwrites the existing file
and is not deleted after the test.
----End

7.9.5 Configuring an HTTP Test Instance
Context
Before configuring an HTTP test instance, configure an HTTP server and ensure reachable
routes between the HTTP client and the HTTP server.
Through an NQA HTTP test, you can obtain the response speed in three phases:
l DNS resolution time: indicates the time taken to resolve the HTTP server domain name
into its IP address. During this process, the NQA client sends a DNS request to the DNS
server. The DNS server resolves the domain name of the HTTP server to an IP address
and returns a DNS response.
l TCP connection setup time: indicates the time spent in setting up a TCP connection
between the NQA client and the HTTP server through three-way handshake.
l Transaction time: It is a period from the time the client sends the Get or Post packets to
an HTTP server to the time the Echo packet sent by the client reaches the HTTP client.
NOTE
The NQA client also functions as the HTTP client. Perform the following steps on the NQA client.
Procedure
Step 3 Run test-type http
The test type is set to HTTP.
Step 5 (Optional) Run the following commands as required to configure parameters for the HTTP
test.
l Run timeout time

l Run dns-server ipv4 ip-address
The DNS server address is configured.
l Run source-interface interface-type interface-number
The source interface is configured.
l Run ttl number
l Run tos value
Step 6 Run http-operation get
The HTTP operation type is set to Get.
Step 7 Run http-url deststring [ verstring ]
The URL of the web page that the HTTP test accesses and the HTTP version are configured.
NOTE
If no HTTP version is configured, HTTP1.0 is supported by default. You can set the version to
HTTP1.1.
----End
7.9.6 Configuring an ICMP Test Instance

Context
Before configuring an ICMP test instance, configure reachable routes between the NQA client
and the tested device.
An ICMP test has the same function as the ping command but displays more detailed
information.
NOTE
Perform the following steps on the NQA client.

The timeout, probe-count, frequency, and interval commands constrain each other; therefore, properly
set the values when running the four commands. Improper command settings may lead to test failure.
l The interval value must be larger than the timeout value.
l The frequency value must be larger than the product of interval and probe-count.
In an ICMP test instance, if the following conditions are met, the Completion field in the test results
will be displayed as no result:
l The system CPU usage exceeds 90% and the configured timeout period is less than 6s.
l frequency configured ≤ (probe-count - 1) × interval + 6.
Procedure
Step 3 Run test-type icmp
The test type is set to ICMP.
Step 4 Run destination-address { ipv4 ipv4-address | ipv6 ipv6-address }
Step 5 (Optional) Run the following commands as required to configure parameters for the ICMP
test.
The interval at which the NQA test instance is automatically executed is set.
l Run timeout time
By default, the timeout period of an ICMP probe is 3 seconds.
The source interface that sends test packets is configured.


ip-address and ipv6-address are similar to -a in the ping command and -a in the ping
ipv6 command respectively.
l Run ttl number
The TTL value is set.
number is similar to -h in the ping command.
l Run datasize size
The size of Echo Request packets excluding the IP header is configured.
size is similar to -s in the ping command.
l Run datafill fillstring
The padding field is configured.
fillstring is similar to -p in the ping command.
l Run tos value
The type of service (ToS) field value in an IP header is configured.
value is similar to -tos in the ping command.
l Run interval seconds interval
The interval at which test packets are sent is configured.
interval is similar to -m in the ping command.
l Run records history-filter { all | failures }
The device is enabled to filter out records in a historical NQA test instance table.
l Run ip-forwarding
Packets are forcibly forwarded using IP on the first node.
l Run nexthop ipv4 ip-address
The next hop address of the test instance is configured.
Step 6 (Optional) Create an NQA group and add NQA test instances to the NQA group.

After an NQA group is created, you can add NQA test instances to the NQA group, and then
manage the NQA group to monitor multiple links at the same time.
1. Run quit
Exit from the test instance view.
2. Run nqa-group group-name
An NQA group is created and the NQA group view is displayed.
3. Run nqa admin-name test-name
An NQA test instance is added to the NQA group.
----End
7.9.7 Configuring an ICMP Jitter Test Instance

Context
Before configuring an ICMP jitter test, ensure that the NQA client and the tested device have
reachable routes to each other.
NOTE
Perform the following steps on the NQA client. The NQA client also functions as the ICMP jitter client.
The timeout, probe-count, frequency, jitter-packetnum, and interval commands constrain each other;
therefore, properly set the values when running the five commands. Improper command settings may lead to
test failure.
l On a network with poor quality and low transmission rate, increase the timeout value to ensure that the
response to NQA detection packets can be received.
l On a network with low reliability, increase the probe-count value because multiple detection packets
may need to be sent to ensure successful detection.
l The frequency value must comply with the following rules:
Procedure
Step 3 Run test-type icmpjitter
The test type is set to ICMP Jitter.
Step 5 (Optional) Run the following commands to configure other parameters for the ICMP jitter
test:
A description is configured.


The interval at which the NQA test instance automatically runs is set.
l Run icmp-jitter-mode { icmp-echo | icmp-timestamp }
The ICMP Jitter test type is set.
By default, the ICMP jitter test type is icmp-timestamp.
NOTE
The datafill and datasize parameters are supported only when the icmp-jitter-mode is icmp-echo.
In an ICMP jitter test, icmp-timestamp has a higher calculation precision of jitter parameters (such as
delay and jitter) than icmp-echo. Therefore, icmp-timestamp is recommended. If the remote device does
not support icmp-timestamp or requires ICMP echo packets, configure icmp-echo.
l Run datasize size
The echo request packet size, excluding the IP header, is set.
l Run timeout time
By default, the timeout period of a probe is 3 seconds.
The source interface used to send test packets is configured.
The source address is configured. This parameter is similar to -a in the ping command.
l Run ttl number
The TTL value is set. This parameter is similar to -h in the ping command.
The number of probes for one time is set.
l Run tos value
ToS is set for the test packet. This parameter is similar to -tos in the ping command.
The interval for sending test packets is set. This value is similar to -m in the ping
command.
A VPN instance is configured for the test instance.
l Run jitter-packetnum number
The number of test packets sent in each test instance is set.
NOTE
The probe-count command sets the number of jitter tests and the jitter-packetnum command sets
the number of test packets sent during each test. The number of jitter tests multiplied by the
number of test packets must be smaller than 3000.


----End
7.9.8 Configuring an SNMP Query Test Instance
Context
Before configuring an SNMP query test instance, configure an SNMP agent and ensue
reachable routes between the NQA client and the SNMP agent.
You can obtain the statistics about communication between the NQA client and the SNMP
agent.
NOTE

Procedure
Step 2 Run snmp-agent
The SNMP agent service is enabled.
Step 4 Run test-type snmp
The test type is set to SNMP.
The destination IP address (IP address of the SNMP agent) is configured.
NOTE
The SNMP function must be enabled on the destination host, otherwise, the NQA client cannot receive
response packets.
Step 6 Run community read cipher community-name

The community name is set for SNMP test.
NOTE
When the SNMP versions on agents are SNMPv1 or SNMPv2c, the community name must be configured
using the community read cipher command, and the community name must be a read-only community name
on SNMP agents. When the SNMP versions on agents are SNMPv3, the community name does not need to
be configured because SNMPv3 does not support community names.
Step 7 (Optional) Run the following commands as required to configure parameters for the SNMP
test.
l Run timeout time
l Run ttl number
l Run tos value
Type of Service (ToS) is set for the test packet.
----End
7.9.9 Configuring a TCP Test Instance

Context
Before configuring a TCP test instance, configure a TCP server and ensure reachable routes
between the TCP client and the TCP server.
An NQA TCP test measures the speed at which a TCP connection can be set up between an
NQA client and a TCP server through the three-way handshake.
NOTE
The NQA client also functions as the TCP client.

Procedure
l Configure the TCP server.
a. Run system-view
b. Run nqa-server tcpconnect [ vpn-instance vpn-instance-name ] ip-address port-
number
The monitoring IP address and port number of the TCP server are configured.
l Configure the NQA client.
a. Run system-view
b. Run nqa test-instance admin-name test-name
c. Run test-type tcp
The test type is set to TCP.
d. Run destination-address ipv4 ipv4-address
The destination IP address is configured.
e. (Optional) Run the following commands as required to configure parameters for the
TCP test.
n Run description string
n Run frequency interval
n Run timeout time
n Run destination-port port-number


n Run source-address ipv4 ipv4-address
n Run source-port port-number
n Run ttl number
n Run sendpacket passroute
The NQA test instance is configured to send packets without searching the
routing table.
n Run probe-count number
n Run tos value
n Run fail-percent percent
n Run interval seconds interval
n Run vpn-instance vpn-instance-name
n Run records history number
n Run records result number
n Run agetime hh:mm:ss
----End
7.9.10 Configuring a Trace Test Instance
Context
Before configuring a trace test instance, configure reachable routes between the NQA client
and the tested device.
The NQA trace test provides equivalent functions as the tracert command but displays more
detailed information.

NOTE

Procedure
Step 3 Run test-type trace
The test type is set to trace.
Step 4 Run destination-address { ipv4 ipv4-address | ipv6 ipv6-address }
The destination address for the trace instance test is configured.
Step 5 (Optional) Run the following commands as required to configure parameters for the trace test
instance.
The test period is set.
l Run timeout time
The timeout period of a probe is set.
l Run source-address { ipv4 ipv4-address | ipv6 ipv6-address }
l Run tracert-livetime first-ttl first-ttl max-ttl max-ttl
The initial and the maximum TTL of the packet are configured.
l Run tracert-hopfailtimes times
The hop fail times are set.
l Run set-df
Packet fragmentation is prohibited.
l Run datasize size
The packet size is set.


The maximum number of historical records is set.
The maximum number of result records is set.
The aging time is set for the test instance.
----End
7.9.11 Configuring a UDP Test Instance
Context
Before configuring a UDP test instance, configure a UDP server and ensure reachable routes
between the UDP client and the UDP server.
To test the time for a specified port to respond to a UDP connection request, create a UDP test
instance.
NOTE
The NQA client also functions as the UDP client.

Procedure
l Configure the UDP server.
a. Run system-view
b. Run nqa-server udpecho [ vpn-instance vpn-instance-name ] { auto-address | ip-
address | ipv6 ipv6-address } port-number
The monitoring IP address and port number of the UDP server are configured.

a. Run system-view
c. Run test-type udp
The test type is set to UDP.
d. Run destination-address ipv4 ipv4-address
e. Run destination-port port-number
By default, the destination port number in the UDP test is 7.
NOTE
If the configured destination port number is 7, 13, or 19, run the undo anti-attack udp-flood
enable command on the server to disable UDP flood attack defense; otherwise, the server
discards detection packets.
f. (Optional) Run the following commands as required to configure parameters for the
UDP test.
n Run timeout time
n Run source-address ipv4 ipv4-address
n Run ttl number
n Run datafill fillstring
The padding field is configured for the NQA test instance.
n Run datasize size
The packet size is set for the NQA test instance.
routing table.
n Run tos value


n Run interval seconds interval
----End
7.9.12 Configuring a UDP Jitter Test Instance
Context
When configuring a UDP Jitter test instance, configure reachable routes between the UDP
Jitter client and the UDP Jitter server.
You can set the number of packets to be sent consecutively in each test instance. This
configuration is used to simulate certain traffic. For example, G.711 traffic can be simulated
within 1 minute by sending 3000 UDP packets at an interval of 20 milliseconds.
NOTE
Configuring NTP on the client and the server can effectively improve the accuracy of the test.
The NQA client also functions as the UDP Jitter client. The jitter obtained in this test is the UDP Jitter.
therefore, properly set the values when running the five commands. Improper command settings may
lead to test failure.
Procedure
l Configure the UDP Jitter server.
a. Run system-view


a. Run system-view
b. (Optional) Run nqa-jitter tag-version version-number
The version number is configured for Jitter packets.
By default, the version number of Jitter test packets is 1.
After setting the version number of the Jitter test packets to 2 and enabling the NQA
client to collect statistics about packet loss in one direction, you can view the
number of lost packets on the link from the source to the destination, from the
destination to the source, or from unknown directions. Based on these statistics, you
can easily locate network faults and detect malicious attacks.
c. Run nqa test-instance admin-name test-name
d. Run test-type jitter
The test type is set to Jitter.
e. Run destination-address { ipv4 ipv4-address | ipv6 ipv6-address }
f. Run destination-port port-number
g. (Optional) Run the following commands as required to configure parameters for the
Jitter test:
n Run timeout time
n Run source-address { ipv4 ipv4-address | ipv6 ipv6-address }
n Run ttl number
n Run datasize size
n Run datafill fillstring
The padding field is configured for the NQA test instance.
n Run source-interface interface-type interface-number
The source interface that sends test packets is configured.

routing table.
By default, the NQA test packets are sent with searching the routing table.
The number of probes in each test is set.
By default, the number of probes is 3.
n Run tos value
By default, the failure percentage is 100%, that is, the test is regarded failed
only when all the probes fail.
n Run interval { milliseconds interval | seconds interval }
The interval at which test packets are sent is set.
A shorter interval enables a test to be complete sooner. Delays occur during the
sending and receiving of test packets on the processor. Therefore, if the
interval for sending test packets is short, the Jitter test results are inaccurate.
n Run jitter-packetnum number
The number of test packets sent in each probe is set.
By default, 20 packets are sent each time in each test.
The Jitter test is used to collect and analyze the delay variation during the UDP
packet transmission. To improve the accuracy of the test result, the system
sends multiple test packets each time. The more test packets are sent, the more
accurate the statistics are, and the longer the test lasts.
NOTE
The probe-count command sets the number of Jitter probes and the jitter-packetnum
command sets the number of test packets sent during each probe. The product of probe
count multiplied by the number of test packets must be smaller than or equal to 3000.
n Run jitter-codec { g711a | g711u | g729a }
The code type is configured for jitter tests of analog voice services.
This command is applied only to jitter tests of analog voice services.
n Run adv-factor factor-value
The advantage factor is configured for analog voice test calculation.
This command is applied only to jitter tests of analog voice services.
n Run timestamp-unit millisecond

The timestamp unit is set for the NQA test instance.

n Run packet-rewrite-check { alternant-binary | same-binary }
The NQA packet rewrite check function is configured by padding NQA
packets.
----End
7.9.13 Configuring a Hardware-based UDP Jitter Test Instance
Context
Before configuring a hardware-based UDP Jitter test instance, configure reachable routes
between the NQA client and the UDP Jitter server.
Jitter equals the interval between receiving two consecutive packets minus the interval
between sending them.
When configuring a hardware-based UDP Jitter test instance, you can set the number of
packets to be sent consecutively in each test instance. This configuration is used to simulate
certain traffic. For example, G.711 traffic can be simulated within 1 minute by sending 3000
UDP packets at an interval of 20 milliseconds.
NOTE
Configuring NTP on the NQA client and the server can effectively improve the accuracy of the test.
Perform the following steps on the NQA client. The NQA client also functions as the Jitter client. The
Jitter obtained in the test is the UDP jitter that occurs when the device uses the hardware to send packets.
therefore, properly set the values when running the five commands. Improper command settings may
lead to test failure.
frequency > probe-count × jitter-packetnum × interval + 6200 + (5 × timeout/3)
The unit of 6200 is ms.
Procedure
l Configure a UDP Jitter server for hardware-based UDP jitter test.
a. Run system-view
The IP address and port number of the server must be the same as those configured
on the client.
c. (Optional) Run nqa-server session-record enable
NQA client information display is enabled on the NQA server.

By default, NQA client information display is disabled on the NQA server.

a. Run system-view


c. Run test-type jitter
The test type is set to Jitter.

d. Run destination-address ipv4 ip-address

e. Run destination-port port-number

f. Run hardware-based enable
The LPUs are enabled to send packets.

g. (Optional) Run the following commands as required to configure parameters for the
Jitter test:
n Run timeout time
n Run source-address ipv4 ip-address
n Run ttl number
n Run datasize size
n Run source-interface interface-type interface-number
The source interface for the NQA test instance is configured.
routing table.
By default, the NQA test packets are sent by searching the routing table.
The number of test probes in each test is set.

n Run tos value

By default, the failure percentage is 100%, that is, the test is regarded failed
only when all the probes fail.
n Run interval { milliseconds interval | seconds interval }
By default, test packets are sent at an interval of 20 milliseconds.
A shorter interval enables a test to be complete sooner. Delays occur during the
sending and receiving of test packets on the processor. Therefore, if the
interval for sending test packets is short, the Jitter test results are inaccurate.
n Run jitter-packetnum number
The number of test packets sent in each probe is set.
By default, 20 packets are sent in each probe.
The Jitter test is used to collect and analyze the delay variation during UDP
packet transmission. To improve the accuracy of the test result, the system
sends multiple test packets each time. The more test packets are sent, the more
accurate the statistics are, and the longer the test lasts.
NOTE
The probe-count command sets the number of Jitter probes and the jitter-packetnum
command sets the number of test packets sent during each probe. The product of probe
count multiplied by the number of test packets must be smaller than or equal to 3000.
n Run timestamp-unit { millisecond | microsecond }
The timestamp unit is set for the NQA test instance.
----End
7.9.14 Configuring the LSP Ping Test
Context
The NQA LSP Ping test can be used to test the reachability of the following types of Label
Switched Paths (LSPs).
l LSP tunnels
l MPLS TE tunnels

l MPLS CR-LSP hotstandby tunnels
NOTE
The AR100&AR120&AR150&AR160&AR200 does not support the LSP ping test.

Procedure
An NQA test instance is created and the test instance view is displayed.
Step 3 Run test-type lspping
The test type is set to LSP ping.
Step 4 Configure the LSP ping test based on the LSP type.
l Configure the LSP ping test for the LSP tunnel.
– Run lsp-type ipv4
The tunnel type is set to be the LSP tunnel.
– Run destination-address ipv4 ipv4-address [ lsp-masklen masklen [ lsp-masklen
masklen ] [ vpn-frr-path ] | lsp-loopback loopback-address [lsp-masklen
masklen ] [vpn-frr-path ] | vpn-frr-path ]
The destination IP address to be tested is configured.
l Configure the LSP ping test for the MPLS TE tunnel.
– Run lsp-type te
The tunnel type is set to be the MPLS TE tunnel.
– Run lsp-tetunnel tunnel interface-number
The TE tunnel interface to be tested is configured.
l Configure the LSP ping test for the CR-LSP hotstandby tunnel.
– Run lsp-type te
The tunnel type is set to be TE tunnel.
– Run lsp-tetunnel tunnel interface-number hot-standby
The TE tunnel interface to be pinged is specified and the CR-LSP hotstandby tunnel
is set to be tested.
l Configure the LSP ping test for the CR-LSP primary tunnel.
– Run lsp-type te


– Run lsp-tetunnel tunnel interface-number primary
The TE tunnel interface to be pinged is specified and the CR-LSP primary tunnel is
set to be tested.
Step 5 (Optional) Perform the following as required to configure other parameters for the LSP ping
test:
l Run lsp-version { rfc4379 | draft6 }
A protocol used by the LSP ping test is configured.
l Run lsp-nexthop nexthop-ip-address
The next-hop IP address in the scenario where load balancing is enabled is configured on
the initiator of the LSP ping test.
NOTE
The next-hop IP address can be configured only when lsp-type is IPv4 and lsp-version is RFC
4379.
l Run lsp-replymode { no-reply | udp }
The response mode of the LSP Ping test is set.
NOTE
In a uni-directional LSP Ping test, if the lsp-replymode no-reply command is configured, the test
result displays that the test fails regardless of whether the test is successful or fails. If the test is
successful, the test result also displays the number of the timeout packets. If the test fails, the test
result displays the number of the discarded packets.
l Run lsp-exp exp
The LSP EXP value is set.
l Run timeout time
l Run ttl number
The TTL value is set.
l Run datasize size
The packet size is set.
l Run
probe-failtimes times

The number of permitted maximum probe failures, (the threshold to trigger the trap
message) is set.
l Run test-failtimes times
The trap threshold for continuous probe failures is set.
The failure percentage is set.
By default, the failure percentage is 100%, that is, the test is regarded failed only when
all the probes fail.
By default, test packets are sent at an interval of 4 seconds.
----End
7.9.15 Configuring the LSP Trace Test
Context
The NQA LSP Trace test can be used to test the tunnel nodes of the following types of LSPs.
l LSP tunnels
l MPLS TE tunnels
l MPLS CR-LSP hotstandby tunnels
NOTE
The AR100&AR120&AR150&AR160&AR200 does not support the LSP trace test.

Procedure

An NQA test instance is created and the test instance view is displayed.
Step 3 Run test-type lsptrace
The test type is set to LSP Trace.
Step 4 Configure the LSP trace test based on the LSP type.
l Configure the LSP trace test for the LSP tunnel.
– Run lsp-type ipv4
The tunnel type is set to be the LSP tunnel.
– Run destination-address ipv4 ipv4-address [ lsp-masklen masklen [ lsp-loopback
loopback-address ] [ vpn-frr-path ] | lsp-loopback loopback-address [ lsp-
masklen masklen ] [ vpn-frr-path ] | vpn-frr-path ]
The destination IP address to be tested is configured.
l Configure the LSP trace test for the MPLS TE tunnel.
– Run lsp-type te
– Run lsp-tetunnel tunnel interface-number
The TE tunnel interface to be tested is configured.
l Configure the LSP trace test for the CR-LSP hotstandby tunnel.
– Run lsp-type te
– Run lsp-tetunnel tunnel interface-number hot-standby
The TE tunnel interface to be tracerouted is specified and the CR-LSP hotstandby
tunnel is set to be tested.
l Configure the LSP ping test for the CR-LSP primary tunnel.
– Run lsp-type te
– Run lsp-tetunnel tunnel interface-number primary
The TE tunnel interface to be pinged is specified and the CR-LSP primary tunnel is
set to be tested.
Step 5 (Optional) Perform the following as required to configure other parameters for the LSP Trace
test:
l Run lsp-version { rfc4379 | draft6 }
A protocol used by the LSP Trace test is configured.
l Run lsp-nexthop nexthop-ip-address
The next-hop IP address in the scenario where load balancing is enabled is configured on
the initiator of the LSP Trace test.
NOTE
The next-hop IP address can be configured only when lsp-type is IPv4 and lsp-version is RFC
4379.
l Run lsp-replymode { no-reply | udp }
The response mode of the LSP trace test is set.

NOTE
In a uni-directional LSP Trace test, if the lsp-replymode no-reply command is configured, the test
result displays that the test fails regardless of whether the test is successful or fails. If the test is
successful, the test result also displays the number of the timeout packets. If the test fails, the test
result displays the number of the discarded packets.
l Run lsp-exp exp
The LSP EXP value is set.
l Run tracert-hopfailtimes times
The number of hops after which the test is considered failed is set.
l Run tracert-livetime first-ttl first-ttl max-ttl max-ttl
The initial and the maximum TTL values of the packet are set.
l Run timeout time
l Run
probe-failtimes times
The number of permitted maximum probe failures, (the threshold to trigger the trap
message) is set.
l Run test-failtimes times
The trap threshold for continuous probe failures is set.
----End
Prerequisites
After completing NQA configuration, run the following commands to check the NQA
configuration.

Procedure
l Run the display nqa application command on the NQA client to check the type of the
NQA test instance for a service.
l Run the display nqa-parameter command in the NQA view on the NQA client to check
parameters configured for the current NQA test instance.
l Run the display nqa support-server-type command on the NQA client to check the
server types supported by NQA.
l Run the display nqa support-test-type command on the NQA client to check the test
instance types supported by NQA.
l Run the display nqa-agent command on the NQA client to check the status and
configuration of the NQA client.
l Run the display nqa-server command on the NQA server to check information about
the server.
l Run the display nqa-server session command on the NQA server to check NQA client
information on the NQA server.
----End
7.10 Configuring the NQA Transmission Delay Threshold

and Alarm Threshold
The statistics about the test packets that exceed the threshold are displayed in the NQA test
result. This provides a basis for the network administrators to analyze the operating status of
the specified service. The alarm information is sent to the NMS to report the change to the
device.
Before configuring the NQA transmission threshold and alarm function, complete the
following tasks:
l Ensure that the device is running properly.

l Create the NQA test instance and configuring related parameters.
The configured NQA transmission threshold and alarm threshold help you obtain the statistics
about the test packet that exceed the thresholds in the test result. This improves the NQA
function and provides an optional configuration for NQA test.
The alarm information can be sent to the NMS only when the routes between the device and
NMS are reachable and the related configurations are completed.
Perform the following configurations on the NQA client:
7.10.1 Configuring the Two-Way Transmission Delay Threshold

Context
If the two-way transmission delay threshold is configured for an NQA test instance, the
statistics about the test packets that exceed the threshold are displayed in the test result. This
provides a basis for the network administrators to analyze the operating status of the specified
service.
NOTE
This two-way transmission delay refers to the round-trip transmission delay.
Procedure
The NQA view is displayed.
Step 3 Run threshold rtd rtd-value
The two-way transmission delay threshold is configured.
By default, no two-way transmission delay threshold is configured.
----End
7.10.2 Configuring the One-Way Transmission Delay Threshold
Context
In Jitter tests , after the one-way transmission delay threshold is configured, the test results
show statistics about the test packets of which the transmission exceeds the threshold.
Network administrators can analyze the operating status of the network according to the test
results.
NOTE
The one-way transmission delay threshold can be configured only when the test-type is set to jitter.
You can perform either of Step 3 and Step 4 or both of them in any sequence.
Procedure
Step 3 Run threshold owd-sd owd-sd-value
The one-way transmission delay threshold (from the source to the destination) is configured.
By default, no one-way transmission delay threshold is configured.

Step 4 Run threshold owd-ds owd-ds-value

The one-way transmission delay threshold (from the destination to the source) is configured.
By default, no one-way transmission threshold is configured.
----End
7.10.3 Configuring Alarm Thresholds
Context
Configure alarm thresholds to monitor the network. After monitoring conditions are
configured, the device sends alarms to the NMS when the monitored item in the test result
exceeds the configured upper or lower threshold. The alarms enable you to monitor the real-
time operating status of the network.
You can also configure an action for the system to perform when a monitored item exceeds
the threshold. The system can record a log, generate an alarm, or performs both depending on
the configuration.
Procedure
Step 2 Run nqa event event-entry { log | trap | log-trap | linkage admin-name test-name | none }
[ description ]
An event is associated with the NQA alarm.
By default, no event is associated with the NQA alarm.
Step 4 Run alarm entry-number { jitter-average | jitter-ds-average | jitter-sd-average | lost-
packet-ratio | packet-loss-ds | packet-loss-sd | rtt-average } { absolute | delta } { falling-
threshold threshold-value1 event-entry1 | rising-threshold threshold-value2 event-entry2 } *
[ description description ]
The thresholds for triggering alarms for the associated events are configured.
By default, no threshold for triggering alarms is set.
NOTE
l Parameters jitter-average, jitter-ds-average, jitter-sd-average, packet-loss-ds, and packet-loss-sd

can be configured only for jitter test instances.
l At present, the device supports only the absolute statistics function but not the relative statistics
function.
----End

Prerequisites
The NQA upper and lower alarm thresholds have been configured.
Procedure
l Run the display nqa-event command to check the maximum number of events that can
be configured and the number of events that have been configured.
l Run the display nqa event command to check the events associated with the NQA
alarm.
l Run the display nqa alarm command to check alarms of the NQA test instance.
l Run the display nqa-agent [ admin-name test-name ] [ verbose ] command to check the
status and configuration of the test instance configured on the NQA client.
l Run the display nqa-alarm command in the NQA view to check the maximum number
of alarms and current alarms of an NQA test instance.
----End
7.11 Configuring the Trap Function
Context
A device generates traps no matter whether a NQA test succeeds or fails. NQA supports three
types of traps as defined in DISMAN-PING-MIB. NQA also supports the sending of traps to
the NMS when the one-way or two-way transmission delay exceeds the threshold.
l For all test instances, if the two-way transmission delay exceeds the threshold and the
trap function is enabled, traps are sent to the NMS with the specified IP address.
l During a jitter test, if the one-way delay from the source to the destination or from the
destination to the source exceeds the threshold and the trap function is enabled, the NQA
client sends a trap message to the specified NMS IP address.
Traps carry the following information: destination IP addresses, operating status, destination
IP address of the test packet, minimum RTT, maximum RTT, total RTT, number of sent probe
packets, number of received packets, RTT square sum, and time of the latest successful probe.
Before configuring the trap function of the NQA test, complete the following tasks:
l Configure reachable routes between the NQA client and the NMS.
l Create the NQA test instance and configure related parameters.
The following optional configuration tasks are performed on the NQA client.
These configurations take effect only after the NQA alarm function is enabled.
7.11.1 Enabling the NQA Alarm Function

Context
After the NQA alarm function is enabled, the device sends alarms to the NMS.
Procedure
Step 2 Run snmp-agent trap enable feature-name nqa [ trap-name { nqaresultsprobefailed |

nqahttpstatsprobefailed | pingprobefailed | nqaftpstatsprobefailed | pingtestfailed |
pingtestcompleted | traceroutetestfailed | traceroutetestcompleted | nqaresultstestfailed |
nqaresultstestcompleted | nqaresultsthresholdnotification | nqahttpstatstestfailed |
nqahttpstatstestcompleted | nqahttpstatsthresholdnotification | nqaftpstatstestfailed |
nqaftpstatstestcompleted | nqaftpstatsthresholdnotification | nqajitterstatstestfailed |
nqajitterstatstestcompleted | nqajitterstatsrtdthresholdnotification |
nqajitterstatsowdthresholdnotificationsd | nqajitterstatsowdthresholdnotificationds |
nqarisingalarmnotification | nqafaillingalarmnotification | nqaftpsaverecordnotification |
nqajitterstatsjitterthresholdnotificationsd | nqajitterstatsjitterthresholdnotificationds |
nqareflectorstatechangenotification | nqaResultsTestResultChange } ]
The alarm function is enabled for the NQA module.
By default, the alarm function is enabled for the NQA module.
----End
7.11.2 Configuring the NQA Client to Send Traps When a Test

Fails
Procedure
Step 3 Run send-trap testfailure
The NQA client is configured to send traps when the test fails.
By default, the NQA client sends no trap when an NQA test fails.
Step 4 Run test-failtimes times
The threshold on the traps sent after the NQA test fails is configured, The threshold specifies
maximum number of continuous test failures for the NQA test instance.
By default, a trap is sent for each test failure.
----End

7.11.3 Configuring the NQA Client to Send Traps When a Probe

Fails
Procedure
Step 3 Run send-trap probefailure
The NQA client is configured to send traps when a probe fails.
By default, the NQA client sends no trap when a probe fails.
Step 4 Run probe-failtimes times
The threshold on the traps sent after the probe fails is configured, The threshold specifies
maximum number of continuous probe failures for the NQA test instance.
By default, a trap is sent for each probe failure.
----End
7.11.4 Configuring Trap Sending Upon Probe Result Changes
Context
If this function is not configured, a device sends a trap to the NMS server every time a probe
is finished. Frequently receiving traps will affect performance of the NMS server. After this
function is configured, a device sends a trap to the NMS server only when the probe result
changes.
NOTE
This function supports only ICMP test instances.
Procedure
Step 1 Run:
system-view

Step 2 Run:
nqa test-instance admin-name test-name
The NQA test instance view is displayed.

Step 3 Run:
send-trap testresult-change
The device is configured to send a trap only when the probe result changes.

By default, a device sends a trap every time a probe is finished.
----End
7.11.5 Configuring the NQA Client to Send Traps After a Probe

Succeeds
Procedure
Step 3 Run send-trap testcomplete
The NQA client is configured to send traps when a probe succeeds.
By default, the NQA client sends no trap when a probe succeeds.
----End
7.11.6 Configuring the NQA Client to Send Traps When the

Transmission Delay Exceeds the Threshold
Procedure
Step 3 Run send-trap { owd-ds | owd-sd | rtd }*
The NQA client is configured to send traps when the transmission delay exceeds the
threshold.
By default, the NQA client sends no trap when the transmission delay exceeds the threshold.
NOTE
Parameters owd-ds and owd-sd can be configured only for jitter test instances.
----End
Context
After configuring the trap function, check the alarm information.

Procedure
l Run the display snmp-agent trap feature-name nqa all command to check status of all
traps on the NQA module.
l Run the display nqa-parameter command in the NQA view to check parameters
configured for the current test instance.
l Run the display nqa-agent command to check the configurations of test instances on the
NQA client.
----End
7.12 Configuring the NQA Client to Send Test Results to

an FTP Server
Context
If you want to save NQA test results, configure the NQA client to send test results to an FTP
server.
By default, the system saves the latest five test results. When new test results are generated,
the new ones overwrite the earliest ones. If the NMS does not obtain the test results in a
timely manner, test results will be lost. You can configure the NQA client to send the test
results to the FTP server when the number of test results saved on the local device reaches the
maximum value. This prevents the loss of test results and allows network administrators to
analyze the test results obtained at different time.
Before configuring the NQA client to send test results to an FTP server, complete the
following tasks:
l Configure the FTP server.

l Configure reachable routes between the NQA client and the NMS.
l Configure a test instance.
NOTE
It is recommended that you use the FTP protocol in the secure network environment.
7.12.1 Configuring Parameters for Connecting to an FTP Server
Context
Before connecting to an FTP server, specify the FTP server address used to receive NQA test
results, configure a user name and password used for logging into the FTP server, and the
name of file used to save NQA test results.

Procedure
Step 2 Use either of the following methods to configure the IP address of the FTP server:
l On an IP network, run the nqa-ftp-record ip-address ip-address command to configure
the IP address of the FTP server.
l On a VPN network, run the nqa-ftp-record vpn-instance vpn-instance command to
configure the VPN instance name of the FTP server.
Step 3 (Optional) Run nqa-ftp-record source-address ip-address
The FTP client address is configured.
By default, the address of the FTP client from which NQA test results are uploaded to the
FTP server is not configured.
To specify the address of the FTP client from which NQA test results are uploaded to the FTP
server in a scenario that has client address restrictions, run the nqa-ftp-record source-
address command.
Step 4 Run nqa-ftp-record username username
The user name used for logging into the FTP server is configured. The user name is used
when test results are saved on the FTP server.
Step 5 Run nqa-ftp-record password { password | cipher cipher-password }
The password used for logging in to the FTP server is configured. The password is used when
test results are saved on the FTP server.
Step 6 Run nqa-ftp-record filename filename
The name of the file used to save NQA test results is configured.
----End
7.12.2 Enabling the Function of Saving NQA Test Results

Through FTP
Context
The NQA client sends test results to an FTP server only after the function of saving NQA
result through FTP is enabled.
NOTE
Before configuring the NQA client to send test results to the FTP server through FTP, configure
parameters for the FTP connection.
Procedure

Step 2 Run nqa-ftp-record enable
The function of sending test results to the FTP server through FTP is enabled.
By default, the function of sending test results to the FTP server through FTP is disabled.
----End
7.12.3 (Optional) Configuring File Parameters for Saving Test

Results Through FTP
Context
NQA test results can be sent to the specified FTP server and saved in text files. The system
will generate a new text file with a continuous sequence number to save the subsequent test
results: when either of the following parameters exceeds the specified value:
l Number of test results saved in the file on the FTP server
l Time period for saving test results to the file on the FTP server.
Procedure
Step 2 Run nqa-ftp-record item-num item-number
The number of test results saved to the file on the FTP server is configured.
By default, up to 100000 NQA test results can be stored in a file.
Step 3 Run nqa-ftp-record time time
The time period for saving test results to the file on the FTP server is configured.
By default, the time period is 60 minutes.
Step 4 (Optional) Run nqa upload statistics datetime-type { utc | local }
The type of the time based on which FTP test results are saved to a file through FTP is
configured.
The default time type based on which NQA test results are uploaded to the server is
Coordinated Universal Time (UTC).
UTC is the default time type based on which NQA test results are uploaded to the server. This
time type causes difficulties in time understanding. Therefore, changing the time type to local
is recommended.
----End
7.12.4 (Optional) Enabling the NQA Client to Send Traps to the

NMS After Test Results Are Sent to the FTP

Context
When an FTP server is used to save NQA test results, the NQA client sends test results to the
specified FTP server through FTP. After test results are sent to the FTP server, the NQA client
sends a trap to the NMS if it is configured to do so.
Procedure
Step 2 Run nqa-ftp-record trap-enable
The NQA client is configured to send a trap to the NMS after NAQ test results are
successfully sent to the FTP server.
By default, the NQA client sends no trap when NQA test results are successfully sent to the
FTP server.
NOTE
l The NQA client generates no trap when transfer of test results succeeds for the first time. It generates a
trap for every successful transfer since the second successful transfer.
l The NQA client generates a trap only when a text file is completely transferred. That is, the NQA client
generates an alarm only after the number of test results in the file or the interval reaches the configured
value and the file saving is finished.
----End
Prerequisites
The NQA client has been configured to send test results to an FTP server.
Procedure
l Run the display nqa-ftp-record configuration command to check the configuration of
saving NQA test results through FTP.
----End
7.13 Scheduling an NQA Test Instance

After completing the configuration of an NQA test instance, you can schedule the NQA test
instance, for example, starting the NQA test instance.
Before scheduling an NQA test instance, complete the following tasks:
l Configure the server.
l Configure an NQA test instance on the client.

l Configure reachable routes between the server and the client.

NOTE
7.13.1 Starting an NQA Test Instance
Context
After completing the configuration of an NQA test instance, start the NQA test instance in
following modes:
l Start the NQA test instance immediately.
l Start the NQA test instance at a specified time.
l Start the NQA test instance after a delay.
If the test fails, restart the NQA test instance in the next time period.
NOTE
l If the number of running test instances reaches the maximum value defined by the system, the start
command is invalid.
l For the same test instance, the start now command can be used again only when the previous test is
complete.
l The specified time to start a test instance must be later than the current time of the device.
Procedure
l Start an NQA test instance.
a. Run system-view
c. Run start
The NQA test instance is started.
n Run start now [ end { at [ yyyy/mm/dd ] hh:mm:ss | delay { seconds second |
hh:mm:ss } | lifetime { seconds second | hh:mm:ss } } ]
The NQA test instance is started immediately.
n Run start at [ yyyy/mm/dd ] hh:mm:ss [ end { at [ yyyy/mm/dd ] hh:mm:ss |
delay { seconds second | hh:mm:ss } | lifetime { seconds second |
hh:mm:ss } } ]
The NQA test instance is started in a specified time.
n Run start delay { seconds second | hh:mm:ss } [ end { at [ yyyy/mm/dd ]
hh:mm:ss | delay { seconds second | hh:mm:ss } | lifetime { seconds second |
hh:mm:ss } } ]
The NQA test instance is started after a specified delay.
l Restart an NQA test instance.
a. Run system-view



c. Run restart
Then NQA test instance is restarted.
n The restart command stops the running test instance and restart it.
n The restart command functions the same as the start now command.
----End
7.13.2 (Optional) Stopping an NQA Test Instance
Context
A running NQA test instance can stop in the following modes:
l The test stops automatically after all test packets are sent.
l Stop the NQA test instance at a specified time.
l Stop the NQA test instance after a delay.
Stop a running NQA test instance using either of the following commands:
l Run the undo start command to stop the running NQA test instance.
l Run the stop command to stop the running NQA test instance.
Procedure
l Run the undo start command.
a. Run system-view


c. Run undo start
The running NQA test instance is stopped.

l Run the stop command.
a. Run system-view


c. Run stop
The running NQA test instance is stopped.
----End

7.13.3 Checking Test Results
Prerequisites
An NQA test instance has been configured and the NQA test has been completed.
NOTE
l If the display command is executed in the NQA view with no test instance name specified, only the
test results of the current instance are displayed. If the display command is executed in the system or
other views other than the NQA view with no test instance view specified, test results of all test
instances are displayed. If a test instance is specified, only the test result of this test instance is
displayed.
l The display nqa results command displays the test results of only the test instances that have been
completed.
l The display nqa results collection command displays accumulative results of all test instances.
Only the jitter tests support the query of accumulative results.
l Failed Jitter tests are not recorded in the historical records.
Procedure
l Run the display nqa results [ collection | success | failed ] [ test-instance admin-name
test-name ] command to check NQA test results.
l Run the display nqa history [ test-instance admin-name test-name ] [ from start-date
start-time to end-date end-time ] command to check the historical records of NQA test
instances.
----End
7.14 Clearing NQA Test Statistics
Context
To obtain the latest test results, clear the current test results by running the following
commands.
l Statistics cannot be restored after being cleared. Confirm the action before you run the
commands.
l Statistics on the running test instance cannot be cleared.
Procedure

Step 3 Run clear-records

The statistics about NQA test instances are cleared.
Step 4 Run return
Return to the user view.
Step 5 Run reset ip nqa-compatible responder statisticsThe statistics on the NQA handshake
packets sent from the third-party device or NMS software are cleared.
----End
7.15 Configuration Examples for NQA
7.15.1 Example for Configuring a DHCP Test Instance
In Figure 7-17, RouterB functions as a DHCP server. RouterA functions as the DHCP client
to test the time it takes to obtain an IP address from the DHCP server.
Figure 7-17 Networking diagram for configuring a DHCP test instance

RouterA RouterB
GE1/0/0 GE1/0/0
10.1.1.3/24 10.1.1.2/24
NQA Client DHCP Server
1. Configure RouterB as the DHCP server and configure the related functions. (see the
configuration file.)
2. Configure RouterA as an DHCP client.
3. Create and start the DHCP test on the RouterA to check whether a connection can be set
up between the Router and the DHCP server and whether an IP address can be assigned.
Procedure
Step 1 Configure the DHCP client on RouterA.
[RouterA] interface gigabitethernet 1/0/0
[RouterA-GigabitEthernet1/0/0] ip address 10.1.1.3 24
[RouterA-GigabitEthernet1/0/0] quit
Step 2 Configure a DHCP test instance on RouterA.

[RouterA] nqa test-instance admin dhcp
[RouterA-nqa-admin-dhcp] test-type dhcp
[RouterA-nqa-admin-dhcp] source-interface gigabitethernet 1/0/0
[RouterA-nqa-admin-dhcp] timeout 20

Step 3 Start the test instance.

[RouterA-nqa-admin-dhcp] start now
Step 4 Check the configuration.

[RouterA-nqa-admin-dhcp] display nqa results test-instance admin dhcp
NQA entry£¨admin, dhcp£© :testflag is inactive ,testtype is dhcp
1 . Test 1 result The test is finished
Send operation times: 3 Receive response times: 3
Completion:success RTD OverThresholds number: 0
Attempts number:1 Drop operation number:0
Disconnect operation number:0 Operation timeout number:0
System busy operation number:0 Connection fail number:0
Operation sequence errors number:0 RTT Stats errors number:0
Destination ip address:10.1.1.2
Min/Max/Average Completion Time: 1018/1019/1018
Sum/Square-Sum Completion Time: 3055/3111009
Last Good Probe Time: 2012-7-11 9:26:38.5
Lost packet ratio: 0 %
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.3 255.255.255.0
#
nqa test-instance admin dhcp
test-type dhcp
timeout 20
source-interface GigabitEthernet1/0/0
#
return

#
sysname RouterB
#
dhcp enable
#
ip pool 1
gateway-list 10.1.1.1
network 10.1.1.0 mask 255.255.255.0
#
ip address 10.1.1.2 255.255.255.0
dhcp select global
#
return
7.15.2 Example for Configuring a DNS Test Instance
In Figure 7-18, RouterA functions as a DNS client to access the host 10.2.1.1/24, using a
domain name server.com.

Figure 7-18 Networking diagram for configuring a DNS test instance

server.com
10.2.1.1/24
RouterA
GE1/0/0
IP Network
10.1.1.1/24
DNS Server
10.3.1.1/24
1. Configure RouterA as an NQA client.
2. Create and start a DNS test instance on the RouterA to check whether RouterA can set
up a connection with the DNS server and to obtain the speed of responding to an address
resolution request.
Procedure
Step 1 Configure IP addresses for the interfaces on the RouterA and ensure reachable routes between
RouterA and server.com, RouterA and the DNS server.
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
Step 2 Configure an NQA DNS test instance.

<RouterA> system-view
[RouterA] dns resolve
[RouterA] dns server 10.3.1.1
[RouterA] nqa test-instanc admin dns
[RouterA-nqa-admin-dns] test-type dns
[RouterA-nqa-admin-dns] dns-server ipv4 10.3.1.1
[RouterA-nqa-admin-dns] destination-address url server.com

[RouterA-nqa-admin-dns] start now

[RouterA-nqa-admin-dns] display nqa results test-instance admin dns
NQA entry(admin, dns) :testflag is inactive ,testtype is dns
Operation sequence errors number:0 RTT Status errors number:0
Destination ip address: 10.3.1.1


----End
Configuration Files
RouterA configuration file
#
sysname RouterA
#
dns resolve
dns server 10.3.1.1
#
ip address 10.1.1.1 255.255.255.0
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
#
nqa test-instance admin dns
test-type dns
destination-address url server.com
dns-server ipv4 10.3.1.1
#
return
7.15.3 Example for Configuring an FTP Download Test Instance
In Figure 7-19, the performance of the FTP download function needs to be checked.
Figure 7-19 Networking diagram for configuring an FTP download test instance
RouterA RouterB
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24

2. Configure RouterB as the FTP server. Log in to the FTP server using user name user1
and password Helloworld@6789 to download file test.txt.
3. Create and start an FTP test instance on RouterA to check whether RouterA can set up a
connection with the FTP server and to obtain duration for downloading the file from the
FTP server.

Procedure
Step 1 Configure RouterB.
# Configure an IP address for RouterB.
[RouterB] interface gigabitethernet 1/0/0
[RouterB-GigabitEthernet1/0/0] ip address 10.1.1.2 24
[RouterB-GigabitEthernet1/0/0] quit
Configure RouterB as the FTP server.

[RouterB] ftp server enable
[RouterB] aaa
[RouterB-aaa] local-user user1 password irreversible-cipher Helloworld@6789
[RouterB-aaa] local-user user1 privilege level 15
[RouterB-aaa] local-user user1 service-type ftp
[RouterB-aaa] local-user user1 ftp-directory flash:/
[RouterB-aaa] quit
Step 2 Configure RouterA.

# Configure an IP address for RouterA.
# Create an NQA FTP test instance on RouterA.

[RouterA] nqa test-instance admin ftp
[RouterA-nqa-admin-ftp] test-type ftp
[RouterA-nqa-admin-ftp] destination-address ipv4 10.1.1.2
[RouterA-nqa-admin-ftp] source-address ipv4 10.1.1.1
[RouterA-nqa-admin-ftp] ftp-operation get
[RouterA-nqa-admin-ftp] ftp-username user1
[RouterA-nqa-admin-ftp] ftp-password Helloword@6789
[RouterA-nqa-admin-ftp] ftp-filename test.txt

[RouterA-nqa-admin-ftp] start now

[RouterA-nqa-admin-ftp] display nqa results test-instance admin ftp
NQA entry(admin, ftp) :testflag is inactive ,testtype is ftp
SendProbe:1 ResponseProb:1
Completion :success RTD OverThresholds number: 0
MessageBodyOctetsSum: 448 Stats errors number: 0
Operation timeout number: 0 System busy operation number:0
Drop operation number:0 Disconnect operation number: 0
CtrlConnTime Min/Max/Average: 438/438/438
DataConnTime Min/Max/Average: 218/218/218
SumTime Min/Max/Average: 656/656/656
Average RTT:656
Lost packet ratio:0 %
----End
Configuration Files

#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
nqa test-instance admin ftp
test-type ftp
destination-address ipv4 10.1.1.2
source-address ipv4 10.1.1.1
ftp-username user1
ftp-password cipher %^%#}X~*(Tn2C,qJ`SVy3t';Ii,`%^%#
ftp-filename test.txt
#
return

#
sysname RouterB
#
aaa
local-user user1 password irreversible-cipher %^%#HW=5%Mr;:2)/RX$FnU1HLO%-
TBMp4wn%;~\#%iAut}_~O%0L%^%#
local-user user1 privilege level 15
local-user user1 ftp-directory flash:/
local-user user1 service-type ftp
#
ip address 10.1.1.2 255.255.255.0
#
ftp server enable
#
return
7.15.4 Example for Configuring an FTP Upload Test Instance
In Figure 7-20, the speed of uploading a file from RouterA to an FTP server needs to be
tested.
Figure 7-20 Networking diagram for configuring an FTP upload test instance
RouterA RouterB
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24
1. Configure Router A as an NQA client as well as an FTP client. Create and start an FTP
test instance on RouterA to check whether RouterA can set up a connection with the FTP
server and to obtain the time taken by RouterA to upload a file to the FTP server.
2. A user named user1 logs in to the FTP server by entering the password
Helloword@6789 to upload a file with the size being 10 KB.

Procedure
Step 1 Configure RouterB.
# Configure an IP address for RouterB.
# Configure RouterB as the FTP server.

[RouterB] ftp server enable
[RouterB] aaa
[RouterB-aaa] local-user user1 password irreversible-cipher Helloword@6789
[RouterB-aaa] local-user user1 service-type ftp
[RouterB-aaa] local-user user1 ftp-directory flash:/
[RouterB-aaa] quit

# Configure an IP address for RouterA.
# Create an NQA FTP test on RouterA and create a file of 10 KB for uploading.
[RouterA] nqa test-instance admin ftp
[RouterA-nqa-admin-ftp] test-type ftp
[RouterA-nqa-admin-ftp] destination-address ipv4 10.1.1.2
[RouterA-nqa-admin-ftp] source-address ipv4 10.1.1.1
[RouterA-nqa-admin-ftp] ftp-operation put
[RouterA-nqa-admin-ftp] ftp-username user1
[RouterA-nqa-admin-ftp] ftp-password Helloword@6789
[RouterA-nqa-admin-ftp] ftp-filesize 10

[RouterA-nqa-admin-ftp] start now

# Check NQA test results on RouterA.
[RouterA-nqa-admin-ftp] display nqa results test-instance admin ftp
NQA entry(admin, ftp) :testflag is inactive ,testtype is ftp
SendProbe:1 ResponseProb:1
Completion :success RTD OverThresholds number: 0
MessageBodyOctetsSum: 10240 Stats errors number: 0
Operation timeout number: 0 System busy operation number:0
Drop operation number:0 Disconnect operation number: 0
CtrlConnTime Min/Max/Average: 657/657/657
DataConnTime Min/Max/Average: 500/500/500
SumTime Min/Max/Average: 1157/1157/1157
Average RTT:656
Lost packet ratio:0 %
# On RouterB, you can view that a file named nqa-ftp-test.txt is added. Part of the file on the
RouterB is displayed.
<RouterB> dir
Directory of flash:/
0 -rw- 331 Jul 06 2007 18:34:34 private-data.txt

1 -rw- 10,240 Jul 06 2007 18:37:06 nqa-ftp-test.txt

2,540 KB total (1,536 KB free)
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
nqa test-instance admin ftp
test-type ftp
source-address ipv4 10.1.1.1
ftp-filesize 10
ftp-username user1
ftp-password cipher %^%#}X~*(Tn2C,qJ`SVy3t';Ii,`%^%#
ftp-operation put
#
return

#
sysname RouterB
#
aaa
local-user user1 password irreversible-cipher %^%#6W-mT:ZGe)0B*rMm,@#
$LEyI;m_bQibe=46k.,#x$vk0EyLL%^%#
local-user user1 privilege level 15
local-user user1 ftp-directory flash:/
local-user user1 service-type ftp
#
ip address 10.1.1.2 255.255.255.0
#
ftp server enable
#
return
7.15.5 Example for Configuring an HTTP Test Instance
In Figure 7-21, RouterA is connected to the HTTP server over a WAN to test the speed of
RouterA accessing the HTTP server.
Figure 7-21 Networking diagram for configuring an HTTP test instance

HTTP Server
10.2.1.1/24
Router A
IP Network
GE1/0/0
10.1.1.1/24

2. Create and start an HTTP test instance on the RouterA to check whether RouterA can set
up a connection with the HTTP server and to check the duration for transferring files
between RouterA and the HTTP server.
Procedure
Step 1 Configure IP addresses for the interfaces on the RouterA and ensure reachable routes between
RouterA and the HTTP server.
[RouterA] ospf
[RouterA-ospf-1] area 0
[RouterA-ospf-1-area-0.0.0.0] network 10.1.1.0 0.0.0.255
[RouterA-ospf-1-area-0.0.0.0] quit
[RouterA-ospf-1] quit
Step 2 Enable the NQA client and create an NQA HTTP test instance.
[RouterA] nqa test-instance admin http
[RouterA-nqa-admin-http] test-type http
[RouterA-nqa-admin-http] destination-address ipv4 10.2.1.1
[RouterA-nqa-admin-http] http-operation get
[RouterA-nqa-admin-http] http-url http://www.example.com
NOTE
The URL used to test HTTP must be a valid URL that can be displayed on the browser. In this example, the
URL is http://www.example.com.

[RouterA-nqa-admin-http] start now

[RouterA-nqa-admin-http] display nqa results test-instance admin http
NQA entry(admin, http) :testflag is inactive ,testtype is http
SendProbe:3 ResponseProbe:3
Completion:success RTD OverThresholdsnumber: 0
MessageBodyOctetsSum: 411 TargetAddress: 10.2.1.1
DNSQueryError number: 0 HTTPError number: 0
TcpConnError number : 0 System busy operation number:0
DNSRTT Sum/Min/Max:0/0/0 TCPConnectRTT Sum/Min/Max: 4/1/2
TransactionRTT Sum/Min/Max: 3/1/1
RTT Sum/Min/Max/Avg: 7/2/3/2
DNSServerTimeout:0 TCPConnectTimeout:0 TransactionTimeout: 0
Lost packet ratio:0%
----End
Configuration Files
#
sysname RouterA
#

ip address 10.1.1.1 255.255.255.0

#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
#
nqa test-instance admin http
test-type http
http-url http://www.example.com
#
return
7.15.6 Example for Configuring an ICMP Test Instance
In Figure 7-22, RouterA functions as an NQA client to test whether RouterB is reachable.
Figure 7-22 Networking diagram for configuring an ICMP test instance

RouterA RouterB
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24
NQA Client
1. Perform the NQA ICMP test function to test whether the packet sent by RouterA can
reach RouterB.
2. Perform the NQA ICMP test to obtain the RTT of the packet.
Procedure
Step 1 # Configure an IP address for RouterA.
Step 2 # Configure an IP address for RouterB.

Step 3 Enable the NQA client and create an NQA ICMP test instance.
[RouterA] nqa test-instance admin icmp
[RouterA-nqa-admin-icmp] test-type icmp
[RouterA-nqa-admin-icmp] destination-address ipv4 10.1.1.2

[RouterA-nqa-admin-icmp] start now

[RouterA-nqa-admin-icmp] display nqa results test-instance admin icmp

NQA entry(admin, icmp) :testflag is inactive ,testtype is icmp

----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
nqa test-instance admin icmp
test-type icmp
#
return

#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
return
7.15.7 Example for Configuring an ICMP Jitter Test
In Figure 7-23, RouterA is the NQA client. Test the jitter on the network between RouterA
and RouterB.
Figure 7-23 Networking diagram for configuring the ICMP Jitter test
RouterA RouterB
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24
NQA Client
Configure RouterA as the NQA client and create an ICMP Jitter test instance on RouterA.

Procedure
Step 1 Configure IP addresses for interfaces on RouterA.
Step 2 Configure IP addresses for interfaces on RouterB.

Step 3 Enable the NQA client and create an ICMP jitter test instance.
[RouterA] nqa test-instance admin icmpjitter
[RouterA-nqa-admin-icmpjitter] test-type icmpjitter
[RouterA-nqa-admin-icmpjitter] destination-address ipv4 10.1.1.2
Step 4 Start the ICMP jitter test.

[RouterA-nqa-admin-icmpjitter] start now
[RouterA-nqa-admin-icmpjitter] quit
Step 5 Verify the test result.

[RouterA-nqa-admin-icmpjitter] display nqa results test-instance admin icmpjitter
NQA entry(admin, icmpjitter) :testflag is inactive ,testtype is icmpjitter
Completion:success RTD OverThresholds number:0
OWD OverThresholds SD number:0 OWD OverThresholds DS number:0
Min/Max/Avg/Sum RTT:2/31/3/204 RTT Square Sum:1704
NumOfRTT:60 Drop operation number:0
System busy operation number:0 Operation timeout number:0
Min Positive SD:1 Min Positive DS:1
Max Positive SD:28 Max Positive DS:5
Positive SD Number:16 Positive DS Number:16
Positive SD Sum:50 Positive DS Sum:22
Positive SD Square Sum:828 Positive DS Square Sum:46
Min Negative SD:1 Min Negative DS:1
Max Negative SD:20 Max Negative DS:6
Negative SD Number:15 Negative DS Number:17
Negative SD Sum:50 Negative DS Sum:25
Negative SD Square Sum:520 Negative DS Square Sum:63
Min Delay SD:1 Min Delay DS:0
Avg Delay SD:1 Avg Delay DS:0
Max Delay SD:15 Max Delay DS:15
Delay SD Square Sum:372 Delay DS Square Sum:326
Packet Loss SD:0 Packet Loss DS:0
Packet Loss Unknown:0 Average of Jitter:2
Average of Jitter SD:3 Average of Jitter DS:1
Jitter out value:1.2249218 Jitter in value:0.6640373
NumberOfOWD:60 Packet Loss Ratio: 0%
OWD SD Sum:92 OWD DS Sum:52
ICPIF value: 0 MOS-CQ value: 0
TimeStamp unit: ms Packet Rewrite Number: 0
Packet Rewrite Ratio: 0% Packet Disorder Number: 0
Packet Disorder Ratio: 0% Fragment-disorder Number: 0
Fragment-disorder Ratio: 0% Jitter OverThresholds SD number:0
Jitter OverThresholds DS number:0 OverallOverThresholds number:0
Start time: 2016-05-10 15:55:44
End time: 2016-05-10 15:55:45
----End

Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
nqa test-instance admin icmpjitter
test-type icmpjitter
#
return

#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
return
7.15.8 Example for Configuring an SNMP Query Test Instance
In Figure 7-24, SNMP agent is enabled on RouterA and RouterC. An NQA SNMP query test
needs to be performed to obtain the time from when RouterA sends an SNMPv3 query packet
to when RouterA receives an Echo packet.
Figure 7-24 Networking diagram for configuring an SNMP query test instance
GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
SNMP Agent
2. Enable SNMP agent on RouterA.
3. Create and start an SNMP query test instance on RouterA.
4. Enable the SNMP agent on RouterC.
Procedure
Step 1 Configure an IP address for each interface and ensure reachable routes between Routers, as
shown in Figure 7-24.

[RouterA] ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
NOTE
For configurations of RouterB and RouterC, see the configuration files.
Step 2 Enable SNMP agent on RouterC.

<RouterC> system-view
[RouterC] snmp-agent
Step 3 Enable SNMP agent on RouterA.

[RouterA] snmp-agent
Step 4 Create an SNMP query test instance on RouterA.

[RouterA] nqa test-instance admin snmp
[RouterA-nqa-admin-snmp] test-type snmp
[RouterA-nqa-admin-snmp] destination-address ipv4 10.2.1.2

[RouterA-nqa-admin-snmp] start now

[RouterA-nqa-admin-snmp] display nqa results test-instance admin snmp
NQA entry(admin, snmp) :testflag is inactive ,testtype is snmp
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
nqa test-instance admin snmp
test-type snmp
#
return

#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#

ip address 10.2.1.1 255.255.255.0
#
return
l RouterC configuration file

#
sysname RouterC
#
ip address 10.2.1.2 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.1
#
return
7.15.9 Example for Configuring a TCP Test Instance
In Figure 7-25, an NQA TCP test needs to be performed on RouterA to obtain the duration
for setting up a TCP connection with RouterC.
Figure 7-25 Networking diagram for configuring a TCP test instance

GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
NQA Client NQA Server
1. Configure RouterA as an NQA client and configure RouterC as an NQA server.
2. Configure the monitoring port number on the NQA server and create an NQA TCP test
instance on the NQA client.
Procedure
NOTE
Step 2 Configure an NQA server on RouterC.

# Configure the IP address and port number for monitoring TCP connections on the NQA
server.

[RouterC] nqa-server tcpconnect 10.2.1.2 9000
Step 3 Configure the NQA client on RouterA.

# Enable the NQA client and create a TCP test instance.
[RouterA] nqa test-instance admin tcp
[RouterA-nqa-admin-tcp] test-type tcp
[RouterA-nqa-admin-tcp] destination-address ipv4 10.2.1.2
[RouterA-nqa-admin-tcp] destination-port 9000

[RouterA-nqa-admin-tcp] start now
Step 5 Check the configuration.

[RouterA-nqa-admin-tcp] display nqa results test-instance admin tcp
NQA entry(admin, tcp) :testflag is inactive ,testtype is tcp
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
nqa test-instance admin tcp
test-type tcp
destination-port 9000
#
return

#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.2.1.1 255.255.255.0
#
return

#
sysname RouterC

#
ip address 10.2.1.2 255.255.255.0
#
nqa-server tcpconnect 10.2.1.2 9000
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.1
#
return
7.15.10 Example for Configuring a Trace Test Instance
In Figure 7-26, a trace test needs to be performed to trace the IP address of GE1/0/0 of
RouterC on RouterA.
Figure 7-26 Networking diagram for configuring a trace test instance

GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
NQA Client
2. Create and start a trace test instance on RouterA to obtain statistics about each hop from
RouterA to RouterC.
Procedure
NOTE
Step 2 Create an NQA trace test instance on RouterA and set the destination IP address to 10.2.1.2.
[RouterA] nqa test-instance admin trace
[RouterA-nqa-admin-trace] test-type trace
[RouterA-nqa-admin-trace] destination-address ipv4 10.2.1.2

[RouterA-nqa-admin-trace] start now


[RouterA-nqa-admin-trace] display nqa results test-instance admin trace

NQA entry(admin, trace) :testflag is inactive ,testtype is trace
Completion:success Attempts number:1
Drop operation number:0
Last good path Time:2012-07-17 11:21:27.2
1 . Hop 1
RTD OverThresholds number: 0
2 . Hop 2
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
nqa test-instance admin trace
test-type trace
#
return
#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.2.1.1 255.255.255.0
#
return
#
sysname RouterC
#
icmp port-unreachable send
#
ip address 10.2.1.2 255.255.255.0
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.1
#
return

7.15.11 Example for Configuring a UDP Test Instance
In Figure 7-27, an NQA UDP test needs to be performed to obtain the RTT of a UDP packet
transmitted between RouterA and RouterC.
Figure 7-27 Networking diagram for configuring a UDP test instance

GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
2. Configure the port number monitored by the NQA server and create an NQA UDP test
instance on the NQA client.
Procedure
NOTE

# Configure the monitoring IP address and UDP port number on the NQA server.
[RouterC] nqa-server udpecho 10.2.1.2 6000
Step 3 Configure the NQA client on RouterA.

# Enable the NQA client and create a UDP test instance.
[RouterA] nqa test-instance admin udp
[RouterA-nqa-admin-udp] test-type udp
[RouterA-nqa-admin-udp] destination-address ipv4 10.2.1.2
[RouterA-nqa-admin-udp] destination-port 6000

[RouterA-nqa-admin-udp] start now

[RouterA-nqa-admin-udp] display nqa results test-instance admin udp

NQA entry(admin, udp) :testflag is inactive ,testtype is udp

----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
nqa test-instance admin udp
test-type udp
#
return

#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.2.1.1 255.255.255.0
#
return

#
sysname RouterC
#
ip address 10.2.1.2 255.255.255.0
#
nqa-server udpecho 10.2.1.2 6000
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.1
#
return
7.15.12 Example for Configuring a UDP Jitter Test Instance
In Figure 7-28, a UDP Jitter test needs to be performed to obtain the jitter time of
transmitting a packet from RouterA to RouterC.

Figure 7-28 Networking diagram for configuring a jitter test instance

GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
2. Configure the monitoring service type and port number on the NQA server.
3. Create a UDP Jitter test instance on the NQA client.
Procedure
NOTE


# Enable the NQA client and create a UDP Jitter test instance.
[RouterA] nqa test-instance admin jitter
[RouterA-nqa-admin-jitter] test-type jitter
[RouterA-nqa-admin-jitter] destination-address ipv4 10.2.1.2
[RouterA-nqa-admin-jitter] destination-port 9000

[RouterA-nqa-admin-jitter] start now

[RouterA-nqa-admin-jitter] display nqa results test-instance admin jitter
NQA entry(admin, jitter) :testflag is inactive ,testtype is jitter


----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
ip route-static 10.2.1.0 255.255.255.0 10.1.1.2
#
nqa test-instance admin jitter
test-type jitter
#
return
#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.2.1.1 255.255.255.0
#
return
#
sysname RouterC
#
ip address 10.2.1.2 255.255.255.0
#
#
ip route-static 10.1.1.0 255.255.255.0 10.2.1.1
#
return

7.15.13 Example for Configuring NQA to Check VoIP Service

Jitter
In Figure 7-29, the headquarters and its subsidiary often hold conferences through VoIP and
require that the round-trip delay is shorter than 250 ms and jitter is shorter than 20 ms. The
jitter test provided by NQA can be used to simulate VoIP services.
Figure 7-29 Networking diagram for configuring NQA to check VoIP service jitter
RouterA RouterD
GE1/0/0 GE1/0/0
Network
10.1.1.1/24 10.11.1.1/24
Headquarters Branch
1. Respectively configure RouterA and RouterD as the gateways of the headquarters and its
subsidiary and ensure reachable routes between them.
2. Configure RouterA as an NQA server and RouterD as an NQA client, and configure a
jitter test instance on RouterD.
3. Start the test instance on RouterD.
Procedure
Step 1 Configure IP addresses for RouterA and RouterD, as shown in Figure 7-29.
NOTE
For configurations of RouterD, see the configuration file.
Step 2 Configure the NQA server on RouterA.

[RouterA] nqa-server udpecho 10.1.1.1 6000
Step 3 Configure the NQA client on RouterD.

1. # Set the version number of the jitter test packets.
<RouterD> system-view
[RouterD] nqa-jitter tag-version 2
2. Create a jitter test instance and set the destination address to the IP address of RouterA.
[RouterD] nqa test-instance admin udpjitter

[RouterD-nqa-admin-udpjitter] test-type jitter

[RouterD-nqa-admin-udpjitter] destination-address ipv4 10.1.1.1
[RouterD-nqa-admin-udpjitter] destination-port 6000
3. Set the code type of the simulated VoIP service.

[RouterD-nqa-admin-udpjitter] jitter-codec g711a

[RouterD-nqa-admin-udpjitter] start now
Step 5 Verify the configuration, and you can find that the round-trip delay is shorter than 250 ms and
jitter is shorter than 20 ms.
[RouterD-nqa-admin-udpjitter] display nqa results test-instance admin udpjitter
NQA entry(admin, udpjitter) :testflag is active ,testtype is jitter
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
#
return
l RouterD configuration file

#
sysname RouterD

#
ip address 10.11.1.1 255.255.255.0
#
nqa-jitter tag-version 2
#
nqa test-instance admin udpjitter
test-type jitter
jitter-codec g711a
#
return
7.15.14 Example for Configuring a Threshold for the NQA Alarm
In Figure 7-30, RouterA functions as the client to perform the jitter test and monitor the
packet loss ratio of the test result. If the ratio exceeds the threshold, an alarm is sent to the
NMS.
Figure 7-30 Networking diagram for configuring a threshold for the NQA alarm
NM Station
10.1.2.8/24
GE2/0/0
10.1.2.1/24
GE1/0/0 GE1/0/0
10.1.1.1/24 10.1.1.20/24
RouterA RouterB
1. Configure RouterA as a client for the jitter test.

2. Configure the event corresponding to the alarm threshold on RouterA.
3. Configure the alarm threshold on Router and configure alarms to be sent to the NMS.
Procedure
shown Figure 7-30.

NOTE
For configurations of RouterB, see the configuration file.
Step 2 Configure an NQA server on RouterB.
<RouterB> system-view
[RouterB] nqa-server udpecho 10.1.1.20 9000
Step 3 Configure the event corresponding to the alarm threshold on RouterA.

[RouterA] nqa event 10 log-trap
Step 4 Configure the alarm threshold on RouterA.

[RouterA-nqa-admin-jitter] frequency 5
[RouterA-nqa-admin-jitter] alarm 10 lost-packet-ratio absolute rising-threshold
100 10 falling-threshold 10 10
[RouterA-nqa-admin-jitter] quit
Step 5 Configure alarms to be sent to the NS station on RouterA.
# Configure basic SNMP functions.

[RouterA] snmp community write Huawei@123
[RouterA] snmp sys-info version v2c
# Configure alarms to be sent to the NM station through the SNMP agent.

[RouterA] snmp-agent trap enable
[RouterA] snmp-agent target-host trap-paramsname trapnms2 v2c securityname
Huawei@123
[RouterA] snmp-agent target-host trap-hostname nsm2 address 10.1.2.8 trap-
paramsname trapnms2

[RouterA-admin-jitter] start now

<RouterA> display nqa-event
NQA event information:
------------------------------------------------------
NQA Event Max: 100 NQA Event Number: 1
------------------------------------------------------
<RouterA> display nqa alarm
NQA Alarm Information:
---------------------------------------------------------------------------
Admin-Name Operation-Tag Alarm-Entry AlarmType Event-Entry
---------------------------------------------------------------------------
admin jitter 10 Rising 10
admin jitter 10 Falling 10
<RouterA> display nqa-agent
NQA Tests Max: 256 NQA Tests Number: 1
NQA Flow Max: 256 NQA Flow Remained: 255

test-type jitter
frequency 5

alarm 10 lost-packet-ratio absolute rising-threshold 100 10 falling-threshold 10

10
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
$4BUGFe)&2YLuM/kMF!HPG5Mzz3DXe2&F%@%@
snmp-agent target-host trap-hostname nsm2 address 10.1.2.8 udp-port 162 trap-
paramsname trapnms2
snmp-agent target-host trap-paramsname trapnms2 v2c securityname %@
%@Cgx728b4X6_83/;th11:)G&Q%@%@
#
nqa event 10 log-trap
#
test-type jitter
frequency 5
alarm 10 lost-packet-ratio absolute rising-threshold 100 10 falling-
threshold 10 10
#
return

#
sysname RouterB
#
ip address 10.1.1.20 255.255.255.0
#
#
return
7.15.15 Example for Sending Trap Massages to the NMS When the
Threshold Is Exceeded
A Jitter test needs to be performed to configure a transmission delay threshold and enable the
trap function as shown in Figure 7-31. After the jitter test is complete, RouterA sends a trap
message to the NMS when the interval for transmitting the test packet from RouterA to
RouterC or from RouterC to RouterA exceeds the configured unidirectional transmission
threshold, or when the RTT of the test packet exceeds the configured two-way transmission
threshold. According to the traps received by the NMS, network administrators can easily
locate the fault.

Figure 7-31 Networking diagram for sending traps to NMS when the threshold is exceeded
NM Station
10.20.1.2/24
GE2/0/0
10.20.1.1/24 RouterB RouterC
GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0
10.1.1.1/24 10.1.1.2/24 10.30.1.1/24 10.30.1.2/24
RouterA NQA Server
NQA Client
1. Configure RouterC as the NQA server and configure the host IP address and port
number.
2. Configure RouterA as the NQA client, configure a threshold for the NQA alarm, and
enable the trap function.
3. Create a jitter test instance on RouterA.
Procedure
NOTE
Step 2 Configure the IP address and port number for monitoring UDP services on RouterC.
Step 3 Create a jitter test instance on RouterA.

Step 4 Set a threshold on RouterA.

# Configure the RTD threshold on RouterA.
[RouterA-nqa-admin-jitter] threshold rtd 20

# Configure the OWD-DS threshold on RouterA.

[RouterA-nqa-admin-jitter] threshold owd-ds 100
# Configure the OWD-SD threshold on RouterA.

[RouterA-nqa-admin-jitter] threshold owd-sd 100
Step 5 Enable the trap function on RouterA.

[RouterA-nqa-admin-jitter] send-trap owd-ds owd-sd rtd
[RouterA-nqa-admin-jitter] quit
Step 6 Configure traps to be sent to the NMS.

[RouterA] snmp-agent sys-info version v2c
[RouterA] snmp-agent community write Huawei@123
[RouterA] snmp-agent target-host trap-paramsname trapnms v2c securityname
Huawei@123
[RouterA] snmp-agent target-host trap-hostname nms address 10.20.1.2 trap-
paramsname trapnms
[RouterA] snmp-agent trap enable

[RouterA-nqa-admin-jitter] start now

<RouterA> display nqa result
NQA entry(test, jitter) :testflag is inactive ,testtype is jitter
# Check whether traps are generated in the trap buffer.

<RouterA> display trapbuffer

Trapping Buffer Configuration and contents:enabled

Allowed max buffer size: 1024
Actual buffer size: 256
Channel number: 3, Channel name: trapbuffer
Dropped messages: 0
Overwritten messages: 2550
Current messages: 256
#Jul 9 2012 07:53:29+00:00 RouterA NQA/4/RTDTHRESHOLD:OID
1.3.6.1.4.1.2011.5.25.111.6.16 NQA entry RTD over threshold. (OwnerIndex=admin,
TestName=jitter)
#Jul 9 2012 07:53:29+00:00 RouterA NQA/4/SDTHRESHOLD:OID
1.3.6.1.4.1.2011.5.25.111.6.17 NQA entry OWD-SD over threshold.
(OwnerIndex=admin, TestName=jitter)
#Jul 9 2012 07:53:29+00:00 RouterA NQA/4/DSTHRESHOLD:OID
1.3.6.1.4.1.2011.5.25.111.6.18 NQA entry OWD-DS over threshold.
(OwnerIndex=admin, TestName=jitter)
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.1 255.255.255.0
#
ip address 10.20.1.1 255.255.255.0
#
snmp-agent local-engineid 800007DB0354899874DAC9
$4BUGFe)&2YLuM/kMF!HPG5Mzz3DXe2&F%@%@
snmp-agent target-host trap-hostname nms address 10.20.1.2 udp-port 162 trap-
paramsname trapnms
snmp-agent target-host trap-paramsname trapnms v2c securityname %@
%@Cgx728b4X6_83/;th11:)G&Q%@%@
snmp-agent
#
ip route-static 10.30.1.0 255.255.255.0 10.1.1.2
#
test-type jitter
threshold rtd 20
send-trap rtd
send-trap owd-sd
send-trap owd-ds
threshold owd-sd 100
threshold owd-ds 100
#
return

#
sysname RouterB
#
ip address 10.1.1.2 255.255.255.0
#
ip address 10.30.1.1 255.255.255.0
#
return


#
sysname RouterC
#
ip address 10.30.1.2 255.255.255.0
#
#
ip route-static 10.1.1.0 255.255.255.0 10.30.1.1
#
return
7.15.16 Example for Configuring Test Results to Be Sent to the

FTP Server
In Figure 7-32, RouterA functioning as the client performs the ICMP test and send test results
to the FTP server through FTP.
Figure 7-32 Networking diagram for configuring test results to be sent to the FTP server
FTP Server
10.1.2.8/24
GE2/0/0
10.1.2.1/24
GE1/0/0 GE1/0/0
10.1.1.11/24 10.1.1.1/24
RouterA RouterB
1. Set parameters for connecting to the FTP server on RouterA, enable the FTP server to
save NQA test results through FTP, and set related parameter for saving test results.
2. Start the test instance and send test results to the FTP server.
Procedure
NOTE
For configurations of RouterB, see the configuration file.

Step 2 Set parameters for connecting to the FTP server on RouterA.

[RouterA] nqa-ftp-record ip-address 10.1.2.8
[RouterA] nqa-ftp-record source-address 10.1.2.1
[RouterA] nqa-ftp-record username ftp
[RouterA] nqa-ftp-record password ftp
[RouterA] nqa-ftp-record filename icmp
Step 3 Set the number of test results to be saved in a file through FTP.
[RouterA] nqa-ftp-record item-num 10010
Step 4 Configure the duration of saving test results through FTP.

[RouterA] nqa-ftp-record time 2
Step 5 Send an alarm to the NMS after the FTP transmission succeeds.
[RouterA] nqa-ftp-record trap-enable
Step 6 Enable the FTP server to save NQA test results through FTP on RouterA.
[RouterA] nqa-ftp-record enable
Step 7 Create an NQA ICMP test instance.

[RouterA] nqa test-instance admin icmp
[RouterA-nqa-admin-icmp] test-type icmp
[RouterA-nqa-admin-icmp] destination-address ipv4 10.1.1.1

[RouterA-admin-icmp] start now

# Display NQA test results of RouterA.
<RouterA> display nqa-ftp-record configuration
---------------NQA FTP SAVE RECORD CONFIGURATION---------------
FUNCTION: ENABLE TRAP: ENABLE
IP-ADDRESS:10.1.2.8
VPN-INSTANCE:
USERNAME:ftp
PASSWORD:
FILENAME:icmp
ITEM-NUM:10010
TIME:2
LAST FINISHED FILENAME:icmp20131214-163628.txt
----End
Configuration Files
#
sysname RouterA
#
ip address 10.1.1.11 255.255.255.0
#
ip address 10.1.2.1 255.255.255.0
#
nqa-ftp-record trap-enable
nqa-ftp-record ip-address 10.1.2.8
nqa-ftp-record source-address 10.1.2.1nqa-ftp-record username ftp
nqa-ftp-record password cipher %^%#I"q19:tK.V;^4.LaR3FRJW&*%^%#
nqa-ftp-record filename icmp
nqa-ftp-record item-num 10010
nqa-ftp-record time 2
nqa-ftp-record enable

#
nqa test-instance admin icmp
test-type icmp
#
return

#
sysname RouterB
#
ip address 10.1.1.1 255.255.255.0
#
return
7.15.17 Example for Configuring the LSP Ping Test for a Common
Tunnel
In Figure 7-33:
l The OSPF protocol runs on Router A, Router B, and Router C. The three Routers learn
the 32-bit host routes on their loopback interfaces.
l MPLS and MPLS LDP are enabled on Router A, Router B, and Router C.
l MPLS and MPLS LDP are enabled on GE interfaces connected to Router A, Router B,
and Router C to trigger the establishment of an LDP LSP.
The NQA LSP Ping test needs to be performed to check the connectivity of the LSP between
Router A and Router C.
Figure 7-33 Networking diagram for configuring the LSP Ping test
area 0
10.1.1.9/32 10.2.2.9/32 10.3.3.9/32
GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0

10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
1. Configure Router A as the NQA client.

2. Configure Router C as the NQA server.

3. Create an LSP Ping test on Router A.
Procedure
Step 1 Configure reachable routes between Router A and Router B, between Router A and Router C,
and between Router B and Router C. The configuration details are not mentioned here.
Step 2 Configure LDP on RouterA, RouterB, and RouterC. (The detailed procedure is not mentioned
here.)
For the configuration of LDP, refer to the Huawei AR Series Access Routers Configuration
Guide - MPLS.
Step 3 Configure Router A.
# Enable the NQA client and create an LSP Ping test for a common tunnel.
[RouterA] nqa test-instance admin lspping
[RouterA-nqa-admin-lspping] test-type lspping
[RouterA-nqa-admin-lspping] lsp-type ipv4
[RouterA-nqa-admin-lspping] destination-address ipv4 10.3.3.9 lsp-masklen 32
Step 4 Perform the test.

[RouterA-nqa-admin-lspping] start now

[RouterA-nqa-admin-lspping] display nqa results test-instance admin lspping
NQA entry(admin, lspping) :testflag is inactive ,testtype is lspping
----End
Configuration Files
#
sysname RouterA
#
mpls lsr-id 10.1.1.9
mpls
#
mpls ldp
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 10.1.1.9 255.255.255.255
#

ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.1.1.9 0.0.0.0
#
nqa test-instance admin lspping
test-type lspping
destination-address ipv4 10.3.3.9 lsp-masklen 32
#
return

#
sysname RouterB
#
mpls
#
mpls ldp
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls ldp
#
ip address 10.2.1.1 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 10.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
#
return

#
sysname RouterC
#
mpls
#
mpls ldp
#
ip address 10.2.1.2 255.255.255.0
mpls
mpls ldp
#
interface LoopBack1
ip address 10.3.3.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.3.3.9 0.0.0.0
network 10.2.1.0 0.0.0.255
#
return

7.15.18 Example for Configuring the LSP Trace Test for the TE
Tunnel
In Figure 7-34:
l The OSPF protocol runs on Router A, Router B, and Router C. The three Routers learn
the 32-bit host routes on their loopback interfaces.
l MPLS, MPLS TE, and MPLS RSVP-TE are enabled on Router A, Router B, and Router
C.
l MPLS, MPLS TE, and MPLS RSVP-TE are enabled on the GE interfaces connected to
Router A, Router B, and Router C to set up a TE tunnel from Router A to Router C.
The NQA LSP trace test is used to test the TE tunnel.
Figure 7-34 Networking diagram for configuring the LSP trace test
area 0

10.1.1.9/32 10.2.2.9/32 10.3.3.9/32
GE1/0/0 GE1/0/0 GE2/0/0 GE1/0/0

10.1.1.1/24 10.1.1.2/24 10.2.1.1/24 10.2.1.2/24
1. Configure Router A as the NQA client. Create an LSP trace test on Router A.
2. Configure Router C as the NQA server.
Procedure
Step 1 Configure reachable routes between Router A and Router B, between Router A and Router C,
and between Router B and Router C. The configuration details are not mentioned here.
Step 2 Enable MPLS RSVP-TE on Router A, Router B, and Router C. The configuration details are
not mentioned here.
For the configuration of MPLS RSVP-TE, refer to the Huawei AR Series Access Routers
Configuration Guide - MPLS.
Step 3 Configure a TE tunnel on Router A to connect Router C. The configuration details are not
mentioned here.

Step 4 Create an NQA test on Router A.

# Enable the NQA client and configure the LSP trace test for the TE tunnel.
[RouterA] nqa test-instance admin lsptrace
[RouterA-nqa-admin-lsptrace] test-type lsptrace
[RouterA-nqa-admin-lsptrace] lsp-type te
[RouterA-nqa-admin-lsptrace] lsp-tetunnel tunnel 0/0/1
Step 5 Perform the test.

[RouterA-nqa-admin-lsptrace] start now

[RouterA-nqa-admin-lsptrace] display nqa results test-instance admin lsptrace
NQA entry(admin, lsptrace) :testflag is inactive ,testtype is lsptrace

1 . Hop 1
2 . Hop 2
----End
Configuration Files
l Router A configuration file
#
sysname RouterA
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 10.1.1.9 255.255.255.255
#

destination 10.3.3.9
mpls te commit
#
ospf 1
area 0.0.0.0
network 10.1.1.9 0.0.0.0
network 10.1.1.0 0.0.0.255
mpls-te enable
#
nqa test-instance admin lsptrace
test-type lsptrace
lsp-type te
lsp-tetunnel Tunnel0/0/1
#
return
l Router B configuration file
#
sysname RouterB
#
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 10.2.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 10.2.2.9 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.2.2.9 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.2.1.0 0.0.0.255
mpls-te enable
#
return
l Router C configuration file
#
sysname RouterC
#
mpls
mpls te
mpls rsvp-te
#
ip address 10.2.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 10.3.3.9 255.255.255.255
#

mpls te commit
#
ospf 1
area 0.0.0.0
network 10.3.3.9 0.0.0.0
network 10.2.1.0 0.0.0.255
mpls-te enable
#
return
7.15.19 Example for Configuring the LSP Trace Test for Checking
the CR-LSP Hotstandby Tunnel
In the MPLS VPN shown in Figure 7-35, a TE tunnel with Router C being the egress is set up
on Router A, and CR-LSP hot standby is configured on the TE tunnel.
l OSPF is configured on RouterA, RouterB, RouterC, and RouterD to enable them to learn
the 32-bit host addresses of the loopback interfaces from each other.
l MPLS, MPLS TE, MPLS RSVP-TE, and MPLS TE CSPF are enabled on RouterA,
RouterB, RouterC, and RouterD.
l MPLS, MPLS TE, and MPLS RSVP-TE are enabled on the interfaces connected to
RouterA, RouterB, RouterC, and RouterD. Then, a TE tunnel is set up from RouterA to
RouterC.
In the preceding configurations:
l The primary CR-LSP is Router A-Router B-Router C.
l The hotstandby CR-LSP is Router A-Router D-Router C.
In this manner, when the primary CR-LSP becomes faulty, traffic can be switched to the hot-
standby CR-LSP. Traffic is switched back to the primary CR-LSP 15 seconds after the fault
on the primary CR-LSP is rectified.
But if the hotstandby CR-LSP is faulty and therefore is unable to carry the traffic that is
switched from the primary CR-LSP, the hotstandby CR-LSP needs to be detected. NQA LSP
Trace can be used to detect the connectivity of the hotstandby CR-LSP. This function can
detect the connectivity of the hotstandby CR-LSP and its performance in real time. This helps
detect and identify faults on the hotstandby CR-LSP.

Figure 7-35 Networking diagram of the LSP Trace test

10.10.1.1/32 10.20.2.2/32 10.30.3.3/32
GE1/0/0 GE1/0/0
10.1.1.1/24 10.20.1.1/24
GE2/0/0 GE1/0/0
10.30.1.1/24 GE2/0/0 GE2/0/0 10.40.1.2/24
RouterA 10.1.1.2/24 RouterB 10.20.1.2/24 RouterC
Loopback1
10.40.4.4/32
GE1/0/0 GE2/0/0
10.30.1.2/24 10.40.1.1/24
RouterD
1. Configure RouterA as the NQA client and create an LSP Trace test instance on Router
A.
2. Configure RouterC as the NQA server.
Procedure
Step 1 Configure routes among RouterA, RouterB, RouterC and RouterD.
For detailed configuration, see the configuration files in this example.
Step 2 Configure MPLS RSVP-TE on RouterA, RouterB, RouterC, and RouterD.
Step 3 On RouterA, set up a TE tunnel to RouterC.
Step 4 Configure an NQA test instance on RouterA.
# Enable the NQA client and create an LSP Trace test instance for checking the TE tunnel.
[RouterA] nqa test-instance admin lsptrace
[RouterA-nqa-admin-lsptrace] test-type lsptrace
[RouterA-nqa-admin-lsptrace] lsp-type te
[RouterA-nqa-admin-lsptrace] lsp-tetunnel tunnel 0/0/1 hot-standby
Step 5 Start the test.

[RouterA-nqa-admin-lsptrace] start now

[RouterA-nqa-admin-lsptrace] display nqa results test-instance admin lsptrace
NQA entry(admin, lsptrace) :testFlag is inactive ,testtype is lsptrace


1 . Hop 1
2 . Hop 2
----End
Configuration Files
#
sysname RouterA
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
explicit-path backup
next hop 10.30.1.2
next hop 10.40.1.2
next hop 10.30.3.3
#
explicit-path main
next hop 10.1.1.2
next hop 10.20.1.2
next hop 10.30.3.3
#
ip address 10.1.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 10.30.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 10.10.1.1 255.255.255.255
#
mpls te record-route
mpls te path explicit-path main

mpls te path explicit-path backup secondary

mpls te commit
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.10.1.1 0.0.0.0
network 10.30.1.0 0.0.0.255
mpls-te enable
#
nqa test-instance admin lsptrace
test-type lsptrace
lsp-type te
lsp-tetunnel Tunnel0/0/1 hot-standby
#
return
#
sysname RouterB
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ip address 10.20.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 10.1.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 10.20.2.2 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.1.1.0 0.0.0.255
network 10.20.1.0 0.0.0.255
network 10.20.2.2 0.0.0.0
mpls-te enable
#
return
#
sysname RouterC
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ip address 10.40.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#

ip address 10.20.1.2 255.255.255.0

mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 10.30.3.3 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.20.1.0 0.0.0.255
network 10.30.3.3 0.0.0.0
network 10.40.1.0 0.0.0.255
mpls-te enable
#
return
l RouterD configuration file

#
sysname RouterD
#
mpls
mpls te
mpls rsvp-te
mpls te cspf
#
ip address 10.30.1.2 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
ip address 10.40.1.1 255.255.255.0
mpls
mpls te
mpls rsvp-te
#
interface LoopBack1
ip address 10.40.4.4 255.255.255.255
#
ospf 1
area 0.0.0.0
network 10.30.1.0 0.0.0.255
network 10.40.1.0 0.0.0.255
network 10.40.4.4 0.0.0.0
mpls-te enable
#
return
7.16 Troubleshooting NQA
7.16.1 A UDP Jitter Test Instance Fails to Be Started
Context
A UDP jitter test may fail to be started. This fault is commonly caused by incorrect settings of
mandatory parameters of the test instance.

NOTE
Generally, the following commands are used in the NQA view. Only the display commands can be used
in any view.
Procedure
Step 1 Run the display nqa-agent admin-name test-name [ verbose ] command on the NQA client
or run the display this command in the NQA view to check whether the test type is Jitter.
l If so, go to Step 2.
l If not, run the test-type jitter command to set the test type to UDP Jitter.
or run the display this command in the NQA view to check whether the destination IP
address is configured.
l If so, go to Step 3.
l If not, run the destination-address ipv4 ip-address command in the NQA test instance
view to configure the destination IP address.
or run the display this command in the NQA view to check whether the destination port is
configured.
If not, run the destination-port port-number command in the NQA view to configure the
destination port.
----End
7.16.2 A Drop Record Exists in the UDP Jitter Test Result
Context
If the UDP jitter test result has drop records, the value of the Drop operation number field in
the display nqa results command output is not 0. This fault is commonly caused by one of
the following:
l The destination IP address does not exist or the route to the network segment to which
the destination IP address belongs does not exist in the routing table.
l The source IP address is incorrect.
Procedure
Step 1 Run the display ip routing-table command on the NQA client to check whether the unicast
route along the test path exists.
l If the route exists, run the ping command to check whether devices can successfully ping
each other.
l If the route does not exist, run the corresponding command to reconfigure the route.
or run the display this command in the NQA test instance view to check whether the source
IP address is configured.
----End

7.16.3 A Busy Record Exists in the UDP Jitter Test Result
Context
If the UDP jitter test result has busy records, the value of the System busy operation number
field in the display nqa results command output is not 0. This fault is commonly caused by
one of the following: The VPN route instance that is configured in the UDP Jitter test instance
is unreachable.
Procedure
or run the display this command in the NQA test instance view to check whether the VPN
instance is configured.
Step 2 Run the ping -vpn-instance vpn-instance-name command on the NQA client to check
whether the destination address is reachable.
----End
7.16.4 A Timeout Record Exists in the UDP Jitter Test Result
Context
If the UDP jitter test result has timeout records, the value of the operation timeout number
field in the display nqa results command output is not 0. This fault is commonly caused by
one of the following:
l The destination address does not exist, but the route to the network segment of the
destination address exists in the routing table.
l The value of the parameter nqa-jitter tag-version is 2, and the receiver is not configured
with a UDP server.
NOTE
Generally, the following commands are used in the NQA test instance view. Only the display commands
can be used in any view.
Procedure
Step 1 Run the ping command on the NQA client to check whether the route to the destination
address is reachable.
Step 2 Run the display this command in the system view on the NQA client to check whether the
value of the parameter nqa-jitter tag-version is 2. When the value of this parameter is set to
1 (the default value), this parameter is not displayed in the configuration file. When the value
is 2, this parameter is displayed in the configuration file.
Step 3 Run the display nqa-server command on the NQA server to check whether the nqa-server
udpecho ip-address port-number command has been configured on the NQA server.
If the nqa-server udpecho ip-address port-number command is not configured on the NQA
server, run the command to configure the NQA server. Note that the ip-address of the NQA
server must be the same as the destination IP address set using the destination-address ipv4

ip-address command on the NQA client. The port-number configured on the NQA server
must be the same as that set using the destination-port port-number command on the NQA
client.
----End
7.16.5 The UDP Jitter Test Result Is "Failed", "No Result", or

"Packet Loss"
Context
The UDP jitter test result displayed in the display nqa results command output can be failed,
no result, or packet loss. In the command output,
l If the Completion field is displayed as failed, the test fails.
l If the Completion field is displayed as no result, the test has no result.
l If the lost packet ratio field is not 0%, packet loss occurs.
This fault is commonly caused by one of the following:

l A drop record exists in the UDP jitter test result.
l A busy record exists in the UDP jitter test result.
l A timeout record exists in the UDP jitter test result.
l The TTL expires.
l The parameter frequency is incorrect.
l The parameter fail-percent is incorrect.
NOTE
Generally, the following commands are used in the NQA test instance view. Only the display commands
can be used in any view.
Procedure
or run the display this command in the NQA test instance view to check whether the TTL is
configured.
l If the TTL is configured, you can run the ttl number command in the NQA test instance
view to set the value of the TTL to 255. If the fault persists after the TTL is set to 255,
go to Step 2.
l If the TTL is not configured, you can run the ttl number command in the NQA test
instance view to set the value of the TTL to 255. If the fault persists after the TTL is set
to 255, go to Step 2.
or run the display this command in the NQA test instance view to check whether the
parameter frequency is configured.
l If the parameter frequency is set, compare the value of the frequency with that of the
(interval x probe-count x jitter-packetnum). To ensure that the UDP Jitter test instance
can be complete normally, the value of the frequency must be larger than that of the
(interval x probe-count x jitter-packetnum). If the value of the frequency is smaller than

that of the (interval x probe-count x jitter-packetnum), run the frequency interval

command in the NQA test instance view to increase the value of the frequency.
l If the frequency is not set or the fault persists after a proper frequency value is set, go to
Step 3.
or run the display this command in the NQA test instance view to check whether the
parameter fail-percent is set.
If the parameter fail-percent is set, run the undo fail-percent command in the NQA test
instance view to delete the parameter fail-percent.
----End
7.17 FAQ About NQA
7.17.1 How Can I View the Result of an NQA Test Instance?

Run the display nqa results [ collection | success | failed ] test-instance admin-name test-
name command to view the result of an NQA test instance.
Run the display nqa history test-instance admin-name test-name [ from start-date start-time
to end-date end-time ] command to view the result of a history NQA test instance.

and Monitoring 8 LSDP Configuration
8 LSDP Configuration
About This Chapter
This chapter describes the concepts and configuration procedures related to LSDP, and
provides a configuration example.
8.1 Overview of LSDP

This section describes the concept and function of LSDP.
8.2 Understanding LSDP
This section describes the LSDP implementation mechanism.
8.3 Application Scenarios for LSDP
This section describes the LSDP application scenario.
8.4 Licensing Requirements and Limitations for LSDP
This section provides the points of attention when configuring LSDP.
8.5 Configuring LSDP
8.6 Configuration Examples for LSDP
This section provides a configuration example of LSDP by using a network diagram.
8.1 Overview of LSDP

This section describes the concept and function of LSDP.
Definition
The Link Status Detection Protocol (LSDP) detects link connectivity and sets interface status
to Up or Down based on the link status.
Purpose
The Ethernet does not have a link negotiation or detection mechanism. If an interface on a
link is Down or a fiber encounters a unidirectional communication failure, the devices on two
ends of the link or fiber cannot detect the fault. As a result, the devices consider that the

related interfaces are Up and still forwards packets to the failure link, causing the packets to
be discarded.
To improve service quality, the devices on the Ethernet must be able to:
l Detect link connectivity.
l Take actions based on link the status.
To meet the preceding requirements, the devices must use dedicated probe and have
association mechanisms configured. This increases investment on network devices. Using
Huawei LSDP, the devices do not need to use dedicated probe or association mechanisms,
which reduce costs. LSDP can detect link connectivity and accurately take actions based on
the link status. When a link fails, LSDP sets the interface status to Down, making the route to
this interface and related forwarding entries invalid. When detecting that the link is recovered,
LSDP changes the interface status to Up, and the interface can process services.
8.2 Understanding LSDP

This section describes the LSDP implementation mechanism.
LSDP Implementation
LSDP provides millisecond-level link status detection and sets interface status to Up or Down
based on the link status.
As shown in Figure 8-1, LSDP is configured on RouterA to detect the connectivity of the link
between RouterA and RouterB. LSDP uses two types of packets: ARP and ICMP packets.
The detection process is as follows:
1. RouterA's GE1/0/0 sends an ARP request packet to RouterB's GE1/0/0 to request for its
MAC address.
– If RouterA's GE1/0/0 receives an ARP reply packet from RouterB's GE1/0/0, LSDP
proceeds to step 2.
– If RouterA's GE1/0/0 does not receive an ARP reply packet within the maximum
number of probe counts, LSDP considers this probe failed, sets the status of
RouterA's GE1/0/0 to Down, and starts the next round of probe (that is, sends a new
ARP request packet to RouterB's GE1/0/0).
2. RouterA's GE1/0/0 sends an ICMP request packet to RouterD's GE1/0/0 to detect link
connectivity.
– If RouterA's GE1/0/0 receives an ICMP reply packet, LSDP sets the status of
RouterA's GE1/0/0 to Up.
– If RouterA's GE1/0/0 does not receive an ICMP reply packet within the maximum
number of probe counts, LSDP considers this probe failed and sets the status of
RouterD's GE1/0/0 to Down.
LSDP starts the next round of probe.

Figure 8-1 LSDP network diagram

GE1/0/0 GE2/0/0
10.1.2.2/24 10.1.4.1/24
GE1/0/0 GE1/0/0
RouterB 10.1.4.2/24
10.1.2.1/24
RouterA RouterD
GE2/0/0 RouterC GE2/0/0

10.1.3.1/24 10.1.5.2/24
GE1/0/0 GE2/0/0
10.1.3.2/24 10.1.5.1/24
Primary link
Backup link
LSDP probe packets
8.3 Application Scenarios for LSDP

This section describes the LSDP application scenario.
LSDP Application
LSDP monitors link connectivity in real time. When a link fails, LSDP sets the interface
status on the local end to Down so that all services on this interface become invalid. When the
link is recovered, LSDP sets the interface status to Up.
On a network with dual-link or multi-link configured, a device can use the Simple Network
Management Protocol (SNMP) to send an interface Down alarm to the network management
system (NMS) through a working link. Then traffic is quickly switched to the working link.
This improves service transmission reliability.
GE1/0/0 Internet GE1/0/0

10.1.2.2/24 10.1.4.1/24
RouterC RouterD
Branch GE1/0/0 GE1/0/0 Headquarters

10.1.2.1/24 10.1.4.2/24
RouterA RouterB
GE1/0/1 GE1/0/1
10.1.3.1/24 10.1.5.2/24
GE1/0/1 Internet
10.1.3.2/24 Primary link
RouterE Backup link
LSDP probe packets
As shown in Figure 8-2, the egress gateway RouterA of the branch connects to the Internet
through GE1/0/0. The link connected to GE1/0/0 is the primary link, and the link connected to

GE1/0/1 is the backup link. LSDP is configured on RouterA's GE1/0/0 to detect link
connectivity between the branch and headquarters. When the link from RouterD to RouterB
fails, LSDP sets the status of RouterA's GE1/0/0 to Down, and then services are transmitted
through the backup link.
When the link from RouterD to RouterB is recovered, LSDP sets the status of RouterA's
GE1/0/0 to Up, and the primary link takes over services.
8.4 Licensing Requirements and Limitations for LSDP

This section provides the points of attention when configuring LSDP.

None
LSDP is a basic feature of a router and is not under license control.
Feature Limitations
LSDP is supported by only Layer 3 Ethernet interfaces.
An AR3200 has active/standby MPUs installed. An active/standby switchover between the

MPUs will also cause the interface status to alternate between Down and Up. It is difficult to
determine whether the interface status change is caused by MPU switchover or LSDP.
Therefore, you are not advised to configure LSDP on an AR3200.
8.5 Configuring LSDP
Prerequisites
You can configure LSDP on an interface that has an IP address and route configured.
Procedure
Step 3 Run lsdp ip-address [ nexthop-address ] [ interval interval-number ] [ probe-count count

number ]
LSDP is configured
----End


Run the display lsdp command to view the LSDP configuration and running status.
8.6 Configuration Examples for LSDP

This section provides a configuration example of LSDP by using a network diagram.
8.6.1 Example for Configuring LSDP
As shown in Figure 8-3, the link RouterA->RouterB->RouterD is the primary link, and the
link RouterA->RouterC->RouterD is the backup link. It is required to monitor the primary
link status. If the primary link fails, the backup link starts to transmit services to reduce the
impact on services. When the primary link is recovered, the primary link takes over services
again.

GE1/0/0 GE2/0/0
10.1.2.2/24 10.1.4.1/24
RouterB GE1/0/0
10.1.4.2/24
GE1/0/0
Branch Headquraters
10.1.2.1/24
RouterA RouterD
GE2/0/0 RouterC GE2/0/0
10.1.3.1/24 10.1.5.2/24
GE1/0/0 GE2/0/0
10.1.3.2/24 Primary link
10.1.5.1/24
Backup link
1. Configure interface IP addresses and static routes for primary and backup links to
implement connectivity at the network layer.
2. Configure LSDP on RouterA to detect primary link connectivity in real time.
Procedure
Step 1 Configure connectivity at the network layer.
1. Configure interface IP addresses for RouterA according to the network diagram.
[RouterA] interface gigabitethernet1/0/0

[Router-GigabitEthernet1/0/0] ip address 10.1.2.1 255.255.255.0

2. On RouterA, configure static routes to 10.1.4.0/24 and 10.1.5.0/24 of RouterD.

[RouterA] ip route-static 10.1.4.0 255.255.255.0 10.1.2.2 preference 40
[RouterA] ip route-static 10.1.5.0 255.255.255.0 10.1.3.2 preference 80
Step 2 Configure LSDP on RouterA.

[RouterA-GigabitEthernet1/0/0] lsdp 10.1.4.2 10.1.2.2
[RouterA]

# View the LSDP configuration and running status on RouterA.
<RouterA> display lsdp
======LSDP INFO=========
LSDP Instance Index : 1
LSDP Test : success
LSDP Interface Name : GigabitEthernet1/0/0
LSDP Interface Status : UP
LSDP Interface Ip : 10.1.2.1
LSDP Destination Ip : 10.1.4.2
LSDP Next-hop Ip : 10.1.2.2
LSDP Interval : 1000
LSDP Probe-count : 3
LSDP UpTimes : 0
LSDP DownTimes : 0
=========================
----End
Configuration Files
#
sysname RouterA
#
lsdp 10.1.4.2 10.1.2.2
ip address 10.1.2.1 255.255.255.0
#
ip route-static 10.1.4.0 255.255.255.0 10.1.2.2 preference 40
ip route-static 10.1.5.0 255.255.255.0 10.1.3.2 preference 80
#
return

and Monitoring 9 Service Diagnosis Configuration
9 Service Diagnosis Configuration
About This Chapter
9.1 Overview of Service Diagnosis

9.2 Configuration Notes
This section provides the points of attention when configuring BTrace.
9.3 Configuring Service Diagnosis
9.4 Maintaining Service Diagnosis
9.1 Overview of Service Diagnosis

Service diagnosis allows maintenance personnel to create a diagnosis object using command
lines. When a user matching attributes of the diagnosis object gets online, the router
automatically creates a diagnosis instance for the user based on the diagnosis object and
monitors and exports instance information including status changes and protocol processing
during user access.
A diagnosis object is a database of users with some same attributes. For example, all users on
an interface card can be defined as a diagnosis object. A diagnosis instance is created based
on a diagnosis object and maps a user.
A diagnosis object is defined based on the following attributes:
l Interface number
l Calling number
l Tunnel ID
l VLAN ID
l QinQ VLAN
l Access mode
l User name
l IP address
l MAC address
Multiple users may get online or offline simultaneously and debugging information about a
specified user cannot be displayed. Therefore, it is difficult to locate faults during user access

based on debugging information on existing networks. Maintenance personnel need to capture

information about services of a specified user.
The service diagnosis function of the router meets this requirement.
Currently, the device supports diagnosis for Dynamic Host Configuration Protocol (DHCP),
Layer 2 Tunneling Protocol (L2TP), Authentication, Authorization and Accounting (AAA),
and Network Admission Control (NAC) services. The router diagnoses and exports complete
key information about exchanges between modules during user access. This helps
maintenance personnel know about service implementation and locate and rectify service
faults based on the information. Table 9-1 describes key information about exchanges
between modules during service diagnosis.
Table 9-1 Key information about exchanges between modules during service diagnosis
Service Key Exchange Information
DHCP DHCP server IP address allocation, release, and lease.
DHCP client IP address request, release, lease, and conflict.
DHCP relay IP address request, release, and lease between the DHCP
client and server.
DHCP IP address request, release, lease, and adding or deleting of

snooping dynamic DHCP snooping binding entries.
L2TP Control message and data message.
AAA User access, authentication, authorization, and accounting.

NOTE
Service diagnosis supports only common AAA users.
NAC User access and authentication.
9.2 Configuration Notes

This section provides the points of attention when configuring BTrace.
Network Element Involved

None
License Support
BTrace is a basic feature of a router and is not under license control.
Feature Dependency and Limitation

None

9.3 Configuring Service Diagnosis

Context
Service diagnosis affects system performance. Therefore, enable service diagnosis only when
fault locating is required. After locating faults, immediately run the undo trace enable
command to disable service diagnosis.
When locating faults of DHCP, L2TP, AAA, or NAC service during user access, maintenance
personnel can create diagnosis objects to diagnose services and locate the faults.
Users with different services have different attributes. Create diagnosis objects for different
services based on different attributes.
l DHCP service: based on the MAC address.
l L2TP service: based on the calling number and tunnel ID.
l AAA and NAC services: based on the MAC address, IP address, user name, user VLAN
ID, access mode, or interface number.
NOTE
The configurations of the trace enable and trace syslog source commands are not recorded in the
configuration file. After the device restarts, run these commands again to make service diagnosis take effect.
Procedure
Step 2 Run trace enable [ brief ]
Service diagnosis is enabled.
By default, service diagnosis is disabled.
l The trace enable brief command configures the device to output brief service diagnosis
information.
l The trace enable command configures the device to output detailed service diagnosis
information.
Step 3 Run trace object { mac-address mac-address | ip-address ip-address [ vpn-instance vpn-
instance-name ] | interface interface-type interface-number | user-vlan user-vlan-id [ qinq-
vlan qinq-vlan-id ] | user-name user-name | access-mode { dot1x | mac-authen | portal |
wlan } } * [ slot slot-id ] [ output { command-line | file file-name | syslog-server syslog-
server-ip } ]
A diagnosis object is created.
By default, no diagnosis object is created. If you do not specify the direction at which
information is exported, the default direction is the CLI.

NOTE
It is recommended that you export the diagnosis information to a specified file.

The diagnosis output file cannot exceed 1 MB. The excessive diagnosis information is not recorded.
Step 4 (Optional) Run save trace information

Diagnosis information in the device buffer is saved as a file.
When you specify the device to export diagnosis information as a file, to view real-time
diagnosis information, save diagnosis information in the buffer area as a file.
Step 5 (Optional) Run trace syslog source interface-type interface-number
An interface is configured for exporting diagnosis information to a log server.
By default, no interface is specified to export diagnosis information to a log server.
When you specify the device to export diagnosis information to a log server, configure an
interface for exporting diagnosis information to the log server.
----End

l Run the display trace information command to view information about service
diagnosis.
l Run the display trace instance [ instance-start-id [ instance-end-id ] | mac-address
mac-address | ip-address ip-address [ vpn-instance vpn-instance-name ] | interface
interface-type interface-number | cid cid ] [ slot slot-id ] command to view diagnosis
instances on the device.
l Run the display trace object [ service-object-id ] [ slot slot-id ] command to view the
configuration about a diagnosis object.
9.4 Maintaining Service Diagnosis

Context
After service diagnosis is enabled and a diagnosis object is created on a device, the device
creates a diagnosis instance when a user matching the attributes of the diagnosis object gets
online. If the device diagnoses services of multiple users, it creates a diagnosis instance for
each user, which occupies a large amount of system resources. Therefore, the device need to
automatically delete diagnosis instances when corresponding users get offline. The service
diagnosis module will fail to detect that some users are offline because these users got offline
abnormally. The diagnosis instances created for these users are not deleted and occupy system
resources. The device provides an aging mechanism for service diagnosis. When the aging
time is reached, the device automatically deletes diagnosis instances to reclaim resources.
In addition to the preceding two methods you can run the reset trace instance command to
clear all the diagnosis instances on the device.

After all the diagnosis instances are cleared using the reset trace instance command,
properly running diagnosis instances are also deleted. Exercise caution when you run the
reset trace instance command.
Procedure
Step 1 Run the system-view command to display the system view.
Step 2 Run the reset trace instance command to clear all diagnosis instances on the device.
----End

and Monitoring 10 Mirroring Configuration
10 Mirroring Configuration
About This Chapter
Packet mirroring copies packets to a specified destination so that you can analyze packets to
monitor the network and rectify faults.
NOTE
The device supports mirroring. The mirroring function is used for network detection and fault
management, and may involve personal communication information. Huawei cannot collect or store user
communication information without permission. It is recommended that relevant functions used to
collect or store user communication information be enabled under applicable laws and regulations.
During user communication information usage and storage, measures must be taken to protect user
communication information.
10.1 Overview of Mirroring

10.2 Understanding Mirroring
10.3 Licensing Requirements and Limitations for Mirroring
This section provides the points of attention when configuring mirroring.
10.4 Configuring Mirroring
10.5 Configuration Examples for Mirroring
10.6 FAQ About Mirroring
10.1 Overview of Mirroring
Definition
The mirroring function copies packets on a specified port (source port or mirrored port) to
another specified port (destination port or observing port).
Purpose
During network operation and maintenance, network administrators often need to obtain and
analyze packets sent to or from devices for service monitoring and fault location purposes.

The mirroring function copies packets on a mirrored port to an observing port without
affecting the packet processing capability of the devices. Network administrators can analyze
the copy of packets sent from an observing port to a monitoring device to determine whether
services running on a network are normal.
10.2 Understanding Mirroring
10.2.1 Concepts
Figure 10-1 is used to describe concepts of mirroring.
Figure 10-1 Networking of mirroring
Inbound Outbound
Router
Monitoring device
Common port
Mirrored port
Observing port
Original packets
Mirrored packets
Mirrored Port and Observing Port

l Mirrored port: is a monitored port. All the packets that pass through a mirrored port are
copied to the observing port.
l Observing port: is connected to a monitoring device and used to send packets from the
mirrored port to the monitoring device.
Generally, an observing port is only used to forward mirrored traffic, so it is
recommended that other services be not configured on the observing port. If other
services are configured on the observing port, mirrored traffic and traffic of other service
may affect each other.
When mirroring is configured on the device, too many mirrored packets occupy much internal
forwarding bandwidth and affect other services. Additionally, if the mirrored port and
observing port provide different bandwidth, for example, 1000 Mbit/s on the mirrored port

and 100 Mbit/s on the observing port, the observing port may fail to forward all mirrored
packets in a timely manner because of insufficient bandwidth, leading to packet loss.
Mirroring Direction
The mirroring direction refers to the direction in which the device copies packets on the
mirrored port to the observing port:
l Inbound: The device mirrors the packets that are received by the mirrored port to the
observing port.
l Outbound: The device mirrors the packets that are sent from the mirrored port to the
observing port.
l Bidirectional: The device mirrors the packets that are received and sent by the mirrored
port to the observing port.
10.2.2 Local Port Mirroring

Local port mirroring enables the device to copy the packets passing through a mirrored port
and send them to the local observing port for analysis and monitoring.
The local observing port is directly connected to a monitoring device. As shown in Figure
10-2, through local port mirroring, the local observing port forwards the packets that are
copied from the mirrored port to the connected monitoring device.

Figure 10-2 Networking of local port mirroring
Internet
2 The local observing
port sends the copied
packets to the monitoring
device.
Router Monitoring
device
1 The mirrored port copies

original packets and send
them to the local observing
port.
HostA HostB HostC
Mirrored port
Local observing port
Original packet
Mirrored packet
10.2.3 Flow Mirroring

Flow mirroring enables the device to copy the packets matching configured traffic
classification rules to an observing port for analysis and monitoring. As shown in Figure
10-3, the mirrored port copies service flow 2 matching traffic classification rules to the
observing port, and then the observing port forwards the copy of service flow 2 to the
monitoring device.

Figure 10-3 Networking of flow mirroring
Internet
2 the observing port sends the

copy of service flow 2 to the
monitoring device.
Service flow 2
RouterB Monitoring
1 When multiple service device
flows pass the mirrored
Service flow 1
Service flow 3
Service flow 2
port, the mirrored port
copies service flow 2
matching rules to the
observing port.
HostA HostB HostC
Mirrored port
Observing port
Original packet
Mirrored packet
Flow mirroring is a traffic action. Actually, a traffic policy defining flow mirroring is applied
to the system, a VLAN, or an interface. For details about the traffic policy, see "MQC
Configuration" in Huawei AR Series Access Routers - CLI-based Configuration -
Configuration Guide - QoS Configuration.
10.3 Licensing Requirements and Limitations for

Mirroring
This section provides the points of attention when configuring mirroring.

None
mirroring is a basic feature of a router and is not under license control.

Feature Limitations
l Support for the mirroring function:
– In local port mirroring, the device supports inter-card mirroring. That is, the
observing port and mirrored port can be located on different cards of the device.
– In local flow mirroring, when a WAN interface is used as a mirrored port, the
device supports inter-card mirroring.
– When a LAN interface is used as a mirrored port, the device does not support local
flow mirroring.
– The device can copy packets on one or more mirrored ports to one local observing
port.
– Only one local observing port can be configured on the device, and the observing
port must be a LAN or WAN Ethernet port.
– When a LAN Ethernet port is used as a mirrored port, a WAN Ethernet port cannot
be used as an observing port.
l Pay attention to other points:
– Generally, an observing port is only used to forward mirrored traffic, so it is
recommended that other services be not configured on the observing port. If other
services are configured on the observing port, mirrored traffic and traffic of other
service may affect each other.
– When mirroring is configured on the device, too many mirrored packets occupy
much internal forwarding bandwidth and affect other services. Additionally, if the
mirrored port and observing port provide different bandwidth, for example, 1000
Mbit/s on the mirrored port and 100 Mbit/s on the observing port, the observing
port may fail to forward all mirrored packets in a timely manner because of
insufficient bandwidth, leading to packet loss.
– When both port mirroring and flow mirroring are configured for packets, port
mirroring takes effect in the inbound direction and flow mirroring takes effect in the
outbound direction.
– In port mirroring, the outbound packets sent by observing ports may carry different
VLAN tags than the packets sent by mirrored ports. This will not affect existing
services.
– For the AR121, AR129, AR129GW-L, AR129CGVW-L, AR109, AR109W,
AR109GW-L, AR161, AR161G-L,AR161G-Lc, AR161G-U, AR169, AR169G-L,
AR169EW, AR169CVW, AR169CVW-4B4S, AR169EGW-L, AR169-P-M9 to
monitor packets on a sub-interface, ensure that the sub-interface and observing port
are in the same VLAN.
– For the AR2204-51GE-R, AR2204-51GE-P and AR2204-51GE, when GE0/0/3 to
GE0/0/50 work as Layer 2 Ethernet interfaces, GE0/0/3 to GE0/0/26 and GE0/0/27
to GE0/0/50 cannot be bound to the service.
– If an Eth-Trunk is configured as a mirrored port, its member ports cannot be
configured as mirrored ports. To configure a member port as a mirrored port, delete
it from the Eth-Trunk first.
– If an Eth-Trunk member port is configured as a mirrored port, the Eth-Trunk cannot
be configured as a mirrored port. To configure the Eth-Trunk as a mirrored port,
delete the member port from the Eth-Trunk first.
– When port mirroring and traffic shaping (GTS) are configured on the interface, if
there is a message on the interface that is discarded by GTS, the message mirrored
by the port still contains those messages that were discarded by GTS.

10.4 Configuring Mirroring
10.4.1 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.
Ensuring that the link layer protocol status of ports is Up.
10.4.1.1 Configuring a Local Observing Port
Context
NOTE
In PPPoEoA and IPoEoA scenarios, only WAN-side ports can be used as observing ports.
In local port mirroring, an observing port is directly connected to a monitoring device and
directly forwards the packets copied from a mirrored port to the monitoring device for
analysis.
Procedure
Step 2 Run observe-port interface interface-type interface-number
A local observing port is configured.
NOTE
l An observing port is dedicated to forwarding mirrored traffic. Do not configure other services on an
observing port; otherwise, mirrored traffic and other service traffic interfere with each other.
l If an Eth-Trunk is configured as a mirrored port, its member ports cannot be configured as mirrored ports.
To configure a member port as a mirrored port, delete it from the Eth-Trunk first.
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. To configure the Eth-Trunk as a mirrored port, delete the member port from it first.
----End
10.4.1.2 Configuring a Local Mirrored Port
Context
In local port mirroring, an observing port is directly connected to a monitoring device. The
observing port forwards the packets that are copied from the mirrored port to the connected
monitoring device for analysis.

Procedure
Step 2 Bind the mirrored port to the observing port.
1. Run interface interface-type interface-number
2. Run mirror to observe-port { both | inbound | outbound } [ exclude-link-head ]
The mirrored port is bound to the observing port.
NOTE
– inbound: mirrors the packets that are received by the mirrored port to the observing port.
– outbound: mirrors the packets that are sent by the mirrored port to the observing port.
– both: mirrors the packets that are received and sent by the mirrored port to the observing port.
----End
10.4.1.3 Checking the Configuration
Procedure
l Run the display observe-port command to check the observing port.
l Run the display mirror-port command to check the port mirroring configuration.
----End
10.4.2 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.
Ensuring that the link layer protocol status of ports is Up.
10.4.2.1 Configuring a Local Observing Port
Context
NOTE
In PPPoEoA and IPoEoA scenarios, only WAN-side ports can be used as observing ports.
In local port mirroring, an observing port is directly connected to a monitoring device and
directly forwards the packets copied from a mirrored port to the monitoring device for
analysis.
Procedure


Step 2 Run observe-port interface interface-type interface-number
A local observing port is configured.
NOTE
l An observing port is dedicated to forwarding mirrored traffic. Do not configure other services on an
observing port; otherwise, mirrored traffic and other service traffic interfere with each other.
l If an Eth-Trunk is configured as a mirrored port, its member ports cannot be configured as mirrored ports.
To configure a member port as a mirrored port, delete it from the Eth-Trunk first.
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. To configure the Eth-Trunk as a mirrored port, delete the member port from it first.
----End
10.4.2.2 Configuring a Traffic Classifier
No. Task Remarks
1 Configure a traffic classifier l Tasks 1 and 2 can be performed

in any sequence.
2 Define flow mirroring in a traffic
behavior l Task 1 can be performed
multiple times. That is, you can
bind multiple traffic classifiers
to a traffic policy so that the
device mirrors packets
matching the traffic classifiers.
3 Configure a traffic policy -
4 Apply the traffic policy l Task 4 can be performed

multiple times in different
VLANs or on different
interfaces. That is, specified
flows in different VLANs or on
different interfaces can be
mirrored to the same observing
port.
l Only one traffic policy can be
applied in the inbound or
outbound direction of each
interface or VLAN.
Procedure
Step 1 Configure a traffic classifier.
1. Run system-view

2. Run traffic classifier classifier-name [ operator { and | or } ]

A traffic classifier is created and the traffic classifier view is displayed.
and indicates that rules are ANDed with each other.
– If a traffic classifier contains ACL rules, packets match the traffic classifier only
when they match one ACL rule and all the non-ACL rules.
– If a traffic classifier does not contain ACL rules, packets match the traffic classifier
only when the packets match all the non-ACL rules.
or indicates that the relationship between rules is OR. Packets match a traffic classifier
as long as packets match only one rule of the traffic classifier.
By default, the relationship between rules in a traffic classifier is OR.
3. Run the following commands as required.
Matching Rule Command
Outer VLAN ID if-match vlan-id start-vlan-id [ to end-vlan-id ]
Inner VLAN IDs in QinQ if-match cvlan-id start-vlan-id [ to end-vlan-id ]

packets
802.1p priority in VLAN if-match 8021p 8021p-value &<1-8>

packets
Inner 802.1p priority in if-match cvlan-8021p 8021p-value &<1-8>

QinQ packets
EXP priority in MPLS if-match mpls-exp exp-value &<1-8>

packets
(AR1200&AR2200&AR3
200&AR3600 series)
Destination MAC address if-match destination-mac mac-address [ mac-address-

mask mac-address-mask ]
Source MAC address if-match source-mac mac-address [ mac-address-mask

mac-address-mask ]
DLCI value in FR packets if-match dlci start-dlci-number [ to end-dlci-number ]
DE value in FR packets if-match fr-de
Protocol type field if-match l2-protocol { arp | ip | mpls | rarp | protocol-

encapsulated in the value }
Ethernet frame header
All packets if-match any
DSCP priority in IP if-match [ ipv6 ] dscp dscp-value &<1-8>

packets NOTE
If DSCP priority matching is configured in a traffic policy, the
SAE220 (WSIC) and SAE550 (XSIC) cards do not support
redirect ip-nexthop ip-address post-nat.

IP precedence in IP if-match ip-precedence ip-precedence-value &<1-8>

packets NOTE
if-match [ ipv6 ] dscp and if-match ip-precedence cannot be
configured simultaneously in a traffic classifier where the
relationship between rules is AND.
Layer 3 protocol type if-match protocol { ip | ipv6 }
QoS group index of if-match qos-group qos-group-value

packets
IPv4 packet length if-match packet-length min-length [ to max-length ]
PVC information in ATM if-match pvc vpi-number/vci-number

packets
RTP port number if-match rtp start-port start-port-number end-port end-

port-number
SYN Flag in the TCP if-match tcp syn-flag { ack | fin | psh | rst | syn | urg } *
packet header
Inbound interface if-match inbound-interface interface-type interface-

number
Outbound interface if-match outbound-interface Cellular interface-

number:channel
ACL rule if-match acl { acl-number | acl-name }

NOTE
– Before defining a matching rule for traffic classification
based on an ACL, create the ACL.
– To use an ACL in a traffic classifier to match the source IP
address, run the qos pre-nat command on an interface to
configure NAT pre-classification. NAT pre-classification
enables the NAT-enabled device to carry the private IP
address before translation on the outbound interface so that
the NAT-enabled device can classify IP packets based on
private IP addresses and provide differentiated services.
ACL6 rule if-match ipv6 acl { acl-number | acl-name }

NOTE
– Before defining a matching rule for traffic classification
– To use an ACL in a traffic classifier to match the source IP
address, run the qos pre-nat command on an interface to
configure NAT pre-classification. NAT pre-classification
enables the NAT-enabled device to carry the private IP
address before translation on the outbound interface so that
the NAT-enabled device can classify IP packets based on
private IP addresses and provide differentiated services.

Application protocol if-match application application-name [ user-set user-

set-name ] [ time-range time-name ]
NOTE
Before defining a matching rule based on an application
protocol, enable Smart Application Control (SA) and load the
signature file.
SA group if-match category category-name [ user-set user-set-

name ] [ time-range time-name ]
NOTE
– Before defining a matching rule based on an application
protocol, enable Smart Application Control (SA) and load
the signature file.
User group if-match user-set user-set-name [ time-range time-

range-name ]
4. Run quit
Exit from the traffic classifier view.
Step 2 Define flow mirroring in a traffic behavior.

1. Run traffic behavior behavior-name
A traffic behavior is created and the traffic behavior view is displayed.
2. Run mirror to observe-port
The device is configured to mirror the packets matching traffic classification rules to the
specified observing port.
3. Run return
Return to the user view.
Step 3 Configure a traffic policy.

1. Run system-view
2. Run traffic policy policy-name
A traffic policy is created and the traffic policy view is displayed, or the view of an
existing traffic policy is displayed.
By default, no traffic policy is created in the system.
3. Run classifier classifier-name behavior behavior-name [ precedence precedence-
value ]
A traffic behavior is bound to a traffic classifier in a traffic policy.
By default, no traffic classifier or traffic behavior is bound to a traffic policy.
4. Run quit
Exit from the traffic policy view.
5. Run quit
Exit from the system view.

Step 4 Apply the traffic policy.

1. Run system-view
2. Run interface interface-type interface-number [.subinterface-number ]
3. Run traffic-policy policy-name { inbound | outbound }
The traffic policy is applied to the inbound or outbound direction on the interface.
By default, no traffic policy is applied to an interface.
----End
10.4.2.3 Checking the Configuration
Procedure
l Run the display observe-port command to check the observing port.
l Run the display traffic behavior { system-defined | user-defined } [ behavior-name ]
command to check the traffic behavior configuration.
l Run the display traffic classifier { system-defined | user-defined } [ classifier-name ]
command to check the traffic classifier configuration.
l Run the display traffic policy user-defined [ 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
10.5 Configuration Examples for Mirroring
10.5.1 Example for Configuring 1:1 Local Port Mirroring
As shown in Figure 10-4, the R&D department of a company communicates with the Internet
through the router, and the server (monitoring device) is directly connected to the router.
The server is required to monitor traffic from the R&D department to the Internet.

Internet
Router Server
GE1/0/0 GE2/0/0
R&D
HostA HostB HostC
Mirrored port
Original packet
Mirrored packet
1. Configure GE2/0/0 as the local observing port to forward mirrored packets to the server.
2. Configure GE1/0/0 as the mirrored port to copy traffic from the R&D department to the
Internet to the local observing port.
Procedure
Step 1 Configure an observing port.
# Configure GE2/0/0 on the router as the local observing port.

[Router] observe-port interface gigabitethernet 2/0/0
Step 2 Configure a mirrored port.
# Configure GE1/0/0 on the router as the mirrored port and configure GE1/0/0 to copy
received packets to the local observing port.
[Router-GigabitEthernet1/0/0] mirror to observe-port inbound
[Router-GigabitEthernet1/0/0] return


# Check the configuration of the observing port.
<Router> display observe-port
----------------------------------------------------------------------
Index : 1
Interface: GigabitEthernet2/0/0
Used : 0
----------------------------------------------------------------------
# Check the configuration of the mirrored port.

<Router> display mirror-port
---------------------------------------------------------------------------
Mirror-port Direction Observe-dest
---------------------------------------------------------------------------
1 GigabitEthernet1/0/0 Inbound GigabitEthernet2/0/0
---------------------------------------------------------------------------
----End
Configuration Files
l Configuration file of the router
#
sysname Router
#
observe-port interface GigabitEthernet2/0/0
#
mirror to observe-port inbound
#
return
10.5.2 Example for Configuring N:1 Local Port Mirroring
As shown in Figure 10-5, the R&D department and marketing department are connected to
Eth2/0/0 and Eth2/0/1 on the Router. The server (monitoring device) equipped with the
monitoring software is connected to Eth2/0/2 on the Router to analyze the obtained packets.
To ensure enterprise information security, the server is required to monitor all packets sent by
the R&D department and marketing department.

Internet
Eth2/0/2 Server
Router
Eth2/0/0 Eth2/0/1
R&D Marketing
HostA HostB HostC HostA HostB HostC
Mirrored port
Original packet
Mirrored packet
1. Configure Eth2/0/2 as the local observing port.
2. Configure Eth2/0/0 and Eth2/0/1 as the mirrored port to copy traffic from the R&D
department and marketing department to the Internet to the local observing port.
Procedure
Step 1 Configure the local observing port.
# Configure Eth2/0/2 on the Router as the observing port.
[Router] observe-port interface ethernet 2/0/2
Step 2 Configure mirrored ports.

# Configure Eth2/0/0 on the Router as the mirrored port to monitor the packets sent by the
R&D department.

[Router] interface ethernet 2/0/0

[Router-Ethernet2/0/0] mirror to observe-port inbound
[Router-Ethernet2/0/0] quit
# Configure Eth2/0/1 on the Router as the mirrored port to monitor the packets sent by the
marketing department.
[Router-Ethernet2/0/1] mirror to observe-port inbound
[Router-Ethernet2/0/1] return

# Check the configuration of the observing port.
<Router> display observe-port
---------------------------------------------------------------------------
Index : 1
Interface: Ethernet2/0/2
Used : 2
---------------------------------------------------------------------------
# Check the configuration of the mirrored ports.

<Router> display mirror-port
----------------------------------------------------------------------
Mirror-port Direction Observe-dest
----------------------------------------------------------------------
1 Ethernet2/0/0 Inbound Ethernet2/0/2
2 Ethernet2/0/1 Inbound Ethernet2/0/2
----------------------------------------------------------------------
----End
Configuration Files
l Configuration file of the Router
#
sysname Router
#
observe-port interface Ethernet2/0/2
#
#
#
return
10.5.3 Example for Configuring Local Traffic Mirroring

As shown in Figure 10-6, an enterprise's R&D department connects to the router through
Eth2/0/0. The monitoring device (Server) having monitoring software installed is connected
to Eth2/0/1 on the router to analyze the captured packets. Users want to monitor all the IPv4
packets sent from host 192.168.1.10/24 in the R&D department.

Figure 10-6 Networking diagram of local traffic mirroring
Internet
Router Server
Eth2/0/1
Eth2/0/0
R&D
HostA HostB HostC
Mirrored port
Original packets
Mirrored packets
1. Configure Eth2/0/1 as the local observing port.
2. Configure a traffic policy, and apply the traffic policy on Eth2/0/0 to copy IPv4 packets
with the source IP address of 192.168.1.10/24 to the observing port.
Procedure
Step 1 Configure a local observing port.
# Configure Eth2/0/1 on router as the observing port.

[Router] observe-port interface ethernet 2/0/1
Step 2 Configure the traffic classifier c1.
# Create IPv4 ACL 2000 on the router to match the IPv4 packets with the source IP address of
192.168.1.10.

[Router] acl number 2000

[Router-acl-basic-2000] rule permit source 192.168.1.10 0
# Create a traffic classifier named c1 and bind it to ACL 2000.

[Router] traffic classifier c1
[Router-classifier-c1] if-match acl 2000
[Router-classifier-c1] quit
Step 3 Create a traffic behavior named b1 and configure the local traffic mirroring action in the
traffic behavior.
[Router] traffic behavior b1
[Router-behavior-b1] mirror to observe-port
[Router-behavior-b1] quit
Step 4 Configure a traffic policy.

# Create a traffic policy named p1 on router, bind the traffic classifier and traffic behavior to
the traffic policy, and apply the traffic policy to the inbound direction of Eth2/0/0.
[Router] traffic policy p1
[Router-trafficpolicy-p1] classifier c1 behavior b1
[Router-trafficpolicy-p1] quit
[Router-Ethernet2/0/0] traffic-policy p1 inbound
[Router-Ethernet2/0/0] quit
[Router] quit

# View the traffic classifier configuration.
<Router> display traffic classifier user-defined c1
User Defined Classifier Information:
Classifier: c1
Operator: OR
Rule(s) :
if-match acl 2000
# View the traffic policy configuration.

<Router> display traffic policy user-defined p1
User Defined Traffic Policy Information:
Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
mirror to observe-
port
----End
Configuration Files
l Configuration file of the router
#
sysname Router
#
observe-port interface Ethernet2/0/1
#
acl number 2000
#
traffic classifier c1 operator or
if-match acl 2000
#
traffic behavior b1

mirror to observe-port
#
traffic policy p1
classifier c1 behavior b1
#
traffic-policy p1 inbound
#
return
10.6 FAQ About Mirroring
10.6.1 How Many Ports Can Mirror Traffic to One Observing

Port?
AR series routers allow multiple ports to mirror traffic to one observing port. There is no limit
to the number of ports. The traffic mirrored to the observing port, however, cannot exceed the
maximum forwarding traffic of the observing port, namely, maximum bandwidth of the
observing port.
10.6.2 If Mirroring Is Configured on the Main Interface, Will the

Traffic of the Sub-interface Be Mirrored to the Observing Port?
Yes.
10.6.3 Can an Interface Be Configured as a Mirroring Port and an

Observing Port at the Same Time?
An interface cannot be configured as a mirroring port and an observing port at the same time.
This is because the mirroring port and the observing port are exclusive.

and Monitoring 11 Packet Capture Configuration
11 Packet Capture Configuration
About This Chapter
This chapter describes how to configure packet capture and provides configuration examples.
NOTE
Based on your requirements to detect failures in telecom transmission, this feature may collect or store
some communication information about specific customers. Huawei cannot offer services to collect or
store this information unilaterally. Before enabling the function, ensure that it is performed within the
boundaries permitted by applicable laws and regulations. Effective measures must be taken to ensure
that information is securely protected.
11.1 Overview of Packet Capture

11.2 Licensing Requirements and Limitations for Packet Capture
This section provides the points of attention when configuring CP.
11.3 Configuring the Device to Capture Packets
11.4 Configuration Examples for Packet Capture
11.1 Overview of Packet Capture

This function improves network maintenance efficiency and reduces maintenance costs. As
Internet develops, devices on a network transmit various services, and network administrators
often need to capture packets on devices to locate faults. The packet capturing function allows
devices to capture received packets for fault location. This function simplifies the
configurations of packet analysis device and network monitoring device.
After the packet capturing function is enabled, the devices capture the packets matching
certain conditions. The maintenance personnel can run commands to view information about
captured packets or save the captured packets to the local storage media as *.cap files. The
saved files can be downloaded for fault analysis. This function greatly improves maintenance
efficiency and reduces maintenance costs.

11.2 Licensing Requirements and Limitations for Packet

Capture
This section provides the points of attention when configuring CP.

None
CP is a basic feature of a router and is not under license control.
Feature Limitations
None
11.3 Configuring the Device to Capture Packets
Context
If the device fails to forward traffic correctly, configure the packet capture function to capture
service packets for analysis. This allows the device to process invalid packets in time,
ensuring that network data can be transmitted correctly.
During network maintenance, if unexpected traffic (such as lowered voice quality and video
mosaic) occurs, there may be error packets or discarded packets. You need to configure a
filtering policy to capture the packets of specified types. Then the device can process invalid
packets in a timely manner and data services can be correctly transmitted.
The device can be configured to capture all service packets or only voice packets. To
accurately obtain voice packet information, configure the device to capture only voice
packets.
Procedure
Step 2 Packet capturing can be configured in two methods. The two methods cannot be configured at
the same time. Therefore, select one method according to your needs.
l Run the capture-packet { interface interface-type interface-number | dsp } [ acl acl-
number ] destination { terminal | file file-name } * [ car cir car-value | time-out time |
packet-num number | packet-len { length | total-packet } ] * command to configure the
device to capture packets.
l Run the voice-monitor interface interface-type interface-number destination file file-
name* telno telephone-number &<1-8> [ car cir cir-value | time-out time | packet-num

number | packet-len { length | total-packet } ] * command to configure the device to

capture voice packets and save them.
NOTE
l The packet capture configuration is not saved in the configuration file, and becomes invalid when
packet capture is complete.
l The capture-packet command can capture incoming and outgoing packets.
l Before using the capture-packet or voice-monitor command again, wait until the last command
execution is complete.
l The system limits the rate of captured packets. If the rate of packets exceeds the limit, some packets
may be discarded.
l You can set the timeout interval of packet capture and number of packets to be captured. The system
stops capturing packets after the timeout interval or the number of packets to be captured is reached.
l When configuring packet capture, you can set parameters according to the number of packets on an
interface. If there are many packets on the interface, set a small value of time and a large value of
number. If there are less packets on an interface, set a large value of time and a small value of
number.
----End

l Run the display voice-monitor command to display information about voice packets
passing the device.
11.4 Configuration Examples for Packet Capture
11.4.1 Example for Configuring Packet Capture Function
As shown in Figure 11-1, the router connects to the network through GE1/0/0.
Packets sent upstream from GE1/0/0 of the router need to be Captured. Captured packet
information needs to be displayed on the terminal.
Figure 11-1 Networking diagram for configuring the packet capture function
GE1/0/0
Internet
Router
l Capture all packets to be forwarded and display information about these packets on a
terminal

Procedure
l Capture all packets to be forwarded on GE1/0/0 and display information about these
packets on a terminal.
[Router] capture-packet interface gigabitethernet 1/0/0 destination terminal
time-out 10
Warning: Capture packets will be shown on ternimal.
[Router]
Packet: 1
-------------------------------------------------------
ff ff ff ff ff ff 00 e0 fc 01 00 08 08 06 00 01
08 00 06 04 00 01 00 e0 fc 01 00 08 02 01 01 03
00 00 00 00 00 00 0a 01 01 01 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
-------------------------------------------------------
------------------capture report-----------------------
file: NULL
interface: GigabitEthernet1/0/0
acl: -
car: 64pps timeout: 10s
packets: 100 (expected) 1 (actual)
length: 64 (expected)
-------------------------------------------------------
----End

and Monitoring 12 NetStream Configuration
12 NetStream Configuration
About This Chapter
This chapter describes how to configure NetStream to collect and export flow statistics, and
allow fine-grained management, for example, department-based charging for enterprises as
well as traffic monitoring and analysis.
12.1 Overview of NetStream
12.2 Understanding NetStream
12.3 Application Scenarios for NetStream
12.4 Licensing Requirements and Limitations for NetStream
This section provides the points of attention when configuring NetStream.
12.5 Default Settings for NetStream
12.6 Configuring Exporting of IPv4 Unicast Original Flow Statistics
Once exporting of IPv4 unicast original flow statistics is configured, the NDE collects
statistics about IPv4 unicast flows and exports each flow statistics to the NetStream server for
further analysis.
12.7 Configuring IPv4 Multicast Original Flow Statistics Exporting
After the IPv4 multicast original flow statistics exporting is configured, the NDE collects
statistics about IPv4 multicast flows and exports the statistics about each flow to the
NetStream server for further analysis.
12.8 Configuring IPv4 Aggregation Flow Statistics Exporting
After the IPv4 aggregation flow statistics exporting is configured, the NDE aggregates
statistics about IPv4 flows with the same aggregation entries and exports flow statistics to the
12.9 Configuring IPv4 Flexible Flow Statistics Exporting
After flexible flow statistics exporting is configured, the NDE classifies and collects statistics
about packets based on the protocol type, DSCP priority, source IP address, destination IP
address, source port number, and destination port number.
12.10 Configuring Exporting of Statistics about Flows That Fail the RPF Check

After the exporting is configured for statistics about flows that fail the RPF check, the NDE
collects statistics about flows that fail the RPF check and exports the statistics about each
flow to the NetStream server for further analysis.
12.11 Configuring NetStream Interface Index Length
12.12 (Optional) Configuring the Function of Aggregating Site Visitor Traffic on an Interface
12.13 Clearing NetStream Statistics
12.14 Configuration Examples for NetStream
12.1 Overview of NetStream
Definition
NetStream is a Huawei application that collects and analyzes service traffic based on network
flows.
Purpose
Facing the ever-increasing services and applications on the Internet, enterprises poses high
requirements on network management and accounting. NetStream was developed to meet
enterprises' requirements. NetStream covers the shortage (Table 12-1) of the traffic statistics
collection technologies traditionally used in the industry, such as SNMP and port mirroring.
NetStream collects service traffic statistics and resource usage based on traffic classification
and sends the statistics to a dedicated server or a network management system (NMS) with
NetStream software installed for further analysis.
Table 12-1 Implementation and limitations of traditional traffic statistics collection methods
Method Implementation Limitation
Based on Saves counter indexes in the routing Only collects basic statistical
IP packets table to count the number of bytes and information.
packets that pass through the device.
Based on Matches flows based on ACLs and Requires a large number of ACLs
access then collects statistics. and is only able to collect flow
control statistics that match ACL rules.
lists
(ACLs)
Using Uses SNMP to implement simple Is not robust enough.Wastes CPU

SNMP statistics functions, such as interface and network resources by
statistics, IP packet statistics, and ACL continuously polling the NMS for
matching statistics. statistics collection.
Based on Duplicates traffic passing through a Requires a dedicated server,

port port and sends the duplicated traffic to occupies an interface, and requires
mirroring a dedicated server for statistics and that the interface support port
analysis. mirroring.

Method Implementation Limitation
Based on Duplicates traffic using an optical Requires a dedicated server and

traffic splitter or other devices at the physical additional hardware.
duplicatio layer and then sends the duplicated
n at the traffic to a dedicated server for
physical statistics.
layer
Benefits
l Accounting
NetStream provides detailed data for accounting based on resource usage (links,
bandwidths, and time segments). The data includes, but is not limited to:
– Number of packets
– Number of bytes
– IP addresses
– Time
– Types of Service (ToS)
– Application type
Enterprises can calculate the expenses of each department and distribute operation costs
accordingly to use resources effectively.
l Network monitoring
When deployed on an interface connected to the Internet, NetStream monitors outgoing
traffic in real time and analyzes the bandwidth usage of services. This data helps network
administrators determine the network status and discover inappropriate network
structures or performance bottlenecks.
l User monitoring and analysis
NetStream obtains network resource usage of users, allowing network administrators to
efficiently plan and allocate network resources and ensure network security.
12.2 Understanding NetStream
12.2.1 NetStream Implementation
Components of a NetStream System

NetStream systems have three components: NetStream data exporter (NDE), NetStream
collector (NSC), and NetStream data analyzer (NDA), as shown in Figure 12-1.

Figure 12-1 Networking diagram of a NetStream system
NDE NSC
NDA
NDE NSC
NetSTream Flow
l NDE
An NDE is a device configured with NetStream. It analyzes and processes network
flows, extracts flows that meet statistical conditions, and exports the statistics to the
NSC. It can also perform operations (such as aggregation) on the statistics before
exporting them.
l NSC
An NSC is a program running in Windows or Unix that parses packets from NDEs and
saves the statistics to a database. It can collect, filter, and aggregate data exported from
multiple NDEs.
l NDA
An NDA is a traffic analysis tool that extracts and processes statistics from the NSC and
generates a report. This report provides a basis for services such as traffic accounting,
network planning, and attack monitoring. The NDA provides a graphical user interface
(GUI) for users to easily check and analyze the collected data.
NOTE
In practice, the NSC and NDA are integrated on a NetStream server.
NetStream Working Mechanism

NetStream systems work as follows:
1. An NDE periodically exports detailed data about flows to an NSC.
2. The NSC processes the data and sends it to an NDA.
3. The NDA analyzes the data for applications such as accounting and network planning.
Generally, Huawei data communication products function as NDEs in a NetStream system.
Therefore, the following sections describe the implementation of NDE. The implementation
of NetStream is as follows:

Figure 12-2 NetStream implementation
c
ffi
tra
NetStream flow statistics
e
ic
rv
Se
NDE NetStream server
NetStream NetStream
NetStream NetStream
flow flow statistics
flows flow aging
sampling exporting
In Figure 12-2, the NDE is properly forwarding service traffic and periodically exports
detailed data about flows to the NetStream server. The NetStream module on the NDE:
l Samples packets (see NetStream Packet Sampling).
l Creates a flow based on the collected data (see NetStream Flows)
l Ages out the flow (see NetStream Flow Aging).
l Exports the flow statistics (see NetStream Flow Statistics Exporting).
12.2.2 NetStream Packet Sampling

Packet sampling takes samples of incoming and outgoing traffic in adjustable intervals so that
only the statistics of sampled packets are collected. This reduces the impact of NetStream on
device performance and the statistics show the flow status of the entire network.
The following sampling modes are available:
l Packet-based random sampling
A random packet is sampled out of a specified number of packets. For example, if the
number of packets is set to 100, the NDE randomly samples a packet from every 100
packets. This mode applies to sampling regular traffic.
l Packet-based regular sampling
One packet is sampled out of a fixed number of packets. For example, if the number of
packets is set to 100, the NDE samples a packet after every 100 packets are transmitted.
If the NDE samples the 5th packet at the first time, the NDE samples the 105th packet,
followed by the 205th packet, and so on. This mode applies to network traffic
accounting.
l Time-based random sampling
The NDE randomly samples a packet in a specified interval. For example, if the interval
is set to 100, the NDE randomly samples a packet in every 100 ms. This mode applies to
sampling regular traffic.
l Time-based regular sampling
The NDE samples a packet at a specified interval. For example, the interval is set to 100.
If the NetStream module samples a packet at the 5th second at the first time, the NDE

samples a packet at the 105th second, the 205th second, and so on. This mode applies to
networks with a large volume of traffic.
12.2.3 NetStream Flows
NetStream provides packet statistics based on flows and supports statistics about IP packets
(including UDP, TCP, and ICMP packets).
l For IPv4 packets, IPv4 NetStream defines a flow based on the destination IP address,
source IP address, destination port number, source port number, protocol number, ToS,
and inbound or outbound interface. Packets with the same information for all seven
parameters (known as 7–tuple information) are marked as one flow.
12.2.4 NetStream Flow Aging
NetStream flow aging is a prerequisite for exporting flow statistics to the NSC. Once
NetStream is enabled on a device, flow statistics are stored in the NetStream cache on the
device. When a NetStream flow is aged out, the NDE exports the flow statistics in the cache
to the NSC using NetStream packets of the specified version.
NetStream flows are aged out in the following modes:
l Regular aging
– Active aging
Packets are continuously added to a flow for a specified period from when the first
packet is added. When the active aging timer expires, the flow statistics are
exported. Active aging enables the NDE to periodically export statistics about flows
that last for long periods.
– Inactive aging
If no packet is added to a flow in a specified period after the last packet is added to
the flow, the NDE exports flow statistics to the NetStream server. Inactive aging
clears unnecessary entries in the NetStream cache so that the system can fully
leverage statistics entries. Inactive aging enables the NDE to export the statistics
about flows that last for a short period. Once adding packets to a flow stops, the
NDE exports the flow statistics to save memory space.
l FIN- or RST-based aging
A FIN or RST flag in a TCP packet indicates that the TCP connection is terminated. The
NDE immediately ages the corresponding NetStream flow when it receives a packet with
a FIN or RST flag.
l Byte-based aging
The NetStream cache records the number of bytes for each flow. Overflow occurs when
the number of bytes exceeds the specified upper limit, and the NDE immediately ages
the flow to prevent a byte counting error. The hardware byte counter is a 32-bit counter,
and the upper limit is 4,294,967,295 bytes (about 3.9 GB).
l Forced aging
If a flow fails to age due to abnormal NetStream services or the latest statistics are
needed before the flow meets aging conditions, you can run commands to forcibly age
all flows in the NetStream cache

12.2.5 NetStream Flow Statistics Exporting
The NDE exports flow statistics to a specified NSC for further analysis after the flows age in
the NetStream cache.
Flow Statistics Exporting Modes

Original flow statistics exporting
The NDE collects statistics about all flows in original flow statistics exporting mode, and will
export statistics about each flow to the NetStream server after the aging timer expires.
This mode enables the NetStream server to obtain detailed statistics about each flow, but
increases network bandwidth and CPU usage. The statistics also occupy more memory on the
NDE, which increases cost.
Aggregation flow statistics exporting
When in aggregation mode, the NDE aggregates flow statistics with the same aggregation
entry values and then exports them to a specified NetStream server, significantly saving
network bandwidth. The NDE supports the aggregation modes described in Table 12-2.
For example, when there are four original TCP flows that have the same source port number,
destination port number, and destination IP address, but different source IP addresses, the
protocol-port mode is used. Aggregation entries in this mode include:
l Protocol number
l Source port number
l Destination port number
Because the four TCP flows from the example have the same protocol number, source port
number, and destination port number, only one aggregation flow statistics record is recorded
in the aggregation flow statistics table.
Table 12-2 Aggregation modes
Aggregation Mode Aggregation Entries
as Source AS number, destination AS number, index of the inbound

interface, and index of the outbound interface
as-tos Source AS number, destination AS number, inbound interface

index, outbound interface index, and ToS
protocol-port Protocol number, source port number, and destination port number
protocol-port-tos Protocol number, source port number, destination port number,

ToS, inbound interface index, and outbound interface index
source-prefix Source AS number, source mask length, source prefix, and inbound
interface index
source-prefix-tos Source AS number, source mask length, source prefix, ToS, and
inbound interface index

Aggregation Mode Aggregation Entries
destination-prefix Destination AS number, destination mask length, destination

prefix, and outbound interface index
destination-prefix-tos Destination AS number, destination mask length, destination

prefix, ToS, and outbound interface index
prefix Source AS number, destination AS number, source mask length,

destination mask length, source prefix, destination prefix, inbound
interface index, and outbound interface index
prefix-tos Source AS number, destination AS number, source mask length,

destination mask length, source prefix, destination prefix, ToS,
inbound interface index, and outbound interface index
Flexible flow statistics exporting
Flexible flows are created based on customized configurations. Users can collect flow
statistics as required based on the:
l Protocol type
l DSCP field
l Source IP address
l Destination IP address
l Source port number
l Destination port number
l Flow label
The NDE exports the flow statistics to the NetStream server. Flexible flow statistics exporting
occupies less traffic than original flow statistics exporting and provides users with a flexible
way to collect NetStream statistics.
Versions of Exported Packets

The current versions of NetStream exported packets are V5, V8, V9 and V10. NetStream
exported packets of all the versions are transmitted using UDP.
l V5: The packet format is fixed. NetStream packets in this format contain the original
flow statistics collected based on 7-tuple information.
l V8: The packet format is fixed. NetStream packets in this version support the
aggregation exporting format.
l V9: The NetStream packet format is defined in profiles. Statistical items can be
combined, and therefore statistics are exported more flexibly. V9 supports the exporting
of BGP next hop information and MPLSstatistics.
l V10: The NetStream packet format is defined in profiles. Statistics are exported
according to traffic characteristics. Statistics are highly scalable: the statistics formats
vary according to requirements.
NOTE
The exported V10 of NetStream can be used only with some non-Huawei devices.

12.3 Application Scenarios for NetStream

Application Scenario for NetStream
In Figure 12-3, RouterA connects to the Internet, and stores a large number of
communication packets. Network administrators intend to monitor bandwidths occupied by
services, so NetStream needs to be configured to monitor real-time traffic statistics on the
interface connecting to the Internet. The traffic statistics help network administrators
determine the network running status and discover inappropriate network structures or
performance bottlenecks.
Figure 12-3 NetStream networking diagram
Internet
NetStream server
RouterA
RouterB RouterC
12.4 Licensing Requirements and Limitations for

NetStream
This section provides the points of attention when configuring NetStream.

None
NetStream is a basic feature of a router and is not under license control.
Feature Limitations
When deploying NetStream on the router, pay attention to the following:

l The NetStream function conforms to IETF RFC3954. For security risks, see IETF
RFC3954. This function involves analyzing the communications information of terminal
customers. Before enabling the function, ensure that it is performed within the
boundaries permitted by applicable laws and regulations. Effective measures must be
taken to ensure that information is securely protected.
l NetStream supports sampling of IPv4 unicast and multicast packets, but does not support
sampling of IPv4 packets encapsulated with MPLS labels.
12.5 Default Settings for NetStream

Table 12-3 lists the default settings of NetStream parameters.
Table 12-3 Default settings for NetStream

NetStream packet Packet-based regular sampling with a sampling rate of 100.

sampling
Active aging time 30 minutes
Inactive aging time 30 seconds
FIN- and RST-based Disabled

aging
Byte-based aging Enabled
Version of exported V5
packets carrying
IPv4 unicast original
flow statistics
packets carrying
IPv4 multicast
original flow
statistics
packets carrying
IPv4 aggregation
flow statistics
packets carrying
IPv4 flexible flow
statistics
packets carrying
statistics about flows
that fail the RPF
check

12.6 Configuring Exporting of IPv4 Unicast Original Flow

Statistics
Once exporting of IPv4 unicast original flow statistics is configured, the NDE collects
statistics about IPv4 unicast flows and exports each flow statistics to the NetStream server for
further analysis.
Before configuring exporting of IPv4 unicast original flow statistics exporting, complete the
following tasks:
l Set physical parameters of interfaces.
l Set the link-layer attributes of each interface.
12.6.1 Configuring NetStream Sampling
Context
You can set the intervals for sampling packets so that only statistics of sampled packets are
collected. The statistics show the flow status on the entire network. The sampling function
reduces the impact of NetStream on device performance.
Procedure
l Configuring interface-based NetStream sampling
a. Run system-view
b. Run interface interface-type interface-number [.subinterface-number ]
c. Run ip netstream sampler { fix-packets packet-interval | fix-time time-interval |
random-packets packet-interval | random-time time-interval } { inbound |
outbound }
Packet sampling is configured on the interface.
By default, the packet-based regular sampling is used. The default packet sampling
rate is 100.
l Configuring traffic policy-based NetStream sampling
a. Configure a traffic classifier.
i. Run system-view
ii. Run traffic classifier classifier-name [ operator { and | or } ]
○ If a traffic classifier contains ACL rules, packets match the traffic
classifier only when they match one ACL rule and all the non-ACL rules.

○ If a traffic classifier does not contain ACL rules, packets match the traffic
classifier only when the packets match all the non-ACL rules.
or indicates that the relationship between rules is OR. Packets match a traffic
classifier as long as packets match only one rule of the traffic classifier.
iii. Run the following commands as required.
Inner VLAN IDs in if-match cvlan-id start-vlan-id [ to end-vlan-id ]

QinQ packets
802.1p priority in if-match 8021p 8021p-value &<1-8>

VLAN packets
Inner 802.1p priority if-match cvlan-8021p 8021p-value &<1-8>

in QinQ packets

packets
(AR1200&AR2200&
AR3200&AR3600
series)
Destination MAC if-match destination-mac mac-address [ mac-

address address-mask mac-address-mask ]
Source MAC address if-match source-mac mac-address [ mac-

address-mask mac-address-mask ]
DLCI value in FR if-match dlci start-dlci-number [ to end-dlci-

packets number ]
DE value in FR if-match fr-de

packets
Protocol type field if-match l2-protocol { arp | ip | mpls | rarp |

encapsulated in the protocol-value }

packets NOTE
If DSCP priority matching is configured in a traffic
policy, the SAE220 (WSIC) and SAE550 (XSIC) cards
do not support redirect ip-nexthop ip-address post-nat.
IP precedence in IP if-match ip-precedence ip-precedence-value

packets &<1-8>
NOTE
if-match [ ipv6 ] dscp and if-match ip-precedence
cannot be configured simultaneously in a traffic
classifier where the relationship between rules is AND.


packets
IPv4 packet length if-match packet-length min-length [ to max-

length ]
PVC information in if-match pvc vpi-number/vci-number

ATM packets
RTP port number if-match rtp start-port start-port-number end-

port end-port-number
SYN Flag in the TCP if-match tcp syn-flag { ack | fin | psh | rst | syn |
packet header urg } *
Inbound interface if-match inbound-interface interface-type

interface-number

number:channel

NOTE
l Before defining a matching rule for traffic
classification based on an ACL, create the ACL.
l To use an ACL in a traffic classifier to match the
source IP address, run the qos pre-nat command on
an interface to configure NAT pre-classification.
NAT pre-classification enables the NAT-enabled
device to carry the private IP address before
translation on the outbound interface so that the
NAT-enabled device can classify IP packets based
on private IP addresses and provide differentiated
services.

NOTE
services.

Application protocol if-match application application-name [ user-set

user-set-name ] [ time-range time-name ]
NOTE
protocol, enable Smart Application Control (SA) and
load the signature file.
SA group if-match category category-name [ user-set user-

NOTE
l Before defining a matching rule based on an
application protocol, enable Smart Application
Control (SA) and load the signature file.
User group if-match user-set user-set-name [ time-range

time-range-name ]
iv. Run quit

b. Configure a traffic behavior.
i. Run system-view
ii. Run traffic behavior behavior-name
iii. Run ip netstream sampler { fix-packets packet-interval | fix-time time-
interval | random-packets packet-interval | random-time time-interval }
unicast
An action of sampling IPv4 packet statistics is configured in the traffic
behavior.
By default, an action of sampling IPv4 packet statistics is not configured in a
traffic behavior.
iv. (Optional) Run statistic enable
Flow statistics collection is enabled.
v. Run quit
Exit from the traffic behavior view.
vi. Run quit
c. Configure a traffic policy.
i. Run system-view
ii. Run traffic policy policy-name
A traffic policy is created and the traffic policy view is displayed, or the view
of an existing traffic policy is displayed.

iii. Run classifier classifier-name behavior behavior-name [ precedence

precedence-value ]
iv. Run quit
v. Run quit
12.6.2 Configuring NetStream Flow Aging
Context
When a NetStream flow is aged out, the device exports the flow statistics in the cache to the
NSC.
NetStream flow aging modes include regular aging, FIN- and RST-based aging, byte-based
aging, and forced aging. By default, the byte-based aging is enabled.
l Regular aging
– Active aging
Active aging requires the device to periodically export statistics about the flows that
persist for a long period. This aging mode is enabled on the device by default, and
you only need to set the aging time.
– Inactive aging
Inactive aging clears unnecessary entries in the NetStream cache so that the system
can fully leverage statistics entries. Inactive aging requires the device to export
statistics about the flows that persist for a short period. Once adding packets to a
flow stops, the device exports flow statistics to conserve memory space. This aging
mode is enabled on the device by default, and you only need to set the aging time.
l FIN- and RST-based aging
An FIN or RST flag in a TCP packet indicates the termination of a TCP connection.
When receiving a packet with the FIN or RST flag, the device immediately ages out the
corresponding NetStream flow. It is recommended that you enable this mode.
l Forced aging
Forced aging is used when you require the latest statistics, but you do not satisfy with the
existing aging conditions or some flows fail to age out due to an anomaly. You can
forcibly age out all the flows in the cache and export the flow statistics.
Procedure
l Configure regular aging.
Configure active aging.
a. Run the system-view command to enter the system view.
b. Run the ip netstream timeout active active-interval command to set the active
aging time of IPv4 flows.
By default, the active aging time of IPv4 flows is 30 minutes.

Configure inactive aging.

b. Run the ip netstream timeout inactive inactive-interval command to set the
inactive time of IPv4 flows.
By default, the inactive aging time of IPv4 flows is 30 seconds.
l Configure FIN- and RST-based aging.
b. Run the ip netstream tcp-flag enable command to age NetStream flows according
to the FIN or RST flag in the TCP packet header.
By default, NetStream flows are not aged according to the FIN or RST flag in the
TCP packet header.
l Configure forced aging.
b. Run the reset ip netstream cache command to forcibly age out all flows in the
cache.
----End
12.6.3 Configuring NetStream Original Flow Statistics Exporting
Context
Original flow statistics can be exported only when you have specified at least one destination
IP address and one destination UDP port number for the exported packets.
Procedure
Step 2 (Optional) Run ip netstream as extend enable

The supported BGP AS number range is set.
By default, the BGP AS numbers range from 1 to 65535.
Only the output packets of V9 or V10 support the 32-bit BGP AS numbers. The ip netstream
as extend enable command needs to be executed to set the supported BGP AS number range
to 1-4294967295.
Step 3 Run the ip netstream export source ip-address command to configure the source address of
the exported packets carrying original flow statistics.
By default, the source IP address of the exported packets carrying IPv4 flow statistics is not
configured.
Step 4 Run the ip netstream export host ip-address port-number [ vpn-instance vpn-instance-
name ] command to configure the destination IP address and destination UDP port number of
You can configure two destination IP addresses to implement NSC backup. To configure a
third destination IP address, run the undo ip netstream export host command to delete an

existing one first; otherwise, the system displays a message indicating that the maximum
number of IP addresses is exceeded and the configuration fails.
----End
12.6.4 Configuring Versions for Exported Packets
Procedure
Step 2 Run the ip netstream export version version [ origin-as | peer-as ] [ bgp-nexthop ]
command to set the version and AS option of the exported packets carrying original flow
statistics.
By default, V5 supports the exported packets carrying flow statistics without the AS option.
Packets of V5 do not carry BGP next hop information.
NOTE
Currently, V9 and V10 support the exported packets carrying BGP next hop information.
----End
12.6.5 Configuring NetStream Statistics Collection
Context
IPv4 original flow statistics can be exported only if flow statistics collection is enabled on an
interface.
If you configure interface-based flow statistics collection and traffic policy-based flow
statistics collection simultaneously on one direction of the same interface, one packet is
collected only once.
Procedure
l Configuring interface-based flow statistics collection
a. Run system-view
b. (Optional) Run ip netstream pre-classify enable
The pre-classify function is enabled globally.
By default, the pre-classify function is disabled globally.
c. Run interface interface-type interface-number [.subinterface-number ]
d. Run ip netstream { inbound | outbound }
The NetStream function is enabled on the interface to collect statistics about IPv4
flows.
By default, the NetStream function for IPv4 flows is disabled on the interface.
l Configuring traffic policy-based flow statistics collection

a. Run system-view
c. Run traffic-policy policy-name { inbound | outbound }
Before applying a traffic policy to an interface, configure one according to 12.6.1
Configuring NetStream Sampling.
Context
You can run commands to verify that original flow statistics exporting has been configured
correctly.
Procedure
l Run the display ip netstream cache command to check information about flows in
NetStream cache.
l Run the display ip netstream statistic command to check the NetStream statistics.
l Run the display ip netstream { all | global } command to check the NetStream
configuration for IPv4 flows.
l Run the display traffic classifier user-defined [ classifier-name ] command to check the
traffic classifier configuration.
application record of a specified traffic policy.
12.7 Configuring IPv4 Multicast Original Flow Statistics

Exporting
After the IPv4 multicast original flow statistics exporting is configured, the NDE collects
statistics about IPv4 multicast flows and exports the statistics about each flow to the
Before configuring the IPv4 multicast original flow statistics exporting, complete the
following tasks:

Context
Procedure
a. Run system-view
outbound }
rate is 100.
a. Run system-view
b. Run traffic classifier classifier-name [ operator { and | or } ]
n If a traffic classifier contains ACL rules, packets match the traffic classifier
only when they match one ACL rule and all the non-ACL rules.
n If a traffic classifier does not contain ACL rules, packets match the traffic
c. Run the following commands as required.

QinQ packets

VLAN packets

Inner 802.1p priority in if-match cvlan-8021p 8021p-value &<1-8>

QinQ packets

packets
(AR1200&AR2200&A
R3200&AR3600 series)

Source MAC address if-match source-mac mac-address [ mac-address-

mask mac-address-mask ]

packets number ]
DE value in FR packets if-match fr-de


packets NOTE
If DSCP priority matching is configured in a traffic policy,
the SAE220 (WSIC) and SAE550 (XSIC) cards do not
support redirect ip-nexthop ip-address post-nat.
IP precedence in IP if-match ip-precedence ip-precedence-value &<1-8>

packets NOTE
if-match [ ipv6 ] dscp and if-match ip-precedence cannot
be configured simultaneously in a traffic classifier where the
relationship between rules is AND.

packets
IPv4 packet length if-match packet-length min-length [ to max-length ]

ATM packets
RTP port number if-match rtp start-port start-port-number end-port

end-port-number
Inbound interface if-match inbound-interface interface-type interface-

number


number:channel

NOTE
l Before defining a matching rule for traffic classification
l To use an ACL in a traffic classifier to match the source
IP address, run the qos pre-nat command on an
interface to configure NAT pre-classification. NAT pre-
classification enables the NAT-enabled device to carry
the private IP address before translation on the outbound
interface so that the NAT-enabled device can classify IP
packets based on private IP addresses and provide
differentiated services.

NOTE
l Before defining a matching rule for traffic classification
l To use an ACL in a traffic classifier to match the source
IP address, run the qos pre-nat command on an
interface to configure NAT pre-classification. NAT pre-
classification enables the NAT-enabled device to carry
the private IP address before translation on the outbound
interface so that the NAT-enabled device can classify IP
packets based on private IP addresses and provide
differentiated services.

NOTE
protocol, enable Smart Application Control (SA) and load
the signature file.
SA group if-match category category-name [ user-set user-set-

name ] [ time-range time-name ]
NOTE
l Before defining a matching rule based on an application
User group if-match user-set user-set-name [ time-range time-

range-name ]
d. Run quit

Context
When configuring the original flow statistics exporting, you need to configure NetStream
flow aging. When a NetStream flow is aged out, the device exports the flow statistics in the
cache to the NSC using NetStream packets of a specified version.
NetStream flow aging modes include regular aging, byte-based aging, and forced aging. Byte-
based aging is enabled by default, which requires no configuration.
l Regular aging
– Active aging
Active aging enables the device to periodically export the statistics about the flows
that last for a long period. This aging mode is enabled on the device by default. You
can configure the aging time as required.
– Inactive aging
can fully leverage statistics entries. Inactive aging enables the device to export the
statistics about the flows that last for a short period. Once adding packets to a flow
stops, the device exports flow statistics to conserve memory space. This aging mode
is enabled on the device by default. You can configure the aging time as required.
l Forced aging
Forced aging is used when existing flows do not meet aging conditions but the latest
statistics are required or when some flows fail to be aged out due to abnormal NetStream
services. You can run commands to forcibly age all the original flows in the cache and
export the flow statistics.
Procedure
l Configuring regular aging
a. Run system-view
b. Run ip netstream timeout active active-interval
The active aging time of IPv4 flows is set.
a. Run system-view
b. Run ip netstream timeout inactive inactive-interval
The inactive aging time of IPv4 flows is set.
a. Run system-view

b. Run reset ip netstream cache

All flows in the cache are forcibly aged.
----End
12.7.3 Configuring NetStream Original Flow Statistics Exporting
Context
Original flow statistics can be exported only when you have specified at least one destination
Procedure
to 1-4294967295.
configured.
----End
Procedure
Step 2 Run the ip netstream export version version [ origin-as | peer-as ] [ bgp-nexthop ]
command to set the version and AS option of the exported packets carrying original flow
statistics.

NOTE
----End
Context
IPv4 multicast original flow statistics can be exported only when you have enabled the flow
statistics collection function on an interface.
Procedure
a. Run system-view
d. Run ip netstream multicast { inbound | outbound }
The NetStream function is enabled on the interface to collect statistics about IPv4
multicast flows.
By default, NetStream is disabled for multicast flows.
The NetStream function supports independent statistics about incoming and
outgoing packets at the same time.
a. Run system-view

Context
You can run commands to verify that IPv4 multicast original flow statistics exporting has
been configured correctly.
Procedure
NetStream cache.
configuration for IPv4 multicast original flows.
12.8 Configuring IPv4 Aggregation Flow Statistics

Exporting
After the IPv4 aggregation flow statistics exporting is configured, the NDE aggregates
statistics about IPv4 flows with the same aggregation entries and exports flow statistics to the
Before configuring the IPv4 aggregation flow statistics exporting, complete the following
tasks:
Context
Procedure
a. Run system-view


outbound }
rate is 100.
i. Run system-view

QinQ packets

VLAN packets

in QinQ packets

packets
(AR1200&AR2200&
AR3200&AR3600
series)




packets number ]

packets


packets NOTE

packets &<1-8>
NOTE

packets

length ]

ATM packets


interface-number

number:channel


NOTE
services.

NOTE
services.

NOTE

NOTE

time-range-name ]
iv. Run quit

i. Run system-view


{ multicast | rpf-failure | unicast } *
behavior.
traffic behavior.
v. Run quit
vi. Run quit
i. Run system-view
precedence-value ]
iv. Run quit
v. Run quit
Context
NSC using NetStream packets of a specified version.
NetStream flow aging modes include regular aging, byte-based aging, and forced aging. By
default, the byte-based aging is enabled.
l Regular aging
– Active aging

– Inactive aging
l Forced aging
forcibly age out all the original flows in the cache and export the flow statistics.
Procedure

b. Run the ip netstream aggregation timeout active active-interval command to set
the active aging time of IPv4 aggregation flows.

b. Run the ip netstream aggregation timeout inactive inactive-interval command to
set the inactive time of IPv4 aggregation flows.
By default, the inactive aging time of IPv4 aggregation flows is 30 seconds.

cache.
----End
12.8.3 Configuring NetStream Aggregation Flow Statistics

Exporting
Context
You can configure an aggregation method for NetStream flows. Aggregation flow statistics
can be exported only when you have specified at least one destination IP address and one
destination UDP port number.
The device with NetStream aggregation flow statistics enabled can classify and aggregate
original flows according to certain rules, and export the aged flows to the NSC. Aggregation
of original flows will decrease network bandwidth, CPU usage, and memory space
occupation.

Procedure

to 1-4294967295.
Step 3 Run the ip netstream aggregation { as | as-tos | destination-prefix | destination-prefix-tos |
prefix | prefix-tos | protocol-port | protocol-port-tos | source-prefix | source-prefix-tos }
command to configure a NetStream aggregation method and enter the NetStream aggregation
view.
Step 4 (Optional) Run the mask { destination | source } minimum mask-length command to
configure an aggregation mask.
The configured aggregation mask is valid for six aggregation modes: prefix, prefix-tos,
destination-prefix, destination-prefix-tos, source-prefix, and source-prefix-tos, in which:
l The parameter source is used in prefix, prefix-tos, source-prefix, and source-prefix-tos
aggregation method.
l The parameter destination is used in prefix, prefix-tos, destination-prefix, and
destination-prefix-tos aggregation method.
the exported packets carrying flow statistics.
configured.
name ] command to configure the destination IP address and destination UDP port number for
exporting flow statistics.
The destination NSC address of the statistics can be configured in either the system view or
the NetStream aggregation view.
The destination NSC address configured in the aggregation view takes precedence over that
configured in the system view. After the destination NSC address is configured:
l Original flow statistics are exported only to the destination NSC address configured in
the system view.
l Aggregation flows are exported to the destination NSC address configured in the
corresponding aggregation view.
If no destination NSC address is configured in the aggregation view, aggregation flows
are exported to the destination NSC address configured in the system view.
Step 7 Run the enable command to enable the NetStream aggregation function.
By default, the aggregation function is disabled.
----End


Procedure
Step 2 Run the ip netstream aggregation { as | as-tos | destination-prefix | destination-prefix-tos |

prefix | prefix-tos | protocol-port | protocol-port-tos | source-prefix | source-prefix-tos }
command to enter the NetStream aggregation view.
Step 3 Run the export version version command to set the version of the exported packets.
By default, the version of the exported packets carrying aggregation flow statistics is V8.
----End
Context
Aggregation flow statistics can be exported only when you have enabled flow statistics
collection on an interface.
Procedure
a. Run system-view
d. Run ip netstream { inbound | outbound }
The NetStream function is enabled on the interface to collect statistics about
aggregation flows.
By default, NetStream is disabled for aggregation flows.
a. Run system-view


Context
You can run commands to verify that aggregation flow statistics exporting has been
configured correctly.
Procedure
configuration for IPv4 aggregation flows.
12.9 Configuring IPv4 Flexible Flow Statistics Exporting

After flexible flow statistics exporting is configured, the NDE classifies and collects statistics
about packets based on the protocol type, DSCP priority, source IP address, destination IP
address, source port number, and destination port number.
Before configuring the IPv4 flexible flow statistics exporting, complete the following tasks:
12.9.1 Configuring a Flexible Flow Statistics Template
Context
You need to configure a flexible flow statistics template before applying it to an interface. To
obtain richer flow statistics,
Procedure

Step 2 Run the ip netstream record record-name command to create a flexible flow statistics
template or enter the view of an existing flexible flow statistics template.
By default, no flexible flow statistics template exists.
Step 3 Run the match ipv4 { protocol | tos | source-address | destination-address | source-port |
destination-port } command to configure the aggregation keywords for the IPv4 flexible
flow statistics template.
By default, no IPv4 aggregation keyword is configured in a flexible flow statistics template.
Step 4 Run the match vxlan vni command to configure the VXLAN VNI aggregation keyword in
the flexible flow statistics template.
By default, no VXLAN VNI aggregation keyword is configured in a flexible flow statistics
template.
Step 5 (Optional) Run the collect counter { bytes | packets } command to configure the flexible
flow statistics exported to the NSC to contain the number of packets or bytes.
By default, the flexible flow statistics that are exported to the NSC do not contain the number
of packets and bytes.
Step 6 (Optional) Run the collect interface { input | output } command to configure the flexible
flow statistics exported to the NSC to contain the indexes of the inbound or outbound
interfaces.
By default, the flexible flow statistics exported to the NSC do not contain the index of the
inbound and outbound interface.
Step 7 (Optional) Run the collect application { name | description } command to configure the
application name or description of traffic to be added to the flexible flow statistics exported to
the NSC.
By default, the flexible flow statistics that are exported to the NSC do not contain the
application name and description.
Step 8 (Optional) Run the collect category name command to configure the application category
and subcategory of traffic to be added to the flexible flow statistics exported to the NSC.
By default, the flexible flow statistics that are exported to the NSC do not contain the
application category and subcategory.
----End
Context
Procedure
a. Run system-view


outbound }
rate is 100.
i. Run system-view

QinQ packets

VLAN packets

in QinQ packets

packets
(AR1200&AR2200&
AR3200&AR3600
series)




packets number ]

packets


packets NOTE

packets &<1-8>
NOTE

packets

length ]

ATM packets


interface-number

number:channel


NOTE
services.

NOTE
services.

NOTE

NOTE

time-range-name ]
iv. Run quit

i. Run system-view


{ multicast | rpf-failure | unicast } *
behavior.
traffic behavior.
v. Run quit
vi. Run quit
i. Run system-view
precedence-value ]
iv. Run quit
v. Run quit
Context
NSC using NetStream packets of a specified version.
NetStream flow aging modes include regular aging, byte-based aging, and forced aging. By
default, the byte-based aging is enabled.
l Regular aging
– Active aging

– Inactive aging
l Forced aging
forcibly age out all the original flows in the cache and export the flow statistics.
Procedure
b. Run the ip netstream timeout active active-interval command to set the active
aging time of IPv4 flows.
b. Run the ip netstream timeout inactive inactive-interval command to set the
inactive time of IPv4 flows.
cache.
----End
12.9.4 Configuring NetStream Flexible Flow Statistics Exporting
Context
Flexible flow statistics can be exported only when you have specified at least one destination
Procedure
configured.

----End

Procedure
Step 2 Run the ip netstream record record-name command to enter the flexible flow statistics
template view.
NOTE
The flexible flow statistics template must be the same as that in 12.9.1 Configuring a Flexible Flow
Statistics Template.
Step 3 Run the export version version command to set the version of exported packets carrying
flexible flow statistics.
By default, the packets carrying flexible flow statistics are exported in the format of V9.
----End
Context
When configuring flexible NetStream, you must enable flow statistics collection and apply a
flexible flow statistics template on an interface to ensure that statistics are exported
successfully.
Procedure
a. Run system-view

d. Run port ip netstream record record-name

The flexible flow statistics template is applied to the interface.
NOTE
l Each interface can be configured with only one flexible flow statistics template. Before
modifying the flexible flow statistics template in the same interface view, run the undo
port ip netstream record command to delete the existing configuration.
l If the flexible flow statistics template has been applied to the interface, the template
configuration cannot be modified or deleted.
e. Run ip netstream { inbound | outbound }
The NetStream function is enabled on the interface to collect flow statistics.
By default, flow statistics collection function is disabled on an interface.
a. Run system-view
c. Run port ip netstream record record-name
The flexible flow statistics template is applied to the interface.
NOTE
l Each interface can be configured with only one flexible flow statistics template. Before
modifying the flexible flow statistics template in the same interface view, run the undo
port ip netstream record command to delete the existing configuration.
l If the flexible flow statistics template has been applied to the interface, the template
configuration cannot be modified or deleted.
d. Run traffic-policy policy-name { inbound | outbound }
Context
You can run commands to verify that flexible flow statistics exporting has been configured
correctly.
Procedure
NetStream cache.
l Run the display ip netstream record { all | name record-name } command to display
the configuration of a flexible flow statistics template.
configuration for IPv4 flexible flows.

12.10 Configuring Exporting of Statistics about Flows That

Fail the RPF Check
After the exporting is configured for statistics about flows that fail the RPF check, the NDE
collects statistics about flows that fail the RPF check and exports the statistics about each
flow to the NetStream server for further analysis.
Before configuring exporting of statistics about flows that fail the RPF check, complete the
following tasks:
l Setting physical parameters of interfaces

l Setting the link-layer attributes of each interface
Context
Procedure
a. Run system-view
outbound }
rate is 100.


i. Run system-view

QinQ packets

VLAN packets

in QinQ packets

packets
(AR1200&AR2200&
AR3200&AR3600
series)



packets number ]

packets



packets NOTE

packets &<1-8>
NOTE

packets

length ]

ATM packets


interface-number

number:channel

NOTE
services.


NOTE
services.

NOTE

NOTE

time-range-name ]
iv. Run quit

i. Run system-view
interval | random-packets packet-interval | random-time time-interval } rpf-
failure
behavior.
traffic behavior.
v. Run quit


vi. Run quit
i. Run system-view
precedence-value ]
iv. Run quit
v. Run quit
Context
When configuring RPF NetStream, you need to configure NetStream flow aging. When a
NetStream flow is aged out, the device exports the flow statistics in the cache to the NSC
using NetStream packets of a specified version.
NetStream flow aging modes include regular aging, byte-based aging, and forced aging. Byte-
based aging is enabled by default, which requires no configuration.
l Regular aging
– Active aging
Active aging enables the device to periodically export the statistics about the flows
that last for a long period. This aging mode is enabled on the device by default. You
can configure the aging time as required.
– Inactive aging
can fully leverage statistics entries. Inactive aging enables the device to export the
statistics about the flows that last for a short period. Once adding packets to a flow
stops, the device exports flow statistics to conserve memory space. This aging mode
is enabled on the device by default. You can configure the aging time as required.
l Forced aging
Forced aging is used when existing flows do not meet aging conditions but the latest
statistics are required or when some flows fail to be aged out due to abnormal NetStream
services. You can run commands to forcibly age all the original flows in the cache and
export the flow statistics.

Procedure
l Configuring regular aging
a. Run system-view

b. Run ip netstream timeout active active-interval
The active aging time of IPv4 flows is set.
a. Run system-view

b. Run ip netstream timeout inactive inactive-interval
The inactive aging time of IPv4 flows is set.

a. Run system-view

b. Run reset ip netstream cache
All flows in the cache are forcibly aged.
----End
12.10.3 Configuring NetStream RPF Check Failure Flow Statistics

Exporting
Context
Statistics about flows that fail the RPF check can be exported only when you have specified at
least one destination IP address and one destination UDP port number for the exported
packets.
Procedure

to 1-4294967295.
Step 3 Run ip netstream export source ip-address
The source address of the exported packets carrying flow statistics is configured.
configured.
Step 4 Run ip netstream export host ip-address port-number
The destination IP address and destination UDP port number are configured for the flow
statistics packets exported to the NSC.
----End
Procedure
Step 2 Run ip netstream export version version [ origin-as | peer-as ] [ bgp-nexthop ]
The version of the exported packets is set.
NOTE
----End
Context
Statistics about flows that fail the RPF check can be exported only when you have enabled the
flow statistics collection function on an interface.

Procedure
a. Run system-view
d. Run ip netstream rpf-failure inbound
RPF NetStream is enabled.
By default, NetStream is disabled from collecting statistics about flows that fail the
RPF check. Only statistics about incoming packets are collected.
a. Run system-view
Context
You can run commands to verify that exporting of statistics about flows that fail the RPF
check has been configured.
Procedure
NetStream cache.
configuration for IPv4 flows.


12.11 Configuring NetStream Interface Index Length
Context
The NMS obtains interface information of exported packets according to the interface indexes
in NetStream packets. Interface indexes consist of either 16 or 32 digits. NMS devices from
different vendors may use different numbers of digits in interface indexes. The number of
digits in the interface index used by the device must be the same as the number of digits in the
interface index used by the NMS. For example, if the NMS can parse 32-digit interface
indexes, set the number of digits in the interface indexes contained in exported NetStream
packets to 32.
Procedure
Step 2 Run ip netstream export index-switch index-switch
The number of digits in the interface index for exported NetStream packets is set.
By default, the NetStream exported packets contain 16-digit interface indexes.
----End

Run the display ip netstream { all | global } command to check the NetStream
configuration.
12.12 (Optional) Configuring the Function of Aggregating

Site Visitor Traffic on an Interface
Context
You can enable the function of aggregating site visitor traffic on an interface and report uplink
and downlink data on the interface to the Agile Controller.
Procedure

Step 3 Run ip netstream aggregation enable

The function of aggregating site visitor traffic is enabled on an interface.
By default, the function of aggregating site visitor traffic is disabled on an interface.
----End
12.13 Clearing NetStream Statistics
Context
The statistics cannot be restored after being deleted.
Procedure
l Run the reset ip netstream statistic command to clear NetStream statistics.
----End
12.14 Configuration Examples for NetStream

12.14.1 Example for Configuring IPv4 Original Flow Statistics
Exporting
As shown in Figure 12-4, departments 1 and 2 connect to the Internet through the router.
User wants to monitor communication between departments and the Internet, and perform
accounting based on the department.

Figure 12-4 Networking diagram of Configuring IPv4 Original Flow Statistics Exporting
Internet
GE1/0/0 NetStream server

GE2/0/0
10.1.1.1/24 10.1.2.2/24
10.1.2.1/24
GE4/0/0
GE3/0/0
10.1.4.1/24
Router 10.1.3.1/24
Department 1 Department 2
You can configure IPv4 original flow statistics exporting on GE1/0/0 of the router, collect
statistics about incoming traffic on the interface, and send the statistics to the NetStream
server for further analysis. In this way, you can monitor communication between departments
and the Internet, and perform accounting based on the department.
1. Configure IP addresses for interfaces on the router.
2. Configure NetStream sampling.
3. Configure NetStream flow aging.
4. Configure NetStream original flow statistics exporting.
5. Configure the version for exported packets.
6. Enable flow statistics collection on the interface.
Procedure
Step 1 Configure IP addresses for interfaces on the router as shown in Figure 12-4.
# Configure IP addresses for interfaces on the router.

Step 2 Configure NetStream sampling.

# Configure NetStream sampling on GE1/0/0, and set the sampling mode to packet-based
regular sampling and the sampling interval to 1200.
[Router-GigabitEthernet1/0/0] ip netstream sampler fix-packets 1200 inbound
[Router-GigabitEthernet1/0/0] ip netstream sampler fix-packets 1200 outbound
Step 3 Configure NetStream flow aging.

# Set the active aging time to 20 minutes and the inactive aging time to 100 seconds, and
enable FIN- and RST-based aging.
[Router] ip netstream timeout active 20
[Router] ip netstream timeout inactive 100
[Router] ip netstream tcp-flag enable
Step 4 Configure NetStream original flow statistics exporting.

# Set the source IP address of the exported packets carrying original flow statistics to
10.1.2.1, destination IP address to 10.1.2.2, and destination port number to 6000.
[Router] ip netstream export source 10.1.2.1
[Router] ip netstream export host 10.1.2.2 6000
Step 5 Configure the version for exported packets.

# Set the version of the exported packets to V9.
[Router] ip netstream export version 9
Step 6 Enable flow statistics collection on the interface.

# Enable flow statistics collection on GE1/0/0.
[Router-GigabitEthernet1/0/0] ip netstream inbound
[Router-GigabitEthernet1/0/0] ip netstream outbound

# Run the display ip netstream statistic command to check the configurations.
[Router] display ip netstream statistic
Origin ingress entries : 2
Origin ingress packets : 12
Origin ingress octets : 928
Origin egress entries : 2
Origin egress packets : 17
Origin egress octets : 1037
Origin total entries : 4
Agility ingress entries : 0
Agility ingress packets : 0
Agility ingress octets : 0
Agility egress entries : 0
Agility egress packets : 0
Agility egress octets : 0
Agility total entries : 0
Handle origin entries : 0
Handle agility entries : 0
Handle As aggre entries : 0
Handle ProtPort aggre entries : 0
Handle SrcPrefix aggre entries : 0
Handle DstPrefix aggre entries : 0
Handle Prefix aggre entries : 0

Handle AsTos aggre entries : 0

Handle ProtPortTos aggre entries : 0
Handle SrcPreTos aggre entries : 0
Handle DstPreTos aggre entries : 0
Handle PreTos aggre entries : 0
----End
Configuration Files
#
sysname Router
#
ip netstream timeout active 20
ip netstream timeout inactive 100
ip netstream tcp-flag enable
ip netstream export source 10.1.2.1
ip netstream export host 10.1.2.2 6000
ip netstream export version 9
#
ip address 10.1.1.1 255.255.255.0
ip netstream sampler fix-packets 1200 inbound
ip netstream sampler fix-packets 1200 outbound
ip netstream inbound
ip netstream outbound
#
ip address 10.1.2.1 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0
#
ip address 10.1.4.1 255.255.255.0
#
return
12.14.2 Example for Configuring IPv4 Aggregation Flow Statistics

Exporting
In Figure 12-5, departments 1 and 2 connect to the Internet through the router. The network
administrator needs to obtain key information from the communication packets between the
two departments and the Internet to know communication status and traffic information.

Figure 12-5 Networking diagram of Configuring IPv4 Aggregation Flow Statistics Exporting
Internet

GE2/0/0
10.1.1.1/24 10.1.2.2/24
10.1.2.1/24
GE4/0/0
GE3/0/0
10.1.4.1/24
Router 10.1.3.1/24
You can configure aggregation flow statistics exporting on GE1/0/0 of the router so that the
router collects statistics about incoming traffic on GE1/0/0 and exports the flow statistics to
the NetStream server for further analysis. Then you can know communication status and
traffic information.
2. Configure NetStream aggregation flow statistics exporting.
3. Configure the version for exported packets.
4. Enable flow statistics collection on the interface.
Procedure
# Configure IP addresses for interfaces on Router.
Step 2 Configure NetStream aggregation flow statistics exporting.

# Configure protocol-port aggregation, and set the source IP address of the exported packets
to 10.1.2.1, the destination IP address to 10.1.2.2, and the destination port number to 6000.
[Router] ip netstream aggregation protocol-port
[Router-aggregation-protport]ip netstream export source 10.1.2.1
[Router-aggregation-protport]ip netstream export host 10.1.2.2 6000
[Router-aggregation-protport]enable
Step 3 Configure the version for exported packets.

# Set the version of the exported packets carrying aggregation flow statistics to V9.
[Router-aggregation-protport] export version 9
[Router-aggregation-protport] quit
Step 4 Enable flow statistics collection on the interface.

# Enable flow statistics collection on GE1/0/0.

----End
Configuration Files
#
sysname Router
#
ip address 10.1.1.1 255.255.255.0

#
ip address 10.1.2.1 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0
#
ip address 10.1.4.1 255.255.255.0
#
ip netstream aggregation protocol-port
enable
export version 9
#
return
12.14.3 Example for Configuring IPv4 Flexible Flow Statistics

Exporting
In Figure 12-6, departments 1 and 2 connect to the Internet through the router. The network
administrator needs to monitor communication between the two departments and the Internet
and know the top websites visited by the two departments.
Figure 12-6 Networking diagram of Configuring IPv4 Flexible Flow Statistics Exporting
Internet

GE2/0/0
10.1.1.1/24 10.1.2.2/24
10.1.2.1/24
GE4/0/0
GE3/0/0
10.1.4.1/24
Router 10.1.3.1/24
You can configure flexible IPv4 flow statistics on GE1/0/0 of Router so that the Router
collects statistics about incoming traffic on the interface, and sends the statistics to the

NetStream server for further analysis. Then you can know the top websites visited by the two
departments.
2. Configure a flexible flow statistics template.
3. Configure NetStream flexible flow statistics exporting.
4. Enable flexible flow statistics collection on the interface.
Procedure
# Configure IP addresses for interfaces on the router.
Step 2 Configure a flexible flow statistics template.

# Create a flexible flow statistics template named test, configure aggregation based on the
destination IP address and destination port number, configure the number of bytes and packets
in the exported packets, and configure the indexes of the inbound and outbound interfaces.
[Router] ip netstream record test

[Router-record-test]match ipv4 destination-address
[Router-record-test]match ipv4 destination-port
[Router-record-test]collect interface input
[Router-record-test]collect interface output
[Router-record-test]collect counter bytes
[Router-record-test]collect counter packets
[Router-record-test]quit
Step 3 Configure NetStream flexible flow statistics exporting.

# Set the source IP address of the exported packets carrying flexible flow statistics to 10.1.2.1,
the destination IP address to 10.1.2.2, and destination port number to 6000.
[Router] ip netstream export source 10.1.2.1
[Router] ip netstream export host 10.1.2.2 6000
Step 4 Enable flexible flow statistics collection on the interface.

# Enable flexible flow statistics exporting on GE1/0/0, and apply the flexible flow statistics
template test to GE1/0/0.
[Router-GigabitEthernet1/0/0] port ip netstream record test
Info: Interface got a record config succeed.


----End
Configuration Files
#
sysname Router
#
ip netstream export version 9
ip netstream record test
#
ip netstream record test
match ipv4 destination-address
match ipv4 destination-port
collect counter packets
collect counter bytes
collect interface input
collect interface output
#
ip address 10.1.1.1 255.255.255.0
port ip netstream record test
#
ip address 10.1.2.1 255.255.255.0
#
ip address 10.1.3.1 255.255.255.0
#
ip address 10.1.4.1 255.255.255.0

#
return

and Monitoring 13 IP Accounting Configuration
13 IP Accounting Configuration
About This Chapter
This chapter describes the configurations of IP accounting, and provides configuration

examples.
13.1 Overview of IP Accounting
This section describes the background, types, and concepts of IP accounting.
13.2 Licensing Requirements and Limitations for IP Accounting
This section provides the points of attention when configuring IP Accounting.
13.3 Configuring IP Accounting
Configure IP accounting to collect statistics on the IP packets passing a router.
13.4 Maintaining IP Accounting
This section describes how to view and clear IP accounting statistics.
13.5 Configuration Examples for IP Accounting
This section provides an IP accounting configuration example, including networking
requirements and configuration roadmap.
13.1 Overview of IP Accounting

This section describes the background, types, and concepts of IP accounting.
The Internet technologies and services develop fast. Internet users have high requirements on
traffic statistics and analysis. The device's NetStream function provides comprehensive traffic
statistics for users. NetStream collects statistics on all network traffic and provides statistics
reports; however, it is complex and consumes a lot of resources. IP accounting only collects
statistics on IP packets.
Compared to NetStream, IP accounting is easy to configure, provides statistics fast, and
occupies a few resources. It effectively implements IP packet statistics with low costs.
IP accounting applies to the IPv4 packets sent and forwarded by a local router.

Type
The device provides common IP accounting and IP precedence accounting.
l Common IP accounting: collects packet statistics based on source IP addresses,

destination IP addresses, protocol numbers, number of packets, number of bytes, and
data flow update time. Each data flow is stored as one record in the statistics tables.
l IP precedence accounting: collects packet statistics based on IP precedences, number of
packets, and number of bytes. The packets with the same IP precedence are stored as one
record in the statistics tables.
The two IP accounting methods can collect statistics on either incoming and outgoing
packets; therefore, you must specify the direction to which IP accounting applies.
NOTE
IP precedence accounting is implemented based on common IP accounting. To use IP precedence
accounting, first enable common IP accounting first, and ensure that they apply to the same direction.
For example, to use IP precedence accounting on the packets received by an interface, first enable
common IP accounting for the incoming packets on the interface.
Concepts
l IP accounting rule
IP accounting rules only apply to common IP accounting, but do not apply to IP
precedence accounting.
An IP accounting rule consists of an IP address and a subnet mask. Each record in the
rule table is the AND result between an IP address and a subnet mask. IP accounting
matches the source or destination address of an IP packet against the rules. If an IP
packet matches a rule, the IP packet information is recorded in the matched table;
otherwise, the IP packet information is recorded in the mismatched table.
For example, a rule consists of IP address 192.168.0.1 and subnet mask 255.255.255.0:
– The IP packets originating from or destined for network segment 192.168.0.0/24
match the rule, so they are recorded in the matched table.
– Other packets do not match the rule, so they are recorded in the mismatched table.
NOTE
If you have enabled the common IP accounting function but do not configure IP accounting rules,
all packet information is recorded in the mismatched table.
l Statistics table upper threshold
There are two types of IP accounting statistics table upper thresholds as follows:
– Matched table upper threshold: specifies the maximum number of records stored in
the matched table.
– Mismatched table upper threshold: specifies the maximum number of records stored
in the mismatched table.
Statistics about IP precedence accounting are not recorded in matched or mismatched
table, but are stored in a dedicated table. This table does not have an upper threshold
because only 8 records can be stored in the table to match IP precedence 0-7.
l Aging time
The aging time only applies to the matched and mismatched tables of common IP
accounting. The records in the statistics table of IP precedence accounting will never be
aged out, and must be deleted manually.

If a statistics record is not updated within the aging time, the record is aged out and
deleted.
13.2 Licensing Requirements and Limitations for IP

Accounting
This section provides the points of attention when configuring IP Accounting.

None
IP Accounting is a basic feature of a router and is not under license control.
Feature Limitations
None
13.3 Configuring IP Accounting

Configure IP accounting to collect statistics on the IP packets passing a router.
Before configuring IP accounting, complete the following tasks:
l Connecting interfaces and setting physical parameters for the interfaces to ensure that the
physical status of interfaces is Up
l Setting parameters for data link layer protocols on interfaces to ensure that the data link
layer protocol status of the interfaces is Up
l Setting network layer protocol parameters for interfaces to ensure that the routing
protocol status on the interfaces is Up
13.3.1 (Optional) Configuring an IP Accounting Rule

Context
If you have enabled the common IP accounting function but do not configure IP accounting
rules, all packet information is recorded in the mismatched table.
Procedure
Step 2 Run ip accounting rule ip-address { mask | mask-length }
An IP accounting rule is configured.

By default, no IP accounting rule is configured.
----End
13.3.2 (Optional) Configuring Statistics Table Upper Thresholds
Context
Statistics tables include matched table and mismatched table:
l Matched table: stores statistics about the packets matching the IP accounting rules.
l Mismatched table: stores statistics about the packets not matching the IP accounting
rules. Additionally, if you do not configure IP accounting rules, all packet statistics of
common IP accounting are also recorded in this table.
NOTE
The default upper threshold value is 0, indicating that the table does not store packet statistics. If
you need to collect statistics on mismatched IP packets or enable common IP accounting without
configuring IP accounting rules, set the mismatched table upper threshold.
Procedure
Step 2 Set the upper thresholds as follows:

l Run the ip accounting matched-threshold thresh-value command to set the matched
table upper threshold. The default threshold is 512, indicating that a maximum of 512
can be stored in the matched table.
l Run the ip accounting mismatched-threshold thresh-value command to set the
mismatched table upper threshold. The default threshold is 0, indicating that no record
will be stored in the mismatched table.
----End
13.3.3 (Optional) Configuring the Aging Time
Context
If a statistics record is not updated within the aging time, the record is aged out and deleted.
By using the aging time, IP accounting can delete unneeded statistics records, which may
make the statistics inaccurate.
Procedure
Step 2 Run ip accounting timeout time-value
The aging time is set.
By default, the aging time of IP accounting statistics records is 720 minutes (12 hours).

NOTE
The aging time only applies to the matched and mismatched tables of common IP accounting. The
records in the statistics table of IP precedence accounting will never be aged out, and must be deleted
manually using the reset ip accounting precedence command.
----End
13.3.4 Enabling IP Accounting
Context
The router provides common IP accounting and IP precedence accounting:
l Common IP accounting: collects packet statistics based on source IP addresses,

destination IP addresses, protocol numbers, number of packets, number of bytes, and
data flow update time. Each data flow is stored as one record in the statistics tables.
l IP precedence accounting: collects packet statistics based on IP precedences, number of
packets, and number of bytes. The packets with the same IP precedence are stored as one
record in the statistics tables.
Procedure
Step 3 Run ip accounting { input-packets | output-packets }
Common IP accounting is enabled on the router.
Step 4 (Optional) Run ip accounting precedence { input-packets | output-packets }
IP precedence accounting is enabled on the router.
NOTE
The directions to which common IP accounting and IP precedence accounting apply must be the same.
----End
Prerequisites
The IP accounting configurations are complete.
Procedure
l Run the display ip accounting rule command to view IP accounting rules.
----End

13.4 Maintaining IP Accounting

This section describes how to view and clear IP accounting statistics.
13.4.1 Displaying IP Accounting Statistics
Context
IP accounting applies to incoming and outgoing packets on an interface.
If there are too many statistics records, you can choose to display the top 32 records with the
most packets.
Procedure
Step 1 Run the display ip accounting input-packets { matched | mismatched } [ top ] command
to display statistics about incoming packets.
Step 2 Run the display ip accounting output-packets { matched | mismatched } [ top ] command
to display statistics about outgoing packets.
Step 3 Run the display ip accounting precedence command to display statistics about incoming and
outgoing packets in IP precedence accounting.
----End
13.4.2 Clearing IP Accounting Statistics
Context
Before collecting packet statistics, you should clear existing statistics records; otherwise,
statistics are inaccurate. If you do not clear them, the records will not be deleted until the
aging time expires.
IP accounting statistics cannot be restored after they are cleared. Exercise caution when you
use the command.
Procedure
Step 1 Run the reset ip accounting { all | matched | mismatched | precedence } command in the
user view to clear IP accounting statistics.
----End

13.5 Configuration Examples for IP Accounting

This section provides an IP accounting configuration example, including networking
requirements and configuration roadmap.
13.5.1 Example for Configuring IP Accounting

This section provides the IP accounting configuration procedure.
As shown in Figure 13-1, host A and host B connect to GE1/0/0 of the router through a
switch, and host C is connected to GE2/0/0. Statistics about the IP packets from host A and
host B to GE1/0/0 need to be collected, and statistics about the IP packets received on
GE2/0/0 need to be collected based on IP precedence.
The IP address of GE1/0/0 is 192.168.1.1/24, of host A is 192.168.1.100/24, and of host B is

192.168.1.200/24. The IP address of GE2/0/0 is 192.168.2.1/24 and of host C is
192.168.2.10/24.
Figure 13-1 Networking diagram of IP accounting configuration

Host A
192.168.1.100/24
GE1/0/0 Router
192.168.1.1/24
GE2/0/0
192.168.2.1/24
Host B
192.168.1.200/24
Host C
192.168.2.10/24
1. Configure IP accounting rules for host A and host B.

2. Enable common IP accounting on GE1/0/0.
3. Enable IP precedence accounting on GE2/0/0.

Procedure
Step 1 Configure IP accounting on the router.
# Configure an IP address for GE1/0/0.
# Configure an IP address for GE2/0/0.

# Configure IP accounting rules on the router.

[Router] ip accounting rule 192.168.1.0 255.255.255.0
# Enable common IP accounting for the IP packets received by GE1/0/0.

[Router-GigabitEthernet1/0/0] ip accounting input-packets
# Enable IP precedence accounting for the IP packets received by GE2/0/0.

[Router-GigabitEthernet2/0/0] ip accounting input-packets
[Router-GigabitEthernet2/0/0] ip accounting precedence input-packets
[Router] quit

# Run the display ip accounting input-packets matched command on the router to view
statistics about the IP packets sent by host A and host B.
<Router> display ip accounting input-packets matched
The matched list contains 2 incoming streams.
Source Destination Protocol Packets Bytes Age(Unit:Min)
192.168.1.100 192.168.200.155 1 10 840 10
192.168.1.200 192.168.200.155 1 1 100 10
# Run the display ip accounting precedence command on the router to view statistics about
the IP packets received by GE2/0/0. The statistics are displayed based on IP precedence.
<Router> display ip accounting precedence
Precedence Packets Bytes
Input
0 4611010 392075935
6 10 840
Output
----End
Configuration File
#
sysname Router
#

ip accounting rule 192.168.1.0 255.255.255.0

#
ip address 192.168.1.1 255.255.255.0
ip accounting input-packets
#
ip address 192.168.2.1 255.255.255.0
ip accounting input-packets
ip accounting precedence input-packets
#
return

and Monitoring 14 TWAMP Light Configuration
14 TWAMP Light Configuration
About This Chapter
14.1 Overview of TWAMP Light

14.2 Understanding TWAMP Light
14.3 Application Scenarios for TWAMP Light
14.4 Licensing Requirements and Limitations for TWAMP Light
14.5 Default Settings for TWAMP Light
14.6 Configuring TWAMP Light
14.7 Configuration Examples for TWAMP Light
14.1 Overview of TWAMP Light
Definition
Two-Way Active Measurement Protocol (TWAMP) Light is a light version of TWAMP.
TWAMP Light measures the round-trip performance of an IP network by using simplified
control protocol to establish test sessions.
Purpose
Traditional IPRAN networks lack an effective, simple, and universal OAM performance
measurement tool. Most vendors use proprietary features, such as Network Quality Analysis
(NQA), to measure performance of IP networks. However, NQA is not a public protocol. The
devices running NQA from different vendors cannot interwork with each other, and NQA is
difficult to deploy. The IETF IP performance monitoring (IPPM) team proposed a series of
protocols to address the issues in IP network performance measurement. TWAMP is one of
the IP network performance measurement tools applied to IP networks.
TWAMP defines a standard method for across-network performance measurement. It includes
two structures: standard structure and light structure (TWAMP Light). TWAMP Light allows

a router to send detection packets to itself and the control modules in the TWAMP Light
structure can be deployed in a centralized manner. This reduces requirements on the reflector
and facilitates reflector deployment.
Benefits
TWAMP Light is an IP link detection technology. It can monitor network quality, including
delay, jitter, and packet loss, and is easy to deploy and use.
14.2 Understanding TWAMP Light
Related Concepts
TWAMP Light includes two modes: on-demand and continual.
l On-demand measurement: indicates that performance measurement is started manually
within the specified time range aiming at network fault diagnosis. It is a one-off
measurement in the diagnosis period.
l Continual measurement: indicates the measurement is performed continuously.
TWAMP Light Working Mechanism

To perform TWAMP Light performance measurement, you need to create a measurement
service first.
1. Measurement service creation
Figure 14-1 TWAMP Light measurement service creation

NMS
Internet
RouterB RouterA
Responder Controller
In Figure 14-1, the controller is the sender and responder is the reflector.
a. The controller creates a measurement session based on the local IP address,
responder's IP address, local UDP port number, responder's UDP port number, and
VPN instance name.
b. The responder creates a measurement session based on the controller's IP address,
local IP address, controller's UDP port number, local UDP port number, and VPN
instance name.
c. The controller starts performance measurement in on-demand mode or continual
mode. After the measurement starts, the controller sends a TWAMP-Test packet of
the UDP type to the responder. The TWAMP-Test packet carries the packet sending
time and sequence number.

The start mode decides the measurement mode. If on-demand measurement is used,
performance measurement is started manually within the specified time range
aiming at network fault diagnosis. It is a one-off measurement in the diagnosis
period. If continual measurement is used, performance measurement is non-stop.
d. The responder replies to the TWAMP-Test packet sent by the controller. The
returned TWAMP-Test packet carries the packet receiving time stamp, response
time stamp, and sequence number. The responder does not generate a sequence
number. Instead, it copies the sequence number in the TWAMP-Test packet sent by
the controller.
The responder calculates the performance indexes such as bidirectional packet loss
rate, delay, and jitter based on the sequence numbers and time stamps in the
TWAMP-Test packets.
2. Performance measurement
TWAMP Light defines TWAMP-Test packets in two directions:
– Test-request: packet sent from controller to responder.
– Test-response: packet sent from responder to controller.
Figure 14-2 TWAMP Light performance measurement
In Figure 14-2, after a measurement service is created, the TWAMP-Test packets are
used as the probes for performance measurement and the packets use the pre-defined
measurement session IP address and UDP port number. The controller sends a TWAMP-
Test packet. After receiving the packet, the responder returns the Test-response packet to
the controller. The controller collects statistics on TWAMP measurement. The
performance measurement process is as follows:
a. After receiving the Test-response packet from the responder, the controller
calculates the bidirectional packet loss rate, delay, and jitter based on the sequence
number and time stamp in the packet.
Delay
The delay is calculated based on time stamps. The TWAMP-Test packet sent by the
controller carries the sending time t1, the TWAMP-Test packet sent by the

responder carries the receiving time t1' and reply time t2', and the TWAMP-Test
packet received by the controller carries the receiving time t2. The delay is
calculated based on the four time stamps.
Delay1 = t2 - t1- ( t2' - t1')
Jitter
The jitter is calculated based on the absolute delays in neighboring measurement
intervals.
Based on the preceding delay formula, the delay in the neighboring interval is
Delay2 = t4 - t3 - (t4' - t3').
Jitter = | Delay2 - Delay1 |
Packet loss rate
The TWAMP-Test sent by the controller carries a sending sequence number, but the
responder does not generate a sequence number. Instead, the responder copies the
sequence number in the TWAMP-Test sent by the controller as the response
sequence number. The packet loss rate is calculated based on the numbers of sent
and received packets.
Packet loss rate = Number of lost packets/Total number of sent packets
b. The controller reports the performance statistics to the NMS, and you can view the
statistics on the web system.
In different modes, the controller reports statistics to the NMS as follows:
n Continual measurement: The controller reports statistics to the NMS through
the Performance Monitoring (PM) module.
n On-demand measurement: The controller reports statistics to the NMS through
MIB.
14.3 Application Scenarios for TWAMP Light

In Figure 14-3, users access the network through routers. TWAMP Light is run between
router 1 and router 2. Router 1 functions as the controller and router 2 functions as the
responder. After a measurement service is created on the controller and responder, the IP
performance of the network can be measured. You can obtain the network running statistics
and service quality.
Figure 14-3 Know service quality through TWAMP Light
Network
Router1 Router2
Controller Responder
14.4 Licensing Requirements and Limitations for TWAMP

Light


None
TWAMP Light is a basic feature of a router and is not under license control.
Feature Limitations
NOTE
AR3670 do not support TWAMP Light.
14.5 Default Settings for TWAMP Light

Table 14-1 lists the default settings of TWAMP Light.
Table 14-1 Default settings for TWAMP Light
TWAMP Light Disabled

Client
Test-response packet 5s
timeout within the
sampling interval.
DSCP value of 0
packets sent during
session creation
Session padding 128

length
14.6 Configuring TWAMP Light
Before configuring TWAMP Light, complete the following tasks:
l Ensure that the devices on the network support TWAMP Light.

l Ensure that the route between controller and responder is reachable and the IP link works
normally.
14.6.1 Configuring the TWAMP Light Responder

Procedure
Step 2 Run nqa twamp-light
The TWAMP Light service is created and the TWAMP Light view is displayed.
By default, the TWAMP Light service is not created.
Step 3 Run responder
The TWAMP Light Responder function is enabled and the TWAMP Light Responder view is
displayed.
By default, the TWAMP Light Responder function is disabled.
Step 4 Run test-session session-id local-ip local-ip-address remote-ip remote-ip-address local-port
local-port remote-port remote-port [ vpn-instance vpn-instance-name ] [ description
description ]
A measurement session is created on the responder.
By default, no measurement session is created on the responder.
l After a session is created, its parameters cannot be modified. To modify the session
parameters, delete the session and create it again.
l The IP address must be a unicast address.
l The UDP port of the sender must be a port that is not occupied.
l All the parameters related to the VPN instance must exist. When the VPN instance is
deleted, the related measurement instance is also deleted.
----End
14.6.2 Configuring the TWAMP Light Controller
Procedure
Step 1 Configure the TWAMP Light Client.
1. Run the system-view command to enter the system view.
2. Run the nqa twamp-light command to create the TWAMP Light service and enter the
TWAMP Light view.
3. Run the client command to enable the TWAMP Light Client function and enter the
TWAMP Light Client view.
By default, the TWAMP Light Client function is disabled.
4. Run the test-session session-id sender-ip sender-ip-address reflector-ip reflector-ip-
address sender-port sender-port reflector-port reflector-port [ vpn-instance vpn-
instance-name ] [ dscp dscp-value | padding padding-length | description description ]
* command to create a measurement session.
By default, no measurement session is created.

– After a session is created, its parameters cannot be modified. To modify the session
parameters, delete the session and create it again.
– The IP address must be a unicast address. By default, the DSCP field in a sent
packet is 0 and the packet padding length is 128.
– The UDP port of the sender must be a port that is not occupied.
– All the parameters related to the VPN instance must exist. When the VPN instance
is deleted, the related measurement instance is also deleted.
– To configure a session with multiple DSCP values, you can specify different UDP
port numbers for sender. The following are two examples:
n Session 1: test-session 1 sender-ip 1.1.1.1 reflector-ip 2.2.2.2 sender-port
1025 reflector-port 1025 dscp 3
n Session 2: test-session 2 sender-ip 1.1.1.1 reflector-ip 2.2.2.2 sender-port
1026 reflector-port 1025 dscp 6
Step 2 Configure the TWAMP Light Sender.

1. Run the system-view command to enter the system view.
2. Run the nqa twamp-light command to enter the TWAMP Light view.
3. Run the sender command to enable the TWAMP Light Sender function and enter the
TWAMP Light Sender view.
By default, the TWAMP Light Sender function is disabled.
NOTE
If you have not quitted from the TWAMP Light Client view, you can also run the sender
command to enter the TWAMP Light Sender view.
4. Start TWAMP Light performance measurement.
The controller starts performance measurement in on-demand mode or continual mode.
To measure performance only once, enable on-demand measurement. To measure
performance continuously, enable continual measurement.
– To enable on-demand measurement, run the test start test-session session-id
{ duration duration | packet-count packet-count } [ period { 10 | 100 | 1000 |
30000 } ] [ time-out time-out ] command.
– To enable continual measurement, run the test start-continual test-session session-
id [ period { 10 | 100 | 1000 | 30000 } ] [ time-out time-out ] command.
By default, the packet sending interval is 100 ms and timeout interval is 5s.
NOTE
n On-demand measurement: indicates that performance measurement is started manually

within the specified time range aiming at network fault diagnosis. It is a one-off
measurement in the diagnosis period. The measurement stops when the specified interval
is expired or a certain number of packets are sent.
n Continual measurement: indicates the measurement is performed continuously.
n If you enable continual measurement during an on-demand measurement, the on-demand
measurement immediately stops and the continual measurement starts.
----End

Procedure
l Run the display twamp-light statistic-type { twoway-delay | twoway-loss } test-
session session-id command to view bidirectional delay or packet loss information of a
TWAMP Light session.
l Run the display twamp-light test-session [ verbose | session-id ] command to display
real-time measurement session information.
l Run the display twamp-light responder test-session [ verbose | session-id ] command
to display real-time measurement session information on the TWAMP Light responder.
----End
14.7 Configuration Examples for TWAMP Light
14.7.1 Example for Configuring the TWAMP Light Service in

Continual Mode
On an IP network shown in Figure 14-4, router A is the controller and router B is the
responder. Router A receives and sends measurement session packets, collects performance
data, and reports measurement results to the NMS, and router B only responds to the
measurement session packets.
The network administrator wants to monitor network performance between router A and
router B continuously. The TWAMP Light performance measurement can be configured.
Figure 14-4 TWAMP Light network diagram

NMS
192.168.1.4 192.168.1.3
Network
RouterB RouterA
1. Configure router B (TWAMP Light responder).
2. Configure router A (TWAMP Light controller).
a. Create a measurement session.
b. Enable continual measurement.

NOTE
Before performing continual or on-demand measurement, you must create a measurement session in the
TWAMP Light service. It is recommended that you configure router B, and then router A.
Procedure
Step 1 Configure the TWAMP Light Responder.
<huawei> system-view
[huawei] sysname RouterB
[RouterB] nqa twamp-light
[RouterB-twamp-light] responder
[RouterB-twamp-light-responder] test-session 2 local-ip 192.168.1.4 remote-ip
192.168.1.3 local-port 2004 remote-port 2003
Step 2 Configure the TWAMP Light Controller.

1. Create a measurement session.
[huawei] sysname RouterA
[RouterA] nqa twamp-light
[RouterA-twamp-light] client
[RouterA-twamp-light-client] test-session 2 sender-ip 192.168.1.3 reflector-
ip 192.168.1.4 sender-port 2003 reflector-port 2004
2. Enable continual measurement.

[RouterA-twamp-light-client] sender
[RouterA-twamp-light-sender] test start-continual test-session 2
# Verify the responder.

[RouterB-twamp-light-responder] display twamp-light responder test-session 2
Session ID : 2
Local IP : 192.168.1.4
Local Port : 2004
Remote IP : 192.168.1.3
Remote Port : 2003
Mode : unauthenticated
VPN Instance :
Description : -
# Verify the controller.

[RouterA-twamp-light-sender] display twamp-light test-session 2
Session ID : 2
State : active
Type : continual
Sender IP : 192.168.1.3
Sender Port : 2003
Reflector IP : 192.168.1.4
Reflector Port : 2004
DSCP : 0
Padding Length : 128
VPN Instance :
Last Start Time : 2015-02-16 13:28:27 00:00
Last Stop Time : never
Period Time(in millisecond) : 100
Time Out(in second) : 5
Duration Time(in second) : -
Packet Count : -
Sequence Number : 0
Test Tx Number : 0

Test Rx Number : 0
Test Discard Number : 0
----End
Configuration Files
#
sysname RouterB
#
nqa twamp-light
responder
test-session 2 local-ip 192.168.1.4 remote-ip 192.168.1.3 local-port 2004
remote-port 2003
#

#
sysname RouterA
#
nqa twamp-light
client
test-session 2 sender-ip 192.168.1.3 reflector-ip 192.168.1.4 sender-port
2003 reflector-port 2004
sender
test start-continual test-session 2
#
14.7.2 Example for Configuring the TWAMP Light Service in On-

Demand Mode
On an IP network shown in Figure 14-5, router A is the controller and router B is the
responder. Router A sends and receives measurement session packets, collects performance
statistics, and sends measurement results to the NMS. Router B only responds to the
measurement session packets.
The network administrator wants to view network performance between router A and router
B. The TWAMP Light performance measurement can be configured.
Figure 14-5 TWAMP Light network diagram

NMS
192.168.1.1 192.168.1.2
Network
RouterB RouterA

1. Configure router B (TWAMP Light responder).

2. Configure router A (TWAMP Light controller).
a. Create a measurement session.
b. Enable on-demand measurement.
NOTE
Before performing continual or on-demand measurement, you must create a measurement session in the
TWAMP Light service. It is recommended that you configure router B, and then router A.
Procedure
Step 1 Configure the TWAMP Light Responder.
[huawei] sysname RouterB
[RouterB] nqa twamp-light
[RouterB-twamp-light] responder
[RouterB-twamp-light-responder] test-session 1 local-ip 192.168.1.1 remote-ip
192.168.1.2 local-port 2001 remote-port 2002
Step 2 Configure the TWAMP Light Controller.

1. Create a measurement session.
[huawei] sysname RouterA
[RouterA] nqa twamp-light
[RouterA-twamp-light] client
[RouterA-twamp-light-client] test-session 1 sender-ip 192.168.1.2 reflector-
ip 192.168.1.1 sender-port 2002 reflector-port 2001
2. Start on-demand measurement.

[RouterA-twamp-light-client] sender
[RouterA-twamp-light-sender] test start test-session 1 packet-count 30000

# Verify the responder.
[RouterB-twamp-light-responder] display twamp-light responder test-session 1
Session ID : 1
Local IP : 192.168.1.1
Local Port : 2001
Remote IP : 192.168.1.2
Remote Port : 2002
VPN Instance :
Description : -
# Verify the controller.

[RouterA-twamp-light-sender] display twamp-light test-session 1
Session ID : 1
State : active
Type : on-demand
Sender IP : 192.168.1.2
Sender Port : 2002
Reflector IP : 192.168.1.1
Reflector Port : 2001
DSCP : 0
Padding Length : 128
VPN Instance :
Last Start Time : 2015-02-16 13:09:05 00:00
Last Stop Time : never
Period Time(in millisecond) : 100

Time Out(in second) : 5

Duration Time(in second) : 0
Packet Count : 30000
Sequence Number : 0
Test Tx Number : 0
Test Rx Number : 0
Test Discard Number : 0
----End
Configuration Files
#
sysname RouterB
#
nqa twamp-light
responder
test-session 1 local-ip 192.168.1.1 remote-ip 192.168.1.2 local-port 2001
remote-port 2002
#

#
sysname RouterA
#
nqa twamp-light
client
test-session 1 sender-ip 192.168.1.2 reflector-ip 192.168.1.1 sender-port
2002 reflector-port 2001
sender
test start test-session 1 packet-count 30000
#

and Monitoring 15 AR and Controller Interconnection Configuration
15 AR and Controller Interconnection

Configuration
About This Chapter
15.1 Overview of AR and Controller Interconnection Configuration

15.2 Understanding AR and Controller Interconnection Configuration
15.3 Application Scenarios for AR and Controller Interconnection Configuration
15.4 Summary of AR and Controller Interconnection Configuration Tasks
15.5 Licensing Requirements and Limitations for AR and Controller Interconnection
15.6 Connecting an AR to the Controller
15.7 Configuration Examples for AR and Controller Interconnection
15.1 Overview of AR and Controller Interconnection

Configuration
Definition
Controller: a cloud management platform that delivers service configurations, monitors
performance, and provides fault location to network devices using the Network Configuration
Protocol (NETCONF).
NETCONF: provides a mechanism to install, maintain, and delete configurations of network
devices. You can use NETCONF to obtain configurations and status of the network devices.
NETCONF-enabled network devices provide standard Application Programming Interfaces
(APIs) for application developers to develop customized network management software on
third-party software. This network management software facilitates network device
management.

Purpose
As network scale and complexity increase, the traditional Simple Network Management
Protocol (SNMP) cannot meet requirements for easy management (especially configuration
management) of complex networks. Extensible Markup Language (XML)-based NETCONF
is an effective method to address the network configuration and management problems. After
devices are connected to the controller, you can log in to the controller to configure and
manage the devices on the graphic user interface (GUI).
15.2 Understanding AR and Controller Interconnection

Configuration
Figure 15-1 shows the connections between the devices and controller.
Figure 15-1 Connections between devices and controller

Controller
Controller uniformly 3
manages devices
2 Registration and
authentication, setting up
a NETCONF channel
Egress
gateway
1
Obtain
controller
information
...
RouterA RouterN
NETCONF channel
1. The devices obtain controller information, including the controller's IP address and
domain name and port number matching the controller's IP address and domain name.
– Factory settings: The controller information is contained in the configuration file
before delivery.
– USB-based deployment: The controller information is obtained during USB-based
deployment.
– DHCP: After a device connects to the network, the device functions as a DHCP
client to send a request packet to the DHCP server. The DHCP server (which can be
an egress gateway or an independent DHCP server) sends a DHCP packet to the

device. The Option 148 field in the packet sent by the DHCP server contains the
controller's information.
– Command line: The controller information is configured on the device using
commands.
2. The controller registers devices.
a. After obtaining the controller's information, the device registers with the controller.
b. A NETCONF channel is set up: The device functions as a client to set up a TCP
connection with the controller. Based on the TCP connection, the device functions
as an SSH server to set up an SSH tunnel with the controller. During tunnel setup,
the device and controller use bidirectional CA certificate for authentication. Based
on the SSH tunnel, the device as the NETCONF server and the controller as the
NETCONF client exchange control packets.
c. The controller queries and verifies the ESN of the device. After the verification is
successful, the controller notifies the device of successful registration.
3. The controller uniformly manages devices.
After a transmission channel is set up using NETCONF, the controller can manage the
devices, for example, issuing configurations to implement batch service configuration.
15.3 Application Scenarios for AR and Controller

Interconnection Configuration
The controller allows you to centrally manage devices and configure services in a batch,
without compromising network security and scalability.
In Figure 15-2, the controller is deployed on the server, and AR routers are located on the
user network. You can log in to the controller to manage AR routers using graphic user
interface (GUI).
Figure 15-2 Connecting AR routers to the controller
Router A Branch 1
.
Internet .
.
Controller
Router N Branch N
15.4 Summary of AR and Controller Interconnection

Configuration Tasks
Table 15-1 describes the scenarios and configuration tasks.

Table 15-1 Device and controller interconnection tasks

Scenario Description Task
Factory setting The configuration file 15.6.3 Adding an AR to the Controller

before delivery includes
the controller information
and management IP
address. After a device
connects to the network,
the device actively
registers with the
controller. You only need
to add AR routers to the
controller, and then the
controller uniformly
manages the devices.
If the configuration file
has been customized
according to the live
network situation, this
method can be used. The
controller information in
the configuration file
before delivery must be
the same as the controller
information on the live
network. If the controller
information in the
configuration file is
inconsistent with the
controller information on
the live network, you must
manually modify the
configuration file or use
the command line method.

USB-based The controller information 1. For details about USB-based

deployment and management IP deployment, see USB-based
address are obtained Deployment Configuration in the
during USB-based Huawei AR Series Access Routers
deployment. After a Configuration Guide - Basic
device connects to the Configuration.
network and has a USB 2. 15.6.3 Adding an AR to the
flash drive installed, the Controller
device actively registers
with the controller. You
only need to add AR
routers to the controller,
and then the controller
uniformly manages the
devices.
If the devices on the
network are deployed
using the USB flash drive,
you can choose this
method. You need to add
the controller information
when creating the index
file.

DHCP After a DHCP-enabled 15.6.3 Adding an AR to the Controller

device connects to the
network, the DHCP server
(which may be an egress
gateway or an independent
DHCP server) sends a
DHCP packet to the
device. The Option 148
field in the packet includes
the controller information.
The device also obtains
the management IP
address. After obtaining
controller information, the
devices actively registers
with the controller. You
only need to add AR
routers to the controller,
and then the controller
uniformly manages the
devices.
This method requires that
the Option 148 (carrying
controller information) be
configured on the DHCP
server. The device
functions as a DHCP
client to obtain controller
information and
management IP address
from the DHCP server.
Command line After a device connects to 1. 15.6.1 Configuring Network

the network, you need to Connection Between Components
run the related commands of Routers and Controller Cloud
on the device to obtain Management Platform
controller information. 2. 15.6.2 Connecting Routers to the
After obtaining controller Controller Cloud Management
information, the devices Platform
actively registers with the
controller. In addition, you 3. 15.6.3 Adding an AR to the
need to add AR routers to Controller
the controller, and then the 4. 15.6.5 Verifying the Configuration
controller uniformly
manages the devices.
This method is complex,
and is applicable to the
networks with a small
number of devices.

15.5 Licensing Requirements and Limitations for AR and

Controller Interconnection
The router must work with the controller, which is Agile Controller-Cloud Manager running
V200R002C00 or a later version.
Connecting to the controller is a basic capability of an AR router and is not under license
control.
Feature Limitations
Only AR161, AR161W, AR161EW, AR169EW, AR169EGW-L, AR161F, AR161FGW-L,
AR161FW, AR168F, AR169F, AR169FGW-L, AR1220C, AR1220E, AR2204-27GE,
AR2204-27GE-P, AR2204-51GE-P, AR2204-51GE, AR2204-51GE-R, AR2204XE, AR2220,
AR2220E, AR2240, AR2240C, AR3260, and AR3670 support this feature.
15.6 Connecting an AR to the Controller
15.6.1 Configuring Network Connection Between Components of

Routers and Controller Cloud Management Platform
Prerequisites
Routers are connected to a controller cloud management platform.
Context
Figure 15-3 shows the network where the routers and controller are located, and the
controller manages the routers.

Figure 15-3 Connections between routers and controller and basic structure
Controller
Internet
Router A Router B
Router Router OSP
br0
veth1 veth1
Host OS Host OS
Routing system virtual interface

Default virtual interface
Physical interface
The two structures involve the following modules:

l Router
This is a routing system that provides functions of a traditional AR router.
l Host OS
This is the basic operating system that provides basic system services to other service
modules.
l OSP
This is the open service platform where third-party applications can be installed.
The routing system communicates with the controller through the upstream interface over the
Internet, and communicates with the internal Host OS through a default virtual link. The Host
OS is the basic system for other service modules. Therefore, if you want to manage routers on
the controller, configure the network connection between Controller and Host OS. If a router
supports the OSP daughter card, the routing system and OSP daughter card communicate with
each other through physical links. If you want to manage the OSP daughter card on the
controller, configure the network connection between the controller and OSP daughter card.

Procedure
Step 1 Configure network connection between the routing system and Host OS.
1. Run system-view
2. Run dhcp enable
DHCP is enabled.
By default, DHCP is disabled.
The view of the routing system virtual interface is displayed.
The virtual interfaces of different models are as follows:
– AR3670: GE0/0/0-GE0/0/7
– Other models: GE0/0/6
4. Run ip address ip-address { mask | mask-length }
An IP address is configured for the routing system virtual interface.
5. Run dhcp select interface
The DHCP server function is configured to assign IP addresses to clients from the
interface address pool.
By default, the DHCP server function for assigning IP addresses from the interface
address pool is disabled.
After this function is enabled, the system assigns an IP address to the Host OS virtual
interface veth1 from the address pool on the routing system virtual interface. Check the
IP address of veth1:
a. Run the shell command in the diagnostic view to enter the shell view.
b. Run the ifconfig command to view the IP address of veth1.
c. Run the exit command to quit the shell view.
6. Run quit
Step 2 (Optional) Configure network connection between the routing system and OSP daughter card.
This step is required on only the router supporting OSP daughter card.
The view of the routing system physical interface is displayed.
2. Run ip address ip-address { mask | mask-length }
An IP address is configured for the routing system physical interface.
3. Run dhcp select interface
The DHCP server function is configured to assign IP addresses to clients from the
interface address pool.
By default, the DHCP server function for assigning IP addresses from the interface
address pool is disabled.

After this function is enabled, the system assigns an IP address to the virtual interface
br0 of the OSP daughter card from the address pool on routing system physical interface.
Check the IP address of br0:
a. Run the set output-mode osp command in the system view to enable the
redirection from the serial port to the OSP daughter card.
b. Run the ifconfig command to view the IP address of br0.
c. Run the Ctrl+D command to quit the OSP daughter card view.
4. Run quit
Step 3 Configure network connection between the Host OS (or OSP daughter card) and controller
cloud management platform.
The view of the physical interface between the routing system and controller cloud
management platform is displayed.
2. Run nat server protocol { protocol-number | icmp | tcp | udp } global global-address
inside host-address
The IP address of the Host OS virtual interface is mapped to an external IP address to
implement network connection between the Host OS and controller.
The value of global-address cannot be the same as an existing IP address on the router
and must be in the same subnet with the IP address used to communicate with external
network.
3. (Optional) Run nat server protocol { protocol-number | icmp | tcp | udp } global
global-address inside host-address
The IP address of the OSP daughter card virtual interface is mapped to an external IP
address to implement network connection between the OSP daughter card and
Controller.
This step is required on only the router supporting OSP daughter card.
The value of global-address cannot be the same as an existing IP address on the router
and must be in the same subnet with the IP address used to communicate with external
network.
4. Run quit
----End
Follow-up Procedure
l Check whether the network connection between Host OS and controller is successful.
a. Run the shell command in the diagnostic view to enter the shell view.
b. Run the ping command to check connectivity between the Host OS and controller.
l (Optional) Check whether the network connection between OSP daughter card and
controller is successful.
a. Run the set output-mode osp command in the system view to enable the
redirection from the serial port to the OSP daughter card.

b. Run the ping command to check connectivity between the OSP daughter card and
controller.
15.6.2 Connecting Routers to the Controller Cloud Management

Platform
Context
When a controller manages routers in a centralized manner, configure the controller's IP
address/domain name and port number on routers so that the routers can communicate with
the controller.
Procedure
Step 2 Run agile controller host host port port
The controller's IP address/domain name and port number are specified.
By default, the controller's IP address/domain name and port number are not specified.
Step 3 (Optional) Run agile sub-node ip-address ip-address interface interface-type interface-
number
The IP address and interface are specified for the OSP daughter card.
By default, no IP address or interface is specified for an OSP daughter card.
If a router has an OSP daughter card installed, configure sub-nodes on the router and specify
the IP address and interface of the OSP daughter card, to synchronize information from the
OSP daughter card to the controller.
----End
15.6.3 Adding an AR to the Controller
Prerequisites
The ESN of the AR has been obtained.
Context
The AR's ESN needs to be added to the controller. After the AR goes online and successfully
registers, the controller can manage the AR.
Procedure
Step 1 Log in to the controller using an administrator account.
Step 2 Choose Resource > Device in the main menu.

Step 3 In the navigation tree, choose Device.
Step 4 Click Add Device and enter the ESN, as shown in Figure 15-4.
Figure 15-4 Add Device
NOTE
To import devices in a batch, click Batch Import on the Add Device page. Download the template.xls
file, fill in the device information, and import the file to the controller.
----End
15.6.4 (Optional) Enabling Reporting of Statistics to the

Controller
Context
If you want to view NQA, NetStream, TCP FPM, or device information statistics on the
controller, enable the function of reporting the statistics to the controller.
This method is only supported in the SD-WAN solution, in which a controller is used.
Procedure


Step 2 Run pm report enable
The function of reporting device statistics to the controller is enabled.
By default, device statistics are not reported to the controller.
----End

l Run the display ip pool interface interface-pool-name command in any view to check
the IP addresses of the Host OS virtual interface and the default virtual interface of OSP
daughter card.
l Run the display nat server command in any view to check the mapping addresses on
Host OS and OSP daughter card.
l Run the display agile-controller status command in any view to check the connection
status between the device and controller.
15.7 Configuration Examples for AR and Controller

Interconnection
15.7.1 Example for Connecting AR routers to Controller Through

Factory Setting
On a network with complex topology and high-density devices, you can use a controller to
manage network devices.
In Figure 15-5, the controller is deployed on the server, the AR routers are located on the user
network, and the AR routers and controller can communicate with each other. The controller's
IP address, domain name, and port number matching the IP address/domain name is included
in the configuration file before delivery.

Figure 15-5 AR routers communicate with the controller using factory setting
Controller
3
IP Address:10.1.2.1/24
Port:4999
Egress Gateway
GE0/0/0 GE0/0/0
10.1.1.1/24 10.1.1.2/24
……
RouterA RouterN
1. Add AR routers to the controller.
2. On the controller, check the connection status between AR routers and controller.
Procedure
Step 1 Add the AR router to the controller.
1. Log in to the controller using an administrator account.
2. Choose Resource > Device in the main menu.
3. In the navigation tree, choose Device.
4. Click Add Device and enter the ESN (21500102222SF1900004), as shown in Figure
15-6.


4. On the Device page, the device status is normal, indicating that the AR router has
successfully connected to the controller, as shown in Figure 15-7.
Figure 15-7 Displaying device status
----End

USB-based Deployment

In Figure 15-8, the controller is deployed on the server, the AR routers are located on the user
network, and the AR routers and controller can communicate with each other. The AR routers
are deployed using the USB flash drive. The connections between AR routers and controller
are implemented during USB-based deployment.
Figure 15-8 AR routers communicate with the controller using USB-based deployment
Controller
3
Port:4999
Egress Gateway
GE0/0/0 GE0/0/0
10.1.1.1/24 10.1.1.2/24
……
RouterA RouterN
1. Make the index file for USB-based deployment to obtain controller information.
Procedure
Step 1 Configure USB-based deployment to obtain controller information.For details, see Example
for Configuring USB-based Deployment in the Huawei AR Series Access Routers
Configuration Guide - Basic Configuration.
Add controller information to the index file, including:
l Controller's IP address/domain name: CONTROTER_IP=10.1.2.1
l Port number matching the controller's IP address/domain name:
CONTROTER_PORT=4999

Step 2 Add the AR routers to the controller.

15-9.

4. On the Device page, the device status is normal, indicating that the AR router has

----End

DHCP
In Figure 15-11, the controller is deployed on the server, the AR routers and DHCP server are
located on the user network, and the AR routers and controller can communicate with each
other. The AR routers function as DHCP clients to obtain controller information and
management IP address from the DHCP server.
Figure 15-11 The AR routers communicate with the controller using DHCP
Controller
3
Port:4999
DHCP Server
GE0/0/0 GE0/0/0
10.1.1.1/24 10.1.1.2/24
……
RouterA RouterN
1. Configure the gateway address and Option 148 on the DHCP server (for example, the
DHCP server is an AR routers).

Procedure
Step 1 Configure the DHCP server.
# Enable DHCP.
<Router> system-view
[Router] dhcp enable
# Enable the DHCP server to assign IP addresses to clients from the global address pool.
[Router] interface gigabitEthernet 0/0/0
[Router-GigabitEthernet0/0/0] dhcp select global
# Configure an IP address pool.

[Router] ip pool global1
Info:It's successful to create an IP address pool.
[Huawei-ip-pool-global1] gateway-list 10.1.1.10
[Huawei-ip-pool-global1] network 10.1.1.0 mask 255.255.255.0
# Configure Option 148.

[Huawei-ip-pool-global1] option 148 ascii ac_addr=10.1.2.1:4999
[Huawei-ip-pool-global1] force insert option 148

15-12.


4. On the Device page, the device status is normal, indicating that the AR routers has
----End
15.7.4 Example for Connecting Routers (without OSP Daughter

Card) to Controller
In Figure 15-14, the controller is deployed on a server and AR routers are located on the
customer network.
Figure 15-14 Routers communicate with the controller using NETCONF
Controller
IP:10.1.1.3/24
GE0/0/0 GE0/0/0
10.1.1.1/24 10.1.1.N/24
……
Router A Router N
1. Configure an IP address for the management interface on each AR to implement

reachable route between the AR and controller cloud management platform.
2. Connect the AR to the controller cloud management platform.

3. Add the AR to the controller.
Procedure
Step 1 Configure an IP address for the management interface of the AR.
Step 2 Connect the AR to the controller cloud management platform.

[RouterA] agile controller host 10.1.1.3 port 4999
[RouterA] quit
Step 3 Add the AR to the controller.

15-15.



4. On the Device page, the device status is normal, indicating that the AR has successfully
connected to the controller, as shown in Figure 15-16.
----End
15.7.5 Example for Connecting Routers (with OSP Daughter Card)

to Controller
manage network devices through NETCONF.
In Figure 15-17, the controller is deployed on a server and AR routers routers are located on
the customer network.
Figure 15-17 Routers communicate with the controller using NETCONF
Controller
IP:10.1.1.3/24
GE0/0/0 GE0/0/0
10.1.1.1/24 10.1.1.N/24
……
Router A Router N
1. Configure an IP address for the management interface on each AR routers to implement

reachable route between the AR routers and controller cloud management platform.
2. Configure network connection between the OSP daughter card and controller cloud
management platform.
a. Configure network connection between the routing system and OSP daughter card.
b. Configure network connection between the OSP daughter card and controller cloud

3. Connect the AR routers to the controller cloud management platform.

4. Add the AR routers to the controller.
Procedure
Step 1 Configure an IP address for the management interface of the AR routers.
Step 2 Configure network connection between the routing system and OSP daughter card.
[RouterA] dhcp enable
[RouterA-Gigabitethernet0/0/5] ip address 192.168.2.1 24
[RouterA-Gigabitethernet0/0/5] dhcp select interface
Step 3 Configure network connection between the OSP daughter card and controller cloud
[RouterA-Gigabitethernet0/0/0] nat server global 10.1.1.11 inside 192.168.2.254
Step 4 Connect the AR routers to the controller cloud management platform.

[RouterA] agile controller host 10.1.1.3 port 4999
[RouterA] quit

15-18.


4. On the Device page, the device status is normal, indicating that the AR routers has
----End

AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R009 CLI-based Configuration Guide - Network Management and Monitoring

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AR100, AR120, AR150, AR160, AR200, AR1200, AR2200, AR3200, and AR3600 V200R009 CLI-based Configuration Guide - Network Management and Monitoring

Uploaded by

Copyright:

Available Formats

Huawei AR Series Access Routers

CLI-based Configuration Guide -

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. i

About This Document

This document is intended for:

l Data configuration engineers

Indicates an imminently hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Indicates a potentially hazardous situation

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. ii

NOTE Calls attention to important information,

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[] Items (keywords or arguments) in brackets [ ] are optional.

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

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

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

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

&<1-n> The parameter before the & sign can be repeated 1 to n

# A line starting with the # sign is comments.

Interface Numbering Conventions

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. iii

– When configuring a password, the cipher text is recommended. To ensure device

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. iv

Mappings Between Product Software Versions and NMS

AR Product eSight iManager U2000

V200R009C00 V300R008C00 V200R017C60

Changes in Issue 06 (2019-04-30)

Changes in Issue 05 (2018-11-30)

Changes in Issue 04 (2018-03-23)

Changes in Issue 03 (2018-01-05)

Changes in Issue 02 (2017-10-13)

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. v

l 6.5.7 (Optional) Configuring LLDP Packet Authentication on an Interface

Changes in Issue 01 (2017-08-04)

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. vi

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

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. vii

2 RMON and RMON2 Configuration........................................................................................ 50

3 TCP FPM Configuration............................................................................................................ 66

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. viii

4.6.2 Configuring the DCP................................................................................................................................................. 86

6 LLDP Configuration................................................................................................................. 131

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. ix

6.5.7 (Optional) Configuring LLDP Packet Authentication on an Interface....................................................................144

7 NQA Configuration.................................................................................................................. 155

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. x

7.9.3 Configuring an FTP Download Test Instance......................................................................................................... 174

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xi

7.15.4 Example for Configuring an FTP Upload Test Instance....................................................................................... 221

8 LSDP Configuration................................................................................................................. 263

9 Service Diagnosis Configuration........................................................................................... 269

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xii

10.2.2 Local Port Mirroring..............................................................................................................................................276

11 Packet Capture Configuration.............................................................................................. 294

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xiii

12.6.4 Configuring Versions for Exported Packets.......................................................................................................... 314

13 IP Accounting Configuration................................................................................................ 358

Issue 06 (2019-04-30) Copyright © Huawei Technologies Co., Ltd. xiv

13.3 Configuring IP Accounting...................................................................................................................................... 360