Date: Fri, 28 Dec 2018 10:14:58 +0000 From: "Youssef GHORBAL" <youssef.ghorbal@pasteur.fr> To: "Muenz, Michael" <m.muenz@spam-fetish.org> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org> Subject: Re: DUP ACKs sent with no reason Message-ID: <0D994B53-FB3D-450C-8276-82649B6289FE@pasteur.fr> In-Reply-To: <74db0aae-3f93-aaa5-7241-8043ba0254bf@spam-fetish.org> References: <D15A92F5-91C2-44C3-A794-D3B399F67D8C@pasteur.fr> <74db0aae-3f93-aaa5-7241-8043ba0254bf@spam-fetish.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Dec 2018, at 07:37, Muenz, Michael <m.muenz@spam-fetish.org<mailto:m.muenz@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D994B53-FB3D-450C-8276-82649B6289FE>