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 S= elective 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 IC= MP replies when using Intel X710 cards. Did you test exchanging hardware and trying Linux-only and/or BSD-only iper= f 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 ser= ver 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 th= e same one as the Linux box in my initial tests, the server is) =3D> 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 ac= ross 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 t= cp 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>