Network quality analyzer (NQA) allows you to measure network performance, verify the service levels for IP services and applications, and troubleshoot network problems. It provides the following types of operations:

· ICMP echo.

· DHCP.

· DNS.

· FTP.

· HTTP.

· UDP jitter.

· SNMP.

· TCP.

· UDP echo.

· UDP tracert.

· Voice.

· Path jitter.

· DLSw.

As shown in Figure 1, the NQA source device (NQA client) sends data to the NQA destination device by simulating IP services and applications to measure network performance. The obtained performance metrics include the one-way latency, jitter, packet loss, voice quality, application performance, and server response time.

All types of NQA operations require the NQA client, but only the TCP, UDP echo, UDP jitter, and voice operations require the NQA server. The NQA operations for services that are already provided by the destination device such as FTP do not need the NQA server.

You can configure the NQA server to listen and respond to specific IP addresses and ports to meet various test needs.

Figure 1 Network diagram

NQA operation

The following describes how NQA performs different types of operations:

· A TCP or DLSw operation sets up a connection.

· A UDP jitter or a voice operation sends a number of probe packets. The number of probe packets is set by using the probe packet-number command.

· An FTP operation uploads or downloads a file.

· An HTTP operation gets a Web page.

· A DHCP operation gets an IP address through DHCP.

· A DNS operation translates a domain name to an IP address.

· An ICMP echo operation sends an ICMP echo request.

· A UDP echo operation sends a UDP packet.

· An SNMP operation sends one SNMPv1 packet, one SNMPv2c packet, and one SNMPv3 packet.

· A path jitter operation is accomplished in the following steps:

a. The operation uses tracert to obtain the path from the NQA client to the destination. A maximum of 64 hops can be detected.

b. The NQA client sends ICMP echo requests to each hop along the path. The number of ICMP echo requests is set by using the probe packet-number command.

· A UDP tracert operation determines the routing path from the source to the destination. The number of the probes to each hop is set by using the probe count command.

Collaboration

NQA can collaborate with the Track module to notify application modules of state or performance changes so that the application modules can take predefined actions.

Figure 2 Collaboration

The following describes how a static route destined for 192.168.0.88 is monitored through collaboration:

1. NQA monitors the reachability to 192.168.0.88.

2. When 192.168.0.88 becomes unreachable, NQA notifies the Track module of the change.

3. The Track module notifies the static routing module of the state change.

4. The static routing module sets the static route as invalid according to a predefined action.

For more information about collaboration, see High Availability Configuration Guide.

Threshold monitoring

Threshold monitoring enables the NQA client to take a predefined action when the NQA operation performance metrics violate the specified thresholds.

Table 1 describes the relationships between performance metrics and NQA operation types.

Table 1 Performance metrics and NQA operation types

Performance metric	NQA operation types that can gather the metric
Probe duration	All NQA operation types except UDP jitter, UDP tracert, path jitter, and voice
Number of probe failures	All NQA operation types except UDP jitter, UDP tracert, path jitter, and voice
Round-trip time	UDP jitter and voice
Number of discarded packets	UDP jitter and voice
One-way jitter (source-to-destination or destination-to-source)	UDP jitter and voice
One-way delay (source-to-destination or destination-to-source)	UDP jitter and voice
Calculated Planning Impairment Factor (ICPIF) (see "Configuring the voice operation")	Voice
Mean Opinion Scores (MOS) (see "Configuring the voice operation")	Voice

NQA configuration task list

Tasks at a glance	Remarks
Configuring the NQA server	Required for TCP, UDP echo, UDP jitter, and voice operations.
(Required.) Enabling the NQA client	N/A
(Required.) Perform at least one of the following tasks: · Configuring NQA operations on the NQA client · Configuring NQA templates on the NQA client	When you configure an NQA template to analyze network performance, the feature that uses the template performs the NQA operation.

Configuring the NQA server

To perform TCP, UDP echo, UDP jitter, and voice operations, you must enable the NQA server on the destination device. The NQA server listens and responds to requests on the specified IP addresses and ports.

You can configure multiple TCP or UDP listening services on an NQA server, where each corresponds to a specific IP address and port number. The IP address and port number for a listening service must be unique on the NQA server and match the configuration on the NQA client.

To configure the NQA server:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
1. Enable the NQA server.	nqa server enable	By default, the NQA server is disabled.
2. Configure a TCP or UDP listening service.	· TCP listening service: nqa server tcp-connect ip-address port-number [ vpn-instance vpn-instance-name ] [ tos tos ] · UDP listening service: nqa server udp-echo ip-address port-number [ vpn-instance vpn-instance-name ] [ tos tos ]	You can set the ToS value in the IP header of reply packets sent by the NQA server. The default ToS value is 0.

Enabling the NQA client

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable the NQA client.	nqa agent enable	By default, the NQA client is enabled.

Configuring NQA operations on the NQA client

NQA operation configuration task list

Tasks at a glance
(Required.) Perform at least one of the following tasks: · Configuring the ICMP echo operation · Configuring the DHCP operation · Configuring the DNS operation · Configuring the FTP operation · Configuring the HTTP operation · Configuring the UDP jitter operation · Configuring the SNMP operation · Configuring the TCP operation · Configuring the UDP echo operation · Configuring the UDP tracert operation · Configuring the voice operation · Configuring the DLSw operation · Configuring the path jitter operation
(Optional.) Configuring optional parameters for the NQA operation
(Optional.) Configuring the collaboration function
(Optional.) Configuring threshold monitoring
(Optional.) Configuring the NQA statistics collection function
(Optional.) Configuring the saving of NQA history records
(Required.) Scheduling the NQA operation on the NQA client

Configuring the ICMP echo operation

The ICMP echo operation measures the reachability of a destination device. It has the same function as the ping command, but provides more output information. In addition, if multiple paths exist between the source and destination devices, you can specify the next hop for the ICMP echo operation.

The ICMP echo operation is not supported in IPv6 networks. To test the reachability of an IPv6 address, use the ping ipv6 command. For more information about the command, see Network Management and Monitoring Command Reference.

To configure the ICMP echo operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the ICMP echo type and enter its view.	type icmp-echo	N/A
4. Specify the destination IP address of ICMP echo requests.	destination ip ip-address	By default, no destination IP address is specified.
5. (Optional.) Specify the payload size in each ICMP echo request.	data-size size	The default setting is 100 bytes.
6. (Optional.) Specify the payload fill string for ICMP echo requests.	data-fill string	The default string is the hexadecimal number 00010203040506070809.
7. (Optional.) Specify the output interface for ICMP echo requests.	out interface interface-type interface-number	By default, the output interface for ICMP echo requests is not specified. The NQA client determines the output interface based on the routing table lookup.
8. (Optional.) Specify the source IP address of ICMP echo requests.	· Specify the IP address of the specified interface as the source IP address: source interface interface-type interface-number · Specify the source IP address: source ip ip-address	By default, no source IP address is specified. The requests take the primary IP address of the output interface as their source IP address. If you configure both the source ip and source interface commands, the most recent configuration takes effect. The specified source interface must be up. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.
9. (Optional.) Specify the next hop for ICMP echo requests.	next-hop ip-address	By default, no next hop is configured.

Configuring the DHCP operation

The DHCP operation measures whether or not the DHCP server can respond to client requests. DHCP also measures the amount of time it takes the NQA client to obtain an IP address from a DHCP server.

The NQA client simulates the DHCP relay agent to forward DHCP requests for IP address acquisition from the DHCP server. The interface that performs the DHCP operation does not change its IP address. When the DHCP operation completes, the NQA client sends a packet to release the obtained IP address.

To configure the DHCP operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the DHCP type and enter its view.	type dhcp	N/A
4. Specify the IP address of the DHCP server as the destination IP address of DHCP packets.	destination ip ip-address	By default, no destination IP address is specified.
5. (Optional.) Specify the output interface for DHCP request packets.	out interface interface-type interface-number	By default, the output interface for DHCP requests is not specified. The NQA client determines the output interface based on the routing table lookup.
6. (Optional.) Specify the source IP address of DHCP request packets.	source ip ip-address	By default, no source IP address is specified for the request packets. The requests take the IP address of the output interface as their source IP address. The specified source IP address must be the IP address of a local interface, and the local interface must be up. Otherwise, no probe packets can be sent out. The NQA client adds the source IP address to the giaddr field in DHCP requests to be sent to the DHCP server. For more information about the giaddr field, see Layer 3—IP Services Configuration Guide.

Configuring the DNS operation

The DNS operation measures the time for the NQA client to translate a domain name into an IP address through a DNS server.

A DNS operation simulates domain name resolution and does not save the obtained DNS entry.

To configure the DNS operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the DNS type and enter its view.	type dns	N/A
4. Specify the IP address of the DNS server as the destination IP address of DNS packets.	destination ip ip-address	By default, no destination IP address is specified.
5. Specify the domain name to be translated.	resolve-target domain-name	By default, no domain name is specified.

Configuring the FTP operation

The FTP operation measures the time for the NQA client to transfer a file to or download a file from an FTP server.

When you configure the FTP operation, follow these restrictions and guidelines:

· When you perform the put operation with the filename command configured, make sure the file exists on the NQA client.

· If you get a file from the FTP server, make sure the file specified in the URL exists on the FTP server.

· The NQA client does not save the file obtained from the FTP server.

· Use a small file for the FTP operation. A big file might result in transfer failure because of timeout, or might affect other services for occupying much network bandwidth.

To configure the FTP operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the FTP type and enter its view.	type ftp	N/A
4. Specify the URL of the destination FTP server.	url url	By default, no URL is specified for the destination FTP server. Enter the URL in one of the following formats: · ftp://host/filename. · ftp://host:port/filename. When you perform the get operation, the file name is required.
5. (Optional.) Specify 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, and the interface must be up. Otherwise, no FTP requests can be sent out.
6. Specify the FTP operation type.	operation { get \| put }	By default, the FTP operation type is get, which means obtaining files from the FTP server.
7. Specify an FTP login username.	username username	By default, no FTP login username is configured.
8. Specify an FTP login password.	password { cipher \| simple } password	By default, no FTP login password is configured.
9. (Optional.) Specify the name of a file to be transferred.	filename file-name	By default, no file is specified. This step is required if you perform the put operation.
10. Set the data transmission mode.	mode { active \| passive }	The default mode is active.

Configuring the HTTP operation

An HTTP operation measures the time for the NQA client to obtain data from an HTTP server.

To configure an HTTP operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the HTTP type and enter its view.	type http	N/A
4. Specify the URL of the destination HTTP server.	url url	By default, no URL is specified for the destination HTTP server. Enter the URL in one of the following formats: · http://host/resource. · http://host:port/resource.
5. Specify an HTTP login username.	username username	By default, no HTTP login username is specified.
6. Specify an HTTP login password.	password { cipher \| simple } password	By default, no HTTP login password is specified.
7. (Optional.) Specify the source IP address of 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, and the interface must be up. Otherwise, no request packets can be sent out.
8. Specify the HTTP operation type.	operation { get \| post \| raw }	By default, the HTTP operation type is get, which means obtaining data from the HTTP server.
9. Specify the HTTP version.	version { v1.0 \| v1.1 }	By default, HTTP 1.0 is used.
10. (Optional.) Enter raw request view.	raw-request	Every time you enter raw request view, the previously configured content of the HTTP request is removed.
11. (Optional.) Specify the content of a GET request for the HTTP operation.	Enter or paste the content.	By default, no contents are specified. This step is required for the raw operation.
12. Save the input and exit to HTTP operation view.	quit	N/A

Configuring the UDP jitter operation

CAUTION:

To ensure successful UDP jitter operations and avoid affecting existing services, do not perform the operations on well-known ports from 1 to 1023.

Jitter means inter-packet delay variance. A UDP jitter operation measures unidirectional and bidirectional jitters. You can verify whether the network can carry jitter-sensitive services such as real-time voice and video services through the UDP jitter operation.

The UDP jitter operation works as follows:

1. The NQA client sends UDP packets to the destination port regularly.

2. The destination device takes a time stamp to each packet that it receives, and then sends the packet back to the NQA client.

3. Upon receiving the responses, the NQA client calculates the jitter according to the time stamps.

The UDP jitter operation requires both the NQA server and the NQA client. Before you perform the UDP jitter operation, configure the UDP listening service on the NQA server. For more information about UDP listening service configuration, see "Configuring the NQA server."

To configure a UDP jitter operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the UDP jitter type and enter its view.	type udp-jitter	N/A
4. Specify the destination IP address of UDP packets.	destination ip ip-address	By default, no destination IP address is specified. The destination IP address must be the same as the IP address of the listening service on the NQA server.
5. Specify the destination port of UDP packets.	destination port port-number	By default, no destination port number is specified. The destination port number must be the same as the port number of the listening service on the NQA server.
6. (Optional.) Specify the source port number of UDP packets.	source port port-number	By default, no source port number is specified.
7. (Optional.) Specify the payload size in each UDP packet.	data-size size	The default setting is 100 bytes.
8. (Optional.) Specify the payload fill string for UDP packets.	data-fill string	The default string is the hexadecimal number 00010203040506070809.
9. (Optional.) Specify the number of UDP packets sent in one UDP jitter operation.	probe packet-number packet-number	The default setting is 10.
10. (Optional.) Configure the interval for sending UDP packets.	probe packet-interval packet-interval	The default setting is 20 milliseconds.
11. (Optional.) Specify how long the NQA client waits for a response from the server before it regards the response times out.	probe packet-timeout packet-timeout	The default setting is 3000 milliseconds.
12. (Optional.) Specify the source IP address for UDP packets.	source ip ip-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no UDP packets can be sent out.

NOTE:

Use the display nqa result or display nqa statistics command to verify the UDP jitter operation. The display nqa history command does not display the UDP jitter operation results or statistics.

Configuring the SNMP operation

The SNMP operation measures the time for the NQA client to get a response packet from an SNMP agent.

To configure the SNMP operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the SNMP type and enter its view.	type snmp	N/A
4. Specify the destination IP address of SNMP packets.	destination ip ip-address	By default, no destination IP address is specified.
5. (Optional.) Specify the source port of SNMP packets.	source port port-number	By default, no source port number is specified.
6. (Optional.) Specify the source IP address of SNMP packets.	source ip ip-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no SNMP packets can be sent out.

Configuring the TCP operation

The TCP operation measures the time for the NQA client to establish a TCP connection to a port on the NQA server.

The TCP operation requires both the NQA server and the NQA client. Before you perform a TCP operation, configure a TCP listening service on the NQA server. For more information about the TCP listening service configuration, see "Configuring the NQA server."

To configure the TCP operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the TCP type and enter its view.	type tcp	N/A
4. Specify the destination IP address of TCP packets.	destination ip ip-address	By default, no destination IP address is specified. The destination IP address must be the same as the IP address of the listening service configured on the NQA server.
5. Specify the destination port of TCP packets.	destination port port-number	By default, no destination port number is configured. The destination port number must be the same as the port number of the listening service on the NQA server.
6. (Optional.) Specify the source IP address of TCP packets.	source ip ip-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no TCP packets can be sent out.

Configuring the UDP echo operation

The UDP echo operation measures the round-trip time between the client and a UDP port on the NQA server.

The UDP echo operation requires both the NQA server and the NQA client. Before you perform a UDP echo operation, configure a UDP listening service on the NQA server. For more information about the UDP listening service configuration, see "Configuring the NQA server."

To configure the UDP echo operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the UDP echo type and enter its view.	type udp-echo	N/A
4. Specify the destination IP address of UDP packets.	destination ip ip-address	By default, no destination IP address is specified. The destination IP address must be the same as the IP address of the listening service configured on the NQA server.
5. Specify the destination port of UDP packets.	destination port port-number	By default, no destination port number is specified. The destination port number must be the same as the port number of the listening service on the NQA server.
6. (Optional.) Specify the payload size in each UDP packet.	data-size size	The default setting is 100 bytes.
7. (Optional.) Specify the payload fill string for UDP packets.	data-fill string	The default string is the hexadecimal number 00010203040506070809.
8. (Optional.) Specify the source port of UDP packets.	source port port-number	By default, no source port number is specified.
9. (Optional.) Specify the source IP address of UDP packets.	source ip ip-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no UDP packets can be sent out.

Configuring the UDP tracert operation

The UDP tracert operation determines the routing path from the source device to the destination device.

Before you configure the UDP tracert operation, perform the following tasks:

· Enable sending ICMP time exceeded messages on the intermediate devices between the source and destination devices. If the intermediate devices are H3C devices, use the ip ttl-expires enable command.

· Enable sending ICMP destination unreachable messages on the destination device. If the destination device is an H3C device, use the ip unreachables enable command.

For more information about the ip ttl-expires enable and ip unreachables enable commands, see Layer 3—IP Services Command Reference.

The UDP tracert operation is not supported in IPv6 networks. To determine the routing path that the IPv6 packets traverse from the source to the destination, use the tracert ipv6 command. For more information about the command, see Network Management and Monitoring Command Reference.

To configure the UDP tracert operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the UDP tracert operation type and enter its view.	type udp-tracert	N/A
4. Specify the destination IP address of UDP packets.	destination ip ip-address	By default, no destination IP address is configured.
5. (Optional.) Specify the destination port of UDP packets.	destination port port-number	By default, the destination port number is 33434. This port number must be an unused number on the destination device, so that the destination device can reply with ICMP port unreachable messages.
6. (Optional.) Set the payload size for each UDP packet.	data-size size	The default setting is 100 bytes.
7. (Optional.) Enable the no-fragmentation feature.	no-fragment enable	By default, the no-fragmentation feature is disabled.
8. (Optional.) Set the maximum number of consecutive probe failures.	max-failure value	The default setting is 5.
9. (Optional.) Set the TTL value for UDP packets in the start round of the UDP tracert operation.	init-ttl value	The default setting is 1.
10. (Optional.) Specify an output interface for UDP packets.	out interface interface-type interface-number	By default, the output interface for UDP packets is not specified. The NQA client determines the output interface based on the routing table lookup.
11. (Optional.) Specify the source port of UDP packets.	source port port-number	By default, no source port number is specified.
12. (Optional.) Specify the source IP address of UDP packets.	· Specify the IP address of the specified interface as the source IP address: source interface interface-type interface-number · Specify the source IP address: source ip ip-address	By default, no source IP address is specified. The packets take the primary IP address of the output interface as their source IP address. If you configure both the source ip and source interface commands, the most recent configuration takes effect. The specified source interface must be up. The source IP address must be the IP address of a local interface, and the local interface must be up. Otherwise, no probe packets can be sent out.

Configuring the voice operation

CAUTION:

To ensure successful voice operations and avoid affecting existing services, do not perform the operations on well-known ports from 1 to 1023.

The voice operation measures VoIP network performance.

The voice operation works as follows:

1. The NQA client sends voice packets at sending intervals to the destination device (NQA server).

The voice packets are of one of the following codec types:

¡ G.711 A-law.

¡ G.711 µ-law.

¡ G.729 A-law.

2. The destination device takes a time stamp to each voice packet it receives and sends it back to the source.

3. Upon receiving the packet, the source device calculates the jitter and one-way delay based on the time stamp.

The following parameters that reflect VoIP network performance can be calculated by using the metrics gathered by the voice operation:

· 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 of 1 to 5. A higher value represents a higher service quality.

The evaluation of voice quality depends on users' tolerance for voice quality. For users with higher tolerance for voice quality, use the advantage-factor command to configure the advantage factor. When the system calculates the ICPIF value, it subtracts the advantage factor to modify ICPIF and MOS values for voice quality evaluation.

The voice operation requires both the NQA server and the NQA client. Before you perform a voice operation, configure a UDP listening service on the NQA server. For more information about UDP listening service configuration, see "Configuring the NQA server."

The voice operation cannot repeat.

To configure the voice operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the voice type and enter its view.	type voice	N/A
4. Specify the destination IP address of voice packets.	destination ip ip-address	By default, no destination IP address is configured. The destination IP address must be the same as the IP address of the listening service on the NQA server.
5. Specify the destination port of voice packets.	destination port port-number	By default, no destination port number is configured. The destination port number must be the same as the port number of the listening service on the NQA server.
6. (Optional.) Specify the codec type.	codec-type { g711a \| g711u \| g729a }	By default, the codec type is G.711 A-law.
7. (Optional.) Specify the advantage factor for calculating MOS and ICPIF values.	advantage-factor factor	By default, the advantage factor is 0.
8. (Optional.) Specify the source IP address of voice packets.	source ip ip-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no voice packets can be sent out.
9. (Optional.) Specify the source port number of voice packets.	source port port-number	By default, no source port number is specified.
10. (Optional.) Specify the payload size in each voice packet.	data-size size	By default, the voice packet size varies by codec type. The default packet size is 172 bytes for G.711A-law and G.711 µ-law codec type, and 32 bytes for G.729 A-law codec type.
11. (Optional.) Specify the payload fill string for voice packets.	data-fill string	The default string is the hexadecimal number 00010203040506070809.
12. (Optional.) Specify the number of voice packets to be sent in a voice probe.	probe packet-number packet-number	The default setting is 1000.
13. (Optional.) Specify the interval for sending voice packets.	probe packet-interval packet-interval	The default setting is 20 milliseconds.
14. (Optional.) Specify how long the NQA client waits for a response from the server before it regards the response times out.	probe packet-timeout packet-timeout	The default setting is 5000 milliseconds.

NOTE:

Use the display nqa result or display nqa statistics command to verify the voice operation. The display nqa history command does not display the voice operation results or statistics.

Configuring the DLSw operation

The DLSw operation measures the response time of a DLSw device.

To configure the DLSw operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the DLSw type and enter its view.	type dlsw	N/A
4. Specify the destination IP address of probe packets.	destination ip ip-address	By default, no destination IP address is specified.
5. (Optional.) Specify the source IP address of probe packets.	source ip ip-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

Configuring the path jitter operation

The path jitter operation measures the jitter, negative jitters, and positive jitters from the NQA client to each hop on the path to the destination.

Before you configure the path jitter operation, perform the following tasks:

· Enable sending ICMP destination unreachable messages on the destination device. If the destination device is an H3C device, use the ip unreachables enable command.

For more information about the ip ttl-expires enable and ip unreachables enable commands, see Layer 3—IP Services Command Reference.

To configure the path jitter operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify the path jitter type and enter its view.	type path-jitter	N/A
4. Specify the destination IP address of ICMP echo requests.	destination ip ip-address	By default, no destination IP address is specified.
5. (Optional.) Specify the payload size in each ICMP echo request.	data-size size	The default setting is 100 bytes.
6. (Optional.) Specify the payload fill string for ICMP echo requests.	data-fill string	The default string is the hexadecimal number 00010203040506070809.
7. Specify the source IP address of ICMP echo requests.	source ip ip-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no ICMP echo requests can be sent out.
8. (Optional.) Specify the number of ICMP echo requests to be sent in a path jitter operation.	probe packet-number packet-number	The default setting is 10.
9. (Optional.) Specify the interval for sending ICMP echo requests.	probe packet-interval packet-interval	The default setting is 20 milliseconds.
10. (Optional.) Specify how long the NQA client waits for a response from the server before it regards the response times out.	probe packet-timeout packet-timeout	The default setting is 3000 milliseconds.
11. (Optional.) Specify an LSR path.	lsr-path ip-address&<1-8>	By default, no LSR path is specified. The path jitter operation uses the tracert to detect the LSR path to the destination, and sends ICMP echo requests to each hop on the LSR.
12. (Optional.) Perform the path jitter operation only on the destination address.	target-only	By default, the path jitter operation is performed on each hop on the path to the destination.

Configuring optional parameters for the NQA operation

Unless otherwise specified, the following optional parameters apply to all types of NQA operations.

To configure optional parameters for an NQA operation:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify an NQA operation type and enter its view.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| path-jitter \| snmp \| tcp \| udp-echo \| udp-jitter \| udp-tracert \| voice }	N/A
4. Configure a description.	description text	By default, no description is configured.
5. Specify the interval at which the NQA operation repeats.	frequency interval	For a voice or path jitter operation, the default setting is 60000 milliseconds. For other operations, the default setting is 0 milliseconds. Only one operation is performed. If the operation is not completed when the interval expires, the next operation does not start.
6. Specify the probe times.	probe count times	By default: · In an UDP tracert operation, the NQA client performs three probes to each hop to the destination. · In other types of operations, the NQA client performs one probe to the destination per operation. This command is not available for the path jitter and voice operations. Each of these operations performs only one probe.
7. Specify the probe timeout time.	probe timeout timeout	The default setting is 3000 milliseconds. This command is not available for the path jitter, UDP jitter, and voice operations.
8. Specify the maximum number of hops that the probe packets can traverse.	ttl value	The default setting is 30 for probe packets of the UDP tracert operation, and is 20 for probe packets of other types of operations. This command is not available for the DHCP and path jitter operations.
9. Specify the ToS value in the IP header of probe packets.	tos value	The default setting is 0.
10. Enable the routing table bypass function.	route-option bypass-route	By default, the routing table bypass function is disabled. This command is not available for the DHCP and path jitter operations.
11. Specify the VPN where the operation is performed.	vpn-instance vpn-instance-name	By default, the operation is performed on the public network.

Configuring the collaboration function

Collaboration is implemented by associating a reaction entry of an NQA operation with a track entry. The reaction entry monitors the NQA operation. If the number of operation failures reaches the specified threshold, the configured action is triggered.

To configure the collaboration function:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify an NQA operation type and enter its view.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo }	The collaboration function is not available for the path jitter, UDP jitter, UDP tracert, and voice operations.
4. Configure a reaction entry.	reaction item-number checked-element probe-fail threshold-type consecutive consecutive-occurrences action-type trigger-only	By default, no reaction entry is configured. You cannot modify the content of an existing reaction entry.
5. Exit to system view.	quit	N/A
6. Associate Track with NQA.	See High Availability Configuration Guide.	N/A
7. Associate Track with an application module.	See High Availability Configuration Guide.	N/A

Configuring threshold monitoring

This function allows you to monitor the NQA operation running status.

Threshold types

An NQA operation supports the following threshold types:

· average—If the average value for the monitored performance metric either exceeds the upper threshold or goes below the lower threshold, a threshold violation occurs.

· accumulate—If the total number of times that the monitored performance metric is out of the specified value range reaches or exceeds the specified threshold, a threshold violation occurs.

· consecutive—If the number of consecutive times that the monitored performance metric is out of the specified value range reaches or exceeds the specified threshold, a threshold violation occurs.

Threshold violations for the average or accumulate threshold type are determined on a per NQA operation basis. The threshold violations for the consecutive type are determined from the time the NQA operation starts.

Triggered actions

The following actions might be triggered:

· none—NQA displays results only on the terminal screen. It does not send traps to the NMS.

· trap-only—NQA displays results on the terminal screen, and meanwhile it sends traps to the NMS.

· trigger-only—NQA displays results on the terminal screen, and meanwhile triggers other modules for collaboration.

The DNS operation does not support the action of sending trap messages.

Reaction entry

In a reaction entry, configure a monitored element, a threshold type, and an action to be triggered to implement threshold monitoring.

The state of a reaction entry can be invalid, over-threshold, or below-threshold.

· Before an NQA operation starts, the reaction entry is in invalid state.

· If the threshold is violated, the state of the entry is set to over-threshold. Otherwise, the state of the entry is set to below-threshold.

If the action is configured as trap-only for a reaction entry, a trap message is sent to the NMS when the state of the entry changes.

Configuration procedure

Before you configure threshold monitoring, configure the destination address of the trap messages by using the snmp-agent target-host command. For more information about the command, see Network Management and Monitoring Command Reference.

To configure threshold monitoring:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Enter NQA operation view.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-jitter \|udp-tracert \| voice }	Path jitter does not support threshold monitoring.
4. Enable sending traps to the NMS when specific conditions are met.	reaction trap { path-change \| probe-failure consecutive-probe-failures \| test-complete \| test-failure [ cumulate-probe-failures ] }	By default, no traps are sent to the NMS. The UDP jitter and voice operations support only the test-complete keyword. The UDP tracert operation supports the path-change, test-complete, and test-failure keywords.
5. Configure threshold monitoring.	· Monitor the operation duration (not supported in the UDP jitter and voice operations): 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 } ] · Monitor failure times (not supported in the UDP jitter and voice operations): reaction item-number checked-element probe-fail threshold-type { accumulate accumulate-occurrences \| consecutive consecutive-occurrences } [ action-type { none \| trap-only } ] · Monitor the round-trip time (only for the in UDP jitter and voice operations): reaction item-number checked-element rtt threshold-type { accumulate accumulate-occurrences \| average } threshold-value upper-threshold lower-threshold [ action-type { none \| trap-only } ] · Monitor packet loss (only for the UDP jitter and voice operations): reaction item-number checked-element packet-loss threshold-type accumulate accumulate-occurrences [ action-type { none \| trap-only } ] · Monitor the one-way jitter (only for the UDP jitter and voice operations): 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 } ] · Monitor the one-way delay (only for the UDP jitter and voice operations): reaction item-number checked-element { owd-ds \| owd-sd } threshold-value upper-threshold lower-threshold · Monitor the ICPIF value (only for the voice operation): reaction item-number checked-element icpif threshold-value upper-threshold lower-threshold [ action-type { none \| trap-only } ] · Monitor the MOS value (only for the voice operation): reaction item-number checked-element mos threshold-value upper-threshold lower-threshold [ action-type { none \| trap-only } ]	N/A

Configuring the NQA statistics collection function

NQA forms statistics within the same collection interval as a statistics group. To display information about the statistics groups, use the display nqa statistics command.

NQA does not generate any statistics group for the operation that runs once. To set the NQA operation to run only once, use the frequency command to set the interval to 0 milliseconds.

To configure the NQA statistics collection function:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Specify an NQA operation type and enter its view.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| path-jitter \| snmp \| tcp \| udp-echo \| udp-jitter \| voice }	The UDP tracert operation does not support the NQA statistics collection function.
4. (Optional.) Specify the interval for collecting the statistics.	statistics interval interval	The default setting is 60 minutes.
5. (Optional.) Specify the maximum number of statistics groups that can be saved.	statistics max-group number	The default setting is two groups. To disable collecting NQA statistics, set the maximum number to 0. When the maximum number of statistics groups is reached, to save a new statistics group, the oldest statistics group is deleted.
6. (Optional.) Specify the hold time of statistics groups.	statistics hold-time hold-time	The default setting is 120 minutes. A statistics group is deleted when its hold time expires.

Configuring the saving of NQA history records

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA operation and enter NQA operation view.	nqa entry admin-name operation-tag	By default, no NQA operation is created.
3. Enter NQA operation type view.	type { dhcp \| dlsw \| dns \| ftp \| http \| icmp-echo \| snmp \| tcp \| udp-echo \| udp-tracert }	The UDP jitter, path jitter, and voice operations do not support saving history records.
4. Enable the saving of history records for the NQA operation.	history-record enable	By default, this function is enabled only for the UDP tracert operation.
5. (Optional.) Set the lifetime of history records.	history-record keep-time keep-time	The default setting is 120 minutes. A record is deleted when its lifetime is reached.
6. (Optional.) Specify the maximum number of history records that can be saved.	history-record number number	The default setting is 50. If the maximum number of history records for an NQA operation is reached, the earliest history records are deleted.
7. (Optional.) Display NQA history records.	display nqa history	N/A

Scheduling the NQA operation on the NQA client

The NQA operation works between the specified start time and the end time (the start time plus operation duration). If the specified start time is ahead of the system time, the operation starts immediately. If both the specified start and end time are ahead of the system time, the operation does not start. To display the current system time, use the display clock command.

When you schedule an NQA operation, follow these restrictions and guidelines:

· You cannot enter the operation type view or the operation view of a scheduled NQA operation.

· A system time adjustment does not affect started or completed NQA operations. It affects only the NQA operations that have not started.

To schedule the NQA operation on the NQA client:

Step	Command
1. Enter system view.	system-view
2. Specify the scheduling parameters for an NQA operation.	nqa schedule admin-name operation-tag start-time { hh:mm:ss [ yyyy/mm/dd \| mm/dd/yyyy ] \| now } lifetime { lifetime \| forever } [ recurring ]

Configuring NQA templates on the NQA client

An NQA template is a set of operation parameters, such as the destination address, the destination port number, and the destination server URL. You can use an NQA template in load balancing, health monitoring, and other feature modules to provide test statistics. You can create multiple templates on a device, and each template must be uniquely named.

NQA template supports the ICMP, DNS, HTTP, TCP, UDP, and FTP operation types.

Some operation parameters for an NQA template can be specified by the template configuration or the feature that uses the template. When both are specified, the parameters in the template configuration take effect. For example, the server load balancing uses the NQA ICMP template for health monitoring. If the destination IP address in the template is different from the real server address, the destination IP address in the template takes effect.

NQA template configuration task list

Tasks at a glance
(Required.) Perform at least one of the following tasks: · Configuring the ICMP template · Configuring the DNS template · Configuring the TCP template · Configuring the UDP template · Configuring the HTTP template · Configuring the FTP template
(Optional.) Configuring optional parameters for the NQA template

Tasks at a glance

(Required.) Perform at least one of the following tasks:

· Configuring the ICMP template

· Configuring the DNS template

· Configuring the TCP template

· Configuring the UDP template

· Configuring the HTTP template

· Configuring the FTP template

(Optional.) Configuring optional parameters for the NQA template

Configuring the ICMP template

A feature that uses the ICMP template performs the ICMP operation to measure the reachability of a destination device. The ICMP template is supported in both IPv4 and IPv6 networks.

To configure the ICMP template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an ICMP template and enter its view.	nqa template icmp name	N/A
3. (Optional.) Specify the destination IP address of the operation.	· IPv4 address: destination ip ip-address · IPv6 address: destination ipv6 ipv6-address	By default, no destination IP address is configured.
4. (Optional.) Specify the payload size in each ICMP request.	data-size size	The default setting is 100 bytes.
5. (Optional.) Specify the payload fill string for requests.	data-fill string	The default string is the hexadecimal number 00010203040506070809.
6. (Optional.) Specify the IP address of the specified interface as the source IP address of ICMP echo requests.	source interface interface-type interface-number	By default, no source IP address is specified. The requests use the primary IP address of the output interface as their source IP address. If you configure the source interface command with the source ip or source ipv6 command, the most recent configuration takes effect. The specified source interface must be up.
7. (Optional.) Specify the source IP address for the probe packets.	· IPv4 address: source ip ip-address · IPv6 address: source ipv6 ipv6-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

Configuring the DNS template

A feature that uses the DNS template performs the DNS operation to determine the status of the server. It is supported in both IPv4 and IPv6 networks.

In DNS template view, you can specify the address expected to be returned. If the returned IP addresses include the expected address, the DNS server is valid and the operation succeeds. Otherwise, the operation fails.

Create a mapping between the domain name and an address before you perform the DNS operation. For information about configuring the DNS server, see Layer 3—IP Services Configuration Guide.

To configure the DNS template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a DNS template and enter DNS template view.	nqa template dns name	N/A
3. (Optional.) Specify the destination IP address of DNS packets.	· IPv4 address: destination ip ip-address · IPv6 address: destination ipv6 ipv6-address	By default, no destination IP address is specified.
4. (Optional.) Configure the destination port number for the operation.	destination port port-number	By default, the destination port number is 53.
5. Specify the domain name that needs to be translated.	resolve-target domain-name	By default, no domain name is specified.
6. Configure the domain name resolution type.	resolve-type { A \| AAAA }	By default, the type is type A. A type A query resolves a domain name to a mapped IPv4 address, and a type AAAA query to a mapped IPv6 address.
7. (Optional.) Specify the source IP address for the probe packets.	· IPv4 address: source ip ip-address · IPv6 address: source ipv6 ipv6-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.
8. (Optional.) Configure the source port for probe packets.	source port port-number	By default, no source port number is configured.
9. (Optional.) Specify the IP address that is expected to be returned.	· IPv4 address: expect ip ip-address · IPv6 address: expect ipv6 ipv6-address	By default, no expected IP address is specified.

Configuring the TCP template

A feature that uses the TCP template performs the TCP operation to test the following items:

· Whether the NQA client can establish a TCP connection to a specific port on the server.

· Whether the requested service is available on the server.

In TCP template view, you can specify the expected data to be returned. If you do not specify the expected data, the TCP operation tests only whether the client can establish a TCP connection to the server.

To configure the TCP template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a TCP template and enter its view.	nqa template tcp name	N/A
3. (Optional.) Specify the destination IP address of the operation.	· IPv4 address: destination ip ip-address · IPv6 address: destination ipv6 ipv6-address	By default, no destination IP address is specified. The destination IP address must be the same as the IP address of the listening service configured on the NQA server.
4. (Optional.) Configure the destination port number for the operation.	destination port port-number	By default, no destination port number is configured. The destination port number must be the same as the port number of the listening service on the NQA server.
5. (Optional.) Specify the payload fill string for requests.	data-fill string	The default string is the hexadecimal number 00010203040506070809.
6. (Optional.) Specify the source IP address for the probe packets.	· IPv4 address: source ip ip-address · IPv6 address: source ipv6 ipv6-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.
7. (Optional.) Configure the expected data.	expect data expression [ offset number ]	By default, no expected data is configured. The expected data is checked only when you configure both the data-fill and expect-data commands.

Configuring the UDP template

A feature that uses the UDP template performs the UDP operation to test the following items:

· Reachability of a specific port on the NQA server.

· Availability of the requested service on the NQA server.

In UDP template view, you can specify the expected data to be returned. If you do not specify the expected data, the UDP operation tests only whether the client can receive the response packet from the server.

The UDP operation requires both the NQA server and the NQA client. Before you perform a UDP operation, configure a UDP listening service on the NQA server. For more information about the UDP listening service configuration, see "Configuring the NQA server."

To configure the UDP template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a UDP template and enter its view.	nqa template udp name	N/A
3. (Optional.) Specify the destination IP address for the operation.	· IPv4 address: destination ip ip-address · IPv6 address: destination ipv6 ipv6-address	By default, no destination IP address is specified. The destination IP address must be the same as the IP address of the listening service configured on the NQA server.
4. (Optional.) Configure the destination port number for the operation.	destination port port-number	By default, no destination port number is configured. The destination port number must be the same as the port number of the listening service on the NQA server.
5. (Optional.) Specify the payload fill string for the probe packets.	data-fill string	The default string is the hexadecimal number 00010203040506070809.
6. (Optional.) Set the payload size for the probe packets.	data-size size	The default setting is 100 bytes.
7. (Optional.) Specify the source IP address for the probe packets.	· IPv4 address: source ip ip-address · IPv6 address: source ipv6 ipv6-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.
8. (Optional.) Configure the expected data.	expect data expression [ offset number ]	By default, no expected data is configured. If you want to configure this command, make sure the data-fill command is already executed.

Configuring the HTTP template

A feature that uses the HTTP template performs the HTTP operation to measure the time it takes the NQA client to obtain data from an HTTP server.

The expected data is checked only when the expected data is configured and the HTTP response contains the Content-Length field in the HTTP header. The Content-Length field indicates the packet body length, and it does not include the header length. An HTTP packet with this field indicates that the packet data does not include the multipart type and the packet body is a data type.

The status code of the HTTP packet is a three-digit field in decimal notation, and it includes the status information for the HTTP server. The first digit defines the class of response, and the last two digits do not have any categorization role.

Configure the HTTP server before you perform the HTTP operation.

To configure the HTTP template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an HTTP template and enter its view.	nqa template http name	N/A
3. Specify the URL of the destination HTTP server.	url url	By default, no URL is specified for the destination HTTP server. Enter the URL in one of the following formats: · http://host/resource. · http://host:port/resource.
4. Specify an HTTP login username.	username username	By default, no HTTP login username is specified.
5. Specify an HTTP login password.	password { cipher \| simple } password	By default, no HTTP login password is specified.
6. Specify the HTTP operation type.	operation { get \| post \| raw }	By default, the HTTP operation type is get, which means obtaining data from the HTTP server. In the HTTP raw operation, use the raw-request command to specify the content of the GET request to be sent to the HTTP server.
7. (Optional.) Enter raw request view.	raw-request	This step is required for the raw operation. Every time you enter the raw request view, the previously configured content of the GET request is removed.
8. (Optional.) Enter or paste the content of the GET request for the HTTP operation.	N/A	This step is required for the raw operation. By default, no contents are specified.
9. (Optional.) Save the input and exit to HTTP template view.	quit	N/A
10. (Optional.) Specify the source IP address for the probe packets.	· IPv4 address: source ip ip-address · IPv6 address: source ipv6 ipv6-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.
11. (Optional.) Configure the expected status codes.	expect status status-list	By default, no expected status code is configured.
12. (Optional.) Configure the expected data.	expect data expression [ offset number ]	By default, no expected data is configured.

Configuring the FTP template

A feature that uses the FTP template performs the FTP operation. The operation measures the time it takes the NQA client to transfer a file to or download a file from an FTP server.

Configure the username and password for the FTP client to log in to the FTP server before you perform an FTP operation. For information about configuring the FTP server, see Fundamentals Configuration Guide.

To configure the FTP template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an FTP template and enter its view.	nqa template ftp name	N/A
3. Specify the URL of the destination FTP server.	url url	By default, no URL is specified for the destination FTP server. Enter the URL in one of the following formats: · ftp://host/filename. · ftp://host:port/filename. When you perform the get operation, the file name is required. When you perform the put operation, the filename argument does not take effect, even if it is specified. The file name for the put operation is determined by the filename command.
4. (Optional.) Specify the FTP operation type.	operation { get \| put }	By default, the FTP operation type is get, which means obtaining files from the FTP server.
5. Specify an FTP login username.	username username	By default, no FTP login username is specified.
6. Specify an FTP login password.	password { cipher \| simple } password	By default, no FTP login password is specified.
7. (Optional.) Specify the name of a file to be transferred.	filename filename	This step is required if you perform the put operation. This configuration does not take effect for the get operation. By default, no file is specified.
8. Set the data transmission mode.	mode { active \| passive }	The default mode is active.
9. (Optional.) Specify the source IP address for the probe packets.	· IPv4 address: source ip ip-address · IPv6 address: source ipv6 ipv6-address	By default, no source IP address is specified. The source IP address must be the IP address of a local interface, and the interface must be up. Otherwise, no probe packets can be sent out.

Configuring optional parameters for the NQA template

Unless otherwise specified, the following optional parameters apply to all types of NQA templates.

The parameter settings take effect only on the current NQA template.

To configure optional parameters for an NQA template:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create an NQA template and enter its view.	nqa template { dns \| ftp \| http \| icmp \| tcp \| udp } name	N/A
3. Configure a description.	description text	By default, no description is configured.
4. Specify the interval at which the NQA operation repeats.	frequency interval	The default setting is 5000 milliseconds. If the operation is not completed when the interval expires, the next operation does not start.
5. Specify the probe timeout time.	probe timeout timeout	The default setting is 3000 milliseconds.
6. Specify the TTL for probe packets.	ttl value	The default setting is 20.
7. Specify the ToS value in the IP header of probe packets.	tos value	The default setting is 0.
8. Specify the VPN where the operation is performed.	vpn-instance vpn-instance-name	By default, the operation is performed on the public network.
9. Configure the number of consecutive successful probes that lead to a successful operation.	reaction trigger probe-pass count	The default setting is 3. If the number of consecutive successful probes for an NQA operation is reached, the NQA client notifies the feature that uses the template of the successful operation event.
10. Configure the number of consecutive probe failures that lead to an operation failure.	reaction trigger probe-fail count	The default setting is 3. If the number of consecutive probe failures for an NQA operation is reached, the NQA client notifies the feature that uses the NQA template of the operation failure.

Displaying and maintaining NQA

Execute display commands in any view.

Task	Command
Display history records of NQA operations.	display nqa history [ admin-name operation-tag ]
Display the current monitoring results of reaction entries.	display nqa reaction counters [ admin-name operation-tag [ item-number ] ]
Display the most recent result of the NQA operation.	display nqa result [ admin-name operation-tag ]
Display NQA statistics.	display nqa statistics [ admin-name operation-tag ]
Display NQA server status.	display nqa server status

NQA configuration examples

ICMP echo operation configuration example

Network requirements

As shown in Figure 3, configure an ICMP echo operation from the NQA client Device A to Device B to test the round-trip time. The next hop of Device A is Device C.

Figure 3 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create an ICMP echo operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

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

# Specify the destination IP address of ICMP echo requests as 10.2.2.2.

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

# Configure 10.1.1.2 as the next hop. The ICMP echo requests are sent through Device C to Device B.

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

# Configure the ICMP echo operation to perform 10 probes.

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

# Specify the probe timeout time for the ICMP echo operation as 500 milliseconds.

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

# Configure the ICMP echo operation to repeat every 5000 milliseconds.

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

# Enable saving history records.

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

# Configure the maximum number of history records that can be saved as 10.

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

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

# Start the ICMP echo operation.

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

# After the ICMP echo operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the ICMP echo operation.

[DeviceA] display nqa result admin test1

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

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: 2011-08-23 15:00:01.2

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the ICMP echo operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test) history records:

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

The output shows that the packets sent by Device A can reach Device B through Device C. No packet loss occurs during the operation. The minimum, maximum, and average round-trip times are 2, 5, and 3 milliseconds, respectively.

DHCP operation configuration example

Network requirements

As shown in Figure 4, configure a DHCP operation 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 operation.

<SwitchA> system-view

[SwitchA] nqa entry admin test1

[SwitchA-nqa-admin-test1] type dhcp

# Specify the DHCP server address 10.1.1.2 as the destination address.

[SwitchA-nqa-admin-test1-dhcp] destination ip 10.1.1.2

# Enable the saving of history records.

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

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

# Start the DHCP operation.

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

# After the DHCP operation runs for a period of time, stop the operation.

[SwitchA] undo nqa schedule admin test1

# Display the most recent result of the DHCP operation.

[SwitchA] display nqa result admin test1

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

Send operation times: 1 Receive response times: 1

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

Square-Sum of round trip time: 262144

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

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the DHCP operation.

[SwitchA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

Index Response Status Time

1 512 Succeeded 2011-11-22 09:56:03.2

The output shows that it took Switch A 512 milliseconds to obtain an IP address from the DHCP server.

DNS operation configuration example

Network requirements

As shown in Figure 5, configure a DNS operation to test whether Device A can perform address resolution through the DNS server and test the resolution time.

Figure 5 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create a DNS operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type dns

# Specify the IP address of the DNS server 10.2.2.2 as the destination address.

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

# Specify the domain name to be translated as host.com.

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

# Enable the saving of history records.

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

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

# Start the DNS operation.

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

# After the DNS operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the DNS operation.

[DeviceA] display nqa result admin test1

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

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: 2011-11-10 10:49:37.3

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the DNS operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test) history records:

Index Response Status Time

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

The output shows that it took Device A 62 milliseconds to translate domain name host.com into an IP address.

FTP operation configuration example

Network requirements

As shown in Figure 6, configure an FTP operation to test the time required for Device A to upload a file to the FTP server. The login username and password are admin and systemtest, respectively. The file to be transferred to the FTP server is config.txt.

Figure 6 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create an FTP operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type ftp

# Specify the URL of the FTP server.

[DeviceA-nqa-admin-test-ftp] url ftp://10.2.2.2

# Specify 10.1.1.1 as the source IP address.

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

# Configure the device to upload file config.txt to the FTP server.

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

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

# Specify the username for the FTP operation as admin.

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

# Specify the password for the FTP operation as systemtest.

[DeviceA-nqa-admin-test1-ftp] password simple systemtest

# Enable the saving of history records.

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

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

# Start the FTP operation.

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

# After the FTP operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the FTP operation.

[DeviceA] display nqa result admin test1

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

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: 2011-11-22 10:07:28.6

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the FTP operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

Index Response Status Time

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

The output shows that it took Device A 173 milliseconds to upload a file to the FTP server.

HTTP operation configuration example

Network requirements

As shown in Figure 7, configure an HTTP operation on the NQA client to test the time required to obtain data from the HTTP server.

Figure 7 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create an HTTP operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type http

# Specify the URL of the HTTP server.

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

# Configure the HTTP operation to get data from the HTTP server.

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

# Configure the operation to use HTTP version 1.0.

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

# Enable the saving of history records.

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

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

# Start the HTTP operation.

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

# After the HTTP operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the HTTP operation.

[DeviceA] display nqa result admin test1

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

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: 2011-11-22 10:12:47.9

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the HTTP operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

Index Response Status Time

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

The output shows that it took Device A 64 milliseconds to obtain data from the HTTP server.

UDP jitter operation configuration example

Network requirements

As shown in Figure 8, configure a UDP jitter operation to test the jitter, delay, and round-trip time between Device A and Device B.

Figure 8 Network diagram

Configuration procedure

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

2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view

[DeviceB] nqa server enable

# Configure a listening service to listen on the IP address 10.2.2.2 and UDP port 9000.

[DeviceB] nqa server udp-echo 10.2.2.2 9000

4. Configure Device A:

# Create a UDP jitter operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

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

# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port.

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

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

# Configure the operation to repeat every 1000 milliseconds.

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

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

# Start the UDP jitter operation.

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

# After the UDP jitter operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the UDP jitter operation.

[DeviceA] display nqa result admin test1

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

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 packet received time: 2011-05-29 13:56:17.6

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packets out of sequence: 0

Packets 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 packets: 0 DS lost packets: 0

Lost packets for unknown reason: 0

# Display the statistics of the UDP jitter operation.

[DeviceA] display nqa statistics admin test1

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

NO. : 1

Start time: 2011-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 ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packets out of sequence: 0

Packets 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 packets: 0 DS lost packets: 0

Lost packets for unknown reason: 0

SNMP operation configuration example

Network requirements

As shown in Figure 9, configure an SNMP operation to test the time the NQA client uses to get a response from the SNMP agent.

Figure 9 Network diagram

Configuration procedure

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

2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

3. Configure the SNMP agent (Device B):

# Set the SNMP version to all.

<DeviceB> system-view

[DeviceB] snmp-agent sys-info version all

# Set the read community to public.

[DeviceB] snmp-agent community read public

# Set the write community to private.

[DeviceB] snmp-agent community write private

4. Configure Device A:

# Create an SNMP operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type snmp

# Configure 10.2.2.2 as the destination IP address of the SNMP operation.

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

# Enable the saving of history records.

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

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

# Start the SNMP operation.

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

# After the SNMP operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the SNMP operation.

[DeviceA] display nqa result admin test1

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

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: 2011-11-22 10:24:41.1

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the SNMP operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

Index Response Status Time

1 50 Succeeded 2011-11-22 10:24:41.1

The output shows that it took Device A 50 milliseconds to receive a response from the SNMP agent.

TCP operation configuration example

Network requirements

As shown in Figure 10, configure a TCP operation to test the time required for Device A and Device B to establish a TCP connection.

Figure 10 Network diagram

Configuration procedure

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

2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view

[DeviceB] nqa server enable

# Configure a listening service to listen on the IP address 10.2.2.2 and TCP port 9000.

[DeviceB] nqa server tcp-connect 10.2.2.2 9000

4. Configure Device A:

# Create a TCP operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type tcp

# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port.

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

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

# Enable the saving of history records.

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

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

# Start the TCP operation.

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

# After the TCP operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the TCP operation.

[DeviceA] display nqa result admin test1

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

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: 2011-11-22 10:27:25.1

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the TCP operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

Index Response Status Time

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

The output shows that it took Device A 13 milliseconds to establish a TCP connection to port 9000 on the NQA server.

UDP echo operation configuration example

Network requirements

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

Figure 11 Network diagram

Configuration procedure

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

2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view

[DeviceB] nqa server enable

# Configure a listening service to listen on the IP address 10.2.2.2 and UDP port 8000.

[DeviceB] nqa server udp-echo 10.2.2.2 8000

4. Configure Device A:

# Create a UDP echo operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

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

# Configure 10.2.2.2 as the destination IP address and port 8000 as the destination port.

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

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

# Enable the saving of history records.

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

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

# Start the UDP echo operation.

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

# After the UDP echo operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the UDP echo operation.

[DeviceA] display nqa result admin test1

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

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: 2011-11-22 10:36:17.9

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the UDP echo operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

Index Response Status Time

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

The output shows that the round-trip time between Device A and port 8000 on Device B is 25 milliseconds.

UDP tracert operation configuration example

Network requirements

As shown in Figure 12, configure a UDP tracert operation to determine the routing path from Device A to Device B.

Figure 12 Network diagram

Configuration procedure

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

2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

3. Use the ip ttl-expires enable command on the intermediate device and use the ip unreachables enable command on Device B.

4. Configure Device A:

# Create a UDP tracert operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type udp-tracert

# Specify 10.2.2.2 as the destination IP address.

[DeviceA-nqa-admin-test1-udp-tracert] destination ip 10.2.2.2

# Set the destination port number to 33434.

[DeviceA-nqa-admin-test1-udp-tracert] destination port 33434

# Configure Device A to perform three probes to each hop.

[DeviceA-nqa-admin-test1-udp-tracert] probe count 3

# Set the probe timeout time to 500 milliseconds.

[DeviceA-nqa-admin-test1-udp-tracert] probe timeout 500

# Configure the UDP tracert operation to repeat every 5000 milliseconds.

[DeviceA-nqa-admin-test1-udp-tracert] frequency 5000

# Specify GigabitEthernet 3/0/1 as the output interface for UDP packets.

[DeviceA-nqa-admin-test1-udp-tracert] out interface gigabitethernet 3/0/1

# Enable the no-fragmentation feature.

[DeviceA-nqa-admin-test1-udp-tracert] no-fragment enable

# Set the maximum number of consecutive probe failures to 6.

[DeviceA-nqa-admin-test1-udp-tracert] max-failure 6

# Set the TTL value to 1 for UDP packets in the start round of the UDP tracert operation.

[DeviceA-nqa-admin-test1-udp-tracert] init-ttl 1

# Start the UDP tracert operation.

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

# After the UDP tracert operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the UDP tracert operation.

[DeviceA] display nqa result admin test1

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

Send operation times: 6 Receive response times: 6

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

Square-Sum of round trip time: 1

Last succeeded probe time: 2013-09-09 14:46:06.2

Extended results:

Packet loss in test: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

UDP-tracert results:

TTL Hop IP Time

1 3.1.1.1 2013-09-09 14:46:03.2

2 10.2.2.2 2013-09-09 14:46:06.2

# Display the history records of the UDP tracert operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

Index TTL Response Hop IP Status Time

1 2 2 10.2.2.2 Succeeded 2013-09-09 14:46:06.2

1 2 1 10.2.2.2 Succeeded 2013-09-09 14:46:05.2

1 2 2 10.2.2.2 Succeeded 2013-09-09 14:46:04.2

1 1 1 3.1.1.1 Succeeded 2013-09-09 14:46:03.2

1 1 2 3.1.1.1 Succeeded 2013-09-09 14:46:02.2

1 1 1 3.1.1.1 Succeeded 2013-09-09 14:46:01.2

Voice operation configuration example

Network requirements

As shown in Figure 13, configure a voice operation to test jitters between Device A and Device B.

Figure 13 Network diagram

Configuration procedure

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

2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view

[DeviceB] nqa server enable

# Configure a listening service to listen on IP address 10.2.2.2 and UDP port 9000.

[DeviceB] nqa server udp-echo 10.2.2.2 9000

4. Configure Device A:

# Create a voice operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type voice

# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port.

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

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

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

# Start the voice operation.

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

# After the voice operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the voice operation.

[DeviceA] display nqa result admin test1

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

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 packet received time: 2011-06-13 09:49:31.1

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packets out of sequence: 0

Packets 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 packets: 0 DS lost packets: 0

Lost packets for unknown reason: 0

Voice scores:

MOS value: 4.38 ICPIF value: 0

# Display the statistics of the voice operation.

[DeviceA] display nqa statistics admin test1

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

NO. : 1

Start time: 2011-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 ratio: 0%

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packets out of sequence: 0

Packets 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 packets: 0 DS lost packets: 0

Lost packets for unknown reason: 0

Voice scores:

Max MOS value: 4.38 Min MOS value: 4.38

Max ICPIF value: 0 Min ICPIF value: 0

DLSw operation configuration example

Network requirements

As shown in Figure 14, configure a DLSw operation to test the response time of the DLSw device.

Figure 14 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create a DLSw operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type dlsw

# Configure 10.2.2.2 as the destination IP address.

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

# Enable the saving of history records.

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

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

# Start the DLSw operation.

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

# After the DLSw operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the DLSw operation.

[DeviceA] display nqa result admin test1

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

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: 2011-11-22 10:40:27.7

Extended results:

Packet loss ratio: 0%

Failures due to timeout: 0

Failures due to disconnect: 0

Failures due to no connection: 0

Failures due to internal error: 0

Failures due to other errors: 0

# Display the history records of the DLSw operation.

[DeviceA] display nqa history admin test1

NQA entry (admin admin, tag test1) history records:

Index Response Status Time

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

The output shows that the response time of the DLSw device is 19 milliseconds.

Path jitter operation configuration example

Network requirements

As shown in Figure 15, configure a path jitter operation to test the round trip time and jitters from Device A to Device B and Device C.

Figure 15 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Use the ip ttl-expires enable command on Device B and use the ip unreachables enable command on Device C.

# Create a path jitter operation.

<DeviceA> system-view

[DeviceA] nqa entry admin test1

[DeviceA-nqa-admin-test1] type path-jitter

# Specify 10.2.2.2 as the destination IP address of ICMP echo requests.

[DeviceA-nqa-admin-test1-path-jitter] destination ip 10.2.2.2

# Configure the path jitter operation to repeat every 10000 milliseconds.

[DeviceA-nqa-admin-test1-path-jitter] frequency 10000

[DeviceA-nqa-admin-test1-path-jitter] quit

# Start the path jitter operation.

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

# After the path jitter operation runs for a period of time, stop the operation.

[DeviceA] undo nqa schedule admin test1

# Display the most recent result of the path jitter operation.

[DeviceA] display nqa result admin test1

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

Hop IP 10.1.1.2

Basic Results

Send operation times: 10 Receive response times: 10

Min/Max/Average round trip time: 9/21/14

Square-Sum of round trip time: 2419

Extended Results

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packets out of sequence: 0

Packets arrived late: 0

Path-Jitter Results

Jitter number: 9

Min/Max/Average jitter: 1/10/4

Positive jitter number: 6

Min/Max/Average positive jitter: 1/9/4

Sum/Square-Sum positive jitter: 25/173

Negative jitter number: 3

Min/Max/Average negative jitter: 2/10/6

Sum/Square-Sum positive jitter: 19/153

Hop IP 10.2.2.2

Basic Results

Send operation times: 10 Receive response times: 10

Min/Max/Average round trip time: 15/40/28

Square-Sum of round trip time: 4493

Extended Results

Failures due to timeout: 0

Failures due to internal error: 0

Failures due to other errors: 0

Packets out of sequence: 0

Packets arrived late: 0

Path-Jitter Results

Jitter number: 9

Min/Max/Average jitter: 1/10/4

Positive jitter number: 6

Min/Max/Average positive jitter: 1/9/4

Sum/Square-Sum positive jitter: 25/173

Negative jitter number: 3

Min/Max/Average negative jitter: 2/10/6

Sum/Square-Sum positive jitter: 19/153

NQA collaboration configuration example

Network requirements

As shown in Figure 16, configure a static route to Switch C with Switch B as the next hop on Switch A. Associate the static route, a track entry, and an ICMP echo operation to monitor the state of the static route.

Figure 16 Network diagram

Configuration procedure

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

2. On Switch A, configure a static route, 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, configure an ICMP echo operation:

# Create an NQA operation with the administrator name admin and operation tag test1.

[SwitchA] nqa entry admin test1

# Configure the NQA operation type as ICMP echo.

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

# Configure 10.2.1.1 as the destination IP address.

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

# Configure the operation to repeat every 100 milliseconds.

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

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

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

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

# Start the ICMP operation.

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

4. On Switch A, create track entry 1, and associate it with reaction entry 1 of the NQA operation.

[SwitchA] track 1 nqa entry admin test1 reaction 1

Verifying the configuration

# Display information about all the track entries on Switch A.

[SwitchA] display track all

Track ID: 1

State: Positive

Duration: 0 days 0 hours 0 minutes 0 seconds

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

Tracked object:

NQA entry: admin test1

Reaction: 1

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

[SwitchA] display ip routing-table

Destinations : 13 Routes : 13

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

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.0/32 Direct 0 0 10.2.1.2 Vlan3

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.255/32 Direct 0 0 10.2.1.2 Vlan3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

224.0.0.0/4 Direct 0 0 0.0.0.0 NULL0

224.0.0.0/24 Direct 0 0 0.0.0.0 NULL0

255.255.255.255/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.

# 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

# Display information about all the track entries on Switch A.

[SwitchA] display track all

Track ID: 1

State: Negative

Duration: 0 days 0 hours 0 minutes 0 seconds

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

Tracked object:

NQA entry: admin test1

Reaction: 1

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

[SwitchA] display ip routing-table

Destinations : 12 Routes : 12

Destination/Mask Proto Pre Cost NextHop Interface

0.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.0/24 Direct 0 0 10.2.1.2 Vlan3

10.2.1.0/32 Direct 0 0 10.2.1.2 Vlan3

10.2.1.2/32 Direct 0 0 127.0.0.1 InLoop0

10.2.1.255/32 Direct 0 0 10.2.1.2 Vlan3

127.0.0.0/8 Direct 0 0 127.0.0.1 InLoop0

127.0.0.0/32 Direct 0 0 127.0.0.1 InLoop0

127.0.0.1/32 Direct 0 0 127.0.0.1 InLoop0

127.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

224.0.0.0/4 Direct 0 0 0.0.0.0 NULL0

224.0.0.0/24 Direct 0 0 0.0.0.0 NULL0

255.255.255.255/32 Direct 0 0 127.0.0.1 InLoop0

The output shows that the static route does not exist, and the status of the track entry is negative.

ICMP template configuration example

Network requirements

As shown in Figure 17, configure an ICMP template for a feature to perform the ICMP echo operation from Device A to Device B.

Figure 17 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create ICMP template icmp.

<DeviceA> system-view

[DeviceA] nqa template icmp icmp

# Specify 10.2.2.2 as the destination IP address of ICMP echo requests.

[DeviceA-nqatplt-icmp-icmp] destination ip 10.2.2.2

# Set the probe timeout time for the ICMP echo operation to 500 milliseconds.

[DeviceA-nqatplt-icmp-icmp] probe timeout 500

# Configure the ICMP echo operation to repeat every 3000 milliseconds.

[DeviceA-nqatplt-icmp-icmp] frequency 3000

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-icmp-icmp] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-icmp-icmp] reaction trigger probe-fail 2

DNS template configuration example

Network requirements

As shown in Figure 18, configure a DNS template for a feature to perform the DNS operation. The operation tests whether Device A can perform the address resolution through the DNS server.

Figure 18 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create DNS template dns.

<DeviceA> system-view

[DeviceA] nqa template dns dns

# Specify the IP address of the DNS server 10.2.2.2 as the destination IP address.

[DeviceA-nqatplt-dns-dns] destination ip 10.2.2.2

# Specify the domain name to be translated as host.com.

[DeviceA-nqatplt-dns-dns] resolve-target host.com

# Specify the domain name resolution type as type A.

[DeviceA-nqatplt-dns-dns] resolve-type A

# Specify the expected IP address as 3.3.3.3.

[DeviceA-nqatplt-dns-dns] expect ip 3.3.3.3

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-dns-dns] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-dns-dns] reaction trigger probe-fail 2

TCP template configuration example

Network requirements

As shown in Figure 19, configure a TCP template for a feature to perform the TCP operation. The operation tests whether Device A can establish a TCP connection to Device B.

Figure 19 Network diagram

Configuration procedure

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

2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view

[DeviceB] nqa server enable

# Configure a listening service to listen to the IP address 10.2.2.2 and TCP port 9000.

[DeviceB] nqa server tcp-connect 10.2.2.2 9000

4. Configure Device A:

# Create TCP template tcp.

<DeviceA> system-view

[DeviceA] nqa template tcp tcp

# Configure 10.2.2.2 as the destination IP address and port 9000 as the destination port.

[DeviceA-nqatplt-tcp-tcp] destination ip 10.2.2.2

[DeviceA-nqatplt-tcp-tcp] destination port 9000

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-tcp-tcp] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-tcp-tcp] reaction trigger probe-fail 2

UDP template configuration example

Network requirements

As shown in Figure 20, configure a UDP template for a feature to perform the UDP operation. The operation tests whether Device A can receive a response from Device B.

Figure 20 Network diagram

Configuration procedure

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

2. Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

3. Configure Device B:

# Enable the NQA server.

<DeviceB> system-view

[DeviceB] nqa server enable

# Configure a listening service to listen to the IP address 10.2.2.2 and UDP port 9000.

[DeviceB] nqa server udp-echo 10.2.2.2 9000

4. Configure Device A:

# Create UDP template udp.

<DeviceA> system-view

[DeviceA] nqa template udp udp

# Specify 10.2.2.2 as the destination IP address.

[DeviceA-nqatplt-udp-udp] destination ip 10.2.2.2

# Set the destination port number to 9000.

[DeviceA-nqatplt-udp-udp] destination port 9000

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-udp-udp] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-udp-udp] reaction trigger probe-fail 2

HTTP template configuration example

Network requirements

As shown in Figure 21, configure an HTTP template for a feature to perform the HTTP operation. The operation tests whether the NQA client can get data from the HTTP server.

Figure 21 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create HTTP template http.

<DeviceA> system-view

[DeviceA] nqa template http http

# Specify the URL of the server.

[DeviceA-nqatplt-http-http] url http://10.2.2.2/index.htm

# Configure the HTTP operation to get data from the HTTP server.

[DeviceA-nqatplt-http-http] operation get

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-http-http] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-http-http] reaction trigger probe-fail 2

FTP template configuration example

Network requirements

As shown in Figure 22, configure an FTP template for a feature to perform the FTP operation. The operation tests whether Device A can upload a file to the FTP server. The login username and password are admin and systemtest, respectively. The file to be transferred to the FTP server is config.txt.

Figure 22 Network diagram

Configuration procedure

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

# Configure static routes or a routing protocol to make sure the devices can reach each other. (Details not shown.)

# Create FTP template ftp.

<DeviceA> system-view

[DeviceA] nqa template ftp ftp

# Specify the URL of the FTP server.

[DeviceA-nqatplt-ftp-ftp] url ftp://10.2.2.2

# Specify 10.1.1.1 as the source IP address.

[DeviceA-nqatplt-ftp-ftp] source ip 10.1.1.1

# Configure the device to upload file config.txt to the FTP server.

[DeviceA-nqatplt-ftp-ftp] operation put

[DeviceA-nqatplt-ftp-ftp] filename config.txt

# Specify the username for the FTP server login as admin.

[DeviceA-nqatplt-ftp-ftp] username admin

# Specify the password for the FTP server login as systemtest.

[DeviceA-nqatplt-ftp-ftp] password simple systemtest

# If the number of consecutive successful probes reaches 2, the operation succeeds. The NQA client notifies the feature of the successful operation event.

[DeviceA-nqatplt-ftp-ftp] reaction trigger probe-pass 2

# If the number of consecutive probe failures reaches 2, the operation fails. The NQA client notifies the feature of the operation failure.

[DeviceA-nqatplt-ftp-ftp] reaction trigger probe-fail 2

12-Network Management and Monitoring Configuration Guide

Configuring the TCP operation

Configuring the UDP echo operation

Configuring the UDP tracert operation

Threshold types

Triggered actions

Reaction entry

Configuration procedure

Scheduling the NQA operation on the NQA client

NQA template configuration task list

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

Path jitter operation configuration example

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Verifying the configuration

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