|
HP OpenVMS Systems Documentation |
|
Compaq TCP/IP Services for OpenVMSTuning and TroubleshootingOrder Number: AA--RN1VA--TE
January 2001
This manual describes how to troubleshoot Compaq TCP/IP Services for OpenVMS and how to tune the performance of the product. Revision Information: This is a new manual. Operating System: OpenVMS Alpha Versions 7.1 and 7.2-1 OpenVMS VAX Versions 7.1 and 7.2 Software Version: Compaq TCP/IP Services for OpenVMS Version 5.1
© 2001 Compaq Computer Corporation COMPAQ, VAX, VMS, and the Compaq logo Registered in U.S. Patent and Trademark Office. OpenVMS and Tru64 are trademarks of Compaq Information Technologies Group, L.P. in the United States and other countries. UNIX is a trademark of The Open Group. All other product names mentioned herein may be trademarks of their respective companies. Confidential computer software. Valid license from Compaq required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. Compaq shall not be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for Compaq products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
ZK6631 This document is available on CD-ROM.
PrefaceCompaq TCP/IP Services for OpenVMS is the Compaq implementation of the TCP/IP networking protocol suite and internet services for OpenVMS Alpha and OpenVMS VAX systems. A layered software product, TCP/IP Services provides a comprehensive suite of functions and applications that support industry-standard protocols for heterogeneous network communications and resource sharing. See the Compaq TCP/IP Services for OpenVMS Installation and Configuration manual for information about installing, configuring, and starting this product. This manual provides system and network managers with information they need to identify and resolve problems. This manual is best used in conjunction with the Compaq TCP/IP Services for OpenVMS Management manual. Intended AudienceThis manual is for OpenVMS or UNIX system managers who are experienced in troubleshooting complex software products. This manual assumes a working knowledge of TCP/IP networking, TCP/IP terminology, and familiarity with the TCP/IP Services for OpenVMS product. If you are not familiar with the TCP/IP Services for OpenVMS product, please review all product documentation before attempting to resolve any problems. Document StructureThis manual contains the following two chapters and appendix:
Related DocumentsTable 1 lists the documents available with this version of TCP/IP Services.
For additional information about Compaq OpenVMS products and services, access the Compaq website at the following location:
If you are looking for a comprehensive overview of the TCP/IP protocol suite, you might find the following books useful:
Reader's CommentsCompaq welcomes your comments on this manual. Please send comments to either of the following addresses:
How to Order Additional DocumentationVisit the following World Wide Web address for information about how to order additional documentation:
If you need help deciding which documentation best meets your needs, call 800-282-6672. ConventionsThe name TCP/IP Services means both:
The following conventions are used in this manual. In addition, please note that all IP addresses are fictitious.
Chapter 1
|
$ SHOW DEVICE BG Device Device Error Name Status Count BG0: Mounted 0 BG1: Mounted 0 BG5: Mounted 0 BG6: Mounted 0 BG7: Mounted 0 BG8: Mounted 0 |
If the command output shows only the BG0: device, then the product is stopped.
The second step is to reduce the problem to its basic components and to systematically identify what is and what is not working. Ask the following questions:
The following steps can help you isolate your problem and determine a solution.
Table 1-1 summarizes the tools you use to obtain information about network operations. The following sections describe each tool in detail.
| Diagnostic Tool | Function |
|---|---|
| arp | Controls and displays ARP tables. |
| dig | Sends domain name query packets to name servers. |
| ifconfig | Configures or displays network interface parameters, redefines an address for a particular interface, or sets options such as an alias list, broadcast address, or access filter. Use to detect incorrect IP addresses, subnet masks, and broadcast addresses. |
| ndc | Allows the name server administrator to send messages to a name server to start, stop, and restart BIND; to dump the BIND database; to check the status of the BIND process; and to change the tracing level. |
| netstat | Displays network statistics of sockets, data link counters, specified protocols or aliases, network interfaces, and a host's routing table. |
| nslookup | Provides the ability to directly query a name server and retrieve information. Use NSLOOKUP to determine whether your local name server is running correctly or to retrieve information from remote name servers. |
| ping | Indicates a host is reachable, and displays statistics about packet loss and delivery time. |
| route | Allows the user to manipulate the network routing tables manually. |
| sysconfig | Displays and maintains the various network subsystem attributes. |
| TCPTRACE | Traces packets going in and out of the system. To run the trace utility, enter the DCL command TCPTRACE. |
| traceroute | Displays the route of an IP packet sent from the local host to a remote host. |
To enter a command at the system prompt, execute the SYS$STARTUP:TCPIP$DEFINE_COMMANDS.COM file. This file defines each tool as a foreign command.
See Appendix A for complete reference information about these
diagnostic tools.
1.2.1 Testing Connectivity Between Network Hosts
Use the ping command to test whether you can reach a remote host from your local system. The ping command sends an Internet Control Message Protocol (ICMP) echo request to the specified host name or host address. When received by a host, an ICMP reply is returned to the requester.
When using the ping command to isolate a problem, you should first test the localhost to verify that the system can communicate with itself. For example:
TCPIP> ping localhost PING LOCALHOST (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0 ms ----LOCALHOST PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1 ms TCPIP> TCPIP> ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=1 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0 ms ----127.0.0.1 PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1 ms |
The output from this ping command shows that the system is able to send a message down and then back up the protocol stack through the loopback address. The host address 127.0.0.1 and its associated host name, localhost , are the loopback address of the local host. This address was devised so that software could use common code to address local processes as well as remote processes. If the command output shows that it received a message for every message it transmitted, then you can be sure that the network software is up and running and that your system should able to communicate with remote systems.
If you do not receive output similar to that shown in the example, then one of the following conditions may exist:
If the ping command for localhost does not respond correctly, try the ping command with the IP address 127.0.0.1 . If this command displays correct output, the TCPIP database is missing a definition for localhost .
If localhost returns the data correctly at this point, use the ping command to test another host on the same local network. If you are able to reach this host, then test remote hosts farther and farther away from the local host.
If the remote host does not respond to the request, the ping command displays the following message:
TCPIP> ping a7u1kt ping: unknown host a7u1kt %SYSTEM-F-UNREACHABLE, remote node is not currently reachable |
If you used an IP address in the ping command, the output may be:
TCPIP> ping 10.10.22.1 PING 10.10.22.1 (10.10.22.1): 56 data bytes ----10.10.22.1 PING Statistics---- 4 packets transmitted, 0 packets received, 100% packet loss %SYSTEM-F-TIMEOUT, device timeout |
These error messages could indicate that:
The following sample shows the ping statistics displayed:
TCPIP> ping chester PING chester (16.20.208.53): 56 data bytes 64 bytes from 16.20.208.53: icmp_seq=0 ttl=64 time=0 ms 64 bytes from 16.20.208.53: icmp_seq=1 ttl=64 time=1 ms 64 bytes from 16.20.208.53: icmp_seq=2 ttl=64 time=0 ms 64 bytes from 16.20.208.53: icmp_seq=3 ttl=64 time=1 ms ----chester PING Statistics---- 4 packets transmitted, 4 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/1 ms |
The ping command displays statistics on packets sent; packets received; the percentage of packets lost; and the minimum, average, and maximum round-trip packet times.
If you do not specify command options, the ping command displays the results of each ICMP request in sequence, the number of bytes received from the remote host, and the round-trip time on a per-request basis.
Use the output from the ping command to help determine the cause of direct and indirect routing problems such as host is unreachable, connection timed out, and network is unreachable.
This command helps you decide whether further testing is required and where. For example, if someone reports a problem connecting to a remote host, but ping shows packets traveling to the remote system and back, the problem probably resides in the upper (application) layer protocols (such as FTP, TELNET), or the user introduced the error to the application.
If the packets do not make the round trip, the problem probably resides in the lower layers, and perhaps indicates a misconfigured interface or other configuration or routing problems.
When preliminary testing indicates a problem in the lower layers, the next step is to test the network interfaces and routing. Use the ifconfig , netstat , and arp commands for these purposes (see Appendix A).
| Next | Contents | Index |