CX600

HUAWEI CX600 Metro Services Platform V600R002
Feature Description - System Management

Issue Date 01 2010-06-25
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2010. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

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

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China Website: Email: http://www.huawei.com support@huawei.com
Issue 01 (2010-06-25)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
HUAWEI CX600 Metro Services Platform Feature Description - System Management
About This Document
About This Document

Intended Audience
This document describes the System Management protocols in terms of its overview, principle, and applications. This document together with other types of document helps intended readers get a deep understanding of the System Management feature. This document is intended for: Network planning engineers Commissioning engineers Data configuration engineers System maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows. Symbol Description Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury. Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury. Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results. Indicates a tip that may help you solve a problem or save time. Provides additional information to emphasize or supplement important points of the main text.
Issue 01 (2010-06-25)
iii
About This Document
Change History
Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues.
Changes in Issue 01 (2010-06-25)

Initial field trial release.
iv
Issue 01 (2010-06-25)
Contents
Contents
About This Document ................................................................................................................... iii 1 Information Center ....................................................................................................................1-1
1.1 Introduction ................................................................................................................................................... 1-1 1.2 Reference ...................................................................................................................................................... 1-2 1.3 Availability .................................................................................................................................................... 1-2 1.4 Pinciples ........................................................................................................................................................ 1-3 1.4.1 Information Classification.................................................................................................................... 1-3 1.4.2 Information Hierarchy.......................................................................................................................... 1-8 1.4.3 Information Output .............................................................................................................................. 1-9 1.4.4 Information Shield ............................................................................................................................. 1-10 1.4.5 Suppression of the Log Processing Rate ............................................................................................ 1-12 1.4.6 Binary Log ......................................................................................................................................... 1-13 1.5 Impact.......................................................................................................................................................... 1-14 1.5.1 On the System Performance ............................................................................................................... 1-14 1.5.2 On Other Features .............................................................................................................................. 1-14 1.5.3 Introduction to SNMP ........................................................................................................................ 1-14 1.6 Terms and Abbreviations ............................................................................................................................. 1-15
2 SNMP ...........................................................................................................................................2-1
2.1 Introduction to SNMP ................................................................................................................................... 2-1 2.2 References ..................................................................................................................................................... 2-2 2.3 Availability .................................................................................................................................................... 2-3 2.4 Principles ....................................................................................................................................................... 2-3 2.4.1 Principle of SNMP ............................................................................................................................... 2-4 2.4.2 SNMP Management Model.................................................................................................................. 2-5 2.4.3 MIB ...................................................................................................................................................... 2-6 2.4.4 SMI ...................................................................................................................................................... 2-8 2.4.5 Principle of SNMPv1 ......................................................................................................................... 2-10 2.4.6 Principle of SNMPv2c ....................................................................................................................... 2-13 2.4.7 Principle of SNMPv3 ......................................................................................................................... 2-14 2.4.8 Support of the SNMP Protocol Stack for Error Codes ....................................................................... 2-16 2.4.9 Supported of SNMP for IPv6 ............................................................................................................. 2-16 2.4.10 Comparisons in the Security of SNMP in Different Versions .......................................................... 2-17
Issue 01 (2010-06-25)
Contents
2.5 Impact.......................................................................................................................................................... 2-17 2.5.1 On the System Performance ............................................................................................................... 2-17 2.5.2 On Other Features .............................................................................................................................. 2-17 2.5.3 Introduction to SNMP ........................................................................................................................ 2-18 2.6 Terms and Abbreviations ............................................................................................................................. 2-19
3 RMON and RMON2 ..................................................................................................................3-1

3.1 Introduction ................................................................................................................................................... 3-1 3.2 Reference ...................................................................................................................................................... 3-3 3.3 Availability .................................................................................................................................................... 3-3 3.4 Principles ....................................................................................................................................................... 3-4 3.4.1 RMON and RMON2 Infrastructure ..................................................................................................... 3-4 3.4.2 Features of RMON and RMON2 ................................................................................................. 3-11 3.4.3 Remote Monitoring of RMON and RMON2 ..................................................................................... 3-12 3.4.4 Table Management in RMON and RMON2 ...................................................................................... 3-14 3.4.5 Implementation of RMON and RMON2 on Huawei Devices ..................................................... 3-14 3.5 Impact.......................................................................................................................................................... 3-18 3.5.1 On the System Performance ............................................................................................................... 3-18 3.5.2 On Other Features .............................................................................................................................. 3-18 3.5.3 Huawei's Advantage ........................................................................................................................... 3-18 3.5.4 Other Defects ..................................................................................................................................... 3-19 3.6 Terms and Abbreviations ............................................................................................................................. 3-19
4 HGMP...........................................................................................................................................4-1
4.1 Introduction to HGMP .................................................................................................................................. 4-1 4.2 References ..................................................................................................................................................... 4-2 4.3 Availability .................................................................................................................................................... 4-2 4.4 Principles ....................................................................................................................................................... 4-2 4.4.1 Roles of Devices in a Cluster ............................................................................................................... 4-3 4.4.2 Multicast MAC Address....................................................................................................................... 4-3 4.4.3 Neighbor Information Collection ......................................................................................................... 4-4 4.4.4 Topology Information Collection ......................................................................................................... 4-5 4.4.5 Management VLAN ............................................................................................................................. 4-6 4.4.6 Communications Between Cluster Members and External Devices .................................................... 4-6 4.5 HGMP Application ........................................................................................................................................ 4-7 4.6 Impact............................................................................................................................................................ 4-9 4.6.1 On the System Performance ................................................................................................................. 4-9 4.6.2 On Other Features ................................................................................................................................ 4-9 4.6.3 Our Advantages .................................................................................................................................... 4-9 4.6.4 Defects ................................................................................................................................................. 4-9 4.7 Terms and Abbreviations ............................................................................................................................... 4-9
5 NTP ...............................................................................................................................................5-1
5.1 Introduction ................................................................................................................................................... 5-1 vi Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2010-06-25)
Contents
5.2 References ..................................................................................................................................................... 5-1 5.3 Availability .................................................................................................................................................... 5-2 5.4 Principle ........................................................................................................................................................ 5-2 5.4.1 Network Architecture ........................................................................................................................... 5-2 5.4.2 Operating Mode ................................................................................................................................... 5-3 5.4.3 Event Processing of NTP ..................................................................................................................... 5-4 5.4.4 Operating Principle .............................................................................................................................. 5-6 5.4.5 Security Mechanism............................................................................................................................. 5-8 5.4.6 Dynamic and Static Associations of NTP ............................................................................................ 5-8 5.5 Impact............................................................................................................................................................ 5-9 5.5.1 Impact on the System Performance ...................................................................................................... 5-9 5.5.2 Impact on Other Features ................................................................................................................... 5-10 5.5.3 Our Advantages .................................................................................................................................. 5-10 5.5.4 Defects ............................................................................................................................................... 5-10 5.6 Terms and Acronyms ................................................................................................................................... 5-10
6 1588v2 ...........................................................................................................................................6-1
6.1 Introduction to 1588v2 .................................................................................................................................. 6-1 6.2 References ..................................................................................................................................................... 6-4 6.3 Availability .................................................................................................................................................... 6-4 6.4 Principles ....................................................................................................................................................... 6-5 6.4.1 Basic Concepts ..................................................................................................................................... 6-5 6.4.2 Principle of Synchronization ................................................................................................................ 6-8 6.5 Application Environment ............................................................................................................................ 6-20 6.6 Impact.......................................................................................................................................................... 6-23 6.6.1 On the System Performance ............................................................................................................... 6-23 6.6.2 On Other Features .............................................................................................................................. 6-23 6.7 Terms and Abbreviations ............................................................................................................................. 6-24
7 NQA ..............................................................................................................................................7-1
7.1 Introduction to NQA ..................................................................................................................................... 7-1 7.2 References ..................................................................................................................................................... 7-3 7.3 Availability .................................................................................................................................................... 7-4 7.4 Principles ....................................................................................................................................................... 7-4 7.4.1 UDP Jitter Test ..................................................................................................................................... 7-6 7.4.2 UDP Jitter (hardware-based) ................................................................................................................ 7-6 7.4.3 ICMP Jitter ........................................................................................................................................... 7-7 7.4.4 ICMP Jitter (hardware-based) .............................................................................................................. 7-8 7.4.5 Path Jitter ............................................................................................................................................. 7-9 7.4.6 HTTP Test ............................................................................................................................................ 7-9 7.4.7 DNS Test ............................................................................................................................................ 7-10 7.4.8 FTP Test ............................................................................................................................................. 7-11 7.4.9 DHCP Test ......................................................................................................................................... 7-11
Issue 01 (2010-06-25)
vii
Contents
HUAWEI CX600 Metro Services Platform Feature Description - System Management 7.4.10 SNMP Test ....................................................................................................................................... 7-12 7.4.11 TCP Test ........................................................................................................................................... 7-13 7.4.12 UDP Test .......................................................................................................................................... 7-13 7.4.13 MPing Test ....................................................................................................................................... 7-13 7.4.14 MTrace Test ..................................................................................................................................... 7-14 7.4.15 ICMP Test ........................................................................................................................................ 7-15 7.4.16 Trace Test ......................................................................................................................................... 7-16 7.4.17 LSP Ping Test ................................................................................................................................... 7-17 7.4.18 LSP Trace Test ................................................................................................................................. 7-18 7.4.19 LSP Jitter .......................................................................................................................................... 7-18 7.4.20 PWE3 Ping Test ............................................................................................................................... 7-19 7.4.21 PWE3 Trace Test .............................................................................................................................. 7-20 7.4.22 MAC Ping Test................................................................................................................................. 7-21 7.4.23 MAC TUNNEL PING ..................................................................................................................... 7-22 7.4.24 Path MTU......................................................................................................................................... 7-22 7.4.25 CE-Ping ............................................................................................................................................ 7-23 7.4.26 VPLS MPING .................................................................................................................................. 7-24 7.4.27 VPLS PING ..................................................................................................................................... 7-26 7.4.28 VPLS Trace ...................................................................................................................................... 7-27
7.5 Impact.......................................................................................................................................................... 7-29 7.5.1 On the System Performance ............................................................................................................... 7-29 7.5.2 On Other Features .............................................................................................................................. 7-29 7.5.3 Defects ............................................................................................................................................... 7-29 7.6 Terms and Abbreviations ............................................................................................................................. 7-29
8 VLL NetStream ...........................................................................................................................8-1

8.1 Introduction to VLL NetStream .................................................................................................................... 8-1 8.2 References ..................................................................................................................................................... 8-3 8.3 Availability .................................................................................................................................................... 8-3 8.4 Principles ....................................................................................................................................................... 8-3 8.5 Applications................................................................................................................................................... 8-4 8.6 Impact............................................................................................................................................................ 8-4 8.6.1 On the System Performance ................................................................................................................. 8-4 8.6.2 On Other Features ................................................................................................................................ 8-4 8.7 Terms and Abbreviations ............................................................................................................................... 8-4
9 NetStream ....................................................................................................................................9-1
9.1 Introduction ................................................................................................................................................... 9-1 9.2 References ..................................................................................................................................................... 9-2 9.3 Availability .................................................................................................................................................... 9-3 9.4 Principles ....................................................................................................................................................... 9-3 9.4.1 Sampling Procedure ............................................................................................................................. 9-4 9.4.2 Sampling Modes .................................................................................................................................. 9-6
viii
Issue 01 (2010-06-25)
Contents
9.4.3 Aging of a Stream ................................................................................................................................ 9-6 9.4.4 Export of a Stream ............................................................................................................................... 9-7 9.4.5 Interface Index of NetStream ............................................................................................................... 9-9 9.4.6 Format Versions of NetStream Packets ................................................................................................ 9-9 9.5 Applications................................................................................................................................................. 9-26 9.6 Impact.......................................................................................................................................................... 9-28 9.6.1 On the System Performance ............................................................................................................... 9-29 9.6.2 On Other Features .............................................................................................................................. 9-29 9.6.3 Huawei's Advantage ........................................................................................................................... 9-29 9.6.4 Other Defects ..................................................................................................................................... 9-29 9.7 Terms and Abbreviations ............................................................................................................................. 9-29
10 Ping and Tracert .....................................................................................................................10-1

10.1 Introduction to Ping and Tracert ................................................................................................................ 10-1 10.2 References ................................................................................................................................................. 10-2 10.3 Availability ................................................................................................................................................ 10-2 10.4 Principles ................................................................................................................................................... 10-2 10.4.1 Working of Ping ............................................................................................................................... 10-2 10.4.2 Working of Tracert ........................................................................................................................... 10-3 10.4.3 LSPV ................................................................................................................................................ 10-3 10.4.4 Service Ping ..................................................................................................................................... 10-6 10.4.5 VPLS MAC Diagnosis ..................................................................................................................... 10-8 10.5 Impact........................................................................................................................................................ 10-9 10.5.1 On System Performance................................................................................................................. 10-10 10.5.2 On Other Features .......................................................................................................................... 10-10 10.5.3 Our Advantages .............................................................................................................................. 10-10 10.5.4 Defects ........................................................................................................................................... 10-10 10.6 Terms and Abbreviations ......................................................................................................................... 10-10
11 LLDP .........................................................................................................................................11-1
11.1 Introduction to LLDP ................................................................................................................................ 11-1 11.2 References ................................................................................................................................................. 11-2 11.3 Availability ................................................................................................................................................ 11-2 11.4 Principles ................................................................................................................................................... 11-3 11.4.1 Basic Principles ................................................................................................................................ 11-3 11.4.2 LLDP Parameters ............................................................................................................................. 11-5 11.4.3 LLDP Implementation on Devices ................................................................................................... 11-8 11.5 Applications ............................................................................................................................................... 11-9 11.6 Impact ...................................................................................................................................................... 11-10 11.6.1 On the System Performance ........................................................................................................... 11-10 11.6.2 On Other Features .......................................................................................................................... 11-10 11.6.3 Defects ........................................................................................................................................... 11-11 11.7 Terms and Abbreviations ......................................................................................................................... 11-11
Issue 01 (2010-06-25)
ix
Contents
12 Fault Management .................................................................................................................12-1

12.1 Introduction to Basic Configuration .......................................................................................................... 12-1 12.2 References ................................................................................................................................................. 12-2 12.3 Principles ................................................................................................................................................... 12-2 12.3.1 Fault Management............................................................................................................................ 12-2 12.4 Impact........................................................................................................................................................ 12-4 12.4.1 On the System Performance ............................................................................................................. 12-4 12.4.2 On Other Features ............................................................................................................................ 12-5 12.4.3 Our Advantages ................................................................................................................................ 12-5 12.4.4 Defects ............................................................................................................................................. 12-5 12.5 Terms and Abbreviations ........................................................................................................................... 12-5
Issue 01 (2010-06-25)
Figures
Figures
Figure 1-1 Output format of logs........................................................................................................................ 1-4 Figure 1-2 Output format of traps ...................................................................................................................... 1-6 Figure 1-3 Diagram of outputting debugging information ................................................................................. 1-7 Figure 1-4 Diagram of information filtration ................................................................................................... 1-11 Figure 2-1 Typical SNMP configuration ............................................................................................................ 2-4 Figure 2-2 Schematic diagram of a proxy server................................................................................................ 2-5 Figure 2-3 SNMP management model ............................................................................................................... 2-6 Figure 2-4 MIB tree structure ............................................................................................................................. 2-7 Figure 2-5 SNMP operations and corresponding packets................................................................................. 2-11 Figure 3-1 MIB groups in the RMON and RMON2 .................................................................................... 3-5
Figure 3-2 Statistics group .................................................................................................................................. 3-6 Figure 3-3 History group .................................................................................................................................... 3-7 Figure 3-4 Host group ........................................................................................................................................ 3-8 Figure 3-5 HostTopN group ............................................................................................................................... 3-9 Figure 3-6 Matrix group ..................................................................................................................................... 3-9 Figure 3-7 Filter group ..................................................................................................................................... 3-10 Figure 3-8 Packet capture group ....................................................................................................................... 3-10 Figure 3-9 Event group ..................................................................................................................................... 3-11 Figure 3-10 Relationship between tables.......................................................................................................... 3-17 Figure 3-11 Sampling of flow........................................................................................................................... 3-18 Figure 4-1 Schematic diagram of role exchange in a cluster .............................................................................. 4-3 Figure 4-2 Ethernet-II frame format ................................................................................................................... 4-4 Figure 4-3 Schematic diagram of topology information collection .................................................................... 4-5 Figure 4-4 HGMP Application ........................................................................................................................... 4-7 Figure 5-1 Network Architecture of NTP ........................................................................................................... 5-3 Figure 5-2 Diagram of NTP implementation ...................................................................................................... 5-7
Issue 01 (2010-06-25)
xi
Figures
Figure 6-1 Schematic diagram of time synchronization and frequency synchronization ................................... 6-2 Figure 6-2 Location of TC, OC, and TC+OC on a time synchronization network ............................................. 6-7 Figure 6-3 E2E delay measurement in Delay mode ........................................................................................... 6-9 Figure 6-4 Networking diagram of the directly-connected BC and OC ........................................................... 6-10 Figure 6-5 Schematic diagram of the transmission delay correction on a TC .................................................. 6-11 Figure 6-6 Networking diagram of the BC, OC, and E2E TC and the 1588v2 operation ................................ 6-12 Figure 6-7 Schematic diagram of the delay measurement in PDelay mode ..................................................... 6-13 Figure 6-8 Networking diagram of time synchronization in PDelay mode on the directly-connected BC and OC ........................................................................................................................................................................... 6-14 Figure 6-9 Transmission delay correction in PDelay mode .............................................................................. 6-15 Figure 6-10 Schematic diagram of transmission delay correction in PDelay mode on a P2P-TC ................... 6-15 Figure 6-11 Asymmetric delay correction ........................................................................................................ 6-16 Figure 6-12 Layer 2 multicast encapsulation without VLAN tags ................................................................... 6-17 Figure 6-13 Layer 2 multicast encapsulation with VLAN tags ........................................................................ 6-17 Figure 6-14 Layer 3 unicast encapsulation without VLAN tags ...................................................................... 6-17 Figure 6-15 Layer 3 unicast encapsulation with VLAN tags ........................................................................... 6-17 Figure 6-16 Synchronization with an external time source .............................................................................. 6-18 Figure 6-17 Networking diagram of 1588v2 clock synchronization in E2E mode .......................................... 6-20 Figure 6-18 Networking diagram of 1588v2 clock synchronization in hop-by-hop mode............................... 6-21 Figure 6-19 Networking diagram of the bearer and wireless networks in the same clock domain .................. 6-22 Figure 6-20 Networking diagram of the bearer and wireless networks in different clock domains ................. 6-22 Figure 7-1 Application scenario of the UDP Jitter test ....................................................................................... 7-6 Figure 7-2 Application scenario of UDP jitter (hardware-based) ....................................................................... 7-7 Figure 7-3 Application scenario of an ICMP Jitter test ...................................................................................... 7-8 Figure 7-4 Application scenario of ICMP jitter (hardware-based) ..................................................................... 7-9 Figure 7-5 Application scenario of a Path Jitter test ........................................................................................... 7-9 Figure 7-6 Applicable scenario of the HTTP test ............................................................................................. 7-10 Figure 7-7 Applicable scenario of the DNS test ............................................................................................... 7-11 Figure 7-8 Applicable scenario of the FTP test ................................................................................................ 7-11 Figure 7-9 Applicable scenario of the DHCP test ............................................................................................. 7-12 Figure 7-10 Application scenario of the SNMP test ......................................................................................... 7-12 Figure 7-11 Applicable scenario of the TCP test .............................................................................................. 7-13 Figure 7-12 Applicable scenario of the UDP test ............................................................................................. 7-13 Figure 7-13 Applicable scenario of the MPing test .......................................................................................... 7-14
xii
Issue 01 (2010-06-25)
Figures
Figure 7-14 Application scenario of the MTrace test ....................................................................................... 7-15 Figure 7-15 Applicable scenario of the ICMP test ........................................................................................... 7-16 Figure 7-16 Applicable scenario of the Trace test ............................................................................................ 7-17 Figure 7-17 Application scenario of the LSP Ping test ..................................................................................... 7-17 Figure 7-18 Applicable scenario of the LSP Trace test..................................................................................... 7-18 Figure 7-19 Application scenario of the LSP Jitter test .................................................................................... 7-19 Figure 7-20 Application scenario of the PWE3 Ping test ................................................................................. 7-20 Figure 7-21 Application scenario of the PWE3 Trace test................................................................................ 7-21 Figure 7-22 Application scenario of the MAC Ping test .................................................................................. 7-21 Figure 7-23 Application scenario of the MAC Tunnel Ping test ...................................................................... 7-22 Figure 7-24 Application scenario of a Path MTU test ...................................................................................... 7-23 Figure 7-25 Application scenario of a CE-Ping test ......................................................................................... 7-24 Figure 7-26 Applicable scenario of a VPLS MPing test ................................................................................... 7-25 Figure 7-27 Structure of a VPLS MPing private TLV ...................................................................................... 7-26 Figure 7-28 Applicable scenario of the VPLS Ping test ................................................................................... 7-27 Figure 7-29 Applicable scenario of a VPLS trace test ...................................................................................... 7-28 Figure 8-1 Typical networking plan ................................................................................................................... 8-2 Figure 8-2 Diagram of the PPPoE packet format ............................................................................................... 8-2 Figure 9-1 NetStream sampling procedure ......................................................................................................... 9-5 Figure 9-2 NetStream packet ............................................................................................................................ 9-10 Figure 9-3 Header of the NetStream packet exported in V5 format ................................................................. 9-10 Figure 9-4 V5 format information .................................................................................................................... 9-12 Figure 9-5 Header of the NetStream packet exported in V8 format ................................................................. 9-12 Figure 9-6 Schematic diagram of the aggregation based on the AS ................................................................. 9-14 Figure 9-7 Schematic diagram of the aggregation based on the protocol type ................................................. 9-15 Figure 9-8 Schematic diagram of the aggregation based on the destination IP address prefix ......................... 9-15 Figure 9-9 Schematic diagram of the aggregation based on the source IP address prefix ................................ 9-16 Figure 9-10 Schematic diagram of the aggregation based on the source IP address prefix and the destination IP address prefix .................................................................................................................................................... 9-16 Figure 9-11 Schematic diagram of the aggregation based on ToS + AS........................................................... 9-17 Figure 9-12 Schematic diagram of the aggregation based on ToS + protocol type .......................................... 9-17 Figure 9-13 Schematic diagram of the aggregation based on the IP address prefix + ToS + protocol type ..... 9-18 Figure 9-14 Schematic diagram of the aggregation based on ToS + source IP address prefix ......................... 9-18 Figure 9-15 Schematic diagram of the aggregation based on ToS + destination IP address prefix .................. 9-19
Issue 01 (2010-06-25)
xiii
Figures
Figure 9-16 Schematic diagram of the aggregation based on ToS + IP address prefix .................................... 9-19 Figure 9-17 Header of the NetStream packet exported in V9 format ............................................................... 9-20 Figure 9-18 Schematic diagram of the NetStream packet exported in V9 format ............................................ 9-21 Figure 9-19 Format of the template FlowSet .................................................................................................... 9-22 Figure 9-20 Packet format of the data FlowSet ................................................................................................ 9-24 Figure 9-21 Relationship between the data stream and the V9 template format .............................................. 9-25 Figure 9-22 Schematic diagram of inter-AS NetStream ................................................................................... 9-26 Figure 9-23 IP address prefix-based charging for ISPs .................................................................................... 9-27 Figure 9-24 Schematic diagram of the analysis of the service mode on the MPLS network ........................... 9-28 Figure 9-25 Schematic diagram of collecting the statistics about VPN traffic ................................................. 9-28 Figure 10-1 Applicable scenario of the service ping ........................................................................................ 10-7 Figure 11-1 LLDP topology discovery between directly connected neighbors ................................................ 11-3 Figure 11-2 LLDP topology discovery between indirectly connected neighbors ............................................. 11-4 Figure 11-3 Relationship between the interval for sending LLDP frames and the delay in sending LLDP frames ........................................................................................................................................................................... 11-6 Figure 11-4 Sending LLDP frames at different time points.............................................................................. 11-7 Figure 11-5 Networking diagram of LLDP configurations on the network where an interface has multiple neighbors ......................................................................................................................................................... 11-10
xiv
Issue 01 (2010-06-25)
Tables
Tables
Table 1-1 Feature list of the information center .................................................................................................. 1-2 Table 1-2 Description of each field in a log ........................................................................................................ 1-4 Table 1-3 Description of each field in a trap ....................................................................................................... 1-6 Table 1-4 Description of the severity levels of information ............................................................................... 1-8 Table 1-5 Relationship between information channels and output directions..................................................... 1-9 Table 2-1 Types of information managed by the MIB ........................................................................................ 2-7 Table 2-2 PDU type .......................................................................................................................................... 2-12 Table 2-3 Error status description ..................................................................................................................... 2-12 Table 2-4 Trap type description ........................................................................................................................ 2-13 Table 2-5 Comparisons in the security of SNMP in different versions ............................................................. 2-17 Table 3-1 Time span of each table .................................................................................................................... 3-16 Table 6-1 Requirements of wireless standards for time synchronization and frequency accuracy ..................... 6-3 Table 7-1 Comparisons between NQA and Ping ................................................................................................ 7-2 Table 7-2 Differences between UDP Jitter and UDP Jitter (hardware-based) .................................................... 7-7 Table 7-3 Differences between ICMP jitter and ICMP jitter (hardware-based) .................................................. 7-8 Table 9-1 Implementation and drawbacks of the traditional traffic statistics method ........................................ 9-2 Table 9-2 Information related to the NetStream function ................................................................................... 9-5 Table 9-3 List of aggregation modes .................................................................................................................. 9-8 Table 9-4 Description of fields in the header of the NetStream packet exported in V5 format ........................ 9-10 Table 9-5 Description of fields in the header of the NetStream packet exported in V8 format ........................ 9-13 Table 9-6 Description of fields in the header of the NetStream packet exported in V9 format ........................ 9-20 Table 10-1 Description of fields in the result table ........................................................................................... 10-8 Table 12-1 Mappings between alarm levels and severity levels ....................................................................... 12-2
Issue 01 (2010-06-25)
xv
1 Information Center
1
About This Chapter
1.1 Introduction 1.2 Reference 1.3 Availability 1.4 Pinciples 1.5 Impact 1.6 Terms and Abbreviations
Information Center
1.1 Introduction
Definition
The information center, which is indispensable to a device, functions as the information hub of the device. The information center manages most output information. Output information is refinedly classified and then effectively filtered. Cooperated with the debugging program (the debugging command) and SNMP module, the information center provides powerful supports for the network administrator to monitor the operation of devices and locate faults. The working principle of the information center is as follows: Generally speaking, the information center distributes three types of information with eight severity levels to ten information channels and then outputs information in different directions. Details are as follows: 1. Receives logs, traps, and debugging information of different severity levels that are output by each module.
The logs, traps, and debugging information of each module are saved in the corresponding log, trap, and debugging queues in the information center. Each queue can hold 30 k messages.
2.
Distributes information of different types and with different severity levels to different information channels according to user settings.
Issue 01 (2010-06-25)
1-1
3.
Outputs information in different directions based on the association between the information channel and the output direction.
The following table lists main features of the information center. Table 1-1 Feature list of the information center Feature Information type Information severity Information output Information shield Description Information is classified into log, trap, and debugging information. Eight severity levels are defined for information. The more important the information is, the smaller the severity value is. The information center can output information to the log file, console, VTY/TTY terminal, log host, SNMP agent, log buffer, and trap buffer. You can shield the output information of a severity level or a module through commands.
Purpose
The information center outputs information in a unified format to different directions, thus improving readability, maintainability, and flexibility of logs. 1. 2. 3. 4. Controls where information is output. Currently, information can be output to the log file, console, VTY/TTY terminal, log host, SNMP agent, log buffer, and trap buffer. Filters information. Currently, information can be filtered based on the source, severity level, type, and output direction. Provides a system-level information output platform. Displays the system-level debugging information.
1.2 Reference
The following table lists the reference of this feature: Document RFC 3164 Description The BSD syslog
1.3 Availability
License Support
Information center is not license controlled.
1-2
Issue 01 (2010-06-25)
Version Support
Product Model CX600 Earliest Software Version V200R001
1.4 Pinciples
1.4.1 1.4.2 1.4.3 1.4.4 Information Classification Information Hierarchy Information Output Information Shield
1.4.5 Suppression of the Log Processing Rate 1.4.6 Binary Log
1.4.1 Information Classification

To meet different requirements of clarified information in different directions, the information center classifies information into three types: logs, traps, and debugging information. Logs are used to record user operations and diagnosis information. Diagnosis logs are used by R&D personnel for fault location; users can view user logs only. Traps are used to record faults. After receiving traps, the information center sends them to the SNMP agent. Then, the SNMP agent sends the traps to the NMS. Debugging information is used to trace the running status of a device.
Log Information
Log overview Defined by the ITU-T, logs refer to records about events and abnormal activities of the managed object. It is generally accepted that the log module is capable of tracing activities of users, managing security affairs of the system, providing basis for diagnosis and maintenance. Therefore, log recording is an important method for operation maintenance and fault location. Implementation of logs on Huawei devices By default, the information center is enabled and it can output logs to the console, log buffer, SNMP agent, and log file. After a log host is configured, logs can be sent to it. Currently, up to eight log hosts can be configured for a Huawei device. In this manner, logs can be sent to different log hosts simultaneously for backup. By default, the device can send logs to the console and log buffer. The number of logs stored in the log buffer or the trap buffer can be configured from 1 to 1024. The default value is 512. If the number of logs in the log buffer reaches the upper limit, new logs will replace the existing logs in a time order until all the new logs are stored. That is, the log put into the log buffer earliest is replaced first.
Issue 01 (2010-06-25)
1-3
Diagnosis log Certain logs are used for fault location. As these logs are not intended for instruction, users do not need to be informed of these logs. Therefore, logs can be classified into user logs and diagnosis logs. The information center continues to use the original user log management system, but processes diagnosis logs independently. In this manner, users can view only user logs; configurations on diagnosis logs are invisible for users. Users can find that a diagnosis log file is generated but they cannot view the diagnosis logs in the file because the file is encrypted. By default, diagnosis logs are output to diagnosis log files. Output format of logs Syslog is a sub-function of the information center. Syslog uses UDP as the transmission protocol and outputs logs to log hosts through port 514. Figure 1-1 shows the log format. Figure 1-1 Output format of logs
<Int_16>TIMESTAMP HOSTNAME %%ddAAA/B/CCC(l): -Slot=k-XXX; YYYY
Table 1-2 describes each field in a log. Table 1-2 Description of each field in a log Field <Int_16> Meaning Leading character Description Before logs are output to log hosts, leading characters are added to logs. Logs saved in the local device do not contain leading characters. Five timestamp formats are available: boot: indicates relative time. By default, debugging information adopts this timestamp format. date: indicates system time. By default, logs and traps adopt this timestamp format. short-date: indicates system time. The short-date format does not contain year information. format-date: indicates another format of system time. none: indicates that no timestamp is contained in logs. The timestamp and the host name are separated by a blank space. HOSTNAME Host name By default, the system name is HUAWEI. The host name and the module name are separated by a blank space.
TIMESTAMP
Time to send logs
1-4
Issue 01 (2010-06-25)
Field %% dd AAA B CCC (L)
Meaning Huawei identifier Version number Module name Log level Description Information type
Description Indicates that the log is output by a Huawei product. Identifies the version of the log format. Indicates the name of the module that outputs information to the information center. Indicates the severity level of logs. Further describes the information type. l: log information T: trap information d: debugging information D: Diagnosis log information
-Slot=k-XXX
Location information
Slot: indicates the number of the slot that sends location information. Location information begins and ends with a blank space. Some modules generate logs without location information. Indicates detailed log information output from each module to the information center. Every time a log is output, the module fills this field with detailed information.
YYYY
Descriptor
Trap Information
Trap overview Traps are notifications generated when the system detects faults. Information about the faults are carried in traps. Different from logs, traps are time sensitive and need to be notified to administrators in time. Therefore, the information center processes traps sent to the NMS in a different method. Traps are sent from a device to an NMS device. With SNMP agent enabled on a device, the trap function enabled on the related module, and the NMS host to which traps are sent configured, when an event happens (for example, the network interface becomes Down), the deivce generates a trap and sends it to the specified destination address. If the device and the NMS are routable, the NMS can receive the trap. In addition, the device has a trap buffer for storing traps. If the information source is configured for the buffer on the information center, the buffer can store traps generated by the local device regardless whether the destination NMS host is configured. Concepts about traps
Event: indicates anything that takes place on the managed object. For example, the managed object is added, deleted, or modified. Fault: indicates that the system does not work normally. A fault may cause the system to be disabled in operation or redundancy. Trap: indicates the notification generated when the system detects a fault.
Issue 01 (2010-06-25)
1-5
Output format of traps Figure 1-2 Output format of traps

TimeStamp HostName ModuleName Severity Brief:Description
Table 1-3 describes each field in a trap. Table 1-3 Description of each field in a trap Field TimStamp Meaning Time to send traps Description Five timestamp formats are available: boot: indicates relative time. By default, debugging information adopts this timestamp format. date: indicates the timestamp in the format of system time. By default, logs and traps adopt this timestamp format. short-date: indicates system time. The short-date format does not contain year information. format-date: indicates another format of system time. none: indicates that no timestamp is contained in traps. The timestamp and the host name are separated by a blank space. HostName Host name By default, the system name is HUAWEI. The host name and the module name are separated by a blank space. ModuleName Serverity Module name Severity Indicates the name of the module that generates traps. Indicates the severity level of traps. Critical Major Minor Warning Indeterminate Cleared Brief Description Description Description Indicates brief description of traps. Indicates detailed description of traps.
1-6
Issue 01 (2010-06-25)
Debugging Information
Debugging information is the output of the tracing information about the running status of a device. Devices can generate debugging information only after the debugging of the module to be debugged is enabled in the user view. Debugging information shows the contents of packets sent or received by the debugged module. Note that enabling debugging only generates debugging information. Displaying debugging information requires more configurations. Different from logs and traps, no buffer is available for debugging information. Debugging information can be output to the console or be sent to log hosts through certain configurations. You can connect the PC to the console port of a device (the console mode) or to a network interface of a device through Telnet (the terminal mode). When debugging the device through the console or the terminal, you can control the contents of the output debugging information. Abundant debugging commands are provided for debugging protocols and functions that a device supports. You can enable the debugging of a protocol or a function to diagnose and locate the fault. The output of debugging information depends on the following situations: Whether debugging information about a protocol is output Whether terminal monitor is enabled, that is, whether to display the debugging information on the screen Figure 1-3 shows the relationship between the preceding two situations. After the debugging of protocol 1 and 3 is enabled, corresponding debugging information is output. As screen display is also enabled, the debugging information is displayed. No debugging information about protocol 2 is output because the debugging of protocol 2 is not enabled. Figure 1-3 Diagram of outputting debugging information
Debug information Protocol debug switch
ON
OFF
ON
1 Termina display switch
OFF
ON
Issue 01 (2010-06-25)
1-7
1.4.2 Information Hierarchy

Overview
In the case of much information, users can hardly differentiate between information about normal operation and information about faults. Therefore, information hierarchy is designed to help users roughly determine whether to take action immediately or shield the information that does not require an action.
Severity Levels of Information

Information is categorized into eight severity levels. The severer the information is, the lower the severity level threshold is. Details are shown in Table 1-4. Table 1-4 Description of the severity levels of information Value 0 Severity Level Emergency Description A fatal fault occurs in the device, which causes the system to fail to run normally unless the device is restarted. For example, the device is restarted because of the abnormal operation of a program or because of a detected fault about memory usage. A grave fault occurs in the device, which requires actions to be taken immediately. For example, memory usage of the system reaches the upper limit. A grave fault occurs in the device, which requires actions to be taken to analyze or process it. For example, the memory usage is lower than the lower limit; the temperature is lower than the lower limit; Bidirectional Forwarding Detection (BFD) detects that the device is unreachable; error messages generated by the device itself are detected. A fault about improper operation or abnormal process occurs in the device, which does not affect subsequent services but requires attention and cause analysis. For example, users enter incorrect instructions or passwords; error protocol packets received by other devices are detected. An abnormality that may result in a fault occurs in the device, which requires full attention. For example, the routing process is disabled; packet loss is detected through BFD; error protocol packets are detected. A key operation is performed to keep the device running normally. For example, the shutdown command is run on an interface; a neighbor is discovered; the state of the protocol state machine normally changes. A normal operation is performed. For example, the display command is run. A normal operation is performed, which requires no attention.
Alert
Critical
Error
Warning
Notice
6 7
informational Debugging
1-8
Issue 01 (2010-06-25)
The severity level of output information is configurable. If information is filtered according to the configured severity level, only information with a severity level lower than or equal to the configured severity level threshold is output. That is, only information with the configured severity level and more serious information are output. For example, if the severity level threshold is set to 6, only the information whose severity level ranges from 0 to 6 is output.
1.4.3 Information Output

The information center needs to output information to the terminal, console, log buffer, SNMP agent, and log file. To output information in different directions, ten information channels are defined for the information center and the channels work independently from each other.
Information Output Channel

The ten channels are equal and same. Before using information channels, you need to specify information sources for channels. The defaults information sources for the fist six channels (console, monitor, log host, trap buffer, log buffer, and SNMP agent). For devices installed with the storage medium, log files can be output through channel 9 by default. Besides the default channels, you can customize information sources for the rest four channels (Channel 6, Channel 7, Channel 8, and Channel 9) by configuring their channel name or by running the configuration commands.
Information Output Direction

The information center supports ten channels, among which Channel 0 to Channel 5 have their default channel names. By default, the six information channels are respectively related to six output directions, as shown in Table 1-5. Table 1-5 Relationship between information channels and output directions Chan nel Numb er 0 1 Default Channel Name console monitor Output Direction Description
Console Monitor
Outputs information to the local console that can receive logs, traps, and debugging information. Outputs information to the virtual type terminal (VTY) that can receive logs, traps, and debugging information. This is helpful for remote maintenance. Outputs information to the log host that can receive logs, traps, and debugging information. The information is saved to the log host in the file format for the convenience of reference. Outputs information to the trap buffer that can receive traps. An area is specified inside a device as the trap buffer to record traps.
loghost
Log host
trapbuffer
Trap buffer
Issue 01 (2010-06-25)
1-9
Chan nel Numb er 4
Default Channel Name logbuffer
Output Direction
Description
Log buffer
Outputs information to the log buffer that can receive logs. An area is specified inside a device as the log buffer to record logs. Outputs information to the SNMP agent that can receive traps. Reserved. Reserved. Reserved. Outputs information to log files that can receive logs, traps, and debugging information. Information is saved to the hard disk or the flash card in the file format. The supported file types vary with products. For details, refer to the Configuration Guide of each product.
5 6 7 8 9
snmpagent unspecified unspecified unspecified channel9
SNMP agent Unspecifie d Unspecifie d Unspecifie d Log file
Owning to associating each information channel with an output direction, information can be output to a specific direction through the associated channel. You can change channel names or relationships between channels and output directions as required.
Information Output
Terminals that are connected to the device dynamically change. The information center needs to know the change in time so that it determines whether to output information to terminals and in which format information is output. Once an EXEC user enters or quits or its attribute changes, the change is notified to the information center through the EXEC module so that information can be correctly output. After information is output to the log file, a log file in .zip format is generated. When available storage space is smaller than the specified threshold, the information center deletes the earliest log file.
1.4.4 Information Shield

To control information output flexibly, the information center provides the information shield function. Through commands, the information center can determine whether a specific type of information is output, information with which severity level is output, and information from which module is output.
1-10
Issue 01 (2010-06-25)
Information Shield Table

The information center filters information by using a shield table. With the shield table, information that is output to multiple directions is filtered and then output according to information types, severity levels, and sources. Multiple information shield table can be set up in the information center. Each information shield table can correspond to one or several output directions. Shielded information can be unshielded through modification as required. The contents of an information shield table are as follows: Number of the module that generates the information Whether logs can be output Logs at which severity levels can be output Whether traps can be output Traps with which severity levels can be output Whether debugging information can be output Debugging information with which severity levels can be output As shown in Figure 1-4, by default, logs, traps, and debugging information are output through default channels. You can specify a channel through which information is output. For example, you can configure logs to be output to the log buffer through Channel 6. In this manner, logs are output through the configured Channel 6 rather than the default Channel 4. Figure 1-4 Diagram of information filtration
Infomation type
Infomation channel 0 Console 1 Monitor Loghost
Output direction
Console Remote terminal Loghost Trap buffer Log buffer SNMP agent
Logs
Traps
2 3 Trapbuffer Logbuffer
Debugs
5 SNMP agent 6 Direction of logs Direction of alarms Direction of debugging information 7 8 9 channel6 channel7 channel8 channel9
Logfile
Issue 01 (2010-06-25)
1-11
1.4.5 Suppression of the Log Processing Rate

Overview of the Suppression of the Log Processing Rate
If too many logs with the same log ID are generated on a running device, the information center is too busy processing these logs to process logs with other log IDs, which may even affect the running service. The information center monitors the traffic of logs with different log IDs. When the traffic of logs with a specific log ID repeatedly exceeds the threshold during the monitoring period, the information center suppresses the processing rate of these specified logs by processing only the conforming traffic and discarding the non-conforming traffic; when the traffic of logs with the specific log ID falls below the threshold and remains below the threshold for five monitoring periods, the suppression is removed.
Features of the Suppression of the Log Processing Rate

Configurable monitoring threshold You can set the current monitoring threshold for the information center through command lines. In addition, you can set the monitoring threshold of logs with a specific log ID according to their generation scenario and importance. Configurable monitoring duration You can set the current monitoring duration for the information center through command lines. In addition, you can set the monitoring duration according to the specific scenario to adjust the suppression condition. To avoid the traffic fluctuation, the suppression is removed only when the number of logs that are generated every second falls below the threshold and remains below the threshold for five monitoring periods. Configurable global processing capability You can configure and adjust the processing capability of the information center to meet the requirement of services. Query of suppression records You can query the suppression record in real time. In addition, you can query the historical suppression records. For example, you can query the logs that have been suppressed over half an hour in the suppression record that is updated every half an hour. In this case, after the suppression is removed, you can view information about the suppression duration and number of logs that are sent and received during the suppression period.
Output of the Statistics About Repeatedly Generated Logs

If a log is repeatedly generated on a running device, the information center will be too busy processing these repeated logs to process other logs. In extreme cases, the service operation may be affected. By default, before sending logs to the information center, the service module checks whether these logs are repeated as follows: If log IDs or parameters of two consecutive logs are different, these two logs are sent to the information center. If log IDs and parameters of two consecutive logs are identical, these two logs are regarded as repeated logs and their numbers are counted.
1-12
Issue 01 (2010-06-25)
In the case of logs that are repeatedly generated within a period, the information center only counts their number.
1.4.6 Binary Log

With the rapid growth in network scales and complexity, device configurations become more complex and the operating environment keeps changing. Consequently, devices are generating an increasing number of logs than ever before. If the device saves only dynamic parts of logs, the contents to be saved and the number of times for writing the disk can be effectively reduced, the storage capacity is increased and the storage period is extended, the efficiency in processing logs is improved, and the lifespan of the storage device is prolonged. The binary log function writes the log to be saved to a log file in binary format. A binary log file is made up of: Dynamic part: The changing information, such as the time. Static part: The fixed information. Each log has a unique ID and the static information in each log can be identified with its corresponding ID. In this case, only the log ID and dynamic parameters need to be saved. Binary log files only record the dynamic parameters and each log is identified with a unique ID. Users can view a generated binary log file by: Running commands on the device to view log information. Copying the binary log file to the local end and parsing it through the log parsing tool. By default, log files are saved in the text format. The default format can be converted to the binary format through command lines. Diagnosis logs are always saved in binary format. For example, a log contains the following the registration information: The user chose [Y/N] when deciding whether to reboot the system. The log ID is 1078464521. Normally, the following information is saved: 2009-5-21 19:46:52 CX600 %%01CMD/4/REBOOT(l):The user chose N when deciding whether to reboot the system. When the log is saved in binary format, only the dynamic parameters are saved: Time (2009-5-21 19:46:52) + ID (1078464521) + dynamic parameter (N) If the binary log file is to be parsed offline, the data dictionary and log parsing tool are required. A data dictionary is a centralized repository of information about all modules in the system, such as the log ID and format string. It can be generated on the device through command lines. The log parsing tool is an exe. file. It searches the data dictionary downloaded to the local end for the static information according to the log ID carried in the binary log file. Then, it integrates the static information in the data dictionary and dynamic parameters in the binary log file into a complete log. The binary log file can be checked directly on the device through command lines. Checking the binary log file through either command lines or the parsing tool follows the same parsing principle, namely, integrating the static information in the data dictionary and dynamic parameters in the binary log file into a complete log. Checking the binary log file through command lines, however, requires neither the help of the data dictionary nor the parsing tool. The entire parsing process is performed automatically.
Issue 01 (2010-06-25)
1-13
In actual application, the binary log has obvious advantages. For example, an 8 MB binary log file can be parsed into a 21 MB log file in the text format. This proves that binary log can save the storage space, reduce the I/O operations, and prolong the lifespan of the storage device.
1.5 Impact
1.5.1 On the System Performance 1.5.2 On Other Features 1.5.3 Introduction to SNMP
1.5.1 On the System Performance

The information center does not affect system performance. But too frequently recording of module log information will affect system performance.
1.5.2 On Other Features

The information center does not affect other features.
1.5.3 Introduction to SNMP

Definition
The Simple Network Management Protocol (SNMP) is a network management standard widely used in the TCP/IP network. It provides a core device running the network management software (network management station) to manage network elements, such as CX devices or switches. Communication in SNMP can be in the following ways: The network management station obtains network resource information through Get, Get-Next, and Get-Bulk operations. The network management station sets network resources through the Set operation. The SNMP agent actively reports Trap messages to the network management station so that the network management station can obtain network status in time, and the network administrator fast take corresponding measures.
Purpose
SNMP is mainly used to manage networks. Network management involves the following: Managing application programs, user accounts (for example user count for file using), and write/read authorities (licenses). Since all these network management issues are related to software, they are not further described here. Managing the hardware that constructs the network, that is, network elements, including workstations, servers, network cards, CX devices, bridges, and hubs. Commonly, these devices locate far away from the central office where the network administrator stays. Therefore, when faults occur on the devices, it is expected that the network administrator
1-14
Issue 01 (2010-06-25)
can be automatically notified of the faults. The CX device, however, is unlike a user, and it cannot make a phone call to the network administrator. To solve this problem, some device producers have integrated the network management function into their devices. Then, the network management station can query the device status remotely and the devices can report trap messages of certain events to the network management station. Generally, network management involves four parts: Managed objects: are devices being monitored, that is, network elements. Agent: is a special software or firmware that traces the status of the managed objects. Network management station: communicates with the agent processes in different managed objects and displays the status of the managed objects. Network management protocol: works to exchange information between the network management stations and the agents.
1.6 Terms and Abbreviations

Terms
Term Log Event Trap Debug SNMP Description Log information Anything that takes place on the managed object. For example, the managed object is added, deleted, or modified. Trap information Debugging information Simple Network Management Protocol
Issue 01 (2010-06-25)
1-15
2 SNMP
2
About This Chapter
2.1 Introduction to SNMP 2.2 References 2.3 Availability 2.4 Principles 2.5 Impact 2.6 Terms and Abbreviations
SNMP
2.1 Introduction to SNMP

Definition
The Simple Network Management Protocol (SNMP) is a network management protocol widely used in the TCP/IP network. SNMP is a method of managing network elements through a network console workstation which runs network management software. Communication in SNMP can be in the following ways: The network management station obtains network resource information through Get and Get-Next operations. The network management station sets network resources through the Set operation. The SNMP agent actively reports Trap messages to the network management station so that the network management station can obtain network status in time, and the network administrator fast take corresponding measures. SNMP version evolution In May 1990, RFC 1157 defined the first SNMP version: SNMPv1. RFC 1157 provides a system method to monitor and manage the network. SNMPv1 cannot ensure security because it is based on community-name authentication and only a few error codes are returned. Later, Internet Engineering Task Force (IETF) released SNMPv2p. For network security, SNMPv2p imports the concept of "participant". This concept, however, was not popularized
Issue 01 (2010-06-25)
2-1
2 SNMP
because of the problems encountered during actual practice. SNMPv2p was then replaced by SNMPv2c. SNMPv2c does not cover the concept "participant". It still uses the community-name authentication of SNMPv1 but imports GetBulk and provide more error codes. Considering incomplete security provided by SNMPv2c, IETF released SNMPv3. SNMPv3 provides User Security Module-based (USM-based) encrypted authentication and View-based Access Control Model (VACM). Huawei products support SNMPv1, SNMPv2c, and SNMPv3.
Purpose
SNMP is mainly used to manage networks. Network management involves the following: Managing application programs, user accounts (for example user count for file using), and write/read authorities (licenses). Since all these network management issues are related to software, they are not further described here. Managing the hardware that constructs the network, that is, network elements, including workstations, servers, network cards, routing deivices, switches, and hubs. Commonly, these devices locate far away from the central office where the network administrator stays. Therefore, when faults occur on the devices, it is expected that the network administrator can be automatically notified of the faults. The devices, however, is unlike a user, and it cannot make a phone call to the network administrator. To solve this problem, some device producers have integrated the network management function into their devices. Then, the network management station can query the device status remotely and the devices can report trap messages of certain events to the network management station. Generally, network management involves four parts: Managed objects: are devices being monitored, that is, network elements. Agent: is a special software or firmware that traces the status of the managed objects. Network management station: communicates with the agent processes in different managed objects and displays the status of the managed objects. Network management protocol: works to exchange information between the network management stations and the agents.
2.2 References
The following table lists the references of this document. Document RFC 1157 RFC 1905 RFC 2271 Description Simple Network Management Protocol (SNMP) Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) An Architecture for Describing SNMP Management Frameworks Rema rks -
2-2
Issue 01 (2010-06-25)
2 SNMP
Document RFC 2570 RFC 2571 RFC 2572 RFC 2573 RFC 2574 RFC 2575 RFC 2578 RFC 2579 RFC 2580
Description Introduction to Version 3 of the Internet-standard Network Management Framework An Architecture for Describing SNMP Management Frameworks Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) SNMP Applications User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) Structure of Management Information Version 2 (SMIv2) Textual Conventions for SMIv2 Conformance Statements for SMIv2
Rema rks -
2.3 Availability
License Support
The SNMP feature is not license controlled.
Version Support
2.4 Principles
2.4.1 Principle of SNMP 2.4.2 SNMP Management Model 2.4.3 MIB 2.4.4 SMI 2.4.5 Principle of SNMPv1 2.4.6 Principle of SNMPv2c
Issue 01 (2010-06-25)
2-3
2 SNMP
2.4.7 Principle of SNMPv3 2.4.8 Support of the SNMP Protocol Stack for Error Codes 2.4.9 Supported of SNMP for IPv6 2.4.10 Comparisons in the Security of SNMP in Different Versions
2.4.1 Principle of SNMP

Figure 2-1 shows a typical SNMP configuration. The entire system must have one network management station that functions as a network management center over the network and runs management processes. Each managed object must have an agent process. The management process and the agent process communicate through SNMP packets borne by UDP. Figure 2-1 Typical SNMP configuration
Network Management station Management process SNMP UDP IP Network interface User terminal Agent process SNMP UDP IP Network interface User process FTP TCP Internet
User terminal Agent process SNMP UDP IP Network interface Routing Device Management process SNMP UDP IP Network interface User process
FTP
TCP
In the case that some network elements use another network management protocol, rather than SNMP, the network management station running SNMP cannot manage these network elements. In this situation, the network elements can use proxy servers for management. A proxy server provides functions such as protocol transition and filtering operations. Figure 2-2 is a schematic diagram of a proxy server.
2-4
Issue 01 (2010-06-25)
2 SNMP
Figure 2-2 Schematic diagram of a proxy server
Network management station Management process SNMP UDP IP Network interface
Proxy agent mapping function Manageme nt process SNMP UDP IP Network interface Protocols used by commissi oned devices Network interface Proxy agent Management process SNMP UDP IP Network interface
Network
Network
2.4.2 SNMP Management Model

In SNMP, the network management station and the agent communicate by exchanging signals. The network management system (NMS) of the network management station acts as a manager to send an SNMP Request packet to the SNMP agent. The agent searches the MIB on the managed object for the required information and sends an SNMP Response packet to the NMS. When the alarm triggering conditions defined on a module are met, the corresponding agent sends a trap message to the network management station for notifying the event on the managed object. This helps the network administrator to deal with the abnormality occurred over the network. Figure 2-3 shows the SNMP management model.
Issue 01 (2010-06-25)
2-5
2 SNMP
Figure 2-3 SNMP management model
NMS
Agent
MIB
Management object
2.4.3 MIB
A Management Information Base (MIB) specifies the variables maintained by network elements. These variables are the information that can be queried and set by the management process. A MIB presents a data structure, collecting all possible managed objects over the network. The SNMP MIB adopts a tree structure like the Domain Name System (DNS) with its root on the top without a name. Figure 2-4 shows a part of the MIB, called object naming tree.
2-6
Issue 01 (2010-06-25)
2 SNMP
Figure 2-4 MIB tree structure

root
ccitt(1)
iso(1)
Joint-iso-ccitt(1)
registration authority(1) standard(0)
memberbody(2) ide ntified organization(3) dod(6)
internet(1)
directort(1) mgmt(2) experim ental(3) 1.3.6.1.2.1 private(4) security(5) snmpv2(6)
mib-2(1)
enterprises(1)
......
1.3.6.1.4.1
system(1)
interface(2)
at(3)
ip(4)
icmp(5)
tcp(6) udp(7)
egp(8) . . . . . .
......
......
......
...... ......
............ ......
The object naming tree has three top objects: ISO, ITU-T (that is CCITT), and the joint of the two organizations. Under the ISO, there are four objects among which number 3 is the identified organization. A sub-tree of the Department of Defense in the United States dod (6) is under the identified organization (3) and the following is the Internet (1). When discussing only the objects in the Internet, you can draw only the sub-tree below the Internet object (the square frames in dotted lines with shadow marks in the following diagram), and mark {1.3.6.1} next to the Internet object. The object under the Internet is mgmt (2). What follows mgmt (2) is MIB-II. The original object name is MIB. In 1991, the new edition MIB-II is defined; therefore, the current name is MIB-II that is identified as {1.3.6.1.2.1} or {Internet(1) .2.1}. This kind of identifier is the OID. Information managed by the initial MIB fall into eight types, as shown in Table 2-1. The current MIB-II, however, contains more than 40 types of information. Table 2-1 Types of information managed by the MIB Type system interface address translation Identifier 1 2 3 Information Operating system of a host or a device Various types of network interfaces and traffic volume on the interfaces Address translation (such as ARP mapping)
Issue 01 (2010-06-25)
2-7
2 SNMP
Type ip icmp Tcp udp egp
Identifier 4 5 6 7 8
Information IP software(IP fragment statistics) ICMP software(Statistics about received ICMP messages) TCP software(TCP traffic volume statistics) UDP software(UDP traffic volume statistics) EGP software(EGP traffic volume statistics)
MIB definition is independent of the network management protocol. Device producers can integrate SNMP agent software into their products and should ensure that this software still complies with the standard after the new MIBs are defined. Users can adopt the same network management software to manage the devices containing MIBs of various versions; however, the prerequisite is that the device should support the MIB function; otherwise, the device cannot provide the corresponding functions.
2.4.4 SMI
Structure of Management Information (SMI) is a set of rules for naming and defining managed objects in the MIB. SMI can define the identifier, type, access level, and status of the managed objects. Currently, SMI has two versions: SMIv1 and SMIv2. SMI defines the following standard data types: INTEGER Specifies an integer variable. Its value varies with different scenarios. For example, the forwarding flag in the IP header is 0 or 1; both UDP and TCP port numbers range from 0 to 65535. OCTET STRING Consists of 0 or more bytes, with each byte ranging from 0 to 255. DisplayString Consists of 0 or more bytes, with each byte being in ASCII format. In MIB-II, the value of a DisplayString variable ranges from 0 to 255, in characters. OBJECT IDENTIFIER Specifies the unique identifier of a managed object, consisting of a set of sequence numbers. From left to right, these sequence numbers identify the location of a managed object in the hierarchical MIB tree structure. NULL Indicates that the value of a specific variable is not set. For example, values of variables in Get or GetNext messages are Null. IpAddress Specifies an IP address, consisting of a 4-byte octet string. Each byte represents a field in the IP address. PhysAddress
2-8
Issue 01 (2010-06-25)
2 SNMP
Specifies a physical address, consisting of octet strings. For example, the physical address of the Ethernet is a 6-byte octet string. Counter Defines a non-negative integer ranging from 0 to 4294976295 (in ascending order). The value returns to 0 after reaching the maximum number. Gauge Defines a non-negative integer ranging from 0 to 4294976295 (in ascending order or descending order). After reaching the maximum number, the value remains unchanged until being reset. For example, tcpCurrEstab in the MIB is a gauge variable, indicating the number of TCP connections in the Established or CLOSE_WAIT state. TimeTicks Specifies a timer. The precision of different types of timers varies, with the value increments by 0.01 seconds. In this case, a precision increment rate must be specifies when a timeticks variable is specified. For example, sysUpTime in the MIB is a timeticks variable, indicating the time period since the agent process was last re-initialized, in 0.01 seconds. SEQUENCE Consists of 0 or more elements, with each element in the data type defined by ASN.1. For example, UdpEntry in the MIB is a sequence variable, indicating the number of Activated UDP UdpEntry includes the following elements:

udpLocalAddress (in the IpAddress type), indicating an IP address. udpLocalPort (in the integer type), ranging from 0 to 65535 and indicating a port number.
SEQUENDEOF Defines a vector. All elements of a vector are of the same type. In SNMP, each element of a vector is in the Sequence format and therefore a vector can be regarded as a two-dimensional array or table. The comparision between SMIv1 and SMIv2 is as follows: SMIv1 SYNTAX SMIv2 SMIv1 ACESS SMIv2 MAX-ACE SS SMIv1 STATUS SMIv2
Issue 01 (2010-06-25)
2-9
2 SNMP
SMIv1 SimpleSynta x INTEGER OCTET STRING OBJECT IDENTIFIE R NULL ApplicationS yntax NetworkAdd ress Counter (0..4294967 295) Gauge (0..4294967 295) TimeTicks(0 ..429496729 5) Opaque
SMIv2 SimpleSynta x INTEGER (21474836 48..2147483 647) OCTET STRING (SIZE (0..65535)), OBJECT IDENTIFIE R NULL ApplicationS yntax IpAddress Counter32 (0..4294967 295) Gauge (0..4294967 295) TimeTicks (0..4294967 295) Opaque (0..4294967 295) Counter64 (0..1844674 4073709551 615) Unsigned32 (0..4294967 295)
SMIv1 read-only read-write write-only not-accessibl e
SMIv2 read-only read-write write-only not-accessibl e accessible-fo r-notify
SMIv1 mandatory optional obsolete
SMIv2 current deprecated obsolete
2.4.5 Principle of SNMPv1

SNMP defines five types of Protocol Data Units (PDUs), namely, SNMP packets, to be exchanged between the management process and the agent process. get-request: indicates that the management process reads one or more parameter values from the MIB of the agent process. get-next-request: indicates that the management process reads the next parameter value in the lexicographic order from the MIB of the agent process.
2-10
Issue 01 (2010-06-25)
2 SNMP
set-request: indicates that the management process sets one or more parameter values in the MIB of the agent process. get-response: returns one or more parameter values. This operation is performed by the agent process. It is the response to the preceding three operations. trap: is actively sent by the agent process to inform the management process of some important events. The first three operations are initiated by the management process and while the latter two operations are initiated by the agent process. To simplify definition, the first three operations are also called get, get-next, and set. Figure 2-5 shows the preceding five operations.
The agent process uses the well-known port 161 to receive get or set packets and the management process uses the well-known port 162 to receive trap packets.
Figure 2-5 SNMP operations and corresponding packets
SNMP management process get-request
SNMP management process
UDP port 161 get-response UDP port 162 get-next-request UDP port 161 get-response UDP port 162 set-request UDP port 161 get-response UDP port 162 trap UDP port 162
An SNMP packet contains three parts: common SNMP header, get/set header or trap header, and variable binding.
Common SNMP Header

The common SNMP header contains three fields: Version This value is the real version number minus one. For example, for an SNMPv1 packet, this field is 0. Community The community is a plain-text password between the management process and the agent process. It is in the character string format. A common value is the 6-character string "public". PDU type There are five types of PDUs in total. Table 2-2 shows the values for the PDU type.
Issue 01 (2010-06-25)
2-11
2 SNMP
Table 2-2 PDU type PDU Type 0 1 2 3 4 Name get-request get-next-request get-response set-request trap
Get/set Header
Request ID It is an integer set by the management process and returned by the agent process in the Get-Response packet. The management process may send Get packets to multiple agents simultaneously and these packets are all sent through UDP. It is possible that the packets are sent first but received last. In this case, this field enables the management process to sort out the returned responses. Error status It is filled by the agent process in the Get-Response packet to specify an error. Table 2-3 shows the values, names, and descriptions about error status. Table 2-3 Error status description Error Status 0 1 2 3 4 5 Name noError tooBig noSuchName badValue readOnly genErr Description All are normal. The agent cannot fit the response into a single SNMP packet. The operation specifies a nonexistent variable. A set operation specifies an invalid value or syntax. The management process tries to modify a read-only variable. Some other errors.
Error index It indicates an integer offset specifying which variable is error. It is set by the agent process only for the noSuchName, badValue, and readOnly errors.
Trap Header
Enterprise
2-12
Issue 01 (2010-06-25)
2 SNMP
It identifies the network device that sends the trap message. This object identifier resides in the sub-tree of the enterprise object {1.3.6.1.4.1} in the object naming tree. Trap type This field is actually called generic-trap. It has seven types, as shown in Table 2-4. Table 2-4 Trap type description Trap Type 0 1 2 3 4 5 6 Name coldStart warmStart linkDown linkUp authenticationFailure egpNeighborLoss enterpriseSpecific Description The agent is initializing itself. The agent is reinitializing itself. An interface has changed from the Up state to the Down state. An interface has changed from the Down state to the Up state. A packet was received from an SNMP management process with an invalid community. An EGP peer has changed to the Down state. It is the event defined by the agent. Look in the specific code field for information on the trap.
For the trap message of type 2, 3, or 5, the first variable in the variable binding field in the message should specify the interface that responds to the trap message. Specific-code It specifies events defined by the agent if there are traps of type 6. Otherwise, this field must be 0. Timestamp It specifies the time from when the agent is initialized to when the event is reported through the trap happens. The value is in 10 ms. For example, if the timestamp is 1908, it indicates that the event happens 19080 milliseconds after the agent is initialized.
Variable Binding
The variable binding specifies the names and values of one or more variables. In the Get or Get-Next packet, this field is null.
2.4.6 Principle of SNMPv2c

SNMPv2 has been released as a recommended Internet-standard. Simplicity is a main cause for the success of SNMP. This is because in the large-sized and complicated network constructed by devices of multiple vendors, managing protocol details becomes critically important. This, however, is also a defect in SNMP: To simplify protocol management, SNMP tailors some functions, for example: 1. SNMP does not provide the batch write/read function, which results in a low efficiency in saving or reading a large block of data.
Issue 01 (2010-06-25)
2-13
2 SNMP
2. 3.
SNMP runs only on the TCP/IP protocol. It does not support other network protocols. SNMP does not provide a mechanism for the communication between managers. Therefore, it is applicable to centralized management rather than distributed management. SNMP can be used to monitor only the network devices but not the network itself.
4.
Improving SNMP is a long-term task being performed to solve the preceding problems. In November 1991, the Remote Network Monitoring (RMON) MIB was introduced to enhance the network management capability of SNMP. Through the RMON MIB, SNMP can not only manage network devices but also collect statistics about traffic over the LAN and the Internet. In July 1992, to enhance the security of SNMP, SNMPv2 was introduced. In 1996, the IETF issued a series of RFC documents. These documents defined SNMPv2c and abandoned the security idea in SNMPv2. SNMPv2c extends SNMPv1 in the following aspects: SMI SNMPv2c supports both SMIv1 and SMIv2 (SNMPv1 supports only SMIv1), enhancing the communication capability between network management stations. Message type SNMPv2c is increased with two message types.
GetBulk: The GetBulk message is developed to minimize the number of message exchanges required to retrieve a large amount of management information. A GetBulk operation performed by the NMS according to a GetBulk message is equal to several consecutive GetNext operations. The recycle times of a GetBulk message (the number GetNext operations required in the GetBulk message) can be set at the NMS side. InformRequest: An InformRequest message is generated and transmitted to notify an event that has occurred or a condition that is present. This is a confirmed notification delivery mechanism, in which the NMS returns an Acknowledge message to the agent after receiving an InformRequest message. If the NMS does not return any Acknowledge message, the agent re-transmits the InformRequest message until the number of retransmission times exceeds the upper limit.
2.4.7 Principle of SNMPv3

The SNMPv3 architecture is defined in RFC 2271, which embodies the modularization design theory and simplifies function addition and modification. SNMPv3 features the following: Strong adaptability: SNMPv3 is applicable to multiple operating systems. It can manage both simple and complex networks. Good extensibility: New models can be added as required. High security: SNMPv3 provides multiple security processing models. SNMPv3 has four models: message processing and control model, local processing model, user security model, and view-based access control model. Different from SNMPv1 and SNMPv2, SNMPv3 can implement access control, identity authentication, and data encryption through the local processing model and user security model.
2-14
Issue 01 (2010-06-25)
2 SNMP
Message Processing and Control Model

As defined in RFC 2272, a message processing and control model is responsible for constructing and analyzing SNMP packets and determining whether the packets should pass a proxy server. During the packet constructing process, the message processing and control model receives PDUs from a dispatcher and sends it to the user security model for adding security parameters to the headers. When analyzing the received PDUs, the user security model should first process the security parameters in the headers and send the unpacked PDUs to the dispatcher for processing.
Local Processing Model

A local processing model is mainly used to implement access control, data packaging, and data transmission interruption. Access control is implemented by setting information related to the agent so that the management processes on different network management stations can have different authorities to access the agent. This process is implemented through PDU transmission. There are two commonly-used control policies: restricting the commands that can be delivered by the network management station to the agent; specifying the details in the MIB of the agent that the network management station can access. Access control policies must be predefined. SNMPv3 flexibly defines access control methods by using the syntax with different parameters.
User Security Model

A user security model provides identify authentication and data encryption services. For the two functions, it is required that the network management station and the agent use a shared key. Identify authentication: is a process in which the agent (or the network management station) confirms whether the received message is from an authorized station (or agent) and whether the message is changed during transmission. RFC 2104 defines Keyed-Hashing for Message Authentication Code (HMAC), an effective tool that uses the security hash function and key to generate the message authentication code. This tool is widely used in the Internet. HMAC used in SNMP contains HWAC-MD5-96 and HWAC-SHA-96. The hash function of HWAC-MD5-96 is MD5 that uses 128-bit authKey to generate the key. The hash function of HWAC-SHA-96 is SHA-1 that uses 160-bit authKey to generate the key. Data encryption: uses the cipher block chaining (CBC) code of the data encryption standard (DES) and uses 128-bit privKey to generate the key. The network management station uses the key to calculate the CBC code and then adds the CBC code to the message while the agent fetches the authentication code through the same key and then obtains the actual information. Like identity authentication, data encryption also requires the network management station and the agent to use a shared key for encryption or decryption.
View-based Access Control Model

As defined in RFC 2515, a view-based access control model is mainly used to restrict the access rights of user groups or communities to specific views. You must pre-configure a view and specify its authority. Then, when you configure a user, user group, or community, load this view to implement read/write restriction or trap function (for SNMPv3).
Issue 01 (2010-06-25)
2-15
2 SNMP
2.4.8 Support of the SNMP Protocol Stack for Error Codes

During the communication between the network element (NE) and network management device, an SNMP error code returned by the NE in response to SNMP requests can provide error information, such as the packet being of excessive length and the index being non-existent. The error code defined by SNMP is called the standard error code. The SNMP protocol stack provides 21 types of standard error codes: Five of them are dedicated to SNMPv1. Sixteen of them are shared by SNMPv2 and SNMPv3. With the increasing number of features and scenarios supported by the system, the current types of SNMP standard error codes cannot meet requirements in diversified scenarios. Consequently, the network management device cannot identify the scenario where the fault occurs when the NE processes the packets. As a solution to the preceding problem, the extended error code is introduced. When a fault occurs during the packet processing, the NE returns an error code corresponding to the fault scenario. If the fault scenario is beyond the range of the SNMP standard error code, a general error or a user-defined error code is returned. The error code that is relative to the standard error code and defined by users are called the extended error code. The extended error code can define more scenarios. The network management device (only the Huawei NMS) can correctly parse the fault scenario of the current NE based on the agreement with NEs. This is because the NMS and device use the same mechanism to define error codes. Extended error code can be enabled through either command lines or operations on the NMS. After extended error code is enabled, SNMP, based on certain rules, converts the internal error codes returned from features into different extended error codes, and then sends them to the NMS. If the internal error codes returned from features are standard error codes, SNMP sends them to the NMS without any other action. If extended error code is not enabled, standard error codes and internal error codes defined by modules are directly sent to the NMS. The system generates and manages extended error codes according to the module number and extended error codes registered on the modules. The NMS parses extended error codes according to its agreement with NEs and then displays the obtained detail information.
2.4.9 Supported of SNMP for IPv6

Replacing IPv4 with IPv6 has become a trend. Therefore, it is required that devices be capable of running IPv6 and transmitting SNMP packets on the IPv6 network. SNMP does not distinguish whether the SNMP packets transmitted on the network are encapsulated with IPv4 or IPv6 headers, that is, SNMP processes SNMP IPv4 packets and SNMP IPv6 packets in the same manner. SNMP supports IPv6 by: Reading SNMP packets. SNMP can read and process both SNMP IPv4 packets and SNMP IPv6 packets. These two types of packets do not affect each other. In this case, the NE can run on either the IPv6 network or the network that runs IPv4 and IPv6 simultaneously.
2-16
Issue 01 (2010-06-25)
2 SNMP
When receiving a packet, the NE identifies whether the packet is an IPv4 or IPv6 packet in order to distribute the packet to the corresponding task for processing and return the processing result according to different IP protocols. SNMP IPv6 packets are sent to port 161. In this case, the NE can obtain information about both SNMP IPv4 packets and SNMP IPv6 packets by monitoring port 161. Sending IPv6-based trap messages. A network management host with an IPv6 address is configured through command lines. According to IPv6, the NE sends trap messages to the network management host.
At present, SNMP does not support the IPv6-based Inform packet.
Recording SNMP IPv6 packets. Commands used to configure SNMP IPv6 and SNMP IPv4 are the same and command outputs are separately displayed according to protocol types. The NE automatically separates IPv6 packets from IPv4 packets by matching packets with their upper layer protocols.
2.4.10 Comparisons in the Security of SNMP in Different Versions

Table 2-5 Comparisons in the security of SNMP in different versions Protocol Version v1 v2c v3 User Checksum Adopts the community name. Adopts the community name. Adopts user name-based encryption/decryption. Encryptio n NO NO YES Authorization NO NO YES
2.5 Impact
2.5.1 On the System Performance 2.5.2 On Other Features 2.5.3 Introduction to SNMP

If a large number of packets are received in a short period, a great number of CPU resources are occupied. The number of received packets depends on the frequency at which the management process sends the request packets.

SNMP does not affect other features.
Issue 01 (2010-06-25)
2-17
2 SNMP
2.5.3 Introduction to SNMP

Definition
The Simple Network Management Protocol (SNMP) is a network management standard widely used in the TCP/IP network. It provides a core device running the network management software (network management station) to manage network elements, such as CX devices or switches. Communication in SNMP can be in the following ways: The network management station obtains network resource information through Get, Get-Next, and Get-Bulk operations. The network management station sets network resources through the Set operation. The SNMP agent actively reports Trap messages to the network management station so that the network management station can obtain network status in time, and the network administrator fast take corresponding measures.
Purpose
SNMP is mainly used to manage networks. Network management involves the following: Managing application programs, user accounts (for example user count for file using), and write/read authorities (licenses). Since all these network management issues are related to software, they are not further described here. Managing the hardware that constructs the network, that is, network elements, including workstations, servers, network cards, CX devices, bridges, and hubs. Commonly, these devices locate far away from the central office where the network administrator stays. Therefore, when faults occur on the devices, it is expected that the network administrator can be automatically notified of the faults. The CX device, however, is unlike a user, and it cannot make a phone call to the network administrator. To solve this problem, some device producers have integrated the network management function into their devices. Then, the network management station can query the device status remotely and the devices can report trap messages of certain events to the network management station. Generally, network management involves four parts: Managed objects: are devices being monitored, that is, network elements. Agent: is a special software or firmware that traces the status of the managed objects. Network management station: communicates with the agent processes in different managed objects and displays the status of the managed objects. Network management protocol: works to exchange information between the network management stations and the agents.
2-18
Issue 01 (2010-06-25)
2 SNMP

Terms
Terms SNMP Agent ASN.1 Explanation Simple Network Management Protocol An agent is the process run on the managed devices. ASN.1 is a syntax notation type employed to specify protocols. It describes the syntax used during the data transmission instead of detailed data signification. BER is the basic encoding rules. It is in the syntax structure of the ASN.1, describing how data is represented during transmission. An entity is the software or hardware to be managed.
BER Entity
Abbreviation
Abbreviation SNMP SMI MIB PDU NMS Full Spelling Simple Network Management Protocol Structure of Management Information Management Information Base Protocol Data Unit Network Management System
Issue 01 (2010-06-25)
2-19
3 RMON and RMON2
3
About This Chapter
3.1 Introduction 3.2 Reference This section lists the references of RMON. 3.3 Availability 3.4 Principles 3.5 Impact
RMON and RMON2
This chapter gives the introduction to RMON and RMON2 and describes their basic concepts and principles as well as applications on Huawei devices.
This section describes the basic knowledge about RMON.
3.1 Introduction
This section describes the basic knowledge about RMON.
Basic Concepts of RMON

NMS A Network Management System (NMS) is the network management software running on the Network Management Workstation (NM WS). The network manager sends requests to the managed devices, and monitors and configures the network devices through the NMS. MIB A Management Information Base (MIB) is a virtual database that collects the information about the status of the managed devices. Agent An agent is a process that runs on the managed devices. Monitor
Issue 01 (2010-06-25)
3-1
3 RMON and RMON2
A monitor is used to trace communications across network devices. It is also called the network probe. Poll The NM workstation sends SNMP packets to query the operating status of the device and configure parameters.
Drawbacks of SNMP
SNMP is a widely used network management protocol. It collects statistics about network communications by using the agent software embedded in the managed device. The management software polls the agent for the information. The agent then searches the MIB and returns the required information to the NMS. This implements network management through the NMS. Though the MIB counter records the sum of the statistics, it cannot analyze the history status of daily communications. To completely obtain the information about traffic and traffic change in traffic volume in a day, the NMS software must continue to poll the agent for required information and then analyze the network status. Poll in SNMP has the following drawbacks: Consumes network resources heavily. In a large-scale network, poll generates heavy traffic across the network. This leads to network congestion or network block. In addition, SNMP collects a lot of information, such as information about routing tables. Therefore, SNMP is not suitable to manage large-size networks. Burdens the network manager. In polling, the network manager is responsible for collecting information through the NMS software. If the manager monitors more than three network segments, the monitoring task may be so overloaded that the network manager cannot complete. In addition, MIB-II contains public MIBs and private MIBs defined by manufacturers. They collect information about devices, such as port status and traffic information, instead of the information about the NMS running in the sub-network. Therefore, SNMP is not suitable to manage large-scale networks.
Introduction of RMON
To improve the usability of management information, lighten the burden on the NMS, and enable the network manager to monitor several network segments, the Internet Engineering Task Force (IETF) proposed RMON to replace SNMP for managing increasingly distributed networks. RMON is based on SNMP and is compatible with SNMP. It consists of two parts: the NMS and the SNMP agent. The implementation of RMON is simple because it uses the original mechanism of SNMP. RMON enables the SNMP module to monitor remote network devices more efficiently and actively. It provides an efficient method to monitor the running status of sub-networks, which reduces the communication traffic between the NMS and the Agent. Large-scale networks can thus be managed in a simple and effective manner.
RMON Goals
RMON provides an effective method to monitor traffic behaviors in sub-networks. RMON goals are as follows: Offline operation: The monitor can continuously collect information about errors, performance, and configuration even when the network manager is not available.
3-2 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2010-06-25)
3 RMON and RMON2
Proactive monitoring: The monitor must be available at the onset of any network failure. It can notify the network manager of the failure and provide useful statistics for fault location. Problem detection and reporting: The monitor can be configured to monitor conditions, such as faults in the network and resource consumption. When any of these conditions occurs, an event is logged. This is helpful in checking errors. Data analyzing: The monitor can collect and analyze data about the sub-network. This lightens the burden on the NM Station. Multiple managers: Multiple managers can be used to enhance reliability. Managers have different functions and provide different management performance for interior devices.
3.2 Reference
This section lists the references of RMON. For more information about RMON, refer to the following documents. No. FRC 1757 RFC 2021 RFC 2819 RFC 2895 RFC 3577 Description Remote Network Monitoring Management Information Base Remote Network Monitoring Management Information Base Version 2 Remote Network Monitoring Management Information Base Remote Network Monitoring MIB Protocol Identifier Reference Introduction to the Remote Monitoring (RMON) Family of MIB Modules
3.3 Availability
Involved Network Element
None
License Support
None
Version Support
Issue 01 (2010-06-25)
3-3
3 RMON and RMON2
Hardware Support
None
3.4 Principles
3.4.1 RMON and RMON2 Infrastructure 3.4.2 Features of RMON and RMON2
3.4.3 Remote Monitoring of RMON and RMON2 3.4.4 Table Management in RMON and RMON2 3.4.5 Implementation of RMON and RMON2 on Huawei Devices
This section describes the implementation of RMON and RMON2 on Huawei devices.
3.4.1 RMON and RMON2 Infrastructure

RMON defines a set of MIBs, which contain the information about standard network monitoring function and interfaces. This implements the communication between the SNMP management terminal and the remotely managed devices. MIBs are divided into a certain number of function table groups. Each table group may have one or more control tables and data tables. Managers can read from or write into control tables. The data table, however, is read-only. Control tables define the data collection function, whereas data tables collect data according to the specifications in control tables. MIB-II contains RMON MIBs. The identifier of the sub-tree is 16. MIBs are divided in to nine groups with different functions. Figure 3-1 shows the MIB groups defined in RMON and RMON2.
3-4
Issue 01 (2010-06-25)
3 RMON and RMON2
Figure 3-1 MIB groups in the RMON and RMON2
rmon ( mib- 2 16)
statistic ( 1 ) protocolDir ( 11 ) history ( 2 ) protocolDir ( 12 ) alarm ( 3 ) addressMap ( 13 ) host ( 4 ) nlHost( 14 ) hostTopN ( 5 ) nlMatrix ( 15 ) matrix ( 6 ) alHost ( 16 ) filter ( 7 ) alMatrix( 17 ) capture ( 8 ) userHistory( 18 ) event ( 9 )
probeConfig( 19 )
RMON
RMON2
Statistics group: collects basic statistics of each monitored sub-network. The statistics include the data flow on a network segment, distribution of various packets, error frames, and collision times. History group: periodically collects the network status statistics and stores them for future use.
Issue 01 (2010-06-25)
3-5
3 RMON and RMON2
Alarm group: allows predefining a set of thresholds for alarm variables that can be any object in the local MIB. The monitor records logs or sends trap messages to the NMS when the sample crosses a threshold in a certain direction. Host group: contains inbound and outbound traffic statistics associated with each host discovered on the network. HostTopN group: contains statistics about hosts that top a list ordered by one of the parameters. Matrix group: stores errors and useful information in the form of a matrix. This is convenient for operators to search the information based on any set of two addresses. Filter group: allows the monitor to observe packets on the interface and select a specific packet through filtering. Packet capture group: provides a cache mechanism and allows packets to be captured after they flow through a channel. Event group: stores all the events generated by the RMON agent in a table. The event group records logs or sends trap messages to the NMS when an event occurs.
The alarm group requires the implementation of the event group. The hostTopN group requires the implementation of the host group. The capture group requires the implementation of the filter group.
Statistics Group
The statistics group collects basic statistics of each monitored sub-network. Figure 3-2 shows the three tables in the statistics group. Figure 3-2 Statistics group
statistic ( rmon 1 ) EtherStats Table ( 1 ) tokenRing MPLS Stats Table ( 2 ) tokenRing PStats Table ( 3 )
EtherStatsTable This table contains 21 objects. It has a record entry for each monitored sub-network to display statistics about the sub-networks. Most objects in this table are counters, used by the monitor to record packets with different status across sub-networks. The EtherStatsTable contains information about sub-networks and error information, such as Cyclic Redundancy Check (CRC) code, and correct and incorrect packets. Therefore, this table displays the operating status of the entire network. Information collected in the EtherStatsTable and MIB-II is similar. The information in the EtherStatsTable is more detailed and is more pertinent to Ethernet networks.
3-6
Issue 01 (2010-06-25)
3 RMON and RMON2
Upper and lower limits in the alarm table are set based on the statistics in the EtherStatsTable. Setting the alarm threshold is an effective method for network monitoring. tokenRingmlStats Table and tokenRing PStats Table The tokenRingmlStatsTable and the tokenRing PStatsTable provide statistics of token ring networks. Most objects in the tables are counters.
History Group
The history group periodically collects statistical samples on a monitor. This group consists of one historyControlTable and three HistoryTables as shown in Figure 3-3. Figure 3-3 History group
history ( rmon 2 ) historyControl Table ( 1 ) etherHisTable( 2 ) tokenRingMLHistory Table( 3 ) tokenRingPHistory Table( 4 )
historyControlTable The historyControlTable contains detailed information, such as the sampling interval and interface information. Every record in it defines the sampling interval for a specified interface. After being sampled, data is saved as a related entry in the data table. As defined in RMON, a monitored interface must have two control rows, one of which defines the sampling interval as 30 seconds and the other defines the sampling interval as 30 minutes. The short interval is used to detect the burst communication events, and the long interval is used to detect the stable communication events. Data Table Data tables are applied to record data. The etherHistoryTable is a data table especially for Ethernet networks. The tokenRingMLIHistoryTable and the tokenRingTable are data tables for token ring networks. Similar to the statistics group, the data table also provides counters.
Alarm Group
The alarm group allows predefining a set of thresholds for variables. If the monitored variable exceeds the threshold, an event is generated, and the monitor records logs or sends trap messages to the NMS. This group is dependent on the event group and requires the implementation of the event group. The alarm group consists of only one table: the alarmTable. Each record defines the specified variable, sampling interval, and threshold.
Issue 01 (2010-06-25) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 3-7
3 RMON and RMON2
Host Group
The host group collects statistics associated with the specified host newly discovered on a Local Area Network (LAN).It discovers hosts by monitoring the source and destination MAC addresses in the packets transmitted across the LAN. The host group retains a group of statistics for each host. This group consists of the hostControlTable, the hostTable, and the hostTimeTable, as shown in Figure 3-4. Figure 3-4 Host group
host ( rmon 4 ) hostControlTable( 1 ) hostTable( 2 ) hostTimeTable( 3 )
hostControlTable Every row in the hostControlTable corresponds to a monitored network interface. Options in the control tables define various data. Control tables also record the time when entries in the data table are deleted. The control tables and the data tables are directly mapped. The hostTable records the MAC addresses discovered by network interfaces specified by rows in the control table. hostTable Rows in the hostTable store statistics about hosts. This table can be indexed either by MAC addresses of hosts or network interfaces. If the network interface discovers a new host, a row is added in the hostTable. Once a row is added in the hostTable, the monitor begins to the check the MAC address of the corresponding network interface. hostTimeTable Rows in the hostTimeTable store the same information as that in the hostTable. The hostTimeTable is indexed by the creation time instead of the MAC address. The hostTimeTable also supports management stations. You can effectively find new entries for the specified interface without downloading the information of the complete table.
HostTopN Group
The hostTopN group is used to maintain statistics of the hosts in a sub-network. The monitored hosts top a list ordered by one of their variables. For example, this group can collect the information about the host with the top 10 data transmission amount. This group consists of the hostTopNControlTable and the hostTopNTable, as shown in Figure 3-5.
3-8
Issue 01 (2010-06-25)
3 RMON and RMON2
Figure 3-5 HostTopN group
hostTopN ( rmon 5 ) hostTopControl Table( 1 ) hostTopNTable( 2 )
hostTopControl Table Every row in the hostTopControlTable defines a Top-N report of a network interface. It also covers the period from the time the last TOP-N report is initialized to the time the system starts. hostTopTable This table contains information about Top N hosts. Each row represents a unique host. This table also contains the MAC address of the host and defines the changes of the sampled data.
Matrix Group
The matrix group stores statistics of traffic between hosts in a sub-network. The statistics are stored in a metric format. This group consists of the matrixControlTable, the matrixSDTable, and the matrixDSTable, as shown in Figure 3-6. Figure 3-6 Matrix group
matrix (rmon 6)
matrixControlTable (1) matrixSDTable(2)
matrixSDTable(2)
matrixControlTable Each row in this table identifies a sub-network. It displays the session status on the network interface and records the statistics of sessions in two data tables. matrixSDTable This table is used to store the statistics of traffic from the specified source host to multiple destination hosts. It keeps two rows for a pair of hosts that have recently interchanged information. Each row records traffic from one direction individually.
3 RMON and RMON2
matrixDSTable This table is similar to the matrixSD table. The difference lies in the sequence of indexes.
Filter Group
The filter group allows the monitor to trace the packets on a specified interface. Basic components of this group are two types of filters: data filter and status filter. A data filter allows the monitor to shield the traced packets in a bit method. A status filter allows the monitor to match the packets based on packet status. Filters can be used in the logical AND/OR combination to form a complicated test mode. This group consists of the filterTable and the channelTable. Figure 3-7 Filter group
filterindex (rmon 7)
filter Table(1)
channelTable(2)
The filterTable defines related filters. Each row in the channelTable corresponds to a unique channel and is associated with one or several rows in the filterTable.
Packet Capture Group

The packet capture group is set as a cache mechanism, used to capture packets after they flow through a channel. The packet capture group requires the implementation of the filter group. Figure 3-8 shows the two tables that the packet capture group contains. Figure 3-8 Packet capture group
capture ( rmon 8 ) BufferControl Table( 1 ) captureBuffer Table( 2 )
Each row in the bufferControlTable defines a cache used to capture and store packets passing through a channel. Each row in the captureBufferTable corresponds to a captured packet.
3-10
Issue 01 (2010-06-25)
3 RMON and RMON2
Event Group
The event group can define events. An event can be triggered by a certain condition in the MIB or can trigger a certain operation defined in the MIB. The event also generates logs (recorded in this group) or SNMP trap messages. This group consists of the eventTable and the logTable, as shown in Figure 3-9. Figure 3-9 Event group
event ( rmon 9)
eventTable(1)
logTable(2)
The eventTable defines events. Each row in the table describes the parameters of the event triggered by a certain condition. If events are recorded, corresponding entries in the logTable are created.
3.4.2 Features of RMON

Feature Description of RMON
and
and
RMON2
RMON2
RMON MIBs contain information used for statistics, analysis, and diagnosis. The manager can obtain the data by using the standard tools from various manufacturers. In this way, it provides the function of analyzing the remote network. Generally, each sub-network has one monitor, also called a probe or an RMON agent. A monitor is an independent device especially used to collect and analyze traffic statistics. To ensure more effective network management, the monitor must communicate with the central network management station. Monitors have the following functions: Traces information groups in the network, collects statistics, and summarizes the information. Provides important management information for the network manager; stores certain information groups for later analysis. Filters groups according to information types. Captures special information groups. To implement RMON in the network, the monitor and the RMON client software must be used. The monitor runs effectively without continuously polling the managed devices. It generates a trend diagram to illustrate the network operating status based on the capability of the RMON module to store history statistics. The monitor reports the operating status and describes any captured abnormal situation regardless of accidental network events. The client software diagnoses the fault based on the reported information from the RMON module and finds solutions.
Issue 01 (2010-06-25)
3-11
3 RMON and RMON2
RMON allows multiple monitors and collects data in the following ways: Uses a special RMON probe. The NM WS obtains management information from the RMON probe and controls network resources directly. This helps in obtaining all the information on the RMON MIB. This costs a lot because RMON probes must be deployed in all LANs. Embeds the RMON Agent into a network device (CX-, switcher and HUB), enabling the device with the RMON probe function. The NM WS uses the basic SNMP commands to exchange data information with the RMON agent and to collect the network management information. This is, however, restricted by the device resources, and the NMS collects the information in four groups only (alarm, event, history, and statistics) rather than the entire RMON MIB data. This method improves the efficiency of the network monitoring and reduces costs.
The CX600 implements the monitoring and statistics collection function only on the Ethernet interfaces of network devices.
New Feature of RMON2

RMON2 is one of the RMON MIB standards, serving as a supplement to RMON. In RMON2, certain new groups are added. RMON and RMON2 are both used to monitor Ethernet links. RMON monitors the traffic only at the MAC layer whereas RMON2 can monitor the traffic at the MAC layer and the subsequent upper layers. RMON2 can decode data packets from layer 3 to layer 7 in the OSI model. The RMON agent has the following functions: Monitors the traffic based on network layer protocols and addresses. This enables the agent to learn its connected external LAN network segment and view the incoming traffic to the LAN through the CX-. Records the incoming and outgoing traffic to and from a specific application because the RMON2 agent decodes and monitors the traffic of applications such as email, the File Transfer Protocol (FTP), and WWW. In this manner, the monitor can record the information about the actions of the application on a host and display diagrams to illustrate the action of each application. This strengthens the network monitoring.
3.4.3 Remote Monitoring of RMON and RMON2

Special devices or a function module of the system can be used to implement remote monitoring. To manage the remote monitor effectively, RMON MIB supports the terminal management function.
Configurations
To implement remote monitoring, configurations about data collection are required. The type of data required to be collected must be configured. MIBs are divided into multiple function groups. Each group contains one or more controls tables, corresponding to one or more data tables. The manager can read from or write into the control tables, whereas data tables are read-only. A control table contains all parameters in the data table. The manager collects the required data by controlling parameters in data tables. Parameter setting is implemented by
3-12
Issue 01 (2010-06-25)
3 RMON and RMON2
adding or deleting records in the control table. After data is collected according to the data in the control table, data is stored in the corresponding data table. Defining and actualizing of the functions of the monitor are implemented through tables. The operation process is similar to the database operation. Parameters in the control tables are all configured with values, and every record defines a specified data collection function. Records in the data table correspond to the records in the control table. Every record in the control table and its corresponding data records are bound through pointers. Records in the control table have indexes, which are used to search the corresponding records in the data table. Similarly, records in the data table also have indexes, which are applied to find the corresponding records in the control table. To modify parameters in the control table, first delete the record with the specified index in the control table. Note that the corresponding records in the data table must be deleted simultaneously. The manager then generates a control record and adds it to the control table. When the records in the control table and the data table are mapped one-to-one, the control table and the data table can be considered as one table.
Operation Control on the Monitor

RMON inherits operating modes in SNMP. RMON releases and controls commands by reading the specified value from the MIB and setting the value of the object. Each object can be used to indicate a command. If the object is set with a special value, it indicates that a specific operation is to be performed.
Multiple Manager Control

One RMON agent may be controlled by multiple managers. Then, resources must be shared among managers. This may lead to conflicts and unexpected results. The following are the problems that occur when the RMON agent is shared: A manager requires additional resources more than that a monitor can provide. A manager uses a significant amount of resources for a long period. This prevents other manager from using the monitor. A manager uses resources and then crashes; the resources used cannot be released. A mechanism is developed to prevent the preceding conflicts and help to resolve them. This mechanism is a simple control function in the control table of the RMON MIB. Each control table has a label identifying the owner of the function. This shows the relationship between records and related functions. When multiple managers want to access the same control table, the following can be implemented based on the relationship: A manager may recognize resources it owns as well as resources that it no longer needs. A network manager can know the resources and successfully release resources or related functions. An authorized network manger can release resources that are reserved by other managers. Upon initialization, a manager can recognize the resources it has reserved. It then releases the resources if it no longer needs them. In RMON, owner ID cannot be used as passwords or access control mechanism. In SNMP management frame, the unique access control mechanism is SNMP views and community names. If a readable and writable RMON control table exists in the views of some managers, all these managers can read from and write into the control table. The control table can be deleted or modified by the owner only. Other managers have read-only authority.
Issue 01 (2010-06-25)
3-13
3 RMON and RMON2
If multiple NMSs want to access the same control table, it is more effective to use the resource sharing function. When a manager intends to utilize a function in a monitor, it first scans the control table of that function to find the function or a similar function defined by other managers for sharing. If the function is found, the manager can read the records from the data table corresponding to the control table. The owner of the records may indiscriminately modify or delete the functions. Therefore, in certain cases, other managers may find that the expected functions have been modified or deleted. Generally, during the initialization of each monitor, default function sets should be configured. The labels of function owners are characters starting with "monitor", indicating that resources related to the pre-defined functions belong to the specified monitor. If some managers need to use the functions, they can only read but cannot modify or delete the function. Functions can be deleted by the manager of the monitor (commonly, network manager) only.
3.4.4 Table Management in RMON and RMON2

RMON MIBs are composed of control tables and data tables. Control tables define the structure of data tables by setting parameters, and data tables are used to store information. Without modifying or disobeying the SNMP management frame, RMON provides standard specifications, clearly describing the operations as row addition or row deletion.
Row Addition
The manager obeys the following rules to add rows through the SNMP Set operation: The manager sends the Set request to the managed device for adding a row. If the index of the new row does not conflict with indexes of other rows, the agent generates a new row. If the tabular information is not configured for the new row, the agent can set the row to the default value or maintain the row in the incomplete status. Before the manager requires adding a new row, the inactive row must keep the inactive status. If the new row to be created exists, the agent responds with an error packet.
Row Deletion
If the manager sets the value of this object to an invalid value by sending the Set request to the agent, a row can be deleted.
Row Modification
The manager sets the value of the object to an invalid value and then modifies the value by sending the Set request. In this way, the value of the object is modified.
3.4.5 Implementation of RMON Devices
and
RMON2 on Huawei
This section describes the implementation of RMON and RMON2 on Huawei devices.
3-14
Issue 01 (2010-06-25)
3 RMON and RMON2
Implementation of RMON
RMON effectively implements monitoring on all network segments. In LANs, deploying RMON probes is highly expensive. In addition, monitoring network segments individually degrades the performance of RMON and generates heavy traffic on the network. To solve the preceding problems, manufacturers embed the RMON module into network devices. This is more economic and effective. The RMON agent module is embedded on Huawei CX-s, forming a complete system with other modules in the CX600. The NMS can use SNMP. The network managers then do not need extra learning to handle RMON. RMON in the CX600 supports four groups, namely, statistics, history, alarm, and event, defined in RFC 2819, and a Performance-MIB defined by Huawei. The four groups are described as follows: Statistics group The statistics group collects basic statistics of each monitored sub-network. The statistics include the data flow on a network segment, distribution of various packets, error frames, and collision times. The statistics group contains an ethernetStatsTable. Rows can be created in the ethernetStatsTable only on Ethernet and Gigabit Ethernet interfaces (not sub-interfaces). An interface corresponds to only one row in the etherStatsTable. The etherStatsTable has a maximum of 100 rows.
The results of the RMON statistics are inconsistent with the output of the display interface command. Although data is collected from the bottom layer in both cases, the RMON information is more comprehensive.
History group The history group periodically collects the network status statistics and stores them for future use. The history group has the following tables:
historyControlTable: controls information such as the sampling interval and interface information. After being sampled, data is saved as a related entry in the ethernetHistoryTable. Rows can be created in the historyControlTable only on Ethernet and Gigabit Ethernet interfaces (not sub-interfaces). The historyControlTable contains a maximum of 100 rows. etherHistoryTable: provides the network administrator with other history statistics such as the traffic on a network segment, error packets, broadcast packets, utilization, and collision times.
Each entry in the historyControlTable defines a sampling interval and is associated with the historyControlTable that the sampling is based on. The history control table is created once one sampling interval arrives. Each entry in the historyControlTable corresponds to a maximum of 10 pieces of history records in the etherHistoryTable. The previous records are overwritten circularly when the number of records exceeds 10. When the RMON module receives a request for row deletion from the historyCotrolTable, the manager cannot delete the specified row because the etherHistoryTable does not contain the status of the row. Instead, the manager can delete all the associated etherHistoryTables. Alarm group The alarm group allows predefining a set of thresholds for alarm variables that can be any object in the local MIB. The monitor records logs or sends trap messages to the NMS when the sample crosses a threshold in a certain direction. The alarm table requires the implementation of the event group. As defined in RFC 2819, the alarm function has a hysteresis mechanism to limit the generation of alarms. This mechanism generates an
Issue 01 (2010-06-25)
3-15
3 RMON and RMON2
event when the sampled data crosses the threshold in one direction, and does not generate more events until the sampled data crosses the threshold in the opposite direction. This is inconvenient for monitoring devices. The CX600 does not apply this mechanism because it may stop generating alarms for a long period. In the CX600, once the sampled value becomes normal, the alarm function can be reused to monitor the value alarm variables. The alarm table requires the implementation of the event table. The alarm table takes effect and automatically updates the status of effective parameters to valid only after the corresponding event table is created. The alarm table contains a maximum of 60 rows. The alarm group contains an alarmTable. Event group The event group records all events occurring on the RMON agent. It controls events and prompts on the managed devices. Entries in this group are used to describe parameters that trigger the events. Each event row is activated by related variables in the MIB. After an event row is created, its associated alarm row and prialarm row automatically update their status to valid if the parameters are effective. If the event row becomes invalid, it must update the status of the associated valid alarm row and prialarm row, from invalid to critical. The event table has a maximum of 60 rows. Logs or trap messages are sent to the NMS for notifying that an event occurs. The event group contains the eventTable and the logTable. Performance-MIB Based on the alarmTable in RFC 2819, the RMON prialarm group is enhanced with a function: setting the alarm object and the time span of an alarm entry in the form of an expression. The RMON Performance-MIB has a prialarmTable. After an event row is created, its associated prialarm row automatically updates the status to valid if the configured parameters are effective. If the event row becomes invalid, it must update the status of the associated effective prialarm row, from invalid to critical. The prialarmTable has a maximum of 50 rows. In the CX600, each entry is given a specific time span, to save system resources. Lifetime indicates the time period of an entry that is not in the valid state. The longer an entry keeps invalid, the shorter its lifetime is. The entry is deleted when the lifetime reaches the value 0. Table 3-1 shows the capacity of various tables and the maximum time span of each table. Table 3-1 Time span of each table Table ethernetStatsTable historyControlTable alarmTable eventTable logTable prialarmTable Entry Capacity (Byte) 100 100 60 60 600 50 Maximum Lifetime (s) 600 600 6000 600 6000
3-16
Issue 01 (2010-06-25)
3 RMON and RMON2
When an interface board or an interface card is removed, its corresponding ethernetStatsTable and historyControlTable entries become invalid. The CX- then sets the default lifetime of these tables to 1200s. If lifetime reaches 0, entries are deleted. Adding an interface when its corresponding entries still exist makes the entries to be valid again.
Implementation of RMON2
RMON2 is one of the RMON MIB standards, serving as a supplement to RMON. In RMON2, some groups are added. As defined in RFC 2021, RMON2 contains several MIB groups: protocolDir, protocolDist, addressMap, nlHost, nlMatrix, alHost, alMatrix, usrHistory, probeConfig, and rmonConformance. Currently, the CX600 supports two RMON2 MIB groups: protocolDir and nlHost. Figure 3-10 shows the relationship between the protocolDirTable, nlHostTable, and hlHostControl table. Figure 3-10 Relationship between tables
protocolDirTable
protocolDirID protocolDirParameters protocolDirLocalIndex other PARA
nlHostTable
index1 nlHostTimeMark (index2) index 3 nlHostAddress (index4) other PARA
hlHostControlTable
hlHostControlInde other PARA
protocolDirTable It lists the protocols, which the RMON agent can decode and count. Each row in the table corresponds to one type of protocols. The protocols can be network layer protocols, transport layer protocols, or higher-layer protocols. Note that nlHost supports the network layer host group instead of the application layer group. That is, application layer host control and the alHostTable are not implemented in the host control table. Therefore, only IP can be set in the protocol directory group. nlHostTable The nlHostTable is used to count the amount of inbound and outbound traffic on the interface. It provides traffic statistics for the specified network address. This table collects statistics of the host discovered by the RMON agent and classifies statistics based on network addresses. hlHostControlTable The hlHostControlTable contains two tables: network layer host control table and application layer host control table. It defines the monitored interface, and records the
3 RMON and RMON2
total number of frames that are received on the interface but not recorded in the nlHostTable. It also records the number of times of entry addition and deletion and the expected maximum number of entries in the nlHostTable. The alHostControlTable cannot control the alHostTable.
3.5 Impact
3.5.1 On the System Performance 3.5.2 On Other Features 3.5.3 Huawei's Advantage 3.5.4 Other Defects

Collecting statistics on the interface in the software forwarding system is quite time-consuming, which seriously affects the system performance. Therefore, when multiple interface statistics tables are configured, the system performance is affected.

None.
3.5.3 Huawei's Advantage

The alarm function of RMON uses a hysteresis mechanism to restrict the generation of events. When an upper/lower threshold is exceeded, one event is generated and no more event is generated until the lower/upper threshold is exceeded. A new alarm can be generated when the sampled value is restored to a normal value on the CX600, the horizontal axis indicates the time point at which traffic is sampled; the vertical axis indicates the traffic volume. The lower alarm threshold is 200 and the upper alarm threshold is 900. Even though the traffic volumes sampled at T1, T2, T4, and T5 exceed the upper alarm threshold (900), only the traffic exceeding at T1 and T4 causes alarms to be generated. Figure 3-11 Sampling of flow
Value 900
200 T1 T2 T3 T4 T5 Time
3-18
Issue 01 (2010-06-25)
3 RMON and RMON2
Collecting statistics on the interface in the software forwarding system is quite time-consuming, which seriously affects the performance. Therefore, you need to check whether the interface on the CX600 is enabled with RMON. By default, collecting statistics on the interface in the software forwarding system is disabled. In this case, the system performance is not affected. Based on the alarmTable in RFC 2819, the RMON prialarmTable is added with two functions: setting the alarm object in the form of expressions and setting the TTL of a prialarm entry. This is the only difference between the RMON prialarmTable and the alarmTable. The added entries in the prialarmTable are:
Expressions of the particular variable to be sampled. It is the arithmetic expressions composed of the OIDs of alarm variables, that is, +, -, *, /, and round brackets. Descriptions of prialarm entries in a string of characters. Prialarm status period. It must be set to a value greater than the sampling period. Prialarm status type. It can be Forever or During. If During is set, no alarm is generated and the entry is deleted after the specified prialarm state period (in seconds) expires.
Sampling types are added on the CX600 so that the 10 Gbit/s to 40 Gbit/s bandwidth can be monitored. The RMON table can be configured and viewed through commands on the CX600.
3.5.4 Other Defects

None.

Abbreviations
Abbreviations RMON Full Spelling Remote Monitor
Issue 01 (2010-06-25)
3-19
4 HGMP
4
About This Chapter
4.1 Introduction to HGMP 4.2 References 4.3 Availability 4.4 Principles 4.5 HGMP Application 4.6 Impact
HGMP
4.1 Introduction to HGMP

Definition
The Huawei Group Management Protocol (HGMP) addresses the automatic and centralized management of a great number of scattered devices.
Purpose
Without HGMP, equipment maintainers cannot manage devices remotely or operate devices in batches. If devices become faulty or need to be upgraded, equipment maintainers have to rectify faults on site or upgrade the devices one by one. The workload will be heavy and trivial along with the increase in the number of Ethernet devices if the devices are still managed and maintained separately. Using HGMP to manage devices has the following advantages: 1. 2. 3. Private network IP addresses are used to manage devices, and thus public network IP addresses are saved. Devices can be managed in batches, which greatly improves the efficiency of management. Devices can be logged in to and operated remotely.
Issue 01 (2010-06-25)
4-1
4 HGMP
4.2 References
This protocol is Huawei proprietary.
HGMP manages only the devices where HGMP is enabled.
4.3 Availability
The CX600, functioning as the HGMP administration switch or HGMP member switch
License Support
This function is not license controlled.
Version Support
Hardware Support
Only the following interface boards on the CX600 support HGMP: LPUA LPUF-21 LPUF-40
4.4 Principles
An HGMP cluster is a unified management domain that comprises a group of devices. A device in the domain can be configured as an administrator device to manage and control the other devices in the domain.
An HGMP cluster is different from a multi-chassis cluster. The basic principle of the multi-chassis cluster system is that multiple chassis are clustered to implement smooth expansion of the system capacity, including the increase in interface boards and interfaces, and the entire system can still be regarded as one device.
4.4.1 Roles of Devices in a Cluster 4.4.2 Multicast MAC Address 4.4.3 Neighbor Information Collection 4.4.4 Topology Information Collection
4-2
Issue 01 (2010-06-25)
4 HGMP
4.4.5 Management VLAN 4.4.6 Communications Between Cluster Members and External Devices
4.4.1 Roles of Devices in a Cluster

At present, the devices in an HGMP cluster can play the following roles: Administrator CX device Member CX device Candidate CX device
The administrator, member, or candidate CX device is a mere role appellation and does not indicate any actual device type.
Role Administrator CX device Member CX device Candidate CX device
Description An administrator CX device is the management device in a cluster and needs to be manually specified. A member CX device is a member device in a cluster and managed by the administrator CX device. A candidate CX device is the device that supports cluster functions but does not join any cluster.
In a cluster, the roles of devices can be exchanged, as shown in Figure 4-1. Figure 4-1 Schematic diagram of role exchange in a cluster
Candidate switch
C th an e ce a d ll m e sw in d to itc istr be D h at es or ig ad n m ate i sw nis d a itc tra s th h tor e r te us cl a a s m in fro r Jo ed te et s el clu
Administrator switch
Administrator switch
4.4.2 Multicast MAC Address

Cluster management packets are transmitted in the format of multicast packets. These multicast packets have a fixed destination address, which defaults to 0180-C200-000A. The multicast MAC address can be configured within an allowable range. The following are the currently supported ranges: 0180-c200-0001 From 0180-c200-0003 to 0180-c200-0007
Issue 01 (2010-06-25)
4-3
4 HGMP
From 0180-c200-0009 to 0180-c200-0010 From 0180-c200-0020 to 0180-c200-002f

Certain multicast MAC addresses have been used by other protocols. Thus, multicast MAC addresses used in HGMP are not successive.
4.4.3 Neighbor Information Collection

NDP is short for Neighbor Discovery Protocol. As a Huawei proprietary protocol, NDP is a basic protocol for cluster management. It discovers neighbors and collects information about neighbors. The neighbor information collected by NDP includes the device model, software version, hardware version, interface used for connection, member ID, private IP address used for communications within a cluster, and hardware platform. NDP packets are carried by Ethernet-II frames whose format is shown in Figure 4-2. Figure 4-2 Ethernet-II frame format
DA_MAC (6bytes)
SA_MAC (6bytes)
ProtocolType Packettype (2bytes) (4bytes)
Payload (variable)
FCS (4bytes)
The destination MAC address is a multicast address, which defaults to 0180-C200-000A. The fields of the Ethernet_II frame are described as follows: DMAC It indicates the destination MAC address. DMAC specifies the receiver of the frame. SMAC It indicates the source MAC address. SMAC specifies the station that sends the frame. Type The 2-byte Type field identifies the upper layer protocol of the Data field. The receiver can know how to parse the Data field according to the Type field. On the Ethernet, multiple protocols can coexist on a LAN. The hexadecimal values in the Type field of an Ethernet_II frame stand for different protocols.

Frames with the Type field value being 0800 are IP frames. Frames with the Type field value being 0806 are Address Resolution Protocol (ARP) frames. Frame with the Type field value being 0835 are Reverse Address Resolution Protocol (RARP) frames. Frames with the Type field value being 8137 are Internetwork Packet Exchange (IPx) and Sequenced Packet Exchange (SPx) frames.
Data The minimum length of the Data field is 46 bytes, which guarantees that the frame is at least 64 bytes in length. The 46-byte Data field is required even if you attempt to transmit only 1-byte information.
4-4
Issue 01 (2010-06-25)
4 HGMP
If the payload of the Data field is less than 46 bytes, the Data field must be padded to 46 bytes. The maximum length of the Data field is 1500 bytes. CRC The Cyclic Redundancy Check (CRC) field provides an error detection mechanism. Each sending device calculates a CRC code containing the DMAC, SMAC, Type, and Data fields. Then the CRC code is filled into the 4-byte CRC field.
4.4.4 Topology Information Collection

NTDP is short for Network Topology Discovery Protocol. As a Huawei proprietary protocol, NTDP collects topology information and is a basic protocol for cluster management. The topology information collected by NTDP includes the software information, hardware information, and NDP entries. Candidate devices can be added to a created cluster based on the topology information collected by NTDP. Figure 4-3 Schematic diagram of topology information collection
NMS
Topplogy collection switch Switch enabled with NTDP NTDP request packet NTDP response packet
Issue 01 (2010-06-25)
4-5
4 HGMP
Figure 4-3 shows the typical networking of HGMP. The topology information collected by NTDP includes the software information, hardware information, and NDP entries. NTDP collects the information through NTDP packets, which are encapsulated into Ethernet-II frames for transmission. NTDP collects the following types of equipment information: Topology information about all the devices in a cluster NTDP collects the topology information about all devices in a cluster by sending an NTDP topology request packet and receiving the response packets. All devices in the cluster respond to this request and forward the packet, which thus can traverse all devices in the cluster. The destination MAC address of the NTDP topology request packet is the HGMP multicast MAC address. Topology information about a specified device NTDP collects the topology information about a specified device by sending an NTDP direct topology request packet. Only the destination device responds to the request and does not forward the packet to other devices. The destination MAC address of the NTDP direct request packet is the MAC address of the specified device. Information about the device initiating the topology information collection When receiving the topology request packet, the devices in the cluster send NTDP topology response packets to the device that sends the request. An NTDP topology response packet includes the basic information about the local device and information about NDP entries. The destination address of an NTDP topology response packet is the MAC address of the device that sends the request.
4.4.5 Management VLAN

A management VLAN needs to be configured when HGMP is adopted for cluster management. Except NDP packets, all the data of a cluster is transmitted within the management VLAN. The ID of the management VLAN can be configured as required. By default, the ID of a management VLAN is 1.
4.4.6 Communications Between Cluster Members and External Devices

when a cluster is created, the IP addresses used for communication in the HGMP cluster can be either public addresses or private addresses.
Using public IP addresses

If public IP addresses are used, the cluster members can be allocated with public IP addresses. In this case, cluster members can directly communicate with external devices after routes are configured.
Using private IP addresses

1. When a user sends a packet with a private IP address to any external device, the private source IP address and port of the packet are replaced with a public IP address and a port that can be identified on the public network on the outgoing interface of the administrator CX device.
4-6
Issue 01 (2010-06-25)
4 HGMP
2.
When the administrator CX device receives an external packet, it searches the address-and-port mapping table to replace the destination IP address and port of the packet with a private IP address that can be identified on the private network. After an HGMP cluster is created, private IP addresses are allocated to cluster members. Generally, the devices not belonging to any cluster are allocated with public IP addresses. Thus, cluster members and external devices communicate with each other through Network Address Translation (NAT).
4.5 HGMP Application

HGMP can be used for the internal management of banks, electrical power systems, campuses, and enterprises. The devices scattering on the network can be added to a unified management domain to improve management efficiency. As shown in Figure 4-4. Figure 4-4 HGMP Application
IP/MPLS
Administrator
Member 2 Candidate 2
Candidate 1
Member 1 Cluster Member 3 Member 5 Member 4
General 1 Administrator: administrator CX device Candidate: candidate CX device Member: member CX device General: general CX device that does not support HGMP
Batch upgrade HGMP provides the batch upgrade function to download files and deliver configuration files to part of or all the devices in a cluster. The command used for batch upgrade can be run on the administrator CX device to specify part of or all the member CX devicees to perform upgrade.
Issue 01 (2010-06-25)
4-7
4 HGMP
To prevent the FTP server congestion because excessive clients download files at the same time, you can set the number of member CX devicees allowed to simultaneously download files through FTP in HGMP. A query of the batch delivery result list can show the files obtained by member CX devicees. The batch delivery result list stores only the latest execution result as the latter execution automatically overrides the previous execution. Incremental configuration In a cluster, some member CX devicees may have the same configurations such as creating a VLAN. Through incremental configuration, part of or all the member CX devicees in a cluster can be delivered with the same configurations. You only need to edit the command list on the administrator CX device, and this CX device then performs the configuration based on the commands. In addition, the command execution results of each member CX device can be queried. Incremental configuration is applicable to scenarios where member CX devicees need to be operated in batches, for example, to create VLAN 10 on multiple member CX devicees. A query of the incremental configuration result list can show the command execution result of member CX devicees. If en execution error is displayed, you can find the corresponding command based on the index. The incremental configuration result list stores only the latest execution result as the latter execution result automatically overrides the previous execution result. The command list is configured in the incremental configuration view. The execution of commands is closely related to the view. The sequence of commands in the command list should be consistent with the sequence of commands manually configured on devices. Plug and play Before a device joins a cluster, you need to manually configure the device. When a great number of CX devicees need to be added to a cluster, you can use the plug and play function to simplify the process. After using the Product Adaptive File (PAF) to configure devices with certain basic settings required for a cluster member, you can connect the devices to the cluster devices physically. Then, the devices are added to the cluster automatically. Plug and play uses the PAF to perform certain basic configurations. The plug and play function needs to be enabled on the administrator CX device. Interfaces connecting the administrator CX device and member CX devicees need to be added to a management VLAN in trunk mode. The function of regularly collecting NTDP packets needs to be enabled on the administrator CX device. Saving and restoring configuration files You can save the configuration files of member CX devicees to a specified FTP server through configuration synchronization. Then, the specified configuration file can be delivered to specified member CX devicees through the batch upgrade function. In addition, when a device is replaced with a new device of the same type, and the physical topology of the cluster is unchanged, the administrator CX device automatically delivers the configuration files of the old device to the new one. You need to enable plug and play when you replace the devices and have configuration files delivered automatically. Ensure that the physical interfaces of the old and new devices are the same; otherwise, the configuration file of the old device does not take effect.
4-8
Issue 01 (2010-06-25)
4 HGMP
In addition, you need to specify an FTP server before synchronizing the configuration files. Security feature After a cluster is created and configured with basic functions, you can close the network edge of the cluster as required and ascertain the cluster management range. When plug and play is enabled and the PAF is used to control devices configured with HGMP functions to automatically enable NDP and NTDP on Layer 2 interfaces, a great number of Layer 2 interfaces on member CX devicees are automatically enabled with NDP and NTDP. These interfaces do not take part in cluster management, and thus are called unrelated interfaces. After NDP or NTDP is disabled on unrelated interfaces in the cluster, the interfaces no longer send NDP or NTDP packets to the CPU, that can reduce the afford of CPU and ensure stable topology of the cluster.
4.6 Impact
4.6.1 On the System Performance 4.6.2 On Other Features 4.6.3 Our Advantages 4.6.4 Defects

None.

None.
4.6.3 Our Advantages 4.6.4 Defects

Abbreviations
Abbreviation HGMP NDP NTDP Management VLAN NAT Full Spelling Huawei Group Management Protocol Neighbor Discover Protocol Network Topology Discover Protocol Management Virtual Local Area Network Network Address Translation
Issue 01 (2010-06-25)
4-9
4 HGMP
4-10
Issue 01 (2010-06-25)
5 NTP
5
About This Chapter
5.1 Introduction 5.2 References 5.3 Availability 5.4 Principle 5.5 Impact 5.6 Terms and Acronyms
NTP
5.1 Introduction
Definition
Network Time Protocol (NTP) is an application layer protocol used on the internet to synchronize clock among a set of distributed time servers and clients. In this manner, the clock of the host is synchronized with certain time standards.
Purpose
NTP synchronizes all the clocks of devices on the network so that these devices can provide multiple applications based on the uniform time.
5.2 References
The references of this feature are as follows: Document RFC 1305 Description Basis of the NTP module requirements specification Comm ents
Issue 01 (2010-06-25)
5-1
5 NTP
5.3 Availability
Primary reference clock, mostly a radio clock or GPS Secondary time server, probably the CX600
License Support
The NTP function is not license controlled.
Version Support
5.4 Principle
NTP synchronizes time among a set of distributed time servers and clients. In this manner, the time of the host is synchronized with certain time standards. The server and client are two relative concepts. The device that announces the willingness to synchronize clocks and provides the standard time is a server; the device that announces its willingness to be synchronized is a client. A local system running NTP can be synchronized by other clock sources or acts as a clock source to synchronize other clocks. In addition, mutual synchronization can be implemented through NTP packet exchanges. NTP message transmission is based on UDP and uses the port number 123. 5.4.1 Network Architecture 5.4.2 Operating Mode 5.4.3 Event Processing of NTP 5.4.4 Operating Principle 5.4.5 Security Mechanism 5.4.6 Dynamic and Static Associations of NTP
5.4.1 Network Architecture

As shown in Figure 5-1, the networking of NTP is composed of primary time server, secondary time server, clients, and interconnecting transmission paths.
5-2
Issue 01 (2010-06-25)
5 NTP
Figure 5-1 Network Architecture of NTP
Secondary server
Primary server
Secondary server
Third server
Third server
A primary time server is directly synchronized with a primary reference source, which is usually a radio clock or Global Positioning System (GPS). A secondary time server synchronizes its clock with the clock of the primary time server on the network or other secondary time servers, and transmits the time information to other hosts on the network through NTP. Under normal circumstances, primary and secondary time servers in the synchronization subnet assume a hierarchical-master-slave structure, with the primary server at the root and the secondary server at successive stratums toward the leaf node. The higher the stratum level is, the less accurate the clock will be.
5.4.2 Operating Mode

In actual application, you need to select a proper NTP operating mode based on the network deployment to meet various clock synchronization requirements. The operating modes of NTP are classified into client/server mode, peer mode, broadcast mode, and multicast mode.
Client/Server Mode
Client mode: The host operating in this mode periodically sends NTP request messages to the server regardless of the reachability state or the stratum of the server. Usually, the host operating in client mode is a workstation on a specified network, which synchronizes its clocks with the clock on the server but does not alter the clock of the server. Server mode: The host operating in this mode receives NTP request messages and responds to the client. Usually, the host operating in server mode is a time server on a network, which provides synchronization information for the clients but does not alter its own clock. During and after the restart, the host operating in client mode periodically sends NTP request messages to the host operating in server mode. After receiving the NTP request message, the server swaps the position of destination IP address and source IP address, and the source port number and destination port number, fills in the necessary information, and sends the message to the client. The server does not need to retain state information when the client sends the request message. The client freely adjusts the interval for sending NTP request messages according to the local conditions.
Issue 01 (2010-06-25)
5-3
5 NTP
Peer Mode
In this mode, the active peer and the passive peer can be synchronized with each other. To be specific, the higher stratum (lower level) peer is synchronized with the lower stratum (higher level) peer. Active peer: The host operating in this mode periodically sends packets regardless of the reachability state or the stratums of their peers. In this manner, the host can provide synchronization information for the peer and synchronize its clock with the peer. Passive peer: The host operating in this mode receives packets and responds to their peers. In this manner, the host provides synchronization information for the peer but synchronizes its clocks with the peer. The premise of being a passive host is as that the host receives messages from a peer operating in active mode; the route from the host to the peer is reachable and the stratum of the peer is higher than or equal to the stratum of the host.
The host operating in passive mode is at the lower stratum in the synchronization subnet. You need not to obtain information about the peer in advance because the connection between peers is not set up and status variables are not configured unless the passive host receives NTP messages from the peer.
Broadcast Mode
The host operating in broadcast mode periodically sends clock-synchronization packets to the broadcast address 255.255.255.255 regardless of the reachability state or the stratum of its peer. The host in this mode is usually a time server using high-speed broadcast media on the specified network, which provides synchronization information for its peers but does not alter the clock of its own. The client senses the broadcast packets from the server. After receiving the first broadcast packet, to estimate the network delay, the client leaves the broadcast mode and then temporarily operates in client/server mode to interchange packets with the remote server. Later, it restores the broadcast mode, continuing to listen to the broadcast packets and re-synchronizing the local clock according to the received broadcast packets. The broadcast mode is applied to the high speed network that has multiple workstations and does not require high accuracy. In a typical scenario, one or more time servers on the network periodically send broadcast packets to the workstations. The delay of packet transmission in a LAN is at the milliseconds level.
Multicast Mode
The host operating in multicast mode periodically sends clock-synchronization packets to a multicast address. Usually, the host in this mode is a time server using high-speed broadcast media on the network, which provides synchronization information for all the peers but does not alter the clock of its own. The client listens to the multicast packets from the server. After receiving the first multicast packet, to estimate the network delay, the client temporarily operates in client/server mode to interchange packets with the remote server. Later, it restores the multicast mode, continuing to listen to the multicast packets and re-synchronizing the local clock according to the received multicast packets.
5.4.3 Event Processing of NTP

The followings are considered as significant events of NTP: the event generated when the timer of the peer in active mode times out; the event generated when NTP request messages
5-4
Issue 01 (2010-06-25)
5 NTP
sent from various peers arrive at the server. An event can also be generated when certain commands are run or system is faulty, for example, the primary reference clock is faulty. Each mode processes the event with the same procedure: sending messages, receiving messages, processing messages, and updating the clock.
Sending Messages
In all modes except the broadcast client mode and all server modes, the peer sends NTP request messages when its timer times out. In broadcast client mode, the peer never sends NTP request messages. In server mode, the peer sends NTP request messages only in response to the received messages. If the received NTP request message does not result in a local permanent connection, the action of receiving message invokes the action of sending message to retain the connection. To ensure a valid response message, the time when the message is sent must be accurately saved and then added to the message.
Receiving Messages
After receiving the NTP request message, the server first checks the mode field of the NTP request message. If the value is 0, it indicates that the peer adopts an earlier NTP version. Then, the server checks whether modes of the local end and the peer are matched. If matched, the received message is processed; if the matching result is error, the received message is discarded and the connection is deleted unless it is configured in advance. The following cases exist: If both the local and remote hosts operate in client modes, the matching result is displayed as error. The message is discarded and an error message is returned. If the matching result is displayed as recv, the received message is processed. If the packet header is valid, the connection is marked as reachable. If both the packet header and the data are valid, the clock-update procedure is invoked to update the local clock. Otherwise, the connection is deleted if it is not configured in advance. If the matching result is displayed as xmit, the received message is processed and a response message is sent immediately. If the connection is not configured in advance, it is deleted. If the matching result is displayed as pkt, the received message is processed. If the packet header is valid, the connection is marked as reachable. If both the packet header and the data are valid, the clock-update procedure is invoked to update the local clock. Otherwise, if the connection is not configured in advance, a response message is sent immediately, and then the connection is deleted.
Processing Messages
This process is used to check the message validity, calculate delay/offset samples, and invoke other procedures to filter data and select reference source. This process first requires that the transmit timestamp should be different from the transmit timestamp of the last message received from the same peer; otherwise, the message may be outdated. Secondly, it is required that the originate timestamp should be different from the originate timestamp of the last message sent to the same peer; otherwise, the message may be mis-sequenced, bogus or less accurate. In broadcast mode (5), the roundtrip delay is zero. In this case, the high accuracy of the time-transfer operation is not ensured. However, the accuracy achieved may be adequate for most objectives.
Issue 01 (2010-06-25)
5-5
5 NTP
After the preceding procedure, the best clock sample can be selected from a specified clock and the best clock can be selected from clock groups at different stratums. Finally, the delay (peer.delay), offset (peer.offset), and dispersion (peer.dispersion) for the peer are all determined.
Updating the Clock

After the valid clock offset, delay and dispersion are determined by the clock-filter procedure, the clock-selection procedure invokes the clock-update procedure. The result of the clock-selection and clock-combining procedures is the final clock adjustment value. The local-clock procedure then updates the local clock based on this value. If no reference source is found after these procedures, the clock-update procedure stops. The clock-selection is then invoked, which contains two algorithms: intersection and clustering. The intersection algorithm generates a list of candidate peers suitable to serve as the reference source and calculates a confidence interval for each peer. It then discards falsetickers using a technology adopted from Marzullo and Owicki [MAR85]. The clustering algorithm orders the list of remaining candidates based on their stratums and synchronization distance. It repeatedly discards outlyers peers based on select dispersion until only the most accurate, precise and stable candidates are selected. If the offset, delay, and dispersion of the candidate peers are close identical, the clock combining analyzes the clock candidates and then provides the parameters determined through comprehensive analysis to the local end for updating the local clock.
5.4.4 Operating Principle

Figure 5-2 shows the NTP implementation: CX- A and CX- B are connected through a Wide Area Network (WAN). Each of them has its own system clock, which is synchronized automatically through NTP.
5-6
Issue 01 (2010-06-25)
5 NTP
Figure 5-2 Diagram of NTP implementation
NTP packet 10:00:00am
Step1: CX-A
Network CX-B
NTP packet 10:00:00am 11:00:01am
Step2: CX-A
Network CX-B
NTP packet 10:00:00am 11:00:01am 11:00:02am
Step3: CX-A
Network CX-B
NTP Packet received at 10:00:03
Step4: CX-A
Network CX-B
Presuming that: Before the clocks of CX- A and CX- B are synchronized, the clock of CX- A is 10:00:00 am. and the clock of CX- B is 11:00:00 am. CX- B acts as an NTP time server. CX- A must synchronize its clock with CX- B. Unidirectional transmission of an NTP message between CX- A to CX- B takes one second. Both CX- A and CX- B take one second to process an NTP message. The process of synchronizing the system clock is as follows: CX- A sends an NTP message to CX- B. The message carries an initial timestamp, 10:00:00 am (T1), indicating the time when it leaves CX- A. When the NTP message reaches CX- B, CX- B adds a timestamp, namely, 11: 00:01 am. (T2) to the NTP message, indicting the time when CX- B receives the message. When the NTP message leaves CX- B, CX- B adds a transmit timestamp, namely, 11:00:02 am. (T3) to the NTP message, indicating the time when the message leaves CXB. When CX- A receives this response message, it adds a new receive timestamp, which is 10:00:03am (T4). CX- A uses the received information to calculate the following two important parameters: A roundtrip delay of the NTP message: Delay = (T4 - T1) - (T3 - T2).
Issue 01 (2010-06-25)
5-7
5 NTP
The clock offset of CX- A by taking CX- B as a reference: Offset = ((T2 - T1) + (T3 T4))/2. CX- A sets its clock based on the delay and offset to implement clock synchronization with CX- B.
NTP uses the standard algorithm in RFC 1305 to ensure the precision of clock synchronization. The preceding example is only a brief introduction to the operating principle of NTP.
5.4.5 Security Mechanism

When a time server in the subnet is faulty or data is maliciously modified or destroyed, timekeeping on other time servers in the subnet should not be affected. To meet this requirement, NTP provides two security mechanisms: access authority and NTP authentication to guarantee the network security.
Access Authority
The deivce protects local NTP services by setting access authority. This is a simple measure to ensure security. The device provides four access authority levels. When an NTP access request message reaches the local end, the device matches it with the access authority from level 1 to level 4. The first matched authority level takes effect. The matching sequence is as follows: peer: indicates the minimum access authority. The remote end can perform time requests and control queries for the local NTP service. The local clock can also be synchronized with the clock of the remote server. server: indicates that the remote end can perform time requests and control queries for the local NTP service. The local clock, however, cannot be synchronized with the clock of the remote server. synchronization: indicates that the remote end can perform time requests only for the local NTP service. query: indicates the maximum access authority. The remote end can perform control queries only for the local NTP service.
Authentication
NTP authentication can be enabled on networks demanding high security. NTP authentication should be separately configured on the client and the server. When configuring NTP authentication, note the following rules: Configurations of NTP authentication on both the client and the server must be complete. Otherwise, the authentication does not take effect. If NTP authentication is enabled, you must configure the key and declare the key as reliable. Keys configured on the server and the client must be identical.
5.4.6 Dynamic and Static Associations of NTP

To manage the synchronization information transmitted to each reference source, the NTP module sets up a peer structure for each reference source. These peer structures are saved as links in the form of Hash. Each peer structure corresponds to an association (or a session).
5-8
Issue 01 (2010-06-25)
5 NTP
NTP supports a maximum of 128 associations, including static and dynamic associations. The maximum number of dynamic associations is 100.
Static Association
A static association is set up through command lines.
Dynamic Association
A dynamic association is set up dynamically during the NTP implementation process.
Static and Dynamic Associations in Different Modes

In client/server mode, you must configure the IP address of the server to be synchronized with on the client. In this situation, a static association is set up on the client. The association is not set up on the server because the server only passively responds to the request messages from the client. In symmetric peer mode, the IP address of the symmetric passive end must be configured on the symmetric active end. In such a case, a static association is set up on the symmetric active end for the message exchange between peers. When the passive peer receives the seventeenth message from the active peer

If NTP authentication is not enabled, a dynamic association is set up If NTP authentication is enabled, a dynamic association is set up only after the authentication
In multicast mode, you must configure the IP address of the server on the interfaces of the multicast server. In such a case, a static association is set up on the server. You need also enable the client mode on the multicast client. This is not intended to set up a static association but to set up a dynamic association after the client receives a response packet from the server. In broadcast mode, you must enable the server mode on the interfaces of the broadcast server. In such a case, a static association is set up on the server. You need also enable the client mode on the broadcast client. This is not intended to set up a static association but to set up a dynamic association after the client receives a response packet from the server.
5.5 Impact
5.5.1 5.5.2 Impact on the System Performance Impact on Other Features
5.5.1 Impact on the System Performance

When the number of NTP messages reaches the CPU per seconds is huge, the CPU usage is high.
Issue 01 (2010-06-25)
5-9
5 NTP
When devices are of empty configuration, a tester is configured to send packets to simulate the packet attack scenario. If the tester sends 1000 NTP messages per second, the CPU usage of the receiver is about 24% to 25%; if the tester sends 1000 NTP message per millisecond, the CPU usage of the receiver is close to 100%.
5.5.2 Impact on Other Features

None.
5.6 Terms and Acronyms

Terms
Terms NTP Description Network Time Protocol (NTP) is an application layer protocol used in the internet to synchronize timekeeping among a set of distributed time servers and clients. In this manner, the clock of the host is synchronized with certain time standards.? An NTP timestamp is a second relative to 00:00:00 on 1 January, 1900. The value is in the format of a 64-bit unsigned fixed-point number, with the integer part being the first 32 bits and the fraction part being the last 32 bits. Originate Timestamp (peer.xmt, pkt.xmt): A format of the timestamp, indicating the local time when the NTP message leaves the sender, such as T 1. Receive Timestamp (peer.rec, pkt.rec): A format of the timestamp, indicating the local time when the NTP message reaches the remote peer, such as T2. When the peer is unreachable, the receive timestamp is set to 0. Transmit Timestamp (peer.org, pkt.org): A format of the timestamp, indicating the local time when the remote peer returns the NTP message, such as T3. When the peer is unreachable, the transmit timestamp is set to 0. Reference Timestamp (sys.reftime, peer.reftime, pkt.reftime): A format of the timestamp, indicating the local time when the NTP message reaches the sender, such as T4. If the local clock is never synchronized, the reference timestamp is set to 0. Clock offset Round trip delay Dispersio n Clock offset is the time difference between the local clock and the reference clock. It represents the offset time to be adjusted when the local clock is synchronized with the reference clock. Round trip delay refers to the time difference between the sending and receiving of an NTP message on the client. It indicates the capability of the local clock to send a message to the reference clock within a specified time. Dispersion is the maximum error of the local clock compared with the reference clock.
Timesta mp
5-10
Issue 01 (2010-06-25)
5 NTP
Terms Stratum
Description Stratum is a hierarchical standard for clock synchronization. It represents the clock precision. The value ranges from 1 to 16. The lower the stratum is, the more precise the clock will be. Value 1 indicates that the clock is the most precise and 16 indicates that the clock is not synchronized. Clock filtering is used among is used to select the best time sample from a specified peer. Clock selection is a method of selecting reference clocks by using the clock selection algorithm.
Clock filtering Clock selection
Acronyms
Acronyms NTP VRP UDP Full Spelling Network Time Protocol Versatile Routing Platform User Datagram Protocol
Issue 01 (2010-06-25)
5-11
6 1588v2
6
About This Chapter
6.1 Introduction to 1588v2 6.2 References 6.3 Availability 6.4 Principles 6.5 Application Environment 6.6 Impact
1588v2
6.1 Introduction to 1588v2

Definition
Synchronization In a modern communications network, most telecommunications services require network clock synchronization in order to function properly. This means that the frequency offset or time difference between devices should be kept within a reasonable range. Network clock synchronization involves time synchronization and frequency synchronization.
Time synchronization Time synchronization, also called phase synchronization, means that both the frequency of and the time between signals remain constant. That is, the time offset between signals is always 0.
Frequency synchronization Frequency synchronization, also called clock synchronization, refers to a constant frequency offset or phase offset. That is, signals are transmitted at a constant average rate during any given time period so that all the devices on the network can work at the same rate.
Issue 01 (2010-06-25)
6-1
6 1588v2
Figure 6-1 Schematic diagram of time synchronization and frequency synchronization
Phase synchronization Watch A
Watch B
Frequency synchronization Watch A
Watch B
Figure 6-1 shows the differences between time synchronization and frequency synchronization. If Watch A and Watch B always keep the same time, they are in time synchronization. If Watch A and Watch B keep different time, but the time offset remains constant, for example, 6 hours, they are in frequency synchronization. IEEE 1588 IEEE 1588, defined by the Institute of Electrical and Electronics Engineers (IEEE), is a standard for Precision Clock Synchronization Protocol (PTP) for networked measurement and control systems. IEEE 1588v1, released in 2002, applies to the field of industrial automation and that of tests and measurements. With the development of IP networks and the popularization of 3G networks, the demand for time synchronization on telecommunications networks has increased. To satisfy this need, IEEE drafted IEEE 1588v2 based on IEEE 1588v1 in June 2006, revised IEEE 1588v2 in 2007, and released IEEE 1588v2 at the end of 2008. Targeted at telecommunications industry applications, IEEE 1588v2 improves on IEEE 1588v1 in the following aspects:

Encapsulation of Layer 2 and Layer 3 packets has been added. The transmission rate of Sync messages is increased. A transparent clock (TC) model has been developed. Hardware timestamp processing has been defined. Time-length-value (TLV) extension is used to enhance protocol features and functions.
6-2
Issue 01 (2010-06-25)
6 1588v2
1588v2 is a time synchronization protocol allowing for highly accurate time synchronization between devices. It is also used to implement frequency synchronization between devices.
Purpose
Data communications networks do not require time or frequency synchronization and, therefore, routers on such networks need not support time or frequency synchronization. On IP radio access networks (RANs), time or frequency needs to be synchronized among base transceiver stations (BTSs). Therefore, routers on IP RANs are required to support time or frequency synchronization. Frequency synchronization between BTSs on an IP RAN requires that frequencies between BTSs be synchronized to certain accuracy; otherwise, call dropping may occur during mobile handoff. Some wireless standards require synchronization of both frequency and time. Table 6-1 shows requirements of wireless standards for time synchronization and frequency accuracy. Table 6-1 Requirements of wireless standards for time synchronization and frequency accuracy Wireless Standards GSM WCDMA TD-SCDMA CDMA2000 WiMax FDD WiMax TDD LTE Requirement for Frequency Accuracy 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm 0.05 ppm Requirement for Time Synchronization NA NA 3us 3us NA 1us In favor of time synchronization
Different BTSs have different requirements for frequency synchronization. These requirements can be satisfied though physical clock synchronization (including external clock input, WAN clock input, and synchronous Ethernet clock input) and packet-based clock recovery (including CES ACR/DCR and 1588v2). Traditional packet-based clock recovery cannot meet the time synchronization requirement of BTSs. For example, NTP-based time synchronization is only accurate to within one second and 1588v1-based time synchronization is only accurate to within one millisecond. To meet time synchronization requirements, BTSs need to be connected directly to a global positioning system (GPS). This solution, however, has some disadvantages. GPS installation and maintenance costs are high Also, because a GPS uses satellites from different countries, communications may be vulnerable to security breaches. 1588v2, with hardware assistance, provides time synchronization accuracy to within one micro second to meet the time synchronization requirements of wireless networks. The deployment cost of 1588v2 is less than a GPS and 1588v2 operates independently of GPS, making 1588v2 strategically significant.
Issue 01 (2010-06-25)
6-3
6 1588v2
In addition, operators are paying more and more attention to the operation and maintenance of networks, requiring routers to provide network quality analysis (NQA) to support high-precision delay measurement at the 100us level. Consequently, high-precision time synchronization between measuring devices and measured devices is required. 1588v2 meets this requirement.
Benefits
This feature brings the following benefits to operators: Construction and maintenance costs for time synchronization on wireless networks are reduced. Time synchronization and frequency synchronization on wireless networks are independent of GPS, providing a higher level of strategic security. High-accuracy NQA-based unidirectional delay measurement is supported.
6.2 References
References of this document are listed as follows: IEEE 1588-2008: Precision Clock Synchronization Protocol for Networked Measurement and Control Systems ITU-T G.813: Timing requirements of SDH equipment slave clocks (SEC) ITU-T G.823: The control of jitter and wander within digital networks which are based on the 2048 kbit/s hierarchy ITU-T G.824: The control of jitter and wander within digital networks which are based on the 1544 kbit/s hierarchy ITU-T G.8261: Timing and Synchronization aspects in Packet Networks
6.3 Availability
NodeB stations: NodeB stations synchronize the time or frequency with each other. BITS: provides the external clock source. CX600: functions as a BC, an OC, a TC, or a TC+OC and runs 1588v2 to perform frequency or time synchronization between base stations on an IP RAN.
License Support
The 1588v2 feature itself is hardware-controlled instead of license-controlled. But on LPUF-10, the 8-Port 100/1000Base-X-SFP Flexible Card A (supporting 1588v2) replaces the old 8-Port 100/1000Base-X-SFP Flexible Card and, therefore, the 1588v2 feature on this card is license-controlled.
6-4
Issue 01 (2010-06-25)
6 1588v2
Version Support
Hardware Support
To support the 1588v2 feature, the CX600 needs to be configured with the following hardware: New MPUs

Main Processing Unit B2(Supporting 1588v2) Switch and Route Processing Unit A3(Supporting 1588v2) Main Processing Unit B4(Including 1*2G Memory and 1*1G CF Card) Switch and Route Processing Unit A4(Including 1*2G Memory and 1*1G CF Card) 8-Port 100/1000Base-X-SFP Flexible Card A(Supporting 1588v2) 12-Port 100/1000Base-SFP Flexible Card A(Supporting 1588v2) 1-Port 10GBase WAN/LAN-XFP Flexible Card A(Supporting 1588v2) 2-Port 10GBase LAN/WAN-XFP Flexible Card A(Supporting 1588v2) 20-Port 100/1000Base-X-SFP Flexible Card A(Supporting 1588v2)
1588v2 PICs

6.4 Principles
6.4.1 Basic Concepts 6.4.2 Principle of Synchronization
6.4.1 Basic Concepts

Clock Domain
Logically, a physical network can be divided into multiple clock domains. Each clock domain has a reference time with which all devices in the domain are synchronized. Each clock domain has its own reference time and these times are independent of each other. A device can transparently transmit time signals from multiple clock domains over a bearer network to provide specific reference times for multiple mobile operator networks. The device, however, can join only one clock domain and can synchronize only with the synchronization time of that clock domain.
Clock Node
Each node on a time synchronization network is a clock. The 1588v2 protocol defines the following types of clocks: Ordinary clock
Issue 01 (2010-06-25)
6-5
6 1588v2
An ordinary clock (OC) has only one 1588v2 clock interface (a clock interface enabled with 1588v2) through which the OC synchronizes with an upstream node or distributes time signals to downstream nodes. Boundary clock A boundary clock (BC) has multiple 1588v2 clock interfaces: one of these is used to synchronize with an upstream node and the others are used to distribute time signals to downstream nodes. This is an example of a special case: If a router obtains the standard time from a BITS through an external time interface (which is not enabled with 1588v2) and then distributes time signals through two 1588v2 enabled clock interfaces to downstream nodes, this router is a BC node, as it has more than one 1588v2 clock interface. Transparent clock Unlike BCs and OCs which maintain time synchronization with other devices, a transparent clock (TC) does not synchronize the time with other devices. A TC has multiple 1588v2 clock interfaces through which it transmits 1588v2 messages and corrects message transmission delays. The TC does not synchronize the time with any interface. TCs are classified into end-to-end (E2E) TCs and peer-to-peer (P2P) TCs. TC+OC A TC+OC is a special TC, which has functions of both the TC and OC. On interfaces having TC attributes, the TC+OC can transparently transmit 1588v2 messages and correct message transmission delays. On interfaces having OC attributes, the TC+OC performs frequency synchronization, but does not implement time synchronization. As mentioned before, the TC corrects for 1588v2 message transmission its delays. If the times on the inbound and outbound interfaces of the TC are synchronous, the message transmission delay is determined by subtracting the time of the 1588v2 message's arrival at the inbound interface from the time of departure at the outbound interface. If the clocks of the TC and the BC or OC with which the TC synchronizes are asynchronous, the obtained message transmission delay is inaccurate, causing a time offset in the BC or OC time synchronization. As a result, the time synchronization's accuracy may be degraded. Usually, it is recommended that frequency synchronization between the TC and the BC or OC be implemented through a physical clock, such as a WAN clock or synchronous Ethernet clock. If no such physical clock is available, the TC needs to use 1588v2 Sync messages sent periodically to restore frequency and to realize time synchronization with the upstream device. TC+OCs are classified into E2E TC+OCs and P2P TC+OCs. Figure 6-2 shows the location of TC, OC, and TC+OC on a time synchronization network.
6-6
Issue 01 (2010-06-25)
6 1588v2
Figure 6-2 Location of TC, OC, and TC+OC on a time synchronization network
BC1 Grandmaster clock TC1 TC2
OC1
OC2
BC2 Cyclic path
BC3
TC3
TC4
OC3
OC4
OC5
OC6
Time Source Selection

On a 1588v2 time synchronization network, all clocks are organized into a master-slave synchronization hierarchy with the Grandmaster (GM) clock at the top of the hierarchy. This topology can be statically configured or automatically generated by 1588v2 using the Best Master Clock (BMC) algorithm. 1588v2 Announce messages are used to exchange time source information, including information about the priority level of the GM, time strata, time accuracy, distance, and hops to the GM between clocks. After this information has been gathered, one of the clock nodes is selected to be GM, the interface to be used for transmitting clock signals issued by the GM is selected, and master and slave relationships between nodes are specified. The result of the source information gathering process is the construction of a GM-rooted spanning tree of loop-free and full-mesh. If a master-slave relationship has been set up between two nodes, the master node periodically sends Announce messages to the slave node. If the slave node does not receive an Announce message from the master node within a specified time period, it terminates the current master-slave relationship and finds another interface with which to establish a new master-slave relationship.
Supported Link Types

Theoretically, 1588v2 supports all types of links, but at this time, 1588v2 has in fact only been defined for encapsulation and implementation on Ethernet links and, thus,CX600 supports only Ethernet links.
Issue 01 (2010-06-25)
6-7
6 1588v2
Grandmaster
A time synchronization network is like a GM-rooted spanning tree. All other nodes synchronize with the GM.
Master/Slave
When a pair of nodes perform time synchronization, the upstream node distributing the reference time signals is the master node and the downstream node receiving the reference time signals is the slave node.
6.4.2 Principle of Synchronization

Principles of 1588v2 time synchronization and NTP are the same, in which the master and slave nodes exchange timing messages, and calculate the message transmission delays in two directions (sending and receiving) according to the receiving and sending timestamps in the exchanged timing messages. If the message transmission delays in two directions are identical, the message transmission delay in one direction (the time offset between the slave and master nodes) equals the delays in two directions divided by 2. Then, the slave node synchronizes with the master node by correcting its local time according to the time offset. In practice, the delay and jitter on the network need be considered, and the receiving and sending delays are not always identical. Therefore, message-based time synchronization, namely, 1588v2 and NTP, cannot guarantee the high synchronization accuracy. For example, NTP can only provide the synchronization accuracy of 10 to 100 ms. 1588v2 and NTP differ in implementation. NTP runs at the application layer, for example, on the MPU of the CX600. The delay measured by NTP, in addition to the link delay, includes various internal processing delays, such as the internal congestion queuing, software scheduling, and software processing delays. These make the message transmission delay unstable, causing message transmission delays in two directions to be asymmetric. As a result, the accuracy of NTP-based time synchronization is low. 1588v2 presumes that the link delay is constant or changes so slowly that the change between two synchronization processes can be ignored, and the message transmission delays in two directions on a link are identical. Messages are time-stamped for delay measurement at the physical layer of the LPU. This ensures that time synchronization based on the obtained link delay is extremely accurate. 1588v2 defines two modes for the delay measurement and time synchronization mechanisms, namely, Delay and Peer Delay (PDelay).
Delay Mode
The delay mode is applied to end-to-end (E2E) delay measurement. Figure 6-3 shows the delay measurement in Delay mode.
6-8
Issue 01 (2010-06-25)
6 1588v2
Figure 6-3 E2E delay measurement in Delay mode
Master time
Slave time
Timestamps known by slave
t1 t-ms Syn t2 Follow_Up t2 t1, t2
t-sm t4
Delay_Req
t3
t1, t2, t3
Delay_Resp t1, t2, t3, t4
As shown in Figure 6-3, t-sm and t-ms respectively represent the sending and receiving delays, which are presumed to be identical. If they are different, they should be made identical through asymmetric delay correction. For details about asymmetric delay correction, see the following part of this section. Follow_Up messages are used in two-step mode. Only the one-step mode is described in this part and Follow_UP messages are not mentioned. For details about the two-step mode, see the following part of this section.
A master node periodically sends the Sync message carrying the sending timestamp t1 to the slave node. When the slave node receives the Sync message, it time-stamps t2 to the message. The slave node periodically sends the Delay_Req message carrying the sending timestamp t3 to the master node. When the master node receives the Delay_Req message, it time-stamps t4 to the message and returns a Delay_Resp message to the slave node. The slave node receives a set of timestamps, including t1, t2, t3, and t4. Other elements affecting the link delay are ignored. The message transmission delays of the link between the master and slave nodes in two directions are equal to (t4 - t1) - (t3 - t2). If the message transmission delays between both nodes are identical, the message transmission delay in one direction is equal to [(t4 - t1) - (t3 t2)]/2. The time offset between the master and slave nodes is equal to [(t4-t1)-(t3-t2)]/2. Based on the time offset, the slave node synchronizes with the master node. As shown in Figure 6-4, time synchronization is performed repeatedly to ensure that the slave node always synchronizes with the master node.
Issue 01 (2010-06-25)
6-9
6 1588v2
Figure 6-4 Networking diagram of the directly-connected BC and OC BC Master OC Slave
t1
Sync t2 DelayReq t3
t4 DelayResp
The BC and OC can be directly connected as shown in Figure 6-4. Alternatively, they can be connected through other devices, which must be TCs to ensure the accuracy of time synchronization. The TC only transparently transmits 1588v2 messages and corrects the message transmission delay (which requires that the TC identify these 1588v2 messages). To ensure the high accuracy of 1588v2 time synchronization, it is required that the message transmission delays in two directions between master and slave nodes be stable. Usually, the link delay is stable but the transmission delay on devices is unstable. Therefore, if two nodes performing time synchronization are connected through forwarding devices, the time synchronization accuracy cannot be guaranteed. The solution to the problem is to perform the transmission delay correction on these forwarding devices, which requires that the forwarding devices be TCs. Figure 6-5 shows how the transmission delay correction is performed on a TC.
6-10
Issue 01 (2010-06-25)
6 1588v2
Figure 6-5 Schematic diagram of the transmission delay correction on a TC

Message at ingress Event message payload Network protocol Preamble correctionField headers Message at egress Network PTP message payload protocol Preamble correctionField headers
+
Ingress timestamp
+ +
Engress timestamp
Ingress Residence time bridge
Egress
The TC performs the transmission delay correction by adding the time it takes to transmit the message to the Correction field of a 1588v2 message. To be specific, the TC deducts the receiving timestamp of the 1588v2 message on its inbound interface and adds the sending timestamp to the 1588v2 message on its outbound interface. In this manner, the 1588v2 message exchanged between the master and slave nodes, when passing multiple TCs, carry message transmission delays of all TCs in the Correction field. When the value of the Correction field is deducted, the obtained value is the link delay. This ensures high accuracy time synchronization. A TC that records the transmission delay from end to end as described above is the E2E TC. Time synchronization in Delay mode can be applied only to E2E TCs. Figure 6-6 shows how the BC, OC, and E2E TC are connected and how 1588v2 operates.
Issue 01 (2010-06-25)
6-11
6 1588v2
Figure 6-6 Networking diagram of the BC, OC, and E2E TC and the 1588v2 operation
BC Master
E2E TC
OC Slave
t1
Sync correction t2 t3 correction
t4 DelayResp
PDelay Mode
When performing time synchronization in PDelay mode, the slave node deducts both the message transmission delay and upstream link delay. This requires that adjacent devices perform the delay measurement in PDelay mode to enable each device on the link to know its upstream link delay. Figure 6-7 shows the delay measurement in PDelay mode.
6-12
Issue 01 (2010-06-25)
6 1588v2
Figure 6-7 Schematic diagram of the delay measurement in PDelay mode

Node 1 time Node 2 time
t1 Pdelay_Req t-ms t2
t3 Pdelay_Resp t-sm t4
Pdelay_Resp_Follow_Up
As shown in Figure 6-3, t-sm and t-ms respectively represent the sending and receiving delays, which are presumed to be identical. If they are different, they should be made identical through asymmetric delay correction. For details of asymmetric delay correction, see the following part of this section. Follow_Up messages are used in two-step mode. In this part, the one-step mode is described and Follow_UP messages are not mentioned. For details of the two-step mode, see the following part of this section.
Node 1 periodically sends the PDelay_Req message carrying the sending timestamp t1 to node 2. When the PDelay_Req message is received, node 2 time-stamps t2 to the PDelay_Req message. Then, node 2 sends a PDelay_Resp message carrying the sending timestamp t3 to node 1. When the PDelay_Resp message is received, node 1 time-stamps t4 to the PDelay_Resp message. Node 1 obtains a set of timestamps, including t1, t2, t3, and t4. Other elements affecting the link delay are ignored. The message transmission delays in two directions on the link between node 1 and node 2 are equal to (t4 - t1) - (t3 - t2). If the message transmission delays in two directions on the link between node 1 to node 2 are identical, the message transmission delay in one direction is equal to [(t4 - t1) - (t3 - t2)]/2. The delay measurement in PDelay mode does not distinguish the master and slave nodes. All nodes send PDelay messages to their adjacent nodes to calculate adjacent link delay. This calculation process repeats and the message transmission delay in one direction is updated accordingly.
Issue 01 (2010-06-25)
6-13
6 1588v2
The delay measurement in PDelay mode does not trigger time synchronization. To implement time synchronization, the master node needs to periodically send Sync messages to the slave node and the slave node receives the t1 and t2 timestamps. The slave node then deducts the message transmission delay on the link from the master node to the slave node. The obtained t2-t1-CorrectionField is the time offset between the slave and master nodes. According to the time offset, the slave node synchronizes with the master node. Figure 6-8 shows how time synchronization is implemented in PDelay mode in the scenario where the BC and OC are directly connected. Figure 6-8 Networking diagram of time synchronization in PDelay mode on the directly-connected BC and OC
BC Master
OC Slave
t1
PDelay Req
t2
PDelay Resp
t3 t1
t4 t2 t3 t1
PDelay Req
PDelay Resp
t4
Sync
t2
The BC and OC can be directly connected as shown in Figure 6-4. Alternatively, the BC and OC are connected through other device serving as TCs to ensure the accuracy of time synchronization. The TC only transparently transmits 1588v2 messages and corrects the message transmission delay (which requires that the TC identify these 1588v2 messages). Unlike delay correction on the E2E TC, delay correction on the P2P TC involves the correction of both transmission delay and upstream link delay. Figure 6-9 shows how transmission delay correction is performed on a P2P-TC.
6-14
Issue 01 (2010-06-25)
6 1588v2
Figure 6-9 Transmission delay correction in PDelay mode

Sync message at ingress Event message payload Network protocol Preamble correctionField headers Sync or Follow_up message at egress PTP message payload correctionField Network protocol Preamble headers
+ +
Engress timestamp
Ingress timestamp
Link delay on ingress port Ingress Residence time bridge Egress
Figure 6-10 shows how the BC, OC, and E2E TC are connected and how 1588v2 operates. Figure 6-10 Schematic diagram of transmission delay correction in PDelay mode on a P2P-TC
BC Master
P2P TC
OC Slave
t1
PDelayReq PDelayResp
t2 t3 t1 t4
PDelayReq
t4
PDelayResp
t2 t3
t1 t4
PDelayReq PDelayResp
t2 t3 t1 t4
PDelayReq
t2
PDelayReq
t3
t1
correction
Sync
t2
Issue 01 (2010-06-25)
6-15
6 1588v2
one-step/two-step
In one-step mode, both the Sync messages for time synchronization in Delay mode and PDelay_Resp messages for time synchronization in PDelay mode are stamped with a sending time. In two-step mode, Sync messages for time synchronization in Delay mode and PDelay_Resp messages for time synchronization in PDelay mode are not stamped with a sending time. The sending time is carried in Follow_Up and PDelay_Resp_Follow_Up messages. The CX600 adopts the one-step mode. To communicate with other devices, the CX600 is also able to identify incoming messages that are time-stamped in two-step mode.
Asymmetric Correction
Theoretically, 1588v2 requires the message transmission delays in two directions on a link to be symmetrical. Otherwise, the algorithms of 1588v2 time synchronization cannot be implemented. In practice, however, the message transmission delays in two directions on a link may be asymmetric. This may be caused by the attributes of a link or a device. For example, the delays between receiving the message, and time-stamping the message in two directions are different. To solve this problem, 1588v2 provides a mechanism of asymmetric delay correction, as shown in Figure 6-11. Figure 6-11 Asymmetric delay correction
Master clock or Responder
tms
tsm
Slave clock or Resuestor
Usually, t-ms is identical with t-sm. If they are different, the user can set a delay offset between t-ms and t-sm as long as the delay offset is constant and obtainable. 1588v2 performs the time synchronization calculation according to the asymmetric correction value. In this manner, the high time synchronization accuracy can be achieved on an asymmetric-delay link.
Packet Encapsulation
1588v2 defines the following multiple packet encapsulation modes: Layer 2 multicast encapsulation through a multicast MAC address The EtherType field is 0x88F7, and the multicast MAC address is 01-80-C2-00-00-0E (in PDelay messages) or 01-1B-19-00-00-00 (in non-PDelay messages).
6-16
Issue 01 (2010-06-25)
6 1588v2
The Layer 2 multicast encapsulation mode is recommended by 1588v2. The CX600 supports the Layer 2 multicast encapsulation with VLAN tags. Figure 6-12 shows the Layer 2 multicast encapsulation without VLAN tags. Figure 6-12 Layer 2 multicast encapsulation without VLAN tags
DA 6 Byte
SA 6 Byte
0x88f7 2 Byte
1588 packet
Figure 6-13 shows the Layer 2 multicast encapsulation with VLAN tags. Figure 6-13 Layer 2 multicast encapsulation with VLAN tags
Vlan--12bit 0x8100 prority--3bit 0x88f7
DA 6 Byte
SA 6 Byte
1588 packet
2 Byte
2 Byte
2 Byte
Layer 3 unicast encapsulation through unicast UDP The destination UDP port number is 319 or 320, depending on the types of 1588v2 messages. Currently, it is recommended that Huawei base stations adopt the Layer 3 unicast encapsulation. The IP clock server consists of multiple BTSs and uses unicast UDP packets to exchange 1588v2 protocol packets. Figure 6-14 shows the Layer 3 unicast encapsulation without VLAN tags. Figure 6-14 Layer 3 unicast encapsulation without VLAN tags
DA 6Byte
SA 6Byte
0x800 IP(header) UDP(header) 2Byte 20Byte 8Byte
1588 packet
Figure 6-15 shows the Layer 3 unicast encapsulation with VLAN tags. Figure 6-15 Layer 3 unicast encapsulation with VLAN tags
Vlan--12bit prority--3bit
DA 6Byte
SA 6Byte
0x8100 2Byte
IP(header) UDP(header) 1588 packet 20Byte 8Byte
2Byte
Issue 01 (2010-06-25)
6-17
6 1588v2
Layer 3 multicast encapsulation through multicast UDP Layer 3 unicast encapsulation through a unicast MAC address IPv6 encapsulation The CX600 supports Layer 2 multicast encapsulation, Layer 2 unicast encapsulation, Layer 3 multicast encapsulation, and Layer 3 unicast encapsulation, but does not currently support IPv6 encapsulation.
Unicast Negotiation Mode

According to 1588v2, in unicast negotiation mode, the client should send a service request to the server. After accepting the request, the server sends a 1588v2 message to the client at the required frequency for time synchronization. If the services requested by the client expire, the server stops the services. The client, therefore, needs to continue the lease terms with the server before they expire.
BITS Interface
1588v2 enables clock nodes to synchronize with each other, but cannot enable them to synchronize with Greenwich Mean Time (GMT). If the clock nodes need to synchronize with GMT, an external time source is required. That is, the GM needs to be connected to an external time source to obtain reference time in non-1588v2 mode and distributes the time signals to other clock nodes. Currently, the external time sources are from satellites, such as the GPS of the U.S.A, Galileo of Europe, GLONASS of Russia, and Beidou of China. Figure 6-16 shows how the GM and an external time source are connected. Figure 6-16 Synchronization with an external time source
Grandmaster 1588v2 External time port CX device
CX device
BITS
The CX600 provides two types of external clock or time interfaces: SMB port (using a 75 Ohm unshielded coaxial cable) A pair of coaxial ports provides one type of the following clock or time signals:
2 MHz clock signal (Transistor-Transistor Logic (TTL) level with one line clock input and one line clock output) 2 Mbit/s clock signal (TTL level with one line clock input and one line clock output) 1 pps + time-of-day (TOD) time signal (TTL and RS232 level with one line time input) 1 pps + TOD time signal (TTL and RS232 level with one line time output)
RJ45 port (using a 120 Ohm shielded cable)
6-18
Issue 01 (2010-06-25)
6 1588v2
The two RJ45 ports function as an external clock port and an external time port respectively, providing the following clock or time signals:
2 MHz clock signal (Differential level with one line clock input and one line clock output) 2 Mbit/s clock signal (Differential level with one line clock input and one line clock output) DC level shifter (DCLS) time signal (RS422 differential level with one line clock input + one line clock output) 1 pps + TOD time signal (RS422 differential level with one line time input) 1 pps + TOD time signal (RS422 differential level with one line time output)
Clock Synchronization
In addition to time synchronization, 1588v2 can be used in clock synchronization, that is, frequency recovery can be performed through 1588v2 messages. 1588v2 time synchronization in Delay or PDelay mode requires the device to periodically send Sync messages to its peer. The sent Sync message carries a sending timestamp. After receiving the Sync message, the peer adds a receiving timestamp to it. When the link delay is stable, the two timestamps change at the same pace. If the receiving timestamp changes are faster or slower, it indicates that the clock of the receiving device runs faster or slower than the clock of the sending device. In this case, the clock of the receiving device needs to be adjusted. In this manner, frequencies of the two devices are synchronized. The frequency restored through 1588v2 messages has a lower accuracy than the frequency restored through synchronous Ethernet. Therefore, it is recommended to perform frequency synchronization through synchronous Ethernet and time synchronization through 1588v2. 1588v2 restores the frequency in the following modes: Hop-by-hop In hop-by-hop mode, all devices on a link are required to support 1588v2. The frequency recovery in this mode is of highly accurate. In the case of a small number of hops, the frequency recovery accuracy can meet the requirement of International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) G.813 (that is, the stratum 3 standard). End-to-end (A delay and jitter may occur on the transit network.) In E2E mode, the forwarding devices do not need to support 1588v2, and the delay of the forwarding path is only required to meet a certain standard, for example, less than 20 ms. The frequency recovery accuracy in this mode is low, and can meet only the requirement of the G.8261 and base stations (50 pps) rather than the that of the stratum 3 clock standard. To achieve high frequency recovery accuracy, 1588v2 requires Sync messages to be sent at a high rate, namely, 100 packets/s and above. The CX600 meets the following clock standards: G.813 and G.823 for external clock synchronization G.813 for SDH clocks (such as POS, ATM, and c-STM-1) G.813 and G.823/G.824 for E1 and T1 clocks G.8261 and G.8262 for synchronous Ethernet clocks
Issue 01 (2010-06-25)
6-19
6 1588v2
G.8261 and G.823/G.824 for frequency recovery through 1588v2 messages At present, the CX600 supports frequency recovery through 1588v2 messages in hop-by-hop mode, rather than in end-to-end or inter-packet delay variation (PDV) network mode. The CX600 is not promised to be G.813 and G.8262 compliant.
6.5 Application Environment

1588v2 Clock Synchronization in E2E Mode
Figure 6-17 Networking diagram of 1588v2 clock synchronization in E2E mode
clock server
1588 FE Node B with 1588 GE GE GE
1588 FE Node B with 1588
As shown in Figure 6-17, clock servers and NodeBs exchange TOP-encapsulated 1588 messages over a QoS-enabled bearer network with the jitter being less than 20 ms. Scenario description: NodeBs only need frequency synchronization. The bearer network does not support 1588v2 or frequency recovery in synchronous Ethernet mode. Solution description: The bearer network is connected to a wireless IP clock server and adopts 1588v2 clock synchronization and frequency recovery in E2E mode. The clock server sends 1588v2 timing messages, which are transparently transmitted over the bearer network to NodeBs. Upon receiving the timing messages, NodeBs perform frequency recovery. 1588v2 timing messages need be transparently transmitted by priority over the bearer network; the E2E jitter on the bearer network must less than 20 ms. Advantage of the solution: Devices on the bearer network are not required to support 1588v2, and are therefore easily deployed. Disadvantage of the solution: Only frequency synchronization, rather than time synchronization, is performed. In practice, it cannot ensure that the E2E jitter is less than 20 ms.
6-20
Issue 01 (2010-06-25)
6 1588v2
1588v2 Clock Synchronization in Hop-by-Hop Mode

Figure 6-18 Networking diagram of 1588v2 clock synchronization in hop-by-hop mode
BITS clock source/WAN link
Synchronous Ethernet GE
WAN clock
1588 GE
1588 FE Node B
Physical clock signal transfer
1588 clock without 1588 signal transfer
As shown in Figure 6-18, the clock source can send clock signals to NodeBs through the 1588v2 clock, WAN clock, synchronous Ethernet clock, or any clock combination. Scenario description: NodeBs only need frequency synchronization. GE links on the bearer network support the 1588v2 clock rather than the synchronous Ethernet clock. Solution description: The Synchronous Digital Hierarchy (SDH) or synchronous Ethernet clock sends stratum 3 clock signals through physical links. On the GE links that do not support the synchronous Ethernet clock, stratum 3 clock signals are transmitted through 1588v2. Advantage of the solution: The solution is simple and flexible. Disadvantage of the solution: Only frequency synchronization rather than time synchronization is performed.
Issue 01 (2010-06-25)
6-21
6 1588v2
Bearer and Wireless Networks in the Same Clock Domain

Figure 6-19 Networking diagram of the bearer and wireless networks in the same clock domain
GPS+BITS GPS+BITS Node B without 1588 1588 FE Node B with 1588 GE BC BC
Physical clock signal transfer
1588 GE BC BC
E1 1588 FE Node B with 1588
1588 clock signal transfer
Scenario description: NodeBs need to synchronize time with each other. The bearer and wireless networks are in the same clock domain. Solution description: The core node supports GPS or BITS clock interfaces. All nodes on the bearer network function as BC nodes, which support the link delay measurement mechanism to cope with fast link switching. Links or devices that do not support 1588v2 can be connected to devices with GPS or BITS clock interfaces to perform time synchronization. Advantage of the solution: The time of all nodes is synchronous on the entire network. Disadvantage of the solution: All nodes on the entire network must support 1588v2.
Bearer and Wireless Networks in Different Clock Domains

Figure 6-20 Networking diagram of the bearer and wireless networks in different clock domains
clock server
1588 FE Node B with TC+BC 1588
1588 GE BC
1588
1588 GE BC TC+BC
6-22
Issue 01 (2010-06-25)
6 1588v2
Scenario description: NodeBs need to synchronize time with each other. The bearer and the wireless networks are in different time domains. Solution description: The GPS, as a time source, is connected to the wireless IP clock server. BCs are deployed in the middle of the bearer network to synchronize the time of intermediate network. TCs are deployed on both ends of the bearer network. TCs only correct the message transmission delay and send the time to NodeBs, but do not synchronize the time with the clock server. Advantage of the solution: The implementation is simple because the bearer network does not need to synchronize with the clock server. Disadvantage of the solution: Devices on both ends of the bearer networks need to support 1588v2 in TCandBC mode.
6.6 Impact
6.6.1 On the System Performance 6.6.2 On Other Features

Running 1588v2 occupies the link bandwidth. Take the hop-by-hop clock or time synchronization and frequency recovery through 1588v2 messages as an example. 1588v2 sends 128 Sync messages every second and one packet of other types every second, totally using the bandwidth of 100 Kbit/s.

None.
Issue 01 (2010-06-25)
6-23
6 1588v2

Terms
Terms Synchron ization Description In a modern communications network, the proper functioning of most telecommunications services requires network clock synchronization. This means that the frequency offset or time difference between devices should be kept in a reasonable range. Network clock synchronization involves time synchronization and frequency synchronization. Time synchronization Time synchronization, also called phase synchronization, refers to the consistency of both frequencies and phases between signals. That is, the phase offset between signals is always 0. Frequency synchronization Frequency synchronization, also called clock synchronization, refers to a constant frequency offset or phase offset. That is, signals are transmitted at the same average rate during the valid time so that all the devices on the network can work at the same rate. IEEE 1588v2 PTP Clock domain IEEE 1588, defined by the Institute of Electrical and Electronics Engineers (IEEE), is a standard for Precision Clock Synchronization Protocol for Networked Measurement And Control Systems (PTP). Logically, a physical network can be divided into multiple clock domains. Each clock domain has a reference time, with which all devices in the domain are synchronized. Different clock domains have their own reference time, which is independent of each other. Each node on a time synchronization network is a clock. The 1588v2 protocol defines the three types of clocks: OC, BC, and TC. Clock source selection is a method to select reference clocks based on the clock selection algorithm. In one-step mode, Sync messages in Delay mode and PDelay_Resp messages in PDelay mode are stamped with the time when messages are sent. In two-step mode, Sync messages in Delay mode and PDelay_Resp messages in PDelay mode only record the time when messages are sent and carry no timestamps. The timestamps are carried in the messages, such as Follow_Up and PDelay_Resp_Follow_Up messages.
Clock node Clock reference source One-step mode Two-step mode
Abbreviations
Abbreviati on 1588v2 Full Spelling Precision Time Protocol
6-24
Issue 01 (2010-06-25)
6 1588v2
Abbreviati on IP RAN GSM WCDMA TD-SCDMA WiMax FDD WiMax TDD NTP GPS LTE BC OC TC BMC BITS
Full Spelling Internet Protocol Radio Access Network Global System for Mobile communications Wideband Code Division Multiple Access Time Division-Synchronous Code Division Multiple Access Worldwide Interoperability for Microwave Access Frequency Division Duplex Worldwide Interoperability for Microwave Access Time Division Duplex Network Time Protocol Global Position System Long Term Evolution Boundary Clock Ordinary Clock Transparent Clock Best Master Clock Building Integrated Time Supply System
Issue 01 (2010-06-25)
6-25
7 NQA
7
About This Chapter
7.1 Introduction to NQA 7.2 References 7.3 Availability 7.4 Principles 7.5 Impact 7.6 Terms and Abbreviations
NQA
7.1 Introduction to NQA

Definition
Network Quality Analysis (NQA) is a feature provided by the device. Independent of lower-layer hardware, NQA functions above the link layer to measure the performance of protocols running at the network layer, transport layer, and application layer.
Purpose
The device provides NQA to help carriers to monitor network QoS in real time and locate the faults occurring on the network. To visualize the qualities of network services and allow users themselves to check whether the qualities of network services meet requirements, carriers must take the following measures: Provide statistics about the device to illuminate the qualities of network services. Owing to the statistical multiplexing and traffic burst of IP networks, NQA can only be described by statistics. Therefore, carriers need to provide relevant statistical parameters such as delay, jitter, and packet loss ratio at the equipment side. Monitor the qualities of network services by deploying probe devices. As the scale of networks continuously increases, if dedicated probe devices are used, for example, the third party probe device Brix, more and more probe devices are needed. This will increase carriers' expenditure.
Issue 01 (2010-06-25)
7-1
7 NQA
The device provides NQA to meet the preceding requirements. Through the network quality test function integrated in a device, NQA can accurately test the operating status of the network and collect statistics. In addition, since dedicate probe devices are not required, NQA provided by the device also reduces the carriers' cost. NQA measures the performance of different protocols running on the network. In that case, carriers can collect operation indexes of networks in real time, such as total delay of the HTTP operation, delay in setting up a TCP connection, delay in DNS resolution, file transmission rate, delay in setting up an FTP connection, and DNS resolution error ratio. The Ping operation is a traditional method to monitor the network quality. Compared with information collected through NQA, the information collected through the Ping operation is limited. The following shows the differences between NQA and Ping in the aspect of functions and configurations. Table 7-1 Comparisons between NQA and Ping NQA Function NQA not only supports Internet Control Message Protocol (ICMP) tests but also service availability tests (such as TCP, UDP, DHCP, FTP, HTTP, SNMP, DNS, Traceroute, and LSP Ping/Traceroute services). Moreover, NQA can be used to test the response time of each service and the jitter time on the network through Jitter tests. By default, NQA supports a maximum of 2000 test instances. You can use a specified license file to extend the number of supported test instances. Configura tion For NQA, you can run commands on the client to view NQA test results. Note the following: In NQA, parameters of operations can be set and tests can be started through the Network Management System (NMS). You can obtain statistics by viewing the output test results and history tables. In most test instances, you only need configure NQA clients. Configuring NQA servers is necessary for TCP, UDP, and Jitter test instances. An NQA server responds to the test request from a client through the monitoring function. After being configured with the corresponding destination IP address and port number, the NQA server can respond to the test request. The IP address and port number specified in the monitoring service on the server must be consistent with those configured on the client. Ping Ping is based on ICMP and is used to test only the round-trip time (RTT) of a datagram between the source and the destination and test the reachability of the destination. A user can initiate only one Ping operation at a time. For Ping, you need to run the ping command on the Console to test the reachability of a specified IP address. The RTT or timeout period of every packet can be displayed in real time.
7-2
Issue 01 (2010-06-25)
7 NQA
NQA Schedulin g mode NQA supports test instance scheduling, which avoids concurrent test operating and hence reduces the burden on a device. NQA supports the configuration of different start time and end time for a single test instance. NQA supports three modes of starting tests: immediate, delayed, and periodical. NQA supports five modes of ending tests: automatic, immediate, delayed, timely, and ending tests when the life cycle of the test expires. When several tasks are performed at the same time, a device reasonably arranges start time and test intervals.
Ping Ping only supports command line delivery.
7.2 References
The following table lists the references of this document. Document RFC 1889 RFC 2925 RFC 2131 RFC 1035 RFC 414 RFC 1945 RFC 2616 RFC 792 RFC 4379 IEEE 802.1AG DRAFT6.1 RFC 792 Description RTP: A Transport Protocol for Real-Time Applications Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Dynamic Host Configuration Protocol DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION FILE TRANSFER PROTOCOL (FTP) STATUS AND FURTHER COMMENTS Hyptertext Transfer Protocol - HTTP/1.0 Hypertext Transfer Protocol - HTTP/1.1 INTERNET CONTROL MESSAGE PROTOCOL Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures IEEE 802.1AG DRAFT6.1 INTERNET CONTROL MESSAGE PROTOCOL Remarks
Issue 01 (2010-06-25)
7-3
7 NQA
Document DRAFT-FENNE R-TRACEROU TE-IPM-07 RFC 1157 RFC 1905 RFC 3414 RFC 793 RFC 862 RFC 1393
Description DRAFT-FENNER-TRACEROUTE-IPM-07
Remarks
A Simple Network Management Protocol (SNMP) Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) Transmission Control Protocol Echo Protocol Traceroute Using an IP Option TCP/UDP test TCP/UDP test Traceroute test
7.3 Availability
License Support
The NQA function is not license controlled.
Version Support
7.4 Principles
In NQA, two test ends are called an NQA client and an NQA server. An NQA test is initiated by the NQA client. Users can configure test instances through command lines or the NMS. Then, NQA places different types of test instances into various test queues for scheduling. When starting an NQA test instance, you can choose to start the test instance immediately or in a timing manner, or delay starting the test. A test packet is generated according to the test type when the timer expires. If the size of the generated test packet is not in accordance with the minimum size of the protocol packet, the test packet must be generated and sent out with the size being the defined minimum size of the protocol packet. After the test instance starts, a response packet is returned. Carriers can then know the operation status about the protocol by analyzing the received response packet. The test packet
7-4
Issue 01 (2010-06-25)
7 NQA
is marked with a timestamp based on the local system time before being sent to the destination. After receiving the test packet, the destination sends a response packet to the source. The source then marks the received response packet with a timestamp based on the current local system time. This helps the source to calculate the RTT of the packet according to the time of sending and receiving the packet.
For a Jitter test instance, not only the source needs to mark the packet with a timestamp but also the destination needs to mark the packet with a timestamp based on the local system time after receiving the packet and returning a response packet. In this way, the source can calculate the jitter time of the packet.
Carriers can know the network operation status by viewing test results. 7.4.1 UDP Jitter Test 7.4.2 UDP Jitter (hardware-based) 7.4.3 7.4.4 ICMP Jitter ICMP Jitter (hardware-based)
7.4.5 Path Jitter 7.4.6 HTTP Test 7.4.7 DNS Test 7.4.8 FTP Test
7.4.9 DHCP Test 7.4.10 SNMP Test 7.4.11 TCP Test 7.4.12 UDP Test 7.4.13 MPing Test 7.4.14 MTrace Test 7.4.15 ICMP Test 7.4.16 Trace Test 7.4.17 LSP Ping Test 7.4.18 LSP Trace Test 7.4.19 LSP Jitter 7.4.20 PWE3 Ping Test 7.4.21 PWE3 Trace Test 7.4.22 MAC Ping Test 7.4.23 MAC TUNNEL PING 7.4.24 Path MTU 7.4.25 CE-Ping 7.4.26 VPLS MPING
Issue 01 (2010-06-25)
7-5
7 NQA
7.4.27 VPLS PING 7.4.28 VPLS Trace
7.4.1 UDP Jitter Test

UDP Jitter is borne by UDP packets. It is a test method used to obtain the packet delay, jitter, and packet loss ratio by marking packets with timestamps. Jitter refers to the interval for receiving two consecutive packets minus the interval for sending the two packets. Figure 7-1 shows the process of a UDP Jitter test. 1. 2. 3. The client (CX- A) sends packets to the server (CX- B) at a certain interval. After receiving the packets, CX- B adds a timestamp to each packet and sends it back to CX- A. After receiving the returned packets, CX- A calculates the packet jitter by subtracting the interval for sending the packets from the interval for receiving the packets.
In a UDP jitter test, the maximum number of packets to be sent each time is configurable, which is equal to the product of probe-count and jitter-packetnum.
The following can be calculated based on the information in the packets received by the client:
Maximum, minimum, and average jitter of the packets from the client to the server and from the server to the client Maximum unidirectional delay from the server to the client or from the client to the server
The obtained jitter can clearly reflect network status. In a UDP Jitter test, you can set the number of packets to be sent consecutively in each test instance. Through this setting, the actual traffic of a kind of packets can be simulated. For example, set the client to send 3000 UDP packets at an interval of 20 ms. Then, G.711 traffic can be simulated within one minute. Figure 7-1 Application scenario of the UDP Jitter test
IP Network CX-A CX-B
7.4.2 UDP Jitter (hardware-based)

UDP Jitter (hardware-based) is a supplement to the UDP Jitter, which use the hardware forwarding engine to transmit packets and add timestamps to packets. The hardware forwarding engine can: Reduce the interval for sending packets. The minimum interval for sending packets can be 10 ms.
7-6
Issue 01 (2010-06-25)
7 NQA
Increase the number of concurrent test instances. Each time an LPU is installed, 100 concurrent test instances is increased on the device. Enhance the accuracy on the calculation of the delay and jitter time. This can reflect the network status in a more accurate way and improve the efficiency of the device. Table 7-2 Differences between UDP Jitter and UDP Jitter (hardware-based) UDP Jitter Interval for sending packets Number of concurrent test instances The minimum value is 20 ms. A device can have a maximum of 100 concurrent test instances. UDP Jitter (hardware-based) The minimum value is 10 ms. Each time an LPU is installed, 100 more concurrent test instances can be implemented on the device. The device can implement a maximum of 1000 concurrent test instances. The LPU timestamps packets, which is more precise.
Jitter calculation
The MPU timestamps packets.
Figure 7-2 Application scenario of UDP jitter (hardware-based)

CX-A CX-B
NQA agent
NQA server
7.4.3 ICMP Jitter

ICMP Jitter is a test method based on UDP packets and used to obtain the statistics on the packet delay, Jitter, and packet loss by marking packets with timestamps. Jitter refers to the interval for receiving two consecutive packets minus the interval for sending the two packets. Figure 7-3 shows the process of an ICMP jitter test. 1. 2. 3. The client (CX- A) sends packets to the server (CX- B) at a specified interval. The server adds a timestamp to each received packet and sends the packet back to the client. After receiving the returned packet, the client calculates the packet jitter by subtracting the interval for the server to receive the packets from the interval for the client to send the packets.
ICMP Jitter defaults the interval for sending packets to 20 milliseconds (ms) and the maximum number of packets to be sent each time to 60. The interval and the number of packets to be sent are configurable.
The following items can be calculated based on the information in the packets received by the client:
7 NQA
Maximum, minimum, and average jitters of the packets from the client to the server and from the server to the client Maximum unidirectional delay from the server to the client or from the client to the server The obtained jitter can clearly reflect network status. In a UDP jitter test, you can set the number of packets to be sent consecutively in a single test instance. Through this setting, the actual traffic of a kind of packet can be simulated. Figure 7-3 Application scenario of an ICMP Jitter test
7.4.4 ICMP Jitter (hardware-based)

ICMP Jitter (hardware-based) is a supplement to the ICMP jitter, which uses the hardware forwarding engine to transmit packets and add timestamps to packets. The hardware forwarding engine can: Reduce the interval for sending packets. The minimum interval for sending packets can be 10 ms. Increase the number of concurrent test instances. Each time an LPU is installed, 100 concurrent test instances is increased on the device. Enhance the accuracy on the calculation of the delay and jitter time. The following items can be calculated based on the information in the packets received by the client: Maximum, minimum, and average jitters of the packets from the client to the server and from the server to the client Maximum unidirectional delay from the server to the client or from the client to the server The obtained jitter can clearly reflect network status. Table 7-3 Differences between ICMP jitter and ICMP jitter (hardware-based) ICMP Jitter Interval for sending packets The minimum value is 20 ms. ICMP Jitter (hardware-based) The minimum value is 10 ms.
7-8
Issue 01 (2010-06-25)
7 NQA
ICMP Jitter Number of concurrent test instances A device can have a maximum of 50 concurrent test instances.
ICMP Jitter (hardware-based) Each time an LPU is installed, 100 more concurrent test instances can be implemented on the device. The device can implement a maximum of 1000 concurrent test instances. The LPU timestamp packets, which is more precise.
Jitter calculation
The MPU timestamps packets.
Figure 7-4 Application scenario of ICMP jitter (hardware-based)

CX-A CX-B
NQA agent
NQA server
7.4.5 Path Jitter

An NQA UDP jitter test instance can accurately measure the delay and jitter along the path from the client to the server, but cannot figure out the faulty location if the jitter value is too great. An NQA path jitter test instance, however, can identify the CX device whose jitter value is great. The NQA path jitter test first identifies the IP address of each hop from the client to the server by initiating a trace test, and then initiates an ICMP jitter test from the client to obtain the jitter value of each hop along the path. Figure 7-5 shows the process of a path jitter test: 1. 2. CX device A initiates a trace test to obtain the IP address of each hop along the path to CX-C. CX-A initiates an ICMP jitter test to the IP address of each hop to obtain the jitter value of each hop along the path to CX-C.
Figure 7-5 Application scenario of a Path Jitter test
CX-A
CX-B
CX-C
7.4.6 HTTP Test

An NQA HTTP test is used to obtain the responding speed in three phases. Figure 7-6 shows the process of an HTTP test.
Issue 01 (2010-06-25)
7-9
7 NQA
1.
Time of DNS resolution: It is a period from the time when the client sends a DNS packet to the resolver for resolving the name of the HTTP server to an IP address to the time when a DNS resolution packet containing the IP address is returned. Time to set up a TCP connection: It is the time taken by the client to set up a TCP connection with the HTTP server through three-way handshake. Transaction time: It is a period from the time at which the client sends a Get or Post packet to the HTTP server to the time at which a response packet sent by the client reaches the HTTP server. Through an HTTP test, the following can be calculated based on the information in the packets received by the client:

2. 3.
Minimum, maximum, and total time of DNS resolution Minimum, maximum, and total time to set up a TCP connection Minimum, maximum, and total HTTP transaction time
These statistics can clearly reflect the performance of the HTTP protocol over the network. Figure 7-6 Applicable scenario of the HTTP test
server.com
CX-A IP Network
DNS Server
7.4.7 DNS Test

An NQA DNS test is used to obtain the speed of resolving a specified DNS name to an IP address. The DNS test is borne by UDP packets. Figure 7-7 shows the process of a DNS test. 1. 2. 3. The client sends a DNS Query packet to the DNS server for resolving a specified DNS name. After receiving the Query packet, the DNS server constructs a Response packet and sends it to the client. After receiving the Response packet, the client calculates the time for DNS resolution by subtracting the time at which the client receives the Response packet from the time at which the client sends the Query packet. This can clearly reflect the performance of the DNS protocol over the network.
7-10
Issue 01 (2010-06-25)
7 NQA
Figure 7-7 Applicable scenario of the DNS test
server.com
CX-A IP Network
DNS Server
7.4.8 FTP Test

An NQA FTP test is used to obtain the speed of downloading a specified file from the FTP server or uploading a specified file to the FTP server. The FTP test is borne by TCP packets. Through an NQA FTP test, you can obtain the responding speed in two phases. Figure 7-8 shows the process of an FTP test. Time to set up a control connection: It is the time taken by the client to set up a TCP control connection with the FTP server through three-way handshake and the time taken to interchange signals through the control connection. Time to set up a data transmission connection: It is the time taken by the client to download a specified file from the FTP server or upload a specified file to the FTP server through the data transmission connection. Through an FTP test, the following can be calculated based on the information in the packets received by the client: Minimum, maximum, and average time to set up a control connection Minimum, maximum, and average time to set up a data transmission connection These statistics can clearly reflect the performance of the FTP protocol over the network. Figure 7-8 Applicable scenario of the FTP test
CX-A
FTP Client
FTP Server
7.4.9 DHCP Test

An NQA DHCP test is used to check the speed of obtaining an IP address from the DHCP server. The DHCP test is borne by UDP packets. Figure 7-9 shows the process of a DHCP test:
Issue 01 (2010-06-25)
7-11
7 NQA
1.
The client broadcasts a DHCP Discovery packet through the interface that needs to be allocated an IP address to query the DHCP server. The Discovery packet is broadcast to the network segment where the interface resides. After receiving the Discovery packet, the DHCP server returns a DHCP Offer packet carrying its own IP address, to the client. 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. After receiving the Request packet, the DHCP server returns a DHCP ACK packet carrying an IP address assigned to the interface, to the client. 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 at which the client receives the ACK packet from the time at which the client sends the Discovery packet. This can clearly reflect the performance of the DHCP protocol over the network.
2. 3. 4.
Figure 7-9 Applicable scenario of the DHCP test
CX-A
CX-B
NQA agent
DHCP Server
7.4.10 SNMP Test

An NQA SNMP test is used to check the speed of the communication between a host and an SNMP agent. The SNMP test is borne by UDP packets. Figure 7-10 shows the process of an SNMP test. 1. 2. The client (CX-A) sends a Request packet to the SNMP agent (CX-C) for obtaining the system time. After receiving the Request packet, the SNMP agent queries the system time and constructs a Response packet, and sends the Response packet to the client. After receiving the Response packet, the client calculates the time for the communication between the client and the SNMP agent by subtracting the time at which the client receives the Response packet from the time at which the client sends the Request packet. This can clearly reflect the performance of the SNMP protocol over the network. Figure 7-10 Application scenario of the SNMP test
CX-A
CX-B
CX-C
SNMP Agent
7-12
Issue 01 (2010-06-25)
7 NQA
7.4.11 TCP Test

An NQA TCP test is used to check the speed of setting up a TCP connection between a host and a TCP server through three-way handshake. Figure 7-11 shows the process of a TCP test. 1. 2. 3. CX- A sends a TCP SYN packet to CX- C (TCP server) for setting up a TCP connection. After receiving the TCP SYN packet, the TCP server accepts the request and responds the client with a TCP SYN ACK packet. After receiving the SYN ACK packet, the client returns an ACK packet to the TCP server. Then, a TCP connection is successfully set up. The client can calculate the time taken in three-way handshake for setting up the TCP connection with the TCP server by subtracting the time at which the client receives the packet to the time at which the client sends the packet. This can clearly reflect the performance of the TCP protocol over the network. Figure 7-11 Applicable scenario of the TCP test
CX-A
CX-B
CX-C
NQA Server
7.4.12 UDP Test

An NQA UDP test is used to check the speed of the communication between a host and a UDP server. Figure 7-12 shows the process of a UDP test. 1. 2. The client (CX- A) constructs a UDP packet and sends it to the UDP server (CX- C). After receiving the UDP packet, the UDP server returns the packet to the client. After receiving the returned packet, the client calculates the time for the communication between the client and the UDP server by subtracting the time at which the client receives the returned UDP packet from the time at which the client sends the UDP packet. This can clearly reflect the performance of the UDP protocol over the network. Figure 7-12 Applicable scenario of the UDP test
CX-A
CX-B
CX-C
NQA Server
7.4.13 MPing Test

An NQA MPing test is used to detect the connectivity and obtain the communication speed between a multicast source and a multicast group member. Acting as a simulated multicast source, the client sends a multicast packet to the multicast group member. If the multicast tree
Issue 01 (2010-06-25)
7-13
7 NQA
from the multicast source to the multicast group member has not been set up, the MPing test can also trigger the setup of the multicast tree. Figure 7-13 shows the process of an MPing test. 1. 2. The client (multicast source) sends a multicast ICMP Echo Request packet to the multicast group. After receiving the ICMP Echo Request packet, the multicast group member responds the multicast source with an ICMP Echo Reply packet in unicast mode. After receiving the ICMP Echo Reply packet, the multicast source calculates the time for the communication between the source and the multicast group member by subtracting the time at which the source receives the ICMP Echo Reply packet from the time at which the source sends the ICMP packet. This can clearly reflect the connectivity and communication speed between the multicast source and multicast group member. Figure 7-13 Applicable scenario of the MPing test
Source
CX-E CX-D
CX-C CX-B
CX-A
Receiver
7.4.14 MTrace Test

An NQA MTrace test is used to detect the multicast forwarding path between a multicast source and a destination host and collect statistics related to the devices along the multicast forwarding path. Figure 7-14 shows the process of an MTrace test. 1. The client (multicast source) sends an IGMP Tracert Query packet to the last-hop device connected with the destination host.
7-14
Issue 01 (2010-06-25)
7 NQA
2.
After the first-hop device connected with the multicast source receives the IGMP Tracert Request packet, the device sends an IGMP Tracert Response packet to the multicast querier, that is, the NQA client. After receiving the IGMP Tracert Response packet, the multicast querier can obtain the multicast forwarding path from the multicast querier to the destination host and information about each device along the multicast forwarding path. This can clearly reflect the multicast network status.
Figure 7-14 Application scenario of the MTrace test PC1
First-hop router
PC2
Multicast source Response Query Request
PC3 NQA Client
7.4.15 ICMP Test

An NQA ICMP test is used to detect the reachability of the route between the NQA client and a destination. The ICMP test has a similar function with the ping command. The difference is that the ICMP test provides more output information: By default, the command output shows the results of the latest five tests. The test result contains information about average delay, packet loss ratio, and the time at which the last packet is correctly received. Figure 7-15 shows the process of an ICMP test. 1. 2. The client (CX- A) constructs an ICMP Echo Request packet and then sends it to the destination (CX- B). After receiving the ICMP Echo Request packet, the destination responds the client with an ICMP Echo Reply packet. The client can then calculate the time for the communication between the client and the destination by subtracting the time at which the client receives the ICMP Echo packet to the time at which the client sends the ICMP Echo Request packet. This can clearly reflect network status.
Issue 01 (2010-06-25)
7-15
7 NQA
Figure 7-15 Applicable scenario of the ICMP test
7.4.16 Trace Test

An NQA Trace test is used to detect the forwarding path between the NQA client and a destination and collect statistics related to the devices along the forwarding path. The Trace test has a similar function with the tracert command. The difference is that the Trace test provides more output: Information about each hop in the test result contains average delay and packet loss ratio. The test result contains the time at which the last packet is received. Figure 7-16 shows the process of a Trace test. 1. 2. The client (CX- A) constructs a UDP packet, with the TTL being 1, and sends the packet to the destination (CX- B). After the first-hop device (CX- C) receives the UDP packet, it checks the TTL field and finds that the TTL decreases to be 0. Then, CX- C returns an ICMP Time Exceeded packet. After the client receives the ICMP Time Exceeded packet, it receives the IP address of the first-hop device and re-constructs a UDP packet, with the TTL being 2. After the second-hop device (CX- D) receives the UDP packet, it checks the TTL field and finds that the TTL decreases to be 0. Then, CX- D returns an ICMP Time Exceeded packet. The procedure repeats and after the packet reaches the last-hop device, the device returns an ICMP Port Unreachable packet to the client. The client (CX- A) can then obtain the forwarding path from the client to the destination and collect statistics related to each device along the forwarding path based on the ICMP packet returned by each hop. This can clearly reflect the network status.
3. 4.
5.
7-16
Issue 01 (2010-06-25)
7 NQA
Figure 7-16 Applicable scenario of the Trace test CX-C
CX-D
7.4.17 LSP Ping Test

An NQA LSP Ping test is used to detect the reachability of two types of LSPs, LDP LSPs and TE LSPs. Figure 7-17 shows the process of an LSP Ping test. 1. In an LSP Ping test, a UDP MPLS Echo Request packet is first constructed. The destination IP field is filled with an IP address on the network segment 127.0.0.0/8. The client searches for the LDP LSP based on the set remote LSR ID and then forwards the packet through the 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 CR-LSP. The egress monitors port 3503 and then returns an MPLS Echo Reply packet. The client can then calculate the time for the communication between the client and the egress by subtracting the time at which the client receives the MPLS Echo Reply packet from the time at which the client sends the MPLS Echo Request packet. This can clearly reflect the MPLS network status. Figure 7-17 Application scenario of the LSP Ping test
2.
MPLS Backbone
PE-A VLAN1
P PW
PE-B VLAN2
CE-A
CE-B
Issue 01 (2010-06-25)
7-17
7 NQA
7.4.18 LSP Trace Test

An NQA LSP Trace test is used to detect the forwarding paths of the two types of LSPs, LDP LSPs and TE LSPs, and collect statistics related to each device along the forwarding path. Figure 7-18 shows the process of an LSP Trace test. 1. In an LSP Trace test, a UDP MPLS Echo Request packet is first constructed. The destination IP field is filled with an IP address on the network segment 127.0.0.0/8. The client 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-LSR. The Echo Request packet should include the downstream mapping TLV that carries downstream information at current node, including next-hop address and outbound label. The TTL of the first sent MPLS Echo Request packet is 1. The MPLS Echo Request packet is forwarded through the specified LSP in the MPLS domain. After the packet reaches the first hop of the LSP, the TTL decreases to be 0 and times out. The firs hop then returns an MPLS Echo Reply packet. The client continues to send an Echo Request packet, with the TTL increasing by 1. Such a process is performed repeatedly until all the LSRs along the whole LSP return their responses. Then, the traceroute process ends. The client can obtain the forwarding path of the LSP from the client to the destination and collect statistics related to each LSR along the forwarding path based on the MPLS Echo Reply packet returned by each hop. This can clearly reflect the LSP status. Figure 7-18 Applicable scenario of the LSP Trace test
2.
3.
MPLS Backbone
PE-A VLAN1
P PW
PE-B VLAN2
CE-A
CE-B
7.4.19 LSP Jitter

An NQA LSP Jitter test is used to detect the jitter, delay, and packet loss ratio on the two types of LSPs, LDP LSPs and TE LSPs according to the timestamps in the packets. Figure 7-19 shows the process of an LSP Jitter test: 1. In an LSP Jitter test, a UDP MPLS Echo Request packet is first constructed. The destination IP field is filled with an IP address on the network segment 127.0.0.0/8. The client then searches for the corresponding LSP and forwards the packet through the LSP
7-18
Issue 01 (2010-06-25)
7 NQA
in the MPLS domain at certain intervals. For a TE LSP, the packet can be sent from a tunnel interface and then forwarded along a specified CR-LSP. 2. 3. The egress of the LSP monitors port 3503 and sends an MPLS Echo Reply packet marked with a timestamp to the client. After receiving the returned packet, the client calculates the packet jitter by subtracting the interval for the egress to receive the packets from the interval for the client to send the packets. The client can also calculate the maximum, minimum, and average jitter time in the transmission of the packet from the client to the egress. This can clearly reflect network status. Figure 7-19 Application scenario of the LSP Jitter test
MPLS Backbone
PE-A VLAN1
P PW
PE-B VLAN2
CE-A
CE-B
7.4.20 PWE3 Ping Test

An NQA PWE3 Ping test is used to detect the reachability of the PW for MPLS forwarding. Figure 7-20 shows the process of a PWE3 Ping test: 1. The client constructs an MPLS Echo Request packet and sends the packet through a specified PW based on the configured PW ID. After the packet reaches the remote PE, the remote PE responds the client with an MPLS Echo Reply packet with the destination address being the IP address of the interface that sends the MPLS Echo Request packet. The client can forward data along the PW only when receiving an MPLS Echo Reply packet returned by the remote PE. The client can then calculate the time for the communication between the client and the destination by subtracting the time at which the client receives the MPLS Echo Reply packet to the time at which the client sends the MPLS Echo Request packet. This can clearly reflect the PW status.
2.
Issue 01 (2010-06-25)
7-19
7 NQA
Figure 7-20 Application scenario of the PWE3 Ping test
MPLS Backbone
PE-A VLAN1
P PW
PE-B VLAN2
CE-A
CE-B
7.4.21 PWE3 Trace Test

An NQA PWE3 Trace test is used to detect the forwarding path of the MPLS-based PW and collect statistics related to each device along the forwarding path. Figure 7-21 shows the process of a PWE3 Trace test. 1. The client sends an MPLS Echo Request packet, with the TTL being 1. The Request packet is forwarded through a specified PW. After the packet reaches the first-hop device along the PW, its TTL decreases to be 0 and expires and the first-hop device returns an MPLS Echo Reply packet. After receiving the MPLS Echo Reply packet from the first-hop device, the client continues to send an MPLS Echo Request packet along the specified PW, with the TTL being 2. After the packet reaches the second-hop device along the PW, the TTL decreases to be 0 and expires and the second-hop device returns an MPLS Echo Reply packet. The preceding procedure is repeated and as a result the client can collect information about each node along the PW. The client can obtain the forwarding path of the PW from the client to the destination and collect statistics related to each LSR along the forwarding path based on the MPLS Echo Reply packet returned by each LSR. This can clearly reflect the PW status.
2.
3.
7-20
Issue 01 (2010-06-25)
7 NQA
Figure 7-21 Application scenario of the PWE3 Trace test
MPLS Backbone
PE-A VLAN1
P PW
PE-B VLAN2
CE-A
CE-B
7.4.22 MAC Ping Test

An NQA MAC Ping test is a kind of detection tool provided by Ethernet OAM. It is implemented based on 802.1ag. A MAC Ping test is initiated by an MEP and is performed between the MEP and MP in one MA. The destination can be any MP in the MA. The process of an MAC Ping test is as follows: An 802.1ag MAC Ping test is initiated by an MEP. The destination node can be any MEP or MIP within the same MA or in different MAs but should be at the same level as that of the initiator MEP. Through a MAC Ping test, statistics about the performance of Ethernet OAM, including average delay, jitter, and packet loss ratio can be collected based on the timestamps in the test packets. These statistics can clearly reflect the Ethernet network status. Figure 7-22 Application scenario of the MAC Ping test RouterB
RouterA
LBM
MEP2 LBR
MEP1
MEP3
MEP
LBM traffic LBR traffic
Issue 01 (2010-06-25)
7-21
7 NQA
Figure 7-22 shows the process of an 802.1ag MAC Ping test. 1. 2. MEP1 sends a Loopback Message (LBM) to MEP2. After receiving the LBM, MEP2 responds MEP1 with a Loopback Reply (LBR) message. MEP1 then calculates the time of the Ping operation for analyzing the network performance. Within the timeout period:
If MEP1 does not receive the LBR message from MEP2, it considers that the route between MEP1 and MEP2 is not reachable. If MEP1 receives the LBR message from MEP2, it calculates the transmission delay from MEP1 to MEP2 based on the timestamps carried in the messages.
During the test, the client can send multiple LBMs continuously and then observe whether LBR messages are returned. Through a MAC Ping test, statistics about the performance of Ethernet OAM, including average delay, jitter, and packet loss ratio can be collected based on the timestamps in the test packets. These statistics can clearly reflect the Ethernet network status.
7.4.23 MAC TUNNEL PING

The NQA MAC Tunnel Ping test is similar to the 802.1ag MAC Ping test. It is used to detect the PBB-TE tunnel. Figure 7-23 shows the process of an NQA MAC Tunnel Ping test. Note that the destination device of the MAC tunnel Ping test can only be the remote PE rather than a transit device over the PBB-TE tunnel. Figure 7-23 Application scenario of the MAC Tunnel Ping test
7.4.24 Path MTU

A path MTU test instance is used to obtain the maximum MTU value that does not require packet fragmentation during the packet transmission on the link. When one host sends a large number of IP packets to another host, the IP packets are fragmented according to the maximum acceptable packet length. This affect forwarding efficiency. It is preferable that these packets be of the largest size that does not requires fragmentation anywhere along the path from the client to the server. This packet size is referred to as the path MTU. Usually, the path MTU is equal to the minimum of the MTUs of each hop along the sub-paths. As shown in Figure 7-24, the MTU value between CX-A and CX-B is 100 bytes and between CX-B and CX-C is 200 bytes. Therefore, the path MTU value between CX-A and CX-C is 100 bytes.
7-22
Issue 01 (2010-06-25)
7 NQA
An NQA path MTU test is initiated from the client to the server. It requires several incremental steps to estimate the maximum path MTU. Figure 7-24 shows the process of a path MTU test: 1. 2. CX-A sends an ICMP probe packet to CX-C, with the packet size as the minimum range (The value is configurable and the default value is 48 bytes). When the first probe packet successfully hits the destination, CX-A continues to send ICMP probe packets with incremental steps (which is configurable and the default value is 10 bytes) to CX-C until three consecutive packets time out. This indicates that the MTU of the sent packet is greater than the minimum path MTU. CX-A sends a 48-byte detection packet to CX-C to check the connectivity of the network. If the connectivity of the network is normal, the size of the packet that times out in Step 2 is the maximum path MTU.
3.
Figure 7-24 Application scenario of a Path MTU test
CX-A
CX-B
CX-C
7.4.25 CE-Ping
CE-ping is tool used by a PE on the VPLS network to identify whether the IP address of the CE is online (reachable) by initiating an ARP request. As shown in Figure 7-25, CE1 is a Layer 2 CX device on the user side, which connects R1 and R2 to PE1. CE2 is a device on the other user side of the VPLS network and is connected to PE3. PE1 pings the IP address of a CE to check whether the CE is reacheable. PE1 cannot identify the PE to which the CE is connected and therefore broadcasts the ARP request message within the VPLS network to ask for the MAC address corresponding to the IP address of the CE. All CEs receive the ARP request message. CE1, being a Layer 2 device, broadcasts the request message to R1 and R2. If R1, R2 or CE2 identifies its own IP address to have been included in the ARP requests by PE1, it responds to the ARP request. After receiving the response, PE1 can decide that the user is online (reachable).
Issue 01 (2010-06-25)
7-23
7 NQA
Figure 7-25 Application scenario of a CE-Ping test CE PING
R1
CE1
CE2
R2
PE1
PW2
PE4
PW1 VPLS P PW4
PW3 PE2
PE3
7.4.26 VPLS MPING

An NQA VPLS MPing test instance is used to check whether the IGMP snooping function of a specified Virtual Switching Instance (VSI) on the VPLS network is normal. In addition, it can be used to discover edge devices in one VSI. Figure 7-26 shows the process of an NQA MPing test: The client can determine the communication time between the client and the destination by subtracting the arrival time of MPLS Echo Reply packets at the client from the departure time of MPLS Echo Request packets from the client. The communication time can clearly reflect the PW status. If MPLS Echo Reply packets carry information about the CE list, it means that entries in the MFIB table on the peer are matched. Information about the CE list consists of five fields: the first field is the IP address of the responding PE; the second field is information about the interface connecting the CE and PE (including information about the VLAN); the third field is the reply mode; the fourth field is the size of the Reply packet; the fifth field is the round-trip delay. 1.1.1.9 SubPort: 0/0/1.1:10 Inband 120 10ms
If entries in the MFIB table on the peer are found, it means that information about PWs on the forwarding-side or CE side of a specified VSI exists on the PE.
7-24
Issue 01 (2010-06-25)
7 NQA
Figure 7-26 Applicable scenario of a VPLS MPing test VPN1 LSP Tunnel CE1 UPE1 SPE1 VSI 1 VSI 1 VSI 2 VSI 1 CE4 VPN2 LSP Tunnel UPE2 SPE2 PW VSI 2 PW CE3 VPN1 PW LSP Tunnel SPE3 UPE3
CE5 VPN2
CE2 VPN1
An NQA VPLS MPing test instance can be used to check whether the IGMP snooping function of a VSI is normal only after the VSI is enabled with the IGMP snooping function. After the NQA VPLS MPing test instance starts, the client sends an MPLS Echo Request packet carrying a VPLS MPing private TLV along a PW based on the Layer 2 MFIB table. In the case of HVPLS network, the MPLS Echo Request packet is forwarded based on the Layer 2 MFIB table of each SPE. When the MPLS Echo Request packet reaches the egress (a PE or UPE connected to a CE) in the VPLS domain, an MPLS Echo Reply packet is returned. The MPLS Echo Reply packet carries the VPLS MPing private TLV, including a list learned by the VSI (The list includes CEs that are added to the specified multicast group).
Issue 01 (2010-06-25)
7-25
7 NQA
Figure 7-27 Structure of a VPLS MPing private TLV
Vendor(64512) Vendor Vender OUI(2011) sub-type(5:mfib ping) Length Multicast Addr Src LSR ID Src Mac(6byte) Dest Mac(6byte) AClist ...
The client determines whether the IGMP snooping function of VSIs along paths to different destinations is normal by checking whether the received MPLS Echo Reply packets carry the CE list. To obtain information about edge devices in the same VSI, it is required that the VSI be not enabled with the IGMP snooping function. Alternatively, the information can be obtained based on the specified reserved multicast address (224.0.0.x). After the NQA VPLS MPing test instance starts, the client broadcasts an MPLS Echo Request packet carrying a VPLS MPing private TLV along PWs. If server PEs (SPEs) exist, the MPLS Echo Request packet is broadcast throughout SPEs. When the MPLS Echo Request packet reaches the egress in the VPLS domain, the egress returns an MPLS Echo Reply packet carrying a VPLS MPing private TLV. The client determines the number of edge devices in one VSI based on the number of MPLS Echo Reply packets returned from different destinations.
7.4.27 VPLS PING

An NQA VPLS Ping test instance is used to test whether a particular server is reachable across a VPLS network. Figure 7-28 shows the process of an NQA VPLS Ping test: 1. A VSI and a MAC address are specified. The MAC address can be the bridge MAC address of the peer PE on the VPLS network or the MAC address of the CE on the user side. The test instance constructs an MPLS Echo Request packet, with the network address 127.0.0.0/8 being added to the IP header as the destination IP address. Then, the MAC table learned on a PW side is checked. If an entry corresponding to the destination address is found in the MAC table, the MPLS Echo Request packet is forwarded to the PW; otherwise, the MPLS Echo Request packet is broadcast throughout all PWs in the specified VSI. The PE monitors the port numbered 3503. When the port receives the MPLS Echo Request packet, the PE node responds with an MPLS Echo Reply packet. If the MAC address specified on the client is the MAC address of the CE side, the MPLS Echo Request packet is not actually forwarded to the CE. Instead, the MAC address of the requested CE is searched on the PE node to which the requested CE is connected. If the MAC address of the CE exists on the PE node, the VPLS ping test is regarded as successful; otherwise, the test is regarded as failed. The client can then calculate the time for the communication between the client and the egress by subtracting the time at which the client receives the MPLS Echo Reply packet from the time at which the client sends the MPLS Echo Request packet. This can clearly reflect the MPLS network status.
2. 3.
7-26
Issue 01 (2010-06-25)
7 NQA
Figure 7-28 Applicable scenario of the VPLS Ping test CE1 CE2 MAC 0018-826D-4917
PW vsi:a2 PE1
P W
vsi:a2 PE2
P W
VPLS
MAC 0018-826D-4917
port GE3/0/1.3
PE3
vsi:a2
As shown in Figure 7-28, the process of initiating the VPLS ping test on PE1 is as follows. 1. A VPLS ping test instance is configured on PE1, with the MAC address of CE2, namely, 0018-826d-4917, as the destination MAC address. The entry corresponding to the destination MAC address is not found in the MAC table on PE1. Consequently, the MPLS Request packet is broadcast throughout PWs to the specified VSI. Both PE2 and PE3 receive the MPLS Request packet. Because the destination MAC address and the bridge MAC address on PE3 are different, and no entry corresponding to the destination MAC address is found in the MAC table on the CE, according to the split horizon principle, the Request packet is not forwarded. The destination MAC address and the bridge MAC address on PE2 are different. An entry corresponding to the destination MAC address, however, is found in the MAC table on the CE. In this case, an MPLS Reply packet is returned to the client, indicating that the VPLS ping test is successful.
2.
3.
7.4.28 VPLS Trace

An NQA VPLS trace test instance is used to detect the connectivity of the forwarding path across the VPLS network, locate faults on the VPLS network, and collect statistics about every device along the forwarding path. Figure 7-29 shows the process of a VPLS trace test. 1. A VSI and MAC address are specified for the VPLS trace test. The MAC address can be the bridge MAC address of the peer PE on the VPLS network or the MAC address of the CE on the user side. The test instance creates an MPLS Echo Request packet and adds the network address 127.0.0.0/8 to the IP header as the destination IP address. Then, the MAC table learned on a PW side is checked. If an entry corresponding to the destination address is found in the MAC table, the MPLS Echo Request packet is forwarded to the PW; otherwise, the MPLS Echo Request packet is broadcast throughout all PWs corresponding to the specified VSI. The Echo Request packet should include a downstream mapping TLV that carries downstream information about the LSP at the current node, such as next-hop address and outbound label. The TTL value of the first MPLS Echo Request packet is 1.
Issue 01 (2010-06-25)
7-27
7 NQA
2.
The MPLS Echo Request packet is forwarded in the VPLS domain through a specified PW. When the TTL carried in the packet expires, an MPLS Echo Reply packet is returned. The client continues to send Echo Request packets carrying incremental TTL values. Such a process repeats until the destination or the edge of the VPLS network return their responses. Then, the VPLS trace process is complete. If the MAC address specified on the client is the MAC address of the CE, the MPLS Echo Request packet is not forwarded to the CE and the PE node that is connected to the CE is checked. If the MAC address of the CE exists on the PE node, the VPLS trace test is successful; otherwise, the test is failed. Based on the MPLS Echo Reply packet returned by each node, the client collect and display information about the forwarding path from the client to the server and each device along the forwarding path.
3.
4.
Figure 7-29 Applicable scenario of a VPLS trace test
CE1
CE2 MAC 0018-826D-4917
Sending PE vsi:a2
PW
PW VPLS
vsi:a2
Receiving PE MAC 0018-826D-4917
port GE3/0/1.3
PE3
vsi:a2 TTL2
Figure 7-29 shows the process of a VPLS trace test initiated on the client PE. 1. A VPLS trace test instance is configured on the sending PE, with the MAC address of CE2, namely, 0018-826d-4917, as its destination MAC address. An MPLS Echo Request packet with the TTL being 1 is sent. Because no destination MAC address is found on the sending PE, the MPLS Echo Request packet is broadcast throughout all PWs of the specified VSI. After receiving the MPLS Echo Request packet, PE3 checks Because the destination MAC address and the bridge MAC address on the PE3 are different, and no entry corresponding to the destination MAC address is found in the MAC table, when the TTL carried in the MPLS Echo Request expires, the packet is not forwarded and an MPLS Echo Reply packet is returned to the sending PE. The Receiving PE receives the MPLS Echo Request packet. The destination MAC address and bridge MAC address on the Receiving PE are different. An entry corresponding to the destination MAC address exists, however, is found in the MAC
2.
7-28
PW
L1 TT
Issue 01 (2010-06-25)
7 NQA
table on the CE. In this case, an MPLS Reply packet is returned to the Sending PE, indicating that the VPLS ping test is successful.
7.5 Impact
7.5.1 On the System Performance 7.5.2 On Other Features 7.5.3 Defects

Configuring abundant NQA instances occupies a large number of memory and CPU resources, thereby affecting the system performance.

Abundant NQA tasks result in higher CPU usage, which will affect the scheduling of other tasks.
7.5.3 Defects

Acronyms and Abbreviations
Abbreviation NQA QoS LSP FTP DHCP HTTP PWE3 LSP MPLS UDP TCP DNS MD Full Spelling Network Quality Analysis Quality of Service Label Switched Path File Transfer Protocol Dynamic Host Configuration Protocol Hypertext Transfer Protocol Pseudo Wire Emulation Edge-to-Edge Label Switched Path Multi-Protocol Label Switch User Datagram Protocol Transport Control Protocol Domain Name Service Maintenance Domain
Issue 01 (2010-06-25)
7-29
7 NQA
Abbreviation MEP CCM LBM LBR
Full Spelling Maintenance association End Point Continuity Check Message Loopback Message Loopback Reply
7-30
Issue 01 (2010-06-25)
8 VLL NetStream
8
About This Chapter
8.1 Introduction to VLL NetStream 8.2 References 8.3 Availability 8.4 Principles 8.5 Applications 8.6 Impact
VLL NetStream
8.1 Introduction to VLL NetStream

Definition
VLL NetStream refers to the delivery of sampled VLL service packets on the LPUs to the network management system (NMS) for analysis and statistics. The sampled VLL service packets contain fields including VLAN ID, source IP address, destination IP address, source port number, destination port number, protocol number, type of service (ToS), and interface index.
Purpose
VLL services are encapsulated into VLAN packets. To know the service traffic in each VLAN, you need to collect the statistics about the VLAN ID-based aggregated traffic. Some Point-to-Point Protocol over Ethernet (PPPoE) packets may contain PPP packets, the intermediate PPPoE headers, and the outer Ethernet headers. To obtain information about fields such as source/destination IP address, the PPPoE headers must be removed.
Issue 01 (2010-06-25)
8-1
8 VLL NetStream
Figure 8-1 Typical networking plan
CE NetStream board
CE
NSC
As shown in Figure 8-1, VLL service packets are sampled and sent to the NetStream board for analysis. VLL service packets are sampled on the inbound Ethernet interface and the obtained original traffic is sent to the NMS. The sampled VLL service packets can be aggregated based on VLAN IDs. As shown in Figure 8-2, PPPoE packets are sampled, and information about IP addresses (starting from the field ppp_payload) is obtained. Figure 8-2 Diagram of the PPPoE packet format
LW0 LW1 LW2 LW3 LW4 LW5 DMAC_L16
DMAC_H32 DMAC_H16 SMAC_L32 ETHER_TYPE = 0x8864 SESSION_ID = 0x1234 PPP CONTROL= 0xc021 v = 1 | t = 1 | CODE = 0x00 LENGTH = 0x0004 PPP_PAYLOAD
Benefits
Benefits brought to operators: Provides the statistics about the VLAN ID-based aggregated traffic for analysis. Enables VLL service packets to be sampled on the inbound Ethernet interface for traffic and security analysis. Benefits brought to users:
8-2 Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. Issue 01 (2010-06-25)
8 VLL NetStream
None.
8.2 References
Descriptions about PPPoE in RFC 2516.
8.3 Availability
None
License Support
This feature is not license-controlled.
Version Support
8.4 Principles
When VLL service packets are transmitted through interfaces of an LPU, you can enable NetStream and set the sampling ratio on the interfaces. In this manner, VLL service packets are sampled and sent to the NetStream board. On the NetStream board, Layer 2, Layer 3, and Layer 4 headers of the sampled packets are resolved and information about the VLAN ID, source IP address, destination IP address, protocol number, ToS, TCP/UDP source port number, and TCP/UDP destination port number is obtained. According to the obtained information, the original traffic is constructed and saved to the original traffic cache. The original traffic in the cache is aged when either of the following conditions is met: Original traffic is continuously received by the cache, and the number of packets in the original traffic keeps increasing. When the receiving time exceeds the threshold of Active time, the original traffic is aged. This is called the active-time aging. Original traffic is not received for a period of time, and the number of packets in the original traffic keeps unchanged. When the period of time exceeds the threshold of Inactive time, the original traffic is aged. This is called the inactive-time aging. The aged original traffic is exported to the NMS or is used to construct an aggregated traffic. If VLAN ID-based aggregation is enabled, a VLAN-based aggregated traffic is constructed based on VLAN IDs or IF indexes. Similar to the original traffic, the aggregated traffic is
Issue 01 (2010-06-25)
8-3
8 VLL NetStream
saved in the cache and aged in either active-time aging mode or inactive-time aging mode. The aged aggregated traffic is packaged and exported to the NMS. Through VLAN ID-based aggregation, the NMS can collect statistics about VLAN-based VLL services.
8.5 Applications
None.
8.6 Impact
8.6.1 On the System Performance 8.6.2 On Other Features

NetStream sampling affects traffic forwarding on the LPU.

NetStream is exclusive with port mirroring and rate limit of MAC address learning functions on the K board.

Terms
Term Original flow Description The system defines a set of packets with the same septuple information (the source IP address, destination IP address, protocol number, ToS domain, TCP/UDP source port number, TCP/UDP destination port number, or interface index) as a data flow. The LPU samples the data flow and sends the sampled packets to the NetStream board, where the septuple information of the packets is extracted and the statistics about the packets, including the duration of the packet sampling, total number of packets, and total number of bytes are collected. Then, the NetStream board constructs an original flow according to the septuple information and statistics. The NetStream board collects the statistics about original flows, including the duration of the packet sampling, total number of packets, total number of bytes, and total number of original flows, based on which the NetStream board constructs an aggregated flow.
Aggregat ed flow
8-4
Issue 01 (2010-06-25)
8 VLL NetStream
Abbreviations
Abbreviati on VLL VLAN ID TOS Full Spelling Virtual Leased Line ID of the Virtual Local Area Network (VLAN) Type of Service
Issue 01 (2010-06-25)
8-5
9 NetStream
9
About This Chapter
9.1 Introduction 9.2 References 9.3 Availability 9.4 Principles 9.5 Applications 9.6 Impact
NetStream
9.1 Introduction
Definition
NetStream is a Huawei-patented technology for collecting the statistics about the network traffic and exporting the statistics. The statistics exported through NetStream can be used for various purposes, including: Network management and planning Enterprise accounting and departmental chargebacks ISP billing report Data storage Data mining for marketing purposes
Object
The rapid development of the Internet provides customers with higher bandwidth and predictable QoS. Meanwhile, with the increase of services and applications, operators need to provide more fine-grained metering for network management and accounting. As shown in Table 9-1, traditional methods to collect stream statistics have drawbacks. Developing a
Issue 01 (2010-06-25)
9-1
9 NetStream
technology to answer the preceding demands becomes urgent. NetStream is therefore developed. Table 9-1 Implementation and drawbacks of the traditional traffic statistics method Item Based on IP statistics Implementation The counter index is saved in the routing table to count the bytes and packets passing through the router. The ACL is used to accurately match packets and then collect statistics about matching packets. The SNMP protocol is used to implement the statistics function on the router, such as the interface statistics, IP statistics, and the ACL matching statistics. Through interface mirroring, traffic passing through the interface is duplicated and then sent to a special server to implement the statistics. Traffic is duplicated through the splitter or other devices at the physical layer and then sent to the special server to implement statistics. Drawback This method can calculate packets of limited types only.
Based on the ACL
Large numbers of ACLs need to be configured, and the mismatching packets cannot be counted. The statistics function is not strong enough. It needs to collect the statistics through continuous polling, which puts heavy load on the CPU and network.
Based on SNMP
Based on interface mirroring
The cost is high. A special server is needed to carry out statistics and an interface is occupied. The statistics cannot be performed on the interface that does not support the mirroring function. The cost is high. The special server and device must be purchased.
Based on the traffic duplication at the physical layer
Benefits
NetStream enables carriers to implement more fine-grained metering for network management and accounting.
9.2 References
Document ISO 3954 Description Cisco Systems NetFlow Services Export Version 9 Remarks
9-2
Issue 01 (2010-06-25)
9 NetStream
9.3 Availability
The NetStream Data Exporter (NDE) samples packets and exports the statistics data to the NetStream Collector (NSC). The NSC is responsible for analyzing and collecting the statistics data from the NDE. The NetStream Data Analyzer (NDA) analyzes the statistics data and then provides the basis for various services, such as network accounting, network planning, network monitoring, application monitoring, and analysis.
License Support
NetStream in integrated mode are available only after the corresponding license is obtained.
Version Support
Hardware Support
None
9.4 Principles
The implementation of the NetStream function is divided into two parts: 1. 2. Stream sampling Packets are replicated and sent to the NetStream board. Stream processing Streams are constructed, maintained, aged, aggregated, and added to packets for export. NetStream service processing modes are as follows: Integrated service processing mode The packet sampling is performed on the LPU and the stream processing is performed on the NetStream board, that is, each LPU samples and sends packets to the NetStream board for integrated processing. Distributed service processing mode The packet sampling and stream processing are performed on the LPU. In V8R1, the distributed service processing mode cannot be configured on the LPU. Packet sampling procedure is as follows: 1. 2. After the NetStream function is enabled on an interface, the system stores the NetStream information in the interface information table. The system samples packets passing through the interface at the set sampling ratio.
Issue 01 (2010-06-25)
9-3
9 NetStream
The LPU replicates the sampled packets and sends them to the NetStream board for processing. After receiving a packet, the NetStream board extracts the attributes (such as source address and destination address) of the packet and compare them with those of existing streams created from packets. If matching, the packet is added to the stream and the packet count is refreshed; if not, a new stream is created. Then, the NetStream board ages and aggregates streams, and sends the statistics to the specified Network Management System (NMS) for analysis. If the number of the sampled packets is great, the forwarding performance of the device is affected. The reasonable sampling ratio is 1000:1. 9.4.1 Sampling Procedure 9.4.2 Sampling Modes 9.4.3 Aging of a Stream 9.4.4 Export of a Stream 9.4.5 9.4.6 Interface Index of NetStream Format Versions of NetStream Packets
9.4.1 Sampling Procedure

Figure 9-1 shows the NetStream sampling procedure.
9-4
Issue 01 (2010-06-25)
9 NetStream
Figure 9-1 NetStream sampling procedure

A packet reaches the interface.
Check whether the packet is a fragment. No Analyze whether the IP packet is a unicast packet or a multicast packet.
Yes Sampling is not performed.
Analyze whether sampling is enabled on the interface. Enable sampling on the interface.
Fixed packet Check whether the Extract the number sampling sampling mode is random of fixed packets or packet sampling or fixed interval and packet sampling. update the data.
Random packet sampling Compare the number and the value configured on the interface. Sample the packet Packets that carry the flow information are sent to the NetStream board.
Table 9-2 shows the information related to the NetStream function on an interface. Table 9-2 Information related to the NetStream function Item Enabling mark of unicast packet sampling Enabling mark of multicast packet sampling Enabling mark of the sampling function Lengt h 1 bit Function Indicates whether the sampling of the unicast packet is enabled. Indicates whether the sampling of the multicast packet is enabled. Indicates whether the sampling function is enabled on the interface.
1 bit
1 bit
Issue 01 (2010-06-25)
9-5
9 NetStream
Item Sampling mask Interface index
Lengt h 15 bits 16 bits
Function Indicates the sampling ratio of the random sampling ratio and packet-based sampling ratio. Indicates the index of an interface, including the 4-bit slot information and the 12-bit interface index information. This field serves as the inbound interface information of a stream.
Information about the incoming traffic and information about the outgoing traffic are separate. The CX600 only supports the sampling of the incoming traffic.
9.4.2 Sampling Modes

Through packet sampling, information about only few packets needs to be extracted for analysis, which reduces the impact exerted by the NetStream function on the device performance. There are four sampling modes: Packet-based random sampling In this mode, one packet is randomly sampled every certain packets. That is, if the packet interval is 100, one packet is randomly sampled every 100 packets. Packet-based regular sampling In this mode, one packet is regularly sampled at a fixed packet interval. That is, if the packet interval is 100, after the fifth packet is sampled, every 100th packet is sampled, for example, packets 105, 205, 305 are sampled. Time-based random sampling In this mode, one packet is randomly sampled every certain time periods. That is, if the sampling time period is 100, one packet is randomly sampled among packets that pass through the interface in every 100 ms. Time-based regular sampling In this mode, one packet is regularly sampled at a fixed time interval. That is, if the time interval is 100 ms, after the first packet is sampled at 30 ms, packets that pass through the interface every 100th ms are sampled, for example, packets are sampled at 130 ms, 230 ms, and 330 ms.
The CX600 supports only the packet-based regular sampling.
9.4.3 Aging of a Stream

The NetStream traffic on the network burst in an intermittent mode, that is, tens of thousands of streams are generated in a few seconds. The memory capacity of the NDE, however, is limited. This requires that streams saved earlier to the NDE be exported to release space for later streams. This process is called aging. A stream is aged in any of the following situations: Regular aging:
9-6
Issue 01 (2010-06-25)
9 NetStream
A stream is aged when its inactive time (the duration from the time no packets are added to the stream to the current time) expires or its active time (the duration from the time the stream is constructed to the current time) expires. When the active time of a stream in the buffer expires, the system dose not age the stream until a new stream enters the buffer; when the inactive time of a stream in the buffer expires, the system immediately ages the stream regardless of whether the active time of the stream expires. You can set the active time and inactive time for a stream; alternatively, you can adopt the default values (the default active time is 30 minutes and the default inactive time is 30 seconds). The active time is used to export the long-lasting stream on a regular basis. The inactive time is used to export the stream to which packets are intermittently added. Once packets stop being added to the stream, the stream is exported to release memory space. FIN-based or RST-based aging: A stream is aged when the FIN or RST bit is detected in the packets of the stream. This is because the FIN or RST bit in the packet transmitted over the TCP connection indicates that the TCP connection is terminated. When a packet containing the FIN or RST bit enters a stream, the system immediately ages the stream. If the first packet of a stream contains the FIN or RST bit, a stream is not aged. By default, the system ages the stream that contains the packet carrying the FIN or RST bit. To collect the statistics about packets carrying different TCP flags, you can configure the system not to age the stream that contains the packet carrying the FIN or RST bit through setting. Bytes-based aging: A stream is aged when the number of bytes exceeds the upper limit. Bytes of packets in the streams cached in the buffer are counted. When the number of packet bytes in a stream exceeds the specified upper limit (The maximum count of the hardware byte counter is 4294967295, 3.9 Gbytes), the buffer overflows. In this case, the system immediately ages the stream to avoid the byte counting error. Forcible aging: You can run the reset ip netstream cache command to forcibly age all the original streams in the current buffer. The forcible aging is required when the buffer is full but new streams need to be added or when the streams in the buffer fail to be aged due to the abnormality of the NetStream service.
9.4.4 Export of a Stream

Export of original streams Information in the aged original streams is collected and then encapsulated into UDP packets to be sent to the NDC. In this manner, the NDC can obtain the detailed information about each original stream and process these stream records in a flexible manner. This, however, increases the network bandwidth and CPU usage. In addition, to store these stream records, a great amount of memory is occupied and the cost of the CX600 is increased. Export of aggregated streams After the information about the aged original streams is collected, original streams are classified, combined, and constructed into aggregated streams according to certain rules. When the timer in the system expires, aggregated streams are exported to the NDC as UDP packets. Through aggregation, original streams can be transmitted with less network
Issue 01 (2010-06-25)
9-7
9 NetStream
bandwidth, CPU usage, and storage space. The CX600 supports the aggregation modes listed in Table 9-3. Table 9-3 List of aggregation modes Aggregation Mode as Description AS aggregation: Streams with the same source AS number, destination AS number, input interface index, and output interface index are aggregated as one stream, and the statistics about the aggregated stream are collected. AS-ToS aggregation: Streams with the same source AS number, destination AS number, input interface index, output interface index, and ToS are aggregated as one stream and the statistics about the aggregated stream are collected. Protocol-port aggregation: Streams with the same protocol number, source port, and destination port are aggregated as one stream and the statistics about the aggregated stream are collected. Protocol-port-ToS aggregation: Streams with the same protocol number, source port, destination port, ToS, input interface index, and output interface index are aggregated as one stream and the statistics about the aggregated stream are collected. Source-prefix aggregation: Streams with the same source AS number, source mask length, source prefix, and input interface index are aggregated as one stream and the statistics about the aggregated stream are collected. Source-prefix-ToS aggregation: Streams with the same source AS number, source mask length, source prefix, ToS, and input interface index are aggregated as one stream and the statistics about the aggregated stream are collected. Destination-prefix aggregation: Streams with the same destination AS number, destination mask length, and output interface index are aggregated as one stream and the statistics about the aggregated stream are collected. Destination-ToS aggregation: Streams with the same destination AS number, destination mask length, destination prefix, ToS, and output interface index are aggregated as one stream and the statistics about the aggregated stream are collected. Prefix aggregation: Streams with the same source AS number, destination AS number, source mask length, destination mask length, source prefix, destination prefix, input interface index, and output interface index are aggregated as one stream and the statistics about the aggregated stream are collected. Prefix-ToS aggregation: Streams with the same source AS number, destination AS number, source mask length, destination mask length, source prefix, destination prefix, ToS, input interface index, and output interface index are aggregated as one stream and the statistics about the aggregated stream are collected.
as-tos
protocol-port
protocol-port-tos
source-prefix
source-prefix-tos
destination-prefix
destination-prefix-tos
prefix
prefix-tos
9-8
Issue 01 (2010-06-25)
9 NetStream
Aggregation Mode mpls-label
Description MPLS-label aggregation: Information about the sampled MPLS packets covers MPLS labels or MPLS labels and IP packets. In this mode, streams with the same three-layer labels (including the label field, EXP field, and stack bottom label of each layer) are aggregated and the statistics about the aggregated stream are collected. VLAN-ID aggregation: Streams with the same VLAN ID and input interface index are aggregated as one stream and the statistics about the aggregated stream are collected. BGP-next hop-ToS aggregation: Streams with the same BGP next hop, source AS number, destination AS number, input interface index, output interface index, and ToS are aggregated as one stream and the statistics about the aggregated stream are collected. Index-ToS aggregation: Streams with the same input interface index, output interface index, and ToS are aggregated as one stream and the statistics about the aggregated stream are collected.
vlan-id
bgp-nhp-tos
index-tos
9.4.5 Interface Index of NetStream

The Interface Index Function of NetStream
After the NetStream statistics function is enabled on the interface, statistics packets sent to the NM station carry index values of the interface. The NM station parses the interface name according to the index value and then monitors traffic of the specified interface.
Interface Index Mapped in NetStream

On the CX device, the interface index of the system is 32 bits. The index value carried in the statistics packets that are sent to the NM station from NetStream can be 16 bits or 32 bits. By default, the value is 16 bits. If the NM station only supports the 16-bit interface index, you need to load NetStream MIB to map the interface index value from 16 bits to 32 bits. After that, the interface index value is mapped to the interface name. If the NM station only supports the 32-bit interface index, you need to map the interface index from 16 bits to 32 bits. After that, when the NM station receives packets, it can map the interface index to the interface name.
9.4.6 Format Versions of NetStream Packets

Currently, the format versions of NetStream packets are available in V5, V8, and V9. Development of later versions is under way. NetStream packets of all formats are transmitted through UDP. Each data packet contains a header and one or several stream records. Original streams can be exported in V5 or V9 format; aggregated streams can be exported in V8 or V9 format.
Issue 01 (2010-06-25)
9-9
9 NetStream
Differing from the previous versions, the V9 format is based on the template, which makes the traffic statistics to be exported more flexibly, new fields to be added easily, and new records to be generated easily. The V9 format is incompatible with the V5 and V8 formats. Table 9-4 shows the structure of a NetStream packet. Figure 9-2 NetStream packet
IP UDP Header Flow Records
Figure 9-3 Header of the NetStream packet exported in V5 format

0 7 version system up time unix_secs unix_nsecs flow sequence engine type engine id sampling interval 15 count 31
Table 9-4 describes fields in the header of the NetStream packet exported in V5 format. Table 9-4 Description of fields in the header of the NetStream packet exported in V5 format Field version count SysUptime unix_secs unix_nsecs Description Indicates the version number of the format in which the NetStream packet is exported. For V5, the value is 0x05. Indicates the number of stream records in the current NetStream packet. The value ranges from 1 to 30. Indicates the period from the time the system is booted to the time the NetStream packet is generated, in milliseconds. Indicates the seconds from 00:00:00, January 1st, 1970 to the time the NetStream packet is generated. Indicates the residual nanoseconds since 00:00:00, January 1st, 1970.
9-10
Issue 01 (2010-06-25)
9 NetStream
Field flow_sequence
Description Indicates the sequence numbers of the exported stream records: In the first NetStream packet, the value is 0 and count of streams in the NetStream packet is c1 (count = c1). In the second NetStream packet, the value is c1 and count of streams in the NetStream packet is c2 (count = c2). In the third NetStream packet, the value is c2 + c1. In the n1 NetStream packet, the value is fs(n1) and the count of streams in the NetStream packet is c(n1). In the Nth NetStream packet, the value is fs(n1) + c(n1). You can judge from the value whether the NetStream packet is lost. When the stream sequence number overflows, NetStream packets transmission continues.
engine_type engine_id sampling Interval
Indicates the type of the stream switching engine, which is the device type. Indicates the slot ID where the switching engine resides, which is the slot ID where the NetStream board resides. Indicates the sampling interval. The value is configured in the global view.
Information carried in the NetStream packet exported in V5 format

Information carried in the NetStream packet exported in V5 format is marked in dark as shown in Figure 9-4.
Issue 01 (2010-06-25)
9-11
9 NetStream
Figure 9-4 V5 format information
Source port Destination port TCP flags Transport layer Protocol type
Time of flow set up Time of flow closed Time
Count of packets Count of Bytes statistic Length of destination mask Length of source mask Source AS number
Destination IP address Source IP address
Protocol Nexthop address Incoming label of the outer lable Outgoing label of the outer label Label layers Label
Destination AS number Routing infomation
Input interface Output interface Interface
Protocol type Class of service
The system constructs two types of UDP packets according to the statistics about the incoming and outgoing traffic. These two types of UDP packets are both in V5 format but carry different flag bits (incoming and outgoing).
Header of a NetStream packet exported in V8 format

0 7 version system up time unix_secs unix_nsecs flow sequence engine type engine id aggregation aggregation version reserved 15 count 31
sampling interval
The following table describes fields in the header of the NetStream packet exported in V8 format.
9-12
Issue 01 (2010-06-25)
9 NetStream
Table 9-5 Description of fields in the header of the NetStream packet exported in V8 format Field version count SysUptime unix_secs unix_nsecs flow sequence Description Indicates the version number of the format in which NetStream packets are exported. For V8, the value is 0x08. Indicates the number of streams in the current NetStream packet instead of the number of streams in all NetStream packets. Indicates the period from the time the system is booted to the time the NetStream packet is generated, in milliseconds. Indicates the seconds from 00:00:00, January 1st, 1970 to the time the NetStream packet is generated. Indicates the residual nanoseconds since 00:00:00, January 1st, 1970. Indicates the sequence number of the exported stream records: In the first NetStream packet, the value is 0 and count of streams in the NetStream packet is c1 (count = c1). In the second NetStream packet, the value is c1 and count of streams in the NetStream packet is c2 (count = c2). In the third NetStream packet, the value is c2 + c1. ... In the n 1 NetStream packet, the value is fs(n - 1) and the count of streams in the NetStream packet is c(n - 1). In the Nth NetStream packet, the value is fs(n - -1) + c(n - -1). You can judge from the value whether the NetStream packet is lost. When the stream sequence number overflows, NetStream packets transmission continues. engine type engine id aggregation Indicates the type of the stream switching engine, which is the device type. Indicates the slot ID where the switching engine resides, which is the slot ID where the NetStream board resides. Indicates the aggregation modes, which are: 01 as 02 protocol-port 03 source-prefix 04 destination-prefix 05 prefix 09 as-tos 0a protocol-port-tos 0b source-prefix-tos 0c destination-prefix-tos 0d prefix-tos aggregation version Indicates the version number of the format in which the aggregated NetStream packet is exported. The value is 0x02.
Issue 01 (2010-06-25)
9-13
9 NetStream
Field sampling Interval reserved
Description Indicates the sampling interval. The value is configured in the global view. Indicates the reserved field, whose values are all 0s.
Information carried in the NetStream packet exported in V8 format

Starting from V8, original streams can be aggregated on the NDE. Aggregation refers to the action of classifying and combining original streams into one stream according to certain rules. Aggregated streams can be transmitted with less network bandwidth. In the previous versions, the stream aggregation is implemented on the NDC. Aggregation based on the AS Figure 9-6 Schematic diagram of the aggregation based on the AS
Time of flow set up Time of flow closed Time
Count of packets Count of Bytes Statistic
Number of aggregation flow Flow number of aggregation flow
Source AS number Destination AS number Routing information
This aggregation mode is mainly used to collect the statistics about packets and bytes exchanged between routers in two ASs. Based on the traffic statistics about different ASs, carriers can implement the accounting settlement. If the source AS is the original AS, the source AS number is the AS to which the source address belongs. If the source AS is the peer AS, the source AS number is the number of the prior AS in the AS path.? If the source address belongs to the local AS or if the AS number cannot be obtained from the routing table, the source AS number is 0. If the destination AS is the original AS, the destination AS number is the AS to which the destination address belongs. If the destination AS is the peer AS, the destination AS number is the number of the prior AS in the AS path.? If the destination address belongs to the local AS or if the AS number cannot be obtained from the routing table, the destination AS number is 0. The source AS number and the destination AS number are the key values for the AS-based aggregation. Aggregation based on the protocol type
9-14
Issue 01 (2010-06-25)
9 NetStream
Figure 9-7 Schematic diagram of the aggregation based on the protocol type
Time of flow set up Time of flow closed Time Protocol type Count of packets Count of Bytes Statistic Source port Destination port Protocol Number of aggregation flow Flow number of aggregation flow
In this mode, packets of the same protocol type in the transmission layer (TCP and UDP), and with the same source and destination port number are aggregated. If the Protocol Type field is 6, it indicates that the protocol is TCP; if the Protocol Type filed is 17, it indicates that the protocol is UDP. For non-TCP or non-UDP packets, the source port number is 0. For ICMP packets, the destination port number is determined by the Type and Code fields in the packets. For non-TCP or non-UDP packets, the destination port number is 0. Aggregation based on the destination IP address prefix Figure 9-8 Schematic diagram of the aggregation based on the destination IP address prefix
Time of flow set up Time of flow closed Time Count of packets Count of Bytes Statistic Prefix of destination IP address Destination AS number Output interface Destination IP address Number of aggregation flow Flow number of aggregation flow
In this mode, packets with the same destination IP address prefix are aggregated.
Issue 01 (2010-06-25)
9-15
9 NetStream
Aggregation based on the source IP address prefix Figure 9-9 Schematic diagram of the aggregation based on the source IP address prefix
Time of flow set up Time of flow closed Time Count of packets Count of Bytes Statistic Prefix of destination IP address Destination AS number Input interface Outputinterface Source IP Protocol Number of aggregation flow Flow number of aggregation flow
Aggregation based on the source IP address prefix and the destination IP address prefix Figure 9-10 Schematic diagram of the aggregation based on the source IP address prefix and the destination IP address prefix
Time of flow set up Time of flow closed Time Count of packets Count of Bytes Statistic Prefix of destination IP address Destination AS number Output interface Destination IP address Number of aggregation flow Flow number of aggregation flow
In this mode, packets with the same source IP address prefix and the destination IP address prefix are aggregated. Aggregation based on ToS + AS
9-16
Issue 01 (2010-06-25)
9 NetStream
Figure 9-11 Schematic diagram of the aggregation based on ToS + AS
Time of flow set up Time of flow closed Time TOS of IP Count of packets Count of Bytes Statistic Number of aggregation flow Flow number of aggregation flow Destination AS number Source AS number TOS + AS Input interface Output interface Interface
Type of Service (ToS) is a filed in the IP packet header and is used to set the packet priority. Aggregation based on ToS + protocol type Figure 9-12 Schematic diagram of the aggregation based on ToS + protocol type
Time of flow set up Time of flow closed Time Count of packets Count of Bytes Statistic Number of aggregation flow Flow number of aggregation flow TOS of IP Protocol type Destination port Source port TOS + Protocol Input interface Output interface Interface
Aggregation based on the IP address prefix + ToS + protocol type
Issue 01 (2010-06-25)
9-17
9 NetStream
Figure 9-13 Schematic diagram of the aggregation based on the IP address prefix + ToS + protocol type
Time of flow set up Protocol type Time of flow closed Time Count of packets Count of Bytes Statistic Number of aggregation flow Flow number of aggregation flow Destination port Source port Protocol
TOS of IP Prefix of destination IP address Prefix of source IP address IP address
Aggregation based on ToS + source IP address prefix Figure 9-14 Schematic diagram of the aggregation based on ToS + source IP address prefix
Time of flow set up Time of flow closed Time TOS of IP Count of packets Count of Bytes Statistic Number of aggregation flow Flow number of aggregation flow Prefix of source IP address Source AS number Source port TOS+Source IP
Aggregation based on ToS + destination IP address prefix
9-18
Issue 01 (2010-06-25)
9 NetStream
Figure 9-15 Schematic diagram of the aggregation based on ToS + destination IP address prefix
Time of flow set up Time of flow closed Time TOS of IP Count of packets Count of Bytes Statistic Number of aggregation flow Flow number of aggregation flow Prefix of destination IP address Destination AS number Destination port TOS+Destination IP
Aggregation based on ToS + IP address prefix Figure 9-16 Schematic diagram of the aggregation based on ToS + IP address prefix
Time of flow set up Time of flow closed Time Count of packets Count of Bytes Statistic Number of aggregation flow Flow number of aggregation flow TOS of IP Prefix of destination IP address Prefix of source IP address Source AS number Destination AS number TOS + IP address
Issue 01 (2010-06-25)
9-19
9 NetStream
Header of a NetStream packet exported in V9 format

0 7 version system up time unix_secs package sequence source id 15 count 31
The following table describes fields in the header of the NetStream packet exported in V9 format. Table 9-6 Description of fields in the header of the NetStream packet exported in V9 format Field version count Description Indicates the version number of the format in which NetStream packets are exported. For V9, the value is 0x09. Indicates the number of FlowSet records (including records in the template FlowSet and data FlowSet) exported in the NetStream packet. Indicates the period from the time the system is booted to the time the NetStream packet is generated, in milliseconds. Indicates the seconds from 00:00:00, January 1st, 1970 to the time the NetStream is generated. Indicates the sequence number of all the exported packets. The value is accumulated. You can judge from the value whether the NetStream packet is lost.
NOTE The meaning of this filed in the header of the NetStream packet exported in V9 is different from that in V5 or V8 format. In V5 and V8, this field indicates the sequence number of all streams.
system up time unix_secs package sequence
source id
Indicates the source ID. The value is 4 bytes and is used to guarantee the uniqueness for all streams exported from a router. (The Source ID field is equal to the Engine Type and Engine ID fields in the header of the NetStream packet exported in V5 or V8 format). The value can be defined by the user. The first two bytes are reserved for future extension and set to 0. The third byte uniquely specifies the router engine on the export device by the device type. The fourth byte specifies the card number by the number of the slot where the NetStream board resides.
9-20
Issue 01 (2010-06-25)
9 NetStream
Terms related to the V9 format

Template FlowSet Describes the stream information in the exported NetStream packet. The template is encapsulated into the NetStream packet by a NetStream-enabled router and is sent to the NDC to set up a convention for information parsing between the router and the NDC. Being the core of the V9 format, a template FlowSet consists of multiple template records. Based on the template sent from the router, the NDC can parse the stream information carried in the exported NetStream packet without pre-defined parsing format. This greatly increases the flexibility and scalability of the NetStream records, and facilitates the development of the third party's software and the NetStream function. Template Record Corresponds to each data record in the exported NetStream packet. The stream information in the data record is parsed according to the corresponding template record. Template ID Identifies different templates. Different templates have different IDs. The data record contains the template ID used to select a template. Data FlowSet Indicates a combination consisting of one or multiple data records. Data Record Corresponds to one NetStream record.
NetStream packet exported in V9 format

As shown in Figure 9-18, a NetStream packet exported in V9 format consists of packet header, template FlowSet, and data FlowSet. Figure 9-18 Schematic diagram of the NetStream packet exported in V9 format
Packet Header Template flowset Data flowset Data flowset ...... Template flowset Data flowset Data flowset ......
The template FlowSet and the data FlowSet are independent of each other. The data record in the data FlowSet is parsed by the NDC according to a known template. That is, the NDC has already known the template corresponding to the template ID in the data record. The template FlowSet notifies the NDC of a template to be used. The template is used to parse the subsequent exported NetStream packets. The template FlowSet and the data FlowSet are not necessarily contained in an exported NetStream packet. The possible combinations are as follows: The exported NetStream packet contains the template FlowSet and the data FlowSet. For the NDC, the template FlowSet and the data FlowSet are independent from each other. The NDC saves the template in the received template FlowSet to parse the data record in the subsequent data FlowSet. The exported NetStream data contains only the data FlowSet. If the template ID is predefined, the router enabled with the NetStream function exports a NetStream packet carrying only the data FlowSet to the NDC. The exported NetStream data contains only the template FlowSet. Usually, the template FlowSet and the data FlowSet are packed into one exported NetStream packet to better use the
Issue 01 (2010-06-25)
9-21
9 NetStream
network bandwidth. When the router is already configured with the template and is restarted, the router is required to send all templates to NDC as soon as possible. In this situation, the exported NetStream packet contains only the template FlowSet. The template has an effective time. When the validity time of a template expires, the NDC deletes the template. In this case, the router is required to regularly transmit the template FlowSet to the NDC. If no data FlowSet is generated during the transmission, only the template FlowSet is transmitted.
Packet format of the template FlowSet

Figure 9-19 shows the format of the template FlowSet. Figure 9-19 Format of the template FlowSet
0 7 flowset id=0 length template id field count field 1 type field 1 length field 1 type field 1 length ...... field n type field n length template id field count field 1 type field 1 length field 1 type field 1 length ...... field m type field m length 15
In this example, the template FlowSet contains two template records. The following table describes the meaning of each field. Field FlowSet ID Description Distinguishes template records from data records. The FlowSet ID of a template record ranges from 0 to 255, and the FlowSet ID of a data FlowSet starts from 256. In this case, the NDC can identify the template FlowSet in the exported NetStream packet.
9-22
Issue 01 (2010-06-25)
9 NetStream
Field Length
Description Indicates the total length of the FlowSet. An individual template FlowSet may contain multiple template IDs. The length value should be used to determine the position of the next FlowSet record, which could be either a template or a data FlowSet. Length is described in the type/length/value (TLV) format, meaning that the value includes the bytes used for the FlowSet ID and the length bytes themselves, as well as all the lengths of the Template records of the FlowSet.
Template ID
When a router generates different template FlowSets to match the types of the NetStream data to be exported, each template is assigned a unique ID. The ID is unique on the router that generates the template ID. The templates that define the data record formats are numbered from 256, because the IDs from 0 to 255 are reserved for FlowSet IDs. Indicates the number of fields in this template record. A template FlowSet may include multiple template records. This value allows the users to determine the end point of the current template record and the start point of the next one. Indicates the field type. The value can be defined by users. For example, if the statistics based on the destination IP address, protocol type, ToS, and MPLS are collected, each type of the obtained information is defined by a filed type. Indicates the length of the field defined previously, in bytes. For the destination IP address, the value is 4, representing 4 bytes.
Field Count
Field Type
Field Length
Packet format of the data FlowSet

Figure 9-20 shows the packet format of the data FlowSet.
Issue 01 (2010-06-25)
9-23
9 NetStream
Figure 9-20 Packet format of the data FlowSet

0 7 15 flowset id= template id length record 1-field 1 value record 1-field 2 value record 1-field 3 value record 1-field 4 value ...... record 1-field n value record 2-field 1 value record 2-field 2 value record 2-field 3 value record 2-field 4 value ...... record 2-field m value ...... padding 31
In this example, the data FlowSet contains two data records. The data FlowSet ID is the ID of the template used to parse the two data records. The following table describes the fields carried in the data FlowSet packet. Field flowset ID = template ID length Description The FlowSet ID maps to a previously described Template ID. The NDC and display applications use the FlowSet ID to search for the corresponding template ID in the template FlowSet. Indicates the length of the data FlowSet. Length is described in the TLV format, meaning that the value includes the bytes used for the FlowSet ID and the length bytes themselves, as well as all the lengths of the current data records. Indicates a collection of field values of the data FlowSet. The padding field is 32 bits long and is inserted to the end of the FlowSet. Note that the length field will include those padding bits.
record n field n Padding
Relationship between the data stream and the V9 template format

The following figure shows the relationship between the data stream and the V9 template format.
9-24
Issue 01 (2010-06-25)
9 NetStream
Figure 9-21 Relationship between the data stream and the V9 template format
Template
V9 Header
0 represents the data template packet. Based on the mapping of the FlowSet ID, resolve the attirbutes of Value in Type + Length.
FlowSet ID=0 Length TemplateID=256 Num
Traffic data
V9 Header TemplateID=256 Num
Type+Length
Value
TemplateID=257 Num
Type+Length Pading
Issue 01 (2010-06-25)
9-25
9 NetStream
9.5 Applications
Inter-AS NetStream
Figure 9-22 Schematic diagram of inter-AS NetStream
1000:1 sampling and Peer-As are enabled on the interface. Statistics on the traffic from AS 700 and AS 900 to AS 600 are collected.
AS 700 AS 800 AS 600
AS 900 AS 100 AS 500
AS 200 AS 300
AS 400
1000:1 sampling and Origin-As are enabled on the interface. Statistics on the traffic from AS 100 and AS 800 to AS 500 are collected.
The AS type of the BGP route carried in the NetStream packet can be original AS or peer AS, which are mutually exclusive. The original AS indicates the AS that advertises the BGP route; the peer AS indicates the AS from which the BGP route is transparently transmitted to the local AS. With inter-AS NetStream, the traffic from the AS advertising the BGP route to the local AS or from the neighboring AS to the local AS is collected and monitored to serve as reference for the network deployment. In this networking: The traffic from AS 800 passes through AS 700, AS 900, and then AS 600 before reaching AS 500 . If the NetStream function is enabled for AS 600 and the peer AS is configured, the traffic from AS 700 and AS 900 to AS 600 is monitored.
9-26
Issue 01 (2010-06-25)
9 NetStream
The traffic sent from AS 800 and AS 100 reaches AS 500 through AS 200, AS 300, and AS 400. If the NetStream function is enabled for AS 300 and the original AS is configured, the traffic from AS 800 and AS 100 to AS 500 is monitored.
IP Address Prefix-Based Charging for ISPs

Figure 9-23 IP address prefix-based charging for ISPs
ISP 1
AS 500
ISP 2
User Networks 1000:1 sampling and Peer-As are enabled on the interface. Statistics on the traffic from AS 700 and AS 900 to AS 600 are collected.
Different IP address prefixes are applied to different ISP networks. The statistics about the traffic travelling to different ISPs' networks can be collected according to the destination IP address and the mask by means of destination-prefix aggregation. Thus, traffic streams with different destination IP addresses and masks are charged separately.
Issue 01 (2010-06-25)
9-27
9 NetStream
Analysis of Service Mode on the MPLS Network

Figure 9-24 Schematic diagram of the analysis of the service mode on the MPLS network
CE Stream :FEC+ Label+IP
PE
MPLS Core NSC&NDA P

.
PE CE
NetStream is deployed on the user interface on the PE to collect the statistics about the traffic from the MPLS network to the IP network and from the IP network to the MPLS network. This can provide a complete accounting scheme. NetStream is deployed at the network interface on the PE and on the P to collect the statistics about MPLS packets. In this case, the MPLS service mode can be pinpointed.
Statistics About the VPN Traffic

Figure 9-25 Schematic diagram of collecting the statistics about VPN traffic
VPN ingress VPN MPLS VPN VPN egress
IP to MPLS
NetStream can collect the statistics about the VPN traffic based on VPN instance numbers.
9.6 Impact
9-28
Issue 01 (2010-06-25)
9 NetStream
9.6.2 On Other Features 9.6.3 Huawei's Advantage 9.6.4 Other Defects

RMON enabled on the LPUK board and LPU board affects less than 5% of services and RMON enabled on the SPUC board affects about 30% of services.

None.
9.6.3 Huawei's Advantage

The ACL-based sampling is supported so that users can define ACL rules to sample traffic. The TCP flag information can be collected to help detect various TCP attacks. VPNIDs can be collected to calculate the VPN traffic. The SPUC board enabled with integrated NetStream boasts high performance and can process traffic at the rate of 500 kpps. The LPUK board enabled with distributed NetStream boasts high performance and can process traffic at the rate of 100 kpps without affecting the forwarding performance.
9.6.4 Other Defects

There is no loopback channel from the downstream to the upstream on the common interface boards, which disables downstream sampled packets from reaching the switching board. Therefore, downstream sampling is not supported.
The flexible card supports downstream sampling.
Downstream sampling can only obtain the outbound interface information rather than the inbound interface information. The LPUK board enabled with distributed NetStream does not support ACL-based sampling. Only a few types of aggregation based on the original flow are available and the aggregation costs a lot. Therefore, users cannot define and configure aggregation based on the original flow currently.

None.
Issue 01 (2010-06-25)
9-29
10 Ping and Tracert
10
About This Chapter
10.1 Introduction to Ping and Tracert 10.2 References 10.3 Availability 10.4 Principles 10.5 Impact 10.6 Terms and Abbreviations
Ping and Tracert
10.1 Introduction to Ping and Tracert

Definition
The ping command is a very common debugging tool for testing the accessibility of devices. It uses a series of Internet Control Message Protocol (ICMP) Echo messages to determine: Whether the remote device is available Round-trip delay in communicating with the remote host Packet loss The tracert command is used to discover the gateways that packets actually pass through when traveling from the source host to the destination host.
Purpose
When a device is faulty, you can use the ping and tracert commands to check network connectivity. The ping command is used to test the network connectivity and the host accessibility. The source host first sends an ICMP request message to the destination host, and then waits for an ICMP reply message. The tracert command is used to check the network connectivity and locate network faults.
Issue 01 (2010-06-25)
10-1
10 Ping and Tracert
10.2 References
The following table lists the references of this document. Document RFC4379 RFC5085 Description Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires Internet Protocol ICMP Router Discovery Messages Traceroute Using an IP Option Remarks
RFC791 RFC1256 RFC1393
10.3 Availability
License Support
The LSPV, service ping, and VPLS MAC ping functions are not license controlled.
Version Support
10.4 Principles
10.4.1 Working of Ping 10.4.2 Working of Tracert 10.4.3 LSPV 10.4.4 Service Ping 10.4.5 VPLS MAC Diagnosis
10.4.1 Working of Ping

The ping command sends an ICMP echo request message to an address, and then waits for a reply. The ping is successful only if the echo request gets to the destination, and the destination is able to return an echo reply message back to the source within a predetermined
10-2
Issue 01 (2010-06-25)
10 Ping and Tracert
time called a timeout. If the source does not receive the echo rely message within the timeout, the source displays that the Request message times out. The ping command sets the identifier field in the ICMP message as the process ID of the sending process. This allows the remote end to distinguish multiple ping processes that are running on the local end simultaneously. The ping command labels each ICMP Echo Request message with a sequence ID that starts from 1 and is increased by 1. The number of ICMP Echo Request messages to be sent varies with different systems. The default number is 5. The number of ICMP Echo Request messages can also be set through commands. If the destination is reachable, the source can receive five ICMP Echo Reply messages from the destination, with sequence numbers corresponding to those of ICMP Echo Request messages. If the TTL filed is reduced to 0 during the message forwarding, the device that the message reaches sends an ICMP timeout message to the source host, indicating that the destination host is unreachable.
10.4.2 Working of Tracert

The source host first sends three UDP packets with TTL fields being 1 to a remote device. A port with number greater than 32768 is selected randomly for the destination to receive the packet. The TTL value of 1 causes the UDP packets to be timed out as soon as it hits the first device in the path; this device then responds with an ICMP timeout message indicating that the UDP packets have expired. The source sends another three UDP messages, each with the TTL value set to 2, which causes the second device to return ICMP timeout messages. This process continues until the UDP packets actually reach the destination. Since these UDP packets are trying to access an invalid port at the destination host, the destination returns ICMP port unreachable messages, indicating that the port is unreachable port and the tracert process is finished. The purpose behind this is to record the source of each ICMP timeout message to provide a trace of the path the packet took to reach the destination. The maximum TTL value set for the UDP packets can be 30. Each time a message fails to be received received within the predetermined time, the UDP packets are displayed as expired at the sending end. If UDP packets with the TTL value set to 30 expire, it indicates that the destination is unreachable and the tracert test fails. By default, if no UDP packet is sent within 5 seconds, a timeout messages is displayed. The timeout value ranges from 0 to 65535, in milliseconds.
10.4.3 LSPV
Label Switched Path Verification (LSPV) is a mechanism using the MPLS ping and tracert to detect LSP errors and locate faulty nodes. The MPLS tunnel supports multiple upper-layer protocols and services. In MPLS, the control panel in charge of setting up an LSP cannot detect the failure in data forwarding of the LSP. This makes the network maintenance difficult. Similar to the IP ping and tracert, the MPLS ping and tracert are used to detect the availability of the LSP. The MPLS ping and tracert use MPLS Echo Request messages and MPLS Echo Reply messages to detect the availability of the LSP. Both Echo Request and Echo Reply messages are transmitted in UDP packets with the port number being 3503. The receive end distinguishes these two types of messages according to the port number. The MPLS Echo Request message carries FEC information to be detected, and is sent along the LSP like other packets with the same FEC. In this manner, the LSP is detected. The MPLS Echo Request message is transmitted to the destination through MPLS, while the MPLS Echo Reply
Issue 01 (2010-06-25)
10-3
10 Ping and Tracert
message is transmitted to the source through IP. To prevent the egress from forwarding the received Echo Request Message to other nodes, the destination address in the IP header of the Echo Request Message is set to 127.0.0.0/8 (the local loopback address), and the TTL value contained in the IP header is set to 1. The device supports the diagnosis of the following link types: LDP LSP
Load balancing of of the head node Detection on the hot-standby tunnel PWE3 ping and tracert VLL in Kompella mode Multi-hop PW Inter-AS PW ping rather than Inter-AS tracert VPLS in Martini mode VPLS in Kompella mode Only the single-hop PW Inter-AS VPLS ping rather than inter-AS tracert
TE tunnel
VLL PW

VPLS PW ping and tracert

L3VPN LSP
LDP LSP Ping and Tracert

A ping or tracert to the egress is initiated from the ingress according to the specified FEC and mask to check the connectivity of the LDP LSP.
If there are multiple LDP LSPs, the LSP to be checked is determined by the next hop address.
TE Tunnel Ping and Tracert

A ping or tracert to the egress is initiated from the ingress to check the connectivity of an existing TE tunnel.
If the TE tunnel is configured with a hot-standby LSP, the connectivity of the hot-standby LSP can be detected.
VLL PW Ping and Tracert

According to the VLL types, the VLL PW ping and tracert can be classified into: PWE3 VLL PW ping In the PWE3 VLL networking, the PW must be configured with a PW template. Then, it can obtain the Virtual Circuit Connectivity Verification (VCCV) capability after VCCV is enabled on the PW template. A PW ping is initiated to check the connectivity of the PW. The PWE3 VLL PW ping can be performed in control word mode or label alert mode.
10-4
Issue 01 (2010-06-25)
10 Ping and Tracert
After receiving the Echo Request message, the PE extracts and sends the FEC to L2VPN to judge whether the message has reached the egress. If yes, an Echo Reply message is sent.
If the reply mode is specified as 4, the label alert function must be enabled on the PW. If the multi-hop PW is detected in label alert mode, the Echo Request message is sent to the PW Swtiching Point (SPE). Then, the control module judges that the SPE is not the egress. After that, the Echo Request message is forwarded and no Echo Reply message is returned.
PWE3 VLL PW tracert In the PWE3 VLL networking, the PW must be configured with a PW template and then it can obtain the VCCV capability after VCCV is enabled on the PW template. A PW tracert is initiated to view information about SPEs and Ps along the path the message that travels from the source to the destination. The PW tracert is used to check the connectivity of the PW and locate faults on the network. The PWE3 VLL PW ping can be performed in control word mode, label alert mode, or TTL mode. The default mode is label alert. The normal mode and the control word mode cannot be configured. The TTL value of the PW Tracert Request message is incremented by 1. Each time the transit node (P node) receives an Echo Request message after the TTL value of the message expires, it sends the Echo Request message to the LSPV module. Then, and sends an Echo Reply message containing information about the next hop of the current node. A PW tracert terminates when:

The PW Tracert Request message reaches the egress. The TTL value of the PW Tracert Request message reaches the upper threshold.
Kompella VLL PW ping and tracert In the Kompella VLL networking:

A VLL PW ping is initiated to check the connectivity of the PW. A VLL PW tracert is initiated to view information about PEs and Ps along the path that the message travels from the source to the destination. The VLL PW tracert is used to check the connectivity of the Layer 2 forwarding link and locate faults on the network.
Different from the PWE3 networking, the Kompella VLL does not need the PW template and supports the control word and label alert modes. By default, the label alert mode is supported.
VPLS PW Ping and Tracert

According to the VPLS types, the VPLS PW ping and tracert can be classified into: Martini VPLS PW ping and tracert The Martini VPLS PW ping and tracert only support the label alert mode. On a Hierarchical Virtual Private LAN Service (HVPLS) network, only a single PW can be detected.
If an optional PW ID is configured and specified, the PW corresponding to the PW ID is detected. If the PW ID is not specified, the PW corresponding to the VSI ID is detected.
Martini VPLS PW ping and tracert are performed according to the following procedures: 1. On the ingress node: A forwarding token is obtained from the L2VPN according to the VSI name, peer address, and PW ID. If no PW ID is specified, the first PW is detected
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 10-5
Issue 01 (2010-06-25)
10 Ping and Tracert
by default. Then, the TunnelInfo is checked in the TNLM according to the forwarding token. After that the downstream information is obtained based on the TunnelInfo, and then the Request message is encapsulated. 2. On the transit node: The Next Hop Label Forwarding Entry (NHLFE) and Incoming Label Map (ILM) are checked according to the incoming label. Then, downstream information is obtained according to the incoming label and index of the inbound interface. On the egress node: The L2VPN judges whether the egress is reached based on information carried in the incoming label and FEC TLV. If yes, a Reply message is returned. Detection results or timeout information is displayed. Kompella VPLS PW ping and tracert Kompella VPLS PW ping and tracert can be performed only in label alert mode. The detailed procedures are as follows: 1. On the ingress node: A forwarding token is obtained from the L2VPN according to the VSI name and remote-site ID. Then, the TunnelInfo is checked in the TNLM according to the forwarding token. After that the downstream information is obtained based on the TunnelInfo, and then the Request message is encapsulated. On the transit node: The NHLFE and ILM are checked according to the incoming label. Then, downstream information is obtained according to the incoming label and index of the inbound interface. On the egress node The L2VPN judges whether the egress is reached based on information carried in the incoming label and FEC TLV. If yes, a Reply message is returned. Detection results or timeout information is displayed.
3.
4.
2.
3.
4.
L3VPN LSP Ping

The L3VPN LSP can be detected only through the L3VPN LSP ping. After a VPN is correctly configured, the PE sends a ping request to the peer PE to check the connectivity of the LSP of the BGP IP VPN. Public network tunnels can be: Equal-cost load balancing LDP LSPs Tunnels of various types, such as a TE tunnel Backup VPN FRR tunnels
L3VPN LSP ping cannot interwork with that of Cisco. If the destination of a ping operation is a CE address, the ping can be successful even when the link between the CE and PE is faulty, because it is the end-to-end link between PEs that is detected.
10.4.4 Service Ping

Service ping is used to detect the consistency of PE configurations on a VPLS network, which can thus protect the normal services. The configuration and deployment of VPLS services are complex and cannot be successful unless some configurations of PE peers on the VPLS network are identical. For example, on a Martini VPLS network, only when VSI-IDs of PE peers are identical can VPLS services be successfully configured.
10-6
Issue 01 (2010-06-25)
10 Ping and Tracert
In the past, the configuration consistency was checked by network maintenance engineers, which is error-prone when there are many VPLS services on the device. As a solution, the vpn-configure ping command is used to enable the VPLS requesting PE to send a probe message asking for the VPLS configuration of its peer on a specified responding PE and wait for a Reply message. Then, the VPLS requesting PE displays the configuration information carried in the Reply message. This can facilitate the consistency check, especially when many VPN services exist on a PE. The VPLS configuration of the peer PE is encapsulated in an MPLS Echo Reply message and sent to the local PE in response to the MPLS Echo Request message from the local PE. In this manner, VPLS configurations of both the local and peer PEs are displayed, which helps locate faults on the VPLS network through comparison. Figure 10-1 Applicable scenario of the service ping
VPN Size CE PE1
IP network PE2 CE
VPN Size
Figure 10-1 shows the process of a service ping operation. 1. The vpn-configure ping command is first run on the local PE1 to search for the local VPLS configuration. Then the vpn-configure ping command sends an MPLS Echo Request message that is constructed according to the obtained information. The timeout period, which is 10s, is counted from the time when the MPLS Echo Request message is successfully sent. Upon receiving the Request message, the peer PE2 parses information carried in the message, such as the PW ID, PW type, and peer address, and then searches for local configurations based on the preceding information. Then, it constructs an MPLS Echo Reply message and returns the Reply message to PE1. If the Reply message is successfully returned, the following information is displayed on the user terminal.

2. 3.
4.
VSI name PW status PW ID VPN type VSI status MTU Number of CEs VC type Label of the outbound interface Label of the inbound interface Description of fields in the result table is as follows:
Issue 01 (2010-06-25)
10-7
10 Ping and Tracert
Table 10-1 Description of fields in the result table Item Result Detail Local VSI description Remote VSI description PW State VSI Name: VSI ID VPN Type Admin State Oper State VSI MTU CE Count Actual IP Addr Expected Peer IP SPE PW-ID VC-Type Egress Lable Ingress Lable LSP Tunnel Used Description Actual results Description of the local VSI Description of the remote VSI Status of a PW Name of a VSI ID of a VSI Type of a VPN VSI administration status VSI operation status MTU of a VSI Number of CEs Actual IP address Expected peer IP address Whether it is a SPE ID of a PW Type of a VC Egress label Ingress label Whether the probe message is encapusulated in LSP mode
10.4.5 VPLS MAC Diagnosis

VPLS MAC diagnostic tools provide a mechanism to check the MAC address learning capability of the specified VSI in a VPLS through extended MPLS Echo packets. The device supports the diagnosis of the following link types: VPLS in Martini mode Currently, the HVPLS and inter-AS Option C are supported. VPLS in Kompella mode Currently, the interface-AS Option C is supported. MAC address learning is important to the VPLS and determines the establishment and correctness of the forwarding plane in the VPLS domain. VPLS MAC diagnostic tools can detect the MAC address learning capability of a VSI.
10-8
Issue 01 (2010-06-25)
10 Ping and Tracert
MAC diagnostic tools are mainly used to detect whether the MAC address capability of the specified VSI on a VPLS network is normal, which helps to determine whether the forwarding plane can be established normally. In the VPLS networking, you can use MAC diagnostic tools to detect whether the MAC address learning capability of a device is normal when the abnormality of the data forwarding plane is suspected to be caused by the fault in MAC address learning. MAC diagnostic tools can check the MAC address learning capability of the specified VSI of the local PE, and detect the MAC address capability of all the PEs in the specified VSI domain on a VPLS network by using the flood option. Two methods are available to use MAC diagnostic tools: populate operation: When using the populate command to initiate a test, you need to specify the VSI and OAM MAC addresses that are applied for the test to detect MAC address learning capability. In this manner, MAC address learning is triggered on the local device. If the flood option is specified, an MPLS Echo Request packet with the reply mode being no-relay is broadcast in the specified VSI on a VPLS network. After receiving the packet, the remote PE triggers MAC address learning. In the HVPLS networking, after receiving the packet and triggering MAC address learning, the remote SPE continues to forward the packet until the packet reaches the edge device. After the preceding operations, you can check whether MAC address learning by viewing the MAC address table of each device You can set the aging time for OAM MAC addresses so that they can be automatically deleted after the aging time. purge operation: Using the purge command can delete the OAM MAC addresses populated in the specified VSI. The flood option is required when you need to delete the OAM MAC addresses learned by all the PEs in the specified VSI. Configuring the register function of OAM MAC addresses When the purge command with the register option is used, the local device does not allow other PEs to populate this OAM MAC address to the specified VSI. When both register and flood are specified, in the specified VSI, this OAM MAC address can be used by only the PE that initiates the register operation. Canceling the register function of OAM MAC addresses If the purge operation is performed on the specified OAM MAC address of the PE that initiates the register operation, the register function is cancelled on the local device. If the flood option is specified, the register operation initiated by the local device is cancelled in the specified VSI domain on the VPLS network. If the populate operation is performed on the specified OAM MAC address of the PE that initiates the register operation, the register function is cancelled. If the flood option is specified, the register operation initiated by the local device is also cancelled in the specified VSI domain on the VPLS network.
10.5 Impact
10.5.1 On System Performance 10.5.2 On Other Features 10.5.3 Our Advantages
Issue 01 (2010-06-25)
10-9
10 Ping and Tracert
10.5.4 Defects
10.5.1 On System Performance

For MAC diagnosis: At present, each device can be configured with only a maximum of 100 OAM MAC entries.
10.5.2 On Other Features 10.5.3 Our Advantages 10.5.4 Defects

Abbreviations
Abbreviations MPLS LSP LDP TE VLL L3VPN VPLS HVPLS CE PE UPE SPE PW Full Spelling Multiprotocol Label Switch Label Switched Path Label Distribution Protocol Traffic Engineering Virtual Leased Line Layer3 Virtual Private Network Virtual Private LAN Service Hierarchical Virtual Private LAN Service Custom Edge Provider Edge Underlayer PE Superstratum PE Pseudo-Wires
10-10
Issue 01 (2010-06-25)
11 LLDP
11
About This Chapter
11.1 Introduction to LLDP 11.2 References 11.3 Availability 11.4 Principles 11.5 Applications 11.6 Impact 11.7 Terms and Abbreviations
LLDP
11.1 Introduction to LLDP

Definition
The Link Layer Discovery Protocol (LLDP) is a Layer 2 Discovery (L2D) protocol defined in the IEEE 802.1ab standard. The LLDP protocol defines that each interface has a standard Simple Network Management Protocol (SNMP) Management Information Base (MIB), which stores local status information. A device can send local status information and updates to its neighbors. The neighbors store the received information in the standard SNMP MIB. The Network Management System (NMS) can search the MIB for link layer information.
Purpose
At present, the Ethernet technology is widely used on the Local Area Network (LAN) and Metropolitan Area Network (MAN). The increasing expansion of the network scale requires enhanced capabilities of Ethernet network management. For example, Ethernet network management should address issues such as automatically obtaining the topology of interconnected devices and solving conflicts in configurations on different devices. Recently, the NMS adopts the automated discovery function to trace topology changes. Most NMSs can only analyze the network layer and higher. The information obtained by these NMSs through the analysis concerns only basic events such as adding or deleting devices. The NMSs cannot obtain information about which interfaces on a device are used to connect to
Issue 01 (2010-06-25)
11-1
11 LLDP
other devices. That is, the NMSs cannot locate a device or describe the current network topology. The L2D protocol is introduced to address this problem. An L2D protocol can precisely discover which interfaces reside on devices and which interfaces are used to connect to other devices. In addition, an L2D protocol can discover the paths between the client, router, application server, and network server.
Benefits
Benefits brought to operators With the LLDP technology, the NMS can rapidly obtain the Layer 2 network topology and topology changes when the network scale expands.
11.2 References
The following table lists the references of this document. Document IEEE 802.1ab Description IEEE Standard for Local and metropolitan area networks: Station and Media Access Control Connectivity Discovery Remarks
11.3 Availability
In LLDP, at least two CX600s and the NMS are involved. The CX600 can send local status information and updates to its neighbors. The NMS collects topology information from the MIB on the CX600 and analyzes the current link layer topology.
License Support
Not involved.
Version Support
11-2
Issue 01 (2010-06-25)
11 LLDP
Feature Dependency
Not involved.
Hardware Support
Boards supporting LLDP include the LPUF-20/21 and LPUF-40. Interfaces supporting LLDP include Ethernet physical interfaces of Fast Ethernet (FE), Gigabit Ethernet (GE), and 10 GE interfaces.
11.4 Principles
11.4.1 Basic Principles 11.4.2 LLDP Parameters 11.4.3 LLDP Implementation on Devices
11.4.1 Basic Principles

The LLDP protocol defines that each interface has a standard SNMP MIB. An SNMP MIB stores local status information including the chassis ID, interface ID, and management address. A device can send its status information and updates to its neighbors as required. Neighbors store the received information in the standard SNMP MIB so that the NMS can extract the network topology information. The NMS collects topology information from MIBs of all the managed devices and then determines the current link layer topology.
LLDP Topology Discovery Between Directly Connected Neighbors

Figure 11-1 shows the topology discovery process of LLDP. Figure 11-1 LLDP topology discovery between directly connected neighbors
NMS
SN MP
MP SN
LLDPDU
CX-A SNMP Packets
CX-B LLDPDU
Issue 01 (2010-06-25)
11-3
11 LLDP
When LLDP is enabled on both CX- A and CX- B, the LLDP topology discovery process works as follows: 1. 2. 3. 4. 5. CX- A sends its status information to CX- B by using LLDP frames (namely, LLDPDUs as shown in Figure 11-1). CX- B analyzes the received LLDP frames and stores the analysis result in its LLDP remote system MIB so that the NMS can extract the network topology information. CX- B also sends its status information to CX- A. CX- A analyzes the received LLDP frames and stores the analysis result in its LLDP remote system MIB so that the NMS can extract the network topology information. The NMS extracts local information and neighbor information from CX- A and CX- B. The NMS then analyzes the information and determines the network topology.
LLDP Topology Discovery Between Indirectly Connected Neighbors

When two neighbors are connected through an intermediate device, the LLDP topology discovery process is as shown in Figure 11-2. Figure 11-2 LLDP topology discovery between indirectly connected neighbors
NMS
SNMP
SNMP
ISP Network Tunnel
LLDPDU CX- A
LLDPDU CX- B
LLDPDU SNMP Packets
The LLDP topology discovery process is as follows: 1. CX- A sends LLDP multicast packets with the frame type being 0x88CC and the MAC address being 01-80-C2-00-00-0E. The LLDP frames are transparently transmitted to CX- B through a tunnel on the Internet Service Provider (ISP) network.
11-4
Issue 01 (2010-06-25)
11 LLDP
2.
After receiving the LLDP frames, CX- B determines that these LLDP frames can be processed based on the frame type. CX- B then further analyzes the LLDP frames and stores the analysis result in its LLDP remote system MIB so that the NMS can extract the network topology information. CX- B sends LLDP frames in the same manner as CX- A. CX- A also analyzes the LLDP frames sent from CX- B and stores the analysis result in its LLDP remote system MIB so that the NMS can obtain the network topology information. The NMS locates CX- A and CX- B based on the management address and obtains the topology information for analysis.
To implement LLDP topology discovery between indirectly connected neighbors, a tunnel must have been established between CX- A and CX- B on the ISP network for transparent transmission of LLDP frames.
3.
4.
11.4.2 LLDP Parameters

In the process of topology discovery, adjusting LLDP parameters properly can help discover the topology in time and save resources. LLDP parameters include: Interval for sending LLDP frames Delay in sending LLDP frames Multiplier of the hold time of local information on neighbors Delay in re-enabling LLDP on an interface Delay in sending LLDP traps
Interval for Sending LLDP Frames

When the device status keeps unchanged, the device sends LLDP frames to neighbors at an interval. After the interval for sending LLDP frames is set on a device, all LLDP-enabled interfaces on the device send LLDP frames to neighbors at this interval. The time at which these interfaces begin to send LLDP frames can be different. You can adjust the speed for discovering the network topology by adjusting the interval for sending LLDP frames. The interval for sending LLDP frames should be adjusted according to the network load: The larger the value, the lower the frequency of exchanging LLDP frames. Therefore, system resources are saved. If the value is too large, a device does not notify its status to neighbors in time, in which case the NMS cannot discover network topology changes in time. The smaller the value, the higher the frequency of sending local status information to neighbors. This helps the NMS to discover network topology changes in time. If the value is too small, LLDP frames are exchanged too frequently, in which case the system load is increased and resources are wasted.
Delay in Sending LLDP Frames

Delay in sending LLDP frames refers to the minimum delay between successive LLDP frame transmissions. After the delay in sending LLDP frames is set on a device, all LLDP-enabled interfaces on the device take this value as the minimum delay to send LLDP frames to neighbors. The time at which these interfaces begin to send LLDP frames can be different.
Issue 01 (2010-06-25)
11-5
11 LLDP
When the status of a device changes frequently, you can increase the delay to reduce the frequency of sending LLDP frames to neighbors. The delay in sending LLDP frames should be adjusted according to the network load: The larger the value, the lower the frequency of exchanging LLDP frames. Therefore, system resources are saved. If the value is too large, a device does not notify its status to neighbors in time, in which case the NMS cannot discover network topology changes in time. The smaller the value, the higher the frequency of sending local status information to neighbors. This helps the NMS to discover network topology changes in time. If the value is too small, LLDP frames are exchanged too frequently, in which case the system load is increased and resources are wasted. The interval for sending LLDP frames must be equal to or greater than four times the delay in sending LLDP frames. The relationship between the interval for sending LLDP frames and the delay in sending LLDP frames is shown in Figure 11-3. Figure 11-3 Relationship between the interval for sending LLDP frames and the delay in sending LLDP frames
An LLDP frame is sent and the Interval timer is triggered
A
Does local status information change within the interval? No
Yes LLDP frames are sent and the Interval timer and Delete timer are triggered again
The Delete timer times out and check whether local status information changes
Yes
No
The Interval timer continues until it times out
int: is short for interval, indicating the interval for sending LLDP frames. del: is short for delay, indicating the delay in sending LLDP frames. A, B, C, and D refer to different time points at which LLDP frames are sent.
Figure 11-4 shows the process of sending LLDP frames at different time points.
11-6
Issue 01 (2010-06-25)
11 LLDP
Figure 11-4 Sending LLDP frames at different time points

A
interval
interval
B
delay
C
interval
delay
D
interval
LLDP frames sent after the interval times out
LLDP frames sent after local status information changes
A: The first LLDP frame is sent. B: When local status information does not change within the interval, LLDP frames are sent after the interval times out. C: When local status information changes within the interval, LLDP frames are sent and the Interval timer and Delay timer are triggered. D: After the Interval timer and Delay timer are triggered, if local status information changes within the delay period, LLDP frames are sent again after the delay times out, and the Interval timer and Delay timer are triggered again.
Multiplier of the Hold Time of Local Information on Neighbors

The multiplier of the hold time of local information on neighbors, that is, the hold multiplier, is used to calculate the hold time of LLDP frames on neighbors. After receiving LLDP frames, neighbors use the hold time to update the aging time of device information from the sender. The formula for calculating the hold multiplier is as follows: TTL = Min [65535, (interval * hold multiplier)] Time to Live (TTL): specifies the hold time of local information on neighbors. The value is the smaller one between 65535 and the value of interval x hold multiplier. interval: specifies the interval for sending LLDP frames to neighbors. hold multiplier: specifies the multiplier of the hold time of local information on neighbors.
Delay in Re-enabling LLDP on an Interface

The delay in re-enabling LLDP on an interface refers to the delay in re-enabling LLDP from the disabled state on an interface. If the LLDP status of an interface is changed frequently, you can set the delay in re-enabling LLDP on the interface to suppress the topology flapping of neighbors.
Issue 01 (2010-06-25)
11-7
11 LLDP
Delay in Sending LLDP Traps

The delay in sending LLDP traps is the minimum delay for a device to send LLDP traps to the NMS when the LLDP trap function is enabled and information in the LLDP remote system MIB frequently changes. The delay in sending LLDP traps is applicable only to the traps generated in the following scenarios: Adding neighbors Deleting neighbors Aging neighbors Discarding neighbors After the delay in sending LLDP traps is set on a device, all LLDP-enabled interfaces on the device take this value as the minimum delay to send the traps indicating neighbor information changes to neighbors. The time at which these interfaces begin to send the traps can be different. When neighbor information changes frequently, you can increase the delay to reduce the frequency of sending traps to the NMS, thus suppressing the topology flapping.
11.4.3 LLDP Implementation on Devices

Operation Mode
The CX600 supports duplex operation mode of LLDP. That is, the CX600 can send and receive LLDP frames at the same time.
Enabling LLDP Globally

Enabling LLDP on the CX600 allows neighbors to send status information to each other. LLDP must be globally enabled on a device before any LLDP-related operations, such as enabling or disabling LLDP on an interface, configuring LLDP parameters, and setting an LLDP management address, are performed.
Enabling LLDP on an Interface

After LLDP is enabled globally on the CX600, all Ethernet physical interfaces are enabled with LLDP. You can disable and then re-enable LLDP on an interface as required.
Setting an LLDP Management Address

Setting an LLDP management address enables the NMS to uniquely identify devices and manage devices. LLDP must be globally enabled on the CX600 before an LLDP management address is set. The LLDP management address must be a unicast IP address that already exists on the device and is not reserved by the system. If a specified IP address is an invalid IP address or no LLDP management address is configured, the system automatically selects an IP address on the device as the LLDP management address. A loopback interface address (the smallest address) is preferentially selected as the LLDP management address, or, if loopback interface addresses are unavailable, a VLANIF interface address is selected, or an IP address of other types (smallest IP address that is not configured on the interface board) is selected if VLANIF interface addresses are unavailable. If no LLDP management address is selected from the preceding address, bridge MAC address of the system is used as the LLDP management address.
11-8
Issue 01 (2010-06-25)
11 LLDP
Enabling the LLDP Trap Function

After the LLDP trap function is enabled on a device, the device can send traps to instruct the NMS to update topology information in the following situations: LLDP is globally enabled or disabled on the device. The LLDP management address is changed. Neighbor information changes.
11.5 Applications
Application of LLDP on the Carrier's Network
As shown in Figure 11-5, there are available links between CX- A and CX- B, and between CX- A and CX- C. Available links also exist between CX- A and the NMS, and between CXC and the NMS. LLDP is configured on CX- A, CX- B, and CX- C, and CX- A, CX- B, and CX- C exchange LLDP frames through available links to obtain the status of each other. In addition, the NMS can locate CX- A and CX- C based on the LLDP management address to discover the topology.
Issue 01 (2010-06-25)
11-9
11 LLDP
Figure 11-5 Networking diagram of LLDP configurations on the network where an interface has multiple neighbors
NMS
SNMP
LLDPDU CX-D
D LL PD U D LL
SNMP
CX-F
PD
10.10.10.1 CX-A CX-B SNMP packets LLDPDU
LL D
Router E
LLDPDU
U PD
10.10.10.2
10.10.10.3 CX-C
Interfaces enables with LLDP NMS Network Management System
11.6 Impact
11.6.1 On the System Performance 11.6.2 On Other Features 11.6.3 Defects

None.

None.
11-10
Issue 01 (2010-06-25)
11 LLDP
11.6.3 Defects
None.

Abbreviations
Abbreviation LLDP LLDPDU MIB SNMP Full Spelling Link Layer Discovery Protocol LLDP data unit Management Information Base Simple Network Management Protocol
Issue 01 (2010-06-25)
11-11
12 Fault Management
12
About This Chapter
12.1 Introduction to Basic Configuration 12.2 References 12.3 Principles 12.4 Impact 12.5 Terms and Abbreviations
Fault Management
12.1 Introduction to Basic Configuration

Definition
The Fault Management (FM) is used to dynamically manage and report alarms generated on devices in a centralized manner.
Purpose
With the rapid growth in network scales and complexity, more and more network configurations and applied features are required. When a module on a device is faulty, a great number of alarms may be generated on one or multiple devices. The alarms, however, may be lost during sending to the network management device because of limited capability of handling alarms on the devices or the network management system (NMS). As a result, certain needed alarms cannot be displayed, which inconveniences network management. In the FM, alarm classification and alarm buffer are introduced. Alarm classification: Alarms can be classified into six levels. (Default alarm classification is enabled in the system, and you can modify alarm classification.) You can use alarm classification to display the concerned alarms and shield the alarms that are not needed from being displayed. Alarm buffer: Alarms or events of specified types can be saved in the devices. Default types are set in the system, and you can modify alarm types. The alarms saved on the device can be displayed on the NMS through MIB interfaces. In addition, the device
Issue 01 (2010-06-25)
12-1
12 Fault Management
provides the active alarm function. The NMS synchronizes the alarms of the current activities in real time.
12.2 References
None.
12.3 Principles
12.3.1 Fault Management
12.3.1 Fault Management

Fault management includes the following functions: A device reports alarms according to different alarm levels. The NMS obtains the time when the alarm is reported. The NMS obtains lost events or alarms. The NMS synchronizes current active alarms in real time. A device suppresses alarms.
Reporting Alarms According to Different Alarm Levels

The system sets an initial level and an initial type for each alarm, which can be modified by a user. In X.733, alarms are classified into six levels according to the severity level and urgency level, as shown in Table 12-1. The more urgent an alarm is, the smaller the alarm level is. Critical indicates that the alarm level is 1; whereas Cleared indicates that the alarm level is 6. Table 12-1 Mappings between alarm levels and severity levels Alarm Level 1 Severity Level Critical Description The Critical severity level indicates that a service affecting condition has occurred and an immediate corrective action is required. Such a severity can be reported, for example, when a managed object becomes totally out of service and its capability must be restored. The Major severity level indicates that a service affecting condition has developed and an urgent corrective action is required. Such a severity can be reported, for example, when there is a severe degradation in the capability of the managed object and its full capability must be restored.
Major
12-2
Issue 01 (2010-06-25)
12 Fault Management
Alarm Level 3
Severity Level Minor
Description The Minor severity level indicates the existence of a non-service affecting fault condition and that corrective action should be taken in order to prevent a more serious (for example, service affecting) fault. Such a severity can be reported, for example, when the detected alarm condition is not currently degrading the capacity of the managed object. The Warning severity level indicates the detection of a potential or impending service affecting fault, before any significant effects have been felt. Action should be taken to further diagnose (if necessary) and correct the problem in order to prevent it from becoming a more serious service affecting fault. The Indeterminate severity level indicates that the severity level cannot be determined. The Cleared severity level indicates the clearing of one or more previously reported alarms. This alarm clears all alarms for this managed object that have the same Alarm type, Probable cause and Specific problems (if given). Multiple associated notifications may be cleared by using the Correlated notifications parameter.
Warning
5 6
Indeterminate Cleared
Alarms can be classified into four types shown as follows: Alarm Resume-alarm Critical event Event A user can configure the level and type of an alarm. If the user focuses on certain types of alarms, he or she can set these types of alarms to be of the highest level and configure filtering conditions. In this manner, the system reports only these types of alarms to the NMS. The user can change the type of an alarm and determine whether to store the alarm on the device. Only the alarms of the three types, namely, alarm, resume-alarm, and critical event, can be stored on the device.
Obtaining the Time When the Alarm Is Reported

According to the Simple Network Management Protocol (SNMP), an alarm carrying the generation time is reported to the NMS. The generation time refers to a relative time from when the system is started to when the alarm is generated. The user cannot view the UTC time of alarm generation. The device can provide the time of obtaining the reported alarm for the NMS.
Issue 01 (2010-06-25)
12-3
12 Fault Management
Before sending an alarm, the system determines whether the alarm is destined for Huawei's NMS. If so, a parameter DateAndTime is added to the alarm binding table to store the alarm generation time. The NMS then obtains the alarm generation time by parsing this parameter.
This function is applicable to only Huawei's NMS. For a third-party network management network system, the alarm binding table does not contain the parameter DateAndTime. Therefore, this function is not supported.
Obtaining Lost Events or Alarms

The alarms of the three types, namely, alarm, resume-alarm, and critical event, can be stored on a device. The alarms of the two types, namely, alarm and resume-alarm, are stored in the alarm queue; whereas the alarms of the type, critical event, are stored in the event queue. After an alarm is sent to the FM module, the system determines whether the alarm needs to be saved. If it needs to be saved, the system generates a copy of the alarm binding table and store the copy in the alarm queue or the event queue according to the alarm type. The system also provides MIB interfaces, through which users can obtain alarms from a device.
The alarm binding table obtained by the NMS is coded according to the type, length, and value (TLV); the alarms obtained by the NMS through the MIB are coded messages. The binding table stored on the device is of Huawei's private data structure. Therefore, a third-party NMS may not be able to correctly parse the alarms.
Synchronizing Current Active Alarms in Real Time

When a user receives an resume-alarm, the system matches the resume-alarm with the alarm in the alarm queue. If the matching is successful, the system, deletes the alarm and the resume-alarm from the active alarm queue. No matter whether the alarm is matched, the system does not add the resume-alarm to the active alarm queue. The procedure for alarm matching is described as follows: 1. 2. 3. A user receives an alarm and adds it to the active alarm queue. The user receives a resume-alarm. Then, the system obtains the matching information and thus obtains the matched alarm and related matching rules. The system searches the name of the alarm to be matched. If the alarm exists, the system select the matching rules related to this alarm. If the matching is successful, the system deletes this alarm and refreshes the alarms in the active alarm queue.
12.4 Impact
12.4.1 On the System Performance 12.4.2 On Other Features 12.4.3 Our Advantages 12.4.4 Defects

If the statistics are too frequent, the system performance will be decreased.
12-4
Issue 01 (2010-06-25)
12 Fault Management

None.
12.4.3 Our Advantages

None.
12.4.4 Defects
None.

Terms
None.
Abbreviation
Abbreviation FM Full Spelling Fault Management
Issue 01 (2010-06-25)
12-5

CX600

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

CX600

Загружено:

Авторское право:

Доступные форматы

HUAWEI CX600 Metro Services Platform V600R002

Feature Description - System Management

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2010. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

About This Document

About This Document

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

About This Document

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Changes in Issue 01 (2010-06-25)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

3 RMON and RMON2 ..................................................................................................................3-1

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

8 VLL NetStream ...........................................................................................................................8-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

10 Ping and Tracert .....................................................................................................................10-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

12 Fault Management .................................................................................................................12-1

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

1.4.5 Suppression of the Log Processing Rate 1.4.6 Binary Log

1.4.1 Information Classification

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Time to send logs

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Field %% dd AAA B CCC (L)

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Output format of traps Figure 1-2 Output format of traps

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

Debug information Protocol debug switch

1 Termina display switch

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

HUAWEI CX600 Metro Services Platform Feature Description - System Management

1.4.2 Information Hierarchy

Severity Levels of Information