Re: [PATCH 1/2] netfilter/xt_hashlimit: new feature/algorithm for xt_hashlimit
On 09/04/2017 06:14 AM, Pablo Neira Ayuso wrote: > Sounds good, applied, thanks. > > A couple of questions: Does it really make sense to expose > --hashlimit-rate-interval or are you using 1 second always there? I > always wonder if it makes sense to expose yet another toggle that it's > not clear to me how the user would take advantage from this. > > Just curious here. Thank you Pablo. I generally just let rate-interval to default to 1, but I've added the toggle to give the user more control on how often to sample the packet rate. This wasn't an option before since we would always keep "delta" as 1 jiffy, but that is not the case in the new algorithm. Hence I have exposed it as an option to the user. Also, it looks like I broke the build on ARM and m68k arch. This is because of the u64 division issue (sorry about that). I have sent another patch to fix the problem "[PATCH] netfilter: xt_hashlimit: fix 64 bit division compile error". Please apply and send to net-next. Thanks, Vishwanath -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] netfilter/xt_hashlimit: new feature/algorithm for xt_hashlimit
On Mon, Sep 04, 2017 at 12:14:33PM +0200, Pablo Neira Ayuso wrote: > On Fri, Aug 18, 2017 at 04:58:59PM -0400, Vishwanath Pai wrote: > [...] > > The main difference between the existing algorithm and the new one is > > that the existing algorithm rate-limits the flow whereas the new > > algorithm does not. Instead it *classifies* the flow based on whether > > it is above or below a certain rate. I will demonstrate this with an > > example below. Let us assume this rule: > > > > iptables -A INPUT -m hashlimit --hashlimit-above 10/s -j new_chain > > > > If the packet rate is 15/s, the existing algorithm would ACCEPT 10 > > packets every second and send 5 packets to "new_chain". > > > > But with the new algorithm, as long as the rate of 15/s is sustained, > > all packets will continue to match and every packet is sent to new_chain. > > Sounds good, applied, thanks. BTW, for the record, I have rename this patch title to: netfilter: xt_hashlimit: add rate match mode -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] netfilter/xt_hashlimit: new feature/algorithm for xt_hashlimit
On Fri, Aug 18, 2017 at 04:58:59PM -0400, Vishwanath Pai wrote: [...] > The main difference between the existing algorithm and the new one is > that the existing algorithm rate-limits the flow whereas the new > algorithm does not. Instead it *classifies* the flow based on whether > it is above or below a certain rate. I will demonstrate this with an > example below. Let us assume this rule: > > iptables -A INPUT -m hashlimit --hashlimit-above 10/s -j new_chain > > If the packet rate is 15/s, the existing algorithm would ACCEPT 10 > packets every second and send 5 packets to "new_chain". > > But with the new algorithm, as long as the rate of 15/s is sustained, > all packets will continue to match and every packet is sent to new_chain. Sounds good, applied, thanks. A couple of questions: Does it really make sense to expose --hashlimit-rate-interval or are you using 1 second always there? I always wonder if it makes sense to expose yet another toggle that it's not clear to me how the user would take advantage from this. Just curious here. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
