Red Hat Bugzilla – Bug 1225359
bonding: fail to configure master mac address by initscripts
Last modified: 2016-05-10 18:23:25 EDT
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:
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.
I've reproduced this locally in a VM, looking into the cause.
(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.
(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.
Patch submitted upstream to fix this: http://marc.info/?l=linux-kernel&m=143354307910123&w=2
(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...
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.
*** Bug 1252524 has been marked as a duplicate of this bug. ***
Patch(es) available on kernel-2.6.32-580.el6
Verified on- kernel-2.6.32-604.el6.x86_64 Beaker Job link- https://beaker.engineering.redhat.com/jobs/1214867
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