How does loading an nftables ruleset with `nft -f rules.nft` differ from applying the same rules one `nft add` command at a time, and why do production nftables files usually begin with `flush ruleset`?

## One transaction versus many nftables talks to the kernel over netlink, and its unit of change is a transaction. When you run `nft add rule ...`, the tool opens a transaction, puts one change in it and commits. Run twenty such commands and you have twenty commits, and the packet path is live between every pair of them. `nft -f rules.nft` parses the entire file first, turns it into one batch of netlink messages, and commits once. Two consequences follow, and both are the reason experienced people never build a firewall interactively on a machine they care about: 1. **All or nothing.** If line 40 has a typo, or refers to a chain that does not exist, or uses a match the kernel does not support, the commit fails and *nothing* from the file is applied. The ruleset that was loaded before is still loaded. You get an error message and a working host. 2. **No intermediate states.** There is never a moment when the drop policy is in force but the rule permitting your SSH session has not landed yet, or when half the NAT rules exist. Anyone who has locked themselves out of a remote box by adding a default-drop policy before the accept rules understands why this matters. ## Why the file starts with `flush ruleset` Loading is additive, not declarative. The file syntax looks declarative: ``` table inet filter { chain input { type filter hook input priority filter; policy drop; ct state established,related accept tcp dport 22 accept } } ``` but `table inet filter { ... }` means *ensure this table exists and apply what follows to it*. Loading the same file twice does not replace the chain; it appends its two rules a second time. The chain now has four rules, the duplicates are harmless in behaviour but ruinous for review, and after a few reloads nobody can read the output of `nft list ruleset` any more. `flush ruleset` as the first line removes every table in every family, and because it is part of the same transaction the removal and the reload commit together. The host is never briefly ruleless. ## Scoping the flush `flush ruleset` is a big hammer: it also deletes tables you did not write. Container runtimes, orchestrators and firewall frontends install their own tables, and wiping them mid-flight breaks connectivity for workloads that had nothing to do with your change. When something else shares the host, delete only your own table. The classic idiom makes the delete safe even on a first run: ``` table inet myfilter delete table inet myfilter table inet myfilter { ... } ``` The bare `table` line creates it if absent so the `delete` cannot fail on a missing object. nft 1.0.8 and later add `destroy table inet myfilter`, which deletes without erroring when the table is not there and expresses the same intent in one line. ## Check before you commit ```bash nft -c -f /etc/nftables.conf ``` `-c` (`--check`) parses and validates against the running kernel without applying anything. It catches typos and unsupported constructs. It cannot tell you the ruleset is *correct* — a perfectly valid file can still lock you out — so on a remote host the belt-and-braces move remains a scheduled rollback: arrange for the previous ruleset to be restored in a few minutes unless you cancel it. ## What a reload does not carry over A flush-and-reload builds fresh objects, so anything accumulated at runtime is gone: - **Counters** reset to zero. `nft -s list ruleset` produces a stateless dump precisely so a saved file does not carry stale counter values back in. - **Set contents** added with `nft add element` disappear unless the file declares them. A dynamically grown ban list starts empty again. - Connection tracking state is a separate subsystem and survives, which is why an established SSH session usually keeps working across a reload as long as the new ruleset accepts `ct state established,related`. ## `nft list ruleset` is the source of truth Whatever your files say, the loaded ruleset is what the kernel holds, and `nft list ruleset` prints it in full — every family, table, chain, set and rule, in one output. Add `-a` for handles when you need to delete a specific rule. Persistence is a separate concern: the kernel forgets everything at reboot, so the ruleset lives in a file (`/etc/nftables.conf` on Debian-family systems, `/etc/sysconfig/nftables.conf` on RHEL-family) loaded at boot by the `nftables` service. Saving with `nft list ruleset > /etc/nftables.conf` works, but a hand-written, reviewed, version-controlled file is the better artefact — and remember the saved dump needs the `flush ruleset` line put back at the top.