On Fri, 8 Mar 2024, at 9:12 AM, Sreedhar M wrote:
> Hi Kerin,
> Thanks for the mail.
>
> I did the flush and clean-up in all my tests.
>
> The main problem is with one of the below use case only other use cases works:
> problem Use case : Say clients sends new connection request every 1
> second , in this case the new connections must continue to be accepted
> even after 15 new connections in 15 seconds because in this use case
> we are sending only one per second. this what expected, this use case
> is not working when we use "update" rule. This use case works only
> when we use "add" in the rule.
Indeed. That is because "add" does not cause the value of the timer to be reset to 10 seconds each time the rule is matched, potentially allowing for elements to persist for a long time after begin added (along with their token bucket states).
Consider the rule that you originally wanted translated:
iptables-translate -A rms0 -p tcp --dport 8000 -m state --state NEW
-m recent --update --seconds 10 --hitcount 15 -j DROP
There you specifed --update, which does have the effect of resetting the value of the timer. So it was that I proposed to use "update" in nftables, to precisely match its behaviour.
>
> Add: The above use case works , when we use "add" in the rule
> nft add set ip filter myrate "{ type ipv4_addr . inet_service; flags
> timeout ; flags dynamic; timeout 10s; }"
> nft add rule ip filter INPUT tcp dport 7880 ct state new add @myrate
> { ip saddr . th dport limit rate over 1/day burst 15 packets }
> counter drop
>
> Update : The above use case won't work , when we use "update" in the rule.
> nft add set ip filter myrate "{ type ipv4_addr . inet_service; flags
> timeout ; flags dynamic; timeout 10s; }"
> nft add rule ip filter INPUT tcp dport 7880 ct state new update
> @myrate { ip saddr . th dport limit rate over 1/day burst 15 packets
> } counter drop
>
> Use cases that works :
> when we send 15 packets in 1 second, we wait for 10 seconds and the
> next will be accepted at 11th second, this perfectly works with
> update.
Yes.
>
> Use cases that do not work :
> Assume we are going to 1 packet every 1 second for an hour , we should
> continuously accept all the new connections as we are sending only one
> per second this is not working when use "update" in the rule , but
> works when use "add" in the rule.
I see. You never wanted the behaviour of --update to begin with, despite implying otherwise.
>
> Fyi, I have tested by adding this also - "tcp flags syn";
>
> Please advise me shall I use "add" in all the cases , so it satisfy
> all the above uses cases.?
Yes. The effect will be that any element added to the set will be evicted after 10 seconds has elapsed, no matter how many more times the rule is matched during the intervening period.
--
Kerin Millar
