From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 Description of problem: I configured the /etc/sysconfig/network-scripts/ifcfg-eth0-range0 file so that it would setup a range of virtual interfaces the next time the network service would be restarted. This worked fine. I then attempted to bond my two interfaces, eth0 and eth1 to a new interface called bond0, renaming ifcfg-eth0-range0 to ifcfg-bond0-range0. This is where the problems started. Both interfaces bonded without complaint, however, when I would restart the network service, the bond interface would not come online. Actually, the bond0 interface I configured would say its up, as would all the virtual (alias) interfaces I would configure, however both eth0 and eth1 would be down. If I manually brought them up using ifconfig then it all worked fine. I searched through the scripts and the problem seemed to be that redhat was treating the virtual (alias) interfaces as actual devices and trying to bring them up as such. This in turn was some how knocking off eth0 and eth1 which would have already been brough up. The lines which are responsible for identifying the virtual interfaces as a device can be found in /etc/init.d/network :- # find all the interfaces besides loopback. # ignore aliases, alternative configurations, and editor backup files interfaces=`ls ifcfg* | LANG=C egrep -v '(ifcfg-lo|:|rpmsave|rpmorig|rpmnew)' | \ LANG=C egrep -v '(~|\.bak)$' | \ LANG=C egrep 'ifcfg-[A-Za-z0-9\._-]+$' | \ sed 's/^ifcfg-//g' | sed 's/[0-9]/ &/' | LANG=C sort -k 1,1 -k 2n | sed 's/ //'` Once I added "range" to the "interfaces=..." line above it worked fine because it skipped the file ifcfg-bond0-range0. It now looks like this :- # find all the interfaces besides loopback. # ignore aliases, alternative configurations, and editor backup files interfaces=`ls ifcfg* | LANG=C egrep -v '(ifcfg-lo|:|rpmsave|rpmorig|rpmnew|range)' | \ LANG=C egrep -v '(~|\.bak)$' | \ LANG=C egrep 'ifcfg-[A-Za-z0-9\._-]+$' | \ sed 's/^ifcfg-//g' | sed 's/[0-9]/ &/' | LANG=C sort -k 1,1 -k 2n | sed 's/ //'` with the virtusl range instead being setup in the ifup-post by the line :- /etc/sysconfig/network-scripts/ifup-aliases ${DEVICE} ${CONFIG} So like I said, it works fine right now, but is this a bug? I am worried perhaps I was just doing something wrong (I have trawled the online resources and news groups and have found no one with the same problem or solution, and no where that says you should be able to do this). Can someone please confirm either way? Thanks Conor Version-Release number of selected component (if applicable): initscripts-7.31.7.EL How reproducible: Always Steps to Reproduce: 1.Configure an alias range by creating a file such as ifcfg-bond0-range0, contents, for example, look like this :- IPADDR_START=172.16.1.30 IPADDR_END=172.16.1.49 CLONENUM_START=0 NETMASK=255.255.255.0 Test this works by either restarting the network service or using ifup-aliases to bring the aliases up. 2. Now create the bond, calling it bond 0. Relevent files look as follows :- # cat ifcfg-bond0 DEVICE=bond0 IPADDR=172.16.1.133 NETMASK=255.255.255.0 BROADCAST=172.16.1.255 GATEWAY=172.16.1.1 ONBOOT=yes BOOTPROTO=none # cat ifcfg-eth0 DEVICE=eth0 ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none # cat ifcfg-eth1 DEVICE=eth1 ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none Now restart the network services by runnign the command :- # service network restart 3.You should see that bond0, along with all the virtual (alias) interfaces are now configured and UP, however you will have no connectivity as eth0 and eth1 are down. You can manually bring them up by doing :- # ifup eth0 # ifup eth1 4. Now make the edit i made above to /etc/init.d/network and restart the network service again. It should work this time. Actual Results: All explained above. Expected Results: I would have expected all alias interfaces and the bond to come on line with full connectivity to the rest of the network. Additional info: None. Should all be explained sufficently above.
This should be fixed in 7.31.20.EL. *** This bug has been marked as a duplicate of 65415 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.