Bug 1802424

Summary: Got failure when activating bond with fail_over_mac=1 option.
Product: Red Hat Enterprise Linux 8 Reporter: Gris Ge <fge>
Component: NetworkManagerAssignee: Beniamino Galvani <bgalvani>
Status: CLOSED NOTABUG QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 8.2CC: acardace, atragler, bgalvani, lrintel, mburman, rkhan, sukulkar, thaller, till
Target Milestone: rc   
Target Release: 8.2   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-21 06:15:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1738136, 1801798    
Attachments:
Description Flags
bug.yml none

Description Gris Ge 2020-02-13 06:02:24 UTC
Created attachment 1662876 [details]
bug.yml

Description of problem:

When reactivating an existing bond with fail_over_mac=1 option, activation
failed with:

2020-02-13 14:00:35,923 root         ERROR    NM main-loop aborted: Connection activation failed on bond99: reason=<enum NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_DISCONNECTED of type NM.ActiveConnectionStateReason>


Version-Release number of selected component (if applicable):
nmstate-0.2.3-1.el8
NetworkManager-1.22.7-24673.3a43575539.el8.x86_64

How reproducible:
100%

Steps to Reproduce:
1. sudo nmstatectl set bug.yml  # This command will pass without failure
2. sudo nmstatectl set bug.yml  # This command will fail
3.

Actual results:

Failure

Expected results:

No failure

Additional info:

Comment 1 Beniamino Galvani 2020-02-14 09:38:41 UTC
(In reply to Gris Ge from comment #0)

> Steps to Reproduce:
> 1. sudo nmstatectl set bug.yml  # This command will pass without failure
> 2. sudo nmstatectl set bug.yml  # This command will fail

Hi,

on the first command, the bond is added without any cloned MAC address. On the second time nmstate sets a cloned MAC on the bond:

 ++ connection 'update connection' (0x7f07cc001560/NMSimpleConnection/"bond" < 0x278caa0/NMSimpleConnection/"bond") [/org/freedesktop/NetworkManager/Settings/8]:
 ++ 802-3-ethernet            [ 0x27c50c0 < *missing* ]
 ++ 802-3-ethernet.cloned-mac-address = '0A:CB:9C:97:03:03'
 ++ 802-3-ethernet.mac-address-blacklist = []
 ++ 802-3-ethernet.mtu        = 1500
 ++ 802-3-ethernet.s390-options = ((GHashTable*) 0x2717240)
 audit: op="connection-update" uuid="7294931c-1cf0-4efe-8830-b2989798c008" name="bond99" args="802-3-ethernet.s390-options,802-3-ethernet.mac-address-blacklist,802-3-ethernet.cloned-mac-address,802-3-ethernet.mtu,ipv4.dhcp-client-id,ipv6.dhcp-duid,ipv6.addr-gen-mode,ipv6.dhcp-iaid" pid=32619 uid=0 result="success"

The kernel doesn't allow changing the MAC for bonds that have the fail_over_mac=1 option (because in that case the MAC is taken from the active slave) and thus the activation fails.

 # ip link del bond1
 # ip link add bond1 type bond
 # echo active-backup > /sys/class/net/bond1/bonding/mode
 # echo 1 >             /sys/class/net/bond1/bonding/fail_over_mac
 # ip link set bond1 address 00:99:88:77:66:55
 # ip link show bond1
   30603: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
      link/ether ce:1a:97:23:37:c5 brd ff:ff:ff:ff:ff:ff

Why is nmstate setting a cloned MAC on the bond the second time?

Comment 2 Gris Ge 2020-02-19 12:08:17 UTC
Hi Beniamino,

On the initial set, nmstate does not know the MAC address, so it does not have ethernet/wire section in the connection profile.

On the second set, nmstate will merge desire state with current state which has a MAC address of first slave.


I guess I should ignore that MAC address when `fail_over_mac=1` presents.

Is there any other bond option has the limitation on MAC address changing?

Comment 3 Beniamino Galvani 2020-02-19 16:51:49 UTC
(In reply to Gris Ge from comment #2)
> I guess I should ignore that MAC address when `fail_over_mac=1` presents.
> 
> Is there any other bond option has the limitation on MAC address changing?

From what I see in kernel sources, the only bond configuration that has this limitation is:

  (mode == ACTIVEBACKUP) && (fail_over_mac == 1)

Comment 4 Gris Ge 2020-02-21 06:15:22 UTC
Thanks for the information.

Closing as not a bug. Nmstate will fix their part.