From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: Jasper Spaans <spaans@fox-it.com>, netdev@vger.kernel.org
Subject: Re: bridging + load balancing bonding
Date: Thu, 22 Oct 2009 19:53:50 +0200 [thread overview]
Message-ID: <4AE09C2E.6020702@gmail.com> (raw)
In-Reply-To: <347.1256232960@death.nxdomain.ibm.com>
Jay Vosburgh a écrit :
> 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)?
>
Yes this is probably Jasper problem : catch both direction on same IDS target
Say you have machine A with MAC address MAC_A
and machine B with MAC address MAC_B
(I suspect asymetric routing on A or B is out of the question :) )
A tcp / udp/ whatever protocol flow is running between these two machines
When machine A sends a frame to machine B, Jasper machine
receives a copy of this frame, with eth->src = MAC_A and eth->dst = MAC_B
With current xor algo, we perform a hash on (bond->dev_addr[5] ^ MAC_B[5]) -> IDS X
When machine B sends a frame to machine A, Jasper machine
receives a copy of this frame, with eth->src = MAC_B and eth->dst = MAC_A
With current xor algo, we peform a hash on (bond->dev_addr[5] ^ MAC_A[5]) -> possibly other IDS Y
With his fix, algo is a commutative hash (MAC_A[5] ^ MAC_B[5]) == (MAC_B[5] ^ MAC_A[5])
I suspect multicast/broadcast trafic should be sent to both IDS, so bonding might be inappropriate anyway...
an iptables solution might be more powerfull
next prev parent reply other threads:[~2009-10-22 17:53 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 [this message]
2009-10-23 11:45 ` Jasper Spaans
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=4AE09C2E.6020702@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=fubar@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=spaans@fox-it.com \
/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).