From: Jonathan Toppins <jtoppins@redhat.com>
To: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Veaceslav Falico <vfalico@gmail.com>,
Jay Vosburgh <j.vosburgh@gmail.com>,
Andy Gospodarek <andy@greyhouse.net>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: bonding: link state question
Date: Sat, 7 Aug 2021 17:26:34 -0400 [thread overview]
Message-ID: <020577f3-763d-48fd-73ce-db38c3c7fdf9@redhat.com> (raw)
Is there any reason why bonding should have an operstate of up when none
of its slaves are in an up state? In this particular scenario it seems
like the bonding device should at least assert NO-CARRIER, thoughts?
$ ip -o -d link show | grep "bond5"
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc
fq_codel master bond5 state DOWN mode DEFAULT group default qlen 1000\
link/ether 8c:8c:aa:f8:62:16 brd ff:ff:ff:ff:ff:ff promiscuity 0
minmtu 68 maxmtu 9000 \ bond_slave state ACTIVE mii_status UP
link_failure_count 0 perm_hwaddr 8c:8c:aa:f8:62:16 queue_id 0
numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
41: bond5: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP mode DEFAULT group default qlen 1000\ link/ether
8c:8c:aa:f8:62:16 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu
65535 \ bond mode balance-xor miimon 0 updelay 0 downdelay 0
peer_notify_delay 0 use_carrier 1 arp_interval 0 arp_validate none
arp_all_targets any primary_reselect always fail_over_mac none
xmit_hash_policy layer2 resend_igmp 1 num_grat_arp 1 all_slaves_active 0
min_links 0 lp_interval 1 packets_per_slave 1 lacp_rate slow ad_select
stable tlb_dynamic_lb 1 numtxqueues 16 numrxqueues 16 gso_max_size 65536
gso_max_segs 65535
$ cat /sys/class/net/enp0s31f6/operstate
down
$ cat /sys/class/net/bond5/operstate
up
This is an older kernel (4.18.0-305.7.1.el8_4.x86_64) but I do not see
any changes upstream that would indicate a change in this operation.
Thanks,
-Jon
next reply other threads:[~2021-08-07 21:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-07 21:26 Jonathan Toppins [this message]
2021-08-07 22:42 ` Jay Vosburgh
2021-08-08 0:09 ` Jonathan Toppins
2021-08-08 4:49 ` Willy Tarreau
2021-08-09 1:31 ` Jonathan Toppins
2021-08-09 10:10 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=020577f3-763d-48fd-73ce-db38c3c7fdf9@redhat.com \
--to=jtoppins@redhat.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=j.vosburgh@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=vfalico@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®