I'm quite new to tcpdump. I've never used it except for very trivial tasks.

Recently, I was asked to complete the following job.

What I have: A server with a network interface connected to a switch. All traffic on that switch would be mirrored to this server. What I need: Store all these traffic to a PCAP format file. The file should include

  1. Only outgoing or incoming traffic are interested. Traffic that travels only within the subnet is not needed and should not be logged if possible.
  2. All multicast and broadcast traffic are not interested and should be ignored if possible
  3. All I need is Ethernet -> IPv4 -> TCP, UDP and ICMP. Others aren't interested and should be neglected if possible
  4. I don't need message body. Headers (Ethernet, IP and TCP/UDP/ICMP) are enough. So the body should not be logged if possible

The traffic would be ~100MByte/s during daytime and for my work, packet loss is not tolerable (it must be continuous for 24 hours).
Anyway, as is mentioned above, I don't need everything.


  1. How can I do the job?
  2. What should I take care of so that all data are collected smoothly without loss (almost).

Thank you.

  • 1
    It reads like you're trying to capture flow data at the switch uplink. Is that a fair assessment?
    – Scott Pack
    Mar 30, 2011 at 12:24
  • #4 is really hard to do. You never know how many more packet types are encapsulated in the packet. But before you do that you must do TCP and IP reassembly. Libnids is the only library I found that does IP defragmenation and TCP stream reassembly. So first you'd have to recreate all the streams separately, then detect how many encapsulation levels there are, then decide which of them you dont need, and filter these out.
    – Marcin
    Mar 30, 2011 at 13:27
  • @Scott I'm not sure about it. I was told that the switch is configured so that all flow would be mirrored to this port. Would you please explain why this is important? I know a few about networks, but mostly from textbooks, RFCs and papers, rather than real-life experience. Thank you!
    – Haozhun
    Mar 30, 2011 at 14:58
  • @Marcin Actually, as I don't know about tcpdump much, the most straightforward way for me would be write a C/C++ program and use libpcap to capture, check certain rules and then store it. But I am really worried about the performance as this is 100MByte/sec. However, I guessed tcpdump could do this great. Anyway, what's the solution if we don't care about #4? Thank you!
    – Haozhun
    Mar 30, 2011 at 15:04
  • if you're actually utilizing full 100MBit/sec (or do you really mean 100MByte/sec?), the first thing to look at is the drive you're dumping it to. I often do dumps directly to an external drive, and then I keep bumping into USB bandwidth limits (22-30mbyte/sec), so I started using eSATA and that aliviated that problem, but it's still not completely eliminated. If you have loads of traffic, you might need to build a RAID (not RAID5, that's really slow for writes!) to support full speed captures. The reason why payload scrubbing would be nice is it would minimize the write throughput.
    – Marcin
    Mar 30, 2011 at 16:03

1 Answer 1


My best bet would be to use something like:

 tcpdump -ieth0 -s96 -w traffic.dump 'ip or icmp or tcp or udp'

Where the "tricky" part will be to chose a correct value for the "-s" (snaplen) parameter (snaplen is the maximum length of the packet tcpdump will capture).

From the tcpdump man pages:

Snarf snaplen bytes of data from each packet rather than the default of 68 (with NIT, the minimum is actually 96). 68 bytes is adequate for IP, ICMP, TCP and UDP but may truncate protocol information from name server and NFS packets (see below). Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effectively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the smallest number that will capture the protocol information you're interested in.

In this example i'm using 96 to be "almost" sure that I would capture 100% of ethernet+ip+(icmp || udp || tcp) header values.

In case your traffic have IP or TCP options (i.e. timestamps) and you want to also capture this info, then you will have to play with the snaplen parameter (i.e. increase/decrease it).

In case the length of the headers of your packet is less than snaplen, you may also capture part of the payload.

Finally, to read the traffic captured, I would use something like:

tcpdump -e -nn -vv -r traffic.dump   

Where the important part is to use the "-e" option so you can get the ethernet headers printed.

This page gives you an idea about the size of the ethernet/tcp/udp headers under different circumstances and may help you to arrive to a "correct" value for the snaplen parameter.

  • 1
    Thank you for patiently posted so much for me. You really helped! Sorry, but still something I want to hear your opinion. What is the usual bottleneck that affects packet loss. How should I know if it has happened? Is there something I can do to avoid this (given enough hardware resource), i.e. is there any configuration I can make to boost tcpdump performance?
    – Haozhun
    Mar 30, 2011 at 15:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .