[ Previous | Next | Contents | Glossary | Home | Search ]
AIX Version 4.3 System Management Guide: Communications and Networks

TCP/IP Problem Determination

This section contains information about diagnosing common problems in a Transmission Control Protocol/Internet Protocol (TCP/IP) network environment.

The netstat command is a good tool to use to help determine in which area the problem is. Once you have isolated the problem to an area, you can use more sophisticated tools to proceed. For example, you might use the netstat -i and netstat -v to determine if you have a problem with a particular hardware interface, and then run diagnostics to further isolate the problem. Or, if the netstat -s command shows that there are protocol errors, you could then use the trpt or iptrace commands.

The topics discussed in this section are:

Communication Problems

If you cannot communicate with a host on your network:

If the name resolves and you are trying to contact a host on another network, you may have a routing problem. See "Routing Problems" for more information.

Name Resolution Problems

Resolver routines on hosts running TCP/IP attempt to resolve names, using the following sources in the order listed:

  1. DOMAIN name server (named)
  2. Network Information Service (NIS)
  3. Local /etc/hosts file

Client Host

If you cannot get a host name resolved, and you are using flat name resolution (using the /etc/hosts file), verify that the host name and correct Internet Protocol (IP) address information is in the /etc/hosts file.

If you cannot get a host name resolved, and you are using a name server:

  1. Verify that you have a resolv.conf file specifying the domain name and Internet address of a name server.

  2. Verify that the local name server is up by issuing the ping command with the IP address of the name server (found in the local resolv.conf file).

  3. If the local name server is up, verify that the named daemon on your local name server is active by issuing the lssrc -s named command on the name server.

  4. If you are running the syslogd, there could be error messages logged. The output for these messages is defined in the /etc/syslog.conf file.

If these steps do not identify the problem, start looking at the name server host.

Name Server Host

If you cannot get a host name resolved:

  1. Verify that the named daemon is active by issuing the following command:
    lssrc -s named
  2. Verify that the address of the target host exists and is correct in the name server's database. Send a SIGINT signal to the named daemon to dump the database and cache to the file /var/tmp/named_dump.db. Verify that the address you are trying to resolve is there and is correct.

    Add or correct name-to-address resolution information in the named hosts data file for the master name server of the domain. Then issue the following SRC command to reread the data files:

    refresh -s named
  3. Verify that the name resolution requests are being processed. To do this, enter the named daemon from the command line and specify a debugging level. Valid debug levels are 1 through 9. The higher the level, the more information the debug mechanism logs.
    startsrc -s named -a "-d DebugLevel"
  4. Check for configuration problems in the named data files. For more information, see "Configuring Name Servers", the "DOMAIN Data File Format," "DOMAIN Reverse Data File Format," "DOMAIN Cache File Format," and the "DOMAIN Local Data File Format" in the AIX Version 4.3 Files Reference.
    Note: A common error is the incorrect use of the . (period) and the @ (at sign) in the DOMAIN data files.

If external users cannot reach your domains:

If external resolvers query your servers constantly:

Routing Problems

If you cannot reach a destination host, consider the following situations:

Other Possibilities

If all else fails, you may want to turn on tracing for your routing daemon (either routed or gated). Use the SRC traceson command from the command line, or send a signal to the daemon to specify different levels of tracing. See the gated daemon or the routed daemon for specifics on sending signals to these daemons.

Problems with SRC Support

telnet or rlogin Problems

The following explanations may be useful in solving problems with the telnet or rlogin command.

Screen Distortion

If you are having trouble with screen distortion in full-screen applications:

  1. Check the TERM environment variable by issuing one of the following commands:
    env
    OR
    echo $TERM
  2. Verify that the TERM variable is set to a value that matches the type of terminal display you are using.

telnet Debugging

telnet subcommands that may help in debugging problems include:

display Displays set and toggle values.
toggle Toggles the display of all network data in hex.
toggle options Toggles the display of internal telnet process options.

Programs Using Extended Curses

Problems with function and arrow keys may arise when using the rlogin and telnet commands with programs using extended curses. Function and arrow keys generate escape sequences, which are split if too little time is allotted for the entire key sequence. Curses waits a specific amount of time to decide whether an Esc indicates the escape key only or the start of a multibyte escape sequence generated by other keys, such as cursor keys, the action key, and function keys.

If no data, or data that is not valid, follows the Esc in the allotted amount of time, curses decides that the Esc is the escape key, and the key sequence is split. The delay resulting from the rlogin or telnet command is network dependent. Sometimes arrow and function keys work and sometimes they do not, depending on the speed of the network to which you are connecting. Setting the ESCDELAY environment variable to a large value (1000 to 1500) effectively solves this problem.

Configuration Problems

Network interfaces are automatically configured during the first system startup after the adapter card is installed. However, you still need to set some initial values for TCP/IP including the host name, the Internet address, and the subnet mask. To do this, you can use the Web-based System Manager fast path, wsm network, or you can use the SMIT interface in the following ways:

You may also want to set up any static routes the host needs for sending transmitting information, such as a route to the local gateway. Use the Web-based System Manager fast path, wsm network, or the SMIT fast path, smit mkroute, to set these up permanently in the configuration database.

If you are having other problems with your configuration, see the "Configuring a TCP/IP Network Checklist" for more information.

Common Problems with Network Interfaces

Network interfaces are configured automatically during the first system startup after the adapter card is installed. However, there are certain values that must be set in order for TCP/IP to start. These include the host name and Internet address and can be set using the Web-based System Manager fast path, wsm network, or the SMIT fast path, smit mktcpip.

If you choose the SMIT method, use the smit mktcpip fast path to set these values permanently in the configuration database. Use the smit chinet and smit hostname fast paths to change them in a running system. The smit mktcpip fast path minimally configures TCP/IP. To add adapters, use the Further Configuration menu, which can be reached with the smit tcpip fast path.

If you have already checked these to verify accuracy and you are still having trouble sending and receiving information, check the following:

If these steps do not identify the problem, refer to "Problems with a SLIP Network Interface", "Problems with an Ethernet Network Interface", or "Problems with a Token-Ring Network Interface".

Problems with a SLIP Network Interface

In general, the most effective method for debugging problems with a Serial Line Interface Protocol (SLIP) interface is to retrace your configuration, verifying each step. However, you can also:

If the modem is not functioning correctly:

If the tty is not functioning properly, verify that the tty's baud rate and modem characteristics are set correctly in the configuration database by entering the smit tty fast path.

Problems with an Ethernet Network Interface

If the network interface has been initialized, the addresses correctly specified, and you have verified that the adapter card is good:

Problems with a Token-Ring Network Interface

If you cannot communicate with some of the machines on your network although the network interface has been initialized, the addresses correctly specified, and you have verified that the adapter card is good:

Problems with a Token-Ring/Ethernet Bridge

If you cannot communicate between a token-ring and an Ethernet network, using a bridge, and you have verified that the bridge is functioning properly, the Ethernet adapter may be dropping packets. A machine drops packets if the incoming packet (including headers) is greater than the network adapter's maximum transmission unit (MTU) value. For instance, a 1500-byte packet sent by a token-ring adapter over the bridge collects an 8-byte logical link control (LLC) header, making the total packet size 1508. If the receiving Ethernet adapter's MTU is set to 1500, the packet is dropped.

Check the MTU values of both network adapters. To allow for the eight-byte LLL header, the token-ring adapter attaches to outgoing packets, the MTU value for the token-ring adapter should be set at least eight bytes lower than the MTU value for the Ethernet adapter. For example, the MTU for a token-ring adapter should be set to 1492 to communicate with an Ethernet adapter with an MTU of 1500.

Problems with a Token-Ring/Token-Ring Bridge

When operating through a bridge, the default value of 1500 for the maximum transmission unit (MTU) should be changed to a value that is eight less than the maximum information field (maximum I-frame) advertised by the bridge in the routing control field.

To find the routing control field value, use the iptrace daemon to look at incoming packets. Bits 1, 2, and 3 of Byte 1 are the Largest Frame Bits, which specify the maximum information field that can be transmitted between two communicating stations on a specific route. Refer to the following figure for the format of the routing control field:

Values for the Largest Frame Bits are as follows:

000 Specifies a maximum of 516 bytes in the information field.
001 Specifies a maximum of 1500 bytes in the information field.
010 Specifies a maximum of 2052 bytes in the information field.
011 Specifies a maximum of 4472 bytes in the information field.
100 Specifies a maximum of 8144 bytes in the information field.
101 Reserved.
110 Reserved.
111 Used in all-routes broadcast frames.

For example, if the maximum I-frame value is 2052 in the routing control field, the MTU size should be set to 2044. This is for token-ring network interfaces only.

Note: When using iptrace, the output file must not be on a Network File System (NFS).

Problems with Packet Delivery

Communicating with a Remote Host

If you cannot communicate with a remote host, try the following:

If you are having trouble with packet loss or are experiencing delays in packet delivery, try the following:

If you cannot communicate between a token-ring and an Ethernet network using a bridge, and you have verified that the bridge is good:

snmpd Response to Queries

If snmpd is not responding to queries and there are no log messages received, the packet may be to large for the kernel User Datagram Protocol (UDP) packet handler. If this is the case, increase the kernel variables, udp_sendspace and udp_recvspace by issuing the following commands:

no -o udp_sendspace=64000
no -o udp_recvspace=64000

The maximum size for a UPD packet is 64K. If your query is larger than 64K, it will be rejected. The packet should be split into smaller packets to avoid this problem.

Problems with Dynamic Host Configuration Protocol (DHCP)

If you cannot get an IP address or other configuration parameters:


[ Previous | Next | Contents | Glossary | Home | Search ]