From owner-freebsd-net@freebsd.org Tue Jun 27 09:04:36 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D534BDA55A1 for ; Tue, 27 Jun 2017 09:04:36 +0000 (UTC) (envelope-from prvs=34432f271=youssef.ghorbal@pasteur.fr) Received: from mx0.pasteur.fr (mx0.pasteur.fr [157.99.45.50]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "Cisco Appliance Demo Certificate", Issuer "Cisco Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 28B79829D2 for ; Tue, 27 Jun 2017 09:04:35 +0000 (UTC) (envelope-from prvs=34432f271=youssef.ghorbal@pasteur.fr) Authentication-Results: mx0.pasteur.fr; spf=None smtp.pra=youssef.ghorbal@pasteur.fr; spf=None smtp.mailfrom=youssef.ghorbal@pasteur.fr; spf=None smtp.helo=postmaster@EXCHANGE02.corp.pasteur.fr Received-SPF: None (mx0.pasteur.fr: no sender authenticity information available from domain of youssef.ghorbal@pasteur.fr) identity=pra; client-ip=157.99.211.32; receiver=mx0.pasteur.fr; envelope-from="youssef.ghorbal@pasteur.fr"; x-sender="youssef.ghorbal@pasteur.fr"; x-conformance=sidf_compatible Received-SPF: None (mx0.pasteur.fr: no sender authenticity information available from domain of youssef.ghorbal@pasteur.fr) identity=mailfrom; client-ip=157.99.211.32; receiver=mx0.pasteur.fr; envelope-from="youssef.ghorbal@pasteur.fr"; x-sender="youssef.ghorbal@pasteur.fr"; x-conformance=sidf_compatible Received-SPF: None (mx0.pasteur.fr: no sender authenticity information available from domain of postmaster@EXCHANGE02.corp.pasteur.fr) identity=helo; client-ip=157.99.211.32; receiver=mx0.pasteur.fr; envelope-from="youssef.ghorbal@pasteur.fr"; x-sender="postmaster@EXCHANGE02.corp.pasteur.fr"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.39,399,1493676000"; d="scan'208";a="1442675" Received: from exchange02.corp.pasteur.fr ([157.99.211.32]) by mx0.pasteur.fr with ESMTP/TLS/AES256-GCM-SHA384; 27 Jun 2017 11:04:27 +0200 Received: from EXCHANGE02.corp.pasteur.fr (2002:9d63:d320::9d63:d320) by EXCHANGE02.corp.pasteur.fr (2002:9d63:d320::9d63:d320) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Tue, 27 Jun 2017 11:04:26 +0200 Received: from EXCHANGE02.corp.pasteur.fr ([fe80::a819:199f:2049:3d20]) by EXCHANGE02.corp.pasteur.fr ([fe80::a819:199f:2049:3d20%18]) with mapi id 15.01.0845.034; Tue, 27 Jun 2017 11:04:26 +0200 From: "Youssef GHORBAL" To: Navdeep Parhar CC: "freebsd-net@freebsd.org" Subject: Re: Sporadic TCP/RST sent to client Thread-Topic: Sporadic TCP/RST sent to client Thread-Index: AQHS66rb2Qoho5P9iUa0cYMOeRPraqI3fpaAgADRTIA= Date: Tue, 27 Jun 2017 09:04:26 +0000 Message-ID: References: <84CB0795-B28E-46DF-9593-4C1BAAB7DDF5@pasteur.fr> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [157.99.101.113] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 09:04:36 -0000 [...] >> I've read about netisr work and I was under the impression that e= ven if it's SMP enabled it was made to keep prorocol ordering. >>=20 >> What's the expected behaviour in this scenario on the netisr side= ? >> How can I push the investigation further ? >=20 > I think you've already figured out the situation here -- the PSH/ACK is l= ikely > being handled before the ACK for the SYN because they arrived on differen= t > interfaces. There is nothing in netisr dispatch that will maintain proto= col > ordering in this case. Navdeep, thank you for you feedback. I don't get the fact that netisr is no= t lagg "aware" (if I may say) I understand that netisr dispatch can't maintain ordering if NICs are treat= ed separetly. But when they are enslaved in a "lagg", from the point of the= view of the lagg interface itself, packets arrive ordred and I expect the = system to handle it correctly. The fact is that it is actually handled corr= ectly in most cases but not when packets are really "close" (under 10 micro= seconds) Maybe the default sysctl settings are not meant to handle this corner case,= but I did'nt find anything regarding this in documentation. Youssef Ghorbal=