Florian Westphal <fw@xxxxxxxxx> wrote on 05/07/2012 01:40:29 PM: > Re: [RFC] [PATCH 0/4] netfilter: "fail-open" feature support for NFQUEUE > > Krishna Kumar <krkumar2@xxxxxxxxxx> wrote: > > Many users of an IBM security product, which uses netfilter's NFQUEUE > > target to process packets in userspace, face a problem of dropped > > connections during heavy load. Incoming packets are queued and > > processed by the security module, which does deep packet analysis to > > decide whether to accept or reject them. However during heavy load, > > NFQUEUE queue (default 1024 entries) fills up and connections fail > > after large number of packets drop during enqueue. Increasing the > > queue size delays the problem and also worsens latency. > > > > This patch set implements a "failopen" support to help keep connections > > open during such failures. This is achieved by allowing acceptance of > > packets temporarily when the queue is full, which enables existing > > connections to be kept alive. Customers prefer this option as similar > > feature is available on other systems. > > > > This patch set implements failopen for NFQUEUE (though a similar patch > > for IPQUEUE is also implemented but not submitted at this time). I will > > submit the iptables changes which controls turning failopen mode on/off > > later. The original requirement for sysctl option is not implemented - > > please let me know whether that is acceptable/preferable. > > I think that exposing this feature as userspace-changeable via netlink > (eg. by adding "NFQA_CFG_FAILOPEN" attribute) rather than via ruleset > would make most sense, as only the application can know wheter it > can cope with missing packets. Thanks for your review. With this change, is there any reason to modify xt_NFQ_info_v2's bypass field, since app can specify this option directly? I tested without this for now and it works. Thanks, - KK -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
