HPE FlexNetwork 10500 Switch Series

HPE FlexNetwork 10500 Switch Series Network Management and Monitoring Configuration Guide Part number: 5998-7128R Software version: 10500-CMW710-R7178 Document version: 6W100-20160129

Copyright 2016 Hewlett Packard Enterprise Development LP The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or omissions contained herein. Confidential computer software. Valid license from Hewlett Packard Enterprise required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor s standard commercial license. Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard Enterprise has no control over and is not responsible for information outside the Hewlett Packard Enterprise website. Acknowledgments Intel, Itanium, Pentium, Intel Inside, and the Intel Inside logo are trademarks of Intel Corporation in the United States and other countries. Microsoft and Windows are trademarks of the Microsoft group of companies. Adobe and Acrobat are trademarks of Adobe Systems Incorporated. Java and Oracle are registered trademarks of Oracle and/or its affiliates. UNIX is a registered trademark of The Open Group.

Contents Using ping, tracert, and system debugging 1 Ping 1 Using a ping command to test network connectivity 1 Ping example 1 Tracert 3 Prerequisites 4 Using a tracert command to identify failed or all nodes in a path 4 Tracert example 4 System debugging 5 Debugging information control switches 6 Debugging a feature module 6 Configuring NQA 8 Overview 8 NQA operation 8 Collaboration 9 Threshold monitoring 9 NQA configuration task list 10 Configuring the NQA server 10 Enabling the NQA client 11 Configuring NQA operations on the NQA client 11 NQA operation configuration task list 11 Configuring the ICMP echo operation 12 Configuring the DHCP operation 13 Configuring the DNS operation 13 Configuring the FTP operation 14 Configuring the HTTP operation 15 Configuring the UDP jitter operation 16 Configuring the SNMP operation 17 Configuring the TCP operation 18 Configuring the UDP echo operation 18 Configuring the UDP tracert operation 19 Configuring the voice operation 21 Configuring the DLSw operation 22 Configuring the path jitter operation 23 Configuring optional parameters for the NQA operation 24 Configuring the collaboration function 25 Configuring threshold monitoring 26 Configuring the NQA statistics collection function 29 Configuring the saving of NQA history records 29 Scheduling the NQA operation on the NQA client 30 Configuring NQA templates on the NQA client 30 NQA template configuration task list 31 Configuring the ICMP template 31 Configuring the DNS template 32 Configuring the TCP template 33 Configuring the UDP template 34 Configuring the HTTP template 35 Configuring the FTP template 36 Configuring optional parameters for the NQA template 37 Displaying and maintaining NQA 38 NQA configuration examples 38 ICMP echo operation configuration example 38 DHCP operation configuration example 40 DNS operation configuration example 41 FTP operation configuration example 42 HTTP operation configuration example 43 i

UDP jitter operation configuration example 44 SNMP operation configuration example 47 TCP operation configuration example 48 UDP echo operation configuration example 49 UDP tracert operation configuration example 50 Voice operation configuration example 52 DLSw operation configuration example 54 Path jitter operation configuration example 55 NQA collaboration configuration example 57 ICMP template configuration example 59 DNS template configuration example 60 TCP template configuration example 61 UDP template configuration example 62 HTTP template configuration example 63 FTP template configuration example 63 Configuring NTP 65 Overview 65 How NTP works 65 NTP architecture 66 Association modes 67 NTP security 69 NTP for MPLS L3VPNs 70 Protocols and standards 71 Configuration restrictions and guidelines 71 Configuration task list 71 Enabling the NTP service 71 Configuring NTP association mode 71 Configuring NTP in client/server mode 72 Configuring NTP in symmetric active/passive mode 72 Configuring NTP in broadcast mode 73 Configuring NTP in multicast mode 74 Configuring access control rights 75 Configuring NTP authentication 75 Configuring NTP authentication in client/server mode 75 Configuring NTP authentication in symmetric active/passive mode 77 Configuring NTP authentication in broadcast mode 80 Configuring NTP authentication in multicast mode 81 Configuring NTP optional parameters 84 Specifying the source interface for NTP messages 84 Disabling an interface from receiving NTP messages 84 Configuring the maximum number of dynamic associations 85 Setting a DSCP value for NTP packets 85 Configuring the local clock as a reference source 86 Displaying and maintaining NTP 86 NTP configuration examples 86 NTP client/server mode configuration example 86 IPv6 NTP client/server mode configuration example 88 NTP symmetric active/passive mode configuration example 89 IPv6 NTP symmetric active/passive mode configuration example 90 NTP broadcast mode configuration example 91 NTP multicast mode configuration example 93 IPv6 NTP multicast mode configuration example 96 Configuration example for NTP client/server mode with authentication 99 Configuration example for NTP broadcast mode with authentication 100 Configuration example for MPLS VPN time synchronization in client/server mode 103 Configuration example for MPLS VPN time synchronization in symmetric active/passive mode 104 Configuring SNTP 107 Configuration restrictions and guidelines 107 Configuration task list 107 Enabling the SNTP service 107 ii

Specifying an NTP server for the device 107 Configuring SNTP authentication 108 Displaying and maintaining SNTP 109 SNTP configuration example 109 Configuring SNMP 111 Overview 111 SNMP framework 111 MIB and view-based MIB access control 111 SNMP operations 112 Protocol versions 112 Access control modes 112 FIPS compliance 113 Configuring SNMP basic parameters 113 Configuring SNMPv1 or SNMPv2c basic parameters 113 Configuring SNMPv3 basic parameters 115 Configuring SNMP logging 118 Configuring SNMP notifications 119 Enabling SNMP notifications 119 Configuring the SNMP agent to send notifications to a host 119 Displaying the SNMP settings 121 SNMPv1/SNMPv2c configuration example 122 Network requirements 122 Configuration procedure 122 Verifying the configuration 123 SNMPv3 configuration example 123 Network requirements 123 Configuration procedure 123 Verifying the configuration 125 Configuring RMON 127 Overview 127 RMON groups 127 Sample types for the alarm group and the private alarm group 129 Protocols and standards 129 Configuring the RMON statistics function 129 Creating an RMON Ethernet statistics entry 129 Creating an RMON history control entry 129 Configuring the RMON alarm function 130 Displaying and maintaining RMON settings 131 RMON configuration examples 131 Ethernet statistics group configuration example 131 History group configuration example 132 Alarm function configuration example 134 Configuring NETCONF 136 Overview 136 NETCONF structure 136 NETCONF message format 137 How to use NETCONF 138 Protocols and standards 139 FIPS compliance 139 NETCONF configuration task list 139 Enabling NETCONF over SOAP 140 Enabling NETCONF over SSH 140 Enabling NETCONF logging 140 Establishing a NETCONF session 141 Entering XML view 141 Exchanging capabilities 141 Subscribing to event notifications 142 Subscription procedure 142 Example for subscribing to event notifications 142 iii

Locking/unlocking the configuration 144 Locking the configuration 144 Unlocking the configuration 144 Example for locking the configuration 145 Performing service operations 146 Performing the get/get-bulk operation 146 Performing the get-config/get-bulk-config operation 147 Performing the edit-config operation 148 All-module configuration data retrieval example 148 Syslog configuration data retrieval example 150 Example for retrieving a data entry for the interface table 151 Example for changing the value of a parameter 152 Rolling back the configuration based on a rollback point 153 Configuring a rollback point 154 Performing the save-point/rollback operation 154 Performing the save-point/commit operation 154 Saving, rolling back, and loading the configuration 155 Saving the configuration 155 Rolling back the configuration 155 Loading the configuration 156 Example for saving the configuration 156 Filtering data 157 Example for filtering data with regular expression match 159 Example for filtering data by conditional match 162 Performing CLI operations through NETCONF 163 Configuration procedure 163 CLI operation example 164 Retrieving NETCONF session information 165 Terminating another NETCONF session 167 Configuration example 167 Returning to the CLI 168 Appendix 169 Appendix A Supported NETCONF operations 169 Configuring EAA 178 Overview 178 EAA framework 178 Elements in a monitor policy 179 EAA environment variables 180 Configuring a user-defined EAA environment variable 181 Configuring a monitor policy 182 Configuration restrictions and guidelines 182 Configuring a monitor policy from the CLI 182 Configuring a monitor policy by using Tcl 184 Suspending monitor policies 185 Displaying and maintaining EAA settings 186 EAA configuration examples 186 CLI-defined policy configuration example 186 CLI-defined policy with EAA environment variables configuration example 187 Tcl-defined policy configuration example 188 Monitoring and maintaining processes 190 Displaying and maintaining processes 190 Displaying and maintaining user processes 191 Monitoring kernel threads 192 Configuring kernel thread deadloop detection 192 Configuring kernel thread starvation detection 193 Displaying and maintaining kernel threads 194 Configuring port mirroring 196 Overview 196 iv

Terminology 196 Port mirroring classification and implementation 197 Configuring local port mirroring 200 Local port mirroring configuration task list 200 Creating a local mirroring group 200 Configuring source ports for the local mirroring group 200 Configuring source CPUs for the local mirroring group 201 Configuring the monitor port for the local mirroring group 202 Configuring Layer 2 remote port mirroring 202 Layer 2 remote port mirroring with configurable reflector port configuration task list 203 Layer 2 remote port mirroring with egress port configuration task list 203 Configuring a remote destination group on the destination device 204 Configuring a remote source group on the source device 205 Configuring Layer 3 remote port mirroring 209 Layer 3 remote port mirroring configuration task list 209 Configuration prerequisites 209 Configuring local mirroring groups 210 Configuring source ports for a local mirroring group 210 Configuring source CPUs for a local mirroring group 211 Configuring the monitor port for a local mirroring group 211 Displaying and maintaining port mirroring 212 Port mirroring configuration examples 212 Local port mirroring configuration example (in source port mode) 212 Local port mirroring configuration example (in source CPU mode) 214 Layer 2 remote port mirroring configuration example (reflector port configurable) 215 Layer 2 remote port mirroring configuration example (with egress port) 217 Layer 3 remote port mirroring configuration example 219 Configuring flow mirroring 222 Flow mirroring configuration task list 222 Configuring match criteria 222 Configuring a traffic behavior 223 Configuring a QoS policy 223 Applying a QoS policy 223 Applying a QoS policy to an interface 223 Applying a QoS policy to a VLAN 224 Applying a QoS policy globally 224 Applying a QoS policy to the control plane 224 Flow mirroring configuration example 224 Network requirements 224 Configuration procedure 225 Verifying the configuration 226 Configuring NetStream 227 Overview 227 NetStream architecture 227 Flow aging 228 NetStream data export 228 NetStream filtering 230 Feature and hardware compatibility 230 NetStream configuration task list 231 Enabling NetStream 232 Configuring NetStream filtering 232 Configuring attributes of the NetStream data export 232 Configuring the NetStream data export format 232 Configuring the refresh rate for NetStream version 9 templates 233 Configuring NetStream flow aging 234 Flow aging methods 234 Configuration procedure 234 Configuring the NetStream data export 235 Configuring the NetStream traditional data export 235 Configuring the NetStream aggregation data export 235 v

Displaying and maintaining NetStream 236 NetStream configuration examples 237 NetStream traditional data export configuration example 237 NetStream aggregation data export configuration example 239 Configuring IPv6 NetStream 243 Overview 243 IPv6 NetStream architecture 243 Flow aging 244 IPv6 NetStream data export 244 IPv6 NetStream filtering 245 Feature and hardware compatibility 245 IPv6 NetStream configuration task list 246 Enabling IPv6 NetStream 247 Configuring IPv6 NetStream filtering 247 Configuring attributes of the IPv6 NetStream data export 247 Configuring the IPv6 NetStream data export format 247 Configuring the refresh rate for IPv6 NetStream version 9 templates 248 Configuring IPv6 NetStream flow aging 249 Flow aging methods 249 Configuration procedure 249 Configuring the IPv6 NetStream data export 250 Configuring the IPv6 NetStream traditional data export 250 Configuring the IPv6 NetStream aggregation data export 250 Displaying and maintaining IPv6 NetStream 251 IPv6 NetStream configuration examples 252 IPv6 NetStream traditional data export configuration example 252 IPv6 NetStream aggregation data export configuration example 254 Configuring sflow 257 Protocols and standards 257 Configuration restrictions and guidelines 257 sflow configuration task list 258 Configuring the sflow agent and sflow collector information 258 Configuring flow sampling 258 Configuring counter sampling 259 Displaying and maintaining sflow 259 sflow configuration example 260 Network requirements 260 Configuration procedure 260 Verifying the configurations 261 Troubleshooting sflow configuration 261 The remote sflow collector cannot receive sflow packets 261 Configuring the information center 263 Overview 263 Log types 263 Log levels 263 Log destinations 264 Default output rules for logs 264 Default output rules for diagnostic logs 264 Default output rules for security logs 264 Default output rules for hidden logs 265 Default output rules for trace logs 265 Log formats 265 FIPS compliance 268 Information center configuration task list 268 Outputting logs to the console 268 Outputting logs to the monitor terminal 269 Outputting logs to a log host 269 Outputting logs to the log buffer 270 Saving logs to the log file 270 vi

Managing security logs 271 Saving security logs to the security log file 271 Managing the security log file 272 Saving diagnostic logs to the diagnostic log file 273 Configuring the maximum size of the trace log file 273 Enabling synchronous information output 274 Enabling duplicate log suppression 274 Configuring log suppression for a module 274 Disabling an interface from generating link up or link down logs 275 Setting the minimum storage period for logs 275 Displaying and maintaining information center 276 Information center configuration examples 276 Configuration example for outputting logs to the console 276 Configuration example for outputting logs to a UNIX log host 277 Configuration example for outputting logs to a Linux log host 278 Configuring GOLD 280 Configuring monitoring diagnostics 280 Configuring on-demand diagnostics 281 Simulating test results 282 Configuring the log buffer size 282 Displaying and maintaining GOLD 283 GOLD configuration example (in standalone mode) 283 GOLD configuration example (in IRF mode) 285 Configuring the packet capture 287 Overview 287 Filter elements 287 Building a capture filter 292 Building a display filter 293 Configuration restrictions and guidelines 294 Packet capture configuration task list 294 Capturing packets 295 Displaying the contents in a packet file 295 Packet capture configuration examples 295 Basic packet capture configuration example 295 Packet file display configuration example 297 Document conventions and icons 298 Conventions 298 Network topology icons 299 Support and other resources 300 Accessing Hewlett Packard Enterprise Support 300 Accessing updates 300 Websites 301 Customer self repair 301 Remote support 301 Documentation feedback 301 Index 303 vii

Using ping, tracert, and system debugging Ping This chapter covers ping, tracert, and information about debugging the system. Use the ping utility to determine if an address is reachable. Ping sends ICMP echo requests (ECHO-REQUEST) to the destination device. Upon receiving the requests, the destination device responds with ICMP echo replies (ECHO-REPLY) to the source device. The source device outputs statistics about the ping operation, including the number of packets sent, number of echo replies received, and the round-trip time. You can measure the network performance by analyzing these statistics. Using a ping command to test network connectivity Execute ping commands in any view. Task Determine if an address in an IP network is reachable. Command When you configure the ping command for a low-speed network, set a larger value for the timeout timer (indicated by the -t keyword in the command). For IPv4 networks: 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 For IPv6 networks: ping ipv6 [ -a source-ipv6 -c count -i interface-type interface-number -m interval -q -s packet-size -t timeout -v -tc traffic-class -vpn-instance vpn-instance-name ] * host Ping example Network requirements As shown in Figure 1, determine if Device A and Device C can reach each other. If they can reach each other, get detailed information about routes from Device A to Device C. 1

Figure 1 Network diagram Configuration procedure # Use the ping command on Device A to test connectivity to Device C. Ping 1.1.2.2 (1.1.2.2): 56 data bytes, press CTRL_C to break 56 bytes from 1.1.2.2: icmp_seq=0 ttl=254 time=2.137 ms 56 bytes from 1.1.2.2: icmp_seq=1 ttl=254 time=2.051 ms 56 bytes from 1.1.2.2: icmp_seq=2 ttl=254 time=1.996 ms 56 bytes from 1.1.2.2: icmp_seq=3 ttl=254 time=1.963 ms 56 bytes from 1.1.2.2: icmp_seq=4 ttl=254 time=1.991 ms --- Ping statistics for 1.1.2.2 --- 5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.963/2.028/2.137/0.062 ms The output shows that: Device A sends five ICMP packets to Device C and Device A receives five ICMP packets. No ICMP packet is lost. The route is reachable. # Get detailed information about routes from Device A to Device C. <DeviceA> ping -r 1.1.2.2 Ping 1.1.2.2 (1.1.2.2): 56 data bytes, press CTRL_C to break 56 bytes from 1.1.2.2: icmp_seq=0 ttl=254 time=4.685 ms RR: 1.1.2.1 1.1.2.2 1.1.1.2 1.1.1.1 56 bytes from 1.1.2.2: icmp_seq=1 ttl=254 time=4.834 ms (same route) 56 bytes from 1.1.2.2: icmp_seq=2 ttl=254 time=4.770 ms (same route) 56 bytes from 1.1.2.2: icmp_seq=3 ttl=254 time=4.812 ms (same route) 56 bytes from 1.1.2.2: icmp_seq=4 ttl=254 time=4.704 ms (same route) --- Ping statistics for 1.1.2.2 --- 5 packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 4.685/4.761/4.834/0.058 ms The test procedure of ping r is as shown in Figure 1: 1. The source device (Device A) sends an ICMP echo request to the destination device (Device C) with the RR option blank. 2

Tracert 2. The intermediate device (Device B) adds the IP address of its outbound interface (1.1.2.1) 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 (1.1.2.2) 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 (1.1.1.2) 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 (1.1.1.1) to the RR option. The detailed information of routes from Device A to Device C is formatted as: 1.1.1.1 <-> {1.1.1.2; 1.1.2.1} <-> 1.1.2.2. Tracert (also called Traceroute) enables retrieval of the IP addresses of Layer 3 devices in the path to a destination. In the event of network failure, use tracert to test network connectivity and identify failed nodes. Figure 2 Tracert operation Device A Device B Device C Device D 1.1.1.1/24 1.1.1.2/24 1.1.2.1/24 1.1.3.1/24 1.1.2.2/24 1.1.3.2/24 Hop Lmit=1 TTL exceeded Hop Lmit=2 TTL exceeded Hop Lmit=n UDP port unreachable Tracert uses received ICMP error messages to get the IP addresses of devices. Tracert works as shown in Figure 2: 1. The source device sends a UDP packet with a TTL value of 1 to the destination device. The destination UDP port is not used by any application on the destination device. 2. The first hop (Device B, the first Layer 3 device that receives the packet) responds by sending a TTL-expired ICMP error message to the source, with its IP address (1.1.1.2) encapsulated. This way, the source device can get the address of the first Layer 3 device (1.1.1.2). 3. The source device sends a packet with a TTL value of 2 to the destination device. 4. 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 (1.1.2.2). 5. This process continues until a packet sent by the source device reaches the ultimate destination device. Because no application uses the destination port specified in the packet, the destination device responds with a port-unreachable ICMP message to the source device, with its IP address encapsulated. This way, the source device gets the IP address of the destination device (1.1.3.2). 6. The source device thinks that: The packet has reached the destination device after receiving the port-unreachable ICMP message. The path to the destination device is 1.1.1.2 to 1.1.2.2 to 1.1.3.2. 3

Prerequisites Before you use a tracert command, perform the tasks in this section. For an IPv4 network: Enable sending of ICMP timeout packets on the intermediate devices (devices between the source and destination devices). If the intermediate devices are HPE devices, execute the ip ttl-expires enable command on the devices. For more information about this command, see Layer 3 IP Services Command Reference. Enable sending of ICMP destination unreachable packets on the destination device. If the destination device is an HPE device, execute the ip unreachables enable command. For more information about this command, see Layer 3 IP Services Command Reference. For an IPv6 network: Enable sending of ICMPv6 timeout packets on the intermediate devices (devices between the source and destination devices). If the intermediate devices are HPE devices, execute the ipv6 hoplimit-expires enable command on the devices. For more information about this command, see Layer 3 IP Services Command Reference. Enable sending of ICMPv6 destination unreachable packets on the destination device. If the destination device is an HPE device, execute the ipv6 unreachables enable command. For more information about this command, see Layer 3 IP Services Command Reference. Using a tracert command to identify failed or all nodes in a path Execute tracert commands in any view. Task Display the routes from source to destination. Command For IPv4 networks: tracert [ -a source-ip -f first-ttl -m max-ttl -p port -q packet-number -t tos -vpn-instance vpn-instance-name -w timeout ] * host For IPv6 networks: tracert ipv6 [ -f first-hop -m max-hops -p port -q packet-number -t traffic-class -vpn-instance vpn-instance-name -w timeout ] * host Tracert example Network requirements As shown in Figure 3, Device A failed to Telnet to Device C. Test the network connectivity between Device A and Device C. If they cannot reach each other, locate the failed nodes in the network. Figure 3 Network diagram 1.1.1.1/24 1.1.1.2/24 1.1.2.1/24 1.1.2.2/24 Device A Device B Device C 4

Configuration procedure 1. Configure the IP addresses for devices as shown in Figure 3. 2. Configure a static route on Device A. <DeviceA> system-view [DeviceA] ip route-static 0.0.0.0 0.0.0.0 1.1.1.2 [DeviceA] quit 3. Use the ping command to test connectivity between Device A and Device C. <DeviceA> ping 1.1.2.2 Ping 1.1.2.2(1.1.2.2): 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 for 1.1.2.2 --- 5 packet(s) transmitted,0 packet(s) received,100.0% packet loss The output shows that Device A and Device C cannot reach each other. 4. Use the tracert command to identify failed nodes: # Enable sending of ICMP timeout packets on Device B. <DeviceB> system-view [DeviceB] ip ttl-expires enable # Enable sending of ICMP destination unreachable packets on Device C. <DeviceC> system-view [DeviceC] ip unreachables enable # Execute the tracert command on Device A. <DeviceA> tracert 1.1.2.2 traceroute to 1.1.2.2 (1.1.2.2) 30 hops at most,40 bytes each packet, press CTRL_C to break 1 1.1.1.2 (1.1.1.2) 1 ms 2 ms 1 ms 2 * * * 3 * * * 4 * * * 5 <DeviceA> The output shows that Device A can reach Device B but cannot reach Device C. An error has occurred on the connection between Device B and Device C. 5. To identify the cause of the problem, execute the following commands on Device A and Device C: Execute the debugging ip icmp command and verify that Device A and Device C can send and receive the correct ICMP packets. Execute the display ip routing-table command to verify that Device A and Device C have a route to each other. System debugging The device supports debugging for the majority of protocols and features, and provides debugging information to help users diagnose errors. 5

Debugging information control switches The following switches control the display of debugging information: Module debugging switch Controls whether to generate the module-specific debugging information. Screen output switch Controls whether to display the debugging information on a certain screen. Use terminal monitor and terminal logging level commands to turn on the screen output switch. For more information about these two commands, see Network Management and Monitoring Command Reference. As shown in Figure 4, the device can provide debugging for the three modules 1, 2, and 3. The debugging information can be output on a terminal only when both the module debugging switch and the screen output switch are turned on. Debugging information is typically displayed on a console. You can also send debugging information to other destinations. For more information, see "Configuring the information center." Figure 4 Relationship between the module and screen output switch Debugging a feature module Output of debugging commands is memory intensive. To guarantee system performance, enable debugging only for modules that are in an exceptional condition. When debugging is complete, use the undo debugging all command to disable all the debugging functions. To debug a feature module: Step Command Remarks 1. Enable debugging for a module in user view. 2. (Optional.) Display the enabled debugging in any view. debugging { all [ timeout time ] module-name [ option ] } display debugging [ module-name ] By default, all debugging functions are disabled. N/A 6

7

Configuring NQA Overview Network quality analyzer (NQA) allows you to measure network performance, verify the service levels for IP services and applications, and troubleshoot network problems. It provides the following types of operations: ICMP echo. DHCP. DNS. FTP. HTTP. UDP jitter. SNMP. TCP. UDP echo. UDP tracert. Voice. Path jitter. DLSw. As shown in Figure 5, the NQA source device (NQA client) sends data to the NQA destination device by simulating IP services and applications to measure network performance. The obtained performance metrics include the one-way latency, jitter, packet loss, voice quality, application performance, and server response time. All types of NQA operations require the NQA client, but only the TCP, UDP echo, UDP jitter, and voice operations require the NQA server. The NQA operations for services that are already provided by the destination device such as FTP do not need the NQA server. You can configure the NQA server to listen and respond to specific IP addresses and ports to meet various test needs. Figure 5 Network diagram NQA operation The following describes how NQA performs different types of operations: A TCP or DLSw operation sets up a connection. A UDP jitter or a voice operation sends a number of probe packets. The number of probe packets is set by using the probe packet-number command. An FTP operation uploads or downloads a file. An HTTP operation gets a Web page. 8

A DHCP operation gets an IP address through DHCP. A DNS operation translates a domain name to an IP address. An ICMP echo operation sends an ICMP echo request. A UDP echo operation sends a UDP packet. An SNMP operation sends one SNMPv1 packet, one SNMPv2c packet, and one SNMPv3 packet. A path jitter operation is accomplished in the following steps: a. The operation uses tracert to obtain the path from the NQA client to the destination. A maximum of 64 hops can be detected. b. The NQA client sends ICMP echo requests to each hop along the path. The number of ICMP echo requests is set by using the probe packet-number command. A UDP tracert operation determines the routing path from the source to the destination. The number of the probes to each hop is set by using the probe count command. Collaboration NQA can collaborate with the Track module to notify application modules of state or performance changes so that the application modules can take predefined actions. Figure 6 Collaboration Application modules Detection module VRRP VSRP Static routing NQA Associates with a detection entry Sends the detection results Track module Associates with a track entry Sends the track entry status Policy-based routing Interface backup Traffic redirecting WLAN uplink detection Smart Link The following describes how a static route destined for 192.168.0.88 is monitored through collaboration: 1. NQA monitors the reachability to 192.168.0.88. 2. When 192.168.0.88 becomes unreachable, NQA notifies the Track module of the change. 3. The Track module notifies the static routing module of the state change. 4. The static routing module sets the static route as invalid according to a predefined action. For more information about collaboration, see High Availability Configuration Guide. Threshold monitoring Threshold monitoring enables the NQA client to take a predefined action when the NQA operation performance metrics violate the specified thresholds. Table 1 describes the relationships between performance metrics and NQA operation types. 9

Table 1 Performance metrics and NQA operation types Performance metric Probe duration Number of probe failures Round-trip time Number of discarded packets One-way jitter (source-to-destination or destination-to-source) One-way delay (source-to-destination or destination-to-source) Calculated Planning Impairment Factor (ICPIF) (see "Configuring the voice operation") Mean Opinion Scores (MOS) (see "Configuring the voice operation") NQA operation types that can gather the metric All NQA operation types except UDP jitter, UDP tracert, path jitter, and voice All NQA operation types except UDP jitter, UDP tracert, path jitter, and voice UDP jitter and voice UDP jitter and voice UDP jitter and voice UDP jitter and voice Voice Voice NQA configuration task list Tasks at a glance Configuring the NQA server (Required.) Enabling the NQA client (Required.) Perform at least one of the following tasks: Configuring NQA operations on the NQA client Configuring NQA templates on the NQA client Remarks Required for TCP, UDP echo, UDP jitter, and voice operations. N/A When you configure an NQA template to analyze network performance, the feature that uses the template performs the NQA operation. Configuring the NQA server To perform TCP, UDP echo, UDP jitter, and voice operations, you must enable the NQA server on the destination device. The NQA server listens and responds to requests on the specified IP addresses and ports. You can configure multiple TCP or UDP listening services on an NQA server, where each corresponds to a specific IP address and port number. The IP address and port number for a listening service must be unique on the NQA server and match the configuration on the NQA client. To configure the NQA server: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the NQA server. nqa server enable By default, the NQA server is disabled. 10

Step Command Remarks 3. Configure a TCP or UDP listening service. TCP listening service: nqa server tcp-connect ip-address port-number [ vpn-instance vpn-instance-name ] [ tos tos ] UDP listening service: nqa server udp-echo ip-address port-number [ vpn-instance vpn-instance-name ] [ tos tos ] You can set the ToS value in the IP header of reply packets sent by the NQA server. The default ToS value is 0. Enabling the NQA client Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the NQA client. nqa agent enable By default, the NQA client is enabled. Configuring NQA operations on the NQA client NQA operation configuration task list Tasks at a glance (Required.) Perform at least one of the following tasks: Configuring the ICMP echo operation Configuring the DHCP operation Configuring the DNS operation Configuring the FTP operation Configuring the HTTP operation Configuring the UDP jitter operation Configuring the SNMP operation Configuring the TCP operation Configuring the UDP echo operation Configuring the UDP tracert operation Configuring the voice operation Configuring the DLSw operation Configuring the path jitter operation (Optional.) Configuring optional parameters for the NQA operation (Optional.) Configuring the collaboration function (Optional.) Configuring threshold monitoring (Optional.) Configuring the NQA statistics collection function (Optional.) Configuring the saving of NQA history records (Required.) Scheduling the NQA operation on the NQA client 11

Configuring the ICMP echo operation The ICMP echo operation measures the reachability of a destination device. It has the same function as the ping command, but provides more output information. In addition, if multiple paths exist between the source and destination devices, you can specify the next hop for the ICMP echo operation. The ICMP echo operation is not supported in IPv6 networks. To test the reachability of an IPv6 address, use the ping ipv6 command. For more information about the command, see Network Management and Monitoring Command Reference. To configure the ICMP echo operation: Step Command Remarks 3. Enter system view. system-view N/A 4. Create an NQA operation and enter NQA operation view. 5. Specify the ICMP echo type and enter its view. 6. Specify the destination IP address of ICMP echo requests. 7. (Optional.) Specify the payload size in each ICMP echo request. 8. (Optional.) Specify the payload fill string for ICMP echo requests. nqa entry admin-name operation-tag type icmp-echo destination ip ip-address data-size size data-fill string By default, no NQA operation is created. N/A By default, no destination IP address is specified. The default setting is 100 bytes. The default string is the hexadecimal number 00010203040506070809. 9. (Optional.) Specify the output interface for ICMP echo requests. 10. (Optional.) Specify the source IP address of ICMP echo requests. 11. (Optional.) Specify the next hop for ICMP echo requests. out interface interface-type interface-number Specify the IP address of the specified interface as the source IP address: source interface interface-type interface-number Specify the source IP address: source ip ip-address next-hop ip-address By default, the output interface for ICMP echo requests is not specified. The NQA client determines the output interface based on the routing table lookup. By default, no source IP address is specified. The requests take the primary IP address of the output interface as their source IP address. If you configure both the source ip and source interface commands, the most recent configuration takes effect. The specified source interface must be up. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out. By default, no next hop is configured. 12

Configuring the DHCP operation The DHCP operation measures whether or not the DHCP server can respond to client requests. DHCP also measures the amount of time it takes the NQA client to obtain an IP address from a DHCP server. The NQA client simulates the DHCP relay agent to forward DHCP requests for IP address acquisition from the DHCP server. The interface that performs the DHCP operation does not change its IP address. When the DHCP operation completes, the NQA client sends a packet to release the obtained IP address. To configure the DHCP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the DHCP type and enter its view. 4. Specify the IP address of the DHCP server as the destination IP address of DHCP packets. nqa entry admin-name operation-tag type dhcp destination ip ip-address By default, no NQA operation is created. N/A By default, no destination IP address is specified. 5. (Optional.) Specify the output interface for DHCP request packets. 6. (Optional.) Specify the source IP address of DHCP request packets. out interface interface-type interface-number source ip ip-address By default, the output interface for DHCP requests is not specified. The NQA client determines the output interface based on the routing table lookup. By default, no source IP address is specified for the request packets. The requests take the IP address of the output interface as their source IP address. The specified source IP address must be the IP address of a local interface, and the local interface must be up. Otherwise, no probe packets can be sent out. The NQA client adds the source IP address to the giaddr field in DHCP requests to be sent to the DHCP server. For more information about the giaddr field, see Layer 3 IP Services Configuration Guide. Configuring the DNS operation The DNS operation measures the time for the NQA client to translate a domain name into an IP address through a DNS server. A DNS operation simulates domain name resolution and does not save the obtained DNS entry. To configure the DNS operation: Step Command Remarks 1. Enter system view. system-view N/A 13

Step Command Remarks 2. Create an NQA operation and enter NQA operation view. 3. Specify the DNS type and enter its view. 4. Specify the IP address of the DNS server as the destination IP address of DNS packets. 5. Specify the domain name to be translated. nqa entry admin-name operation-tag type dns destination ip ip-address resolve-target domain-name By default, no NQA operation is created. N/A By default, no destination IP address is specified. By default, no domain name is specified. Configuring the FTP operation The FTP operation measures the time for the NQA client to transfer a file to or download a file from an FTP server. When you configure the FTP operation, follow these restrictions and guidelines: When you perform the put operation with the filename command configured, make sure the file exists on the NQA client. If you get a file from the FTP server, make sure the file specified in the URL exists on the FTP server. The NQA client does not save the file obtained from the FTP server. Use a small file for the FTP operation. A big file might result in transfer failure because of timeout, or might affect other services for occupying much network bandwidth. To configure the FTP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the FTP type and enter its view. nqa entry admin-name operation-tag type ftp By default, no NQA operation is created. N/A 4. Specify the URL of the destination FTP server. 5. (Optional.) Specify the source IP address of FTP request packets. url url source ip ip-address By default, no URL is specified for the destination FTP server. Enter the URL in one of the following formats: ftp://host/filename. ftp://host:port/filename. When you perform the get operation, the file name is required. By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no FTP requests can be sent out. 14

Step Command Remarks 6. Specify the FTP operation type. 7. Specify an FTP login username. 8. Specify an FTP login password. operation { get put } username username password { cipher simple } password By default, the FTP operation type is get, which means obtaining files from the FTP server. By default, no FTP login username is configured. By default, no FTP login password is configured. 9. (Optional.) Specify the name of a file to be transferred. 10. Set the data transmission mode. filename file-name mode { active passive } By default, no file is specified. This step is required if you perform the put operation. The default mode is active. Configuring the HTTP operation An HTTP operation measures the time for the NQA client to obtain data from an HTTP server. To configure an HTTP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the HTTP type and enter its view. nqa entry admin-name operation-tag type http By default, no NQA operation is created. N/A 4. Specify the URL of the destination HTTP server. 5. Specify an HTTP login username. 6. Specify an HTTP login password. 7. (Optional.) Specify the source IP address of request packets. 8. Specify the HTTP operation type. url url username username password { cipher simple } password source ip ip-address operation { get post raw } By default, no URL is specified for the destination HTTP server. Enter the URL in one of the following formats: http://host/resource. http://host:port/resource. By default, no HTTP login username is specified. By default, no HTTP login password is specified. By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no request packets can be sent out. By default, the HTTP operation type is get, which means obtaining data from the HTTP server. 9. Specify the HTTP version. version { v1.0 v1.1 } By default, HTTP 1.0 is used. 10. (Optional.) Enter raw request view. raw-request Every time you enter raw request view, the previously configured content of the HTTP request is removed. 15

Step Command Remarks 11. (Optional.) Specify the content of a GET request for the HTTP operation. 12. Save the input and exit to HTTP operation view. Enter or paste the content. quit By default, no contents are specified. This step is required for the raw operation. N/A Configuring the UDP jitter operation CAUTION: To ensure successful UDP jitter operations and avoid affecting existing services, do not perform the operations on well-known ports from 1 to 1023. Jitter means inter-packet delay variance. A UDP jitter operation measures unidirectional and bidirectional jitters. You can verify whether the network can carry jitter-sensitive services such as real-time voice and video services through the UDP jitter operation. The UDP jitter operation works as follows: 1. The NQA client sends UDP packets to the destination port regularly. 2. The destination device takes a time stamp to each packet that it receives, and then sends the packet back to the NQA client. 3. Upon receiving the responses, the NQA client calculates the jitter according to the time stamps. The UDP jitter operation requires both the NQA server and the NQA client. Before you perform the UDP jitter operation, configure the UDP listening service on the NQA server. For more information about UDP listening service configuration, see "Configuring the NQA server." To configure a UDP jitter operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the UDP jitter type and enter its view. nqa entry admin-name operation-tag type udp-jitter By default, no NQA operation is created. N/A 4. Specify the destination IP address of UDP packets. 5. Specify the destination port of UDP packets. 6. (Optional.) Specify the source port number of UDP packets. destination ip ip-address destination port port-number source port port-number By default, no destination IP address is specified. The destination IP address must be the same as the IP address of the listening service on the NQA server. By default, no destination port number is specified. The destination port number must be the same as the port number of the listening service on the NQA server. By default, no source port number is specified. 16

Step Command Remarks 7. (Optional.) Specify the payload size in each UDP packet. 8. (Optional.) Specify the payload fill string for UDP packets. 9. (Optional.) Specify the number of UDP packets sent in one UDP jitter operation. 10. (Optional.) Configure the interval for sending UDP packets. 11. (Optional.) Specify how long the NQA client waits for a response from the server before it regards the response times out. data-size size data-fill string probe packet-number packet-number probe packet-interval packet-interval probe packet-timeout packet-timeout The default setting is 100 bytes. The default string is the hexadecimal number 00010203040506070809. The default setting is 10. The default setting is 20 milliseconds. The default setting is 3000 milliseconds. 12. (Optional.) Specify the source IP address for UDP packets. source ip ip-address By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no UDP packets can be sent out. NOTE: Use the display nqa result or display nqa statistics command to verify the UDP jitter operation. The display nqa history command does not display the UDP jitter operation results or statistics. Configuring the SNMP operation The SNMP operation measures the time for the NQA client to get a response packet from an SNMP agent. To configure the SNMP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the SNMP type and enter its view. 4. Specify the destination IP address of SNMP packets. 5. (Optional.) Specify the source port of SNMP packets. nqa entry admin-name operation-tag type snmp destination ip ip-address source port port-number By default, no NQA operation is created. N/A By default, no destination IP address is specified. By default, no source port number is specified. 17

Step Command Remarks 6. (Optional.) Specify the source IP address of SNMP packets. source ip ip-address By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no SNMP packets can be sent out. Configuring the TCP operation The TCP operation measures the time for the NQA client to establish a TCP connection to a port on the NQA server. The TCP operation requires both the NQA server and the NQA client. Before you perform a TCP operation, configure a TCP listening service on the NQA server. For more information about the TCP listening service configuration, see "Configuring the NQA server." To configure the TCP operation: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an NQA operation and enter NQA operation view. 3. Specify the TCP type and enter its view. nqa entry admin-name operation-tag type tcp By default, no NQA operation is created. N/A 4. Specify the destination IP address of TCP packets. 5. Specify the destination port of TCP packets. 6. (Optional.) Specify the source IP address of TCP packets. destination ip ip-address destination port port-number source ip ip-address By default, no destination IP address is specified. The destination IP address must be the same as the IP address of the listening service configured on the NQA server. By default, no destination port number is configured. The destination port number must be the same as the port number of the listening service on the NQA server. By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no TCP packets can be sent out. Configuring the UDP echo operation The UDP echo operation measures the round-trip time between the client and a UDP port on the NQA server. The UDP echo operation requires both the NQA server and the NQA client. Before you perform a UDP echo operation, configure a UDP listening service on the NQA server. For more information about the UDP listening service configuration, see "Configuring the NQA server." To configure the UDP echo operation: 18