netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Vosburgh <fubar@us.ibm.com>
To: "Harsha R02" <Harsha.R02@mphasis.com>
Cc: "Brian Haley" <brian.haley@hp.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	bugzilla-daemon@bugzilla.kernel.org,
	bugme-daemon@bugzilla.kernel.org, netdev@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 29712] New: Bonding Driver(version : 3.5.0) - Problem with ARP monitoring in active backup mode
Date: Fri, 04 Mar 2011 10:18:33 -0800	[thread overview]
Message-ID: <19583.1299262713@death> (raw)
In-Reply-To: <E351E450E8B9F54684A699D42DC5ADF2103267E5@MPBAGVEX02.corp.mphasis.com>

Harsha R02 <Harsha.R02@mphasis.com> wrote:

>We found that the patch that is presented here has some issues and we
>cannot go with this solution.
>
>In function "bond_ab_arp_probe" in addition to sending arp probes for
>the currently active slave we should also 
>be sending arp probes for the primary_slave if the link status of the
>primary slave is up correct ?
>
>I have made changes as below :
>
>static void bond_ab_arp_probe(struct bonding *bond)
>{
>        struct slave *slave;
>        int i;
>
>        read_lock(&bond->curr_slave_lock);
>
>        if (bond->current_arp_slave && bond->curr_active_slave)
>                pr_info(DRV_NAME "PROBE: c_arp %s && cas %s BAD\n",
>                       bond->current_arp_slave->dev->name,
>                       bond->curr_active_slave->dev->name);
>
>        if (bond->curr_active_slave) {
>+                if((bond->curr_active_slave != bond->primary_slave) &&
>+                   (IS_UP(bond->primary_slave->dev))) {
>+                    bond_arp_send_all(bond, bond->primary_slave);
>+                }
>                bond_arp_send_all(bond, bond->curr_active_slave);
>                read_unlock(&bond->curr_slave_lock);

	No, we can't do this; if we send ARP probes out from an inactive
slave (which the primary would be at this point) it will confuse
switches that snoop traffic to determine the switch port's MAC addresses
(the switches will believe that the "primary" slave is the port to use
to reach the bond's MAC address).

	I think your problem is that your configuration (two systems,
back to back, no switch) is not a configuration the ARP monitor is
designed to work with.

	The ARP monitor determines the availability of backup slaves
based on traffic received by the backup slaves.  The usual source of
this traffic is the ARP broadcast requests being sent out the active
slave and then forwarded by the switch to all switch ports, including
the backup slave's port.  I'm guessing that your system isn't forwarding
these packets like a switch would, and so the primary slave isn't seeing
any incoming packets at all.

	If your primary slave (which is an inactive slave at the moment)
is not receiving traffic, bonding will never believe it is available.

	I've never experimented with using the ARP monitor in a
back-to-back confguration; I'm thinking through how the ARP monitor
functions, and I'm not sure it can be reliable when set up like this.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com

      reply	other threads:[~2011-03-04 18:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-29712-10286@https.bugzilla.kernel.org/>
2011-02-24 22:51 ` [Bugme-new] [Bug 29712] New: Bonding Driver(version : 3.5.0) - Problem with ARP monitoring in active backup mode Andrew Morton
2011-02-25  3:42   ` Brian Haley
2011-02-25 12:44     ` Harsha R02
2011-02-25 18:54       ` David Miller
     [not found]     ` <19879D0AB3081A4B883186484ECC6FC05E780ADF@MPBAGVEX02.corp.mphasis.com>
     [not found]       ` <E351E450E8B9F54684A699D42DC5ADF20C6F1D4A@MPBAGVEX02.corp.mphasis.com>
2011-02-25 19:02         ` Jay Vosburgh
2011-03-03  6:31           ` Harsha R02
2011-03-04 18:18             ` Jay Vosburgh [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19583.1299262713@death \
    --to=fubar@us.ibm.com \
    --cc=Harsha.R02@mphasis.com \
    --cc=akpm@linux-foundation.org \
    --cc=brian.haley@hp.com \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=bugzilla-daemon@bugzilla.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).