From owner-freebsd-net@freebsd.org Thu Sep 22 16:08: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 E5B44BE5359 for ; Thu, 22 Sep 2016 16:08: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 C27AB1C2; Thu, 22 Sep 2016 16:08: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 u8MG8fKD020237 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Sep 2016 09:08:41 -0700 (PDT) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebi.us (8.15.2/8.15.2/Submit) id u8MG8fhd020236; Thu, 22 Sep 2016 09:08: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 09:08: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: <20160922160840.GP1018@cell.glebi.us> References: <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> <20160922154144.GO1018@cell.glebi.us> <0c678da4-bf72-5a81-aee1-d82a873661b7@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c678da4-bf72-5a81-aee1-d82a873661b7@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 16:08:43 -0000 On Thu, Sep 22, 2016 at 04:52:35PM +0100, Steven Hartland wrote: S> > S> > S> > Does lagg(4) hardware address change when it failovers? S> > S> > S> > S> > S> > S> It moves the address between interfaces which typically moves it between S> > S> > S> switches too. S> > S> > S> > S> > So, the address doesn't change, which means ARP cache doesn't need to S> > S> > change as well. If it moves between switches, all that needs to be done S> > S> > is to send whatever packet from proper hardware address to broadcast. S> > S> > S> > S> That would be nice but unfortunately in the wild that won't work as S> > S> without GARP devices can and do ignore :( S> > S> > You can create a fake gratious ARP packet, if you want. Switches must not S> > require IP addresses matching the reality in the packet. S> > S> > P.S. I always read GARP as Generic Attribute Registration Protocol. S> > S> We could but then what happens when its IPv6 or $other protocol that S> needs to know? That would require lagg to be edited with all the special S> cases instead of allowing the protocol to handle it they way it needs. You just said that "without GARP devices can and do ignore", didn't you? Let's take this as truth, although I doubt. So, if this is the truth, that means that if you are running IPv6 only, the switches won't recondigure theirselves due to lack of gratious ARP. Other protocols, where PPPoE is good example simply doesn't have any analogs of ARP or ND. So what would your switches do in that case? And what other layers are you going to hack, if you are going to run PPPoE service with lagg failover? In reality, a layer 2 device must forward layer 2 traffic, and must reconfigure its forwarding table based on source addresses seen on ports. And that's what all devices I've seen do. So what if we actually try the approach, I suggested? I can write the patch for you if you want. S> Overall, while the proposed change (https://reviews.freebsd.org/D4111) S> does involve changes to multiple layers it still feels like the right S> approach as it has the right layer dealing with the change instead of S> hard-coded assumptions. Sorry, it doesn't feel like the right approach. :( -- Totus tuus, Glebius.