Small
Regional ISP
Up to 20K flows/snetworks up to ~5 Gbps
- CPU
- 8 cores (Xeon / EPYC)
- RAM
- 32 GB DDR4
- Disk
- 500 GB NVMe SSD
- Network
- 1 Gbps
- OS
- Debian 13+ (Trixie)
EdgeWarden is a single package that runs as all-in-one, analyzer or scrubber, set by one line in config.toml. Each role leans on a different resource: the box that analyzes lives on disk and memory; the box that scrubs traffic lives on the NIC and CPU cores.
Applies to every role
mlx5, ice, i40e or ixgbeA relative scale across roles to guide purchasing. Exact numbers depend on flow volume, retention and how much traffic crosses the filter.
| Role | CPU | RAM | Disk | Network | What drives it |
|---|---|---|---|---|---|
| All-in-onethe default | Mediumgrows with flows/s | High | Highgrows with retention | Lowvery high if it filters inline | Collection, analysis, databases, UI and filter on the same box. In a typical install it only receives flow samples and announces FlowSpec; the router does the dropping. If it also filters inline, add the scrubber's demand. |
| Analyzerout of the traffic path | Mediumgrows with flows/s | High | Highgrows with retention | Low | Runs ClickHouse, MariaDB, Redis, GoBGP and the UI. It only receives flow samples, so the NIC barely matters; ClickHouse wants NVMe and free memory for the page cache, and swap kills latency. |
| Scrubberin the diverted traffic path | Very highper core, on the NIC's NUMA node | Low | Lowno local databases | Very highnative XDP, PCIe x16 | Just the core with the XDP filter: no databases, no BGP, no UI. What counts is a NIC with native XDP, physical cores on the NIC's NUMA node and a PCIe x16 slot of a recent enough generation. |
| Packet Sensoroptional module (SPAN/TAP) | High | Medium | Medium | High | Packet capture for sub-second detection and to read SNI, DNS and HTTP Host. It isn't a role: it adds to the all-in-one or analyzer (the scrubber turns it off). Estimated order of magnitude per engine: libpcap ~1–2 Gbps and AF_PACKET v3 ~5 Gbps; AF_XDP capture and a DPDK engine are coming soon. |
Low, Medium, High and Very high compare the roles with each other; they are not measurements.
On the scrubber, less is more. The scrubbing node uses the same package, but only the core runs. Don't install MariaDB, Redis, ClickHouse, Apache, PHP, Node.js, GoBGP or certbot: it reads the mitigation queue from the analyzer's ClickHouse.
Firewall with nftables only, never ufw, which would drop the clean traffic.
When you scrub traffic, the recommended mode separates the box that decides from the box that takes the attack. That's why each machine has a different shopping list.
/32 or /128 diversion over BGP, with the scrubber as next hop./health every 10 s. Three consecutive failures withdraw the active diversions; one good response allows diversion again./health, only to the analyzer.These sizes are for the box that collects and analyzes (all-in-one or analyzer). The scrubber is sized by its NIC, covered in the next sections.
Regional ISP
Up to 20K flows/snetworks up to ~5 Gbps
ISP / mid-size DC
Up to 50K flows/snetworks up to ~20 Gbps
Tier-1 / large DC
100K+ flows/snetworks of 40 Gbps+
The build documented in detail for scrubbing traffic at 100G. An equivalent server follows the same logic: one NIC per CPU, an x16 slot and native XDP.
intel_iommu=on iommu=pt, no irqbalance, and the kernel's own mlx5 driver (no MLNX_OFED).mq qdisc and pinned IRQ affinity, reapplied at boot by a systemd unit.| Item | Mode A: everything on the R760 | Mode B: separate analyzer recommended |
|---|---|---|
| On the R760 | Collector, ClickHouse, MariaDB, UI, GoBGP and XDP | Only the core with XDP |
| BGP with the edge | The R760 itself | The analyzer |
| Health watchdog | Not needed | Required |
One port per router, dirty and clean on the same cable; an input filter sends clean traffic to the CLEAN routing instance. IPv4 and IPv6.
VRP8 template written from the official documentation, with one dirty and one clean port. It still needs lab validation.
Line rate of one 100G port with 64-byte frames: the worst case the filter has to face.
XDP drop rate per core in the literature (XDP paper, CoNEXT 2018, ConnectX-5 Ex). reference, not an EdgeWarden benchmark
Diversion ceiling over the capacity measured in your deployment. Above that, the decision falls through to external scrubbing, FlowSpec on the vector and, as a last resort, RTBH.
100G/200G architecture per router, with capacity validated in each deployment. Dropping is cheap; clean traffic that gets forwarded costs an order of magnitude more and has no published figure. That's why capacity is measured at install time and recorded in the system, and the 80% ceiling applies to that number.
The filter runs in the NIC driver. Without native support, EdgeWarden falls back to generic mode (SKB): it works, but packets only get filtered after the kernel has already spent cycles on them.
| NIC | Driver | Speed | XDP | Notes |
|---|---|---|---|---|
| Top tier | ||||
| Mellanox ConnectX-5 / 6 | mlx5 | 25G / 100G | Native | The best native XDP support. For two 100G ports at once, use ConnectX-5 Ex, ConnectX-6 Dx or ConnectX-7. |
| Intel E810 | ice | 25G / 100G | Native | Intel's current generation, with full XDP. |
| Best value (production) | ||||
| Intel X710 | i40e | 10G / 40G | Native | Excellent XDP support, widely tested. |
| Intel X520 / X540 | ixgbe | 10G | Native | Older, but solid XDP and easy to find used. |
| Mellanox ConnectX-4 | mlx5 | 10G / 25G | Native | Great price on the used market. |
| Lab | ||||
| Intel I350 / I210 | igb | 1G | Basic | Good for testing. |
| virtio-net | virtio | VM | Testing | For testing in KVM VMs. |
To take real attack traffic, the minimum is an Intel X520 (10G); ideally, a Mellanox ConnectX-5 (25G).
200 Gbps requires PCIe 4.0 x16. The plain ConnectX-5 (MCX516A-CCAT, PCIe Gen3) can't sustain two 100G ports at once, and in an x8 slot no NIC delivers its rated throughput.
In a VM with vmxnet3, native XDP needs kernel 6.3 or newer; below that, generic mode only. Expect something in the 1–2 Gbps range.
Identify the NIC by its driver, never by MAC address: we've seen a Mellanox OUI on an Intel card.
Read-only commands: they change nothing on the NIC or the system. The actual tuning (rings, queues, IRQs) is in step 11 of the installation guide and needs a maintenance window.
IF=eth0 # data plane interface (the one receiving dirty traffic)
# NIC driver: decides whether XDP can run natively
ethtool -i $IF | grep driver
# NIC's NUMA node (0 or 1; -1 = BIOS without SLIT)
cat /sys/class/net/$IF/device/numa_node
# Which mode did XDP come up in? (with the core running)
ip -d link show $IF | grep -i xdp
# "xdp" = native, in the driver — required at this scale
# "xdpgeneric" = SKB fallback, runs AFTER GRO
# Check whether the NIC is dropping packets (everything should stay at zero)
ethtool -S $IF | grep -iE "drop|discard|miss|nobuf|error" | grep -v ": 0$"
# PCIe slot width and generation
lspci -vv -s $(basename $(readlink /sys/class/net/$IF/device)) | grep -i "LnkSta:"
mlx5_core, ice, i40e or ixgbe: native XDP available.xdp in the ip link output: the filter is in the driver. If you see xdpgeneric, sort out the NIC or driver before sending real traffic.ethtool -S, meaning nothing is being dropped on the NIC.Tell us your flow volume, the retention you want to keep and how many routers will divert to scrubbing. The team will recommend the server and NIC for each role. Assistance is provided in Portuguese.