Re: named counters vs flush ruleset

[Pablo Neira Ayuso <pablo@netfilter.org>]

Hi Victor,

On Sun, Feb 09, 2025 at 11:58:56AM +0100, Victor Julien wrote:
> On 08-02-2025 22:49, Pablo Neira Ayuso wrote:
> > On Sat, Feb 08, 2025 at 03:35:27PM +0100, Victor Julien wrote:
> > > Hi all,
> > > 
> > > I'm working on finally supporting nftables in Vuurmuur.
> > > 
> > > In the iptables support, I have special rules per interface to get per iface
> > > packets and bytes. Essentially my tool reads the iptables -vnL output and
> > > parses all the things. When a user applies a ruleset change, Vuurmuur reads
> > > the most current values, constructs a new input file to `iptables-restore`
> > > and loads the rules. This works but is tedious, and also lacks some
> > > precision as we are not counting the packets/bytes while Vuurmuur is
> > > working.
> > > 
> > > In the nftables support, I'm more or less looking at the same logic. The
> > > ruleset is build as a .nft file that is loaded with `nft -f`.
> > > 
> > > Now I found the the named counter feature, and also the json output `nft -j
> > > list counters`. This combination seems perfect.
> > > 
> > > I guess my main question is if we can make these counters persistent
> > > somehow. As part of the ruleset reload, I issue a `flush ruleset`, which
> > > also removes the counters.
> > > 
> > > So can we make counters survive a `flush ruleset`, or is there a better way
> > > to load a new ruleset?
> > 
> > Would it work for you to destroy all other existing objects (not the
> > table and counters) instead?
> 
> Thanks Pablo. Here's what I'm thinking now:
> 
> I create an additional table "vrmr_accounting"
> 
> table ip vrmr_accounting {
>         counter vrmr_enp1s0 {
>                 packets 17546 bytes 3901328
>         }
> 
>         chain INPUT {
>                 type filter hook input priority -100; policy accept;
>                 iifname "enp1s0" counter name "vrmr_enp1s0" comment
> "lan-nic"
>         }
> 
>         chain OUTPUT {
>                 type filter hook output priority dstnat; policy accept;
>                 oifname "enp1s0" counter name "vrmr_enp1s0"
>         }
> 
>         chain FORWARD {
>                 type filter hook forward priority -100; policy accept;
>                 iifname "enp1s0" counter name "vrmr_enp1s0"
>                 oifname "enp1s0" counter name "vrmr_enp1s0"
>         }
> }
> 
> Then I create regular a regular filter table, where the normal rules are
> created. My assumption is that due to the lower priority value the
> `vrmr_accounting` table goes first in the processing.

I see, you are using a table that contains rules for metering only.

> In my reload instead of a `flush ruleset`, I do:
> 
> # clear existing tables/rules
> destroy table ip filter
> ...
> add table ip filter
> add chain ip filter INPUT { type filter hook input priority 0; policy drop;
> }
> add chain ip filter OUTPUT { type filter hook output priority 0; policy
> drop; }
> add chain ip filter FORWARD { type filter hook forward priority 0; policy
> drop; }

Maybe you could use?

  flush table ip filter

to leave the table and chain in place. Similar semantics to
iptables -F.

> ...
> # clear accounting chains (incl rules), but not the counter itself
> add table ip vrmr_accounting
> destroy chain ip vrmr_accounting INPUT
> destroy chain ip vrmr_accounting OUTPUT
> destroy chain ip vrmr_accounting FORWARD
> add chain ip vrmr_accounting INPUT { type filter hook input priority -100;
> policy accept; }
> add chain ip vrmr_accounting OUTPUT { type filter hook output priority -100;
> policy accept; }
> add chain ip vrmr_accounting FORWARD { type filter hook forward priority
> -100; policy accept; }
> ...
> add counter ip vrmr_accounting vrmr_enp1s0
> add rule ip vrmr_accounting INPUT iifname "enp1s0" counter name vrmr_enp1s0
> comment lan-nic
> ...
> 
> This appears to leave the counters intact.
> 
> Does this make sense to you?

I wonder if you could consolidate all in one single table:

  flush table ip filter

leaves table, chain and counters intact.