Scrubber — a traffic scrubbing centre in your own network
The same dataplane as our routers, deployed as a separate device that the attacked prefix's traffic passes through — only for the duration of the attack, or permanently. The attack stays with us; clean traffic goes back to your network. Your prefix, your machine, our AS invisible in the path.
Ask about the Scrubber19.6 Mpps
attack dropped per core, 64 B
30 Mpps
SYN+ACK carpet dropped 100%, 2 cores
99.97%
legitimate traffic delivered under the carpet
21.4 Mpps
through a GRE tunnel, zero loss
Measured at 64-byte packets, the attack profile, on an AMD EPYC 4565P (Zen 5).
The scale of one machine
Dropping an attack packet costs less than forwarding it — the packet ends in the filter, with no route lookup, header rewrite or transmit. That is why one core drops 19.6 Mpps, and the attack does not steal the capacity legitimate traffic needs.
Scaled to the machine's 16 cores, that is more than two 100 G ports can carry: at 64 B the limit is the full 2 × 100 G line rate — 297.6 Mpps, not the CPU.
Three ways to connect — all running in production
BGP diversion from your routers
The scrubber announces the victim prefix (e.g. a /32) at a higher preference; clean traffic returns over a separate session — a return VRF, no loops. ITCSECadmin switches the diversion on and off via API, automatically when an attack starts.
Hand-off with your transit provider
The scrubber sits between the upstream and your border router — all traffic from that hand-off passes through the filters, permanently.
GRE tunnel from an anycast scrubbing provider
The scrubber receives traffic pre-cleaned by the provider and cleans it further. Our AS never appears in the path — the internet sees the prefix with your AS. Tunnel traffic is spread across all cores with RSS: 21.4 Mpps measured with zero loss.
The layers traffic passes through — in this order
- NIC silicon (mlx5 rte_flow) — drop before the CPU by attack characteristic: TCP flags, fragments, port.
- ITCacl — rules from ITCSECadmin and from the panel, per hand-off, with a time-to-live; tens of thousands of rules. On the scrubbers we also filter in XDP (eBPF) — at the earliest point of the packet path in the Linux kernel.
- Stateful edge protection — a SYN+ACK with no preceding SYN is dropped; state is synchronized between devices when more than one scrubber or router is running (37.1 Mpps of state copies received on 2 cores with zero loss); "count" or "enforce" mode for each layer separately.
- Port automaton — detects a UDP port carpet from sFlow and installs the rule on its own (threshold, entry limit, release once the attack subsides). From production, November 2026: 9 rules in 2 minutes, 99.8% of the carpet dropped, legitimate traffic passing.
- Payload automaton — byte signatures from UDP samples (e.g. STUN reflections with a fixed identifier): proposal → confirmation on live traffic → dropping.
- Geoblocking per customer prefix (country list, count/enforce), protection classes (DNS-AMPL, NTP-AMPL, fragments), BCP38, MSS clamping on tunnels.
- In-memory sFlow analysis — no raw packets written to disk; a per-customer "Traffic" view: in / dropped / delivered, with outbound traffic shown separately.
Controlled from ITCSECadmin
ITCSECadmin switches the diversion on and off via API — automatically when an attack starts — and supplies ITCacl and XDP rules. The telemetry → detection → response → audit loop closes in one system, with no per-Gbps fees and no data leaving your network.
Deployments
Three scrubbers take real attack traffic at operators in Poland today. We do not publish customer names, their ASes or prefixes without their consent.
The scale we measured — at 64-byte packets, the attack profile →