Netfilter hooks
If you are familiar with Netfilter, don't worry, most of the infrastructure remains the same. nftables reuses the existing hook infrastructure, Connection Tracking System, NAT engine, logging infrastructure, userspace queueing and so on. Therefore, we have only replaced the packet classification framework.
For those unfamiliar with Netfilter, we provide ASCII art to represent our hooks:
Local process ^ | .-----------. .-----------. | | | Routing | | |-----> input / \---> | Decision |----> output \ --> prerouting --->| Routing | .-----------. \ | Decision | --> postrouting | | / | |---------------> forward --------------------------- .-----------.
Basically, traffic flowing to the local machine in the input path see the prerouting and input hooks. Then, the traffic that is generated by local processes follows the output and postrouting path.
If you configure your Linux box to behave as router, do not forget to enable forwarding via:
echo 1 > /proc/sys/net/ipv4/ip_forward
And then, the packets that are not addressed to your local system will be seen from the forward hook. In summary, packets that are not addressed to local processes follow this path: prerouting, forward and postrouting.
Ingress hook
Since Linux kernel 4.2, Netfilter also comes with an ingress hook that you can use from nftables. So the big picture now look like this:
Local process ^ | .-----------. .-----------. | | | Routing | | |-----> input / \---> output --->| Decision |------ ---> ingress ----> prerouting ---> | Routing | .-----------. \ | Decision | ---> postrouting ---> | | / | |---------------> forward ------------------------------------ .-----------.
You can use this new ingress hook to filter traffic from Layer 2, this new hook come earlier than prerouting. This basically provides an alternative to tc.