From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Michael Lilja <michael.lilja@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Jonathan Corbet <corbet@lwn.net>,
Jozsef Kadlecsik <kadlec@netfilter.org>,
Florian Westphal <fw@strlen.de>,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, netfilter-devel@vger.kernel.org,
coreteam@netfilter.org
Subject: Re: [PATCH] Periodically flow expire from flow offload tables
Date: Tue, 25 Oct 2022 15:00:40 +0200 [thread overview]
Message-ID: <Y1fd+DEPZ8xM2x5B@salvia> (raw)
In-Reply-To: <381FF5B6-4FEF-45E9-92D6-6FE927A5CC2D@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
Hi,
On Tue, Oct 25, 2022 at 02:36:35PM +0200, Michael Lilja wrote:
> Hi,
>
> No problem. Here is a snippet of the rulesets in play. I simplified it because there are a lot of devices and a lot of schedules per device. The ‘mark’ is set by userspace so not all flow types are offloaded, that is controlled by userspace:
>
> - - - - snip start - - - -
> table inet fw4 {
> flowtable ft {
> hook ingress priority filter
> devices = { lan1, lan2, wan }
> flags offload
> }
>
> chain mangle_forward {
> type filter hook forward priority mangle; policy
> meta mark set ct mark
> meta mark 0x00000000/16 queue flags bypass to 0
> }
>
>
> chain my_devices_rules {
> ether saddr 96:68:97:a7:e8:a7 jump fw_p0_dev0 comment “Device match”
> }
>
> chain fw_p0_dev0 {
> meta time >= "2022-10-09 18:46:50" meta time < "2022-10-09 19:16:50" counter packets 0 bytes 0 drop comment "!Schedule OFFLINE override"
> meta day “Tuesday" meta hour >= "06:00" meta hour < "07:00" drop
> }
>
> chain forward {
> type filter hook forward priority filter; policy accept;
> jump my_devices_rules
> }
>
> chain my_forward_offload {
> type filter hook forward priority filter + 1; policy accept;
> meta mark != 0x00000000/16 meta l4proto { tcp, udp } flow add @ft
> }
>
> chain mangle_postrouting {
> type filter hook postrouting priority mangle; policy accept;
> ct mark set meta mark
> }
> - - - - snip end - - - -
>
> The use case is that I have schedules per device to control when
> they are allowed access to the internet and if the flows are
> offloaded they will not get dropped once the schedule kicks in.
Thanks for explaining.
I suggest to move your 'forward' chain to netdev/ingress using priority
filter - 1
so the time schedule evaluation is always done before the flowtable
lookup, that is, schedules rules will be always evaluated.
In your example, you are using a linear ruleset, which might defeat
the purpose of the flowtable. So I'm attaching a new ruleset
transformed to use maps and the ingress chain as suggested.
[-- Attachment #2: schedules.nft --]
[-- Type: text/plain, Size: 768 bytes --]
table netdev filter {
map ether_to_chain {
typeof ether saddr : verdict
elements = { 96:68:97:a7:e8:a7 comment "Device match" : jump fw_p0_dev0 }
}
map schedule_time {
typeof meta time : verdict
flags interval
counter
elements = { "2022-10-09 18:46:50" - "2022-10-09 19:16:50" comment "!Schedule OFFLINE override" : drop }
}
map schedule_day {
typeof meta day . meta hour : verdict
flags interval
counter
elements = { "Tuesday" . "06:00" - "07:00" : drop }
}
chain fw_p0_dev0 {
meta time vmap @schedule_time
meta day . meta hour vmap @schedule_day
}
chain my_devices_rules {
ether saddr vmap @ether_to_chain
}
chain ingress {
type filter hook ingress device eth0 priority filter; policy accept;
jump my_devices_rules
}
}
next prev parent reply other threads:[~2022-10-25 13:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-23 17:16 [PATCH] Periodically flow expire from flow offload tables Michael Lilja
2022-10-25 11:05 ` Pablo Neira Ayuso
2022-10-25 12:36 ` Michael Lilja
2022-10-25 13:00 ` Pablo Neira Ayuso [this message]
2022-10-25 13:32 ` Michael Lilja
2022-10-26 10:50 ` Pablo Neira Ayuso
2022-10-26 17:36 ` Michael Lilja
2022-10-26 19:40 ` Michael Lilja
2022-11-02 18:52 ` Pablo Neira Ayuso
2022-11-02 19:52 ` Michael Lilja
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=Y1fd+DEPZ8xM2x5B@salvia \
--to=pablo@netfilter.org \
--cc=corbet@lwn.net \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fw@strlen.de \
--cc=kadlec@netfilter.org \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.lilja@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pabeni@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).