From: Pablo Neira Ayuso <pablo@netfilter.org>
To: ѽ҉ᶬḳ℠ <vtol@gmx.net>
Cc: netfilter@vger.kernel.org
Subject: Re: [nftables] netdev rate limiting | timeouts rfq
Date: Mon, 28 Sep 2020 19:01:36 +0200 [thread overview]
Message-ID: <20200928170136.GA4278@salvia> (raw)
In-Reply-To: <1d252cae-37cc-f457-932c-2c1ada59e2a0@gmx.net>
On Mon, Sep 28, 2020 at 04:47:00PM +0000, ѽ҉ᶬḳ℠ wrote:
> To get a flexible evaluation period for the count value:
>
> * ct state { new , invalid } update @glv4 { ip saddr ct count over 50
> timeout 1s } log flags all prefix "glv4 DROP: " drop
>
> update set element for any saddr that exceeds the count of 50 within 1 s for
> ct state new | invalid
>
>
> * ct state { new , invalid } update @glv4 { ip saddr ct count over 75
> timeout 1s } log flags all prefix "glv4 DROP: " drop
>
> update set element for any saddr that exceeds the count of 75 within 1 h for
> ct state new | invalid
>
>
> * ct state { new , invalid } update @glv4 { ip saddr ct count over 75
> timeout 1s } log flags all prefix "glv4 DROP: " drop
>
> update set element for any saddr that exceeds the count of 150 within 1 d
> for ct state new | invalid
Thanks, these are looking better, although still not correct.
Two issues:
* 'ct count' relies on the connection tracking table. This is counting
the number of existing connections in this table according to your
key, ie. ip saddr. You do not have to specify timeouts here because
it is the connection tracking time that governs when the conntrack
entries expire.
* You have to use 'add' instead of 'update'. Update makes sense to
refresh timeouts when they are in place, but there is no timeouts in
this case.
Therefore, make sure you define the dynamic set with not timeouts at
all when combining this with ct count.
Using 'update' in your rule with ct count and/or 'timeout' in your set
definition will make you hit "Operation not supported".
Error reporting will get better sooner or later to provide more hints
on why this makes no sense, meanwhile, documentation will probably
help fill the gap.
next prev parent reply other threads:[~2020-09-28 17:01 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-22 22:49 [nftables] netdev rate limiting | timeouts rfq ѽ҉ᶬḳ℠
2020-09-23 8:30 ` Pablo Neira Ayuso
2020-09-28 11:02 ` ѽ҉ᶬḳ℠
2020-09-28 11:52 ` Pablo Neira Ayuso
2020-09-28 12:08 ` ѽ҉ᶬḳ℠
2020-09-28 12:24 ` Pablo Neira Ayuso
2020-09-28 13:10 ` ѽ҉ᶬḳ℠
2020-09-28 15:43 ` Pablo Neira Ayuso
2020-09-28 16:03 ` ѽ҉ᶬḳ℠
2020-09-28 16:23 ` Pablo Neira Ayuso
2020-09-28 16:47 ` ѽ҉ᶬḳ℠
2020-09-28 17:01 ` Pablo Neira Ayuso [this message]
2020-09-28 17:38 ` ѽ҉ᶬḳ℠
2020-09-28 17:56 ` Pablo Neira Ayuso
2020-09-28 18:15 ` ѽ҉ᶬḳ℠
2020-09-28 19:19 ` ѽ҉ᶬḳ℠
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200928170136.GA4278@salvia \
--to=pablo@netfilter.org \
--cc=netfilter@vger.kernel.org \
--cc=vtol@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.