All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.