From owner-freebsd-net@freebsd.org Thu Sep 22 07:21:04 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 8A336BE5D2C for ; Thu, 22 Sep 2016 07:21:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 2D63E9B2 for ; Thu, 22 Sep 2016 07:21:04 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22a.google.com with SMTP id l132so309942516wmf.0 for ; Thu, 22 Sep 2016 00:21:04 -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=mPPdZqQDVkP7tkSZz9MiP+ij2xPpygHlQ1lty/36pOk=; b=RgZjViAmslEayZxV+l0DBBX5/kWXh/AVEltBNFW7Q1ISNk4xK67El0vbxzjYP80lzS uf7CSVF3TD6tplcy91TPWSHlOMf7CenK9c/2E1KXFKR6U5VKzanViQTy/uZ4X0cj8iKk S9Id7KuLmNTm/eMhWXzrN9Ynr5Q3m7lpaST5BNKjlvcfUEyqf+b8tyQH9sda+XR3WnMk tor/c4zfPbLLD0NOqJ1gixuMbzI9smlH3xpFlcQs8loYUepMHFFD2gBpn+wE9VuKuBLD F6LcytYyX/gGZKpx0RhRCGa+uIbkp3E/VLUGIfK1RLLQ7tZyzENLVlDqVos8CdLLef+3 0IrQ== 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=mPPdZqQDVkP7tkSZz9MiP+ij2xPpygHlQ1lty/36pOk=; b=NqnLuRR/ohCvJ/IM/RTLXeJvd+qQ2jzfPA5NDN6SZy9JGAII00Qbe+5cAIGM8bTvOs BtNwUCZaNC6fZurwRrL2byVG44MsSMhaIR6pgp3lVJ1zmNLDrUh4Fq4mTyiGKMvzqZ+A L6i6LVsYcRfRlWDw1kaXM9p5QKxQE5ujNGjzQB6GaZ1TweU2WPs2gkvw1n35Yt5/DNTw NCPVcQqWd9mWSHpTbtTxw0gP71aZtJZIMMZ5KXyI0+etY2Q0n6NOwXMkD+rQA1nZHoBq Bv5M44LWypSFXfGLeFoQqd8YLyvxhyJNScxKuXkwST2yG5tHYNpM1CBtIO76UwO9wMZB g/GQ== X-Gm-Message-State: AE9vXwNqsHfe40GdCZ6XwnHHwfNSHZE+8FY0jPMXviCXruxWGZjishmHIB0z+ZEaOd//CNeH X-Received: by 10.28.92.82 with SMTP id q79mr907024wmb.113.1474528862401; Thu, 22 Sep 2016 00:21:02 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id f15sm998465wmf.8.2016.09.22.00.21.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 00:21:01 -0700 (PDT) Subject: Re: lagg Interfaces - don't do Gratuitous ARP? To: Gleb Smirnoff , Ryan Stone References: <0D84203FAAFD0A8E7BBB24A3@10.12.30.106> <6E574F1B61786E6032824A88@10.12.30.106> <2c62f5f0-3fb4-f513-2a8f-02de3a1d552f@FreeBSD.org> <20160921235703.GG1018@cell.glebi.us> <20160922025856.GH1018@cell.glebi.us> Cc: Kubilay Kocak , freebsd-net , Karl Pielorz From: Steven Hartland Message-ID: <348d534d-ef87-f90c-aa43-cc65c2f6283c@multiplay.co.uk> Date: Thu, 22 Sep 2016 08:21:08 +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: <20160922025856.GH1018@cell.glebi.us> Content-Type: text/plain; charset=windows-1252; 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:21:04 -0000 On 22/09/2016 03:58, Gleb Smirnoff wrote: > On Wed, Sep 21, 2016 at 09:12:11PM -0400, Ryan Stone wrote: > R> > IMHO, the original patch was absolutely evil hack touching multiple > R> > layers, for the sake of a very special problem. > R> > > R> > I think, that in order to kick forwarding table on switches, lagg > R> > should: > R> > > R> > - allocate an mbuf itself > R> > - set its source hardware address to its own > R> > - set destination hardware to broadcast > R> > - put some payload in there, to make packet of valid size. Why should it be > R> > gratuitous ARP? A machine can be running IPv6 only, or may even use > R> > whatever > R> > higher level protocol, e.g. PPPoE. We shouldn't involve IP into this > R> > Layer 2 > R> > problem at all. > R> > - Finally, send the prepared mbuf down the lagg member(s). > R> > > R> > And please don't hack half of the network stack to achieve that :) > R> > R> The original report in this thread is about a system where it takes almost > R> 15 minutes for the network to start working again after a failover. That > R> does not sound to me like a switch problem. That sounds to me like the ARP > R> cache on the remote system. To fix such a case we have to touch L3. > > Does lagg(4) hardware address change when it failovers? > It moves the address between interfaces which typically moves it between switches too.