Hi, Holger Eitzenberger wrote: > (replying by private mail) >>> Thank you for pointing it out, I didn't know about conntrack support in ulogd. >>> >>> As far as I understood, IPFIX output in ulogd is in a early stage and >>> don't work. So, I tested ulogd + ctnetlink with null output and it >>> worked very well. IPFIX support in ulog2 in the git tree has been indeed broken/unifinished since long time ago. > I've done an IPFIX implementation a few months ago for ulogd2, but it > currently is of prototype character only, as it only implements IPFIX > over UDP, but SCTP and possibly TCP (+ SSL) are required for a > conforming implementation. I use the "bi-flow" approach of RFC 51303, > but it shouldn't be a problem at all to have it support the single > direction flow approach instead from RFC 5101/5102. I've also have one of my internal tree, I started last summer but thesis has prevent me from working on that. > In general ctnetlink is not a problem here from a performance standpoint, > and I think there is no need for doing that in kernel space. Indeed. > Some bits and pieces may be missing on the kernel side if you need to > classify your flows though. E. g. some IPFIX Aggregrators require the > DSCP value for that. We can post a patch to add the missing stuff to ctnetlink. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
