From owner-freebsd-net@freebsd.org Thu Sep 22 01:12:12 2016 Return-Path: <owner-freebsd-net@freebsd.org> 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 78195BE4E8A for <freebsd-net@mailman.ysv.freebsd.org>; Thu, 22 Sep 2016 01:12:12 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 40233173; Thu, 22 Sep 2016 01:12:12 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-it0-x22b.google.com with SMTP id n143so67665356ita.1; Wed, 21 Sep 2016 18:12:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e5yhPwI+Hdol2nfZnNCllB8DrnX/BHURDWyvZlgctXE=; b=Nx0ZyuN+kTwk5j8ilKszMIaWDaoNCji2mbwLa44rUzxl1WnzoOpKTUozhJPDh9G0jp DbvMX1XYTSV053AhzMP+RUbU78GYGT+mSLqcEyRT9KY4jwmd2Tq7fYrC0UlkxmHdsyDv bZ9rMwBINOKn3hmo0PqWurmJ4FHsP5p+Z/7Wpdbm/CvmfS2uQt0DzkqXRFvFvTanhH8m dt48aQK18qHJEFmYFqk97X/8CrpBL5OvfUZWGC3qikIdC0lJU0ynV/lkmNY2wYed3SGn c4fJhiZjTOjoeMQmApjuHof5Zxr/Ps72TWI8xXzRtBsZF6zLyeqnYoThdZDlkkyJPnA9 KEIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e5yhPwI+Hdol2nfZnNCllB8DrnX/BHURDWyvZlgctXE=; b=T3aL3wODqYVutovp3wHLeflcNr+3nGq76nauHbEaX10jh9+S+5vm9ZExAPgTN3Fbt+ WusH+b5ubAYa0jsoSK4t2z1R/VavADoF/wiQ5IvJKzx9sNKOpF2iT+DdSPZ6nwP4nlXi waejBsPBmj3t7mEqVb8nPyUo6ysbsipT3+DJtXeO2G5GrytFxknDgWFB0Kp96AMEBdmE GX80BqGQCT9uU9okweb0pc3MEIMlNyk1Tk0Js+DEwQVTOyw1F5Z4WI9gdHIciIwT+irl v/5WOu0EeH+qnwk+F5Te178lRPkeCeRrpaMXg2fFIMGOh4QqtFa36CdGj6H/0k1JsKon cDiQ== X-Gm-Message-State: AE9vXwOZZgwmk174k6esnJRHXymFusg5yOfKZPIe9xSp/D+fOywNUpLlLmtsRUiTGPamsu5FctoNLsX1PeP6wQ== X-Received: by 10.36.254.140 with SMTP id w134mr7366145ith.108.1474506731631; Wed, 21 Sep 2016 18:12:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.78 with HTTP; Wed, 21 Sep 2016 18:12:11 -0700 (PDT) In-Reply-To: <20160921235703.GG1018@cell.glebi.us> References: <0D84203FAAFD0A8E7BBB24A3@10.12.30.106> <bc33560b-59bc-01be-6a5d-7994ac121258@multiplay.co.uk> <6E574F1B61786E6032824A88@10.12.30.106> <2c62f5f0-3fb4-f513-2a8f-02de3a1d552f@FreeBSD.org> <20160921235703.GG1018@cell.glebi.us> From: Ryan Stone <rysto32@gmail.com> Date: Wed, 21 Sep 2016 21:12:11 -0400 Message-ID: <CAFMmRNwZBEJ9Me4FSh=W7fRNjm4344jiUGuJqX8KUB_0sWcajA@mail.gmail.com> Subject: Re: lagg Interfaces - don't do Gratuitous ARP? To: Gleb Smirnoff <glebius@freebsd.org> Cc: Kubilay Kocak <koobs@freebsd.org>, freebsd-net <freebsd-net@freebsd.org>, Karl Pielorz <kpielorz_lst@tdx.co.uk>, Steven Hartland <killing@multiplay.co.uk> Content-Type: text/plain; charset=UTF-8 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 <freebsd-net.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net/> List-Post: <mailto:freebsd-net@freebsd.org> List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-net>, <mailto:freebsd-net-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 22 Sep 2016 01:12:12 -0000 On Wed, Sep 21, 2016 at 7:57 PM, Gleb Smirnoff <glebius@freebsd.org> wrote: > IMHO, the original patch was absolutely evil hack touching multiple > layers, for the sake of a very special problem. > > I think, that in order to kick forwarding table on switches, lagg > should: > > - allocate an mbuf itself > - set its source hardware address to its own > - set destination hardware to broadcast > - put some payload in there, to make packet of valid size. Why should it be > gratuitous ARP? A machine can be running IPv6 only, or may even use > whatever > higher level protocol, e.g. PPPoE. We shouldn't involve IP into this > Layer 2 > problem at all. > - Finally, send the prepared mbuf down the lagg member(s). > > And please don't hack half of the network stack to achieve that :) > The original report in this thread is about a system where it takes almost 15 minutes for the network to start working again after a failover. That does not sound to me like a switch problem. That sounds to me like the ARP cache on the remote system. To fix such a case we have to touch L3.