[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]

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 for determining which area of the network has a problem. 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

When NIS+ is installed, lookup preferences are set using the irs.conf file. For more information, see AIX 5L Version 5.2 Network Information Services (NIS and NIS+) Guide.

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, check for logged messages. The output for these messages is defined in the /etc/syslog.conf file.

If these steps do not identify the problem, check 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 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 5L Version 5.2 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 might 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

If the inetd daemon is up and running correctly and the appropriate service seems to be correct but you still cannot connect, try running the inetd daemon processes through a debugger.

  1. Stop the inetd daemon temporarily:

    stopsrc -s inetd

    The stopsrc command stops subsystems like the inetd daemon.

  2. Edit the syslog.conf file to add a debugging line at the bottom. For example:

    vi /etc/syslog.conf
    1. Add the line "*.debug /tmp/myfile" at the bottom of the file and exit.
    2. The file that you specify must exist (/tmp/myfile in this example). You can use the touch command to make your file exists.
  3. Refresh the file:
  4. Start the inetd daemon backup with debugging enabled:

    startsrc -s inetd -a "-d"

    The -d flag enables debugging.

  5. Try to make a connection to log errors in the /tmp/myfile debugging file. For example:

    tn bastet
    connected to bastet
    Connection closed
  6. See if anything shows up as a problem in the debugging file. For example:

    tail -f /tmp/myfile

telnet or rlogin Problems

The following explanations can 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:

    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 can 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.

telnetd Daemon Debugging

If the inetd daemon could execute the telnet service but you still cannot connect using the telnet command, there may be something wrong with the telnet interface.

  1. Verify that telnet is using the correct terminal type.
    1. Check the $TERM variable on your machine:

      echo $TERM
    2. Log in to the machine to which you are trying to attach and check the $TERM variable:

      echo $TERM
  2. Use the telnet interface's debugging capabilities by entering the telnet command without flags.

    1. Enter open host where host is the name of the machine.
    2. Enter Ctrl-T to get to the tn%gt; prompt.
    3. At the tn> prompt, enter debug for debugging mode.
  3. Try to connect to another machine using the telnet interface:

    telnet bastet
    Connected to bastet
    Escape character is '^T'.

    Watch the display as the various commands scroll up the screen. For example:

    SENT do ECHO
    SENT will TERMINAL TYPE (reply)
    SENT will SUPPORT SAK (reply)
    RCVD do TERMINAL TYPE (don't reply)
    RCVD will ECHO (don't reply)
    RCVD will SUPPRESS GO AHEAD (don't reply)
    RCVD wont SUPPORT SAK (reply)
    SENT dont SUPPORT SAK (reply)
    RCVD do SUPPORT SAK (don't reply)
    SENT suboption TELOPT_NAWS Width 80, Height 25
    RCVD suboption TELOPT_TTYPE aixterm
  4. Check /etc/termcap or /usr/lib/terminfo for the aixterm definition. For example:

    ls -a /usr/lib/terminfo
  5. If the aixterm definition is missing, add it by building the ibm.ti file. For example:

    tic ibm.ti

    The tic command is a terminal information compiler.

Programs Using Extended Curses

Problems with function and arrow keys can 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, wsm, 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, wsm, 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, wsm, 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, see "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 correctly, verify that the tty 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 correctly, the Ethernet adapter might be dropping packets. A machine drops packets if the incoming packet (including headers) is greater than the network adapter 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 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, set the MTU value for the token-ring adapter at least eight bytes lower than the MTU value for the Ethernet adapter. For example, set the MTU for a token-ring adapter 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, change the default value of 1500 for the maximum transmission unit (MTU) 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. See the following for the format of the routing control field:

Figure 26. Routing Control Field. This illustration shows byte 0 and byte 1 of a routing control field. The eight bits of byte one are B, B, B, B, L, L, L, L. The eight bits of byte 1 are D, F, F, F, r, r, r, r.
Artwork for comma2

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 might 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. Split the packet 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:

[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]