ping Command

Use ping to look at the response of hosts on the network. The simplest version of ping sends a single packet to a host on the network. If it receives the correct response, it prints the message host is alive.

% ping elvis elvis is alive.

With the -s option, ping sends one datagram per second to a host. It then prints each response and the time it took for the round trip. For example:

% ping -s pluto 64 bytes from pluto (123.456.78.90): icmp_seq=0. time=10. ms 64 bytes from pluto (123.456.78.90): icmp_seq=5. time=0. ms 64 bytes from pluto (123.456.78.90): icmp_seq=6. time=0. ms ^C ----pluto PING Statistics---- 8 packets transmitted, 8 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/2/10 %

If you suspect a physical problem, you can use ping to find the response time of several hosts on the network. If the response from one host is not what you would expect, you can investigate that host.

spray Command

Use spray to test the reliability of your packet sizes. It can tell you whether packets are being delayed, or dropped.

The following example sends 100 packets to a host (-c 100) with each packet having a size of 2048 bytes (-l 2048). The packets are sent with a delay time of 20 microseconds between each burst (-d 20). If you don't use a delay, you may run out of buffers.

% spray -c 100 -d 20 0 -l 2048 pluto spray -c 100 -d 20 -l 2048 iris sending 100 packets of length 2048 to pluto ... no packets dropped by pluto 279 packets/sec, 573043 bytes/sec

Physical problems could be caused by:

• Loose cables or connectors
• Improper grounding
• Missing termination
• Signal reflection

snoop Command

Use snoop to capture packets from the network and trace the calls from each client to each server. It provides accurate time stamps that allow some network performance problems to be isolated quickly. For more information, see the reference page for snoop(1M).

Dropped packets could be caused by insufficient buffer space, or an overloaded CPU.

netstat Command

The netstat command displays statistics about the network interfaces. With the -i option, netstat displays the state of the interfaces used for TCP/IP traffic.

pluto% netstat -i Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue ie0 1500 software pluto 28926802 16235 39590055 22109 13690055 0 lo0 1536 loopback localhost 850886 0 850886 0 0 0

This display shows how many packets a machine has transmitted and received on each interface. A machine with active network traffic should show both Ipkts and Opkts continually increasing.

Calculate the network collisions rate by dividing the number of collision counts (Collis) by the number of out packets (Opkts). In the above example, the collision rate is 3.5 percent. A network-wide collision rate greater than 5 to 10 percent can indicate a problem.

Calculate the input packet error rate by dividing the number of input errors by the total number of input packets (Ierrs/Ipkts). The output packet error rate is the number of output errors divided by the total number of output packets (Oerrs/Opkts). If the input error rate is high (over 0.25 percent), the host may be dropping packets.

With the -s option, netstat displays the per-protocol statistics for the UDP, TCP, ICMP, and IGMP protocols. This example shows part of the netstat -s display:

UDP 0 udpInDatagrams = 61321 udpInErrors udpOutDatagrams = 6783 tcpRtoAlgorithm = 4 ttcpRtoMin = 50 tcpRtoMax = 60000 tcpMaxConn = -1 . . . IP ipForwarding = 1 ipDefaultTT = 255 ipInReceives = 13429 ipInHdrError = 0 8 s . . . ICMP icmpInMsgs = 116 icmpInErrors = 0 icmpInCksumErrs = 0 icmpInUnknow n IGMP: 0 messages received 0 messages received with too few bytes 0 membership reports sent

The -r option of netstat displays the IP routing table.

Routing Table: Destination Gateway Flags Ref Use Interface ----------------- ------------ ----- --- --- -------- localhost localhost UGHD 0 0 lo0 earth-bb sleepy U 3 1 software pluto U 3 147 lo0 224.0.0.0 pluto UG 3 0 lo0 default mars UG 0 18 default earth UG 0 30 default venus UG 0 18 default neptune UG 0 26 default saturn UG 0 3

The fields in the netstat report mean:

· Flags shows the state of the route. The letters under this heading mean: . U

The route is up.

. G The route is through a gateway.

. H The route is to a host.

. D The route was dynamically created using a redirect.

• Ref shows the current number of routes sharing the same link layer.
• Use indicates the number of packets sent out.
• Interface lists the network interface used for the route.

nfsstat Command

The nfsstat utility can be used to identify NFS problems. nfsstat displays a summary of server and client statistics. Run nfsstat -c to show client statistics, and nfsstat -s to show server statistics.

The following example displays RPC and NFS data for the client, pluto.

pluto% nfsstat -c Client rpc: calls badcalls retrans badxid timeout wait newcred timers 6888 123 10 51 101 0 0 138 Client nfs: calls badcalls nclget nclcreate 6765 0 6765 0 null getattr setattr root lookup readlink read 0 0% 1364 20% 4 0% 0 0% 1643 24% 928 13% 1622% wrcache write create remove rename link symlink 0 0% 14 0% 11 0% 1 0% 0 0% 0 0% 0 0% mkdir rmdir readdir fsstat 1 0% 0 0% 2535 37% 10 21%

The nfsstat display shows the following fields:

• calls shows the total number of calls sent.
• badcalls is the total number of calls rejected by RPC.
• retrans is the total number of retransmissions. For this client, the number of retransmissions is less than 1 percent (10 time-outs out of 6888 calls). These may be caused by temporary failures. Higher rates may indicate a problem.
• badxid is the number of times that a duplicate acknowledgment was received for a single NFS request.
• timeout is the number of calls that timed out.
• wait is the number of times a call had to wait because no client handle was available.
• newcred is the number of times the authentication information had to be refreshed.

• timers is the number of times the time-out value was greater than or equal to the specified time-out value for a call.
• readlink is the number of times a read was made to a symbolic link. If this number is high (over 10 percent), it could mean that there are too many symbolic links.

The NFS distributed file service uses a remote procedure call (RPC) facility which translates local commands into requests for the remote host. The remote procedure calls are synchronous. That is, the client application is blocked or suspended until the server has completed the call and returned the results. One of the major factors affecting NFS performance is the retransmission rate.

If the file server cannot respond to a client's request, the client retransmits the request a specified number of times before it quits. Each retransmission imposes system overhead, and increases network traffic. Excessive retransmissions can cause network performance problems. If the retransmission rate is high, you could look for:

• Overloaded servers that take too long to complete requests
• An Ethernet interface dropping packets
• Network congestion which slows the packet transmission

Use netstat -m to display network statistics for each file system.

pluto% nfsstat -m /usr/man from pluto:/export/svr4/man Flags: hard,intr,dynamic read size=8192, write size=8192, retrans = 5 Lookups: srtt=14 (35ms), dev=4 (20ms), cur=3 (60ms) Reads: srtt=17 (42ms), dev=6 (30ms), cur=5 (100ms) All: srtt=15 (37ms), dev=7 (35ms), cur=5 (100ms)

This display reports the following statistics, in milliseconds:

• srtt is the smoothed average of the round-trip times.
• dev is the average deviations.
• cur is the current "expected" response time.

If you suspect that the hardware components of your network are creating problems, you need to look carefully at the cabling and connectors.