Received: by 2002:a05:6a10:c604:0:0:0:0 with SMTP id y4csp1703442pxt; Sat, 7 Aug 2021 21:54:01 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwe2xzewbaCDBPONrkLrp5Bdd9bwv0FoR2vGvSVyBg7ek5Xi7ptSaKmV7fczVdnyYoIdlEA X-Received: by 2002:a02:c6c3:: with SMTP id r3mr17250473jan.7.1628398441700; Sat, 07 Aug 2021 21:54:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628398441; cv=none; d=google.com; s=arc-20160816; b=wxEyy4asVVJ763rYmeKYzdAKPsgb7a7JglM5jg/0WI/J8oMp19FMTjLi9LJ+9w46gu +lhHz25TfcKwi6ykpTpsNtYDkOPn1P66j+4KwnBMrZ4PqhR+6sRxs8m4Y+m3JY5RUYxP 6BamNTZDc814o7w+adG6X0mkGylcrpQ+5SrgkQ3C4avh4JZ8yKYny64hK5yIdieactP2 3IxYtCXm3J1/7SFdOJqiDzpAiWiQCahP3TARRa0nlDHbNrBtj8MjSBDU6SVUdRf9dL1P u/75W2uSres0j3qYvluylU0skje4vGC48iaWA6XfmOxz8nHZaoXEIrbLZJmxZKWwOaXb d+ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=m9hKhu9UbLq0WG7ZkB7CFADdx4bAHe0JhVElmiTzdjo=; b=uW0Jbri+K7j5RKYR8FG6jXnAseUTYcjFIwsaHV8afhjRG+Zxots57h8iGxRWat0/P8 7zSSRMQEvaPnT+QKnuHbtFzKGacT6h3aURHWLk6zFzhKmwjSk2oFA3GrX1cw9haJQxXp SelB4xVsP3j0Lq3SIPzpyUOG05+0E4AOtL55Ja8FLgFfQ8Et5bLUv6tWjUr7JyYPGgot wbfGzDRP7LBGV6bJnzD15TQwY20g2zR1brc4EtBZ+osGBDg9KR0J4I+kYVwhomy2zlYn A3jwR/++EaaNnJS9c/3+dYFyUV5OoePLesTpW2wlovH0WVUMm3ZVoireB7Cpe0kz1s6X 5K3A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x7si17687631ilu.63.2021.08.07.21.53.49; Sat, 07 Aug 2021 21:54:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229726AbhHHEtq (ORCPT + 99 others); Sun, 8 Aug 2021 00:49:46 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:34744 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbhHHEto (ORCPT ); Sun, 8 Aug 2021 00:49:44 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 1784nCFK010240; Sun, 8 Aug 2021 06:49:12 +0200 Date: Sun, 8 Aug 2021 06:49:12 +0200 From: Willy Tarreau To: Jonathan Toppins Cc: Jay Vosburgh , "netdev@vger.kernel.org" , Veaceslav Falico , Andy Gospodarek , "David S. Miller" , Jakub Kicinski , LKML Subject: Re: bonding: link state question Message-ID: <20210808044912.GA10092@1wt.eu> References: <020577f3-763d-48fd-73ce-db38c3c7fdf9@redhat.com> <22626.1628376134@famine> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Aug 07, 2021 at 08:09:31PM -0400, Jonathan Toppins wrote: > setting miimon = 100 does appear to fix it. > > It is interesting that there is no link monitor on by default. For example > when I enslave enp0s31f6 to a new bond with miimon == 0, enp0s31f6 starts > admin down and will never de-assert NO-CARRIER the bond always results in an > operstate of up. It seems like miimon = 100 should be the default since some > modes cannot use arpmon. Historically when miimon was implemented, not all NICs nor drivers had support for link state checking at all! In addition, there are certain deployments where you could rely on many devices by having a bond device on top of a vlan or similar device, and where monitoring could cost a lot of resources and you'd prefer to rely on external monitoring to set all of them up or down at once. I do think however that there remains a case with a missing state transition in the driver: on my laptop I have a bond interface attached to eth0, and I noticed that if I suspend the laptop with the link up, when I wake it up with no interface connected, the bond will not turn down, regardless of miimon. I have not looked closer yet, but I suspect that we're relying too much on a state change between previous and current and that one historically impossible transition does not exist there and/or used to work because it was handled as part of another change. I'll eventually have a look. Willy