From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pablo Neira Ayuso Subject: Re: [PATCH] NETFILTER module xt_hmark new target for HASH MARK Date: Thu, 03 Feb 2011 16:42:03 +0100 Message-ID: <4D4ACCCB.8030902@netfilter.org> References: <1296740050-6311-1-git-send-email-hans.schillstrom@ericsson.com> <1296740050-6311-2-git-send-email-hans.schillstrom@ericsson.com> <4D4AB2D6.7070302@netfilter.org> <1296742995.6662.57.camel@seasc0214> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kaber@trash.net" , "jengelh@medozas.de" , "netfilter-devel@vger.kernel.org" , "netdev@vger.kernel.org" , "hans@schillstrom.com" To: Hans Schillstrom Return-path: Received: from mail.us.es ([193.147.175.20]:44092 "EHLO mail.us.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751735Ab1BCPmM (ORCPT ); Thu, 3 Feb 2011 10:42:12 -0500 In-Reply-To: <1296742995.6662.57.camel@seasc0214> Sender: netfilter-devel-owner@vger.kernel.org List-ID: On 03/02/11 15:23, Hans Schillstrom wrote: > On Thu, 2011-02-03 at 14:51 +0100, Pablo Neira Ayuso wrote: >> On 03/02/11 14:34, Hans Schillstrom wrote: >> this assumption is not valid in NAT handlings. > > That's true, because I want to avoid conntrack > >> If you want consistent hashing with NAT handlings you'll have to make >> this stateful and use the conntrack source and reply directions of the >> original tuples (thus making it stateful). That may be a problem because >> some people may want to use this without enabling connection tracking. > > What about a compilation switch or a sysctl ? or better some option for iptables. >> Are you using this for (uplink) load balancing? > > Actually in both ways > - in front of a bunch of ipvs > - and in the payloads for outgoing traffic. > >> Could you also include one realistic example in the patch description on >> how this is used? > Sure, I guess you mean some nice ascii graphics, > iptables and ip route commands That would be great, for the record. >> If this is accepted, I think this has to be merge with the (already >> overloaded) MARK target. > > I have no opinion about that, others might have. Better put it in the MARK target with a new revision. I think that Patrick is going to ask you this. I don't know why I had the impression that MARK is overload, it's actually fine at a first glance to the code.