12-Network Management and Monitoring Configuration Guide

HomeSupportRoutersH3C SR8800 Router SeriesConfigure & DeployConfiguration GuidesH3C SR8800 Configuration Guide-Release3347-6W10312-Network Management and Monitoring Configuration Guide
02-NQA Configuration
Title Size Download
02-NQA Configuration 447.48 KB

Configuring NQA

NQA overview

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

With the NQA test results, you can diagnose and locate network faults, know network performance in time and take proper actions.

NQA features

Supporting multiple test types

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

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

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

Supporting the collaboration function

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

Figure 1 Implementing collaboration

 

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

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

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

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

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

1.       NQA monitors the reachability to 192.168.0.88.

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

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

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

 

 

NOTE:

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

 

Supporting threshold monitoring

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

1.       Monitored elements

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

Table 1 Monitored elements and NQA test types

Monitored elements

Test type supported

Probe duration

Tests excluding UDP jitter test and voice test

Count of probe failures

Tests excluding UDP jitter test and voice test

Packet round-trip time

UDP jitter test and voice test

Count of discarded packets

UDP jitter test and voice test

One-way delay jitter (source-to-destination and destination-to-source)

UDP jitter test and voice test

One-way delay (source-to-destination and destination-to-source)

UDP jitter test and voice test

Calculated Planning Impairment Factor (ICPIF) (see “Configuring voice tests)

Voice test

Mean Opinion Scores (MOS) (see “Configuring voice tests)

Voice test

 

2.       Threshold types

The following threshold types are supported:

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

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

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

 

 

NOTE:

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

 

3.       Triggered actions

The following actions may be triggered:

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

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

 

 

NOTE:

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

 

4.       Reaction entry

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

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

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

NQA concepts

Test group

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

Test and probe

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

Probe operations vary with NQA test types.

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

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

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

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

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

NQA client and server

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

Figure 2 Relationship between the NQA client and NQA server

 

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

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

NQA probe operation procedure

An NQA probe operation involves the following steps:

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

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

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

NQA configuration task list

Complete the following task to enable the NQA server:

 

Task

Remarks

Configuring the NQA server

Required for TCP, UDP echo, UDP jitter and voice tests

 

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

1.       Enable the NQA client.

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

3.       Schedule the NQA test group.

Complete these tasks to configure NQA client:

 

Task

Remarks

Enabling the NQA client

Required

Creating an NQA test group

Required

Configuring an NQA test group

Configuring ICMP echo tests

Required

Use any of the approaches

Configuring DHCP tests

Configuring DNS tests

Configuring FTP tests

Configuring HTTP tests

Configuring UDP jitter tests

Configuring SNMP tests

Configuring TCP tests

Configuring UDP echo tests

Configuring voice tests

Configuring DLSw tests

Configuring the collaboration function

Optional

Configuring threshold monitoring

Optional

Configuring the NQA statistics collection function

Optional

Configuring the history records saving function

Optional

Configuring optional parameters for an NQA test group

Optional

Scheduling an NQA test group

Required

 

Configuring the NQA server

To perform TCP, UDP echo, UDP jitter, or voice tests, configure the NQA server on the peer device. The NQA server responses to the probe packets sent from the NQA client by listening to the specified destination address and port number.

To configure the NQA server:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable the NQA server.

nqa server enable

Disabled by default.

3.      Configure the listening service.

nqa server { tcp-connect | udp-echo } ip-address port-number

The destination IP address and port number must be the same as those configured on the NQA client. A listening service must be unique on the NQA server.

 

Enabling the NQA client

Configurations on the NQA client take effect only when the NQA client is enabled.

To enable the NQA client:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enable the NQA client.

nqa agent enable

Optional

Enabled by default

 

Creating an NQA test group

Create an NQA test group before you configure NQA tests.

To create an NQA test group:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

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

nqa entry admin-name operation-tag

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

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

 

Configuring an NQA test group

Configuring ICMP echo tests

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

To configure ICMP echo tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as ICMP echo and enter test type view.

type icmp-echo

N/A

4.      Configure the destination address of ICMP echo requests.

destination ip ip-address

By default, no destination IP address is configured.

5.      Configure the size of the data field in each ICMP echo request.

data-size size

Optional.

100 bytes by default.

6.      Configure the string to be filled in the data field of each ICMP echo request.

data-fill string

Optional.

By default, the string is the hexadecimal number 00010203040506070809.

7.      Apply ICMP echo tests to the specified VPN.

vpn-instance vpn-instance-name

Optional.

By default, ICMP echo tests apply to the public network.

8.      Configure the source interface for ICMP echo requests.

source interface interface-type interface-number

Optional.

By default, no source interface is configured for probe packets.

The requests take the IP address of the source interface as their source IP address when no source IP address is specified.

The specified source interface must be a Layer 2 Ethernet interface or a VLAN interface and the interface must be up; otherwise, no ICMP echo requests can be sent out.

9.      Configure the source IP address of ICMP echo requests.

source ip ip-address

Optional.

By default, no source IP address is configured.

If you configure both the source ip command and the source interface command, the source ip command takes effect.

The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no ICMP echo requests can be sent out.

10.   Configure the next hop IP address of ICMP echo requests.

next-hop ip-address

Optional.

By default, no next hop IP address is configured.

11.   Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

 

NOTE:

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

 

Configuring DHCP tests

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

Configuration prerequisites

Before you start DHCP tests, configure the DHCP server. If the NQA (DHCP client) and the DHCP server are not in the same network segment, configure a DHCP relay. For the configuration of DHCP server and DHCP relay, see Layer 3IP Services Configuration Guide.

Configuring DHCP tests

To configure DHCP tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as DHCP and enter test type view.

type dhcp

N/A

4.      Specify an interface to perform DHCP tests.

operation interface interface-type interface-number

By default, no interface is configured to perform DHCP tests.

The specified interface must be up; otherwise, no probe packets can be sent out.

5.      Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

 

NOTE:

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

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

 

Configuring DNS tests

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

Configuration prerequisites

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

Configuring DNS tests

To configure DNS tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as DNS and enter test type view.

type dns

N/A

4.      Specify the IP address of the DNS server as the destination address of DNS packets.

destination ip ip-address

By default, no destination IP address is configured.

5.      Configure the domain name that needs to be translated.

resolve-target domain-name

By default, no domain name is configured.

6.      Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

 

NOTE:

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

 

Configuring FTP tests

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

Configuration prerequisites

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

Configuring FTP tests

To configure FTP tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as FTP and enter test type view.

type ftp

N/A

4.      Specify the IP address of the FTP server as the destination address of FTP request packets.

destination ip ip-address

By default, no destination IP address is configured.

5.      Configure the source IP address of FTP request packets.

source ip ip-address

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no FTP requests can be sent out.

6.      Configure the operation type.

operation { get | put }

Optional.

By default, the operation type for the FTP is get, which means obtaining files from the FTP server.

7.      Configure a login username.

username name

By default, no login username is configured.

8.      Configure a login password.

password password

By default, no login password is configured.

9.      Specify a file to be transferred between the FTP server and the FTP client.

filename file-name

By default, no file is specified.

10.   Set the data transmission mode for FTP tests.

mode { active | passive }

Optional.

active by default.

11.   Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

 

NOTE:

·       When you execute the put command, a file file-name with fixed size and content is created on the FTP server. When you execute the get command, the device does not save the files obtained from the FTP server.

·       When you download a file that does not exist on the FTP server, FTP tests fail.

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

 

Configuring HTTP tests

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

Configuration prerequisites

Before you start HTTP tests, configure the HTTP server.

Configuring HTTP tests

To configure HTTP tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as HTTP and enter test type view.

type http

N/A

4.      Configure the IP address of the HTTP server as the destination address of HTTP request packets.

destination ip ip-address

By default, no destination IP address is configured.

5.      Configure the source IP address of request packets.

source ip ip-address

Optional.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.

6.      Configure the operation type.

operation { get | post }

Optional.

By default, the operation type for the HTTP is get, which means obtaining data from the HTTP server.

7.      Configure the website that an HTTP test visits.

url url

N/A

8.      Configure the HTTP version used in HTTP tests.

http-version v1.0

Optional.

By default, HTTP 1.0 is used.

9.      Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

 

NOTE:

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

 

Configuring UDP jitter tests

 

 

NOTE:

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

 

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

A UDP jitter test takes the following procedure:

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

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

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

Configuration prerequisites

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

Configuring UDP jitter tests

To configure UDP jitter tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as UDP jitter and enter test type view.

type udp-jitter

N/A

4.      Configure the destination address of UDP packets.

destination ip ip-address

By default, no destination IP address is configured.

The destination IP address must be the same as that of the listening service on the NQA server.

5.      Configure the destination port of UDP packets.

destination port port-number

By default, no destination port number is configured.

The destination port must be the same as that of the listening service on the NQA server.

6.      Specify the source port number of UDP packets.

source port port-number

Optional.

By default, no source port number is specified.

7.      Configure the size of the data field in each UDP packet.

data-size size

Optional.

100 bytes by default.

8.      Configure the string to be filled in the data field of each probe packet.

data-fill string

Optional.

By default, the string is the hexadecimal number 00010203040506070809.

9.      Configure the number of probe packets to be sent during each UDP jitter probe operation.

probe packet-number

packet-number

Optional.

10 by default.

10.   Configure the interval for sending probe packets during each UDP jitter probe operation.

probe packet-interval packet-interval

Optional.

20 milliseconds by default.

11.   Configure the interval the NQA client must wait for a response from the server before it regards the response is timed out.

probe packet-timeout packet-timeout

Optional.

3000 milliseconds by default.

12.   Configure the source IP address for UDP jitter packets.

source ip ip-address

Optional.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.

13.   Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

 

NOTE:

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

 

Configuring SNMP tests

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

Configuration prerequisites

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

Configuring SNMP tests

To configure SNMP tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as SNMP and enter test type view.

type snmp

N/A

4.      Configure the destination address of SNMP packets.

destination ip ip-address

By default, no destination IP address is configured.

5.      Specify the source port of SNMP packets.

source port port-number

Optional.

By default, no source port number is specified.

6.      Configure the source IP address of SNMP packets.

source ip ip-address

Optional.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.

7.      Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

Configuring TCP tests

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

Configuration prerequisites

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

Configuring TCP tests

To configure TCP tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as TCP and enter test type view.

type tcp

N/A

4.      Configure the destination address of TCP probe packets.

destination ip ip-address

By default, no destination IP address is configured.

The destination address must be the same as the IP address of the listening service configured on the NQA server.

5.      Configure the destination port of TCP probe packets.

destination port port-number

By default, no destination port number is configured.

The destination port number must be the same as that of the listening service on the NQA server.

6.      Configure the source IP address of TCP probe packets.

source ip ip-address

Optional.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.

7.      Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

Configuring UDP echo tests

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

Configuration prerequisites

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

Configuring UDP echo tests

To configure UDP echo tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as UDP echo and enter test type view.

type udp-echo

N/A

4.      Configure the destination address of UDP packets.

destination ip ip-address

By default, no destination IP address is configured.

The destination address must be the same as the IP address of the listening service configured on the NQA server.

5.      Configure the destination port of UDP packets.

destination port port-number

By default, no destination port number is configured.

The destination port number must be the same as that of the listening service on the NQA server.

6.      Configure the size of the data field in each UDP packet.

data-size size

Optional.

100 bytes by default.

7.      Configure the string to be filled in the data field of each UDP packet.

data-fill string

Optional.

By default, the string is the hexadecimal number 00010203040506070809.

8.      Specify the source port of UDP packets.

source port port-number

Optional.

By default, no source port number is specified.

9.      Configure the source IP address of UDP packets.

source ip ip-address

Optional.

By default, no source IP address is specified.

The source IP address must be that of an interface on the device and the interface must be up; otherwise, no probe packets can be sent out.

10.   Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

Configuring voice tests

 

 

NOTE:

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

 

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

A voice test takes the following procedure:

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

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

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

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

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

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

The evaluation of voice quality depends on users’ tolerance for voice quality, which should be taken into consideration. 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, this advantage factor is subtracted to modify ICPIF and MOS values and both the objective and subjective factors are considered when you evaluate the voice quality.

Configuration prerequisites

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

Configuring voice tests

To configure voice tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as voice and enter test type view.

type voice

N/A

4.      Configure the destination address of voice probe packets.

destination ip ip-address

By default, no destination IP address is configured for a test operation.

The destination IP address must be the same as that of the listening service on the NQA server.

5.      Configure the destination port of voice probe packets.

destination port port-number

By default, no destination port number is configured.

The destination port must be the same as that of the listening service on the NQA server.

6.      Configure the codec type.

codec-type { g711a | g711u | g729a }

Optional.

By default, the codec type is G.711 A-law.

7.      Configure the advantage factor for calculating MOS and ICPIF values.

advantage-factor factor

Optional.

By default, the advantage factor is 0.

8.      Specify the source IP address of probe packets.

source ip ip-address

Optional.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.

9.      Specify the source port number of probe packets.

source port port-number

Optional.

By default, no source port number is specified.

10.   Configure the size of the data field in each probe packet.

data-size size

Optional.

By default, the probe packet size depends on the codec type. The default packet size is 172 bytes for G.711A-law and G.711 µ-law codec type, and is 32 bytes for G.729 A-law codec type.

11.   Configure the string to be filled in the data field of each probe packet.

data-fill string

Optional.

By default, the string is the hexadecimal number 00010203040506070809.

12.   Configure the number of probe packets to be sent during each voice probe operation.

probe packet-number

packet-number

Optional.

1000 by default.

13.   Configure the interval for sending probe packets during each voice probe operation.

probe packet-interval packet-interval

Optional.

20 milliseconds by default.

14.   Configure the interval the NQA client must wait for a response from the server before it regards the response times out.

probe packet-timeout packet-timeout

Optional.

5000 milliseconds by default.

15.   Configure optional parameters.

See “Configuring optional parameters for an NQA test group

Optional.

 

 

NOTE:

Only one probe operation is performed in one voice test.

 

Configuring DLSw tests

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

Configuration prerequisites

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

Configuring a DLSw test

To configure DLSw tests:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Configure the test type as DLSw and enter test type view.

type dlsw

N/A

4.      Configure the destination address of probe packets.

destination ip ip-address

By default, no destination IP address is configured.

5.      Configure the source IP address of probe packets.

source ip ip-address

Optional.

By default, no source IP address is specified.

The source IP address must be the IP address of a local interface. The local interface must be up; otherwise, no probe packets can be sent out.

6.      Configure optional parameters.

See Configuring optional parameters for an NQA test group

Optional.

 

Configuring the collaboration function

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

To configure the collaboration function:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Enter test type view of the test group.

type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo }

The collaboration function is not supported in UDP jitter and voice tests.

4.      Configure a reaction entry.

reaction item-number checked-element probe-fail threshold-type consecutive consecutive-occurrences action-type trigger-only

Not created by default.

You cannot modify the content of an existing reaction entry.

5.      Exit to system view.

quit

N/A

6.      Configure a track entry and associate it with the reaction entry of the NQA test group.

track entry-number nqa entry admin-name operation-tag reaction item-number

Not created by default.

 

Configuring threshold monitoring

Configuration prerequisites

Before you configure threshold monitoring, complete the following tasks:

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

·           Create an NQA test group and configure related parameters.

Configuring threshold monitoring

To configure threshold monitoring:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Enter test type view of the test group.

type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo | udp-jitter | voice }

N/A

4.      Configure to send traps to the network management server under specified conditions.

reaction trap { probe-failure consecutive-probe-failures | test-complete | test-failure cumulate-probe-failures }

Configure to send traps.

No traps are sent to the network management server by default.

5.      Configure a reaction entry for monitoring the probe duration of a test (not supported in UDP jitter and voice tests).

reaction item-number checked-element probe-duration threshold-type { accumulate accumulate-occurrences | average | consecutive consecutive-occurrences } threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

6.      Configure a reaction entry for monitoring the probe failure times (not supported in UDP jitter and voice tests).

reaction item-number checked-element probe-fail threshold-type { accumulate accumulate-occurrences | consecutive consecutive-occurrences } [ action-type { none | trap-only } ]

7.      Configure a reaction entry for monitoring packet round-trip time (only supported in UDP jitter and voice tests)

reaction item-number checked-element rtt threshold-type { accumulate accumulate-occurrences | average } threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

8.      Configure a reaction entry for monitoring the packet loss in each test (only supported in UDP jitter and voice tests).

reaction item-number checked-element packet-loss threshold-type accumulate accumulate-occurrences [ action-type { none | trap-only } ]

9.      Configure a reaction entry for monitoring one-way delay jitter (only supported in UDP jitter and voice tests).

reaction item-number checked-element { jitter-ds | jitter-sd } threshold-type { accumulate accumulate-occurrences | average } threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

10.   Configure a reaction entry for monitoring the one-way delay (only supported in UDP jitter and voice tests).

reaction item-number checked-element { owd-ds | owd-sd } threshold-value upper-threshold lower-threshold

11.   Configure a reaction entry for monitoring the ICPIF value (only supported in voice tests).

reaction item-number checked-element icpif threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

12.   Configure a reaction entry for monitoring the MOS value (only supported in voice tests).

reaction item-number checked-element mos threshold-value upper-threshold lower-threshold [ action-type { none | trap-only } ]

 

 

NOTE:

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

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

 

Configuring the NQA statistics collection function

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

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

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

To configure the NQA statistics collection function:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Enter test type view of the test group.

type { dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo | udp-jitter | voice }

N/A

4.      Configure the interval for collecting the statistics of test results.

statistics interval interval

Optional.

60 minutes by default.

5.      Configure the maximum number of statistics groups that can be kept.

statistics max-group number

Optional.

2 by default.

To disable collecting NQA statistics, set the maximum number to 0.

6.      Configure the hold time of statistics groups.

statistics hold-time hold-time

Optional.

120 minutes by default.

 

 

 

NOTE:

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

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

 

Configuring the history records saving function

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

In addition, you can configure the following elements:

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

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

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

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Enter NQA test type view.

type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo | udp-jitter | voice }

N/A

4.      Enable the saving of the history records of the NQA test group.

history-record enable

By default, history records of the NQA test group are not saved.

5.      Set the lifetime of the history records in an NQA test group.

history-record keep-time keep-time

Optional.

By default, the history records in the NQA test group are kept for 120 minutes.

6.      Configure the maximum number of history records that can be saved for a test group.

history-record number number

Optional.

By default, the maximum number of records that can be saved for a test group is 50

 

Configuring optional parameters for an NQA test group

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

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

To configure optional parameters for an NQA test group:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Enter NQA test group view.

nqa entry admin-name operation-tag

N/A

3.      Enter test type view of a test group.

type { dhcp | dlsw | dns | ftp | http | icmp-echo | snmp | tcp | udp-echo | udp-jitter | voice }

N/A

4.      Configure the description for a test group.

description text

Optional.

By default, no description is available for a test group.

5.      Configure the interval between two consecutive tests for a test group.

frequency interval

Optional.

By default, the interval between two consecutive tests for a test group is 0 milliseconds. Only one test is performed.

If the last test is not completed when the interval specified by the frequency command is reached, a new test does not start.

6.      Configure the number of probe operations to be performed in one test.

probe count times

Optional.

By default, one probe operation is performed in one test.

Not available for voice tests, Only one probe operation can be performed in one voice test.

7.      Configure the NQA probe timeout time.

probe timeout timeout

Optional.

By default, the timeout time is 3000 milliseconds.

Not available for UDP jitter tests.

8.      Configure the maximum number of hops a probe packet traverses in the network.

ttl value

Optional.

20 by default.

Not available for DHCP tests.

9.      Configure the ToS field in an IP packet header in an NQA probe packet.

tos value

Optional.

0 by default.

Not available for DHCP tests.

10.   Enable the routing table bypass function.

route-option bypass-route

Optional.

Disabled by default.

Not available for DHCP tests.

 

Scheduling an NQA test group

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

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

Configuration prerequisites

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

·           Configure test parameters required for the test type.

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

Scheduling an NQA test group

To schedule an NQA test group:

 

Step

Command

Remarks

1.      Enter system view.

system-view

N/A

2.      Schedule an NQA test group.

nqa schedule admin-name operation-tag start-time { hh:mm:ss [ yyyy/mm/dd ] | now } lifetime { lifetime | forever }

now specifies the test group starts testing immediately.

forever specifies that the tests do not stop unless you use the undo nqa schedule command.

3.      Configure the maximum number of tests that the NQA client can simultaneously perform.

nqa agent max-concurrent number

Optional.

By default, a maximum of 10 tests can be simultaneously performed.

 

 

NOTE:

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

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

 

Displaying and maintaining NQA

 

Task

Command

Remarks

Display history records of NQA test groups.

display nqa history [ admin-name operation-tag ] [ | { begin | exclude | include } regular-expression ]

Available in any view

Display the current monitoring results of reaction entries.

display nqa reaction counters [ admin-name operation-tag [ item-number ] ] [ | { begin | exclude | include } regular-expression ]

Display the results of the last NQA test.

display nqa result [ admin-name operation-tag ] [ | { begin | exclude | include } regular-expression ]

Display statistics of test results for the specified or all test groups.

display nqa statistics [ admin-name operation-tag ] [ | { begin | exclude | include } regular-expression ]

Display NQA server status.

display nqa server status [ | { begin | exclude | include } regular-expression ]

 

NQA configuration examples

ICMP echo test configuration example

Network requirements

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

Figure 3 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

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

<DeviceA> system-view

[DeviceA] nqa entry admin test

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

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

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

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

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

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

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

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

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

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

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

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

# Start ICMP echo tests.

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

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

[DeviceA] undo nqa schedule admin test

# Display the results of the last ICMP echo test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 10             Receive response times: 10

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

      Square-Sum of round trip time: 96

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

# Display the history of ICMP echo tests.

[DeviceA] display nqa history admin test

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

    Index      Response     Status           Time

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

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

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

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

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

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

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

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

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

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

DHCP test configuration example

Network requirements

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

Figure 4 Network diagram

 

Configuration procedure

# Create a DHCP test group and specify interface GigabitEthernet 3/1/1 to perform NQA DHCP tests.

<RouterA> system-view

[RouterA] nqa entry admin test

[RouterA-nqa-admin-test] type dhcp

[RouterA-nqa-admin-test-dhcp] operation interface GigabitEthernet 3/1/1

# Enable the saving of history records.

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

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

# Start DHCP tests.

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

# Stop DHCP tests after a period of time.

[RouterA] undo nqa schedule admin test

# Display the results of the last DHCP test.

[RouterA] display nqa result admin test

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

      Send operation times: 1              Receive response times: 1

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

      Square-Sum of round trip time: 262144

      Last succeeded probe time: 2007-11-22 09:54:03.8

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

# Display the history of DHCP tests.

[RouterA] display nqa history admin test

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

    Index      Response     Status           Time

    1          512          Succeeded        2007-11-22 09:54:03.8

DNS test configuration example

Network requirements

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

Figure 5 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

# Create a DNS test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type dns

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

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

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

# Enable the saving of history records.

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

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

# Start DNS tests.

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

# Stop the DNS tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last DNS test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 1              Receive response times: 1

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

      Square-Sum of round trip time: 3844

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

# Display the history of DNS tests.

[DeviceA] display nqa history admin test

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

    Index      Response     Status           Time

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

FTP test configuration example

Network requirements

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

Figure 6 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

# Create an FTP test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type ftp

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

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

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

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

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

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

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

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

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

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

# Enable the saving of history records.

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

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

# Start FTP tests.

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

# Stop the FTP tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last FTP test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 1              Receive response times: 1

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

      Square-Sum of round trip time: 29929

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

# Display the history of FTP tests.

[DeviceA] display nqa history admin test

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

    Index      Response     Status           Time

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

HTTP test configuration example

Network requirements

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

Figure 7 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

# Create an HTTP test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type http

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

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

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

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

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

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

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

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

# Enable the saving of history records.

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

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

# Start HTTP tests.

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

# Stop HTTP tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display results of the last HTTP test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 1              Receive response times: 1

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

      Square-Sum of round trip time: 4096

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors:

      Packet(s) arrived late: 0

# Display the history of HTTP tests.

[DeviceA] display nqa history admin test

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

    Index      Response     Status           Time

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

UDP jitter test configuration example

Network requirements

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

Figure 8 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

1.       Configure Device B:

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

<DeviceB> system-view

[DeviceB] nqa server enable

[DeviceB] nqa server udp-echo 10.2.2.2 9000

2.       Configure Device A:

# Create a UDP jitter test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

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

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

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

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

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

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

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

# Start UDP jitter tests.

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

# Stop UDP jitter tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last UDP jitter test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 10             Receive response times: 10

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

      Square-Sum of round trip time: 3235

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

    UDP-jitter results:

     RTT number: 10

      Min positive SD: 4                     Min positive DS: 1

      Max positive SD: 21                    Max positive DS: 28

      Positive SD number: 5                  Positive DS number: 4

      Positive SD sum: 52                    Positive DS sum: 38

      Positive SD average: 10                Positive DS average: 10

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

      Min negative SD: 1                     Min negative DS: 6

      Max negative SD: 13                    Max negative DS: 22

      Negative SD number: 4                  Negative DS number: 5

      Negative SD sum: 38                    Negative DS sum: 52

      Negative SD average: 10                Negative DS average: 10

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

    One way results:

      Max SD delay: 15                       Max DS delay: 16

      Min SD delay: 7                        Min DS delay: 7

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

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

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

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

      Lost packet(s) for unknown reason: 0

# Display the statistics of UDP jitter tests.

[DeviceA] display nqa statistics admin test

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

    NO. : 1

    Destination IP address: 10.2.2.2

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

      Life time: 47 seconds

      Send operation times: 410            Receive response times: 410

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

      Square-Sum of round trip time: 206176

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

    UDP-jitter results:

     RTT number: 410

      Min positive SD: 3                     Min positive DS: 1

      Max positive SD: 30                    Max positive DS: 79

      Positive SD number: 186                Positive DS number: 158

      Positive SD sum: 2602                  Positive DS sum: 1928

      Positive SD average: 13                Positive DS average: 12

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

      Min negative SD: 1                     Min negative DS: 1

      Max negative SD: 30                    Max negative DS: 78

      Negative SD number: 181                Negative DS number: 209

      Negative SD sum: 181                   Negative DS sum: 209

      Negative SD average: 13                Negative DS average: 14

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

    One way results:

      Max SD delay: 46                       Max DS delay: 46

      Min SD delay: 7                        Min DS delay: 7

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

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

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

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

      Lost packet(s) for unknown reason: 0

 

 

NOTE:

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

 

SNMP test configuration example

Network requirements

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

Figure 9 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

1.       Configurations on SNMP agent (Device B):

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

<DeviceB> system-view

[DeviceB] snmp-agent sys-info version all

[DeviceB] snmp-agent community read public

[DeviceB] snmp-agent community write private

2.       Configurations on Device A:

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

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type snmp

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

# Enable the saving of history records.

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

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

# Start SNMP tests.

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

# Stop the SNMP tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last SNMP test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 1              Receive response times: 1

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

      Square-Sum of round trip time: 2500

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

# Display the history of SNMP tests.

[DeviceA] display nqa history admin test

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

    Index      Response     Status           Time

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

TCP test configuration example

Network requirements

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

Figure 10 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

1.       Configure Device B:

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

<DeviceB> system-view

[DeviceB] nqa server enable

[DeviceB] nqa server tcp-connect 10.2.2.2 9000

2.       Configure Device A:

# Create a TCP test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type tcp

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

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

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

# Enable the saving of history records.

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

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

# Start TCP tests.

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

# Stop the TCP tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last TCP test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 1              Receive response times: 1

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

      Square-Sum of round trip time: 169

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

# Display the history of TCP tests.

[DeviceA] display nqa history admin test

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

Index      Response     Status           Time

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

UDP echo test configuration example

Network requirements

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

Figure 11 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

1.       Configure Device B:

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

<DeviceB> system-view

[DeviceB] nqa server enable

[DeviceB] nqa server udp-echo 10.2.2.2 8000

2.       Configure Device A:

# Create a UDP echo test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

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

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

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

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

# Enable the saving of history records.

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

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

# Start UDP echo tests.

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

# Stop UDP echo tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the results of the last UDP echo test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 1              Receive response times: 1

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

      Square-Sum of round trip time: 625

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

# Display the history of UDP echo tests.

[DeviceA] display nqa history admin test

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

    Index      Response     Status           Time

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

Voice test configuration example

Network requirements

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

Figure 12 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

1.       Configure Device B:

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

<DeviceB> system-view

[DeviceB] nqa server enable

[DeviceB] nqa server udp-echo 10.2.2.2 9000

2.       Configure Device A:

# Create a voice test group.

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type voice

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

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

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

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

# Start voice tests.

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

# Stop the voice tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last voice test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 1000           Receive response times: 1000

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

      Square-Sum of round trip time: 2844813

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

    Voice results:

     RTT number: 1000

      Min positive SD: 1                     Min positive DS: 1

      Max positive SD: 204                   Max positive DS: 1297

      Positive SD number: 257                Positive DS number: 259

      Positive SD sum: 759                   Positive DS sum: 1797

      Positive SD average: 2                 Positive DS average: 6

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

      Min negative SD: 1                     Min negative DS: 1

      Max negative SD: 203                   Max negative DS: 1297

      Negative SD number: 255                Negative DS number: 259

      Negative SD sum: 759                   Negative DS sum: 1796

      Negative SD average: 2                 Negative DS average: 6

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

    One way results:

      Max SD delay: 343                      Max DS delay: 985

      Min SD delay: 343                      Min DS delay: 985

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

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

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

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

      Lost packet(s) for unknown reason: 0

    Voice scores:

      MOS value: 4.38                        ICPIF value: 0

# Display the statistics of voice tests.

[DeviceA] display nqa statistics admin test

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

    NO. : 1

    Destination IP address: 10.2.2.2

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

      Life time: 331 seconds

      Send operation times: 4000           Receive response times: 4000

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

      Square-Sum of round trip time: 7160528

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

    Voice results:

     RTT number: 4000

      Min positive SD: 1                     Min positive DS: 1

      Max positive SD: 360                   Max positive DS: 1297

      Positive SD number: 1030               Positive DS number: 1024

      Positive SD sum: 4363                  Positive DS sum: 5423

      Positive SD average: 4                 Positive DS average: 5

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

      Min negative SD: 1                     Min negative DS: 1

      Max negative SD: 360                   Max negative DS: 1297

      Negative SD number: 1028               Negative DS number: 1022

      Negative SD sum: 1028                  Negative DS sum: 1022

      Negative SD average: 4                 Negative DS average: 5

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

    One way results:

      Max SD delay: 359                      Max DS delay: 985

      Min SD delay: 0                        Min DS delay: 0

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

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

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

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

      Lost packet(s) for unknown reason: 0

    Voice scores:

      Max MOS value: 4.38                    Min MOS value: 4.38

      Max ICPIF value: 0                     Min ICPIF value: 0

 

 

NOTE:

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

 

DLSw test configuration example

Network requirements

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

Figure 13 Network diagram

 

Configuration procedure

 

 

NOTE:

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

 

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

<DeviceA> system-view

[DeviceA] nqa entry admin test

[DeviceA-nqa-admin-test] type dlsw

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

# Enable the saving of history records.

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

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

# Start DLSw tests.

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

# Stop the DLSw tests after a period of time.

[DeviceA] undo nqa schedule admin test

# Display the result of the last DLSw test.

[DeviceA] display nqa result admin test

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

    Destination IP address: 10.2.2.2

      Send operation times: 1              Receive response times: 1

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

      Square-Sum of round trip time: 361

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

    Extended results:

      Packet loss in test: 0%

      Failures due to timeout: 0

      Failures due to disconnect: 0

      Failures due to no connection: 0

      Failures due to sequence error: 0

      Failures due to internal error: 0

      Failures due to other errors: 0

      Packet(s) arrived late: 0

# Display the history of DLSw tests.

[DeviceA] display nqa history admin test

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

    Index      Response     Status           Time

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

NQA collaboration configuration example

Network requirements

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

Figure 14 Network diagram

 

Configuration procedure

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

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

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

<RouterA> system-view

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

3.       On Router A, create an NQA test group:

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

[RouterA] nqa entry admin test

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

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

# Configure ICMP echo requests to use 10.2.2.1 as the destination IP address.

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

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

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

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

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

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

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

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

4.       On Router A, create the track entry:

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

[RouterA] track 1 nqa entry admin test reaction 1

Verifying the configuration

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

[RouterA] display track all

Track ID: 1

  Status: Positive

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

  Reference object:

    NQA entry: admin test

    Reaction: 1

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

[RouterA] display ip routing-table

Routing Tables: Public

         Destinations : 5        Routes : 5

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

 

10.1.1.0/24         Static 60   0            10.2.1.1        GE3/1/1

10.2.1.0/24         Direct 0    0            10.2.1.2        GE3/1/1

10.2.1.2/32         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

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

# Remove the IP address of GigabitEthernet 3/1/1 on Router B.

<RouterB> system-view

[RouterB] interface GigabitEthernet 3/1/1

[RouterB- GigabitEthernet3/1/1] undo ip address

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

[RouterA] display track all

Track ID: 1

  Status: Negative

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

  Reference object:

    NQA entry: admin test

    Reaction: 1

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

[RouterA] display ip routing-table

Routing Tables: Public

         Destinations : 4        Routes : 4

 

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

 

10.2.1.0/24         Direct 0    0            10.2.1.2        GE3/1/1

10.2.1.2/32         Direct 0    0            127.0.0.1       InLoop0

127.0.0.0/8         Direct 0    0            127.0.0.1       InLoop0

127.0.0.1/32        Direct 0    0            127.0.0.1       InLoop0

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

 

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become a Partner
  • Partner Resources
  • Partner Business Management
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网