[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <de8d8ca4-4ead-0cef-1315-8764d93503c1@redhat.com>
Date: Tue, 17 May 2022 17:17:19 -0400
From: Jonathan Toppins <jtoppins@...hat.com>
To: "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc: Jay Vosburgh <j.vosburgh@...il.com>,
Veaceslav Falico <vfalico@...il.com>,
Andy Gospodarek <andy@...yhouse.net>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>
Subject: [question] bonding: should assert dormant for active protocols like
LACP?
So running the following script:
--%<-----
ip link add name link-bond0 type veth peer name link-end0
ip link add bond0 type bond mode 4 miimon 100
ip link set link-bond0 master bond0 down
ip netns add n1
ip link set link-end0 netns n1 up
ip link set bond0 up
cat /sys/class/net/bond0/bonding/ad_partner_mac
cat /sys/class/net/bond0/operstate
--%<-----
The bond reports its operstate to be "up" even though the bond will
never be able to establish an LACP partner. Should bonding for active
protocols, LACP, assert dormant[0] until the protocol has established
and frames actually are passed?
Having a predictable operstate where up actually means frames will
attempt to be delivered would make management applications, f.e. Network
Manager, easier to write. I have developers asking me what detailed
states for LACP should they be looking for to determine when an LACP
bond is "up". This seems like an incorrect implementation of operstate
and RFC2863 3.1.12.
Does anyone see why this would be a bad idea?
-Jon
[0] Documentation/networking/operstates.rst
Powered by blists - more mailing lists