A few weeks ago, I hit a bug that sent me further down the Linux networking stack than I'd gone in years: an NVIDIA Jetson device, running k3s at the edge, with svclb-traefik stuck in a CrashLoopBackOff that made no sense from the Kubernetes side. Pods scheduled fine. Images pulled fine. The manifests were correct. The problem was three layers below anything kubectl describe could tell me, in the kernel's packet-classification engine.
The fix ended up being: blacklist nf_tables. But understanding why that line worked meant actually learning what nftables is, how it relates to the iptables tools everyone's used for twenty years, and where eBPF fits into all of this — because the honest answer is that most of us run this stack daily without ever needing to know what's underneath it, until a vendor kernel breaks the abstraction.
This is that deep dive.
Netfilter: the actual foundation
Before nftables, before iptables, there's netfilter — the kernel subsystem that makes any of this possible. Netfilter itself doesn't know what a "rule," "chain," or "table" is. It's simpler and older than that: it's a set of five hook points wired into the network stack where kernel code can intercept a packet and hand back a verdict.
