Re: bonding: link state question

[Jay Vosburgh]

Jonathan Toppins <jtoppins@xxxxxxxxxx> 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@xxxxxxxxxxxxx