Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 408339 - different MAC address reported by ifconfig vs. bonding driver
Summary: different MAC address reported by ifconfig vs. bonding driver
Status: RESOLVED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-15 12:05 UTC by Martin Mokrejš
Modified: 2012-03-19 20:23 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Mokrejš 2012-03-15 12:05:11 UTC
I wonder whether ifconfig or bonding driver lie about my MAC addresses:



# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.0 (June 2, 2010)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:25:90:18:3f:2c
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:25:90:18:3f:2d
Slave queue ID: 0
#
# ifconfig 
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 1500
        inet 172.25.9.182  netmask 255.255.255.0  broadcast 172.25.9.255
        ether 00:25:90:18:3f:2c  txqueuelen 0  (Ethernet)
        RX packets 299705  bytes 308578086 (294.2 MiB)
        RX errors 0  dropped 29736  overruns 0  frame 0
        TX packets 55759  bytes 5351471 (5.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 00:25:90:18:3f:2c  txqueuelen 1000  (Ethernet)
        RX packets 277924  bytes 306339718 (292.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 55759  bytes 5351471 (5.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfbe60000-fbe80000  

eth1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 00:25:90:18:3f:2c  txqueuelen 1000  (Ethernet)
        RX packets 21781  bytes 2238368 (2.1 MiB)
        RX errors 0  dropped 21781  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfbee0000-fbf00000  


This is probably causing the following messages:

# uname -a
Linux s00142 2.6.39.4 #4 SMP Wed Mar 14 00:33:28 MET 2012 x86_64 Intel(R) Xeon(R) CPU X5680 @ 3.33GHz GenuineIntel GNU/Linux
# dmesg
[cut]
[    0.000000] Kernel command line: root=/dev/md1 bonding.mode=1 miimon=100 console=ttyS0,115200n8 console=tty0 udev
[cut]
[    8.901364] Intel(R) Gigabit Ethernet Network Driver - version 3.0.6-k2
[    8.908208] Copyright (c) 2007-2011 Intel Corporation.
[    8.913667] igb 0000:08:00.0: power state changed by ACPI to D0
[    8.919820] igb 0000:08:00.0: power state changed by ACPI to D0
[    8.925980] igb 0000:08:00.0: PCI INT A -> GSI 28 (level, low) -> IRQ 28
[    8.932923] igb 0000:08:00.0: setting latency timer to 64
[    8.933161] igb 0000:08:00.0: irq 72 for MSI/MSI-X
[    8.933165] igb 0000:08:00.0: irq 73 for MSI/MSI-X
[    8.933169] igb 0000:08:00.0: irq 74 for MSI/MSI-X
[    8.933173] igb 0000:08:00.0: irq 75 for MSI/MSI-X
[    8.933177] igb 0000:08:00.0: irq 76 for MSI/MSI-X
[    8.933180] igb 0000:08:00.0: irq 77 for MSI/MSI-X
[    8.933184] igb 0000:08:00.0: irq 78 for MSI/MSI-X
[    8.933188] igb 0000:08:00.0: irq 79 for MSI/MSI-X
[    8.933191] igb 0000:08:00.0: irq 80 for MSI/MSI-X
[    9.164370] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection
[    9.171471] igb 0000:08:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:25:90:18:3f:2c
[    9.178956] igb 0000:08:00.0: eth0: PBA No: FFFFFF-0FF
[    9.184368] igb 0000:08:00.0: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[    9.197350] igb 0000:08:00.1: power state changed by ACPI to D0
[    9.203498] igb 0000:08:00.1: power state changed by ACPI to D0
[    9.209646] igb 0000:08:00.1: PCI INT B -> GSI 40 (level, low) -> IRQ 40
[    9.216581] igb 0000:08:00.1: setting latency timer to 64
[    9.216804] igb 0000:08:00.1: irq 81 for MSI/MSI-X
[    9.216808] igb 0000:08:00.1: irq 82 for MSI/MSI-X
[    9.216812] igb 0000:08:00.1: irq 83 for MSI/MSI-X
[    9.216816] igb 0000:08:00.1: irq 84 for MSI/MSI-X
[    9.216819] igb 0000:08:00.1: irq 85 for MSI/MSI-X
[    9.216823] igb 0000:08:00.1: irq 86 for MSI/MSI-X
[    9.216827] igb 0000:08:00.1: irq 87 for MSI/MSI-X
[    9.216830] igb 0000:08:00.1: irq 88 for MSI/MSI-X
[    9.216834] igb 0000:08:00.1: irq 89 for MSI/MSI-X
[    9.251768] ata4: SATA link down (SStatus 0 SControl 300)
[    9.268077] ata3: SATA link down (SStatus 0 SControl 300)
[    9.461154] igb 0000:08:00.1: Intel(R) Gigabit Ethernet Network Connection
[    9.468260] igb 0000:08:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:25:90:18:3f:2d
[    9.475713] igb 0000:08:00.1: eth1: PBA No: FFFFFF-0FF
[    9.481097] igb 0000:08:00.1: Using MSI-X interrupts. 8 rx queue(s), 8 tx queue(s)
[    9.489131] bonding: Ethernet Channel Bonding Driver: v3.7.0 (June 2, 2010)
[    9.496321] bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details.
[cut]
[   33.708780] bonding: bond0: Adding slave eth0.
[   33.791800] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[   33.792702] bonding: bond0: making interface eth0 the new active one.
[   33.792885] bonding: bond0: first active interface up!
[   33.792892] bonding: bond0: enslaving eth0 as an active interface with an up link.
[   33.795894] bonding: bond0: Adding slave eth1.
[   33.878789] bonding: bond0: Warning: failed to get speed and duplex from eth1, assumed to be 100Mb/sec and Full.
[   33.878797] bonding: bond0: enslaving eth1 as a backup interface with an up link.
[   36.106747] igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Comment 1 Martin Mokrejš 2012-03-15 12:20:56 UTC
Some more messages from /var/log/messages from previous boot ups (openrc-0.8.2, net-tools-).

Feb 17 16:39:53 s00142 /etc/init.d/sshd[21177]: WARNING: you are stopping a sysinit service
Feb 17 16:39:56 s00142 kernel: [1791338.422958] bonding: bond0: Removing slave eth0.
Feb 17 16:39:56 s00142 kernel: [1791338.423216] bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:25:90:18:3f:2c - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
Feb 17 16:39:56 s00142 kernel: [1791338.423220] bonding: bond0: releasing active interface eth0
Feb 17 16:39:56 s00142 kernel: [1791338.620239] bonding: bond0: Removing slave eth1.
Feb 17 16:39:56 s00142 kernel: [1791338.620371] bonding: bond0: releasing active interface eth1
Feb 17 16:39:56 s00142 kernel: [1791338.837747] bonding: bond0 is being deleted...
Feb 17 16:39:57 s00142 kernel: [1791338.983472] bonding: bond0 is being created...
Feb 17 16:39:57 s00142 kernel: [1791339.004234] bonding: bond0: Adding slave eth0.
Feb 17 16:39:57 s00142 kernel: [1791339.091723] bonding: bond0: Warning: failed to get speed and duplex from eth0, assumed to be 100Mb/sec and Full.
Feb 17 16:39:57 s00142 kernel: [1791339.091740] bonding: bond0: enslaving eth0 as an active interface with an up link.
Feb 17 16:39:57 s00142 kernel: [1791339.094030] bonding: bond0: Adding slave eth1.
Feb 17 16:39:57 s00142 kernel: [1791339.181511] bonding: bond0: Warning: failed to get speed and duplex from eth1, assumed to be 100Mb/sec and Full.
Feb 17 16:39:57 s00142 kernel: [1791339.181523] bonding: bond0: enslaving eth1 as an active interface with an up link.
Feb 17 16:39:57 s00142 sshd[21521]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Feb 17 16:39:57 s00142 sshd[21521]: fatal: Cannot bind any address.
Feb 17 16:39:58 s00142 /etc/init.d/net.bond0[21538]: ERROR: cannot stop net.bond0 as sshd is still up
Feb 17 16:39:59 s00142 kernel: [1791341.549018] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Feb 17 16:39:59 s00142 kernel: [1791341.754842] igb: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Feb 17 16:40:01 s00142 cron[21621]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Feb 17 16:45:45 s00142 kernel: [1791687.531752] igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Comment 2 BigBug 2012-03-15 12:33:15 UTC
Noone lies, the bond driver in balancing modes sets the both MAC addresses to the same value (the mac of the first adapter in bond), and restore back when interface removed from the bond.

I do not see any real error messages in logs :)
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2012-03-15 15:29:30 UTC
Er, so the bonding driver is spoofing eth1's MAC, and when asked, ifconfig reports that precisely as intended? But when the bonding driver is asked through /proc, it faithfully reports the original MACs for both ethNs.

So is this still a bug?

(NOTE: It seems eth1 does not transmit (TX) any packets, and receives comparatively few. Isn't that worth another bug report?)
Comment 4 BigBug 2012-03-15 15:46:56 UTC
No, the access through proc in that case reports remembered MAC, not spoofed.

What problem do you have? RR bond do not split the traffic in half? Or some packet lost issue?
Comment 5 Martin Mokrejš 2012-03-15 15:57:38 UTC
(In reply to comment #4)
> No, the access through proc in that case reports remembered MAC, not spoofed.
> 
> What problem do you have? RR bond do not split the traffic in half? Or some
> packet lost issue?

In this particular case I am annoyed with:

Feb 17 16:39:56 s00142 kernel: [1791338.423216] bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:25:90:18:3f:2c - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.

Whoever prints the false alarm should be made quiet, if this is happening by design. But as I was restarting the netowrk interfaces it was talking about system being unable to restore the original value because the interface was still 'up'. At least I remember seeing such a message in logs as well. I could give you a bunch of other types of messages I have received.

Some I reported in bug #408337, 408333. Thanks for your inputs.
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2012-03-15 16:03:33 UTC
So a workaround might be to use a different MAC address entirely for the bonding interface, and the solution would be to fix the bonding driver to not use the exact same MAC address ever?
Comment 7 Martin Mokrejš 2012-03-15 16:08:32 UTC
(In reply to comment #3)
> (NOTE: It seems eth1 does not transmit (TX) any packets, and receives
> comparatively few. Isn't that worth another bug report?)

Good point, I did not think of it. I am glad the server is running the network at all. ;-) This is on vanilla kernel 2.6.39.4. I used to have mode=balance-rr but the network switch complained (don't remember the details passed to me by our netadmin). So I went for the active-backup mode. Still, not clear why there are just RX and not TX values. Current numbers aren't much better.

# ifconfig 
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST>  mtu 1500
        inet 172.25.9.182  netmask 255.255.255.0  broadcast 172.25.9.255
        ether 00:25:90:18:3f:2c  txqueuelen 0  (Ethernet)
        RX packets 489725  bytes 325005109 (309.9 MiB)
        RX errors 0  dropped 88541  overruns 0  frame 0
        TX packets 94529  bytes 30420195 (29.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 00:25:90:18:3f:2c  txqueuelen 1000  (Ethernet)
        RX packets 425031  bytes 318315128 (303.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 94529  bytes 30420195 (29.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfbe60000-fbe80000  

eth1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST>  mtu 1500
        ether 00:25:90:18:3f:2c  txqueuelen 1000  (Ethernet)
        RX packets 64694  bytes 6689981 (6.3 MiB)
        RX errors 0  dropped 64694  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device memory 0xfbee0000-fbf00000
Comment 8 Martin Mokrejš 2012-03-15 16:18:44 UTC
(In reply to comment #6)
> So a workaround might be to use a different MAC address entirely for the
> bonding interface, and the solution would be to fix the bonding driver to
> not use the exact same MAC address ever?

There used to be something like that in net.example but was commented out. When I tried that yesterday the net result was that the bonding did not assemble correctly:

[cut]
#-----------------------------------------------------------------------------
# MAC changer
# To set a specific MAC address

mac_bond0="00:25:90:18:3f:2e"
mac_eth0="00:25:90:18:3f:2c"
mac_eth1="00:25:90:18:3f:2d"
[cut]

But outcome of this is exactly what I reported under bug #408337 (see the different MAC addresses in /var/log/rc.log, actually those MACs for eth0 and eth1 are real, just the one for bond0 is fake ... yeah, don't know why I re-defined the MACs for the eth0 and eth1 on the above mac_eth* lines above to very same value).

To get the machine up an running, I had to comment out the MAC changer section, as it was by default. And then we are by bug #408333 wondering, why is the whole section gone from current openrc net.example file. There must have been a reason. ;-)
Comment 9 BigBug 2012-03-15 16:25:12 UTC
Jeroen Roovers said the thing i wanted to say. i fixed that kernel message exactly by changing the bond interfaces MAC to the one not owned by any network card. (aka mac_bond0="XX:...." in the /etc/conf.d/net :) )

If you go through switch, you must go with 802.3ad support.

packet drops you see may be related to the:
33.878789] bonding: bond0: Warning: failed to get speed and duplex from eth1, assumed to be 100Mb/sec and Full.
message. There is some issues with bonding driver in kernel regarding this. But those must be fixed by the kernel team :)
Comment 10 Martin Mokrejš 2012-03-15 16:43:08 UTC
(In reply to comment #9)
> Jeroen Roovers said the thing i wanted to say. i fixed that kernel message
> exactly by changing the bond interfaces MAC to the one not owned by any
> network card. (aka mac_bond0="XX:...." in the /etc/conf.d/net :) )
> 
> If you go through switch, you must go with 802.3ad support.
> 
> packet drops you see may be related to the:
> 33.878789] bonding: bond0: Warning: failed to get speed and duplex from
> eth1, assumed to be 100Mb/sec and Full.
> message. There is some issues with bonding driver in kernel regarding this.
> But those must be fixed by the kernel team :)

I think that happens because in those moments /sys/class/net/bond0/bonding/miimon contained zero, not 100 (contrary to the messages during bootup). I think that was just ignored. Maybe like my possibly wrong kernel command line:

root=/dev/md1 bonding.mode=1 miimon=100 console=ttyS0,115200n8 console=tty0 udev


Setting /sys/class/net/bond0/bonding manually to 100 does not help much, except getting:

[ 2760.524942] bonding: bond0: Setting MII monitoring interval to 100.

# mii-tool bond0
bond0: 10 Mbit, half duplex, link ok
# mii-tool eth0
eth0: negotiated 1000baseT-FD flow-control, link ok
# mii-tool eth1
eth1: negotiated 1000baseT-FD flow-control, link ok
# cat /sys/class/net/bond0/bonding/miimon 
100
#

Maybe I have to force re-negotiation via mii-tool on bond0? Not sure I want to make the remote suicide again right now if re-negotiation fails and I loose network access, especially as I am not sure whether /etc/init.d/net.eth* scripts will recognize the bonding-related variables in my /etc/conf.d/net anymore (bug #408333). It might not even configure the interface during next boot ... :( Do not know.
Comment 11 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-03-15 23:50:57 UTC
What you're seeing is in the original report is the CORRECT and intended behavior of bonding.

Consider the round-robin mode, with the ARP to port mapping table in your network switch.

Linux cycles between active interfaces to transmit. Each time it sends out a packet, the ARP table in the switch gets updated based on which port the packet came in on.

When the switch gets a packet destinated for the MAC address, it sends it to port where that MAC was seen LAST.

If you are transmit enough packets (which you should for TCP acks etc), this causes the incoming traffic to the bond to move over the active interfaces as well.

(In reply to comment #3)
> (NOTE: It seems eth1 does not transmit (TX) any packets, and receives
> comparatively few. Isn't that worth another bug report?)
No, this is correct. The user has it configured in active-backup mode. This pings the single fastest available interface, and uses it only. It does NOT aggregate links. Only one link is active at a time.

(In reply to comment #5)
> Feb 17 16:39:56 s00142 kernel: [1791338.423216] bonding: bond0: Warning: the
> permanent HWaddr of eth0 - 00:25:90:18:3f:2c - is still in use by bond0. Set
> the HWaddr of eth0 to a different address to avoid conflicts.
This message comes from the kernel.
It is caused by removing eth0 from the bond0, and trying to bring up eth0 outside the bond after that.

(In reply to comment #7)
> Good point, I did not think of it. I am glad the server is running the
> network at all. ;-) This is on vanilla kernel 2.6.39.4. I used to have
> mode=balance-rr but the network switch complained (don't remember the
> details passed to me by our netadmin). So I went for the active-backup mode.
> Still, not clear why there are just RX and not TX values. Current numbers
> aren't much better.
If you want balance-rr, turn OFF mac learning in your switch, or configure 802.23ad explicitly in the switch and change to that mode via sysfs.


(In reply to comment #10)
> I think that happens because in those moments
> /sys/class/net/bond0/bonding/miimon contained zero, not 100 (contrary to the
> messages during bootup). I think that was just ignored. Maybe like my
> possibly wrong kernel command line:
> 
> root=/dev/md1 bonding.mode=1 miimon=100 console=ttyS0,115200n8 console=tty0
> udev
miimon should never be zero. If you see it as zero, that's a kernel bug (I'm pretty sure even the in-kernel default is non-zero).

> Setting /sys/class/net/bond0/bonding manually to 100 does not help much,
> except getting:
> 
> [ 2760.524942] bonding: bond0: Setting MII monitoring interval to 100.
> 
> # mii-tool bond0
> bond0: 10 Mbit, half duplex, link ok
> # mii-tool eth0
> eth0: negotiated 1000baseT-FD flow-control, link ok
> # mii-tool eth1
> eth1: negotiated 1000baseT-FD flow-control, link ok
> # cat /sys/class/net/bond0/bonding/miimon 
> 100
> #
A bond interface has no MII data. mii-tool does not account for that case.
Use ethtool instead.
# ethtool bond0
Settings for bond0:
	Link detected: yes
# ethtool eth1
Settings for eth1:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
...


> Maybe I have to force re-negotiation via mii-tool on bond0? Not sure I want
> to make the remote suicide again right now if re-negotiation fails and I
> loose network access, especially as I am not sure whether
> /etc/init.d/net.eth* scripts will recognize the bonding-related variables in
> my /etc/conf.d/net anymore (bug #408333). It might not even configure the
> interface during next boot ... :( Do not know.
No, you CANNOT re-negotiation on a bond. It physically has no MII of it's own.
Comment 12 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-03-15 23:51:57 UTC
@kernel:
The only "bug" I see here is the potential miimon coming up with a zero value. Other than that, everything else here is functioning correctly.
Comment 13 Martin Mokrejš 2012-03-19 13:10:18 UTC
(In reply to comment #11)
> (In reply to comment #5)
> > Feb 17 16:39:56 s00142 kernel: [1791338.423216] bonding: bond0: Warning: the
> > permanent HWaddr of eth0 - 00:25:90:18:3f:2c - is still in use by bond0. Set
> > the HWaddr of eth0 to a different address to avoid conflicts.
> This message comes from the kernel.
> It is caused by removing eth0 from the bond0, and trying to bring up eth0
> outside the bond after that.

Hmm, so this means I cannot reliably stop bond0 and use just eth0 (because bond0 always infers the mac address of the first device used to create the bond)? I think that is why I want for chaging the MAC address of the bond0 interface. I will ignore this message when I see it for the next time in my logs.


> (In reply to comment #10)
> > I think that happens because in those moments
> > /sys/class/net/bond0/bonding/miimon contained zero, not 100 (contrary to the
> > messages during bootup). I think that was just ignored. Maybe like my
> > possibly wrong kernel command line:
> > 
> > root=/dev/md1 bonding.mode=1 miimon=100 console=ttyS0,115200n8 console=tty0
> > udev
> miimon should never be zero. If you see it as zero, that's a kernel bug (I'm
> pretty sure even the in-kernel default is non-zero).

Maybe this was caused by my kernel config line "bonding.mode=1 miimon=100"?
What I booted up now with is "bonding.mode=1 bonding.miimon=100" instead. And that really works.

As you told me in the bug #408333#c3 NOT to alter the MAC address of the bond0 interface, my issue is gone provided I have proper /etc/conf.net settings (attached in that bug as well). Thanks!
Comment 14 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-03-19 20:23:53 UTC
(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #5)
> > > Feb 17 16:39:56 s00142 kernel: [1791338.423216] bonding: bond0: Warning: the
> > > permanent HWaddr of eth0 - 00:25:90:18:3f:2c - is still in use by bond0. Set
> > > the HWaddr of eth0 to a different address to avoid conflicts.
> > This message comes from the kernel.
> > It is caused by removing eth0 from the bond0, and trying to bring up eth0
> > outside the bond after that.
> 
> Hmm, so this means I cannot reliably stop bond0 and use just eth0 (because
> bond0 always infers the mac address of the first device used to create the
> bond)? I think that is why I want for chaging the MAC address of the bond0
> interface. I will ignore this message when I see it for the next time in my
> logs.
With a different miimon value, the MAC of the bond should change properly when eth0 is dropped from it, to the MAC of eth1.

If you see it again, and both devices are up, and you're not forcing MAC addresses on interfaces, please open a new bug that the kernel bonding is getting the wrong MAC.

> Maybe this was caused by my kernel config line "bonding.mode=1 miimon=100"?
> What I booted up now with is "bonding.mode=1 bonding.miimon=100" instead.
> And that really works.
Yeah, that would cause it too ;-)

> As you told me in the bug #408333#c3 NOT to alter the MAC address of the
> bond0 interface, my issue is gone provided I have proper /etc/conf.net
> settings (attached in that bug as well). Thanks!
Ok, closing this then.