[PATCH] add TCP protocol state event groups

Patrick McHardy kaber at trash.net
Mon Jul 2 17:36:05 CEST 2007


Holger Eitzenberger wrote:
> Patrick McHardy wrote:
> 
>> I can see that this is useful, but one group per protocol state
>> sounds rather excessive, I would expect that we could group them
>> more logically, maybe "connection setup, teardown and updates"?
>> Which states is conntrackd particulary interested in?
> 
> 
>> I would also like to hear from Holger whether his conntrack daemon
>> could make use of a mechnism like this too and if the filtering
>> capabilities you propose will do.
> 
> 
> ctsyncd currently does quite some per-protocol filtering, e.g. TCP
> connections currently get synced only after being in the ESTABLISHED
> state and deleted on the slave side if the teardown event is received.
> This greatly reduces the number of events which are send to the ctsyncd
> peer.
> 
> Although ctsyncd does not have a performance problem at all even if I
> run it against our Spirent performance system I generally like the idea
> of doing some of the filtering in kernelspace.  Though I would leave the
> userspace filtering code as a fallback solution in place.


I agree that kernel space filtering is useful, I'm just not convinced
of this particular approach. I would much rather like to see something
that is not specific to nf_conntrack_netlink and can be specified per
socket, something like bpf for netlink.

> As of July I have a new colleague which hopefully takes over some of the
> workloads I currently have.  My plan therefore for ctsyncd is to finally
> improve filtering capability of ctsyncd and make if configurable, as
> currently most of the filtering code is still hardcoded.  My plan is
> also to improve the partnership with keepalived et all, basically making
> this part more configurable too.  This version will then be my 1.0
> release, as it currently runs fine for serveral months now on our ASG
> products.
> 
> So hopefully I am able to release ctsyncd 1.0 into the public within the
> next few weeks, especially with Netfilter Workshop in mind.


Great.





More information about the netfilter-devel mailing list