[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter
Subject:    Re: nftables rate limiting per multiple seconds
From:       Sreedhar M <sreemtech () gmail ! com>
Date:       2024-03-08 11:44:31
Message-ID: CANvpR2BZ7xjjbJz6P-THeSHw-uTVuOWTPfeBX98kAKp_49TL2w () mail ! gmail ! com
[Download RAW message or body]

Great Kerin. Good to know the optional.
Thanks again.

Best Regards
Sreedhar


On Fri, Mar 8, 2024 at 10:34 AM Kerin Millar <kfm@plushkava.net> wrote:
> 
> On Fri, 8 Mar 2024, at 10:19 AM, Sreedhar M wrote:
> > Great Kerin. Thank you so much for the support.
> > 
> > With the below rules specially using 'add' and all my uses cases are working.
> > 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
> 
> One more thing occurs to me. Now that you are using "add" and, given that "1/day" \
> might otherwise appear confusing in the course of reviewing a ruleset, you could \
> probably get away with changing the element template to: 
> { ip saddr . th dport limit rate over 6/minute burst 15 packets }
> 
> Consider it optional; the behaviour should not change at all. Still, it does, \
> perhaps, better hint at the underlying policy i.e. something should happen after 10 \
> (60/6) seconds. Normally, that would be the bucket being credited with a token but \
> it is my understanding that the timeout policy should prevail. 
> --
> Kerin Millar



--
Best Regards
Sreedhar


[prev in list] [next in list] [prev in thread] [next in thread]