netdev - Re: bridging + load balancing bonding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AE07D3C.3040702@gmail.com>
Date:	Thu, 22 Oct 2009 17:41:48 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jasper Spaans <spaans@...-it.com>
CC:	netdev@...r.kernel.org
Subject: Re: bridging + load balancing bonding

Jasper Spaans a écrit :
> Hi,
> 
> We're using the following setup for bonding and bridging, to be able to put
> large amounts of data through multiple IDS analyzers:
> 
>                              +---[br0]----+     +--- eth1 ---(IDS machine 1)
> (Span port from switch) -- eth0          bond0--+
>                                                 +--- eth2 ---(IDS machine 2)
> 
> eth0 receives network traffic, which should be passed to machines which are
> connected to eth1 and eth2. These machines run an IDS package, and there are
> two of those for performance reasons.
> 
> bond0 is configured to load balance the packets using "balance-xor", in this
> case combined with xmit_hash_policy layer2.
> 
> However, we're seeing problems: packets from one flow do not end up at the
> same IDS machine.  This is because this selection is not based on the source
> _and_ destination mac addresses of the original packet, but on the mac
> address of the bonding device and the destination mac address of the
> package.
> 
> This is also clear in the code:
> For example, in bond_main.c, in bond_xmit_hash_policy_l2:
> 	return (data->h_dest[5] ^ bond_dev->dev_addr[5]) % count;
> 
> Changing this to
> 	return (data->h_dest[5] ^ data->h_source[5]) % count;
> fixes our problems, but is this harmful for packets originating locally (or
> being routed?)
> 
> If not, can this be applied? Or does anyone have other ideas?
> 

Hi Jasper

Very nice setup, and nice finding.

Dont locally generated (or outed) packets have h_source set to bond_dev->dev_addr anyway ?

So your solution might be the right fix...

About other ideas... I was thinking of TEE target (not in mainline unfortunatly) :

iptables -t mangle -A PREROUTING -i eth0 <some hash on mac addr>  -j TEE --gateway 192.168.99.1  # IDS1
iptables -t mangle -A PREROUTING -i eth0 !<some hash on mac addr>  -j TEE --gateway 192.168.99.2  # IDS2


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html