From owner-freebsd-net@freebsd.org Thu Sep 22 15:52:39 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 5DCC3BE67B8 for ; Thu, 22 Sep 2016 15:52:39 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 D373A1730 for ; Thu, 22 Sep 2016 15:52:38 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22d.google.com with SMTP id b130so155909139wmc.0 for ; Thu, 22 Sep 2016 08:52:38 -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=ragNIBMDQyFQ/vCz77ho5q1arZgcWq0xbgmmSNY2xhc=; b=i+oV6COmJ1cj/c8+8K7KG5nFAP/AOcXGPXHLsheR61E5fY0C5gCVlq0lvO4Lbbvcq+ g3gselXxUcYZIpRXtBOQFFpUrDH20w7dKxZDU0GKAMxy1is4EguSizIrBJzzCZd2z9n1 QFKcBtkkXHJ231UbzwXs2dieSv549peHESKaZBHu56veYF52fu0Cpt3/JL+0K9g5Pfp4 P80SANk++qs/ox/CGYURWj8ceLTaqEi8Fz9ywpg8FUgqHpaRs8Cp7RznLaVMqasoBLO1 SXSVULWQIhclDk+lu7cfKmlZzSmY6lt+N6UHE1y/3jLewmc4hJCsMq7xJGKm65xQtgpQ +yIw== 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=ragNIBMDQyFQ/vCz77ho5q1arZgcWq0xbgmmSNY2xhc=; b=DWI0FahGyZSala0OK/jsK3FwJPEYNNie6gmiNrMbk+f+HE1Ow2W44fwsPXUe6HlXyV KidzzcqIwQQLH0Uw9R40kTjpYPsoMHmg6szmU4jK6oc+cuyGZBhxRvm4QAyAeml0ixD1 UwcbxwOrx8rtGr092b1kd8n6efev6BfkzIy7weAAtmFv4/X2E/ki9InIvncnMOpRRvwW CKWwTVrNldeGtlwRq2svHr5JVHlV1cMxOl22SoGr2Rw/LSAUkZ/We9O+VuUBa8g92KQH hycnIYqap4VPVltATZyCMFFAOgBtFpGkYXlKb37yp6GOzDpaL1KbosChMOey6714z/3A OfKw== X-Gm-Message-State: AE9vXwN4cv+GkdsbrIIMcjDmWztWLi4rzY3VvdqJqKZHpJLr04wO1+2/B1z3A3i+Ph0+SGUk X-Received: by 10.194.148.145 with SMTP id ts17mr2681581wjb.91.1474559556986; Thu, 22 Sep 2016 08:52:36 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id t202sm38220616wmt.22.2016.09.22.08.52.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 08:52:36 -0700 (PDT) Subject: Re: lagg Interfaces - don't do Gratuitous ARP? To: 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> <20160922025856.GH1018@cell.glebi.us> <348d534d-ef87-f90c-aa43-cc65c2f6283c@multiplay.co.uk> <20160922150940.GK1018@cell.glebi.us> <20160922154144.GO1018@cell.glebi.us> Cc: Ryan Stone , Kubilay Kocak , freebsd-net , Karl Pielorz From: Steven Hartland Message-ID: <0c678da4-bf72-5a81-aee1-d82a873661b7@multiplay.co.uk> Date: Thu, 22 Sep 2016 16:52:35 +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: <20160922154144.GO1018@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 15:52:39 -0000 On 22/09/2016 16:41, Gleb Smirnoff wrote: > 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. > We could but then what happens when its IPv6 or $other protocol that needs to know? That would require lagg to be edited with all the special cases instead of allowing the protocol to handle it they way it needs. Overall, while the proposed change (https://reviews.freebsd.org/D4111) does involve changes to multiple layers it still feels like the right approach as it has the right layer dealing with the change instead of hard-coded assumptions. Regards Steve