Some problems in capturing traffic with tcpdump at ~ 1 Gbps



Hello,
we are working with tcpdump in order to capture-to-disk traffic at
(about) 1 Gbps.

We are performing some measurements using two servers (backtoback
connected on e1000 GigaEthernet interfaces).
Both the servers are Dell 2850 with
2 CPU Xeon 3.2 GHz, with hyperthreading enabled
2 Gbytes RAM
SCSI disks
Linux Kernel 2.6.16-1-686-smp (recompiled in order to support SMP,
hyperthreading and 2 Gbytes RAM size)

We use tcpreplay in order to generate traffic at the max rate of ~850
Mbps (we have some traffic samples acquired with tcpdump).

linux_gen:/tank# tcpreplay -i eth1 -R
/home/tank_michele/sample_file

In the default configuration, we have packet dropped from tcpdump, but
not from the NIC (we use "netstat" to monitor the NIC).

We tuned the following kernel parameters and we have found a lot of
improvement in the packet capture process.

/proc/sys/net/core/rmem_default 409715100 bytes
/proc/sys/net/core/rmem_max 409715100 bytes
/proc/sys/net/core/netdev_max_backlog 300000 pkts

With this configuration we can capture 1 Gbyte of traffic, without drop
or packet loss; the whole traffic is written to disk.

linux_generator:/tank# tcpreplay -i eth1 -R
/home/tank_michele/sample_file
linux_capture:/tank#tcpdump -i eth1 -s 0 -n -w
/tmp/data/tcpdump/test

If we improve the amount of traffic to send to the capture process (for
instance 10 Gbytes, at Constant Bit Rate), many packets are dropped;
than we suppose that some buffers become full, dropping a lot of
traffic.

linux_generator:/tank# tcpreplay -i eth1 -l 10 -R
/home/tank_michele/sample_file
linux_capture:/tank#tcpdump -i eth1 -s 0 -n -W 10 -C 1000 -w
/tmp/data/tcpdump/test

Please, note that without writing to disk (-w /dev/null) no drop
occurs.

May be someone can help us?
Thank you very much,

--
-------------------------------------------------
Michele Sciuto
email Michele.Sciuto@xxxxxxxx
Skype sciuto75
-------------------------------------------------

.



Relevant Pages

  • Re: libpcap problem (hdr.len vs tcpdump file size)?
    ... I'm using tcpdump with -s 0, ... read should capture the whole frame; however it seems like that data ... output the rest of the packet. ... >> than the actual dump file. ...
    (comp.os.linux.networking)
  • Re: libpcap problem (hdr.len vs tcpdump file size)?
    ... I'm using tcpdump with -s 0, ... read should capture the whole frame; however it seems like that data ... output the rest of the packet. ... >> than the actual dump file. ...
    (comp.os.linux.development.apps)
  • Re: libpcap problem (hdr.len vs tcpdump file size)?
    ... I'm using tcpdump with -s 0, ... read should capture the whole frame; however it seems like that data ... output the rest of the packet. ... >> than the actual dump file. ...
    (comp.os.linux.development.system)
  • IP protocol checksum errors
    ... Frame 3484 ... Time delta from previous packet: ... Capture Length: 254 bytes ... Fragment offset: 0 ...
    (comp.os.linux.embedded)
  • RE: Snort + (OpenBSD or Linux)
    ... Snort + (OpenBSD or Linux) ... >on the same packet. ... Regarding OpenBSD vs. Linux packet capture performance (this is a really old ...
    (Focus-IDS)