From owner-freebsd-net@freebsd.org Thu Sep 22 15:34:07 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 9CCC8BE5B34 for ; Thu, 22 Sep 2016 15:34:07 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 20F63B75 for ; Thu, 22 Sep 2016 15:34:07 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by mail-wm0-x22b.google.com with SMTP id b130so154985584wmc.0 for ; Thu, 22 Sep 2016 08:34:07 -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=TeryOZlWcySRiyWiS+4SfjKW7ccvVLxICspmy3ZGJb0=; b=rgXnbFDSl2w/jiWUw/RVGUFjSIezDITrs66GfCy56dNHzdFOVZhL7NviygjYxlbT37 MsXMR5Anfcw6CfJVKqWMkzdaqFtl1CemP8KGF4m3uo9kJOR3ge5tsojQtwaTXQ5zJipX wXB2cFKLLwIT0r7Q8drz1PgZADxFMf6aD9BelNDcpwAMIzXFo1fXcH3ZWRDvCbfOIF+7 AD9yBtJyo5egwGFXkMz/hwul3dQ8YpAsQwAfSE5kmRWVGN0jXzABJsQ5qVvvOWXiOG7W lubhB2z9OSR2fgnPbu5cUeqzhUourWXpQPDMkKXm8+LSZPeRJZTMqjMdc/gmGT8tiTT4 onTg== 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=TeryOZlWcySRiyWiS+4SfjKW7ccvVLxICspmy3ZGJb0=; b=drmsMF9HxEnuOXiE3LbD1EqhWHGHehr+d/FEJNMDhEyb7ZIFmjS9DCXZHAyN9Mmcb7 2/RIvGXBmW3yxANyb0a46owaQoDWnubgg1Nf5KEsFVK9LR29GRT+smaGDQW2wwBeGwn1 QUbsDuX4rNgOQqmpmF+Dir8NWs/sKhJ4aoWud/E4NWmWbxJMfh2gdFBufve950K1cDxA gvolvFAXO7YCz2ZajP6I3bctSLjV3bn66SLOj8KdNtXTx6rUM7wDCmmGyCAhAn4GYjHK OcQhC8Sg1P2616eTpUN/ddGVKl8JP9z6hWoVySbvfPOdw8zO38CU52jojBb5IbxVyRR6 oV7g== X-Gm-Message-State: AE9vXwNTz2/MxD5x1H09u7p2miWK1F4CkedicE0qO9iEYtG8LKwU6MvAU/qALB+fIXhbaGqV X-Received: by 10.194.216.233 with SMTP id ot9mr2688118wjc.166.1474558445066; Thu, 22 Sep 2016 08:34:05 -0700 (PDT) Received: from [10.10.1.58] (liv3d.labs.multiplay.co.uk. [82.69.141.171]) by smtp.gmail.com with ESMTPSA id n7sm3037732wmf.18.2016.09.22.08.34.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Sep 2016 08:34:04 -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> Cc: Ryan Stone , Kubilay Kocak , freebsd-net , Karl Pielorz From: Steven Hartland Message-ID: Date: Thu, 22 Sep 2016 16:34:03 +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: <20160922150940.GK1018@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:34:07 -0000 On 22/09/2016 16:09, Gleb Smirnoff wrote: > 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. > That would be nice but unfortunately in the wild that won't work as without GARP devices can and do ignore :( Regards Steve