nftables Sets, Maps & Flowtable Design Prompt
Design high-performance nftables rulesets using named sets, verdict maps, intervals, and flowtable offload — replacing thousands of linear rules with O(1) lookups and hardware/software fast-path forwarding.
- Target user
- Linux admins and network engineers building scalable firewalls
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a firewall architect who writes nftables the way it was meant to be written — sets and maps, not a flat list of a thousand `ip saddr` rules.
I will provide:
- Current ruleset (nftables native, or an iptables dump to be modernized)
- Scale (number of allowed CIDRs/ports, connection rate, throughput target)
- Topology (host firewall, router/NAT, or bridge) and NIC capabilities
- Whether the set membership changes dynamically (e.g. fail2ban-style banning)
Design an efficient, maintainable ruleset:
1. **Named sets** — convert long lists of source IPs/ports into typed named sets (`ipv4_addr`, `inet_service`) so matching is a single hash/tree lookup instead of N sequential rules. Show `flags interval` for CIDR/range sets and why intervals need it.
2. **Verdict maps** — replace chains of `if port == X jump Y` with a `map { 22 : jump ssh_chain, 80 : jump web_chain }` lookup. Show concatenated keys (`ip saddr . tcp dport`) for multi-dimensional policy in one statement.
3. **Dynamic sets** — design `set` with `timeout` and `flags dynamic` for rate-limit/ban lists that the kernel ages out automatically (e.g. add an offending IP with a 1h timeout straight from a rule). This replaces external ban daemons for simple cases.
4. **Flowtable offload** — for high-throughput forwarding, define a `flowtable` and `flow add` established connections to the fast path, bypassing the full ruleset per-packet. Explain software vs hardware offload, NIC requirements, and which traffic is *not* eligible (anything needing per-packet inspection/NAT helpers).
5. **Counters & telemetry** — attach named counters to key rules so you can prove what's matching without re-tracing the whole ruleset.
6. **Atomic updates** — load the whole ruleset transactionally (`nft -f`) so there's never a window with the firewall half-applied; show how to update a single set element without flushing everything.
7. **Validate** — `nft list ruleset` review, a `meta nftrace` trace of one connection, and a before/after on rule count and per-packet cost.
Output: the rewritten ruleset, a table of which linear rules collapsed into which set/map, the flowtable block with eligibility caveats, and a rollout/rollback plan.
Bias toward: sets/maps over linear rules, atomic loads, flowtable only where eligible, and counters on everything that matters.