Articles

tcpdump Performance: Reduce Dropped Packets in Captures (2026)

April 6, 2026 6 min read

The real reason tcpdump drops packets isn’t about its own speed; it’s about the network interface’s inability to keep up with the raw traffic volume hitting it.

Let’s watch tcpdump in action, but first, we need a scenario. Imagine a busy web server. We want to capture all incoming HTTP requests to diagnose a slow response issue.

First, set up a simple web server.

sudo apt-get update && sudo apt-get install -y apache2
sudo systemctl start apache2
sudo systemctl enable apache2

Now, generate some traffic. We’ll use ab (ApacheBench) from another machine.

ab -n 10000 -c 100 http://<your_server_ip>/

On the server, we’ll start tcpdump. A naive approach might be:

sudo tcpdump -i eth0 -w capture.pcap

If you run ab hard enough, you’ll likely see tcpdump report dropped packets, something like:

10000 packets captured
1500 packets dropped by kernel

This "dropped by kernel" message is key. It means the network card (NIC) received a packet, but before the kernel’s networking stack could even hand it off to tcpdump, the NIC’s internal buffer was full, and the packet was discarded at the hardware level. tcpdump itself is often not the bottleneck here; it’s the system’s ability to process packets fast enough.

Common Causes and Fixes for Dropped Packets

  1. NIC Hardware Buffers are Too Small: The physical NIC has a limited amount of memory for incoming packets. If traffic floods this buffer, packets are dropped.

    • Diagnosis: Use ethtool -g <interface_name> (e.g., ethtool -g eth0) to see the current buffer ring sizes (rx-usecs, rx-frames). Look for unusually small values.
    • Fix: Increase the buffer sizes. For example, to set the RX ring size to 4096 descriptors:
      sudo ethtool -G eth0 rx 4096
      Why it works: This allocates more memory on the NIC to queue incoming packets, giving the kernel more time to process them before they are overwritten and lost. The exact maximum value depends on your NIC hardware.
    • Persistence: This change is not persistent across reboots. You’ll need to add it to a network interface configuration script (e.g., /etc/network/interfaces or a systemd-networkd unit) or a startup script.

  2. Kernel Network Buffer Limits: Even if the NIC buffers are large, the kernel’s own internal buffers for network traffic can become a bottleneck.

    • Diagnosis: Check current limits with sysctl net.core.rmem_max and sysctl net.core.netdev_max_backlog.
    • Fix: Increase these limits. For example:
      sudo sysctl -w net.core.rmem_max=16777216 # 16MB
sudo sysctl -w net.core.netdev_max_backlog=5000
      Why it works: net.core.rmem_max sets the maximum receive socket buffer size, and net.core.netdev_max_backlog controls the queue length for packets received from the network device driver before being processed by the kernel’s network stack. Increasing these allows the kernel to hold more packets temporarily.
    • Persistence: Add these to /etc/sysctl.conf to make them permanent.

  3. CPU Saturation: If the CPU is overloaded, it can’t process incoming network packets fast enough, leading to drops at the NIC or kernel level.

    • Diagnosis: Monitor CPU usage with top or htop. Look for sustained high CPU utilization (e.g., >80%) across all cores, especially during the capture period.
    • Fix:
      • Offload Tasks: If possible, move the capture or the source of traffic to a less loaded machine.
      • Reduce Packet Rate: If you are generating the traffic, reduce the number of concurrent connections (-c) or requests per second in your load generator.
      • Optimize Application: If the server application is CPU-bound, optimize it.
      • Hardware Upgrade: In extreme cases, a faster CPU or more cores might be necessary.
      • IRQ Affinity: (Advanced) Ensure network card interrupts (IRQs) are spread across multiple CPU cores. Use cat /proc/interrupts to see IRQ assignments and smp_affinity to adjust.
    • Why it works: Less CPU load means more cycles are available for the kernel to handle network I/O.

  4. tcpdump Capture Filter is Too Complex/Inefficient: While tcpdump’s BPF filter is generally efficient, extremely complex filters can still consume CPU resources.

    • Diagnosis: Compare capture rates with and without a filter. If sudo tcpdump -i eth0 -w capture.pcap (no filter) drops fewer packets than sudo tcpdump -i eth0 'port 80' -w capture.pcap, the filter might be a factor.
    • Fix: Simplify the filter or, better yet, move the filtering to a more efficient point.
      • Use iptables or nftables: Create rules to drop unwanted traffic before it hits the network stack’s processing path for tcpdump.
      • Hardware Filtering: Some high-end NICs support packet filtering directly in hardware.
      • Capture Everything, Filter Later: If filtering is the main issue, capture raw packets and use Wireshark or tshark on a more powerful machine to filter and analyze.
    • Why it works: Offloading filtering or simplifying it reduces the CPU burden on the machine running tcpdump.

  5. tcpdump Packet Buffering (Less Common for Drops, More for Latency): tcpdump itself has internal buffers. If it can’t write to disk fast enough, it might drop packets.

    • Diagnosis: Monitor disk I/O on the capture machine using iostat. If the disk is saturated (high %util, high await), this could be a bottleneck for writing the capture file.
    • Fix:
      • Faster Storage: Write to a faster disk (SSD, NVMe) or a different disk than the OS.
      • Networked Capture: If writing to a remote NFS share, ensure the network and the remote storage are not bottlenecks.
      • Increase tcpdump’s buffer: tcpdump -B <buffer_size_in_KB> (e.g., tcpdump -B 2097152 for 2GB).
    • Why it works: Larger buffers give tcpdump more breathing room to write captured packets to disk without overflowing its internal queues.

  6. Driver Issues or NIC Hardware Faults: Outdated drivers or failing hardware can lead to erratic behavior, including packet drops.

    • Diagnosis: Check dmesg for any NIC-related error messages. Update NIC drivers to the latest stable version. Test the NIC with a loopback test or by swapping it if possible.
    • Fix: Update drivers or replace faulty hardware.
    • Why it works: Ensures the NIC and its software interface are functioning correctly.

  7. Interrupt Storms: Excessive network traffic can cause a very high rate of interrupts, overwhelming the CPU’s interrupt handling mechanisms.

    • Diagnosis: Monitor interrupts using vmstat 1 (look at in column) or sar -I SUM 1. High interrupt rates correlate with high packet rates.
    • Fix:
      • Reduce Traffic: The most direct solution.
      • IRQ Affinity: As mentioned in CPU saturation, spreading IRQs across cores helps.
      • rx-usecs Tuning: For some NICs, ethtool -C eth0 rx-usecs 0 can disable timer-based coalescing, making interrupts more immediate but also more frequent. This is a trade-off: can reduce drops under heavy load but increases CPU overhead. Test carefully.
    • Why it works: By managing how often the CPU is interrupted by the NIC, you can balance responsiveness with CPU load.

After implementing these fixes, you’ll likely encounter a different problem: understanding the sheer volume of data captured.

More Deep Dives in Tcpdump

Want structured learning?

Take the full Tcpdump course →