Re: Reliably flushing individual tables in nftables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Oct 8, 2022 at 1:39 PM Kevin P. Fleming <kevin@xxxxxxx> wrote:
>
> On Sat, Oct 8, 2022 at 12:47 PM Eugene Crosser <crosser@xxxxxxxxxxx> wrote:
> >
> > On 08/10/2022 15:04, Kevin P. Fleming wrote:
> > > On my firewall machines the nft ruleset contains tables I created
> > > (using a systemd unit similar to Debian's nftables.service unit) and
> > > also tables created by Tailscale.
> > [...]
> > > I've got an ugly workaround at the moment but I'd like to avoid that.
> > > I think the simplest solution here would be to enhance 'nft flush
> > > table <table>' to not report an error if the table does not exist,
> > > since in the end that was almost the same goal as the command itself.
> > > Does this seem reasonable?
> >
> > You can define the table and then remove it in the next line. Definition will do
> > nothing if the table exists, and will create and empty one when it does not.
>
> That's a great tip! Thanks.

Confirmed. A ruleset file like this:

add table inet _test
delete table inet _test
table inet _test {
    ... sets and rules here ...
}

This works fine with '--check', and works fine during system startup
as well. Note that 'delete table ...' is required instead of 'flush
table ...' if the table contains sets that will be recreated later in
the file; the other alternative would be to use 'flush set table ...'
for each set-in-table combination, but I opted to just use 'delete'
instead. It is also important to use 'add table ...' and not 'create
table ...', as the latter will fail if the table already exists.



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux