netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jay Vosburgh <fubar@us.ibm.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Chris Friesen <chris.friesen@genband.com>,
	netdev <netdev@vger.kernel.org>,
	andy@greyhouse.net
Subject: Re: bonding and SR-IOV -- do we need arp_validation for loadbalancing too?
Date: Tue, 24 Jul 2012 11:13:49 -0700	[thread overview]
Message-ID: <21683.1343153629@death.nxdomain> (raw)
In-Reply-To: <20120724164220.GA1721@minipsycho.orion>

Jiri Pirko <jiri@resnulli.us> wrote:

>Tue, Jul 24, 2012 at 05:57:03PM CEST, chris.friesen@genband.com wrote:
>>Hi all,
>>
>>We've been starting to look at bonding VFs from separate physical
>>devices in a guest, but we've run into a problem.
>>
>>The host is bonding the corresponding PFs, and it uses arp
>>monitoring.  What we have found is that any broadcast traffic from
>>the guest (if they enable arp monitoring, for example) will be seen
>>by the internal L2 switch of the NIC and sent up into the host, where
>>the bonding driver will count it as incoming packets and use it to
>>mark the link as good.
>>
>>The only solutions I've been able to come up with are:
>>1) add arp validation for load balancing modes as well as active-backup.
>
>This is my favourite.... No reason to not to turn arp validation on.
>TEAM device (teamd arpping linkwatch) does arp or NSNA validation
>always.

	How does that operate for a load balancing mode?

	For arp validate to function (as it's implemented in bonding),
the arp requests (broadcasts) or the arp replies (unicasts) must be seen
by each slave at regular intervals.  Most load balance systems
(etherchannel or 802.3ad, for example) don't flood the broadcast
requests to all members of a channel group, and the unicast replies only
go to one member.

	This generally results in either only one slave staying up, or
slaves going up and down at odd intervals.  The arp monitor for the load
balance modes is already dependent upon there being a steady stream of
traffic to all slaves, and can be unreliable in low traffic conditions
(because not all slaves receive traffic with sufficient frequency).

	-J

>>2) put all the VMs in VLANs
>>
>>Anyone have any better ideas?

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

  reply	other threads:[~2012-07-24 20:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-24 15:57 bonding and SR-IOV -- do we need arp_validation for loadbalancing too? Chris Friesen
2012-07-24 16:42 ` Jiri Pirko
2012-07-24 18:13   ` Jay Vosburgh [this message]
2012-07-24 20:18     ` Chris Friesen
2012-07-24 20:38       ` Chris Friesen
2012-07-24 20:49       ` Jay Vosburgh
2012-07-24 21:15         ` Nicolas de Pesloüan
2012-07-24 21:38         ` Chris Friesen
2012-07-27 14:55           ` Andy Gospodarek
2012-07-27 16:15             ` Chris Friesen
2012-07-27 17:13               ` Andy Gospodarek

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=21683.1343153629@death.nxdomain \
    --to=fubar@us.ibm.com \
    --cc=andy@greyhouse.net \
    --cc=chris.friesen@genband.com \
    --cc=jiri@resnulli.us \
    --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).