Bug 1225359

Summary: bonding: fail to configure master mac address by initscripts
Product: Red Hat Enterprise Linux 6 Reporter: Zhenjie Chen <zhchen>
Component: kernelAssignee: Jarod Wilson <jarod>
kernel sub component: Bonding QA Contact: Amit Supugade <asupugad>
Status: CLOSED ERRATA Docs Contact: Jana Heves <jsvarova>
Severity: high    
Priority: urgent CC: aiyengar, dhoward, jsvarova, kzhang, mabrown, network-qe, pbokoc, peterm, ptalbert, tez, tlavigne, yanwang, zshi
Version: 6.7Keywords: Regression, ZStream
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: kernel-2.6.32-580.el6 Doc Type: Bug Fix
Doc Text:
Custom MAC addresses can be specified again for bond interfaces On a system with a bonded interface, the user could not specify their own custom MAC address for the bond. A patch has been provided to fix this bug, and custom MAC addresses can be specified again in the aforementioned situation.
Story Points: ---
Clone Of:
: 1228772 1266374 (view as bug list) Environment:
Last Closed: 2016-05-10 22:23:25 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: 1228772, 1266374, 1269638    

Description Zhenjie Chen 2015-05-27 08:12:41 UTC
Description of problem:
QE found bz905126 re-occurred on RHEL6.7, it's a regression.

Version-Release number of selected component (if applicable):
2.6.32-562.el6.x86_64

How reproducible:
always

Steps to Reproduce:

[root@hp-dl388g8-14 network-scripts]# cat ifcfg-bond0 
DEVICE=bond0
NAME=bond0
ONBOOT=no
BOOTPROTO="none"
BONDING_MASTER="yes"
BONDING_OPTS="mode=1 miimon=100"
MACADDR=22:33:44:55:66:77

[root@hp-dl388g8-14 network-scripts]# cat ifcfg-eth6
DEVICE=eth6
HWADDR=00:1B:21:85:84:02
TYPE=Ethernet
UUID=6dbd0452-c567-4d62-83f9-c74ad001a08b
ONBOOT=no
NM_CONTROLLED=yes
BOOTPROTO=dhcp
MASTER=bond0
SLAVE=yes


Actual results:

[root@hp-dl388g8-14 network-scripts]# hostname 
hp-dl388g8-14.rhts.eng.nay.redhat.com

[root@hp-dl388g8-14 network-scripts]# uname -r
2.6.32-562.el6.x86_64

[root@hp-dl388g8-14 network-scripts]# ifup bond0
[root@hp-dl388g8-14 network-scripts]# ifconfig bond0
bond0     Link encap:Ethernet  HWaddr 00:1B:21:85:84:02  
          inet6 addr: fe80::21b:21ff:fe85:8402/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:111 errors:0 dropped:0 overruns:0 frame:0
          TX packets:26 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:18132 (17.7 KiB)  TX bytes:3848 (3.7 KiB)

[root@hp-dl388g8-14 network-scripts]# ifconfig eth6
eth6      Link encap:Ethernet  HWaddr 00:1B:21:85:84:02  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:226 errors:0 dropped:0 overruns:0 frame:0
          TX packets:48 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:30985 (30.2 KiB)  TX bytes:9192 (8.9 KiB)
          Memory:fbb80000-fbbfffff 


Expected results:

[root@hp-dl388g8-14 ~]# uname -r
2.6.32-504.el6.x86_64
[root@hp-dl388g8-14 ~]# ifup bond0
[root@hp-dl388g8-14 ~]# ifconfig bond0
bond0     Link encap:Ethernet  HWaddr 22:33:44:55:66:77  
          inet6 addr: fe80::2033:44ff:fe55:6677/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:238 (238.0 b)

[root@hp-dl388g8-14 ~]# ifconfig eth6
eth6      Link encap:Ethernet  HWaddr 22:33:44:55:66:77  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:308 (308.0 b)
          Memory:fbb80000-fbbfffff 


Additional info:

Comment 5 Jarod Wilson 2015-06-02 20:14:10 UTC
We're quite late in the game for 6.7, and since this isn't causing a panic or network outage, we should be able to fix this early in 6.8 and backport it to 6.7 z-stream.

Comment 6 Jarod Wilson 2015-06-03 13:12:27 UTC
I've reproduced this locally in a VM, looking into the cause.

Comment 9 Jarod Wilson 2015-06-05 12:57:51 UTC
(In reply to Jarod Wilson from comment #6)
> I've reproduced this locally in a VM, looking into the cause.

And now I've figured out a fix. I need to test with current upstream, but I think this is broken upstream and probably in RHEL7 as well.

Comment 10 Jarod Wilson 2015-06-05 16:00:41 UTC
(In reply to Jarod Wilson from comment #9)
> (In reply to Jarod Wilson from comment #6)
> > I've reproduced this locally in a VM, looking into the cause.
> 
> And now I've figured out a fix. I need to test with current upstream, but I
> think this is broken upstream and probably in RHEL7 as well.

Yup, this is broken in a Fedora VM running kernel 4.0.4 as well. I'll get the same patch ready for upstream and RHEL7.

Comment 11 Jarod Wilson 2015-06-05 22:27:54 UTC
Patch submitted upstream to fix this:
  http://marc.info/?l=linux-kernel&m=143354307910123&w=2

Comment 12 Jarod Wilson 2015-06-09 00:53:10 UTC
(In reply to Jarod Wilson from comment #11)
> Patch submitted upstream to fix this:
>   http://marc.info/?l=linux-kernel&m=143354307910123&w=2

Okay, so, now, for the life of me, I can't re-reproduce this upstream, I think what I thought was an upstream reproducer was just nmcli failing to respect a user-set mac address. Its definitely broken here in RHEL6, but I may only have to backport the appropriate upstream patches, still tbd...

Comment 13 Jarod Wilson 2015-06-18 01:00:37 UTC
I tracked down the discrepancy with upstream, it was indeed a missing patch that alters rtnetlink.c:do_setlink() to call dev_set_mac_address() instead of ops->ndo_set_mac_address(), and in the dev_set_ version, there's a call to set addr_assign_type to NET_ADDR_SET that will be added by a second patch. Those two, and things behave in my local testing now.

Comment 15 Jarod Wilson 2015-08-11 21:03:06 UTC
*** Bug 1252524 has been marked as a duplicate of this bug. ***

Comment 20 Aristeu Rozanski 2015-09-25 20:33:44 UTC
Patch(es) available on kernel-2.6.32-580.el6

Comment 23 Amit Supugade 2016-02-08 17:30:32 UTC
Verified on- kernel-2.6.32-604.el6.x86_64

Beaker Job link- https://beaker.engineering.redhat.com/jobs/1214867

Comment 25 errata-xmlrpc 2016-05-10 22:23:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-0855.html