![[EdCert previous]](../edcert/images/prev.gif)
![[EdCert next]](../edcert/images/next.gif)
![[EdCert top]](../edcert/images/top.gif)
The command netstat with the option -i displays a list of the interfaces available. Next, to interactively evaluate the amount of data that is being sent and received, the netstat -i 5 command is provided. This command displays a running count of the activity of the network interface. To halt this display type Control-C.
# netstat -i 5
input le0 output input (Total) output
packets errs packets errs colls packets errs packets errs colls
7464256 1 30072 1 1828 7464586 1 30402 1 1828
16 0 1 0 0 16 0 1 0 0
34 0 2 0 0 34 0 2 0 0
94 0 2 0 0 94 0 2 0 0
104 0 2 0 0 104 0 2 0 0
117 0 2 0 0 117 0 2 0 0
In this instance the activity on the default network interface, "le0",
is being tracked with the first five columns of data. The
last columns display the totals for all the network interface
devices for the system.
The first line of each screen of information contains a summary
since the system was last rebooted.
Subsequent lines of output show values accumulated over the preceding
interval.
The information being sent and received from the network are processed as packets. The packets contain two parts, a header and a payload. The header indicates to source and destination for the packet and the payload is the data being transmitted. There are other elements that comprise the header most notably is a checksum for the payload and protocol specific information. The size of a packet is network hardware and software dependent. The Maximum Transfer Unit, which is specified by the network interface, is usually 1500 bytes for Ethernet.
The busier the network the greater number of collisions, the colls column. Collisions are a symptom of a Carrier Sense Multiple Access Collision Detection technology which characterizes Ethernet. Other networking technologies such as ATM or SLIP (serial line internet protocol), use a point to point configuration and don't experience collisions. As a general rule of thumb, collisions of greater that 5% of the total number of packets should be resolved. Usually busy networks are caused by either to many machines on a single Ethernet segment or by machines that "swamp" the network with activity.
The errs column is the number of packets which are not in the format expected. This can occurs if there are hardware problems on the network or there are configuration problems with the network software.
Here is an example of high collision rates as displayed on a HP-UX system. The netstat command for HP-UX must be directed to display statistics for the Ethernet interface, lan0, with the option, -I lan0. This output was gathered while a remote backup was in progress. Once the backup is complete the collision rates fall back under 5%.
#netstat -I lan0 5
input (lan0) output input (Total) output
packets errs packets errs colls packets errs packets errs colls
11661301 38 2561833 2 131123 11677246 38 2999286 2 131123
957 0 482 0 116 957 0 484 0 116
920 0 449 0 84 920 0 451 0 84
981 0 483 0 88 981 0 485 0 88
1320 0 526 0 138 1320 0 528 0 138
* 1004 0 490 0 122 1004 0 494 0 122
19 0 17 0 0 19 0 19 0 0
4 0 0 0 0 4 0 2 0 0
12 0 0 0 0 12 0 2 0 0
13 0 1 0 0 13 0 3 0 0
The collision rate is calculated by dividing the number
of collisions by the number of output packets for the interface, lan0.
Using the data line with the asterisk, the collision
rate is calculated to be 25%, 122 / 490
Also an important utility is one that identifies which applications and systems are sending or receiving packets. Unfortunately there is not a standard tool distributed with all Unix's for this task. Solaris 2.X is the exception, the operating system distribution includes snoop. SGI's IRIX does not include the snoop command but they do have a compiled binary that can be retrieved from SGI ftp site. The source package tcpdump is available for all platforms. The following description of the tcpdump command is taken from the Linux HOWTO, NET-2.
14.3 tcpdump - capturing and displaying network activity.tcpdump allows you to take traces of network activity by intercepting the datagrams on their way in and out of your machine. This is useful for diagnosing difficult to identify network problems.
tcpdump decodes each of the datagrams that it intercepts and displays them in a slightly cryptic looking format in text. You would use tcpdump if you were trying to diagnose a problem like protocol errors, or strange disconnections, as it allows you to actually see what has happened on the network. To properly use tcpdump you would need some understanding of the protocols and how they work, but it is useful for simpler duties such as ensuring that datagrams are actually leaving your machine on the correct port if you are trying to diagnose routing problems and for seeing if you are receiving datagrams from remote destinations.
A sample of tcpdump output looks like this:
# tcpdump -i eth0 tcpdump: listening on eth0 13:51:36.168219 arp who-has gw.vk2ktj.ampr.org tell albert.vk2ktj.ampr.org 13:51:36.193830 arp reply gw.vk2ktj.ampr.org is-at 2:60:8c:9c:ec:d4 13:51:37.373561 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request 13:51:37.388036 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply 13:51:38.383578 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request 13:51:38.400592 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply 13:51:49.303196 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: S 7005 06986:700506986(0) win 512 < mss 1436> 13:51:49.363933 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 1103372289 win 14261 13:51:49.367328 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: S 1103 372288:1103372288(0) ack 700506987 win 2048 < mss 432> 13:51:49.391800 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 134 win 14198 13:51:49.394524 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: P 1:13 4(133) ack 1 win 2048 13:51:49.524930 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: P 1:28 (27) ack 134 win 14335 .. #When you start tcpdump without arguments it grabs the first (lowest numbered) network device that is not the loopback device. You can specify which device to monitor with a command line argument as shown above. tcpdump then decodes each datagram transmitted or received and displays them, one line each, in a textual form. The first column is obviously the time the datagram was transmitted or received. The remainder of the line is then dependent on the type of datagram. The first two lines in the sample are what an arp request from albert.vk2ktj for gw.vk2ktj look like. The next four lines are two pings from albert.vk2ktj to gw.vk2ktj, note that tcpdump actually tells you the name of the icmp datagram transmitted or received. The greater-than (>) symbol tells you which way the datagram was transmitted, that is, from who, to who. It points from the sender, to the receiver. The remainder of the sample trace are the establishment of a telnet connection from albert.vk2ktj to gw.vk2ktj.
The number or name at the end of each hostname tells you what socket number is being used. tcpdump looks in your /etc/services file to do this translation.
tcpdump explodes each of the fields and so you can see the values of the window and mss parameters in some of the datagrams.
The man page documents all of the options available to you.
Note for PPP users: The version of tcpdump that is currently available does not support the PPP suite of protocols. Al Longyear has produced a pair of patches to correct this, but these have not been built into a tcpdump distribution yet. The patch files are located in the same directory on sunsite.unc.edu as the tcpdump package.
Terms used: Ethernet, packet, network, collision.