From: Jasper Spaans <spaans@fox-it.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: <netdev@vger.kernel.org>
Subject: Re: bridging + load balancing bonding
Date: Fri, 23 Oct 2009 13:45:11 +0200 [thread overview]
Message-ID: <20091023114511.GA537@spaans.fox.local> (raw)
In-Reply-To: <347.1256232960@death.nxdomain.ibm.com>
On Thu, Oct 22, 2009 at 07:36:00PM +0200, Jay Vosburgh wrote:
> By "packets from one flow" do you really mean that packets from
> a given "flow" (TCP connection, UDP "stream", etc) are not always
> delivered to the same bonding port? I.e., that two packets from the
> same "flow" will be delivered to different ports? I'm not sure how
> that's possible unless the source MAC in the packets changes during the
> course of the flow.
>
> Or is your problem really that the balance algorithm on the
> bonding send side doesn't match the algorithm used on the other side of
> the IDS machines coming the other direction (and, thus, packets for a
> given flow going in one direction end up at a different IDS than the
> packets going the other direction)?
It's the second problem: traffic in one direction ends up at another
node than traffic in the other direction, even if between the same pair of
machines.
> Locally generated packets do, but he's got a bridge in there, so
> the traffic they're balancing is presumably not locally generated (i.e.,
> is being forwarded by the bridge, in which case they'll still bear the
> source MAC of the originating node on the subnet). If the packets were
> being routed instead of bridged, then, yah, they'd have the bond's
> source MAC.
And in case of routing, the destination MAC will also be modified.. so worst
case (all traffic goes to one node), no balancing will happen. This also
affects non-IDS use of load balancing, I guess.
> >So your solution might be the right fix...
>
> Yes, I think he's found a legitimate bug, one that only will
> manifest when balancing bridged traffic. I had to think for a minute if
> this change would break anything, and I'm coming up empty. Locally
> generated or routed traffic won't see a change, and bridged traffic will
> be correctly balanced according to the "source MAC XOR destination MAC"
> forumla described in the documentation.
I'll post a patch shortly.
Jasper
--
Fox-IT Experts in IT Security!
T: +31 (0) 15 284 79 99
KvK Haaglanden 27301624
next prev parent reply other threads:[~2009-10-23 11:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-22 12:23 bridging + load balancing bonding Jasper Spaans
2009-10-22 15:41 ` Eric Dumazet
2009-10-22 17:36 ` Jay Vosburgh
2009-10-22 17:53 ` Eric Dumazet
2009-10-23 11:45 ` Jasper Spaans [this message]
2009-10-23 11:58 ` [PATCH] Modify bonding hash transmit policies to use the packet's source MAC address Jasper Spaans
2009-10-23 12:37 ` Eric Dumazet
2009-10-23 14:08 ` Jasper Spaans
2009-10-23 16:02 ` Eric Dumazet
2009-10-23 16:23 ` Jay Vosburgh
2009-10-24 14:02 ` David Miller
2009-10-23 14:09 ` [PATCH] Remove bond_dev from xmit_hash_policy call Jasper Spaans
2009-10-23 16:05 ` Eric Dumazet
2009-10-23 16:24 ` Jay Vosburgh
2009-10-24 14:00 ` David Miller
2009-10-23 8:38 ` bridging + load balancing bonding Jasper Spaans
2009-10-23 8:55 ` Eric Dumazet
2009-10-23 9:51 ` Jasper Spaans
2009-10-23 9:54 ` Eric Dumazet
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=20091023114511.GA537@spaans.fox.local \
--to=spaans@fox-it.com \
--cc=fubar@us.ibm.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.