Checking the interface with netstat
Sometimes you just can't connect, and nothing you do seems to work. How can you find out what's wrong? We all know some troubleshooting tools, but we don't all know everything they do. This tip, excerpted from TCP/IP Network Administration, Help for UNIX System Administrators
, published by O'Reilly & Associates, discusses netstat, and the information it gives you.
If the preliminary tests lead you to suspect that the connection to the local area network is unreliable, the netstat -i command can provide useful information. The example below shows the output from the netstat -i command.
% netstat ?i Name MTU Net/Dest Address Ipkts Ieers Opkts Oerrs Collis Queue 1e0 1500 nuts.com Almond 442697 2 633424 2 50697 0 1o0 1536 loopback localhost 53040 0 53040 0 0 0
The line for the loopback interface, 1o0, can be ignored. Only the line for the real network interface is significant, and only the last five fields on that line provide significant troubleshooting information.
Let's look at the last field first. There should be no packets queued (Queue) that cannot be transmitted. If the interface is up and running, and the system cannot deliver packets to the network, suspect a bad drop cable or a bad interface. Replace the cable and see of the problem goes away. If it doesn't, call the vendor for interface hardware repairs.
The input errors (Ierrs) and the output errors (Oerrs) should be close to 0. Regardless of how much traffic has passed through this interface, 100 errors in either of these fields is high. High output errors could indicate a saturated local network or a bad physical connection between the host and the network. High input errors could indicate that the network is saturated, the local host is overloaded, or there is a physical network problem. Tools, such as ping statistics or a cable tester, can help you determine if it is a physical network problem. Evaluating the collision rate can help you determine if the local Ethernet is saturated.
A high value in the collision field (Collis) is normal, but if the percentage of output packets that results in a collision is too high, it indicates that the network is saturated. Collision rates greater than 5% bear watching. If high collision rates are seen consistently, and are seen among a broad sampling of systems on the network, you may need to subdivide the network to reduce traffic load.
Collision rates are a percentage of output packets. Don't use the total number of packets sent and received; use the values in the Opkts and Collis fields when determining the collision rate. For example, the output in the netstat sample above shows 50679 collisions out of 633424 outgoing packets. That's a collision rate of 8%. This sample network could be overworked; check the statistics on other hosts on this network. If the other systems also show a high collision rate, consider subdividing this network.
To learn more about TCP/IP Network Administration, Help for UNIX System Administrators, or to buy this book, click here. Did you like this tip? If you did (or if you didn't) then send us an email and let us know. Or visit our tips page where you can rate this, and other tips.
This was first published in March 2001