From owner-freebsd-net@freebsd.org Thu Sep 22 07:23:13 2016 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 22A51BE5FA3 for ; Thu, 22 Sep 2016 07:23:13 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B88F6C90 for ; Thu, 22 Sep 2016 07:23:12 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22f.google.com with SMTP id w84so235241094wmg.1 for ; Thu, 22 Sep 2016 00:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=multiplay-co-uk.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=ucWXJPZdC697OxqiYxvpYREKzQV1poGxz0B/RxgopCQ=; b=DoxBGadCcf00G8SiXgyzshqSzv7gKeQj3b+fgYQTRHdPx82W8gq/WAnqWntbNSUbcq IbWJFyX66toYtXM/mmnl/Jatl7vbH7vgzM0uWzsnMWaC/irVpFayhsiFmjp6hb0k27s2 j/QFznIDuM6R8Dr97utfXcLLSMbPPD/FAHjJHvI+1GezeXTmQevXOmNre9KoMwevdKo+ w9OdFnYU69ikTTruNNZoPMMZxIOzH5r/lwop5AnjyTSfpPPLLHFdm2CFISC778EtUmEh ZwDxR96s7DaWg5p6v4MqOcrpAsU4zbCS/HgAa8LjcTJtFFFM595rx7R1HSI4cUlRpq1n MHfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ucWXJPZdC697OxqiYxvpYREKzQV1poGxz0B/RxgopCQ=; b=Rzmhg3BEAu4G+t6DKabIzWz0Y5zVlyql4IV02X6xx30LS/51cYGiVaF/Z9YL8P8rY+ JnTkY2x0erV/HNeL8h/pJXF8Os+hOaeBej7aL90+2LJUlf9qC7oRxBBFaGclu7xx2u6S Rt7yM9RheroK6mJZRLG1bDR2ZZagUFpI11jd/9g5OsU95trs8YpryY+MAAbgFFznRvle AshYCYgIKdGnVJk5ivhmYnP6AmHfsE3jTxz0KzmPX8M46KGC80RElbDypBzNY1PrBnwJ lT/TkKykPv/PwYwCPVHEXtzPMC9DcM4xWq3jSyDy1Im5shp7a8dcYJxIi/OBOOhq6hW5 wQGQ== X-Gm-Message-State: AA6/9Rl8i0qo9RG75yAcfo8kthoFP5sqJXubM5eXJR20Wctwmc8yLJbcElrxt+tM7y729AV3 X-Received: by 10.194.141.203 with SMTP id rq11mr567151wjb.112.1474528990983; Thu, 22 Sep 2016 00:23:10 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id w203sm36055406wmw.7.2016.09.22.00.23.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 00:23:10 -0700 (PDT) Subject: Re: lagg Interfaces - don't do Gratuitous ARP? To: Ryan Stone , Gleb Smirnoff References: <0D84203FAAFD0A8E7BBB24A3@10.12.30.106> <6E574F1B61786E6032824A88@10.12.30.106> <2c62f5f0-3fb4-f513-2a8f-02de3a1d552f@FreeBSD.org> <20160921235703.GG1018@cell.glebi.us> Cc: Kubilay Kocak , freebsd-net , Karl Pielorz From: Steven Hartland Message-ID: <796ab1c4-3a05-1e59-f8ba-355e75080935@multiplay.co.uk> Date: Thu, 22 Sep 2016 08:23:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Thu, 22 Sep 2016 07:23:13 -0000 On 22/09/2016 02:12, Ryan Stone wrote: > > > On Wed, Sep 21, 2016 at 7:57 PM, Gleb Smirnoff > wrote: > > IMHO, the original patch was absolutely evil hack touching multiple > layers, for the sake of a very special problem. > > I think, that in order to kick forwarding table on switches, lagg > should: > > - allocate an mbuf itself > - set its source hardware address to its own > - set destination hardware to broadcast > - put some payload in there, to make packet of valid size. Why > should it be > gratuitous ARP? A machine can be running IPv6 only, or may even > use whatever > higher level protocol, e.g. PPPoE. We shouldn't involve IP into > this Layer 2 > problem at all. > - Finally, send the prepared mbuf down the lagg member(s). > > And please don't hack half of the network stack to achieve that :) > > > The original report in this thread is about a system where it takes > almost 15 minutes for the network to start working again after a > failover. That does not sound to me like a switch problem. That > sounds to me like the ARP cache on the remote system. To fix such a > case we have to touch L3. 15mins is a long time however we don't do ARP correctly in this case, which is almost certainly the cause.