Linux's version of TCP/IP has several utility programs that provide status information and statistics on network performance. Several debugging utilities are available that enable a developer or knowledgeable user to trace a network problem. This chapter examines the basic set of these tools. It begins with a look at the primary configuration files involved in TCP/IP. Although these files have been discussed in earlier chapters, it is worth examining them again in closer detail.
Not all of these tools and configuration files will be supplied with every version of Linux, especially because two variants (BSD and System V) of these utilities are in general distribution. Check your software package to see which utilities you are supplied with. If you need a utility that wasn't included, download it from a BBS or FTP site and hope for no incompatibility problems! Most of the commands and utilities mentioned in this chapter are not made available to all users, although the superuser can access them all.
Several files are involved in the complete specification of network addresses and configuration for TCP/IP. Linux allows comments on every line of these configuration files, as long as they are prefaced by a pound sign (#). Many Linux systems will have default, empty configuration files with many default entries commented out until the system administrator removes the comment symbols.
A symbolic name is an alternative to using an IP address. For example, it is much easier to call a neighboring machine darkstar than 147.23.13.32. Whenever a symbolic name is used as an address by an application, the TCP/IP software must be able to resolve that name into a network address (as TCP/IP only uses IP addresses). The ASCII file /etc/hosts is usually employed, with the symbolic names matched to network addresses. (Note that the /etc/hosts file does not apply when Yellow Pages (YP), Network Information Services (NIS), or Domain Name Server (DNS) systems are used. These services use their own configuration files.)
Linux uses the file /etc/hosts to hold the network addresses and symbolic names, as well as a connection called the loopback (which is examined later in this chapter in the section, "Loopback Drivers"). The loopback connection address is usually listed as the machine name loopback or localhost.
The /etc/hosts file consists of the network address in one column and the symbolic name in another. Although the network addresses can be specified in decimal, octal, or hexadecimal format, decimal is the most commonly used form (and use of the others can be downright confusing). You can specify more than one symbolic name on a line by separating the names with white space characters (spaces or tabs). The following is a sample Linux /etc/hosts file:
# network host addresses 127.0.0.1 localhost local merlin_server 157.40.40.12 artemis 157.40.40.2 darkstar 143.10.12.62 big_bob 153.21.63.1 tpci_server tpci_main tpci 191.13.123.4 kitty_cat
Whenever a user or an application specifies a symbolic name, Linux searches the /etc/hosts file for a matching name and then reads the proper address from the same line. You can change the contents of the /etc/hosts file at any time, and the changes are essentially in effect immediately.
Chapter 30, "Configuring TCP/IP," mentioned the /etc/networks file. This file allows networks to be addressed by a symbolic name, just as machines are, instead of by their IP address. To resolve the network names, the file /etc/networks is used to specify symbolic network names. The format of the file provides a network symbolic name, its network address, and any alias that might be used. A sample /etc/networks file is shown below:
# local network names tpci 146.1 tpci_network tpci_local bnr 47.80 BNR bnr.ca big_net 123.2.21 unique 89.12323 UNIQUE loopback 127 localhost
The last entry in the file gives the loopback name. The first entry specifies the local machine name, its network address, and its name variants that may be used by applications.
TCP/IP uses a special number, called a protocol number, to identify the specific transport protocol a Linux system receives. This allows the TCP/IP software to properly decode the information coming in. A configuration file called /etc/protocols identifies all the transport protocols available on the Linux and gives their respective protocol numbers. All systems have this file, although some entries may be commented out to prevent unwanted intrusion or abuse.
Usually the /etc/protocols file is not modified by the administrator. Instead, the file is maintained by the networking software and updated automatically as part of the installation procedure. The file contains the protocol name, its number, and any alias that may be used for that protocol. A sample /etc/protocols file is shown below:
# protocols ip 0 IP # internet protocol, pseudo protocol number icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol ggp 3 GGP # gateway-gateway protocol tcp 6 TCP # transmission control protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol idp 22 IDP # WhatsThis? raw 255 RAW # RAW IP interface
The exact contents of the /etc/protocols file on your system may differ a little from the file shown above, but the protocol numbers and names are probably very similar. There may be additional protocols listed, depending on the version of Linux and networking software.
The last TCP/IP configuration file used on most Linux systems identifies existing network services. This file is called /etc/services. As with the /etc/protocols file, this file is not usually modified by an administrator, but is maintained by software when installed or configured. The exception is when the /etc/services file has services missing that the application software did not add automatically. In addition, a system administrator can trim the /etc/services file in order to enhance security, such as when setting up a firewall to the local area network.
The /etc/services file is in ASCII format, and consists of the service name, a port number, and the protocol type. The port number and protocol type are separated by a slash. Any optional service alias names follow. The following is a short extract from a sample /etc/services file (the file is usually quite lengthy):
# network services echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null ftp 21/tcp telnet 23/tcp smtp 25/tcp mail mailx tftp 69/udp # specific services login 513/tcp who 513/udp whod
Most /etc/services files will have many more lines, because a wide number of TCP/IP services are supported by most versions of Linux. Most Linux systems are not used as firewalls to the Internet or between LANs, so administrators of most Linux machines will never have to worry about the contents of this file. On the other hand, if your machine is going to act as a firewall or you are very worried about security, you may want to manually modify the /etc/services file.
The loopback driver is one of the most fundamental and oft-used diagnostic tools available to a system administrator. The loopback driver acts like a virtual circuit out of and back into the host machine. All outgoing information is immediately rerouted back to an input. You can use the loopback driver to test your machine's circuits by eliminating any external influences (including the network card, the network itself, gateways, or remote machines). With the loopback driver, you can ensure that the local machine is working properly and that any problems are from further out on the network. Loopback drivers are embedded as part of the Linux operating system kernel.
Because TCP/IP requires a destination IP address in order to send data, a loopback driver is set up as a special network address with the IP address 127.0.0.1. The loopback driver entries are always made in the /etc/hosts file, as shown below:
loopback 127 localhost
The loopback driver is also known as the localhost, and you can use either name. If the loopback driver doesn't already exist on your machine, you must create it with the ifconfig command. For more information, see Chapter 30, "Configuring TCP/IP."
With the ifconfig program, you can activate and deactivate network interfaces, as well as configure them. Access to the ifconfig program is generally restricted to the superuser. Many options are available with ifconfig, most of which system administrators never use. Most of the time, you will use ifconfig only to enable an interface, as shown in Chapter 30, "Configuring TCP/IP."
The format of ifconfig commands always follow the same syntax. The syntax is
ifconfig interface [address [parms]]
where interface is the name of the interface, address is the (optional) IP address or symbolic name to be assigned to the interface (which is verified in /etc/hosts or /etc/networks), and parameters is one of a list of optional arguments for the address.
When used with only the name of an interface, ifconfig returns information about the current state of the interface, as shown in the following code. In this example, a query of both an Ethernet card and the loopback driver is performed. The status flags of the interface are followed by the Internet address, broadcast address, and optionally provides a network mask which defines the Internet address used for address comparison when routing. Your output may be different, but ifconfig should always display information about the interface (unless one has not been defined).
$ ifconfig eth0
eth0 Link encap 10Mps: Ethernet Hwaddr
inet addr 147.123.20.1 Bcast 147.123.1.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
$ ifconfig lo
lo Link encap: Local Loopback
inet addr 127.0.0.1 Bcast {NONE SET] Mask 255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
The output from the ifconfig command shows the interface, any characteristics it has assigned to it, broadcast addresses, and network masks. MTU stands for maximum transfer unit. The Maximum Transfer Unit size is usually set to the maximum value the interface type will support (1500 for Ethernet networks). Some operating systems use the Metric field to compute the cost of any particular route, although Linux doesn't use this field.
The RX and TX lines show how many packets of data have been received and transmitted respectively, both in total and those with errors, since the interface started in the current session.
As mentioned earlier, ifconfig accepts a long list of optional arguments to tailor the behavior of the interfaces. The following arguments are available with most versions of Linux:
| allmulti | This argument sets multicast mode. It is not currently supported by Linux. |
| -allmulti | This argument turns off multicast mode. |
| arp | Use this argument to enable Address Resolution Protocol to detect physical address on network machines. This argument is set to on by default. |
| -arp | This argument disables ARP. It sets characteristic flag NOARP. |
| broadcast | Followed by the broadcast address of the network, this argument sets the address used to address all machines on the network. This argument is used if the broadcast address is different than the normal address calculated by TCP/IP based on the Class type of the network. |
| down | This argument makes the interface unusable by the IP software until taken up again. |
| metric | This argument sets the metric value for the interface. Although Linux doesn't use this argument, it is included for compatibility with older TCP/IP implementations. |
| mtu | Followed by a value in bytes, this argument sets the Maximum Transmission Unit size (the number of octets the interface can handle in one datagram). System defaults are usually accurate. (Ethernet defaults to 1500, SLIP to 296.) |
| netmask | Followed by a mask value, this argument sets the subnet mask. |
| pointopoint | This argument is used for point-to-point IP (PLIP) interfaces connecting two machines through the parallel port |
| promisc | This argument sets the interface to promiscuous mode (receives all packets, whether they're for that machine's IP address or not). Used for analyzing network traffic, this argument sets the characteristic flag PROMISC. |
| -promisc | This argument turns off promiscuous mode. |
| up | Implied when an address is given, the up argument makes the interface available to the IP software. When active, the interface has the characteristics of UP and RUNNING. |
You can use most of these arguments when you use the ifconfig command, although most are not necessary for a well-configured network.
When a networked Linux machine is started, it activates TCP/IP and immediately accepts connections at its ports, spawning a process for each. To control the processes better, the inetd program was developed to handle the port connections itself, offloading that task from the server. The primary difference is that inetd creates a process for each connection that is established, whereas the server would create a process for each port (which leads to many unused processes). On many systems, some of the test programs and status information utilities are run through inetd.
The inetd program uses the configuration file /etc/inetd.conf. The following code is an extract of a sample /etc/inetd.conf file. The first column shows the service name (which corresponds to an entry in the services file such as /etc/services), the socket type (stream, raw, or datagram), protocol name, whether inetd can accept further connections at the same port immediately (nowait) or must wait for the server to finish (wait), the login that owns the service, the server program name, and any optional parameters needed for the server program.
#inetd.conf ftp stream tcp nowait NOLUID /etc/ftpd ftpd telnet stream tcp nowait NOLUID /etc/telnetd telnetd shell stream tcp nowait NOLUID /etc/rshd rshd login stream tcp nowait NOLUID /etc/rlogind rlogind exec stream tcp nowait NOLUID /etc/rexecd rexecd finger stream tcp nowait nouser /etc/fingerd fingerd comsat dgram udp wait root /etc/comsat comsat ntalk dgram udp wait root /etc/talkd talkd echo stream tcp nowait root internal discard stream tcp nowait root internal chargen stream tcp nowait root internal daytime stream tcp nowait root internal time stream tcp nowait root internal echo dgram udp wait root internal discard dgram udp wait root internal chargen dgram udp wait root internal daytime dgram udp wait root internal time dgram udp wait root internal
The actual /etc/inetd.conf file may be much longer, but the extract above shows the general format of the file. The /etc/inetd.conf file is read when the server is booted and every time a hangup signal is received from an application. This allows dynamic changes to the file, as any modifications would be read and registered on the next file read.
The netstat program provides comprehensive information about the local system and its TCP/IP system. Administrators commonly use this program to quickly diagnose a problem with TCP/IP. Although netstat's format and specific information differ with the version of Linux, netstat usually supplies the following important summaries, each of which is covered in more detail later:
With some later versions, information about the interprocess communications and other protocol stacks may be appended as well. The information to be displayed can usually be toggled with a command line option. The following are valid options for most versions of netstat are:
| -a | Displayd information about all interfaces |
| -c | Displays continuously, updating every few seconds |
| -i | Displays information about the interfaces |
| -n | Displays IP addresses instead of symbolic names |
| -o | Displays additional information about timer states, expiration times, and backoff times |
| -r | Displays information about the kernel routing table |
| -t | Displays information about TCP sockets only |
| -u | Displays information about UDP sockets only |
| -v | Displays version information |
| -w | Displays information about raw sockets only |
| -x | Displays information about sockets |
The output from a typical Linux installation that uses the netstat command is shown in the next few sections, which discuss netstat and its output in more detail. As already mentioned, the output and meaning may be different with other versions, but the general purpose of the diagnostic tool remains the same.
The netstat command with no options provides information on all active communications end points. To display information about a particular type of end point, use the letter of the type from the following list:
| -a | All connections |
| -t | TCP connections only |
| -u | UDP connections only |
| -w | RAW connections only |
| -x | Socket connections only |
To display all end points that are waiting for a connection (in addition to the sockets specified by one of the above flags), netstat uses the -a option. The -a option by itself will display all sockets.
The output is formatted into columns showing the protocol (Proto), the amount of data in the receive and send queues (Recv-Q and Send-Q), the local and remote addresses, and the current state of the connection. The following is a truncated sample output:
$ netstat -ta Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) ip 0 0 *.* *.* tcp 0 2124 tpci.login merlin.1034 ESTABL. tcp 0 0 tpci.1034 prudie.login ESTABL. tcp 11212 0 tpci.1035 treijs.1036 ESTABL. tcp 0 0 tpci.1021 reboc.1024 TIME_WAIT tcp 0 0 *.1028 *.* LISTEN tcp 0 0 *.* *.* CLOSED tcp 0 0 *.6000 *.* LISTEN tcp 0 0 *.listen *.* LISTEN tcp 0 0 *.1024 *.* LISTEN tcp 0 0 *.sunrpc *.* LISTEN tcp 0 0 *.smtp *.* LISTEN tcp 0 0 *.time *.* LISTEN tcp 0 0 *.echo *.* LISTEN tcp 0 0 *.finger *.* LISTEN tcp 0 0 *.exec *.* LISTEN tcp 0 0 *.telnet *.* LISTEN tcp 0 0 *.ftp *.* LISTEN tcp 0 0 *.* *.* CLOSED
In the preceding sample extract, three TCP connections are active, as identified by the state ESTABL. One has data being sent (as shown in the Send-Q column), while another has incoming data in the queue. The network names and port numbers of the connection ends is shown whenever possible. An asterisk means no end point has yet been associated with that address.
One connection is waiting to be hung up, identified by TIME_WAIT in the state column. After thirty seconds, these sessions are terminated and the connection freed. Any row with LISTEN as the state has no connection at the moment, and is waiting.
You can use the -a option by itself to display a complete list of all connections. The output, which is quite lengthy, looks the same, but includes all connections (active and passive):
$ netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) ip 0 0 *.* *.* tcp 0 2124 tpci.login merlin.1034 ESTABL. tcp 0 0 tpci.1034 prudie.login ESTABL. tcp 11212 0 tpci.1035 treijs.1036 ESTABL. tcp 0 0 tpci.1021 reboc.1024 TIME_WAIT tcp 0 0 *.1028 *.* LISTEN tcp 0 0 *.* *.* CLOSED tcp 0 0 *.6000 *.* LISTEN tcp 0 0 *.listen *.* LISTEN tcp 0 0 *.1024 *.* LISTEN tcp 0 0 *.sunrpc *.* LISTEN tcp 0 0 *.smtp *.* LISTEN tcp 0 0 *.time *.* LISTEN tcp 0 0 *.echo *.* LISTEN tcp 0 0 *.finger *.* LISTEN tcp 0 0 *.exec *.* LISTEN tcp 0 0 *.telnet *.* LISTEN tcp 0 0 *.ftp *.* LISTEN tcp 0 0 *.* *.* CLOSED udp 0 0 *.60000 *.* udp 0 0 *.177 *.* udp 0 0 *.1039 *.* udp 0 0 *.1038 *.* udp 0 0 localhost.1036 localhost.syslog udp 0 0 *.1034 *.* udp 0 0 *.* *.* udp 0 0 *.1027 *.* udp 0 0 *.1026 *.* udp 0 0 *.sunrpc *.* udp 0 0 *.1025 *.* udp 0 0 *.time *.* udp 0 0 *.daytime *.* udp 0 0 *.chargen *.* udp 0 0 *.route *.* udp 0 0 *.* *.*
The output is similar to that for the -ta options shown previously, except the UDP (User Datagram Protocol) connections have been added. UDP sessions have no state column because they do not have an end-to-end connection.
The behavior of the network interface (such as the network interface card) can be shown by using the -i option to the netstat command. This information quickly shows you whether major problems exist with the network connection.
The netstat -i command displays the name of the interface (Iface), the maximum number of characters a packet can contain (MTU), the metric value (not used with Linux), and a set of columns for the number of packets received without problem (RX-OK), received with errors (RX-ERR), received but dropped (RX-DRP), and received but lost due to overrun (RX-OVR). The transmitted packets have similar columns. The last column contains a list of flags set for the interface. The following is a sample output from a netstat -i command:
$ netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags lo 2000 0 231 0 0 0 231 0 0 0 BLRU eth0 1500 0 1230 2 9 12 1421 3 2 1 BRU
This extract shows two interfaces in use: an Ethernet device (/dev/eth0) and the loopback driver (lo0). In this case, you can see the Ethernet interface has had a few bad packet receptions. This is normal because of the nature of the Ethernet system, although if the numbers become too high a percentage of the total packets sent, you should start diagnostic methods to find out why.
You can obtain more specific information about one interface by using the -i option with a device name and a time interval, specified in seconds, such as netstat -i eth0 30, to obtain specific information about the behavior of the "eth0" (Ethernet) interface over the last thirty seconds. For example, the output below shows the activity of the Ethernet interface for the last 30 seconds:
$ netstat -i eth0 30 Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flags eth0 1500 0 2341 3 5 112 2111 5 8 8 BRU
The flags column in the netstat output matches the types of flags you saw with the ifconfig command. The meaning of the flags is shown in the following list:
| B | Broadcast address has been set |
| L | Loopback driver |
| M | Promiscuous mode |
| N | Trailers are avoided |
| O | ARP turned off |
| P | Point-to-point connection |
| R | Running |
| U | Interface is up |
As you can see in the extracts from the previous commands above, several of the flags can be combined into one block.
Versions of netstat that are based on System V UNIX (instead of BSD UNIX) allow displays of data buffer statistics. Information about the TCP/IP data buffers can be obtained with the netstat command's -m option. Monitoring the behavior of the buffers is important, because they directly impact the performance of TCP/IP. The output of the netstat -m command differs depending on the version of Linux networking software in use, reflecting the different implementations of the TCP/IP code.
The netstat -m command output is shown below. In this version, entries are provided for the streamhead, queue, message descriptor table (mblks), data descriptor table (dblks), and the different classes of data descriptor tables. The columns show the number of blocks currently allocated (alloc), the number of columns free (free), the total number of blocks in use (total), the maximum number of blocks that were in use at one time (max), and the number of times a block was not available (fail).
$ netstat -m streams allocation: config alloc free total max fail streams 292 79 213 233 80 0 queues 1424 362 1062 516 368 0 mblks 5067 196 4871 3957 206 0 dblks 4054 196 3858 3957 206 0 class 0, 4 bytes 652 50 602 489 53 0 class 1, 16 bytes 652 2 650 408 4 0 class 2, 64 bytes 768 6 762 2720 14 0 class 3, 128 bytes 872 105 767 226 107 0 class 4, 256 bytes 548 21 527 36 22 0 class 5, 512 bytes 324 12 312 32 13 0 class 6, 1024 bytes 107 0 107 1 1 0 class 7, 2048 bytes 90 0 90 7 1 0 class 8, 4096 bytes 41 0 41 38 1 0 total configured streams memory: 1166.73KB streams memory in use: 44.78KB maximum streams memory used: 58.57KB
The failure column is important, and tt should always show zeros. If a larger number appears there, it means that the particular resource in question has been overtaxed and the number of blocks assigned to that resource should be increased (followed by a kernel rebuild and a reboot of the system to effect the changes).
Routing tables are continually updated to reflect connections to other machines. To obtain information about the routing tables, the netstat -r and -rs options are used (the latter generates statistics about the routing tables).
The output from netstat -r and netstat -rs commands are shown below. The columns show the destination machine, the address of the gateway to be used (an asterisk means no gateway to be used), the Genmask which specifies the generality of the route (which IP addresses can be matched to it), a set of flags, a metric value (not used), a reference counter (Refs) that specifies how many active connections may use that route simultaneously, the number of packets that have been sent over the route (Use), and the interface name.
$ netstat -r Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface loopback * 255.0.0.0 U 0 0 21 lo big_system * 123.23.1.0 UGN 1 0 321 eth0 small_system * 165.213.14.0 UN 1 0 1213 eth0
The flags are used to show different characteristics of the route. The following are valid flags:
| D | Generated by ICMP |
| G | Uses a Gateway |
| H | Only a single host can be reached this way (such as loopback) |
| M | Modified by ICMP |
| U | Interface is up |
You can combine the -s and -rs options with the -n option to display the IP addresses of the entries in the routing table, instead of the symbolic name (as shown above). The layout and information displayed by the netstat command will vary depending on the Linux implementations, as in the following example:
$ netstat -nr Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.0.0.0 U 0 0 21 lo 123.23.1.2 * 123.23.1.0 UGN 1 0 321 eth0 165.213.14.1m * 165.213.14.0 UN 1 0 1213 eth0
This flag saves you from having to figure out the symbolic to IP address translations yourself.
System V-based versions of netstat (as opposed to most Linux BSD-based versions) enable you to display protocol statistics. Statistics about the overall behavior of network protocols can be obtained with the netstat -s command. This usually provides summaries for IP (Internet Protocol), ICMP (Internet Control Message Protocol), TCP (Transmission Control Protocol), and UDP (User Datagram Protocol). The output from this command is useful for determining where an error in a received packet was located, and then leading the user to try to isolate whether that error was due to a software or network problem.
Issuing the netstat -s command provides a verbose output, as shown in the following example:
$ netstat -s ip: 183309 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with header length < data size 0 with data length < header length 0 with unknown protocol 13477 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled 0 packets forwarded 0 packets not forwardable 75 no routes 0 redirects sent 0 system errors during input 309 packets delivered 309 total packets sent 0 system errors during output 0 packets fragmented 0 packets not fragmentable 0 fragments created icmp: 1768 calls to icmp_error 0 errors not generated because old message was icmp Output histogram: destination unreachable: 136 0 messages with bad code fields 0 messages < minimum length 0 bad checksums 0 messages with bad length Input histogram: destination unreachable: 68 0 message responses generated 68 messages received 68 messages sent 0 system errors during output tcp: 9019 packets sent 6464 data packets (1137192 bytes) 4 data packets (4218 bytes) retransmitted 1670 ack-only packets (918 delayed) 0 URG only packets 0 window probe packets 163 window update packets 718 control packets 24 resets 9693 packets received 4927 acks (for 74637 bytes) 37 duplicate acks 0 acks for unsent data 5333 packets (1405271 bytes) received in-sequence 23 completely duplicate packets (28534 bytes) 0 packets with some dup. data (0 bytes duped) 38 out-of-order packets (5876 bytes) 0 packets (0 bytes) of data after window 0 window probes 134 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 system errors encountered during processing 224 connection requests 130 connection accepts 687 connections established (including accepts) 655 connections closed (including 0 drops) 24 embryonic connections dropped 0 failed connect and accept requests 0 resets received while established 5519 segments updated rtt (of 5624 attempts) 5 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 0 connections lingered 0 linger timers expired 0 linger timers cancelled 0 linger timers aborted by signal udp: 0 incomplete headers 0 bad data length fields 0 bad checksums 68 bad ports 125 input packets delivered 0 system errors during input 268 packets sent
Again, the exact layout of the output changes depending on the version of the networking code. However, you can use the basic information with all formats.
Chapter 30, "Configuring TCP/IP," showed you how to use the ping command to check whether interfaces were functioning correctly. You use the ping (Packet Internet Groper) utility to query another system to ensure a connection is still active.
The ping program operates by sending out an Internet Control Message Protocol (ICMP) echo request. If the destination machine's IP software receives the ICMP request, it will issue an echo-reply back immediately. The sending machine will continue to send an echo request until the ping program is terminated with a break sequence (Ctrl-c or DEL in UNIX). After termination, ping displays a set of statistics. The following is a sample ping session:
$ ping merlin PING merlin: 64 data bytes 64 bytes from 142.12.130.12: icmp_seq=0. time=20. ms 64 bytes from 142.12.130.12: icmp_seq=1. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=2. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=3. time=20. ms 64 bytes from 142.12.130.12: icmp_seq=4. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=5. time=10. ms 64 bytes from 142.12.130.12: icmp_seq=6. time=10. ms --- merling PING Statistics --- 7 packets transmitted, 7 packets received, 0% packet loss round-trip (ms) min/avg/max = 10/12/20
An alternate method to invoke ping is to provide the number of times you want it to query the remote. Also, you could provide a packet length as a test. The following command instructs ping to use 256 data byte packets and to try five times:
$ ping merlin 256 5 PING merlin: 256 data bytes 256 bytes from 142.12.130.12: icmp_seq=0. time=20. ms 256 bytes from 142.12.130.12: icmp_seq=1. time=10. ms 256 bytes from 142.12.130.12: icmp_seq=2. time=10. ms 256 bytes from 142.12.130.12: icmp_seq=3. time=20. ms 256 bytes from 142.12.130.12: icmp_seq=4. time=10. ms --- merling PING Statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip (ms) min/avg/max = 10/13/20
Using ping to send large packets is one method of determining the network's behavior with large packet sizes, especially when fragmentation must occur. The ping program is also useful for monitoring response times of the network, by observing the reply time on packets sent as the network load (or the machine load) changes. This information can be very useful in optimization of TCP/IP. Some older implementations of ping simply reply with a message that the system at the other end is active (the message is of the form "X is alive"). To obtain the verbose messages shown previously, you must use the -s option.
The ping program is useful for diagnostics because it tells you whether the TCP/IP software is functioning correctly, whether a local network device can be addressed (validating its address), and whether a remote machine can be accessed (again validating the address and testing the routing). It also verifies the software on the remote machine.
The arp program manages entries in the system's Address Resolution Protocol (ARP) tables. ARP provides the link between the IP address and the underlying physical address. With arp, you can create, modify, or delete entries in the ARP table. Typically, this will have to be performed whenever a machine's network address changes (either because of a change in the network hardware or because of a physical move).
To use the arp program, you need to follow one of the following formats:
arp [-v] [-t type] -a [hostname] arp [-v] [-t type] -s hostname hwaddress arp [-v] -d hostname [hostname ...]
When specifying a hostname you can use either a symbolic name or the IP address.
To display the entry for a host or IP address, use the first format shown above. If you do not give a hostname, all hosts are shown. For example, to check the ARP entry for the remote machine darkstar, issue the following command:
$ arp -a darkstar IP address HW type HW address 147.12.32.1 10Mbps Ethernet 00:00:C0:5A:3F:C2
This command shows that the machine darkstar has the IP address 147.12.32.1, and is reached through a 10Mbps Ethernet connection. You can slightly alter the output by using the -t option with a specific type of interface. Valid values are ax25 (AMPR AX.25 networks), ether (10Mbps Ethernet), and pronet (IEEE 802.5 Token Ring). For example, to show all the Ethernet connections only, use the following command:
arp -t ether -a
To add an entry to the ARP tables, use the second format of the command shown earlier, using the -s option. When adding an entry, the hwaddress refers to the hardware address of the adapter (usually six sets of hexadecimal digits separated by colons). For example, to add an entry for the remote system big_cat, you would issue the command
arp -s big_cat 00:00:c0:10:A1
where the hardware address of the network card is as shown.
Finally, the last format of the arp command shown above is used to delete entries from the ARP table. This format may be necessary when you have incorrectly added an entry to the table or the network has changed. To delete the entry for the machine x-wing, issue this command:
arp -d x-wing
Several other options are valid with many versions of arp, but you will probably never have to use the arp command at all (let alone these more obscure options). If you need more information, the man pages include a list of all valid options and their functions.
Most Linux systems have a utility called traceroute available that sends a series of UDP (User Datagram Protocol) datagrams to a target machine. The datagrams are constructed slightly differently depending on their location in the stream sent to the remote machine. The first three datagrams have a field called Time to Live (TTL) set to a value of one, meaning that the first time a router encounters the message it is returned with an expiry message (the datagram has been discarded). The next three messages have the TTL field set to two, three, four, and so on so that each router the messages pass through will return an expiry message until the destination machine is successfully reached.
The traceroute output shows the round trip time of each message (which is useful for identifying bottlenecks in the network) and the efficiency of the routing algorithms (through a number of routers which may not be the best route). The following is sample output from a traceroute command:
$ traceroute black.cat.com 1 TPCI.COM (127.01.13.12) 51ms 3ms 4ms 2 BEAST.COM (143.23.1.23) 60ms 5ms 7ms 3 bills_machine.com (121.22.56.1) 121ms 12ms 12ms 4 SuperGateway.com (130.12.14.2) 75ms 13ms 10ms 5 black.cat.com (122.13.2.12) 45ms 4ms 6ms
This output shows each router the messages were received by until the destination machine was reached. The traceroute command has many options to tailor its behavior, which are all explained in the man page. The traceroute command is usually used by system or network administrators when there are delivery problems with messages or network behavior seems very slow. Because most Linux systems are on small local area networks or are stand-alone, you may never have to use traceroute.
For RPC (Remote Procedure Call) services, a utility called rpcinfo can determine which RPC services are currently active on the local machine or any remote system that supports RPC. The options supported by rpcinfo vary with the implementation, but all implementations allow flags to decide which type of service to check.
For example, the -p option displays the local portmapper. The following example shows the options supported by the Slackware Linux version of rpcinfo, as well as the output for the portmapper:
merlin:~# rpcinfo Usage: rpcinfo [ -n portnum ] -u host prognum [ versnum ] rpcinfo [ -n portnum ] -t host prognum [ versnum ] rpcinfo -p [ host ] rpcinfo -b prognum versnum rpcinfo -d prognum versnum merlin:~# rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100005 1 udp 650 mountd 100005 1 tcp 652 mountd 100003 2 udp 2049 nfs 100003 2 tcp 2049 nfs
As with the traceroute command, most system administrators will never need to use rpcinfo. If you are a network programmer or a network administrator, they may be handy utilities to know about, though.
This chapter has shown you the basic administration programs used with TCP/IP, as well as the configuration files that are necessary to use TCP/IP properly. Knowing the tools available and the type of diagnostics that can be produced is useful to better understanding TCP/IP and especially handy when you are having a problem.
