conntrack-tool question for contribution.

conntrack-tool question for contribution.

[Miguel Angel Ajo Pelayo]

I was considering the possibility of making an small contribution to
conntrack-tool
to allow the batching of commands in a single conntrack-tool call.

Specifically I'm interested in batching delete commands.

In some of the neutron reference implementations we make use of conntrack-tool
to target and kill any active connection when security group rules are removed.

That sometimes expands in thousands of calls due to combinations (worst
scenario is n_port^2 calls for a very common type of rule we have).


So I was considering two options:

1) Adding a mode to accept conntrack-tool actions via stdin
2) Accepting the cmdline notation of separating multiple command lines
with "--" in a single call to conntrack tool.


Any thoughts or recommendations in this regard?


[1] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/ip_conntrack.py#n32

Re: conntrack-tool question for contribution.

[Arturo Borrero Gonzalez]

On 16 March 2016 at 12:16, Miguel Angel Ajo Pelayo <majopela@redhat.com> wrote:
> I was considering the possibility of making an small contribution to
> conntrack-tool
> to allow the batching of commands in a single conntrack-tool call.
>
> Specifically I'm interested in batching delete commands.
>
> In some of the neutron reference implementations we make use of conntrack-tool
> to target and kill any active connection when security group rules are removed.
>
> That sometimes expands in thousands of calls due to combinations (worst
> scenario is n_port^2 calls for a very common type of rule we have).
>
>
> So I was considering two options:
>
> 1) Adding a mode to accept conntrack-tool actions via stdin
> 2) Accepting the cmdline notation of separating multiple command lines
> with "--" in a single call to conntrack tool.
>
>
> Any thoughts or recommendations in this regard?
>

Hi Miguel Angel,

I wonder if the kernel support batching of messages in ctnetlink. You
may want to check the sources [0][1].

Perhaps you want the conntrack utility to simply chain a lot of calls
to the kernel rather than a proper batch of messages. In this case, I
don't know exactly why but I like more your 2) option.

[0] http://lxr.free-electrons.com/source/net/netfilter/nf_conntrack_netlink.c#L3260
[1] http://lxr.free-electrons.com/source/net/netfilter/nfnetlink.c#L282

-- 
Arturo Borrero González
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: conntrack-tool question for contribution.

[Miguel Angel Ajo Pelayo]

On Fri, Mar 18, 2016 at 12:59 PM, Arturo Borrero Gonzalez
<arturo.borrero.glez@gmail.com> wrote:
> On 16 March 2016 at 12:16, Miguel Angel Ajo Pelayo <majopela@redhat.com> wrote:
>> I was considering the possibility of making an small contribution to
>> conntrack-tool
>> to allow the batching of commands in a single conntrack-tool call.
>>
>> Specifically I'm interested in batching delete commands.
>>
>> In some of the neutron reference implementations we make use of conntrack-tool
>> to target and kill any active connection when security group rules are removed.
>>
>> That sometimes expands in thousands of calls due to combinations (worst
>> scenario is n_port^2 calls for a very common type of rule we have).
>>
>>
>> So I was considering two options:
>>
>> 1) Adding a mode to accept conntrack-tool actions via stdin
>> 2) Accepting the cmdline notation of separating multiple command lines
>> with "--" in a single call to conntrack tool.
>>
>>
>> Any thoughts or recommendations in this regard?
>>
>
> Hi Miguel Angel,
>
> I wonder if the kernel support batching of messages in ctnetlink. You
> may want to check the sources [0][1].
>
> Perhaps you want the conntrack utility to simply chain a lot of calls
> to the kernel rather than a proper batch of messages. In this case, I
> don't know exactly why but I like more your 2) option.
>
> [0] http://lxr.free-electrons.com/source/net/netfilter/nf_conntrack_netlink.c#L3260
> [1] http://lxr.free-electrons.com/source/net/netfilter/nfnetlink.c#L282
>

Hmm, I will have a look into [0][1], I guess the gain of chaining calls
is  saving overhead, right?.

I put 2 up for discussion as 2nd option because of the cmdline limit which
(I guess) is going to be more than enough generally, and because the
ipset cmdline tools accept stdin batches too.

I guess 1 makes chaining (if possible) more complicated, but it could
still be done (less straight forward) in smaller chains, by chaining whatever
you can read without blocking.