Description of problem: Please note, this is identical to Bug 174327 for RHEL 4.4 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174327), but is still occuring in RHEL 5, and the workaround mentioned in the previous bug, will not load the module. When attempting to configure two bonded interfaces with dis-similar configuration, I am unable to rename the bonding module to be loaded a second time. The With the following in modprobe.conf alias bond0 bonding options bond0 -o bond0 mode=balance-rr miimon=100 alias bond1 bonding options bond1 -o bond1 mode=balance-alb miimon=50 instead of loading bond0 or bond1 I only get the module "bonding" loaded. When I try to bring up the interface bond1, I get Bringing up interface bond1: bonding device bond1 does not seem to be present, delaying initialization. When I attempt the workaround mentioned in the previous bug (modprobe --ignore-install -o bonding0 bonding miimon=100), I get: FATAL: Error inserting bonding (/lib/modules/2.6.18-8.el5/kernel/drivers/net/bonding/bonding.ko): Operation not permitted Version-Release number of selected component (if applicable): 2.6.18-8.el5 How reproducible: Every time. Steps to Reproduce: 1. modprobe -o bonding0 bonding or 1. cat ifcfg-bond[0,1] ifcfg-eth[0-3] DEVICE=bond0 IPADDR=192.168.50.111 NETWORK=192.168.50.0 NETMASK=255.255.255.0 BROADCAST=192.168.50.255 USERCTL=no BOOTPROTO=none ONBOOT=yes DEVICE=bond1 IPADDR=192.168.30.111 NETWORK=192.168.30.0 NETMASK=255.255.255.0 USERCTL=no BOOTPROTO=none ONBOOT=yes # Intel Corporation 82546GB Gigabit Ethernet Controller DEVICE=eth0 #HWADDR=00:04:23:CA:80:A0 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none # Intel Corporation 82546GB Gigabit Ethernet Controller DEVICE=eth1 #HWADDR=00:04:23:CA:80:A1 USERCTL=no ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none # Intel Corporation 82541GI Gigabit Ethernet Controller #HWADDR=00:13:72:50:D5:78 DEVICE=eth2 USERCTL=no ONBOOT=yes MASTER=bond1 SLAVE=yes BOOTPROTO=none # Intel Corporation 82541GI Gigabit Ethernet Controller #HWADDR=00:13:72:50:D5:79 DEVICE=eth3 USERCTL=no ONBOOT=yes MASTER=bond1 SLAVE=yes BOOTPROTO=none cat /etc/modprobe.conf <snip> alias bond0 bonding options bond0 -o bond0 mode=balance-rr miimon=100 alias bond1 bonding options bond1 -o bond1 mode=balance-alb miimon=50 </snip> 2. service network restart Actual results: Method 1 (just renaming module): FATAL: Error inserting bonding (/lib/modules/2.6.18-8.el5/kernel/drivers/net/bonding/bonding.ko): Operation not permitted Method 2 (while trying to bring bond1 up): Bringing up interface bond1: bonding device bond1 does not seem to be present, delaying initialization. Additional info:
The recommended way to configure multiple bonding interfaces is no longer to use modprobe.conf options. Now you need to use the BONDING_OPTS values in ifcfg-bond0/1. You actually specify the same options in BONDING_OPTS that you would use in modprobe.conf, so it's pretty easy. Your new modprobe.conf should look like this: cat /etc/modprobe.conf <snip> alias bond0 bonding alias bond1 bonding </snip> and your ifcfg-bondX files should look like this: cat ifcfg-bond[0,1] DEVICE=bond0 IPADDR=192.168.50.111 NETWORK=192.168.50.0 NETMASK=255.255.255.0 BROADCAST=192.168.50.255 USERCTL=no BOOTPROTO=none ONBOOT=yes BONDING_OPTS="mode=balance-rr miimon=100" DEVICE=bond1 IPADDR=192.168.30.111 NETWORK=192.168.30.0 NETMASK=255.255.255.0 USERCTL=no BOOTPROTO=none ONBOOT=yes BONDING_OPTS="mode=balance-alb miimon=50" The RHEL5 documentation should reflect this change soon, but I don't think it's been updated yet. Let me know how this works for you.
When modprobe.conf, ifcfg-bond0, and ifcfg-bond1 are configured exactly as above: Bond0 will load as expected, but bond1 gets the following: bonding device bond1 does not seem to be present, delaying initialization.
I did some more testing. Its certainly not a limitation of the driver. its a limitation of the scripting environment surrounding bringing the interface up. I Configured modprobe.conf as following, which works, and brings up both interfaces with the same settings (miimon=300) alias bond0 bonding options bonding mode=active-backup miimon=300 max_bonds=2 alias bond1 bonding I then changed the config for bond1 on the fly, while it was running: echo '+192.168.30.254' > /sys/class/net/bond1/arp_ip_target # hostname to monitor echo '0' > /sys/class/net/bond1/miimon # Turn off miimon. echo '1000' > /sys/class/net/bond1/arp_interval # Turn on arp monitoring with 1 second delays. miimon must be turned off first [root@nfs2 ~]# cat /proc/net/bonding/bond* Ethernet Channel Bonding Driver: v3.0.3 (March 23, 2006) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth0 MII Status: up MII Polling Interval (ms): 300 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth0 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:04:23:ca:a6:84 Slave Interface: eth1 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:04:23:ca:a6:85 Ethernet Channel Bonding Driver: v3.0.3 (March 23, 2006) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth2 MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 ARP Polling Interval (ms): 1000 ARP IP target/s (n.n.n.n form): 192.168.30.254 Slave Interface: eth2 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:13:72:50:d4:e3 Slave Interface: eth3 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:13:72:50:d4:e4 [root@nfs2 ~]# As you can see.. one interface is now setup for arp monitoring, and the other is setup for miimon monitoring. This exact same configuration fails when I try to configure it using BONDING_OPTS.
Hmmm, that is interesting. I'm glad to hear you can create 2 bonds, but I was pretty sure it worked correctly the way I described. I'll fire up a RHEL5 box and see if I can reproduce what you are seeing. I assume what you were seeing came after completely unloading all bonding modules (or after a fresh boot), right?
Correct. Fresh reboot produced the error given above. Thanks!
There was an update to the initscripts to fix the fact that a '+' was needed before the ip address. That should resolve your problem. That was fixed in bug 288151. *** This bug has been marked as a duplicate of 288151 ***
>FATAL: Error inserting bonding >(/lib/modules/2.6.18-8.el5/kernel/drivers/net/bonding/bonding.ko): Operation not >permitted I'm getting the same problem. Was this because of interface to "modprobe -o another_name" is deprecated or something? I'm interested in the root cause of the bug. Thanks.
Comment #1 should explain how to resolve this issue. To create an additional bond on rhel5, please do this: # echo another_name > /sys/class/net/bonding_masters rather than using modprobe. The kernel's bonding code now uses sysfs for configuration of multiple bonds rather than the old-style from rhel4.