I currently have 2 Debian 5.0 (Lenny) kernal 2.6.26 machines. One is a sender for replaying network traffic and one is a reciever. Both of the machines have Broadcom Netxtreme II 57710 10gbe NICs installed. I have installed tcpdump 4.1.1 (libpcap 1.1.1) on the receiver, and I have installed tcpreplay on the sender. I am attempting to replay traffic from the sender directly to the receiver via the 2 10gbe NICs and a cat6 cable. The scenario seems to execute just fine, but for some reason tcpdump is not accounting for all of the packets that are sent. I am using

tcpdump -i eth1 -w dump.pcap

to capture and

tcpreplay -i eth1 --mbps=100 --limit=500000 large_capture.pcap

to send. Below are the results form tcpdump after the send completes:

tcpdump: listening on eth1, link-type EN10MB (Ethernet)
401215 packets captured
401215 packets received by filter
0 packets dropped by kernel

I am clearing the NIC statistics before I begin. Below are the results from (ifconfig and ethtool -s) after the capture has completed:

Sender (Replay Machine):

ethtool results:

tx_ucast_packets: 498164
tx_mcast_packets: 833
tx_bcast_packets: 1009

ifconfig results:

eth1 Link encap:Ethernet HWaddr 00:10:18:30:fd:a0
inet6 addr: fe80::210:18ff:fe30:fda0/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:500006 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:385407124 (367.5 MiB)
Interrupt:38 Memory:c7800000-c7ffffff


Receiver (Tcpdump Machine):

ethtool results:

rx_ucast_packets: 498164
rx_mcast_packets: 833
rx_bcast_packets: 1009

ifconfig results:

eth1 Link encap:Ethernet HWaddr 00:10:18:64:ff:ea
inet6 addr: fe80::210:18ff:fe64:ffea/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:500006 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:385407124 (367.5 MiB) TX bytes:344 (344.0 B)
Interrupt:38 Memory:cf800000-cfffffff

I don't understand these results. What happened to the packets that tcpdump did not account for? Are they being dropped by libpcap? If so, is there a way to remedy this problem? I would think that tcpdump would be capable of capturing traffic at 100mbps on 10gbe NICs.

Do you try adding a filter to reduce the number of buffer packet instead of wild opening?

Well, it helps, but the problem is basicaly about the packet queue, disabling DNS reverse only because it shortens the time, packet needs to stay in the queue. So in fact it is just a way around, that does not help in all occasions too much.


________________________________________________________________________
Want to get-on Google's first page and loads of traffic to your website? Hire a SEO Specialist from Ocean Groups seo pecialist

I disabled the rx-checksum offloading parameter on the NIC and this stopped the packet loss.