Common Errors - N2N

Errors Received for Node-to-Node and Mesh Tests

If you encounter problems while running node-to-node and mesh tests, they're probably related to failed connections, to the communications software in your network, or to the way you've configured your tests. Hawkeye messages offer information to help you understand why errors occur and guidance to help you avoid them in the future.

The following topics will help you find the information necessary to solve problems you encounter.

Investigate which Probe Detected the Error

The first step in troubleshooting is usually determining which probe detected the error. All Operator Actions described by the message help should be taken at the computer that detected the error, unless otherwise specified.

For most errors involving setup and file manipulation, the Test Agent is the computer that detects the error.

For errors that occur while running a test, the error could have been detected on a particular endpoint pair by the Test Agent, by Endpoint 1, or by Endpoint 2. The program that detects the error reports to the Test Agent, which shows the error and logs it. The first line of the Test Agent error message tells which endpoint probe detected the error.

If for some reason you cannot see the error at the Test Agent, examine the error log at the endpoints involved in the problem. A formatted error log entry should contain a line that resembles the following:

Some pairs in tests did not complete.

One of the following reasons explains the situation:

• Hawkeye test engine started the test but had to abandon at result collection

• Your test generates too much traffic on the link and the first result collection is never happening as result collection intervals depend on requested traffic : this would result into Hawkeye timing out test execution.

  => Solution: Start a test with low traffic between endpoints.

• Check firewall NAT rules between endpoints : this can be test path not opened on ports, can be E2 unable to reach E1 on port 10115 (you need that for the tests).

  => Solution: open relevant ports. Force user traffic to use specific port from Hawkeye (preferences, test agent tab)

• Endpoint process in bad state : this happens sometimes on linux when there was a problem with a test.

  Solution=> Restart the endpoint process on the probes (/etc/init.d/endpoint stop; /etc/init.d/endpoint stop). For hardware probes you can do that from the probe management / probe remote management menu of Hawkeye. There is also an automatic endpoint cleanup process that would do that every hour per default.  A hard reboot on the probe also does the job.

• Hawkeye test engine gets stuck at test initialization stage.

• Port 10115 udp must be opened both ways between probes for sync.
• Endpoint process in bad state: same solution than above.

Error was detected by Endpoint 1

If the error was detected by Endpoint 1 or Endpoint 2, check the test setup at the Test Agent to determine the actual network address of the probe where the error was detected.

Although one probe may detect an error, the solution may actually lie elsewhere. For example, if Endpoint 1 detects an error indicating that a network connection could not be established, it may be because of a configuration error in the middle of the network at Endpoint 2, or between Endpoint 1 and Endpoint 2.

Reading Error Messages

Hawkeye errors are reported in the GUI in the “Reason cause” column of the “Test results list” table. Below is an example of error received when one of the test ports was used by another application:

• The first line of the error message shows the timestamp when the error was detected and received;
• The next lines tell you which endpoint detected the error, the error number and error explanation together with other error details.

Below, is an explanation of the error codes received in Hawkeye, when running node-to-node or mesh tests:

Code	Type	Reason
CHR0200	Error	Connection attempt timed out
CHR0204	Error	No endpoint program is installed on partner computer/probe.
CHR0206	Error	Cannot complete scripts because the assigned port is already in use.
CHR0225	Error	The TCP address is unreachable- the endpoint or phone is unavailable. Check  connectivity to the endpoint.
CHR0264	Error	RUNTST cannot run while the Test Agent is loaded. The RUNTST program is installed at the Test Agent in the \Ixia\Hawkeyegram folder.
CHR0335	Warning	A timing record was received with a measured time of 0 milliseconds. A script command was performed in less than one millisecond, an insignificannot amount of time.
CHR0336	Warning	A timing record was received with a measured time between 1 and 20 milliseconds. The clock timers used in timing scripts are generally accurate to within 1 millisecond (ms). For most tests, this is more than sufficient, but if the transactions in a test are too short, problems may arise.
CHR0337	Warning	More than 500 timing records per pair were generated in Batch Reporting Mode. Excessive timing records create extra traffic on the line and interfere with performance results.
CHR0338	Warning	The test has run for less than 1 second while collecting endpoint CPU utilization. Meaningful data on CPU utilization at the endpoints cannot be collected unless the test runs for a longer period of time.

Common Problems

High-Precision Timer (CHR0359 error)

If you attempt to execute a VoIP or streaming pair test and you receive a CHR0359 error message (An error was detected in the high precision timer), you may be able to resolve the issue by following the instructions given in the Microsoft Knowledge Base article entitled "Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP". You can either search for the article by name or reference it at this address: http://support.microsoft.com/kb/895980.

Insufficient Resources

If you receive an Insufficient Resource error while running node-to-node/mesh tests, the test agent computer does not have access to the amount of memory required to successfully run these tests. Close other applications that currently run and restart the tests.

Insufficient Threads

The Hawkeye Test Agent creates one or more threads for each endpoint pair when running a test. This is in addition to the threads created by the underlying network software (as well as those used by other concurrently-running applications).

In our testing, we did not exhaust threads in our default settings for Windows NT or Windows 2000/2003 until we reached about 7000 threads. We don't believe you'll encounter out-of-threads problems, but please let us know if you do.

Protection Faults and Traps

Protection faults or traps are the operating system's way of telling you when a program is trying to use memory that it doesn't own. They can occur in an Hawkeyegram, in any library routines called by Hawkeye, or in the operating system itself. The default way that they're handled is with a message box. This message box shows program instruction values in hex, which aren't helpful to you as a user.

• If you are using Windows NT, Windows 2000/2003, or Windows XP:

Windows NT, Windows 2000/2003, and Windows XP write an entry to a file named drwtsn32.log when they encounter a trap or protection fault. This file is written to the directory where you installed Windows. Its default location is c:\Winnt. It contains information that is immensely helpful to us in finding and fixing bugs. When you contact the Technical Support team, they may suggest that you send the Dr. Watson file to us via email.