The patch deletes all of 'arp_ip_target' in /sys/class/net/bondX/bonding/arp_ip_target at doing 'ifdown bondX'

I'm not sure that's the right answer - we don't deconfigure other bonding parameters of the interface on ifdown.

Bill, you are correct that we don't deconfigure other bonding parameters, but the initscripts presume that all parameters will be unset when they begin configuration.

It would be wise to consider removing all entries for arp_ip_target either when the interface goes down (with ifdown) or when it comes up (with ifup) before the parameters are set.  It might even be wise to zero out all parameters when the interface is just brought up to be sure no residual information remains from the previous configuration.

'Zero out'... given how bonding is configured, there's no way to guess what needs zeroed out to what.

For arp_ip_target, is there a '-*' or similar syntax supported?

So I didn't elaborate on what I meant by 'zero out.'  I liked the patch in the Description that simply did this:

       # cleanup arp_ip_target
       if [ -d "/sys/class/net/${DEVICE}" ]; then
           arp_ip_target_path=/sys/class/net/${DEVICE}/bonding/arp_ip_target
           arp_ip_targets=`cat ${arp_ip_target_path}`
           for arg in ${arp_ip_targets}; do
              echo "-${arg}" > ${arp_ip_target_path}
           done
       fi

The sysfs files for 'arp_ip_target' and 'slaves' both use +[string] and -[string] syntax for adding and removing entries from their lists.  I might be a good idea to clear both of those with a patch much like the one above when it is first detected that a bonding device is coming up.

Maybe something like this untested patch:

diff --git a/sysconfig/network-scripts/ifup-eth b/sysconfig/network-scripts/ifup-eth
index 33df60f..2a9fe7d 100755
--- a/sysconfig/network-scripts/ifup-eth
+++ b/sysconfig/network-scripts/ifup-eth
@@ -122,6 +122,17 @@ if [ "$ISALIAS" = no ] && is_bonding_device ${DEVICE} ; then

     /sbin/ip link set dev ${DEVICE} down

+    # cleanup old settings if there are any
+    for arg in "slaves arp_ip_target" ; do
+       if [ -d "/sys/class/net/${DEVICE}" ]; then
+           sysfs_path=/sys/class/net/${DEVICE}/bonding/${arg}
+           targets=`cat ${sysfs_path}`
+           for entry in ${targets}; do
+              echo "-${entry}" > ${sysfs_path}
+           done
+       fi
+    done
+
     # add the bits to setup driver parameters here
     for arg in $BONDING_OPTS ; do
         key=${arg%%=*};

Hm, this means that running 'ifup' twice in a row will bounce the device and all the slave links. Is that what we want?

I am good only to erase all current entries of 'arp_ip_target'
by "echo -<ip address> > /sys/class/net/bondX/bonding/arp_ip_target" that kernel supports,
when bondX is doing down.

I think that I need not maintain 'arp_ip_target' configuration when bondX is down.
Why should kernel maintain 'arp_ip_target' configuration?


If the end-user sees this message, he becomes perplexed.
Please fix the problem.
> Bringing up interface bond0:  /etc/sysconfig/network-scripts/ifup-eth: \
> line 133: echo: write error: Invalid argument

I confirmed that there is a success case and is a failure case
by operation of 'echo "-<ip address>" > /sys/class/net/bondX/bonding/arp_ip_target'

If it is so, I think that 'ifup-eth' script should check it so as not to register doubly
before it regist 'arp_ip_target'.
What do you think?

Created attachment 330805 [details]
ifdown-up script patch (check all current 'arp_ip_target' entries before regist a new entry)

I changed the patch from deleting all 'arp_ip_target' entries in 'ifdown-eth'
to checking all current entries before regist a new entry.

typo: ifdown-up script patch ----> correct: ifup-eth script patch

Upstream commit is at http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=a0895aba2529c34387cf9abdc658f5f43c39d32c - it's probably better to do it in the down path.

Please test the erratum candidate:
http://people.redhat.com/harald/downloads/initscripts/initscripts-8.45.26.1.el5/

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1344.html