netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] netfilter: xtables: add cluster match
Date: Mon, 16 Feb 2009 15:03:51 +0100	[thread overview]
Message-ID: <49997247.3010105@trash.net> (raw)
In-Reply-To: <499971CC.6040903@netfilter.org>

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>>> ip maddr add 01:00:5e:00:01:01 dev eth1
>>> ip maddr add 01:00:5e:00:01:02 dev eth2
>>> arptables -I OUTPUT -o eth1 --h-length 6 \
>>>     -j mangle --mangle-mac-s 01:00:5e:00:01:01
>>> arptables -I INPUT -i eth1 --h-length 6 \
>>>     --destination-mac 01:00:5e:00:01:01 \
>>>     -j mangle --mangle-mac-d 00:zz:yy:xx:5a:27
>>
>> Mhh, is the saving of one or two characters really worth these
>> deviations from the kind-of established naming scheme? Its hard
>> to remember all these minor differences in my opinion.
> 
> Hm, you mean the name "mangle" or the name of the option 
> "--mangle-mac-d"? This is what we currently have in kernel mainline and 
> arptables userspace, it's not my fault :). I can send you a patch to fix 
> it with a consistent naming without breaking backward compatibility both 
> in kernel and user-space.

Great, I wasn't aware that this already existed in userspace :)

>>> In the case of TCP connections, pickup facility has to be disabled
>>> to avoid marking TCP ACK packets coming in the reply direction as
>>> valid.
>>>
>>> echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
>>
>> I'm not sure I understand this. You *don't* want to mark them
>> as valid, and you need to disable pickup for this?
> 
> If TCP pickup is enabled, one TCP ACK packet coming in the reply 
> direction enters TCP ESTABLISHED state. Since that's a valid 
> state-transition, the cluster match will consider that this is part of a 
> connection that this node is handling since it's a valid 
> state-transition. The cluster match does not mark packets that trigger 
> invalid state transitions.

Why use conntrack at all? Shouldn't the cluster match simply
filter out all packets not for this cluster and thats it?
You stated it needs conntrack to get a constant tuple, but I
don't see why the conntrack tuple would differ from the data
that you can gather from the packet headers.

>>> echo +2 > /proc/sys/net/netfilter/cluster/$PROC_NAME
>>
>> Does this provide anything you can't do by replacing the rule
>> itself?
> 
> Yes, the nodes in the cluster are identifies by an ID, the rule allows 
> you to specify one ID. Say you have two cluster nodes, one with ID 1, 
> and the other with ID 2. If the cluster node with ID 1 goes down, you 
> can echo +1 to node with ID 2 so that it will handle packets going to 
> node with ID 1 and ID 2. Of course, you need conntrackd to allow node ID 
> 2 recover the filtering.

I see. That kind of makes sense, but if you're running a
synchronization daemon anyways, you might as well renumber
all nodes so you still have proper balancing, right?

> Now, I see that there is a possible optimization that consists of 
> checking if one node has its node mask all set with regards to the total 
> number of nodes, so that hashing can be skipped. But that's something 
> that we can add later I think.

Indeed.



  reply	other threads:[~2009-02-16 14:03 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-14 19:29 [PATCH] netfilter: xtables: add cluster match Pablo Neira Ayuso
2009-02-14 20:28 ` Jan Engelhardt
2009-02-14 20:42   ` Pablo Neira Ayuso
2009-02-14 22:31     ` Jan Engelhardt
2009-02-14 22:32       ` Jan Engelhardt
2009-02-16 10:56 ` Patrick McHardy
2009-02-16 14:01   ` Pablo Neira Ayuso
2009-02-16 14:03     ` Patrick McHardy [this message]
2009-02-16 14:30       ` Pablo Neira Ayuso
2009-02-16 15:01         ` Patrick McHardy
2009-02-16 15:14         ` Pablo Neira Ayuso
2009-02-16 15:10           ` Patrick McHardy
2009-02-16 15:27             ` Pablo Neira Ayuso
2009-02-17 10:46             ` Pablo Neira Ayuso
2009-02-17 10:50               ` Patrick McHardy
2009-02-17 13:50                 ` Pablo Neira Ayuso
2009-02-17 19:45                   ` Vincent Bernat
2009-02-18 10:14                     ` Patrick McHardy
2009-02-18 10:13                   ` Patrick McHardy
2009-02-18 11:06                     ` Pablo Neira Ayuso
2009-02-18 11:14                       ` Patrick McHardy
2009-02-18 17:20                       ` Vincent Bernat
2009-02-18 17:25                         ` Patrick McHardy
2009-02-18 18:38                           ` Pablo Neira Ayuso
2009-02-16 17:17         ` Jan Engelhardt
2009-02-16 17:13     ` Jan Engelhardt
2009-02-16 17:16       ` Patrick McHardy
2009-02-16 17:22         ` Jan Engelhardt
  -- strict thread matches above, loose matches on Subject: below --
2009-02-16  9:23 Pablo Neira Ayuso
2009-02-16  9:31 ` Pablo Neira Ayuso
2009-02-16 12:13   ` Jan Engelhardt
2009-02-16 12:17     ` Patrick McHardy
2009-02-16  9:32 Pablo Neira Ayuso
2009-02-19 23:14 Pablo Neira Ayuso
2009-02-20  9:24 ` Patrick McHardy
2009-02-20 13:15   ` Pablo Neira Ayuso
2009-02-20 13:48     ` Patrick McHardy
2009-02-20 16:52       ` Pablo Neira Ayuso
2009-02-20 20:50 Pablo Neira Ayuso
2009-02-20 20:56 ` Pablo Neira Ayuso
2009-02-23 10:13 Pablo Neira Ayuso
2009-02-24 13:46 ` Patrick McHardy
2009-02-24 14:05   ` Pablo Neira Ayuso
2009-02-24 14:06     ` Patrick McHardy
2009-02-24 23:13       ` Pablo Neira Ayuso
2009-02-25  5:52         ` Patrick McHardy
2009-02-25  9:42           ` Pablo Neira Ayuso
2009-02-25 10:20             ` Patrick McHardy
2009-03-16 16:11 ` Patrick McHardy

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=49997247.3010105@trash.net \
    --to=kaber@trash.net \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.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 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).