Bug 463014 - [PATCH] Fix for problem with bridged bonding interfaces
Summary: [PATCH] Fix for problem with bridged bonding interfaces
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts
Version: 5.2
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: BaseOS QE
: 193236 458502 465794 465801 474645 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2008-09-20 20:09 UTC by Sean E. Millichamp
Modified: 2018-10-20 03:15 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-09-02 11:13:09 UTC
Target Upstream Version:

Attachments (Terms of Use)
Patch to fix reported problem (2.88 KB, patch)
2008-09-20 20:09 UTC, Sean E. Millichamp
no flags Details | Diff
New patch to fix the bridge ordering problem (1.83 KB, patch)
2008-09-24 13:15 UTC, Sean E. Millichamp
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1344 0 normal SHIPPED_LIVE initscripts bug fix update 2009-09-01 10:44:36 UTC

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):

How reproducible:

Every time.

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



BONDING_OPTS='mode=1 miimon=100'


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:

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- 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.


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