Bug 442339

I can confirm that this bug exists and is reproducable.

The bug shows itself on machines using different NIC drivers. Tested with both e1000 (Intel) and tg3 (Broadcom) drivers. The 
results are identical which suggests the problem is in a generic shared part of the networking code.

Jasper and Dennis,

Can you please attach your configuration files that you use for ethernet
devices, bonding, and for the VLAN interfaces?  I'm not sure I need them, but I
would like to have yours to be sure I'm testing everything correctly.

I've also managed to recreate this on one of my systems and it appears that
after setting up a bond, if I type:

# vconfig add bond0 1000

it appears that a callback (most-likely hotplug) calls ifup bond0.1000 and that
may not be needed.

If I comment out the call to ifup-eth that is called from ifup, then it appears
we don't run into this issue.

This patch also seems to work-around the issue, but I'm not sure it's the
correct solution:

--- ifup-eth.orig       2008-05-12 16:45:28.000000000 -0400
+++ ifup-eth    2008-05-12 17:09:32.000000000 -0400
@@ -112,6 +112,7 @@
         /sbin/ethtool -s ${REALDEVICE} $ETHTOOL_OPTS
     fi

+    /sbin/ip link set dev ${DEVICE} up
     exit 0
 fi


Adding notting to the cc-list so we can weigh-in on on this, too.

Setting HOTPLUG=no in the appropriate config file should fix this, FWIW. But I'd
still like to see the config files in use.

Interesting...I see now where that hook is used.

Created attachment 305455 [details]
interface config

Oh, I can't add multiple attachments to one message, sorry, didn't mean to spam. ;-)

Anyway, here are my configs. I haven't gotten around to testing with HOTPLUG=no yet.

# Intel Corporation 82571EB Gigabit Ethernet Controller
DEVICE=nslave0
HWADDR=00:15:17:63:48:E1
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
SLAVE=yes
MASTER=bond1

# Intel Corporation 82571EB Gigabit Ethernet Controller
DEVICE=nslave1
HWADDR=00:15:17:63:4A:81
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
SLAVE=yes
MASTER=bond1


DEVICE=bond1
BOOTPROTO=static
IPADDR=10.100.100.132
NETMASK=255.255.255.128
USERCTL=no
ONBOOT=yes
BONDING_OPTS="arp_ip_target=+10.100.100.129 arp_ip_target=+10.100.100.130
arp_interval=500"

Do you not have a config for the vlan device?

I was testing without one for the moment, as the vcontrol command triggered the
error as well.

The vlan interface config file I used looked like this:

DEVICE=bond1.1000
BOOTPROTO=static
VLAN=yes
IPADDR=172.18.0.1
NETMASK=255.255.255.0
ONPARENT=yes

The simplest solution would be HOTPLUG=no in 'ifcfg-bondX'. Does that work for you?

Unfortunately, fixing this cleanly would require changing functionality that
other people may have come to rely on (hotplugging a network device
automatically finding the appropriate configuration and renaming the new device
to that configured device), which means it wouldn't really be appropriate for RHEL.

Unfortunately not, my ifcfg-bond1 now looks like this:
DEVICE=bond1
BOOTPROTO=static
IPADDR=10.100.100.132
NETMASK=255.255.255.128
USERCTL=no
ONBOOT=yes
HOTPLUG=no
BONDING_OPTS="arp_ip_target=+10.100.100.129 arp_ip_target=+10.100.100.130
arp_interval=500"


Adding a VLAN either through vcontrol or using ifup bond1.1000 still results in
the following message (dmesg):
bonding: bond1: Interface nslave0 is already enslaved!
bonding: bond1: interface nslave0 is now down.
bonding: bond1: now running without any active interface !

Argh, mistyped.

HOTPLUG=no needs to go in the *slave* interface configuration (i.e., wherever
the HWADDR is).

Yes, that works for me. Thanks! :)
I don't seem to be missing any required functionality, so this
solution/workaround is fine.

Excellent!  I will close this one out.