tcpreplay won't replay all packets in a pcap file with --netmap flag at 5+ Gbps rate #255
Comments
|
Tcpreplay "Successful packets" reported means that netmap accepted the packets for transmission. Possibly you adapter needs more time before switching out of netmap mode, causing some packets to clip. Can you try playing with What version of netmap are you using? |
|
That sounds plausible because, when I save the resulting captures in CSV format and do a diff on them, the missing packets are always the last packets of the pcap file. However, this flag only seems to affect the delay switching into netmap mode. Switching out of netmap mode seems to be relatively instantaneous, regardless of what I set the flag to. I've tried up to 30 seconds. No improvement on reliability. Is the specified delay supposed to affect switching out of netmap mode as well as into? I'm not sure how to check the netmap version on FreeBSD, actually. It's whatever version is included in 10.3 as I just recompiled the kernel with the version included in FreeBSD's source. You wouldn't happen to know how I could check the version, do you? I'm not too familiar with working with *nix kernel modules and I am coming up short on Google. |
|
I guess its hard coded. I'll have a look. Maybe #250 will help as well, once it gets implemented. |
|
I did notice similar issues. Added delay before switching netmap to normal mode. Example of fix, note that TX difference on eth5 shows that the number reported sent by tcpreplay was also reported by the driver. |
I have FreeBSD 10.3 set up with a dual-port 10Gb Intel X520-SR2 network card, the netmap drivers, and tcpreplay.
Recently I discovered that if I replay a pcap file with the --netmap flag at a rate of 5 Gbps or higher all packets will not be transmitted. Tcpreplay will report that every packet was transmitted, but the receiving equipment reports that some are missing. The amount missing is not consistent from run to run, but some are always missing. I have a high-performance capture adapter receiving the traffic; it doesn't report any dropped packets or bad CRCs. In-between the capture adapter and the Intel card transmitting the packets, I have a Gigamon GigaVUE-HB2 which doesn't report any dropped packets but corroborates the number reported by my capture device.
If I remove the --netmap option, or if I retain the --netmap option but replay at a lower rate, such as 1 Gbps, the issue will not reproduce. (without the netmap option my system can't achieve 5 Gbps or higher either so, not sure if differentiating those scenarios means much)
This issue seems to reproduce regardless of the pcap file used. If necessary, I may be willing to find one that I'm ok with sharing.
A screenshot is located below, displaying the number of packets reported by all three tools.
Command example
tcpreplay -i ix1 -M 10000 -K --netmap [pcap file here]
dmesg output regarding dual-port 10Gb Intel X520-SR2
ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> port 0xe020-0xe03f mem 0xdfd80000-0xdfdfffff,0xdfe04000-0xdfe07fff irq 16 at device 0.0 on pci1
ix1: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> port 0xe000-0xe01f mem 0xdfd00000-0xdfd7ffff,0xdfe00000-0xdfe03fff irq 17 at device 0.1 on pci1
uname -rsp:
FreeBSD 10.3-RELEASE amd64
tcpreplay version info:
tcpreplay version: 4.1.1 (build git:v4.1.1)
Copyright 2013-2014 by Fred Klassen - AppNeta
Copyright 2000-2012 by Aaron Turner
The entire Tcpreplay Suite is licensed under the GPLv3
Cache file supported: 04
Compiled against libdnet: 1.12
Compiled against libpcap: 1.4.0
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Packet editing: disabled
Fragroute engine: enabled
Default injection method: bpf send()
Not compiled with Quick TX
Optional injection method: netmap
The text was updated successfully, but these errors were encountered: