H3C S7500E Series Ethernet Switches. Network Management and Monitoring. Configuration Guide. Hangzhou H3C Technologies Co., Ltd.

Transcription

1 H3C S7500E Series Ethernet Switches Network Management and Monitoring Configuration Guide Hangzhou H3C Technologies Co., Ltd. Document Version: C-1.01 Product Version: Release 6605 and Later

2 Copyright , Hangzhou H3C Technologies Co., Ltd. and its licensors All Rights Reserved No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Hangzhou H3C Technologies Co., Ltd. Trademarks H3C,, Aolynk,, H 3 Care,, TOP G,, IRF, NetPilot, Neocean, NeoVTL, SecPro, SecPoint, SecEngine, SecPath, Comware, Secware, Storware, NQA, VVG, V 2 G, V n G, PSPT, XGbus, N-Bus, TiGem, InnoVision and HUASAN are trademarks of Hangzhou H3C Technologies Co., Ltd. All other trademarks that may be mentioned in this manual are the property of their respective owners. Notice 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.

3 Preface The H3C S7500E documentation set includes 12 configuration guides, which describe the software features for the H3C S7500E Series Ethernet Switches and guide you through the software configuration procedures. These configuration guides also provide configuration examples to help you apply software features to different network scenarios. The Network Management and Monitoring Configuration Guide describes network management and monitoring fundamentals and configuration. It describes how to view the system information, sample packets, assess the network performance, synchronize time for all devices with clocks in your network, supply power for the attached devices by using PoE, and use the ping, tracert, and debug commands to check and debug the current network connectivity. This preface includes: Audience Document Organization Conventions About the H3C S7500E Documentation Set Obtaining Documentation Documentation Feedback Audience This documentation is intended for: Network planners Field technical support and servicing engineers Network administrators working with the S7500E series Document Organization The Network Management and Monitoring Configuration Guide comprises these parts: System Maintenance and Debugging NQA Configuration NTP Configuration IPC Configuration PoE Configuration SNMP Configuration MIB Style Configuration RMON Configuration Port Mirroring Configuration Traffic Mirroring Configuration sflow Configuration Information Center Configuration Conventions This section describes the conventions used in this documentation set. Command conventions Boldface Convention Description Bold text represents commands and keywords that you enter literally as shown.

4 Convention Description italic [ ] { x y... } [ x y... ] { x y... } * [ x y... ] * &<1-n> Italic text represents arguments that you replace with actual values. Square brackets enclose syntax choices (keywords or arguments) that are optional. Braces enclose a set of required syntax choices separated by vertical bars, from which you select one. Square brackets enclose a set of optional syntax choices separated by vertical bars, from which you select one or none. Asterisk marked braces enclose a set of required syntax choices separated by vertical bars, from which you select at least one. Asterisk marked square brackets enclose optional syntax choices separated by vertical bars, from which you may select multiple choices or none. The argument or keyword and argument combination before the ampersand (&) sign can be entered 1 to n times. # A line that starts with a pound (#) sign is comments. Symbols Convention Description Means reader be extremely careful. Improper operation may cause bodily injury. Means reader be careful. Improper operation may cause data loss or damage to equipment. Means a complementary description. About the H3C S7500E Documentation Set The H3C S7500E documentation set includes: Category Documents Purposes Product description and specifications Marketing brochures Technology white papers Card datasheets Describe product specifications and benefits. Provide an in-depth description of software features and technologies. Describe card specifications, features, and standards.

5 Category Documents Purposes Hardware installation Software configuration Operations and maintenance Power configuration Installation guide H3C N68 Cabinet Installation and Remodel Introduction H3C Pluggable SFP [SFP+][XFP] Transceiver Modules Installation Guide H3C Mid-Range Series Ethernet Switches Pluggable Modules Manual H3C PoE DIMM Module Installation Guide Single PoE DIMM Module Installation Guide Configuration guides Command references Configuration examples Release notes H3C PSR320-A[PSR320-D] Power Module User Manual H3C PSR650-A[PSR650-D] Power Module User Manual H3C PSR1400-A[PSR1400-D] Power Module User Manual H3C PSR2800-ACV Power Module User Manual H3C PSR6000-ACV Power Module User Manual H3C PWR-SPA Power Module Adapter User Manual H3C S7500E Power Configuration Guide Provides a complete guide to hardware installation and hardware specifications. Guides you through installing and remodeling H3C N68 cabinets. Guides you through installing SFP/SFP+/XFP transceiver modules. Describes the hot-swappable modules available for the Mid-Range Series Ethernet Switches, their external views, and specifications. Describes how to install the DIMM (LSBM1POEDIMMH) for PoE master and slave power management. Describes how to install the 24-port DIMM (LSQM1POEDIMMS0) for PoE power management. Describe software features and configuration procedures. Provide a quick reference to all available commands. Describe typical network scenarios and provide configuration examples and instructions. Provide information about the product release, including the version history, hardware and software compatibility matrix, version upgrade information, technical support information, and software upgrading. Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR320-A/PSR320-D power module. Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR650-A/PSR650-D power module. Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR1400-A/PSR1400-D power module. Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR2800-ACV power module. Describes the appearance, specifications, LEDs, and installation and removal of the H3C PSR6000-ACV power module. Describes the functions and appearance of the H3C PWR-SPA power module adapter, and how to use it with the PSR650 power module. Guides you to select power modules in various cases.

6 Category Documents Purposes cards Card manuals The S7500E series Ethernet switches support various card models. Each model is provided with a card manual that describes: The type, number, and transmission rate of interfaces Applicable switches of the card software version Pluggable modules supported by the card Obtaining Documentation You can access the most up-to-date H3C product documentation on the World Wide Web at Click the links on the top navigation bar to obtain different categories of product documentation: [Technical Support & Documents > Technical Documents] Provides hardware installation, and software feature configuration and maintenance documentation. [Products & Solutions] Provides information about products and technologies, as well as solutions. [Technical Support & Documents > Software Download] Provides the documentation released with the software version. Documentation Feedback You can your comments about product documentation to info@h3c.com. We appreciate your comments.

7 Table of Contents 1 System Maintaining and Debugging 1-1 System Maintaining and Debugging 1-1 Ping 1-1 Introduction 1-1 Configuring Ping 1-1 Ping Configuration Example 1-2 Tracert 1-4 Introduction 1-4 Configuring Tracert 1-4 System Debugging 1-5 Introduction to System Debugging 1-5 Configuring System Debugging 1-6 Ping and Tracert Configuration Example NQA Configuration 2-1 NQA Overview 2-1 Introduction to NQA 2-1 Features of NQA 2-1 Basic Concepts of NQA 2-3 NQA Test Operation 2-4 NQA Configuration Task List 2-4 Configuring the NQA Server 2-5 Enabling the NQA Client 2-5 Creating an NQA Test Group 2-6 Configuring an NQA Test Group 2-6 Configuring an ICMP Echo Test 2-6 Configuring a DHCP Test 2-8 Configuring a DNS Test 2-8 Configuring an FTP Test 2-9 Configuring an HTTP Test 2-11 Configuring a UDP Jitter Test 2-12 Configuring an SNMP Test 2-14 Configuring a TCP Test 2-15 Configuring a UDP Echo Test 2-16 Configuring a Voice Test 2-18 Configuring a DLSw Test 2-21 Configuring the Collaboration Function 2-21 Configuring Trap Delivery 2-22 Configuring the NQA Statistics Function 2-23 Configuring the History Records Saving Function 2-24 Configuring Parameters Common to an NQA Test Group 2-25 Scheduling an NQA Test Group 2-26 i

8 Displaying and Maintaining NQA 2-27 NQA Configuration Examples 2-28 ICMP Echo Test Configuration Example 2-28 DHCP Test Configuration Example 2-29 DNS Test Configuration Example 2-30 FTP Test Configuration Example 2-31 HTTP Test Configuration Example 2-32 UDP Jitter Test Configuration Example 2-33 SNMP Test Configuration Example 2-36 TCP Test Configuration Example 2-37 UDP Echo Test Configuration Example 2-38 Voice Test Configuration Example 2-39 DLSw Test Configuration Example 2-42 NQA Collaboration Configuration Example NTP Configuration 3-1 NTP Overview 3-1 Applications of NTP 3-1 Advantages of NTP 3-2 How NTP Works 3-2 NTP Message Format 3-3 Operation Modes of NTP 3-5 Multiple Instances of NTP 3-7 NTP Configuration Task List 3-8 Configuring the Operation Modes of NTP 3-8 Configuring NTP Client/Server Mode 3-9 Configuring the NTP Symmetric Peers Mode 3-10 Configuring NTP Broadcast Mode 3-11 Configuring NTP Multicast Mode 3-12 Configuring the Local Clock as a Reference Source 3-13 Configuring Parameters of NTP 3-14 Specifying the Source Interface for NTP Messages 3-14 Disabling an Interface from Receiving NTP Messages 3-15 Configuring the Maximum Number of Dynamic Sessions Allowed 3-15 Configuring Access-Control Rights 3-16 Configuration Prerequisites 3-16 Configuration Procedure 3-16 Configuring NTP Authentication 3-17 Configuration Prerequisites 3-17 Configuration Procedure 3-17 Displaying and Maintaining NTP 3-19 NTP Configuration Examples 3-20 Configuring NTP Client/Server Mode 3-20 Configuring the NTP Symmetric Mode 3-21 Configuring NTP Broadcast Mode 3-22 Configuring NTP Multicast Mode 3-24 ii

9 Configuring NTP Client/Server Mode with Authentication 3-27 Configuring NTP Broadcast Mode with Authentication 3-28 Configuring MPLS VPN Time Synchronization in Client/server Mode 3-30 Configuring MPLS VPN Time Synchronization in Symmetric Peers Mode IPC Configuration 4-1 IPC Overview 4-1 Introduction to IPC 4-1 Enabling IPC Performance Statistics 4-2 Displaying and Maintaining IPC PoE Configuration 5-1 PoE Overview 5-1 Introduction to PoE 5-1 Protocol Specification 5-3 PoE Configuration Task List 5-3 Enabling PoE 5-4 Enabling PoE for a PSE 5-4 Enabling PoE for a PoE Interface 5-5 Detecting PDs 5-6 Enabling the PSE to Detect Nonstandard PDs 5-6 Configuring the PoE Power 5-7 Configuring the Maximum PoE Power 5-7 Configuring the Maximum PSE Power 5-8 Configuring the Maximum PoE Interface Power 5-8 Configuring PoE Power Management 5-8 Configuring PSE Power Management 5-9 Configuring PoE Interface Power Management 5-10 Configuring the PoE Monitoring Function 5-11 Configuring PoE Power Supply Monitoring 5-11 Configuring PSE Power Monitoring 5-12 Monitoring PD 5-13 Configuring PoE Interface through PoE Profile 5-13 Configuring PoE Profile 5-13 Applying PoE Profile 5-14 Upgrading PSE Processing Software in Service 5-15 Displaying and Maintaining PoE 5-16 PoE Configuration Example 5-18 Troubleshooting PoE SNMP Configuration 6-1 SNMP Overview 6-1 SNMP Mechanism 6-1 SNMP Protocol Version 6-2 MIB Overview 6-2 SNMP Configuration 6-3 Configuring SNMP Logging 6-6 Introduction to SNMP Logging 6-6 iii

10 Enabling SNMP Logging 6-6 Configuring SNMP Trap 6-7 Enabling the Trap Function 6-7 Configuring Trap Parameters 6-8 Displaying and Maintaining SNMP 6-10 SNMPv1/SNMPv2c Configuration Example 6-11 SNMPv3 Configuration Example 6-12 SNMP Logging Configuration Example MIB Style Configuration 7-1 Setting the MIB Style 7-1 Displaying and Maintaining MIB RMON Configuration 8-1 RMON Overview 8-1 Introduction 8-1 Working Mechanism 8-2 RMON Groups 8-2 Configuring the RMON Statistics Function 8-4 Configuring the RMON Ethernet Statistics Function 8-4 Configuring the RMON History Statistics Function 8-4 Configuring the RMON Alarm Function 8-5 Configuration Prerequisites 8-5 Configuration Procedure 8-5 Displaying and Maintaining RMON 8-7 Ethernet Statistics Group Configuration Example 8-7 History Group Configuration Example 8-8 Alarm Group Configuration Example 8-10 Private Alarm Group Configuration Example Port Mirroring Configuration 9-1 Introduction to Port Mirroring 9-1 Classification of Port Mirroring 9-1 Implementing Port Mirroring 9-1 Configuring Local Port Mirroring 9-4 Local Port Mirroring Configuration Task List 9-4 Creating a Local Mirroring Group 9-4 Configuring Mirroring Ports for the Local Mirroring Group 9-5 Configuring the Monitor Port for the Local Mirroring Group 9-6 Configuring Layer 2 Remote Port Mirroring 9-7 Layer 2 Remote Port Mirroring Configuration Task List 9-7 Configuration Prerequisites 9-8 Configuring a Remote Source Mirroring Group (on the Source Device) 9-8 Configuring a Remote Destination Mirroring Group (on the Destination Device) 9-10 Configuring Layer 3 Remote Port Mirroring 9-13 Layer 3 Remote Port Mirroring Configuration Task List 9-13 Configuration Prerequisites 9-13 Configuring Local Mirroring Groups 9-13 iv

11 Configuring Mirroring Ports for a Local Mirroring Group 9-14 Configuring the Monitor Port for a Local Mirroring Group 9-15 Configuring Local Port Mirroring for an ONU 9-16 Displaying and Maintaining Port Mirroring 9-16 Port Mirroring Configuration Examples 9-17 Local Port Mirroring Configuration Example (in Mirroring Port Mode) 9-17 Layer 2 Remote Port Mirroring Configuration Example 9-18 Layer 3 Remote Port Mirroring Configuration Example 9-19 Local Port Mirroring Configuration Example for ONUs Traffic Mirroring Configuration 10-1 Traffic Mirroring Overview 10-1 Traffic Mirroring Overview 10-1 Remote Traffic Mirroring Overview 10-1 Configuring Traffic Mirroring 10-2 Configuring Traffic Mirroring 10-2 Applying a QoS Policy 10-2 Configuring Remote Traffic Mirroring 10-4 Displaying and Maintaining Traffic Mirroring 10-5 Traffic Mirroring Configuration Examples 10-5 Traffic Mirroring Configuration Example 10-5 Network Requirements 10-5 Configuration Procedure 10-5 Remote Traffic Mirroring Configuration Example sflow Configuration 11-1 sflow Overview 11-1 Introduction to sflow 11-1 Operation of sflow 11-2 Configuring sflow 11-2 Displaying and Maintaining sflow 11-3 sflow Configuration Example 11-3 Troubleshooting sflow Configuration 11-4 The Remote sflow Collector Cannot Receive sflow Packets Information Center Configuration 12-1 Information Center Overview 12-1 Introduction to Information Center 12-1 Classification of System Information 12-2 Eight Levels of System Information 12-2 Seven Output Destinations and Ten Channels of System Information 12-3 Outputting System Information by Source Module 12-4 Default Output Rules of System Information 12-4 System Information Format 12-5 Configuring Information Center 12-7 Information Center Configuration Task List 12-7 Outputting System Information to the Console 12-8 Outputting System Information to a Monitor Terminal 12-9 v

12 Outputting System Information to a Log Host Outputting System Information to the Trap Buffer Outputting System Information to the Log Buffer Outputting System Information to the SNMP Module Saving System Information to a Log File Configuring Synchronous Information Output Disabling a Port from Generating Link Up/Down Logging Information Displaying and Maintaining Information Center Information Center Configuration Examples Outputting Log Information to a Unix Log Host Outputting Log Information to a Linux Log Host Outputting Log Information to the Console Index 13-1 vi

13 1 System Maintaining and Debugging When maintaining and debugging the system, go to these sections for information you are interested in: System Maintaining and Debugging Ping Tracert System Debugging Ping and Tracert Configuration Example System Maintaining and Debugging Ping You can use the ping command and the tracert command to verify the current network connectivity, and use the debug command to enable debugging and thus to diagnose system faults based on the debugging information. Introduction You can use the ping command to verify whether a device with a specified address is reachable, and to examine network connectivity. The ping function is implemented through the Internet Control Message Protocol (ICMP): 1) The source device sends an ICMP echo request to the destination device. 2) The source device determines whether the destination is reachable based on whether it receives an ICMP echo reply; if the destination is reachable, the source device determines the link quality based on the numbers of ICMP echo requests sent and replies received, determines the distance between the source and destination based on the round trip time of ping packets. Configuring Ping Follow the step below to configure the ping function: To do Use the command Remarks Check whether a specified address in an IP network is reachable ping [ ip ] [ -a source-ip -c count -f -h ttl -i interface-type interface-number -m interval -n -p pad -q -r -s packet-size -t timeout -tos tos -v -vpn-instance vpn-instance-name ] * host ping ipv6 [ -a source-ipv6 -c count -m interval -s packet-size -t timeout ] * host [ -i interface-type interface-number ] Use either approach The ping command is applicable in an IPv4 network; the ping ipv6 command is applicable in an IPv6 network. Available in any view 1-1

14 For a low-speed network, you are recommended to set a larger value for the timeout timer (indicated by the -t parameter in the command) when configuring the ping command. Only the directly connected segment address can be pinged if the outgoing interface is specified with the -i argument For detailed description of the ping lsp command, refer to MPLS Basics Commands in the MPLS Command Reference. Ping Configuration Example Network requirements As shown in Figure 1-1, check whether an available route exists between Device A and Device C. If there is an available route exists between the two devices, get the detailed information of routes from Device A to Device C. Figure 1-1 Ping network diagram Configuration procedure # Use the ping command to display whether an available route exists between Device A and Device C. <DeviceA> ping PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=254 time=205 ms Reply from : bytes=56 Sequence=2 ttl=254 time=1 ms Reply from : bytes=56 Sequence=3 ttl=254 time=1 ms Reply from : bytes=56 Sequence=4 ttl=254 time=1 ms Reply from : bytes=56 Sequence=5 ttl=254 time=1 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/41/205 ms # Get the detailed information of routes from Device A to Device C. <DeviceA> ping -r

15 PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=254 time=53 ms Record Route: Reply from : bytes=56 Sequence=2 ttl=254 time=1 ms Record Route: Reply from : bytes=56 Sequence=3 ttl=254 time=1 ms Record Route: Reply from : bytes=56 Sequence=4 ttl=254 time=1 ms Record Route: Reply from : bytes=56 Sequence=5 ttl=254 time=1 ms Record Route: ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/11/53 ms The principle of ping r is as shown in Figure ) The source (Device A) sends an ICMP echo request with the RR option being empty to the destination (Device C). 2) The intermediate device (Device B) adds the IP address ( ) of its outbound interface to the RR option of the ICMP echo request, and forwards the packet. 3) Upon receiving the request, the destination device copies the RR option in the request and adds the IP address ( ) of its outbound interface to the RR option. Then the destination device sends an ICMP echo reply. 4) The intermediate device adds the IP address ( ) of its outbound interface to the RR option in the ICMP echo reply, and then forwards the reply. 5) Upon receiving the reply, the source device adds the IP address ( ) of its inbound interface to the RR option. Finally, you can get the detailed information of routes from Device A to Device C: <-> { ; } <->

16 Tracert Introduction By using the tracert command, you can trace the Layer 3 devices involved in delivering an IP packet from source to destination to check whether a network is available. This is useful for identification of failed node(s) in the event of network failure. Figure 1-2 Tracert diagram The tracert function is implemented through ICMP, as shown in Figure 1-2: The source (Device A) sends a packet with a TTL value of 1 to the destination (Device D). The UDP port of the packet is a port number that will not be used by any application of the destination. 1) The first hop (Device B) (the Layer 3 device that first receives the packet) responds by sending a TTL-expired ICMP error message to the source, with its IP address encapsulated. In this way, the source device can get the address ( ) of the first Layer 3 device. 2) The source device sends a packet with a TTL value of 2 to the destination device. 3) The second hop (Device C) responds with a TTL-expired ICMP error message, which gives the source device the address ( ) of the second Layer 3 device. 4) The above process continues until the ultimate destination device is reached. No application of the destination uses this UDP port. Therefore, the destination replies a port unreachable ICMP error message with the destination IP address ) When the source device receives the port unreachable ICMP error message, it knows that the packet has reached the destination, and it can get the addresses of all the Layer 3 devices involved to get to the destination device ( , , ). Configuring Tracert Follow these steps to configure tracert: To do Use the command Remarks Enter system view system-view Enable sending of ICMP timeout packets ip ttl-expires enable Disabled by default. 1-4

17 To do Use the command Remarks Enable sending of ICMP destination unreachable packets Display the routes from source to destination ip unreachables enable tracert [ -a source-ip -f first-ttl -m max-ttl -p port -q packet-number -vpn-instance vpn-instance-name -w timeout ] * host tracert ipv6 [ -f first-ttl -m max-ttl -p port -q packet-number -w timeout ] * host Disabled by default. Use either approach The tracert command is applicable in an IPv4 network; the tracert ipv6 command is applicable in an IPv6 network. Available in any view For the introduction to the tracert lsp command, refer to MPLS Basics Commands in the MPLS Command Reference. System Debugging Introduction to System Debugging The device provides various debugging functions. For the majority of protocols and features supported, the system provides corresponding debugging information to help users diagnose errors. The following two switches control the display of debugging information: Protocol debugging switch, which controls protocol-specific debugging information. Screen output switch, which controls whether to display the debugging information on a certain screen. As Figure 1-3 illustrates, suppose the device can provide debugging for the three modules 1, 2, and 3. Only when both the protocol debugging switch and the screen output switch are turned on can debugging information be output on a terminal. 1-5

18 Figure 1-3 The relationship between the protocol and screen debugging switch Debugging information Debugging information Protocol ON debugging switch OFF ON Protocol debugging switch ON OFF ON Screen output switch OFF Screen output switch ON 1 3 Configuring System Debugging Output of the debugging information may reduce system efficiency. The debugging commands are usually used by administrators in diagnosing network failure. After completing the debugging, disable the corresponding debugging function, or use the undo debugging all command to disable all the debugging functions. Output of debugging information is related to the configurations of the information center and the debugging commands of each protocol and functional module. Displaying the debugging information on a terminal (including console or VTY) is a common way to output debugging information. You can also output debugging information to other destinations. For the detailed configurations, refer to Information Center Commands in the Network Management and Monitoring Command Reference. By default, you can output debugging information to a terminal by following these steps: To do Use the command Remarks Enable the terminal monitoring of system information terminal monitor The terminal monitoring on the console is enabled by default and that on the monitoring terminal is disabled by default. Available in user view Enable the terminal display of debugging information terminal debugging Disabled by default Available in user view 1-6

19 To do Use the command Remarks Enable debugging for a specified module Display the enabled debugging functions debugging { all [ timeout time ] module-name [ option ] } display debugging [ interface interface-type interface-number ] [ module-name ] Disabled by default Available in user view Available in any view You must configure the debugging, terminal debugging and terminal monitor commands first to display the detailed debugging information on the terminal. For the detailed description on the terminal debugging and terminal monitor commands, refer to Information Center Commands in the Network Management and Monitoring Command Reference. Ping and Tracert Configuration Example Network requirements As shown in Figure 1-4, Device A failed to telnet Device C. Now it is required to determine whether an available route exists between Device A and Device C. If no such a route exists, you need to locate the failed nodes in the network. Figure 1-4 Ping and tracert network diagram Configuration procedure # Use the ping command to display whether an available route exists between Device A and Device C. <DeviceA> ping PING : 56 data bytes, press CTRL_C to break Request time out Request time out Request time out Request time out Request time out ping statistics packet(s) transmitted 0 packet(s) received % packet loss 1-7

20 # No such a route exists. Use the tracert command to determine failed nodes. <DeviceA> system-view [DeviceA] ip ttl-expires enable [DeviceA] ip unreachables enable [DeviceA] tracert traceroute to ( ) 30 hops max,40 bytes packet, press CTRL_C to bre ak ms 10 ms 20 ms 2 * * * 3 * * * 4 * * * 5 <DeviceA> The above output shows that no available route exists between Device A and Device C; an available router exists between Device A and Device B; an error occurred on the connection between Device B and Device C. In this case, you can use the debugging ip icmp command to enable ICMP debugging on Device A and Device C to check whether the devices send or receive the specified ICMP packets, or you can use the display ip routing-table command to display whether a route exists between the two devices. 1-8

21 2 NQA Configuration This chapter includes these sections: NQA Overview NQA Configuration Task List Configuring the NQA Server Enabling the NQA Client Creating an NQA Test Group Configuring an NQA Test Group Configuring the Collaboration Function Configuring Trap Delivery Configuring the NQA Statistics Function Configuring the History Records Saving Function Configuring Parameters Common to an NQA Test Group Scheduling an NQA Test Group Displaying and Maintaining NQA NQA Configuration Examples NQA Overview Introduction to NQA Network Quality Analyzer (NQA) analyzes network performance, services and service quality through sending test packets, and provides you with network performance and service quality parameters such as delay jitter, TCP connection delay, FTP connection delay and file transfer rate. With the NQA test results, you can: 1) Know network performance in time and then take corresponding measures. 2) Diagnose and locate network faults. Features of NQA Supporting multiple test types Ping can use only the Internet Control Message Protocol (ICMP) to test the reachability of the destination host and the round-trip time of a packet to the destination. As an enhancement to the Ping tool, NQA provides multiple test types and more functions. At present, NQA supports 11 test types: ICMP echo, DHCP, DNS, FTP, HTTP, UDP jitter, SNMP, TCP, UDP echo, voice and DLSw. In an NQA test, the client sends different types of test packets to the peer to detect the availability and the response time of the peer, helping you know protocol availability and network performance based on the test results. 2-1

22 Supporting the collaboration function Collaboration is implemented by establishing reaction entries to monitor the detection results of the current test group. If the number of consecutive probe failures reaches a certain limit, NQA s collaboration with other modules is triggered. The implementation of collaboration is shown in Figure 2-1. Figure 2-1 Implementation of collaboration The collaboration involves three parts: the application modules, the track module, and the detection modules. The detection modules monitor the link status, network performance and so on, and inform the track module of the detection result. Upon receiving the detection result, the track module changes the status of the track entry accordingly and informs the application modules. The track module works between the application modules and the detection modules and is mainly used to obscure the difference of various detection modules to provide a unified interface for application modules. The application modules then deal with the changes accordingly based on the status of the track entry, and thus collaboration is implemented. Take static routing as an example. You have configured a static route with the next hop If is reachable, the static route is valid; if is unreachable, the static route is invalid. With the collaboration between NQA, track module and application modules, real time monitoring of reachability of the static route can be implemented: 1) Monitor reachability of the destination through NQA. 2) If is detected to be unreachable, NQA will inform the static routing module through track module. 3) The static routing module then can know that the static route is invalid. For the detailed description of the Track module, see Track Configuration in the High Availability Configuration Guide. Supporting delivery of traps You can set whether to send traps to the network management server when an NQA test is performed. When a probe fails or a test is completed, the network management server can be notified, and the network administrator can know the network running status and performance in time through the traps sent. 2-2

23 Basic Concepts of NQA Test group Before performing an NQA test, create an NQA test group, and configure NQA test parameters such as test type, destination address and destination port. Each test group has an administrator name and operation tag, which can uniquely define a test group. Test and probe After an NQA test is started, one test is performed at a regular interval and you can set the interval as needed. One NQA test involves multiple consecutive probes and you can set the number of the probes. Only one probe can be made in one voice test. In different test types, probe has different meanings: For a TCP or DLSw test, one probe means one connection; For a UDP jitter or a voice test, multiple packets are sent successively in one probe, and the number of packets sent in one probe depends on the configuration of the probe packet-number command; For an FTP, HTTP, DHCP or DNS test, one probe means to carry out a corresponding function; For an ICMP echo or UDP echo test, one packet is sent in one probe; For an SNMP test, three packets are sent in one probe. NQA client and server NQA client is the device that initiates an NQA test and the NQA test group is created on the NQA client. NQA server processes the test packets sent from the NQA client, as shown in Figure 2-2. The NQA server makes a response to the request sent by the NQA client by listening to the specified destination address and port number. Figure 2-2 Relationship between the NQA client and NQA server In most NQA tests, you only need to configure the NQA client; while in TCP, UDP echo, UDP jitter, and voice tests, you must configure the NQA server. You can create multiple TCP or UDP listening services on the NQA server, each of which corresponds to a specified destination address and port number. The IP address and port number specified for a listening service on the server must be consistent with those on the client and must be different from those of an existing listening service. 2-3

24 NQA Test Operation An NQA test operation involves the following steps: 1) The NQA client constructs packets with the specified type, and sends them to the peer device. 2) Upon receiving the packet, the peer device replies with a response with a timestamp. 3) The NQA client computes the packet loss rate and RTT based on whether it has received the response and the timestamp in the response. NQA Configuration Task List To perform TCP, UDP jitter, UDP echo or voice tests, configure the NQA server on the peer device. Complete the following task to enable the NQA server: Task Configuring the NQA Server Remarks for TCP, UDP echo, UDP jitter and voice tests To perform an NQA test successfully, make the following configurations on the NQA client: 1) Enable the NQA client; 2) Create a test group and configure test parameters according to the test type. The test parameters may vary with test types; 3) Start the NQA test. To view test results about the test, use the display or debug commands. Complete these tasks to configure NQA client: Task Remarks Enabling the NQA Client Creating an NQA Test Group Configuring an NQA Test Group Configuring an ICMP Echo Test Configuring a DHCP Test Use any of the approaches Configuring an FTP Test Configuring a DNS Test Configuring an HTTP Test Configuring a UDP Jitter Test Configuring an SNMP Test Configuring a TCP Test Configuring a UDP Echo Test Configuring a Voice Test 2-4

25 Task Remarks Configuring a DLSw Test Configuring the Collaboration Function Configuring Trap Delivery Configuring the NQA Statistics Function Configuring the History Records Saving Function Configuring Parameters Common to an NQA Test Group Scheduling an NQA Test Group Configuring the NQA Server Before performing TCP, UDP echo, UDP jitter, or voice tests, configure the NQA server on the peer device. The NQA server makes a response to the request sent by the NQA client by listening to the specified destination address and port number. Follow these steps to configure the NQA server: To do Use the command Remarks Enter system view system-view Enable the NQA server nqa server enable Disabled by default. Configure the listening service on the NQA server nqa server { tcp-connect udp-echo } ip-address port-number The IP address and port number must be consistent with those configured on the NQA client and must be different from those of an existing listening service. Enabling the NQA Client Configurations on the NQA client take effect only when the NQA client is enabled. Follow these steps to enable the NQA client: To do Use the command Remarks Enter system view system-view Enable the NQA client nqa agent enable Enabled by default. 2-5

26 Creating an NQA Test Group One test corresponds to one test group. You can configure test types after you create a test group and enter the test group view. Follow theses steps to create an NQA test group: To do Use the command Remarks Enter system view system-view Create an NQA test group and enter the NQA test group view nqa entry admin-name operation-tag If you execute the nqa entry command to enter the test group view with test type configured, you directly enter the test type view of the test group. Configuring an NQA Test Group Configuring an ICMP Echo Test An ICMP echo test is used to test reachability of the destination host according to the ICMP echo reply or timeout information. An ICMP echo test has the same function as the ping command but provides more output information. It enables you to locate connectivity problems in a network. Follow these steps to configure an ICMP echo test: To do Use the command Remarks Enter system view system-view Enter NQA test group view nqa entry admin-name operation-tag Configure the test type as ICMP echo and enter test type view type icmp-echo Configure the destination address for a test operation Configure the size of probe packets sent destination ip ip-address data-size size By default, no destination IP address is configured for a test operation. 100 bytes by default. 2-6

27 To do Use the command Remarks Configure the filler string of a probe packet sent data-fill string By default, the filler string of a probe packet is the hexadecimal number Specify a VPN instance vpn-instance instance Not specified by default. Specify the IP address of an interface as the source IP address of an ICMP echo request source interface interface-type interface-number By default, no interface address is specified as the source IP address of ICMP probe requests. If you use the source ip command to configure the source IP address of ICMP echo probe requests, the source interface command is invalid. The interface specified by this command must be up. Otherwise, the probe will fail. Configure the source IP address of a probe request source ip ip-address By default, no source IP address is specified. If no source IP address is specified, but the source interface is specified, the IP address of the source interface is taken as the source IP address of ICMP probe requests. The source IP address must be that of an interface on the device and the interface must be up. Otherwise, the probe will fail. Configure the next hop IP address for an ICMP echo request next-hop ip-address By default, no next hop IP address is configured. Configure common optional parameters See Configuring Parameters Common to an NQA Test Group 2-7

28 Configuring a DHCP Test A DHCP test is mainly used to test the existence of a DHCP server on the network as well as the time necessary for the DHCP server to respond to a client request and assign an IP address to the client. Configuration prerequisites Before performing a DHCP test, configure the DHCP server. If the NQA (DHCP client) and the DHCP server are not in the same network segment, configure a DHCP relay. For the configuration of DHCP server and DHCP relay, see DHCP Server Configuration and DHCP Relay Agent Configuration in the Layer 3 - IP Services Configuration Guide. Configuring a DHCP test Follow these steps to configure a DHCP test: To do Use the command Remarks Enter system view system-view Enter NQA test group view nqa entry admin-name operation-tag Configure the test type as DHCP and enter test type view type dhcp Specify an interface for a DHCP test operation interface interface-type interface-number By default, no interface is specified to perform a DHCP test. The interface specified by the source interface command must be up; otherwise, the test fails. Configure common optional parameters See Configuring Parameters Common to an NQA Test Group Because a DHCP test is a process to simulate address allocation in DHCP, the IP address of the interface that performs the DHCP test does not change. When the DHCP test is completed, the NQA client sends a DHCP-RELEASE packet to release the obtained IP address. Configuring a DNS Test A DNS test is mainly used to test whether the NQA client can resolve a domain name into an IP address through a DNS server and the time required for resolution. 2-8

29 Configuration prerequisites Before performing a DNS test, configure the mapping between a domain name and an IP address on a DNS server. Configuring a DNS test Follow these steps to configure a DNS test: To do Use the command Remarks Enter system view system-view Enter NQA test group view nqa entry admin-name operation-tag Configure the test type as DNS and enter test type view type dns Specify a destination address for a DNS test destination ip ip-address By default, no destination IP address is configured for a test operation. The destination IP address must be the IP address of the DNS server. Configure the domain name Configure optional parameters common to an NQA test group resolve-target domain-name See Configuring Parameters Common to an NQA Test Group By default, no domain name is configured for a DNS test. Because a DNS test is a process to simulate the domain name resolution, the mapping between the domain name and the IP address is not saved. Configuring an FTP Test An FTP test is mainly used to test the connection between the NQA client and a specified FTP server and the time necessary for the FTP client to transfer a file to or download a file from the FTP server. Configuration prerequisites Before an FTP test, perform some configurations on the FTP server. For example, configure the username and password that are used to log in to the FTP server. For more information about FTP server configuration, see FTP Configuration in the Fundamentals Configuration Guide. Configuring an FTP test Follow these steps to configure an FTP test: 2-9

30 To do Use the command Remarks Enter system view system-view Enter NQA test group view nqa entry admin-name operation-tag Configure the test type as FTP and enter test type view type ftp Configure the destination address for a test operation destination ip ip-address By default, no destination IP address is configured for a test operation. The destination IP address for a test operation is the IP address of the FTP server. Configure the source IP address of a probe request source ip ip-address By default, no source IP address is specified. The source IP address must be that of an interface on the device and the interface must be up. Otherwise, the test will fail. Configure the operation type operation { get put } By default, the operation type for the FTP is get, which means obtaining files from the FTP server. Configure a login username username name By default, no login username is configured. Configure a login password password password By default, no login password is configured. Specify a file to be transferred between the FTP server and the FTP client filename file-name By default, no file is specified. Configure common optional parameters See Configuring Parameters Common to an NQA Test Group 2-10

31 When you execute the put command, a file file-name with fixed size and content is created on the FTP server. When you execute the get command, the device does not save the files obtained from the FTP server. When you execute the get command, the FTP test cannot succeed if a file named file-name does not exist on the FTP server. When you execute the get command, use a file with a smaller size because a big file may result in test failure due to timeout, or may affect other services because of occupying too much network bandwidth. Configuring an HTTP Test An HTTP test is used to test the connection between the NQA client and a specified HTTP server and the time required to obtain data from the HTTP server, thus detecting the connectivity and performance of the HTTP server. Configuration prerequisites Before performing an HTTP test, configure the HTTP server. Configuring an HTTP test Follow these steps to configure an HTTP test: To do Use the command Remarks Enter system view system-view Enter NQA test group view nqa entry admin-name operation-tag Configure the test type as HTTP and enter test type view type http Configure the destination address for a test operation destination ip ip-address By default, no destination IP address is configured for a test operation. The destination IP address for a test operation is the IP address of the HTTP server. 2-11

32 To do Use the command Remarks Configure the source IP address of a probe request source ip ip-address By default, no source IP address is specified. The source IP address must be that of an interface on the device and the interface must be up. Otherwise, the test will fail. Configure the operation type operation { get post } By default, the operation type for the HTTP is get, which means obtaining data from the HTTP server. Configure the website that an HTTP test visits url url Configure the HTTP version used in the HTTP test http-version v1.0 By default, HTTP 1.0 is used in an HTTP test. Configure common optional parameters See Configuring Parameters Common to an NQA Test Group The TCP port number for the HTTP server must be 80 in an HTTP test. Otherwise, the test will fail. Configuring a UDP Jitter Test It is recommended not to perform an NQA UDP jitter test on known ports, namely, ports from 1 to Otherwise, the NQA test will fail or the corresponding services of this port will be unavailable. Real-time services such as voice and video have high requirements on delay jitters. With the UDP jitter test, uni/bi-directional delay jitters can be obtained to judge whether a network can carry real-time services. 2-12

33 Delay jitter refers to the difference between the interval of receiving two packets consecutively and the interval of sending these two packets. The procedure of a UDP jitter test is as follows: The source sends packets at regular intervals to the destination port. The destination affixes a time stamp to each packet that it receives and then sends it back to the source. Upon receiving the packet, the source calculates the delay jitter, and the network status can be analyzed. Configuration prerequisites A UDP jitter test requires cooperation between the NQA server and the NQA client. Before the UDP jitter test, make sure that the UDP listening function is configured on the NQA server. For the configuration of the UDP listening function, see Configuring the NQA Server. Configuring a UDP jitter test Follow these steps to configure a UDP jitter test: To do Use the command Remarks Enter system view system-view Enter NQA test group view nqa entry admin-name operation-tag Configure the test type as UDP jitter and enter test type view type udp-jitter Configure the destination address for a test operation destination ip ip-address By default, no destination IP address is configured for a test operation. The destination IP address must be consistent with that of the existing listening service on the NQA server. Configure the destination port for a test operation destination port port-number By default, no destination port number is configured for a test operation. The destination port must be consistent with that of the existing listening service on the NQA server. Specify the source port number for a request source port port-number By default, no source port number is specified. 2-13

34 To do Use the command Remarks Configure the size of a probe packet sent data-size size 100 bytes by default. Configure the filler string of a probe packet sent Configure the number of packets sent in a UDP jitter probe Configure the interval for sending packets in a UDP jitter probe Configure the time for waiting for a response in a UDP jitter test data-fill string probe packet-number packet-number probe packet-interval packet-interval probe packet-timeout packet-timeout By default, the filler string of a probe packet is the hexadecimal number by default. 20 milliseconds by default milliseconds by default. Configure the source IP address of a probe request in a test operation source ip ip-address By default, no source IP address is specified. The source IP address must be that of an interface on the device and the interface must be up. Otherwise, the test will fail. Configure common optional parameters See Configuring Parameters Common to an NQA Test Group The number of probes made in a UDP jitter test depends on the probe count command. The number of probe packets sent in each probe depends on the configuration of the probe packet-number command. Configuring an SNMP Test An SNMP query test is used to test the time the NQA client takes to send an SNMP query packet to the SNMP agent and then receive a response packet. 2-14

35 Configuration prerequisites The SNMP agent function must be enabled on the device that serves as an SNMP agent before an SNMP test. For the configuration of SNMP agent, see SNMP Configuration in the Network Management and Monitoring Configuration Guide. Configuring an SNMP test Follow these steps to configure an SNMP test: To do Use the command Remarks Enter system view system-view Enter NQA test group view nqa entry admin-name operation-tag Configure the test type as SNMP and enter test type view type snmp Configure the destination address for a test operation destination ip ip-address By default, no destination IP address is configured for a test operation. Specify the source port number for a probe request in a test operation source port port-number By default, no source port number is specified. Configure the source IP address of a probe request in a test operation source ip ip-address By default, no source IP address is specified. The source IP address must be that of an interface on the device and the interface must be up. Otherwise, the test will fail. Configure common optional parameters See Configuring Parameters Common to an NQA Test Group Configuring a TCP Test A TCP test is used to test the TCP connection between the client and the specified port on the NQA server and the setup time for the connection, thus judging the availability and performance of the services provided on the specified port on the server. Configuration prerequisites A TCP test requires cooperation between the NQA server and the NQA client. Configure the TCP listening function on the NQA server before the TCP test. For the configuration of the TCP listening function, see Configuring the NQA Server. 2-15