From owner-freebsd-net@freebsd.org Thu Sep 22 15:09:42 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 B8D0ABE5E56 for ; Thu, 22 Sep 2016 15:09:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (glebi.us [96.95.210.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "cell.glebi.us", Issuer "cell.glebi.us" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8559093D; Thu, 22 Sep 2016 15:09:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebi.us (localhost [127.0.0.1]) by cell.glebi.us (8.15.2/8.15.2) with ESMTPS id u8MF9fTY019879 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Sep 2016 08:09:41 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u8MF9f9C019878; Thu, 22 Sep 2016 08:09:41 -0700 (PDT) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebi.us: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 22 Sep 2016 08:09:40 -0700 From: Gleb Smirnoff To: Steven Hartland Cc: Ryan Stone , Kubilay Kocak , freebsd-net , Karl Pielorz Subject: Re: lagg Interfaces - don't do Gratuitous ARP? Message-ID: <20160922150940.GK1018@cell.glebi.us> 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> <348d534d-ef87-f90c-aa43-cc65c2f6283c@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <348d534d-ef87-f90c-aa43-cc65c2f6283c@multiplay.co.uk> User-Agent: Mutt/1.6.1 (2016-04-27) 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 15:09:42 -0000 On Thu, Sep 22, 2016 at 08:21:08AM +0100, Steven Hartland wrote: S> On 22/09/2016 03:58, Gleb Smirnoff wrote: S> > On Wed, Sep 21, 2016 at 09:12:11PM -0400, Ryan Stone wrote: S> > R> > IMHO, the original patch was absolutely evil hack touching multiple S> > R> > layers, for the sake of a very special problem. S> > R> > S> > R> > I think, that in order to kick forwarding table on switches, lagg S> > R> > should: S> > R> > S> > R> > - allocate an mbuf itself S> > R> > - set its source hardware address to its own S> > R> > - set destination hardware to broadcast S> > R> > - put some payload in there, to make packet of valid size. Why should it be S> > R> > gratuitous ARP? A machine can be running IPv6 only, or may even use S> > R> > whatever S> > R> > higher level protocol, e.g. PPPoE. We shouldn't involve IP into this S> > R> > Layer 2 S> > R> > problem at all. S> > R> > - Finally, send the prepared mbuf down the lagg member(s). S> > R> > S> > R> > And please don't hack half of the network stack to achieve that :) S> > R> S> > R> The original report in this thread is about a system where it takes almost S> > R> 15 minutes for the network to start working again after a failover. That S> > R> does not sound to me like a switch problem. That sounds to me like the ARP S> > R> cache on the remote system. To fix such a case we have to touch L3. S> > S> > Does lagg(4) hardware address change when it failovers? S> > S> It moves the address between interfaces which typically moves it between S> switches too. So, the address doesn't change, which means ARP cache doesn't need to change as well. If it moves between switches, all that needs to be done is to send whatever packet from proper hardware address to broadcast. -- Totus tuus, Glebius.