In-kernel data plane
Every other mitigation method Kapkan has is a request. RTBH and FlowSpec ask your routers to drop traffic; diversion asks them to send it somewhere else. All three depend on a peer that is willing and able to act on the announcement.
The data plane drops packets itself. Kapkan loads a small XDP program into the Linux kernel of the machine it runs on, and the rules the detector already builds for FlowSpec are written into kernel maps instead of being announced. Nothing has to propagate, and no peer has to accept anything.
This page is the overview. It answers three questions in order — is this for me, does it work, and where do I go next — and the rest of the section is the how:
- Installing the data plane — the kernel and capability requirements, the config block, and how to bring it up safely in dry-run.
- Operating & monitoring — reading its status, the counters and metrics to watch, the one alert you must set, and what to do when something is wrong.
- Tuning & reference — the packet-evaluation order, static policy, per-source rate limiting, attach modes, and the map-sizing limits.
Is it for you? The one question that decides it
The data plane can only drop packets that reach the machine Kapkan runs on. That single fact decides whether the feature applies to your deployment, so answer it before anything else.
It helps when Kapkan runs in the traffic path:
- on a Linux border router or a bump-in-the-wire box the traffic already crosses;
- on the host being attacked, protecting itself;
- on a dedicated scrubbing node that diversion steers traffic to.
It does nothing when Kapkan runs off-path — the classic deployment, where a Kapkan VM receives NetFlow or sFlow from your routers and speaks BGP back to them. No attack traffic flows through that VM, so there is nothing there for it to drop. In that topology, keep using RTBH and FlowSpec, and reach for the data plane only on a scrubbing node.
!It cannot un-saturate an upstream link
An XDP filter runs on packets that have already arrived on this machine's NIC. If a flood has already filled the pipe upstream of the box, the link is congested before the filter sees a packet, and dropping locally changes nothing. That is what the heavier, upstream steps are for. In an escalation ladder the data plane is the most precise response — not a replacement for the ones that move the drop upstream.
Does it work? Measured, not asserted
Every release replays eighteen attack captures end to end — synthetic telemetry into the real detector and classifier, the rules it generates compiled into real kernel maps, then the captured frames replayed through the program. Each capture runs a stream of legitimate traffic alongside the attack, because a block rate measured without one means nothing.
| Measured over 18 captures | Result |
|---|---|
| Attack traffic dropped | 100% on 17 of 18; 98.5% on the per-source rate-limit capture, where each source is allowed its first frame before its bucket empties |
| Legitimate traffic dropped | zero, in all 18 |
| Allowlisted traffic dropped | zero, in all 18 |
The captures cover UDP and SYN floods over IPv4 and IPv6; DNS, NTP, CLDAP, SSDP, memcached and
chargen amplification; ICMP and fragment floods; a TCP ACK flood; a multi-vector mix; a
carpet-bombed /24; a source flood; VLAN-tagged frames; and IPv6 with extension headers. The full
suite also runs on real 5.15, 6.1, 6.6 and 6.12 kernels on every change.
iA block rate is not a throughput number
These numbers say what fraction of an attack the rules catch. They say nothing about how many packets a given box can absorb — that depends on your NIC, driver and CPU, and on whether the program attached in native or generic mode. Size a deployment on your own hardware; do not read capacity off this table.
How it fits the rest of Kapkan
The data plane is a mitigation method, alongside RTBH, FlowSpec and diversion, and it inherits everything the others do. Detection is unchanged. The safety model — dry-run, whitelists, TTLs and blast-radius caps — applies exactly as it does to a BGP announcement, because the data plane plugs in at the same point. What changes is only the last step: instead of an announcement leaving the box, rules are written into the kernel.
Severity runs none < dataplane < flowspec < divert < blackhole. On an
escalation ladder a dataplane rung is the gentlest real action — drop locally
first, and escalate to the router-based methods only if that was not enough.
Where to go next
New to it? Read Installing the data plane and bring it up in dry-run, then Operating & monitoring to learn what to watch. Reach for Tuning & reference when you want static policy, per-source rate limiting, or to understand exactly how a packet is evaluated.