Bug 463014

Summary: [PATCH] Fix for problem with bridged bonding interfaces
Product: Red Hat Enterprise Linux 5 Reporter: Sean E. Millichamp <sean>
Component: initscriptsAssignee: initscripts Maintenance Team <initscripts-maint-list>
Status: CLOSED ERRATA QA Contact: BaseOS QE <qe-baseos-auto>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.2CC: apevec, cward, djuran, ehabkost, emmanuel, harald, k.georgiou, markmc, matt, mvadkert, nenad, notting, ovirt-maint, schlegel, sputhenp, tao, tomek, wijata
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 11:13:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Patch to fix reported problem
none
New patch to fix the bridge ordering problem none

Description Sean E. Millichamp 2008-09-20 20:09:07 UTC
Created attachment 317291 [details]
Patch to fix reported problem

Description of problem:

The ordering in ifup-eth is wrong for bonding interfaces participating in a bridge.  A bonding device can't be added to a bridge until it has at least one slaved Ethernet interface added to it.  That is exactly what the script tries to do as written.  The attached patch just reorders the bonding initialization to be prior to the bridge-related operations.

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

How reproducible:

Every time.

Steps to Reproduce:
1. Configure interfaces with pertinent as follows:

ifcfg-eth0:
DEVICE=eth0
SLAVE=yes
MASTER=bond0

ifcfg-eth1:
DEVICE=eth1
SLAVE=yes
MASTER=bond0

ifcfg-bond0:
DEVICE=bond0
ONBOOT=yes
BONDING_OPTS='mode=1 miimon=100'
BRIDGE=brbond0

ifcfg-brbond0:
DEVICE=brbond0
TYPE=Bridge
IPADDR=192.168.0.1
NETMASK=255.255.255.0
ONBOOT=yes

2. Reboot the system and/or do a fresh start of networking.  Note that 'service networking stop' doesn't properly clean up back to a fresh-boot state, so a reboot of the system is the safest approach for testing.
  
Actual results:

# service network start
Bringing up loopback interface:  [  OK  ]
Bringing up interface bond0:  can't add bond0 to bridge brbond0: Invalid argument
[  OK  ]
Bringing up interface brbond0:  [  OK  ]

# brctl show
bridge name	bridge id		STP enabled	interfaces
brbond0		8000.000000000000	no	


Expected results:

bond0 should be a member of the brbond0 bridge

Additional info:

Patch to ifup-eth attached which fixes this in my testing.  It reorders the operations in ifup-eth to accommodate this scenario.

Comment 1 Sean E. Millichamp 2008-09-20 20:15:30 UTC
This time with a proper subject...

Comment 2 Bill Nottingham 2008-09-23 19:07:59 UTC
*** Bug 458502 has been marked as a duplicate of this bug. ***

Comment 3 Bill Nottingham 2008-09-23 19:13:19 UTC
Technically, I'd prefer a patch more like the one in bug 449950, as it keeps the hardware specific initialization (MTU, MACADDR, etc.) in order. But more or less correct.

Comment 4 Bill Nottingham 2008-09-23 19:14:31 UTC
*** Bug 193236 has been marked as a duplicate of this bug. ***

Comment 5 Sean E. Millichamp 2008-09-24 13:14:17 UTC
Fair enough.  The other nice thing about the order in the other patch is that by placing the bridge membership section after the hardware initialization then we actually can use MTU= to set the MTU of a bridged device.  My original patch had the MTU setting section after the bridge section exit 0'd from the script.  

I discovered the MTU problem after I opened this bug report but my fix was to remove the exit 0.  I like the reordering solution much better.

I am attaching a new patch in the style of the other one which should apply cleanly to the RHEL initscripts package.

Comment 6 Sean E. Millichamp 2008-09-24 13:15:07 UTC
Created attachment 317584 [details]
New patch to fix the bridge ordering problem

Comment 7 Bill Nottingham 2008-10-07 14:39:05 UTC
*** Bug 465794 has been marked as a duplicate of this bug. ***

Comment 8 Bill Nottingham 2008-10-07 14:41:22 UTC
*** Bug 465801 has been marked as a duplicate of this bug. ***

Comment 9 Matthew Kent 2008-11-28 00:42:55 UTC
+1, seeing this here. 

Patch does indeed correct the issue. Thanks for that.

Comment 10 Bill Nottingham 2008-12-04 18:58:07 UTC
*** Bug 474645 has been marked as a duplicate of this bug. ***

Comment 13 Harald Hoyer 2009-05-05 12:51:40 UTC
Please test the erratum candidate:
http://people.redhat.com/harald/downloads/initscripts/initscripts-8.45.26.1.el5/

Comment 15 Chris Ward 2009-07-03 18:09:09 UTC
~~ Attention - RHEL 5.4 Beta Released! ~~

RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner!

If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity.

Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value.

Questions can be posted to this bug or your customer or partner representative.

Comment 16 Sean E. Millichamp 2009-07-16 16:30:04 UTC
We finally had a chance to test the initscripts-8.45.26.1.el5 package and it seems to fix the problems we were experiencing.  Thanks!

Comment 19 errata-xmlrpc 2009-09-02 11:13:09 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1344.html