Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 159108 - error message comes up after ethernet bonding
Summary: error message comes up after ethernet bonding
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: John W. Linville
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-29 23:10 UTC by EE CAP Admin
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-06-06 16:57:02 UTC


Attachments (Terms of Use)
Output of sysreport (deleted)
2005-06-06 13:38 UTC, EE CAP Admin
no flags Details

Description EE CAP Admin 2005-05-29 23:10:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)

Description of problem:
We have two ethernet cards on our HP proliant 360 server, and we have already set up the ethernet bonding. The OS running on the server is RHEL4. The warning message when restarting the network is as following,

âkernel: bonding: Warning: the permanent HWaddr of eth0 - 00:12:79:94:66:1A - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflictsâ.

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


How reproducible:
Always

Steps to Reproduce:
1. Set up the ethernet bonding
2. 
3.
  

Actual Results:  Error message comes up.

Expected Results:  No error message.

Additional info:

For detail information of ethernet bonding we follow, please go to

http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/bonding.txt

Comment 1 John W. Linville 2005-06-06 13:18:03 UTC
Please attach the output of running "sysreport". 
 
When the network restarts, does the bond function correctly?  Are all expected 
interfaces still part of the bond? 
 
When the bonding interface comes-up, it "steals" a MAC address from one of its 
slaves (generally the first one).  The message you are seeing occurs when the 
interface that had it's MAC address stolen is removed from the bond while the 
bond remains active. 
 
My guess is that this is just an artifact of the restart process removing 
interfaces from the bond prior to bringing the bond down before restarting.  
If the bond continues to work properly after the network restart, then the 
message can be safely ignored. 

Comment 2 EE CAP Admin 2005-06-06 13:38:43 UTC
Created attachment 115165 [details]
Output of sysreport

Comment 3 EE CAP Admin 2005-06-06 13:41:42 UTC
Hi John,

Thanks for getting back about this.

OK - as you have seen - sysreport uploaded.

Yes - the bonding does seem to always work; we were just concerned that we were
getting errors and didn't want it to bite us in the backside later on.  

So is something starting/stoppin in the wrong order?  Does something need
modifying in /etc/init.d/network?

Thanks,

Paul

Comment 4 John W. Linville 2005-06-06 16:57:02 UTC
Considering the situation, I don't really think it would be right to call it  
the "wrong" order.  It would be difficult to keep track of the perfect order  
for bringing the slave interfaces up and down, all just to avoid a warning  
message that ultimately doesn't effect the situation.  
  
I'm going to close this as NOTABUG, since it is at worst really just an 
annoying message.  Feel free to reopen this if you observe actual loss of 
functionality.  Thanks! 

Comment 5 EE CAP Admin 2005-06-06 17:13:18 UTC
Hi John - thanks for the info on this.

I'm not going to reopen... I just wanted confirmation that things were operating
properly and that we hadn't set something up wrong.

Paul


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