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.
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.
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.
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.?
Thanks
Sreedhar
On Fri, Mar 8, 2024 at 8:08 AM Kerin Millar <kfm@xxxxxxxxxxxxx> wrote:
>
> On Fri, 8 Mar 2024, at 7:26 AM, Sreedhar M wrote:
> > Hi Kerin,
> > Thanks again .
> >
> > I have changed it for two reasons , because of the errors
> > nft add set ip filter myrate "{ type ipv4_addr . inet_service; flags
> > timeout ; }"
> > nft add rule ip filter INPUT tcp dport 8000 ct state new update
> > @myrate { ip saddr . th dport timeout 10s limit rate over 1/day burst
> > 15 packets } counter drop
> > Error: Could not process rule: Invalid argument
>
> Hmm. I would have to go over the release notes to be sure, but it may be that that it has not always been possible to incorporate a timeout as part of the rule. Should that be the case, defining the timeout as part of the set declaration - as you did - is acceptable.
>
> > add rule ip filter INPUT tcp dport 8000 ct state new update @myrate {
> > ip saddr . th dport timeout 10s limit rate over 1/day burst 15 packets
> > } counter drop
> >
> > After the above error I have changed it to below , In one use case -
> > the below never resets , Say If I send only one message per second all
> > the time , the below rule will stop at 10th second and the next
> > message will be accepted only after 10 seconds. This is not correct
> > when we are sending one 1 message per second it has to accept it ,
> > because we are not sending all the 15 messages in one second.
>
> This should definitely not be the case. The bucket will have a capacity of 15 tokens and they must all be consumed before the drop verdict can be reached (the 16th attempt will be denied). Please review your testing methodology carefully and be sure to flush the set before you begin your testing procedure:
>
> nft flush set ip filter ratelimit
>
> Incidentally, it is worth worth noting that the "new" ctstate can be satisfied under conditions pertaining to all three of the following things:
>
> - the content of the packet being considered
> - the entries that already exist in the kernel's conntrack table
> - the state of the kernel's "nf_conntrack_tcp_loose" sysctl
>
> I consider it highly unlikely that those considerations would have affected your testing. Nevertheless, in the interest of certainty, you may find it useful to include "tcp flags syn" as a condition of your rule while you are testing.
>
> --
> Kerin Millar
--
Best Regards
Sreedhar
