Bug 874030 - Bond mode changing through ifcfg changes has no effect.
Summary: Bond mode changing through ifcfg changes has no effect.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-07 10:34 UTC by Antoni Segura Puimedon
Modified: 2018-12-01 14:47 UTC (History)
7 users (show)

Fixed In Version: initscripts-9.03.33-1
Doc Type: Bug Fix
Doc Text:
Cause: BONDING_OPTS were not applied during if_up of master. Consequence: BONDING_OPTS were not applied. Fix: Set BONDING_OPTS in ifup for master. Result: BONDING_OPTS are applied.
Clone Of:
Environment:
Last Closed: 2013-02-21 10:26:22 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0518 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2013-02-20 21:29:01 UTC

Description Antoni Segura Puimedon 2012-11-07 10:34:49 UTC
Description of problem:
initscripts-9.03.32-1.el6 introduce a change in behavior that makes it impossible to change the bonding mode of an existing bond. In the yum changelog of the initscripts package I can see that in Oct. 8th, entry by Lukáš Nykrýn, there is one line that states:
- sets BONDING_OPTS before interface is brougth up and checks if it is not already added

I have not looked at the code, but it might be that the commit that resulted in this message is the cause of the issue.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create an ifcfg file for a bond with mode 4, e.g., ifcfg-bond10
DEVICE=bond10
BONDING_OPTS="mode=4 miimon=500"
BOOTPROTO=none
ONBOOT=yes
NM_CONTROLLED=no
2. ifup bond10
3. cat /sys/class/net/bond10/bonding/mode to see that mode is effectively 4
4. Change ifcfg-bond10
-BONDING_OPTS="mode=4 miimon=500"
+BONDING_OPTS="mode=2 miimon=500"
5. ifdown bond10
6. ifup bond10
  
Actual results:
cat /sys/class/net/bond10/bonding/mode
will show the mode to be 4.

Expected results:
cat /sys/class/net/bond10/bonding/mode
should show the mode to be 2.

Additional info:

Comment 3 Lukáš Nykrýn 2012-11-07 13:08:10 UTC
Can you please try following patch?


diff --git a/sysconfig/network-scripts/ifup-eth b/sysconfig/network-scripts/ifup-eth
index 5ef3055..7dc9fc6 100755
--- a/sysconfig/network-scripts/ifup-eth
+++ b/sysconfig/network-scripts/ifup-eth
@@ -120,6 +120,7 @@ fi
 if [ "$ISALIAS" = no ] && is_bonding_device ${DEVICE} ; then
     /sbin/ip link set dev ${DEVICE} up
     [ -n "${LINKDELAY}" ] && /bin/sleep ${LINKDELAY}
+    install_bonding_driver ${DEVICE}
     for device in $(LANG=C egrep -l "^[[:space:]]*MASTER=\"?${DEVICE}\"?[[:space:]]*$" /etc/sysconfig/network-scripts/ifcfg-*) ; do
            is_ignored_file "$device" && continue
            /sbin/ifup ${device##*/}

Comment 4 Antoni Segura Puimedon 2012-11-07 13:34:02 UTC
Unfortunately that does not fix it.

Comment 5 Antoni Segura Puimedon 2012-11-07 14:10:11 UTC
Maybe it's nonsense, but if I apply the patch proposed in comment #3 and modify in network-functions method install_bonding_driver to remove the following line:

ethtool -i $1 2>/dev/null | grep -q "driver: bonding" && return 0

Then it works.

This line, in previous versions was in the context of a method that was only creating the bond by echoing +bond to bonding masters, but now it also has the responsibility of setting the options. Since, as far as I can see, the only use it had was to avoid doing the bond creation, but now there is already the following:

if ! grep -sq "$1" /sys/class/net/bonding_masters; then
       echo "+$1" > /sys/class/net/bonding_masters 2>/dev/null
fi

That wasn't there before. I propose to drop the ethtool line.

Comment 12 errata-xmlrpc 2013-02-21 10:26:22 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.

http://rhn.redhat.com/errata/RHBA-2013-0518.html


Note You need to log in before you can comment on or make changes to this bug.