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 a 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. Test results help you understand network performance.

Supporting the collaboration function

Collaboration is implemented by establishing reaction entries to monitor the detection results of NQA probes. If the number of consecutive probe failures reaches a limit, NQA informs the track module of the detection result, and the track module triggers other application modules to take predefined.

Figure 1 Implementing collaboration

The collaboration comprises the following parts: the application modules, the track module, and the detection modules.

· A detection module monitors specific objects, such as the link status, and network performance, and informs the track module of detection results.

· Upon the detection results, the track module changes the status of the track entry and informs the associated application module. The track module works between the application modules and the detection modules. It hides the differences among detection modules from application modules.

· The application module takes actions when the tracked object changes its state.

The following describes how a static route is monitored through collaboration.

1. NQA monitors the reachability to 192.168.0.88.

2. When 192.168.0.88 becomes unreachable, NQA notifies it to the track module.

3. The track module notifies the state change to the static routing module

4. The static routing module sets the static route as invalid.

NOTE:

For more information about the collaboration and the track module, see High Availability Configuration Guide.

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 2 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 2.

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, complete the following tasks 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 the collaboration function		Optional
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 responds to the probe packets sent from the NQA client by listening to the specified destination address and port number.

To configure the NQA server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the NQA server.	nqa server enable	Disabled by default.
3. Configure the listening service.	nqa server { tcp-connect \| udp-echo } ip-address port-number	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.

To enable the NQA client:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the NQA client.	nqa agent enable	Optional Enabled by default

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. 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.

To create an NQA test group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA test group and enter the NQA test group view.	nqa entry admin-name operation-tag	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.

Step

Command

Remarks

1. Enter system view.

system-view

N/A

2. Create an NQA test group and enter the NQA test group view.

nqa entry admin-name operation-tag

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 use 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.

To configure ICMP echo tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as ICMP echo and enter test type view.	type icmp-echo	N/A
4. Configure the destination address of ICMP echo requests.	destination ip ip-address	By default, no destination IP address is configured.
5. Configure the size of the data field in each ICMP echo request.	data-size size	Optional. 100 bytes by default.
6. 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.
7. Apply ICMP echo tests to the specified VPN.	vpn-instance vpn-instance-name	Optional. By default, ICMP echo tests apply to the public network.
8. 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.
9. 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.
10. Configure the next hop IP address of ICMP echo requests.	next-hop ip-address	Optional. By default, no next hop IP address is configured.
11. Configure optional parameters.	See “Configuring optional parameters for an NQA test group”	Optional.

NOTE:

NQA ICMP echo tests are 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.

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 Layer 3—IP Services Configuration Guide.

Configuring DHCP tests

To configure DHCP tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as DHCP and enter test type view.	type dhcp	N/A
4. Specify an interface to perform DHCP tests.	operation interface interface-type interface-number	By default, no interface is configured to perform DHCP tests. The specified interface must be up; otherwise, no probe packets can be sent out.
5. 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

To configure DNS tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as DNS and enter test type view.	type dns	N/A
4. Specify the IP address of the DNS server as the destination address of DNS packets.	destination ip ip-address	By default, no destination IP address is configured.
5. Configure the domain name that needs to be translated.	resolve-target domain-name	By default, no domain name is configured.
6. Configure optional parameters.	See “Configuring optional parameters for an NQA test group”	Optional.

NOTE:

A DNS test only 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 Fundamentals Configuration Guide.

Configuring FTP tests

To configure FTP tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as FTP and enter test type view.	type ftp	N/A
4. Specify the IP address of the FTP server as the destination address of FTP request packets.	destination ip ip-address	By default, no destination IP address is configured.
5. Configure the source IP address of FTP request 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. The local interface must be up; otherwise, no FTP requests can be sent out.
6. 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.
7. Configure a login username.	username name	By default, no login username is configured.
8. Configure a login password.	password password	By default, no login password is configured.
9. Specify a file to be transferred between the FTP server and the FTP client.	filename file-name	By default, no file is specified.
10. Set the data transmission mode for FTP tests.	mode { active \| passive }	Optional. active by default.
11. Configure optional parameters.	See “Configuring optional parameters for an NQA test group”	Optional.

NOTE:

· When you execute the put command, the NQA client creates a file (the name of which is specified in the filename command) with fixed size on the FTP server. The file has no relation to that saved on the NQA client. When you execute the get command, the device does not save the files obtained from the 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 small file. 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

To configure HTTP tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as HTTP and enter test type view.	type http	N/A
4. Configure the IP address of the HTTP server as the destination address of HTTP request packets.	destination ip ip-address	By default, no destination IP address is configured.
5. 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.
6. 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.
7. Configure the website that an HTTP test visits.	url url	N/A
8. Configure the HTTP version used in HTTP tests.	http-version v1.0	Optional. By default, HTTP 1.0 is used.
9. 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

To configure UDP jitter tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as UDP jitter and enter test type view.	type udp-jitter	N/A
4. Configure the destination address of UDP packets.	destination ip ip-address	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.
5. Configure the destination port of UDP packets.	destination port port-number	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.
6. Specify the source port number of UDP packets.	source port port-number	Optional. By default, no source port number is specified.
7. Configure the size of the data field in each UDP packet.	data-size size	Optional. 100 bytes by default.
8. 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.
9. Configure the number of probe packets to be sent during each UDP jitter probe operation.	probe packet-number packet-number	Optional. 10 by default.
10. Configure the interval for sending probe packets during each UDP jitter probe operation.	probe packet-interval packet-interval	Optional. 20 milliseconds by default.
11. 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.
12. 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.
13. 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 about SNMP agent configuration, see the chapter “Configuring SNMP.”

Configuring SNMP tests

To configure SNMP tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as SNMP and enter test type view.	type snmp	N/A
4. Configure the destination address of SNMP packets.	destination ip ip-address	By default, no destination IP address is configured.
5. Specify the source port of SNMP packets.	source port port-number	Optional. By default, no source port number is specified.
6. 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.
7. 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

To configure TCP tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as TCP and enter test type view.	type tcp	N/A
4. Configure the destination address of TCP probe packets.	destination ip ip-address	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.
5. Configure the destination port of TCP probe packets.	destination port port-number	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.
6. 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.
7. 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

To configure UDP echo tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as UDP echo and enter test type view.	type udp-echo	N/A
4. Configure the destination address of UDP packets.	destination ip ip-address	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.
5. Configure the destination port of UDP packets.	destination port port-number	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.
6. Configure the size of the data field in each UDP packet.	data-size size	Optional. 100 bytes by default.
7. 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.
8. Specify the source port of UDP packets.	source port port-number	Optional. By default, no source port number is specified.
9. 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.
10. 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 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

To configure voice tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as voice and enter test type view.	type voice	N/A
4. Configure the destination address of voice probe packets.	destination ip ip-address	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.
5. Configure the destination port of voice probe packets.	destination port port-number	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.
6. Configure the codec type.	codec-type { g711a \| g711u \| g729a }	Optional. By default, the codec type is G.711 A-law.
7. Configure the advantage factor for calculating MOS and ICPIF values.	advantage-factor factor	Optional. By default, the advantage factor is 0.
8. 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.
9. Specify the source port number of probe packets.	source port port-number	Optional. By default, no source port number is specified.
10. 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.
11. 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.
12. Configure the number of probe packets to be sent during each voice probe operation.	probe packet-number packet-number	Optional. 1000 by default.
13. Configure the interval for sending probe packets during each voice probe operation.	probe packet-interval packet-interval	Optional. 20 milliseconds by default.
14. 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.
15. 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. For more information about DLSw configuration, see Layer 2—WAN Configuration Guide.

Configuring a DLSw test

To configure DLSw tests:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Configure the test type as DLSw and enter test type view.	type dlsw	N/A
4. Configure the destination address of probe packets.	destination ip ip-address	By default, no destination IP address is configured.
5. 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.
6. Configure optional parameters.	See “Configuring optional parameters for an NQA test group”	Optional.

Configuring the collaboration function

Collaboration is implemented by establishing reaction entries to monitor the detection results of a test group. If the number of consecutive probe failures reaches the threshold, the configured action is triggered.

To configure the collaboration function:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Enter test type view of the test group.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo }	The collaboration function is not supported in UDP jitter and voice tests.
4. Configure a reaction entry.	reaction item-number checked-element probe-fail threshold-type consecutive consecutive-occurrences action-type trigger-only	Not created by default. You cannot modify the content of an existing reaction entry.
5. Exit to system view.	quit	N/A
6. Configure a track entry and associate it with the reaction entry of the NQA test group.	track entry-number nqa entry admin-name operation-tag reaction item-number	Not created by default.

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 Network Management and Monitoring Command Reference.

· Create an NQA test group and configure related parameters.

Configuring threshold monitoring

To configure threshold monitoring:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Enter test type view of the test group.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	N/A
4. Configure threshold monitoring.	· Enable sending traps to the network management server under specified conditions: reaction trap { probe-failure consecutive-probe-failures \| test-complete \| test-failure cumulate-probe-failures } · 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 } ]	Configure to send traps. By default, no traps are sent 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.

· 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.

To configure the NQA statistics collection function:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Enter test type view of the test group.	type { dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	N/A
4. Configure the interval for collecting the statistics of test results.	statistics interval interval	Optional. 60 minutes by default.
5. 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.
6. 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.

To configure the history records saving function of an NQA test group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Enter NQA test type view.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	N/A
4. Enable the saving of the history records of the NQA test group.	history-record enable	By default, history records of the NQA test group are not saved.
5. 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.
6. 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.

To configure optional parameters for an NQA test group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter NQA test group view.	nqa entry admin-name operation-tag	N/A
3. Enter test type view of a test group.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	N/A
4. Configure the description for a test group.	description text	Optional. By default, no description is available for a test group.
5. 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.
6. 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.
7. Configure the NQA probe timeout time.	probe timeout timeout	Optional. By default, the timeout time is 3000 milliseconds. Not available for UDP jitter tests.
8. Configure the maximum number of hops a probe packet traverses in the network.	ttl value	Optional. 20 by default. Not available for DHCP tests.
9. 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.
10. 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

To configure a schedule for an NQA test group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. 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 }	now specifies the test group starts testing immediately. forever specifies that the tests do not stop unless you use the undo nqa schedule command.
3. Configure the maximum number of tests that the NQA client can simultaneously perform.	nqa agent max-concurrent number	Optional. By default, the device can perform up to 10 tests simultaneously.

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

Task	Command	Remarks
Display history records of NQA test groupsN/A	display nqa history [ admin-name operation-tag ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the current monitoring results of reaction entriesN/A	display nqa reaction counters [ admin-name operation-tag [ item-number ] ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the results of the last NQA testN/A	display nqa result [ admin-name operation-tag ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display statistics of test results for the specified or all test groupsN/A	display nqa statistics [ admin-name operation-tag ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display NQA server status.	display nqa server status [ \| { begin \| exclude \| include } regular-expression ]	Available in any view

NQA configuration examples

NOTE:

By default, Ethernet interface, VLAN interfaces, and aggregation ports are down. To configure these interfaces, first use the undo shutdown command to bring them up.

ICMP echo test configuration example

Network requirements

As shown in Figure 3, 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 3 Network diagram

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 4, configure NQA DHCP tests to test the time required for Switch A to obtain an IP address from the DHCP server (Switch B).

Figure 4 Network diagram

Configuration procedure

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

<SwitchA> system-view

[SwitchA] nqa entry admin test

[SwitchA-nqa-admin-test] type dhcp

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

# Enable the saving of history records.

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

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

# Start DHCP tests.

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

# Stop DHCP tests after a period of time.

[SwitchA] undo nqa schedule admin test

# Display the result of the last DHCP test.

[SwitchA] 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 5, 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 5 Network diagram

Configuration procedure

NOTE:

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

# 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 6, 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 6 Network diagram

Configuration procedure

NOTE:

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

# 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 7, 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 7 Network diagram

Configuration procedure

NOTE:

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

# 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 is optional.)

[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 is optional.)

[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 8, configure NQA UDP jitter tests to test the delay jitter of packet transmission between Device A and Device B.

Figure 8 Network diagram

Configuration procedure

NOTE:

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

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

[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 9, 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 9 Network diagram

Configuration procedure

NOTE:

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

1. Configure the SNMP 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 10, configure NQA TCP tests to test the time for establishing a TCP connection between Device A and Device B.

Figure 10 Network diagram

Configuration procedure

NOTE:

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

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 11, configure NQA UDP echo tests to test the round-trip time between Device A and Device B. The destination port number is 8000.

Figure 11 Network diagram

Configuration procedure

NOTE:

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

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 12, configure NQA voice tests to test the delay jitter of voice packet transmission and voice quality between Device A and Device B.

Figure 12 Network diagram

Configuration procedure

NOTE:

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

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

[DeviceB] nqa server udp-echo 10.2.2.2 9000

2. 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 13, configure NQA DLSw tests to test the response time of the DLSw device.

Figure 13 Network diagram

Configuration procedure

NOTE:

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

# 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

NQA collaboration configuration example

Network requirements

As shown in Figure 14, on Switch A configure a static route to Switch C, with Switch B as the next hop. Associate the static route, track entry, and NQA test group to verify whether static route is active in real time.

Figure 14 Network diagram

Configuration procedure

1. Assign each interface an IP address. (Details not shown)

2. On Switch A, configure a unicast static route and associate the static route with a track entry.

# Configure a static route, whose destination address is 10.2.1.1, and associate the static route with track entry 1.

<SwitchA> system-view

[SwitchA] ip route-static 10.1.1.2 24 10.2.1.1 track 1

3. On Switch A, create an NQA test group.

# Create an NQA test group with the administrator name being admin and operation tag being test.

[SwitchA] nqa entry admin test

# Configure the test type of the NQA test group as ICMP echo.

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

# Configure ICMP echo requests to use 10.2.1.1 as their destination IP address.

[SwitchA-nqa-admin-test-icmp-echo] destination ip 10.2.1.1

# Configure the device to perform tests at an interval of 100 milliseconds.

[SwitchA-nqa-admin-test-icmp-echo] frequency 100

# Create reaction entry 1. If the number of consecutive probe failures reaches 5, collaboration with other modules is triggered.

[SwitchA-nqa-admin-test-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only

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

# Configure the test start time and test duration for the test group.

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

4. On Switch A, create the track entry.

# Create track entry 1 to associate it with Reaction entry 1 of the NQA test group (admin-test).

[SwitchA] track 1 nqa entry admin test reaction 1

5. Verify the configuration.

# On Switch A, display information about all the track entries.

[SwitchA] display track all

Track ID: 1

Status: Positive

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

NQA entry: admin test

Reaction: 1

# Display brief information about active routes in the routing table on Switch A.

[SwitchA] display ip routing-table

Routing Tables: Public

Destinations : 5 Routes : 5

Destination/Mask Proto Pre Cost NextHop Interface

10.1.1.0/24 Static 60 0 10.2.1.1 Vlan3

10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan3

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

The output shows that the static route with the next hop 10.2.1.1 is active, and the status of the track entry is positive. The static route configuration works.

# Remove the IP address of VLAN-interface 3 on Switch B.

<SwitchB> system-view

[SwitchB] interface vlan-interface 3

[SwitchB-Vlan-interface3] undo ip address

# On Switch A, display information about all the track entries.

[SwitchA] display track all

Track ID: 1

Status: Negative

Notification delay: Positive 0, Negative 0 (in seconds)

Reference object:

NQA entry: admin test

Reaction: 1

# Display brief information about active routes in the routing table on Switch A.

[SwitchA] display ip routing-table

Routing Tables: Public

Destinations : 4 Routes : 4

Destination/Mask Proto Pre Cost NextHop Interface

10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan3

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

The output shows that the next hop 10.2.1.1 of the static route is not reachable, and the status of the track entry is negative. The static route does not work.

13-Network Management and Monitoring Configuration Guide

Configuring NQA

Supporting multiple test types

Supporting the collaboration function

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

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