From owner-freebsd-net@freebsd.org Thu Sep 22 15:41:46 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 CFAC7BE616F for ; Thu, 22 Sep 2016 15:41:46 +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 ABC631111; Thu, 22 Sep 2016 15:41:45 +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 u8MFfi8s020086 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Sep 2016 08:41:44 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u8MFfiUT020085; Thu, 22 Sep 2016 08:41:44 -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:41:44 -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: <20160922154144.GO1018@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> <20160922150940.GK1018@cell.glebi.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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:41:46 -0000 On Thu, Sep 22, 2016 at 04:34:03PM +0100, Steven Hartland wrote: S> On 22/09/2016 16:09, Gleb Smirnoff wrote: S> > On Thu, Sep 22, 2016 at 08:21:08AM +0100, Steven Hartland wrote: S> > S> On 22/09/2016 03:58, Gleb Smirnoff wrote: S> > S> > On Wed, Sep 21, 2016 at 09:12:11PM -0400, Ryan Stone wrote: S> > S> > R> > IMHO, the original patch was absolutely evil hack touching multiple S> > S> > R> > layers, for the sake of a very special problem. S> > S> > R> > S> > S> > R> > I think, that in order to kick forwarding table on switches, lagg S> > S> > R> > should: S> > S> > R> > S> > S> > R> > - allocate an mbuf itself S> > S> > R> > - set its source hardware address to its own S> > S> > R> > - set destination hardware to broadcast S> > S> > R> > - put some payload in there, to make packet of valid size. Why should it be S> > S> > R> > gratuitous ARP? A machine can be running IPv6 only, or may even use S> > S> > R> > whatever S> > S> > R> > higher level protocol, e.g. PPPoE. We shouldn't involve IP into this S> > S> > R> > Layer 2 S> > S> > R> > problem at all. S> > S> > R> > - Finally, send the prepared mbuf down the lagg member(s). S> > S> > R> > S> > S> > R> > And please don't hack half of the network stack to achieve that :) S> > S> > R> S> > S> > R> The original report in this thread is about a system where it takes almost S> > S> > R> 15 minutes for the network to start working again after a failover. That S> > S> > R> does not sound to me like a switch problem. That sounds to me like the ARP S> > S> > R> cache on the remote system. To fix such a case we have to touch L3. S> > S> > S> > S> > Does lagg(4) hardware address change when it failovers? S> > S> > S> > S> It moves the address between interfaces which typically moves it between S> > S> switches too. S> > S> > So, the address doesn't change, which means ARP cache doesn't need to S> > change as well. If it moves between switches, all that needs to be done S> > is to send whatever packet from proper hardware address to broadcast. S> > S> That would be nice but unfortunately in the wild that won't work as S> without GARP devices can and do ignore :( You can create a fake gratious ARP packet, if you want. Switches must not require IP addresses matching the reality in the packet. P.S. I always read GARP as Generic Attribute Registration Protocol. -- Totus tuus, Glebius.