DUP ACKs sent with no reason
Youssef GHORBAL
youssef.ghorbal at pasteur.fr
Fri Dec 28 10:15:54 UTC 2018
On 28 Dec 2018, at 07:37, Muenz, Michael <m.muenz at spam-fetish.org<mailto:m.muenz at spam-fetish.org>> wrote:
Am 27.12.2018 um 19:32 schrieb Youssef GHORBAL:
What can explain those DUP ACKs sent by the FreeBSD host? (DUP ACKs sent by the client are "normal" in a way to report missing packet loss and carry Selective ACKs, but those sent by the BSD stack are hard to explain)
How can I push the investigation further ?
Hi,
I had similar phenomenons with DUP ACKs, lost packets and also duplicate ICMP replies when using Intel X710 cards.
Did you test exchanging hardware and trying Linux-only and/or BSD-only iperf to look for a difference?
Thanks Michael. I've tested what you suggested :
- iperf3 on Linux on both sides is working fine. (but It's not the same server with Linux on it, it's another box so I'm not sure it's a relevant test)
- iperf3 on FreeBSD on both sides exhebits the issue. (the client is not the same one as the Linux box in my initial tests, the server is)
=> I'm tempting to think that it's the FreeBSD that is the issue here.
I've also tested with other cards, on the FreeBSD host I have mellanox NICs and I have the same issue.
There is also something I forget to mention in my initial email. On the BSD host the network is configured with a lagg enslaving two cards.
I've had weird issues in the past when a single TCP session was scattred across the two NICs of a lagg :
https://lists.freebsd.org/pipermail/freebsd-net/2017-June/048291.html
This time I've ensured (using tcpdump on both cards of the lagg) that all tcp segments of the dialogue was actually using only one NIC.
Is there any known dtrace magic to track which part of the code is sending those ACKs ?
Youssef Ghorbal
More information about the freebsd-net
mailing list