next up previous contents
Next: Data gathering Up: Software utilities Previous: Modified ping behaviour   Contents


Tcpdump

Tcpdump is a network monitoring program that can dump traffic on the network [25]. The traffic of interest can be specified by command line arguments when tcpdump is run and tcpdump will only dump the required traffic. In this study, only ICMP request and reply packets between the pinging host and the destination host are of interest, thus it is always specified that tcpdump dumps only these packets. Tcpdump supports a variety of output options. By default it outputs packet headers in a user readable format to the standard output. This can be altered by specifying the option -w file, which tells tcpdump not to parse and print the packets, but to dump the raw packets to a file. In the study, tcpdump is always requested to dump raw packets to a file. The bytes of data from a packet to be dumped is by default 68 and can be altered by specifying the option -s snaplen, where snaplen is the length of a packet to be dumped. In the study, 68 bytes are adequate for identifying ICMP packets.

The use of tcpdump in the study is mainly due to its ability to measure packet timestamps in an operating system's kernel space. To understand this, it needs to know how tcpdump works. Tcpdump records network traffic by the use of a host computer's packet filter. A packet filter is an operating system service for selectively recording network packets. This is referred to as packet capture. Tcpdump is written in terms of the Packet Capture library (libpcap) which recognises a variety of packet capture systems on different operation system platforms. An example packet capture system is the Berkeley Packet Filter (BPF). In an operating system that supports BPF in the kernel space, after a tcpdump process enables BPF to listen on the network interface the link-level device driver calls BPF when a packet arrives at the network interface before it makes a decision whether the packet is addressed to the local host and should be passed up to the system protocol stack. At the time BPF gains control, it feeds the packet to the tcpdump process's filter which is specified by the user and is responsible for deciding whether a packet is to be accepted. If the packet is to be accepted, BPF copies the requested amount of data to the buffer associated with the filter and timestamps it. It is at this point that is is stated that tcpdump is capable of measuring packet timestamps in the kernel space. When the tcpdump process gets a chance to do a read from the buffer, there might already have been several packets in the buffer and tcpdump reads them as a unit. [28] [24] [32]

At least from kernel version 2.1.96, Linux supports a packet capture system called ``Linux Socket Filter'', which is based on BPF and provides kernel level packet filtering.3.2

Timestamps measured by tcpdump are closer to packets' wire times than those acquired in the user-space by a process such as ping, since they are captured by BPF just above the link-layer device driver which directly communicates with the network interface card. Furthermore, since ping timestamps an ICMP request packet earlier than BPF and timestamps the ICMP reply packet later than BPF, the round-trip time reported by ping is always larger than that reported by the tcpdump running on the same machine. In chapter 4, we analyse the measurement differences between ping and tcpdump monitors, and between tcpdump monitors.

Tcpdump plays an important role in the analysis of short term ping traffic patterns, which is covered in Chapter 5. There we study the patterns of wire round-trip times, which are caused by network and destination host factors. The smaller the monitor processing delays in the round-trip time measurements are, the better. Thus, in every ping experiment in the study, tcpdump was run to monitor the ICMP traffic, and round-trip times measured by tcpdump are used for analysis. In fact, this decision coincides with RFC2330 [33] which recommends the use of a packet filter to measure packet arrival and departure times as close to the their wire times as possible when conducting network dynamics study. Furthermore, tcpdump was run on separate monitoring machines that ran in single user mode and listened to the same link as the pinging host did. As RFC2330 noted, running packet filter on a separate machine helps avoid the timing problem that some packet filters receive timestamps corresponding to when the packets were scheduled to be injected into the network, rather than when they actually were sent out onto the network.

The last issue of tcpdump is related to the errors packet filters can exhibit. Paxon found that packet filters could exhibit five types of errors: drops, additions, re-sequencing, timing, and misfiltering [32]. Of these five error types, only drop error was encountered in this study. In an experiment aimed to compare the measurement differences between ping and tcpdump monitors, and between tcpdump monitors, tcpdump was run on the pinging host ab2. Packets were sent as fast as possible with option -l 1000 to lagavulin.caida.org. Four additional tcpdump monitors were run on hosts atmvectra, atmmon, m1, and m2. It was found that ping and the tcpdump monitors running on hosts atmvectra, atmmon, m1, and m2 all reported having captured 1639 packets (including request and reply packets), but the tcpdump monitor on ab2 reported only 1588. Looking into ab2's tcpdump file, it was found that the ICMP request packets with sequence numbers ranging from 949 to 999 were missed by the tcpdump monitor. Perhaps this was due to CPU resource contention on ab2 between ping and tcpdump.

Two simple strategies were applied to cope with the packet drop problem. First, the size of the socket receive-buffer was increased from the default 64 Kbytes to 1 Mbyte. With such a machine configuration, there is less contention for CPU resources and larger buffer space, so tcpdump is less likely to suffer from drop errors.

Second, two dedicated monitoring machines with the configuration described above were used in each experiment. It is assumed that there is little chance that both of the two monitoring machines will miss the same packet. Thus unless both of the monitoring machines failed to capture the same packet, we are able to tell if drops have occurred. Using two dedicated monitoring machines we are also able to detect other types of error if they happen in only one of the monitoring machines at a time.


next up previous contents
Next: Data gathering Up: Software utilities Previous: Modified ping behaviour   Contents
Xing Deng
July 1999