Keywords: NQA, test, probe, collaboration, scheduling
Abstract: Network Quality Analyzer (NQA) is a network performance probe and statistics technology used to collect statistics on the network information such as response time, jitter, and packet loss rate. NQA also provides the collaboration between the track module and the application modules to monitor network status change in real time. This manual introduces the basic concepts first, and then introduces the mechanism, technical characteristics and application scenarios of NQA in detail.
Dynamic Host Configuration Protocol
Data Link Switching
Domain Name System
File Transfer Protocol
Hypertext Transfer Protocol
Internet Control Message Protocol
Calculated Planning Impairment Factor
Mean Opinion Scores
Network Quality Analyzer
Simple Network Management Protocol
Transmission Control Protocol
User Datagram Protocol
Voice over IP
Table of Contents
With the fast development of the Internet, it supports more and more services and applications. Traditional network performance analysis tools such as ping and tracert cannot satisfy users’ requirements on service diversity and real-time monitoring of the network.
Network Quality Analyzer (NQA) analyzes network performance and service quality by sending test packets, providing you with network performance parameters such as jitter, total delay of HTTP, delay for obtaining an IP address through DHCP, TCP connection delay, FTP connection delay and file transfer rate. With the NQA test results, you can:
l Know network performance in time and then take corresponding measures.
NQA also provides the collaboration between the track module and the application modules to monitor network status change in real time, and then take corresponding actions, thus avoiding communication interruption or service quality decrease.
NQA has the following benefits:
l Supporting multiple test types
Traditional ping tool can only use the Internet Control Message Protocol (ICMP) to test the reachability of the destination and the roundtrip time of a packet between the source and the destination. NQA is an enhanced ping tool used for testing the performance of protocols running on networks.
At present, NQA supports eleven test types: ICMP-echo, DHCP, DNS, FTP, HTTP, UDP jitter, SNMP, TCP, UDP echo, voice, and DLSw.
l Supporting enabling of multiple test groups at the same time
The NQA module supports enabling of multiple test groups at the same time and you can configure the number of test groups as needed. For a DHCP test, however, only one test group can perform a test at one time.
l Supporting the collaboration function
The collaboration function means that NQA performs probes and notify other modules of the probe results, and these modules then take corresponding actions according to the probe results. At present, collaboration between NQA and static routing, backup center and policy routing is implemented.
l NQA agent: client in an NQA test.
l NQA server: In a narrow sense, an NQA server is the NQA server in a UDP echo, TCP, UDP jitter, or voice test; in a broad sense, an NQA server refers to the peer device to be probed, such as an FTP server or an HTTP server.
l Test group: An NQA test is performed based on test groups. Each test group has attributes such as test type, destination address, destination port, and packet sending interval.
l Identification of a test group: For better management of an NQA test group, each test group has an administrator name and operation tag, which can uniquely identify the test group. After a test group is created, you can configure the test type in test group view and enter test type view to configure other parameters.
l Probe: An independent process in which complete probe results can be obtained. For a TCP or DLSw test, one probe means one connection; for a UDP jitter or voice test, the number of packets sent in one probe depends on the probe packet-number command; for an FTP, HTTP or DHCP test, one probe means to carry out a corresponding function; for an ICMP-echo or UDP echo test, one probe packet is sent in one probe; for an SNMP test, three probe packets are sent in one probe.
l Test: One NQA test involves multiple consecutive probes.
l UDP jitter test: A group of probe packets are sent in one UDP jitter test and the probe results are calculated based on the information carried in each response.
l SD: Source to destination.
l DS: Destination to source.
l Test frequency: The interval between the start time of two consecutive tests for a test group.
l Test results: Statistics of all the probes in one test. If only some of the probes in one test are completed, the statistics of the probes completed will be displayed.
l History record: A history record is related to a probe, and is generated for each probe.
The ICMP-echo function is the most basic function of NQA, and is implemented following RFC 2925. An ICMP-echo test is used to test reachability of a destination, and calculate the response time and packet loss rate by sending ICMP-echo requests.
An ICMP-echo test can succeed only if the destination device can respond correctly to the ICMP-echo requests. An NQA client sends an ICMP-echo request to the destination IP address according to the configured probe time and interval. Upon receiving the ICMP-echo request, the destination IP address sends an ICMP-echo reply. The NQA client calculates the response time of the destination IP address and the packet loss rate based on the time when it receives the ICMP-echo reply and the number of the received packets, and thus the current network performance and network status can be analyzed.
The test results and history records of an ICMP-echo test will be recorded in the test group, and you can use command lines to view them.
A UDP echo test is used to test the connectivity and delay of a network by sending UDP echo packets. When you test the network connectivity and delay of a UDP packet, you must enable the NQA server, and bring up the corresponding UDP port on the NQA server.
An NQA client sends a UDP packet to the destination IP address according to the configured probe time and interval. Upon receiving the UDP packet, the destination sends a response. The NQA client then calculates the time for the packet to reach the destination and the packet loss rate, thus analyzing the network performance and status.
The test results and history records of a UDP echo test will be recorded in the test group, and you can use command lines to view them.
UDP jitter is an important tool to detect network status and monitor real-time service quality. Real-time services such as voice and video have high requirements on delay jitters. A UDP jitter test can be used to judge whether a network can provide high quality services for real-time services.
As packets in a UDP jitter test are proprietary packets, the peer device should be NQA-enabled and be configured with NQA server related parameters; therefore, the device cannot be a device of other vendors.
The process of a UDP jitter test is as shown in Figure 1:
1) The NQA agent sends the NQA server a UDP jitter packet, which is timestamped when it leaves the NQA agent. The timestamp is T1.
2) When this packet arrives at the NQA server, it is timestamped by the NQA server. The timestamp is T2.
3) When the UDP jitter packet leaves the NQA server, the NQA server timestamps it. The timestamp is T3.
4) When the NQA agent receives the response, the time when it receives the packet is timestamped T4.
5) The NQA agent sends multiple probe packets at a fixed interval (T5-T1), and repeats the above process.
6) The NQA agent calculates the SD (source to destination) and DS (destination to source) delay jitters according to the roundtrip time of two consecutive packets it successfully received. Take the two packets shown in Figure 1 as an example:
SD jitter = (T6-T5) – (T2-T1) = (T6-T2) – (T5-T1)
DS jitter = (T8-T7) – (T4-T3) = (T8-T4) – (T7-T3)
As shown in Figure 2, SD or DS packet loss rate can be calculated by the UDP jitter client and server.
Each packet sent by the NQA agent contains a packet ID. The NQA server updates the biggest packet ID and the number of packets received every time it receives a packet, and sends them back to the NQA agent in the response; the NQA agent then records the number of responses and obtains the information of the NQA sever from these responses.
The information that the NQA agent can obtain includes:
1) Number of packets sent by the NQA agent;
2) The greatest packet ID and the number of packets received by the NQA server;
3) Number of packets received by the NQA agent.
Based on the information, the following can be calculated:
Number of packets lost from source to destination = the biggest packet ID received by the NQA server – Number of packets received by the NQA server
Number of packets lost from destination to source = Number of packets received by the NQA server – Number of packets received by the NQA agent
Number of packets lost on the unknown directions = Number of packets sent by the NQA agent – Number of packets received by the NQA agent – Number of packets lost from source to destination – Number of packets lost from destination to source
UDP jitter can collect the following statistics: packet response time, packet loss rate, reasons for probe failures, delay jitters from the NQA agent to the NQA server, delay jitters from the NQA server to the NQA agent and uni-directional packet loss rate (SD or DS).
The test results and history records of a UDP jitter test will be recorded in the test group, and you can use command lines to view them.
In a UDP jitter test, a group of packets are sent in one probe, and this group of packets corresponds to one history record only. Therefore, to know the UDP jitter test results, you are recommended to view the probe results, rather than the history records.
A voice test is used to test voice over IP (VoIP) network status, and collect VoIP network parameters so that users can adjust the network accordingly.
The voice test can be used to test delay jitter, delay, and packet loss. The calculation method is similar to that of a UDP jitter test.
The voice parameter values that indicate VoIP network status can also be calculated in a voice test, including:
l Calculated Planning Impairment Factor (ICPIF): Measures attenuation of voice data in a network, depending on packet loss and delay. A higher value represents a lower network quality.
l Mean Opinion Scores (MOS): Measures quality of a VoIP network. A MOS value can be evaluated by using the ICPIF value, in the range 1 to 15. A higher value represents a higher quality of a VoIP network.
The evaluation of voice quality depends on users’ tolerance to voice quality, and this factor should be taken into consideration. For users with higher tolerance to voice quality, you can use the advantage-factor command to configure the advantage factor. When the system calculates the ICPIF value, this advantage factor is subtracted to modify ICPIF and MOS values and thus both the objective and subjective factors are considered when you evaluate the voice quality.
The test results and history records of a voice test will be recorded in the test group, and you can use command lines to view them.
l As packets in a voice test are proprietary packets, the peer device should be NQA-enabled and be configured with NQA server related parameters; therefore, the device cannot be a device of other vendors.
l In a voice test, a group of packets are sent in one probe, and this group of packets corresponds to one history record only. Therefore, to know the voice test results, you are recommended to view the probe results, rather than the history records.
A TCP test is used to test the TCP connection between a client and a specified server and the setup time for the connection.
The test results and history records of a TCP test will be recorded in the test group, and you can use command lines to view them.
An NQA DLSw test initiates a TCP connection to the DLSw port of the peer device, and then decides whether the DLSw function has been enabled on the peer device according to whether the connection can be established. As an NQA DLSw test is only used to test whether DLSw is enabled on the peer device, it can be considered as a TCP test with a fixed destination port number.
The test results and history records of a DLSw test will be recorded in the test group, and you can use command lines to view them.
An SNMP test is used to send SNMP packets to a specified port to decide whether SNMP is enabled on the peer device according to the peer’s response. You cannot specify the SNMP version on the client. Every time a test is performed, all the SNMP versions SNMPv1, SNMPv2c and SNMPv3 are tested; as long as a response is received from any version, the probe succeeds. At present, the SNMP test does not distinguish between different SNMP versions on the SNMP server.
The test results and history records of an SNMP test will be recorded in the test group, and you can use command lines to view them.
An HTTP test is used to test the connection between the NQA client and a specified HTTP server, thus deciding whether the NQA client provides HTTP services and the time for establishing the connection.
An HTTP test supports get and post operations, that is, it is used to send a get or post request to a specified HTTP server, and then calculates the test time after receiving a response. This process is to establish a connection with the HTTP server; if the connection is established, the test succeeds.
The test results and history records of an HTTP test will be recorded in the test group, and you can use command lines to view them.
An FTP test is used to test the connection between the NQA client and a specified FTP server and the time necessary for the NQA client to transfer a file to or download a file from the FTP server.
An FTP test supports both get and put operations. A get operation does not put a file into the local file system, but calculate the time for downloading the file, and automatically releases the memory after the calculation; a put operation does not put a local file on the server, but uploads the file with fixed size and content (you can configure the filename, and the data is the fixed data specified by the system; if the configured filename is the same as that on the server, the existing file is overwritten, and the file will not be deleted after the test is completed.). Therefore, an FTP test is unrelated to the local file system.
A DHCP test simulates a DHCP client to initiate a DHCP request on the specified interface. Then it decides whether the DHCP server services exist on the network segment where the interface resides and tests the time used for the NQA client obtains an IP address.
A DHCP just uses an interface to send DHCP packets, and as long as an address is obtained, the lease of the address will be released at once, and therefore, it does not occupy the address resources of the DHCP server. An interface that is performing a DHCP test must be in the up state.
The test results and history records of a DHCP test will be recorded in the test group, and you can use command lines to view them.
A DNS test is mainly used to test whether the NQA client can resolve a domain name into an IP address through a DNS server and the time required for resolution.
As a DNS test is a process to simulate the domain name resolution, the mapping between the domain name and the IP address will not be saved.
The test results and history records of a DNS test will be recorded in the test group, and you can use command lines to view them.
Collaboration is implemented by establishing collaboration entries to monitor the probe results of the current test group. If the number of consecutive probe failures reaches a certain limit, collaboration with other modules is triggered (collaboration is not supported in a UDP jitter test).The implementation of collaboration is as shown in Figure 3.
The collaboration here involves three parts: the application modules, the track module, and the detection modules (for example, NQA).The track module works between the application modules and the detection modules. If the state of a track entry changes, the detection module notifies the track module, which then notify the application module to take corresponding actions. In this way, collaboration can be implemented.
Take static routing as an example. You have configured a static route with the next hop 192.168.0.88. If 192.168.0.88 is reachable, the static route is valid; if 192.168.0.88 is unreachable, the static route is invalid. With the collaboration between NQA, the track module and the application modules, real time monitoring of reachability of static routes can be implemented. If 192.168.0.88 is detected to be unreachable, NQA will inform the static routing module through the track module. The static routing module then can know that the static route is invalid.
Before performing a UDP jitter, UDP echo, TCP or voice test, you need to configure the NQA server first. For a UDP echo test, the NQA server simply sends the received packets back to the client; for a TCP test, the NQA server simply creates a listening port to connect to the client; for a UDP jitter or voice test, however, the NQA server needs to put a timestamp in the packet, records the greatest packet ID received and the number of packets in the packet, and sends the packet to the client.
NQA is generally used in the collaboration function. NQA can collaborate with VRRP, static routing, backup center, and policy routing through the track module, so as to detect network faults in time and avoid communication interruption or service quality decrease.
Through collaboration between NQA and VRRP, you can monitor the upper link. If there is a fault on the upper link of the master of a VRRP group, hosts in the LAN cannot access the external network through the master. In this case, NQA will notify VRRP through the track module to decrease the priority of the master by a specified value, allowing a higher priority router in the VRRP group to become the master to maintain proper communication between the hosts in the LAN and the external network. After the upper link recovers, NQA will notify VRRP to restore the priority of the router whose priority is decreased through the track module.
As shown in Figure 4, configure VRRP-track-NQA collaboration on Device A to implement real-time monitoring of 10.1.2.2. If 10.1.2.2 is detected unreachable, NQA will notify the track module, which will notify VRRP to decrease the priority of Device A by a specified value, allowing Device B to become the master to forward packets.
With the collaboration between NQA, track module and static routing module, real time monitoring of reachability of static routes can be implemented. NQA probes the next hop of the static route. If the probe succeeds, the static route is valid; otherwise, the static route is invalid.
As shown in Figure 5, on Device B, configure the next hop address of the static route to Device C as 10.1.2.1, and configure static routing-track-NQA collaboration. If 10.1.2.1 is detected unavailable, NQA will notify the track module, which will notify the static routing module to set the static route as invalid; if 10.1.2.1 is detected available, NQA will notify the track module, which will notify the static routing module to set the static route as valid.
NQA-backup center collaboration implements interface backup state change based on network status.
NQA is used to monitor the status of the main interface. If detecting that the link on the main interface fails, the NQA will notify the track module, which then notify the backup center to enable the link on the backup interface for communication; if NQA detects that the link on the main interface restores, it will notify the track module, which then notify the backup center to communicate through the main interface.
As shown in Figure 6, data from Device A can reach Device C through Device B or Device D. Suppose the main link is Device A-Device B-Device C, that is, data from Device A is sent to Device C through Device B. On Device A, configure backup center-track-NQA collaboration. If the main link is detected unreachable, NQA notifies the track module, which then notifies the backup center to use Device A-Device D-Device C as the main link, that is, data from Device A is sent to Device C through Device D; if the link Device A-Device B-Device C recovers, NQA notifies the track module, which then notifies the backup center to use the Device A-Device B-Device C link as the main link, that is, data from Device A is sent to Device C from Device B.
Collaborated with NQA and track, IP unicast policy routing can be used more flexibly, and its awareness of the dynamic networking environment is enhanced.
You can associate the policy routing with NQA through track when configuring the outgoing interface, the default outgoing interface, the next hop, and the default next hop. If the NQA probe succeeds, the configuration is valid and can be used to instruct forwarding; if the probe fails, the configuration is invalid and is ignored during packet forwarding.
As shown in Figure 7, Device A can connect to the Internet through Device B or Device C. Define a policy routing on Device A, thus all TCP packets received on the interface connecting the LAN are forwarded by Device B (with the next hop of the packets being 10.2.1.2). Configure collaboration between policy routing, NQA and Track to use NQA to detect the reachability of Device B. If Device B is reachable, the policy can instruct forwarding, and the next hop of the TCP packets received on the interface is 10.2.1.2; otherwise, the policy is invalid, and an available next hop of the TCP packets received on the interface will be searched according to the routing table.
Copyright ©2008-2009 Hangzhou H3C Technologies Co., Ltd. All rights reserved.
No part of this manual may be reproduced or transmitted in any form or by any means without prior written consent of Hangzhou H3C Technologies Co., Ltd.
The information in this document is subject to change without notice.