Network Quality Analyzer (NQA) can perform various types of tests and collect network performance and service quality parameters such as delay jitter, time for establishing a TCP connection, time for establishing an FTP connection, and file transfer rate.

With the NQA test results, you can diagnose and locate network faults, be aware of network performance in time and take proper actions to correct any problems.

Benefits of NQA

Supporting multiple test types

Ping uses only the Internet Control Message Protocol (ICMP) to test the reachability of the destination host and the round-trip time. As an enhancement to Ping, NQA supports more test types and functions.

NQA supports 11 test types: ICMP echo, DHCP, DNS, FTP, HTTP, UDP jitter, SNMP, TCP, UDP echo, voice and DLSw.

NQA enables the client to send probe packets of different test types to detect the protocol availability and response time of the peer. Test results help you understand network performance.

Supporting threshold monitoring

NQA supports threshold monitoring for performance parameters such as average delay jitter and packet round-trip time. The performance parameters to be monitored are monitored elements. NQA monitors threshold violations for a monitored element, and reacts to certain measurement conditions, for example, sending trap messages to the network management server. This helps network administrators understand the network service quality and network performance.

1. Monitored elements

Table 1 describes the monitored elements and the NQA test types in which the elements can be monitored.

Table 1 Monitored elements and NQA test types

Monitored elements	Test type supported
Probe duration	Tests excluding UDP jitter test and voice test
Count of probe failures	Tests excluding UDP jitter test and voice test
Packet round-trip time	UDP jitter test and voice test
Count of discarded packets	UDP jitter test and voice test
One-way delay jitter (source-to-destination and destination-to-source)	UDP jitter test and voice test
One-way delay (source-to-destination and destination-to-source)	UDP jitter test and voice test
Calculated Planning Impairment Factor (ICPIF) (see “Configuring voice tests”)	Voice test
Mean Opinion Scores (MOS) (see “Configuring voice tests”)	Voice test

2. Threshold types

The following threshold types are supported:

· average—Monitors the average value of monitored data in a test. If the average value in a test exceeds the upper threshold or goes below the lower threshold, a threshold violation occurs. For example, you can monitor the average probe duration in a test.

· accumulate—Monitors total number of times the monitored data violates the threshold in a test. If the total number of times reaches or exceeds a specified value, a threshold violation occurs.

· consecutive—Monitors the number of consecutive times the monitored data violates the threshold since the test group starts. If the monitored data violates the threshold consecutively for a specified number of times, a threshold violation occurs.

NOTE:

The counting for the average or accumulate threshold type is performed per test, but that for the consecutive type is performed since the test group is started.

3. Triggered actions

The following actions may be triggered:

· none—NQA only records events for terminal display; it does not send trap information to the network management server.

· trap-only—NQA records events and sends trap messages to the network management server.

NOTE:

NQA DNS tests do not support the action of sending trap messages. The action to be triggered in DNS tests can only be the default one, none.

4. Reaction entry

In a reaction entry, a monitored element, a threshold type, and the action to be triggered are configured to implement threshold monitoring.

The state of a reaction entry can be invalid, over-threshold, or below-threshold. Before an NQA test group starts, the reaction entry is in the state of invalid. After each test or probe, threshold violations are counted according to the threshold type and range configured in the entry. If the threshold is violated consecutively or accumulatively for a specified number of times, the state of the entry is set to over-threshold; otherwise, the state of the entry is set to below-threshold.

If the action to be triggered is configured as trap-only for a reaction entry, when the state of the entry changes, a trap message is generated and sent to the network management server.

Basic NQA concepts

Test group

An NQA test group specifies test parameters including the test type, destination address, and destination port. Each test group is uniquely identified by an administrator name and operation tag. You can configure and schedule multiple NQA test groups to test different objects.

Test and probe

After the NQA test group starts, tests are performed at a specified interval. During each test, a specified number of probe operations are performed. Both the test interval and the number of probe operations per test are configurable. But only one probe operation is performed during one voice test.

Probe operations vary with NQA test types.

· During a TCP or DLSw test, one probe operation means setting up one connection.

· During a UDP jitter or a voice test, one probe operation means continuously sending a specified number of probe packets. The number of probe packets is configurable.

· During an FTP, HTTP, DHCP or DNS test, one probe operation means uploading or downloading a file, obtaining a web page, obtaining an IP address through DHCP, or translating a domain name to an IP address.

· During an ICMP echo or UDP echo test, one probe operation means sending an ICMP echo request or a UDP packet.

· During an SNMP test, one probe operation means sending one SNMPv1 packet, one SNMPv2C packet, and one SNMPv3 packet.

NQA client and server

A device with NQA test groups configured is an NQA client and the NQA client initiates NQA tests. An NQA server makes responses to probe packets destined to the specified destination address and port number.

Figure 1 Relationship between the NQA client and NQA server

Not all test types require the NQA server. Only the TCP, UDP echo, UDP jitter, or voice test requires both the NQA client and server, as shown in Figure 1.

You can create multiple TCP or UDP listening services on the NQA server. Each listens to a specific destination address and port number. Make sure the destination IP address and port number for a listening service on the server are the same as those configured for the test group on the NQA client. Each listening service must be unique on the NQA server.

NQA probe operation procedure

An NQA probe operation involves the following steps:

1. The NQA client constructs probe packets for the specified type of NQA test, and sends them to the peer device.

2. Upon receiving the probe packets, the peer sends back responses with timestamps.

3. The NQA client computes the network performance and service quality parameters, such as the packet loss rate and round-trip time based on the received responses.

NQA configuration task list

Complete the following task to enable the NQA server:

Task	Remarks
Configuring the NQA server	Required for TCP, UDP echo, UDP jitter and voice tests

To perform NQA tests successfully, make the following configurations on the NQA client:

1. Enable the NQA client.

2. Create a test group and configure test parameters. The test parameters may vary with test types.

3. Configure a schedule for the NQA test group.

Complete these tasks to configure NQA client:

Task		Remarks
Enabling the NQA client		Required
Creating an NQA test group		Required
Configuring an NQA test group	Configuring ICMP echo tests	Required Use any of the approaches
	Configuring DHCP tests
	Configuring DNS tests
	Configuring FTP tests
	Configuring HTTP tests
	Configuring UDP jitter tests
	Configuring SNMP tests
	Configuring TCP tests
	Configuring UDP echo tests
	Configuring voice tests
	Configuring DLSw tests
Configuring threshold monitoring		Optional
Configuring the NQA statistics collection function		Optional
Configuring the history records saving function		Optional
Configuring optional parameters for an NQA test group		Optional
Configuring a schedule for an NQA test group		Required

Configuring the NQA server

To perform TCP, UDP echo, UDP jitter, or voice tests, configure the NQA server on the peer device. The NQA server responses to the probe packets sent from 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	Required Disabled by default.
Configure the listening service	nqa server { tcp-connect \| udp-echo } ip-address port-number	Required The destination IP address and port number must be the same as those configured on the NQA client. A listening service must be unique on the NQA server.

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	Optional Enabled by default.

To do…

Use the command…

Remarks

Enter system view

system-view

—

Enable the NQA client

nqa agent enable

Optional

Enabled by default.

Creating an NQA test group

Create an NQA test group before you configure NQA tests.

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	Required In the NQA test group view, you can specify the test type You can use the nqa entry command to enter the test type view of an NQA test group with test type configured.

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

Required

In the NQA test group view, you can specify the test type

You can use the nqa entry command to enter the test type view of an NQA test group with test type configured.

Configuring an NQA test group

Configuring ICMP echo tests

ICMP echo tests of an NQA test group uses ICMP echo response information to test reachability of a destination host. An ICMP echo test has the same function as the ping command but provides more output information. In addition, you can specify the next hop for ICMP echo tests. ICMP echo tests are used to locate connectivity problems in a network.

Follow these steps to configure ICMP echo tests:

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	Required
Configure the destination address of ICMP echo requests	destination ip ip-address	Required By default, no destination IP address is configured.
Configure the size of the data field in each ICMP echo request	data-size size	Optional 100 bytes by default.
Configure the string to be filled in the data field of each ICMP echo request	data-fill string	Optional By default, the string is the hexadecimal number 00010203040506070809.
Configure the source interface for ICMP echo requests. The requests take the IP address of the source interface as their source IP address when no source IP address is specified.	source interface interface-type interface-number	Optional By default, no source interface is configured for probe packets. The specified source interface must be up; otherwise, no ICMP echo requests can be sent out.
Configure the source IP address of ICMP echo requests	source ip ip-address	Optional By default, no source IP address is configured. If you configure both the source ip command and the source interface command, the source ip command takes effect. The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no ICMP echo requests can be sent out.
Configure the next hop IP address of ICMP echo requests	next-hop ip-address	Optional By default, no next hop IP address is configured.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

Configuring DHCP tests

DHCP tests of an NQA test group are used to test if a DHCP server is on the network, and the time for the DHCP server to respond to a client request and assign an IP address to the client.

Configuration prerequisites

Before you start DHCP tests, 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 the Layer 3 Configuration Guide. The switching engine on a WX3000E wireless switch does not support acting as the DHCP server.

Configuring DHCP tests

Follow these steps to configure DHCP tests:

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	Required
Specify an interface to perform DHCP tests	operation interface interface-type interface-number	Required By default, no interface is configured to perform DHCP tests. The specified interface must be up; otherwise, no probe packets can be sent out.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

NOTE:

· The interface that performs DHCP tests does not change its IP address. A DHCP test only simulates address allocation in DHCP.

· When a DHCP test completes, the NQA client sends a DHCP-RELEASE packet to release the obtained IP address.

Configuring DNS tests

DNS tests of an NQA test group are used to test whether the NQA client can translate a domain name into an IP address through a DNS server and test the time required for resolution.

Configuration prerequisites

Before you start DNS tests, configure the mapping between a domain name and an IP address on a DNS server.

Configuring DNS tests

Follow these steps to configure DNS tests:

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	Required
Specify the IP address of the DNS server as the destination address of DNS packets	destination ip ip-address	Required By default, no destination IP address is configured.
Configure the domain name that needs to be translated	resolve-target domain-name	Required By default, no domain name is configured.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

NOTE:

A DNS test simulates the domain name resolution. It does not save the mapping between the domain name and the IP address.

Configuring FTP tests

FTP tests of an NQA test group are used to test the connection between the NQA client and an FTP server and the time required for the FTP client to transfer a file to or download a file from the FTP server.

Configuration prerequisites

Before you start FTP tests, configure the FTP server. For example, configure a username and password that are used to log in to the FTP server. For more information about FTP server configuration, see the Fundamentals Configuration Guide.

Configuring FTP tests

Follow these steps to configure FTP tests:

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	Required
Specify the IP address of the FTP server as the destination address of FTP request packets	destination ip ip-address	Required By default, no destination IP address is configured.
Configure the source IP address of FTP request packets	source ip ip-address	Required By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no FTP requests can be sent out.
Configure the operation type	operation { get \| put }	Optional By default, the operation type for the FTP is get, which means obtaining files from the FTP server.
Configure a login username	username name	Required By default, no login username is configured.
Configure a login password	password password	Required By default, no login password is configured.
Specify a file to be transferred between the FTP server and the FTP client	filename file-name	Required By default, no file is specified.
Set the data transmission mode for FTP tests	mode { active \| passive }	Optional active by default.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

NOTE:

· 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 download a file that does not exist on the FTP server, FTP tests fail.

· When you execute the get command, use a file with a small size. A big file may result in test failure due to timeout, or may affect other services for occupying too much network bandwidth.

Configuring HTTP tests

HTTP tests of an NQA test group are used to test the connection between the NQA client and an HTTP server, and the time required to obtain data from the HTTP server. HTTP tests enable you to detect the connectivity and performance of the HTTP server.

Configuration prerequisites

Before you start HTTP tests, configure the HTTP server.

Configuring HTTP tests

Follow these steps to configure HTTP tests:

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	Required
Configure the IP address of the HTTP server as the destination address of HTTP request packets	destination ip ip-address	Required By default, no destination IP address is configured.
Configure the source IP address of request packets	source ip ip-address	Optional By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.
Configure the operation type	operation { get \| post }	Optional 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	Required
Configure the HTTP version used in HTTP tests	http-version v1.0	Optional By default, HTTP 1.0 is used.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

NOTE:

The TCP port must be port 80 on the HTTP server for NQA HTTP tests.

Configuring UDP jitter tests

NOTE:

Do not perform NQA UDP jitter tests on known ports, ports from 1 to 1023. Otherwise, UDP jitter tests might fail or the corresponding services of this port might be unavailable.

Real-time services such as voice and video have high requirements on delay jitters. UDP jitter tests of an NQA test group obtain uni/bi-directional delay jitters. The test results help you verify whether a network can carry real-time services.

A UDP jitter test takes the following procedure:

1. The source sends packets at regular intervals to the destination port.

2. The destination affixes a time stamp to each packet that it receives, and then sends it back to the source.

3. Upon receiving the response, the source calculates the delay jitter, which reflects network performance. Delay refers to the amount of time it takes a packet to be transmitted from source to destination or from destination to source. Delay jitter is the delay variation over time.

Configuration prerequisites

UDP jitter tests require cooperation between the NQA server and the NQA client. Before you start UDP jitter tests, configure UDP listening services on the NQA server. For more information about UDP listening service configuration, see “Configuring the NQA server.”

Configuring UDP jitter tests

Follow these steps to configure UDP jitter tests:

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	Required
Configure the destination address of UDP packets	destination ip ip-address	Required By default, no destination IP address is configured. The destination IP address must be the same as that of the listening service on the NQA server.
Configure the destination port of UDP packets	destination port port-number	Required By default, no destination port number is configured. The destination port must be the same as that of the listening service on the NQA server.
Specify the source port number of UDP packets	source port port-number	Optional By default, no source port number is specified.
Configure the size of the data field in each UDP packet	data-size size	Optional 100 bytes by default.
Configure the string to be filled in the data field of each probe packet	data-fill string	Optional By default, the string is the hexadecimal number 00010203040506070809.
Configure the number of probe packets to be sent during each UDP jitter probe operation	probe packet-number packet-number	Optional 10 by default.
Configure the interval for sending probe packets during each UDP jitter probe operation	probe packet-interval packet-interval	Optional 20 milliseconds by default.
Configure the interval the NQA client must wait for a response from the server before it regards the response is timed out	probe packet-timeout packet-timeout	Optional 3000 milliseconds by default.
Configure the source IP address for UDP jitter packets	source ip ip-address	Optional By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

NOTE:

The probe count command specifies the number of probe operations during one UDP jitter test. The probe packet-number command specifies the number of probe packets sent in each UDP jitter probe operation.

Configuring SNMP tests

SNMP tests of an NQA test group are used to test the time the NQA client takes to send an SNMP packet to the SNMP agent and receive a response.

Configuration prerequisites

Before you start SNMP tests, enable the SNMP agent function on the device that serves as an SNMP agent. For more information abut SNMP agent configuration, see the chapter “SNMP configuration.”

Configuring SNMP tests

Follow these steps to configure SNMP tests:

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	Required
Configure the destination address of SNMP packets	destination ip ip-address	Required By default, no destination IP address is configured.
Specify the source port of SNMP packets	source port port-number	Optional By default, no source port number is specified.
Configure the source IP address of SNMP packets	source ip ip-address	Optional By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

Configuring TCP tests

TCP tests of an NQA test group are used to test the TCP connection between the NQA client and a port on the NQA server and the time for setting up a connection. The test result helps you understand the availability and performance of the services provided by the port on the server.

Configuration prerequisites

TCP tests require cooperation between the NQA server and the NQA client. Before you start TCP tests, configure a TCP listening service on the NQA server. For more information about the TCP listening service configuration, see “Configuring the NQA server.”

Configuring TCP tests

Follow these steps to configure TCP tests:

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 TCP and enter test type view	type tcp	Required
Configure the destination address of TCP probe packets	destination ip ip-address	Required By default, no destination IP address is configured. The destination address must be the same as the IP address of the listening service configured on the NQA server.
Configure the destination port of TCP probe packets	destination port port-number	Required By default, no destination port number is configured. The destination port number must be the same as that of the listening service on the NQA server.
Configure the source IP address of TCP probe packets	source ip ip-address	Optional By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

Configuring UDP echo tests

UDP echo tests of an NQA test group are used to test the connectivity and round-trip time of a UDP packet from the client to the specified UDP port on the NQA server.

Configuration prerequisites

UDP echo tests require cooperation between the NQA server and the NQA client. Before you start UDP echo tests, configure a UDP listening service on the NQA server. For more information about the UDP listening service configuration, see “Configuring the NQA server.”

Configuring UDP echo tests

Follow these steps to configure UDP echo tests:

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 echo and enter test type view	type udp-echo	Required
Configure the destination address of UDP packets	destination ip ip-address	Required By default, no destination IP address is configured. The destination address must be the same as the IP address of the listening service configured on the NQA server.
Configure the destination port of UDP packets	destination port port-number	Required By default, no destination port number is configured. The destination port number must be the same as that of the listening service on the NQA server.
Configure the size of the data field in each UDP packet	data-size size	Optional 100 bytes by default.
Configure the string to be filled in the data field of each UDP packet	data-fill string	Optional By default, the string is the hexadecimal number 00010203040506070809.
Specify the source port of UDP packets	source port port-number	Optional By default, no source port number is specified.
Configure the source IP address of UDP packets	source ip ip-address	Optional 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, no probe packets can be sent out.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

Configuring voice tests

NOTE:

Do not perform voice tests on known ports, ports from 1 to 1023. Otherwise, the NQA test might fail or the corresponding services of these ports might be unavailable.

Voice tests of an NQA test group are used to test voice over IP (VoIP) network status, and collect VoIP network parameters so that users can adjust the network.

A voice test takes the following procedure:

1. The source (NQA client) sends voice packets of G.711 A-law, G.711 µ-law or G.729 A-law codec type at regular intervals to the destination (NQA server).

2. The destination affixes a time stamp to each voice packet that it receives and then sends it back to the source.

3. Upon receiving the packet, the source calculates results, such as the delay jitter and one-way delay based on the packet time stamps. The statistics reflect network performance.

Voice test result also includes the following parameters that reflect VoIP network performance:

· Calculated Planning Impairment Factor (ICPIF)—Measures impairment to voice quality in a VoIP network. It is decided by packet loss and delay. A higher value represents a lower service quality.

· Mean Opinion Scores (MOS)—A MOS value can be evaluated by using the ICPIF value, in the range 1 to 5. A higher value represents a higher quality of a VoIP network.

The evaluation of voice quality depends on users’ tolerance to voice quality, which should be taken into consideration. For users with higher tolerance to voice quality, use the advantage-factor command to configure the advantage factor. When the system calculates the ICPIF value, this advantage factor is subtracted to modify ICPIF and MOS values, so objective and subjective factors are both considered when you evaluate the voice quality.

Configuration prerequisites

Voice tests require cooperation between the NQA server and the NQA client. Before you start voice tests, configure a UDP listening service on the NQA server. For more information about UDP listening service configuration, see “Configuring the NQA server.”

Configuring voice tests

Follow these steps to configure voice tests:

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 voice and enter test type view	type voice	Required
Configure the destination address of voice probe packets	destination ip ip-address	Required By default, no destination IP address is configured for a test operation. The destination IP address must be the same as that of the listening service on the NQA server.
Configure the destination port of voice probe packets	destination port port-number	Required By default, no destination port number is configured. The destination port must be the same as that of the listening service on the NQA server.
Configure the codec type	codec-type { g711a \| g711u \| g729a }	Optional By default, the codec type is G.711 A-law.
Configure the advantage factor for calculating MOS and ICPIF values	advantage-factor factor	Optional By default, the advantage factor is 0.
Specify the source IP address of probe packets	source ip ip-address	Optional By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.
Specify the source port number of probe packets	source port port-number	Optional By default, no source port number is specified.
Configure the size of the data field in each probe packet	data-size size	Optional By default, the probe packet size depends on the codec type. The default packet size is 172 bytes for G.711A-law and G.711 µ-law codec type, and is 32 bytes for G.729 A-law codec type.
Configure the string to be filled in the data field of each probe packet	data-fill string	Optional By default, the string is the hexadecimal number 00010203040506070809.
Configure the number of probe packets to be sent during each voice probe operation	probe packet-number packet-number	Optional 1000 by default.
Configure the interval for sending probe packets during each voice probe operation	probe packet-interval packet-interval	Optional 20 milliseconds by default.
Configure the interval the NQA client must wait for a response from the server before it regards the response times out	probe packet-timeout packet-timeout	Optional 5000 milliseconds by default.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

NOTE:

Only one probe operation is performed in one voice test.

Configuring DLSw tests

DLSw tests of an NQA test group are used to test the response time of a DLSw device.

Configuration prerequisites

Before you start DLSw tests, enable the DLSw function on the peer device.

Configuring a DLSw test

Follow these steps to configure DLSw tests:

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 DLSw and enter test type view	type dlsw	Required
Configure the destination address of probe packets	destination ip ip-address	Required By default, no destination IP address is configured.
Configure the source IP address of probe packets	source ip ip-address	Optional By default, no source IP address is specified. The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.
Configure optional parameters	See “Configuring optional parameters for an NQA test group”	Optional

Configuring threshold monitoring

Configuration prerequisites

Before you configure threshold monitoring, complete the following tasks:

· Configure the destination address of the trap message by using the snmp-agent target-host command. For more information about the snmp-agent target-host command, see the Network Management and Monitoring Command Reference.

· Create an NQA test group and configure related parameters.

Configuring threshold monitoring

Follow these steps to configure threshold monitoring:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter NQA test group view	nqa entry admin-name operation-tag	—
Enter test type view of the test group	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	—
Configure to send traps to the network management server under specified conditions	reaction trap { probe-failure consecutive-probe-failures \| test-complete \| test-failure cumulate-probe-failures }	Required Configure to send traps. No traps are sent to the network management server by default.
Configure a reaction entry for monitoring the probe duration of a test (not supported in UDP jitter and voice tests)	reaction item-number checked-element probe-duration threshold-type { accumulate accumulate-occurrences \| average \| consecutive consecutive-occurrences } threshold-value upper-threshold lower-threshold [ action-type { none \| trap-only } ]
Configure a reaction entry for monitoring the probe failure times (not supported in UDP jitter and voice tests)	reaction item-number checked-element probe-fail threshold-type { accumulate accumulate-occurrences \| consecutive consecutive-occurrences } [ action-type { none \| trap-only } ]
Configure a reaction entry for monitoring packet round-trip time (only supported in UDP jitter and voice tests)	reaction item-number checked-element rtt threshold-type { accumulate accumulate-occurrences \| average } threshold-value upper-threshold lower-threshold [ action-type { none \| trap-only } ]
Configure a reaction entry for monitoring the packet loss in each test (only supported in UDP jitter and voice tests)	reaction item-number checked-element packet-loss threshold-type accumulate accumulate-occurrences [ action-type { none \| trap-only } ]
Configure a reaction entry for monitoring one-way delay jitter (only supported in UDP jitter and voice tests)	reaction item-number checked-element { jitter-ds \| jitter-sd } threshold-type { accumulate accumulate-occurrences \| average } threshold-value upper-threshold lower-threshold [ action-type { none \| trap-only } ]
Configure a reaction entry for monitoring the one-way delay (only supported in UDP jitter and voice tests)	reaction item-number checked-element { owd-ds \| owd-sd } threshold-value upper-threshold lower-threshold
Configure a reaction entry for monitoring the ICPIF value (only supported in voice tests)	reaction item-number checked-element icpif threshold-value upper-threshold lower-threshold [ action-type { none \| trap-only } ]
Configure a reaction entry for monitoring the MOS value (only supported in voice tests)	reaction item-number checked-element mos threshold-value upper-threshold lower-threshold [ action-type { none \| trap-only } ]

NOTE:

· NQA DNS tests do not support the action of sending trap messages. The action to be triggered in DNS tests can only be the default one, none.

· Only the test-complete keyword is supported for the reaction trap command in a voice test.

Configuring the NQA statistics collection function

NQA groups tests completed in a time period for a test group, and calculates the test result statistics. The statistics form a statistics group. To view information about the statistics groups, use the display nqa statistics command. To set the interval for collecting statistics, use the statistics interval command.

When the number of statistics groups kept reaches the upper limit and a new statistics group is to be saved, the oldest statistics group is deleted. To set the maximum number of statistics groups that can be kept, use the statistics max-group command.

A statistics group is formed after the last test is completed within the specified interval. Statistics groups have an aging mechanism. A statistics group is deleted when its hold time expires. To set the hold time of statistics groups for a test group, use the statistics hold-time command.

Follow these steps to configure the NQA statistics collection function:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter NQA test group view	nqa entry admin-name operation-tag	—
Enter test type view of the test group	type { dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	—
Configure the interval for collecting the statistics of test results	statistics interval interval	Optional 60 minutes by default.
Configure the maximum number of statistics groups that can be kept	statistics max-group number	Optional 2 by default. To disable collecting NQA statistics, set the maximum number to 0.
Configure the hold time of statistics groups	statistics hold-time hold-time	Optional 120 minutes by default.

NOTE:

· The NQA statistics collection function is not supported in DHCP tests.

· If you use the frequency command to set the frequency between two consecutive tests to 0, only one test is performed, and no statistics group information is collected.

Configuring the history records saving function

The history records saving function enables the system to save the history records of NQA tests. To view the history records of a test group, use the display nqa history command.

In addition, you can configure the following elements:

· Lifetime of the history records—The records are removed when the lifetime is reached.

· The maximum number of history records that can be saved in a test group—If the number of history records in a test group exceeds the maximum number, the earliest history records are removed.

Follow these steps to configure the history records saving function of an NQA test group:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter NQA test group view	nqa entry admin-name operation-tag	—
Enter NQA test type view	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	—
Enable the saving of the history records of the NQA test group	history-record enable	Required By default, history records of the NQA test group are not saved.
Set the lifetime of the history records in an NQA test group	history-record keep-time keep-time	Optional By default, the history records in the NQA test group are kept for 120 minutes.
Configure the maximum number of history records that can be saved for a test group	history-record number number	Optional By default, the maximum number of records that can be saved for a test group is 50

Configuring optional parameters for an NQA test group

Optional parameters for an NQA test group are valid only for tests in this test group.

Unless otherwise specified, the following optional parameters are applicable to all test types.

Follow these steps to configure optional parameters for an NQA test group:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter NQA test group view	nqa entry admin-name operation-tag	—
Enter test type view of a test group	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	—
Configure the description for a test group	description text	Optional By default, no description is available for a test group.
Configure the interval between two consecutive tests for a test group	frequency interval	Optional By default, the interval between two consecutive tests for a test group is 0 milliseconds. Only one test is performed. If the last test is not completed when the interval specified by the frequency command is reached, a new test does not start.
Configure the number of probe operations to be performed in one test	probe count times	Optional By default, one probe operation is performed in one test. Not available for voice tests, Only one probe operation can be performed in one voice test.
Configure the NQA probe timeout time	probe timeout timeout	Optional By default, the timeout time is 3000 milliseconds. Not available for UDP jitter tests.
Configure the maximum number of hops a probe packet traverses in the network	ttl value	Optional 20 by default. Not available for DHCP tests.
Configure the ToS field in an IP packet header in an NQA probe packet	tos value	Optional 0 by default. Not available for DHCP tests.
Enable the routing table bypass function	route-option bypass-route	Optional Disabled by default. Not available for DHCP tests.

Configuring a schedule for an NQA test group

You can configure a schedule for an NQA test group by setting the start time and test duration for a test group.

A test group performs tests between the scheduled start time and the end time (the start time plus test duration). If the scheduled start time is ahead of the system time, the test group starts testing immediately. If both the scheduled start and end time are behind the system time, no test will start. To view the current system time, use the display clock command.

Configuration prerequisites

Before you configure a schedule for an NQA test group, complete the following tasks:

· Configure test parameters required for the test type.

· Configure the NQA server for tests that require cooperation with the NQA server.

Scheduling an NQA test group

Follow these steps to configure a schedule for an NQA test group:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Configure a schedule for an NQA test group	nqa schedule admin-name operation-tag start-time { hh:mm:ss [ yyyy/mm/dd ] \| now } lifetime { lifetime \| forever }	Required now specifies the test group starts testing immediately. forever specifies that the tests do not stop unless you use the undo nqa schedule command.
Configure the maximum number of tests that the NQA client can simultaneously perform	nqa agent max-concurrent number	Optional The default setting is 2.

NOTE:

· After an NQA test group is scheduled, you cannot enter the test group view or test type view.

· System adjustment does not affect started or completed test groups. It only affects test groups that have not started.

Displaying and maintaining NQA

To do…	Use the command…	Remarks
Display history records of NQA test groups	display nqa history [ admin-name operation-tag ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the current monitoring results of reaction entries	display nqa reaction counters [ admin-name operation-tag [ item-number ] ] [ \| { begin \| exclude \| include } regular-expression ]
Display the results of the last NQA test	display nqa result [ admin-name operation-tag ] [ \| { begin \| exclude \| include } regular-expression ]
Display statistics of test results for the specified or all test groups	display nqa statistics [ admin-name operation-tag ] [ \| { begin \| exclude \| include } regular-expression ]
Display NQA server status	display nqa server status [ \| { begin \| exclude \| include } regular-expression ]

NQA configuration examples

ICMP echo test configuration example

Network requirements

As shown in Figure 2, configure NQA ICMP echo tests to test whether the NQA client (Device A) can send packets through a specified next hop to a specified destination (Device B) and test the round-trip time of the packets.

Figure 2 Network diagram for ICMP echo tests

Configuration procedure

NOTE:

Before you make the configuration, make sure the devices can reach each other.

# Create an ICMP echo test group and specify 10.2.2.2 as the destination IP address for ICMP echo requests to be sent.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type icmp-echo

[DeviceA-nqa-admin-test-icmp-echo] destination ip 10.2.2.2

# Configure 10.1.1.2 as the next hop IP address for ICMP echo requests. The ICMP echo requests are sent to Device C to Device B (the destination).

[DeviceA-nqa-admin-test-icmp-echo] next-hop 10.1.1.2

# Configure the device to perform 10 probe operations per test, perform tests at an interval of 5000 milliseconds. Set the NQA probe timeout time as 500 milliseconds.

[DeviceA-nqa-admin-test-icmp-echo] probe count 10

[DeviceA-nqa-admin-test-icmp-echo] probe timeout 500

[DeviceA-nqa-admin-test-icmp-echo] frequency 5000

# Enable the saving of history records and configure the maximum number of history records that can be saved for a test group.

[DeviceA-nqa-admin-test-icmp-echo] history-record enable

[DeviceA-nqa-admin-test-icmp-echo] history-record number 10

[DeviceA-nqa-admin-test-icmp-echo] quit

# Start ICMP echo tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop the ICMP echo tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last ICMP echo test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 10 Receive response times: 10

Min/Max/Average round trip time: 2/5/3

Square-Sum of round trip time: 96

Last succeeded probe time: 2007-08-23 15:00:01.2

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

# Display the history of ICMP echo tests.

[DeviceA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

370 3 Succeeded 2007-08-23 15:00:01.2

369 3 Succeeded 2007-08-23 15:00:01.2

368 3 Succeeded 2007-08-23 15:00:01.2

367 5 Succeeded 2007-08-23 15:00:01.2

366 3 Succeeded 2007-08-23 15:00:01.2

365 3 Succeeded 2007-08-23 15:00:01.2

364 3 Succeeded 2007-08-23 15:00:01.1

363 2 Succeeded 2007-08-23 15:00:01.1

362 3 Succeeded 2007-08-23 15:00:01.1

361 2 Succeeded 2007-08-23 15:00:01.1

DHCP test configuration example

Network requirements

As shown in Figure 3, configure NQA DHCP tests to test the time required for Device A to obtain an IP address from the DHCP server (Device B).

Figure 3 Network diagram for DHCP tests

Configuration procedure

# Create a DHCP test group and specify interface VLAN-interface 2 to perform NQA DHCP tests.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type dhcp

[DeviceA-nqa-admin-test-dhcp] operation interface vlan-interface 2

# Enable the saving of history records.

[DeviceA-nqa-admin-test-dhcp] history-record enable

[DeviceA-nqa-admin-test-dhcp] quit

# Start DHCP tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Display the result of the last DHCP test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 624/624/624

Square-Sum of round trip time: 389376

Last succeeded probe time: 2007-11-22 09:56:03.2

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

# Display the history of DHCP tests.

[SwitchA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

1 624 Succeeded 2007-11-22 09:56:03.2

DNS test configuration example

Network requirements

As shown in Figure 4, configure NQA DNS tests to test whether Device A can translate the domain name host.com into an IP address through the DNS server and test the time required for resolution.

Figure 4 Network diagram for DNS tests

Configuration procedure

# Create a DNS test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type dns

# Specify the IP address of the DNS server 10.2.2.2 as the destination address for DNS tests, and specify the domain name that needs to be translated as host.com.

[DeviceA-nqa-admin-test-dns] destination ip 10.2.2.2

[DeviceA-nqa-admin-test-dns] resolve-target host.com

# Enable the saving of history records.

[DeviceA-nqa-admin-test-dns] history-record enable

[DeviceA-nqa-admin-test-dns] quit

# Start DNS tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop the DNS tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last DNS test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 62/62/62

Square-Sum of round trip time: 3844

Last succeeded probe time: 2008-11-10 10:49:37.3

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

# Display the history of DNS tests.

[DeviceA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

1 62 Succeeded 2008-11-10 10:49:37.3

FTP test configuration example

Network requirements

As shown in Figure 5, configure NQA FTP tests to test the connection with a specified FTP server and the time required for Device A to upload a file to the FTP server. The login username is admin, the login password is systemtest, and the file to be transferred to the FTP server is config.txt.

Figure 5 Network diagram for FTP tests

Configuration procedure

# Create an FTP test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type ftp

# Specify the IP address of the FTP server 10.2.2.2 as the destination IP address for FTP tests.

[DeviceA-nqa-admin-test-ftp] destination ip 10.2.2.2

# Specify 10.1.1.1 as the source IP address for probe packets.

[DeviceA-nqa-admin-test-ftp] source ip 10.1.1.1

# Set the FTP username to admin, and password to systemtest.

[DeviceA-nqa-admin-test-ftp] username admin

[DeviceA-nqa-admin-test-ftp] password systemtest

# Configure the device to upload file config.txt to the FTP server for each probe operation.

[DeviceA-nqa-admin-test-ftp] operation put

[DeviceA-nqa-admin-test-ftp] filename config.txt

# Enable the saving of history records.

[DeviceA-nqa-admin-test-ftp] history-record enable

[DeviceA-nqa-admin-test-ftp] quit

# Start FTP tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop the FTP tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last FTP test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 173/173/173

Square-Sum of round trip time: 29929

Last succeeded probe time: 2007-11-22 10:07:28.6

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

# Display the history of FTP tests.

[DeviceA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

1 173 Succeeded 2007-11-22 10:07:28.6

HTTP test configuration example

Network requirements

As shown in Figure 6, configure NQA HTTP tests to test the connection with a specified HTTP server and the time required to obtain data from the HTTP server.

Figure 6 Network diagram for the HTTP tests

Configuration procedure

# Create an HTTP test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type http

# Specify the IP address of the HTTP server 10.2.2.2 as the destination IP address for HTTP tests.

[DeviceA-nqa-admin-test-http] destination ip 10.2.2.2

# Configure the device to get data from the HTTP server for each HTTP probe operation. (get is the default HTTP operation type, and this step can be omitted.)

[DeviceA-nqa-admin-test-http] operation get

# Configure HTTP tests to visit website /index.htm.

[DeviceA-nqa-admin-test-http] url /index.htm

# Configure the HTTP version 1.0 to be used in HTTP tests. (Version 1.0 is the default version, and this step can be omitted.)

[DeviceA-nqa-admin-test-http] http-version v1.0

# Enable the saving of history records.

[DeviceA-nqa-admin-test-http] history-record enable

[DeviceA-nqa-admin-test-http] quit

# Start HTTP tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop HTTP tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display results of the last HTTP test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 64/64/64

Square-Sum of round trip time: 4096

Last succeeded probe time: 2007-11-22 10:12:47.9

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors:

Packet(s) arrived late: 0

# Display the history of HTTP tests.

[DeviceA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

1 64 Succeeded 2007-11-22 10:12:47.9

UDP jitter test configuration example

Network requirements

As shown in Figure 7, configure NQA UDP jitter tests to test the delay jitter of packet transmission between Device A and Device B.

Figure 7 Network diagram for UDP jitter tests

Configuration procedure

1. Configure Device B

# Enable the NQA server and configure a listening service to listen to IP address 10.2.2.2 and port 9000.

<DeviceB> system-view

[DeviceB] nqa server enable

[DeviceB] nqa server udp-echo 10.2.2.2 9000

2. Configure Device A

# Create a UDP jitter test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type udp-jitter

# Configure UDP jitter packets to use 10.2.2.2 as the destination IP address and port 9000 as the destination port.

[DeviceA-nqa-admin-test-udp-jitter] destination ip 10.2.2.2

[DeviceA-nqa-admin-test-udp-jitter] destination port 9000

# Configure the device to perform UDP jitter tests at an interval of 1000 milliseconds.

[DeviceA-nqa-admin-test-udp-jitter] frequency 1000

[DeviceA-nqa-admin-test-udp-jitter] quit

# Start UDP jitter tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop UDP jitter tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last UDP jitter test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 10 Receive response times: 10

Min/Max/Average round trip time: 15/32/17

Square-Sum of round trip time: 3235

Last succeeded probe time: 2008-05-29 13:56:17.6

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

UDP-jitter results:

RTT number: 10

Min positive SD: 4 Min positive DS: 1

Max positive SD: 21 Max positive DS: 28

Positive SD number: 5 Positive DS number: 4

Positive SD sum: 52 Positive DS sum: 38

Positive SD average: 10 Positive DS average: 10

Positive SD square sum: 754 Positive DS square sum: 460

Min negative SD: 1 Min negative DS: 6

Max negative SD: 13 Max negative DS: 22

Negative SD number: 4 Negative DS number: 5

Negative SD sum: 38 Negative DS sum: 52

Negative SD average: 10 Negative DS average: 10

Negative SD square sum: 460 Negative DS square sum: 754

One way results:

Max SD delay: 15 Max DS delay: 16

Min SD delay: 7 Min DS delay: 7

Number of SD delay: 10 Number of DS delay: 10

Sum of SD delay: 78 Sum of DS delay: 85

Square sum of SD delay: 666 Square sum of DS delay: 787

SD lost packet(s): 0 DS lost packet(s): 0

Lost packet(s) for unknown reason: 0

# Display the statistics of UDP jitter tests.

[DeviceA] display nqa statistics admin test

NQA entry (admin admin, tag test) test statistics:

NO. : 1

Destination IP address: 10.2.2.2

Start time: 2008-05-29 13:56:14.0

Life time: 47 seconds

Send operation times: 410 Receive response times: 410

Min/Max/Average round trip time: 1/93/19

Square-Sum of round trip time: 206176

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

UDP-jitter results:

RTT number: 410

Min positive SD: 3 Min positive DS: 1

Max positive SD: 30 Max positive DS: 79

Positive SD number: 186 Positive DS number: 158

Positive SD sum: 2602 Positive DS sum: 1928

Positive SD average: 13 Positive DS average: 12

Positive SD square sum: 45304 Positive DS square sum: 31682

Min negative SD: 1 Min negative DS: 1

Max negative SD: 30 Max negative DS: 78

Negative SD number: 181 Negative DS number: 209

Negative SD sum: 181 Negative DS sum: 209

Negative SD average: 13 Negative DS average: 14

Negative SD square sum: 46994 Negative DS square sum: 3030

One way results:

Max SD delay: 46 Max DS delay: 46

Min SD delay: 7 Min DS delay: 7

Number of SD delay: 410 Number of DS delay: 410

Sum of SD delay: 3705 Sum of DS delay: 3891

Square sum of SD delay: 45987 Square sum of DS delay: 49393

SD lost packet(s): 0 DS lost packet(s): 0

Lost packet(s) for unknown reason: 0

NOTE:

The display nqa history command does not show the results of UDP jitter tests. To know the result of a UDP jitter test, use the display nqa result command to view the probe results of the latest NQA test, or use the display nqa statistics command to view the statistics of NQA tests.

SNMP test configuration example

Network requirements

As shown in Figure 8, configure NQA SNMP tests to test the time it takes for Device A to send an SNMP query packet to the SNMP agent and receive a response packet.

Figure 8 Network diagram for SNMP tests

Configuration procedure

1. Configure theSNMP agent (Device B)

# Enable the SNMP agent service and set the SNMP version to all, the read community to public, and the write community to private.

<DeviceB> system-view

[DeviceB] snmp-agent sys-info version all

[DeviceB] snmp-agent community read public

[DeviceB] snmp-agent community write private

2. Configure Device A

# Create an SNMP test group and configure SNMP packets to use 10.2.2.2 as their destination IP address.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type snmp

[DeviceA-nqa-admin-test-snmp] destination ip 10.2.2.2

# Enable the saving of history records.

[DeviceA-nqa-admin-test-snmp] history-record enable

[DeviceA-nqa-admin-test-snmp] quit

# Start SNMP tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop the SNMP tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last SNMP test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 50/50/50

Square-Sum of round trip time: 2500

Last succeeded probe time: 2007-11-22 10:24:41.1

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

# Display the history of SNMP tests.

[DeviceA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

1 50 Timeout 2007-11-22 10:24:41.1

TCP test configuration example

Network requirements

As shown in Figure 9, configure NQA TCP tests to test the time for establishing a TCP connection between Device A and Device B.

Figure 9 Network diagram for TCP tests

Configuration procedure

1. Configure Device B

# Enable the NQA server and configure a listening service to listen to IP address 10.2.2.2 and TCP port 9000.

<DeviceB> system-view

[DeviceB] nqa server enable

[DeviceB] nqa server tcp-connect 10.2.2.2 9000

2. Configure Device A

# Create a TCP test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type tcp

# Configure TCP probe packets to use 10.2.2.2 as the destination IP address and port 9000 as the destination port.

[DeviceA-nqa-admin-test-tcp] destination ip 10.2.2.2

[DeviceA-nqa-admin-test-tcp] destination port 9000

# Enable the saving of history records.

[DeviceA-nqa-admin-test-tcp] history-record enable

[DeviceA-nqa-admin-test-tcp] quit

# Start TCP tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop the TCP tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last TCP test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 13/13/13

Square-Sum of round trip time: 169

Last succeeded probe time: 2007-11-22 10:27:25.1

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

# Display the history of TCP tests.

[DeviceA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

1 13 Succeeded 2007-11-22 10:27:25.1

UDP echo test configuration example

Network requirements

As shown in Figure 10, configure NQA UDP echo tests to test the round-trip time between Device A and Device B. The destination port number is 8000.

Figure 10 Network diagram for the UDP echo tests

Configuration procedure

1. Configure Device B

# Enable the NQA server and configure a listening service to listen to IP address 10.2.2.2 and UDP port 8000.

<DeviceB> system-view

[DeviceB] nqa server enable

[DeviceB] nqa server udp-echo 10.2.2.2 8000

2. Configure Device A

# Create a UDP echo test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type udp-echo

# Configure UDP packets to use 10.2.2.2 as the destination IP address and port 8000 as the destination port.

[DeviceA-nqa-admin-test-udp-echo] destination ip 10.2.2.2

[DeviceA-nqa-admin-test-udp-echo] destination port 8000

# Enable the saving of history records.

[DeviceA-nqa-admin-test-udp-echo] history-record enable

[DeviceA-nqa-admin-test-udp-echo] quit

# Start UDP echo tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop UDP echo tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last UDP echo test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 25/25/25

Square-Sum of round trip time: 625

Last succeeded probe time: 2007-11-22 10:36:17.9

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

# Display the history of UDP echo tests.

[DeviceA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

1 25 Succeeded 2007-11-22 10:36:17.9

Voice test configuration example

Network requirements

As shown in Figure 11, configure NQA voice tests to test the delay jitter of voice packet transmission and voice quality between Device A and Device B.

Figure 11 Network diagram for voice tests

Configuration procedure

1. Configure Device B

# Enable the NQA server and configure a listening service to listen to IP address 10.2.2.2 and UDP port 9000.

<DeviceB> system-view

[DeviceB] nqa server enable

2. [DeviceB] nqa server udp-echo 10.2.2.2 9000

3. Configure Device A

# Create a voice test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type voice

# Configure voice probe packets to use 10.2.2.2 as the destination IP address and port 9000 as the destination port.

[DeviceA-nqa-admin-test-voice] destination ip 10.2.2.2

[DeviceA-nqa-admin-test-voice] destination port 9000

[DeviceA-nqa-admin-test-voice] quit

# Start voice tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop the voice tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last voice test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 1000 Receive response times: 1000

Min/Max/Average round trip time: 31/1328/33

Square-Sum of round trip time: 2844813

Last succeeded probe time: 2008-06-13 09:49:31.1

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

Voice results:

RTT number: 1000

Min positive SD: 1 Min positive DS: 1

Max positive SD: 204 Max positive DS: 1297

Positive SD number: 257 Positive DS number: 259

Positive SD sum: 759 Positive DS sum: 1797

Positive SD average: 2 Positive DS average: 6

Positive SD square sum: 54127 Positive DS square sum: 1691967

Min negative SD: 1 Min negative DS: 1

Max negative SD: 203 Max negative DS: 1297

Negative SD number: 255 Negative DS number: 259

Negative SD sum: 759 Negative DS sum: 1796

Negative SD average: 2 Negative DS average: 6

Negative SD square sum: 53655 Negative DS square sum: 1691776

One way results:

Max SD delay: 343 Max DS delay: 985

Min SD delay: 343 Min DS delay: 985

Number of SD delay: 1 Number of DS delay: 1

Sum of SD delay: 343 Sum of DS delay: 985

Square sum of SD delay: 117649 Square sum of DS delay: 970225

SD lost packet(s): 0 DS lost packet(s): 0

Lost packet(s) for unknown reason: 0

Voice scores:

MOS value: 4.38 ICPIF value: 0

# Display the statistics of voice tests.

[DeviceA] display nqa statistics admin test

NQA entry (admin admin, tag test) test statistics:

NO. : 1

Destination IP address: 10.2.2.2

Start time: 2008-06-13 09:45:37.8

Life time: 331 seconds

Send operation times: 4000 Receive response times: 4000

Min/Max/Average round trip time: 15/1328/32

Square-Sum of round trip time: 7160528

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

Voice results:

RTT number: 4000

Min positive SD: 1 Min positive DS: 1

Max positive SD: 360 Max positive DS: 1297

Positive SD number: 1030 Positive DS number: 1024

Positive SD sum: 4363 Positive DS sum: 5423

Positive SD average: 4 Positive DS average: 5

Positive SD square sum: 497725 Positive DS square sum: 2254957

Min negative SD: 1 Min negative DS: 1

Max negative SD: 360 Max negative DS: 1297

Negative SD number: 1028 Negative DS number: 1022

Negative SD sum: 1028 Negative DS sum: 1022

Negative SD average: 4 Negative DS average: 5

Negative SD square sum: 495901 Negative DS square sum: 5419

One way results:

Max SD delay: 359 Max DS delay: 985

Min SD delay: 0 Min DS delay: 0

Number of SD delay: 4 Number of DS delay: 4

Sum of SD delay: 1390 Sum of DS delay: 1079

Square sum of SD delay: 483202 Square sum of DS delay: 973651

SD lost packet(s): 0 DS lost packet(s): 0

Lost packet(s) for unknown reason: 0

Voice scores:

Max MOS value: 4.38 Min MOS value: 4.38

Max ICPIF value: 0 Min ICPIF value: 0

NOTE:

The display nqa history command cannot show you the results of voice tests. To know the result of a voice test, use the display nqa result command to view the probe results of the latest NQA test, or use the display nqa statistics command to view the statistics of NQA tests.

DLSw test configuration example

Network requirements

As shown in Figure 12, configure NQA DLSw tests to test the response time of the DLSw device.

Figure 12 Network diagram for the DLSw tests

Configuration procedure

# Create a DLSw test group and configure DLSw probe packets to use 10.2.2.2 as the destination IP address.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type dlsw

[DeviceA-nqa-admin-test-dlsw] destination ip 10.2.2.2

# Enable the saving of history records.

[DeviceA-nqa-admin-test-dlsw] history-record enable

[DeviceA-nqa-admin-test-dlsw] quit

# Start DLSw tests.

[DeviceA] nqa schedule admin test start-time now lifetime forever

# Stop the DLSw tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last DLSw test.

[DeviceA] display nqa result admin test

NQA entry (admin admin, tag test) test results:

Destination IP address: 10.2.2.2

Send operation times: 1 Receive response times: 1

Min/Max/Average round trip time: 19/19/19

Square-Sum of round trip time: 361

Last succeeded probe time: 2007-11-22 10:40:27.7

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to sequence error: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packet(s) arrived late: 0

# Display the history of DLSw tests.

[DeviceA] display nqa history admin test

NQA entry (admin admin, tag test) history record(s):

Index Response Status Time

1 19 Succeeded 2007-11-22 10:40:27.7

08-Network Management and Monitoring @CG@

NQA configuration

Supporting multiple test types

Supporting threshold monitoring

Test group

Test and probe

NQA client and server

NQA probe operation procedure

Configuring ICMP echo tests

Configuring DHCP tests

Configuration prerequisites

Configuring DHCP tests

Configuring DNS tests

Configuration prerequisites

Configuring DNS tests

Configuring FTP tests

Configuration prerequisites

Configuring FTP tests

Configuring HTTP tests

Configuration prerequisites

Configuring HTTP tests

Configuring UDP jitter tests

Configuration prerequisites

Configuring UDP jitter tests

Configuring SNMP tests

Configuration prerequisites

Configuring SNMP tests

Configuring TCP tests

Configuration prerequisites

Configuring TCP tests

Configuring UDP echo tests

Configuration prerequisites

Configuring UDP echo tests

Configuring voice tests

Configuration prerequisites

Configuring voice tests

Configuring DLSw tests

Configuration prerequisites

Configuring a DLSw test

Configuration prerequisites

Configuring threshold monitoring

Configuration prerequisites

Scheduling an NQA test group

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

News & Events

Contact Us