Classic BPF¶

The original BPF is the filter bytecode tcpdump (and libpcap generally) compiles capture expressions down to — see the tcpdump guide for the filter syntax itself. The key property: filtering happens in the kernel, before packets are copied to userspace, which is why a tight tcpdump filter is cheap even on a busy interface.

eBPF: the modern extension¶

"Extended BPF" (eBPF) generalizes the same idea — safely running sandboxed bytecode inside the kernel — far beyond packet filtering: tracing, security enforcement, and, notably, networking datapaths fast enough to replace iptables/Netfilter entirely in some deployments (this is what Cilium does for Kubernetes networking).

Why the kernel networking community has been moving workloads from iptables to eBPF: - iptables rule evaluation is a linear list walk — O(n) per packet against the ruleset size. eBPF programs can implement O(1) hash-table lookups instead. - eBPF programs attach at multiple points (XDP at the driver level, before the kernel even builds an sk_buff; TC; socket level) giving much lower overhead for high-throughput filtering/load-balancing. - Netfilter's chain-of-chains model doesn't compose well at scale (thousands of Kubernetes Services generating iptables rules is a well-known bottleneck) — this is the direct motivation for IPVS and, further, for eBPF-based kube-proxy replacements.

Inspecting loaded eBPF programs¶

sudo bpftool prog list          # currently loaded eBPF programs
sudo bpftool map list           # eBPF maps (the shared state programs use)

Further reading¶

• Cilium: Why is the kernel community replacing iptables with BPF?
• Brendan Gregg — Linux BPF Superpowers
• BPF Performance Tools (book)
• See IPVS and tcpdump for the classic-BPF-adjacent tools this site already covers in depth