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
