[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y1fd+DEPZ8xM2x5B@salvia>
Date: Tue, 25 Oct 2022 15:00:40 +0200
From: Pablo Neira Ayuso <pablo@...filter.org>
To: Michael Lilja <michael.lilja@...il.com>
Cc: "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>,
Jonathan Corbet <corbet@....net>,
Jozsef Kadlecsik <kadlec@...filter.org>,
Florian Westphal <fw@...len.de>, netdev@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
netfilter-devel@...r.kernel.org, coreteam@...filter.org
Subject: Re: [PATCH] Periodically flow expire from flow offload tables
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.
View attachment "schedules.nft" of type "text/plain" (769 bytes)
Powered by blists - more mailing lists