Hardware Requirements for an Anti-DDoS System: How to Choose a Server for DPDK

Deployment of an on-premise DDoS protection system most often fails not at the stage of choosing the solution, but at the stage of selecting hardware. The operator buys a license for the anti-DDoS software and receives the documentation. Then it turns out that the server that was supposed to be sufficient "with room to spare" chokes at the first larger attack. The system itself is not to blame; what is to blame is the lack of understanding that DPDK-based DDoS protection follows different rules than a typical server application.

This problem applies to practically every deployment of an anti-DDoS system for a telecommunications operator or data center: however good the software itself is, badly chosen hardware underneath will negate its effectiveness. Below we describe what to pay attention to so that the protection of an operator network against DDoS attacks works as intended from day one.

Classic network software uses the network stack of the operating system kernel. This is convenient, but slow: each packet goes through several layers of data copying and context switches before the application sees it. At traffic of a few to a dozen or so Gb/s, this is not a problem. When analyzing traffic packet by packet in real time, at the level required to detect a DDoS attack within a second, such overhead is unacceptable.

That is why effective anti-DDoS systems, including LiveShield, are based on DPDK (Data Plane Development Kit), a library that allows an application to receive packets directly from the network card, bypassing the kernel. The DPDK approach to anti-DDoS is today the standard for next-gen DDoS protection solutions that aim to work in real time rather than with a delay of minutes. This solves the performance problem, but imposes specific, rigid requirements on the hardware. Not every server and not every network card is suitable for this.

LiveShield, as an anti-DDoS system for telecommunications operators and data centers, works with three modules: Manager, Analyser and Worker. The Manager and Analyser are management and analytical components and can run on a virtual machine, since the load here is predictable. The Worker is a completely different story: it performs packet processing using DPDK, so it requires a physical server. Virtualization introduces an additional layer between the network card and the application, which in practice means losing the benefits of DPDK.

Consequence for deployment planning: if you assume an all-in-one environment on a single machine, the whole machine must be physical. If you separate the modules, only the Worker must sit on physical hardware.

The number of physical CPU cores depends on the throughput of the traffic to be analyzed:

physical cores = Gbps ÷ 10 + 4

Example: for 40 Gb/s of incoming traffic, this gives 8 cores for the processing itself plus 4 base cores, that is, 12 physical cores.

Two minimum thresholds to keep in mind regardless of the formula's result:

These are physical cores, not Hyper-Threading logical threads. With packet processing in poll mode, as used by DPDK, a core is 100% busy regardless of whether there are packets to process at the moment. Counting on HT threads gives a false picture of the available power.

32 GB of RAM or more is the starting point. DPDK uses hugepages, that is, memory blocks reserved in advance, so you need more headroom than what "usually suffices" on a similar server without packet processing. For disk space, 60 GB on NVMe is enough: the system does not store full traffic continuously, so there are none of the capacity requirements typical of full traffic recording tools.

This is the point on which purchase planning most often falls apart. DPDK theoretically supports a wide list of cards, but in practice specific models with the appropriate PMD (Poll Mode Driver) work well:

Onboard cards (built into the motherboard) or SoC-type solutions require a separate check of whether the manufacturer provides a PMD driver for them at all. The absence of this driver means the card will not be able to work in DPDK mode, no matter how good the processor or the amount of memory is. This is a common mistake when selecting hardware for servers: purchasing teams look at the card's throughput in Gb/s and overlook driver compatibility, which in this case is a necessary condition.

Practical rule for choosing the card manufacturer: below 40 Gb/s of traffic, the difference between Intel and Mellanox/NVIDIA does not matter much, and both families work well. Above this threshold, it is worth aiming for NVIDIA ConnectX-5 or a newer model.

Rather than sticking purely to theory, it is worth showing how these guidelines translate into specific hardware that has already been recommended to operators at the infrastructure selection stage.

Variant I, up to approx. 40 Gb/s: a Dell R430-class server with an Intel Xeon E5-2680 v4 processor, 32 GB RAM, combined with a dual-port Intel XL710-QDA2 card (QSFP+, 40G). This is hardware that can be bought used for relatively little money and that will comfortably handle traffic at this level.

Variant II, up to 100 Gb/s: here the processor must change to an Intel Xeon Gold 63xx series, mainly because of PCIe 4.0 support.

Important: the Intel E8xx-cqda2 network card for this throughput physically splits the PCIe bus in half between the ports, so if you plan to use both ports simultaneously, the motherboard must support PCIe Bifurcation. Without this support, the system will see only one port of the card. Without full PCIe 4.0, the card will be limited to approx. 50G per port, regardless of the number of ports used.

For an operator planning to protect incoming traffic at the 20 Gb/s level, the minimum sensible specification for a Worker looks like this:

At 100 Gb/s of incoming traffic, the formula alone already gives 14 physical cores, so CPU selection must be planned even more carefully with regard to NUMA architecture and the number of processor sockets.

Sizing for a DPDK-based anti-DDoS system is not rounding up a typical server specification. It is a separate category of requirements: a physical server for the packet-processing module, physical cores counted by a specific formula, a network card verified for PMD driver support before it makes it into the order specification. Skipping any of these points at the planning stage usually ends with having to buy additional hardware after testing or, worse, after the first real attack.

Well-planned DDoS protection for an ISP or data center is as much a matter of the right software as of a conscious choice of the infrastructure on which that software is to run. The full, current hardware specification and the list of validated network cards can be found in the documentation: docs.liveshield.net.

Do you already have some hardware? Consult us about it: office@liveshield.net