Re: bonding: link state question

Jonathan Toppins [off-list ref] wrote:

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

	I'm going to speculate that your problem is that miimon and
arp_interval are both 0, and the bond then doesn't have any active
mechanism to monitor the link state of its interfaces.  There might be a
warning in dmesg to this effect.

	Do you see what you'd consider to be correct behavior if miimon
is set to 100?

	-J
	

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

---
	-Jay Vosburgh, jay.vosburgh@canonical.com