What Is eBPF/XDP and Why It's the Future of DDoS Mitigation

Every DDoS mitigation system on the planet does fundamentally the same thing: inspect packets and decide whether to forward or drop them. The difference between systems — the difference that determines whether your mitigation adds 50 microseconds of latency or 5 milliseconds, whether it handles 1 million packets per second or 100 million — is where in the networking stack that decision happens.

eBPF/XDP makes that decision earlier than any other software-based technology. And that’s why it’s replacing everything that came before it.

The Problem: Traditional Packet Processing Is Slow

When a packet arrives at a server’s network card, it normally travels through a long chain of processing:

1. NIC hardware receives the raw electrical/optical signal
2. NIC driver copies the packet into kernel memory (DMA)
3. Kernel networking stack allocates an sk_buff structure, parses headers
4. Netfilter/iptables checks the packet against firewall rules
5. Routing subsystem decides where the packet goes
6. Socket layer delivers the packet to the application

Each step adds latency. Each step consumes CPU cycles. Under normal traffic, this pipeline works beautifully — it’s been refined for decades and handles the complexity of modern networking with remarkable efficiency.

Under DDoS attack conditions, this pipeline becomes the bottleneck. When 50 million attack packets per second arrive, the kernel allocates 50 million sk_buff structures, processes each through the netfilter chain, and only then decides to drop them. The CPU is saturated doing per-packet work on traffic that should never have entered the system.

iptables can process roughly 1-5 million packets per second per CPU core before performance degrades. Under a 50 MPPS attack, you need 10-50 cores just for packet filtering — cores that could be serving your actual application.

What Is eBPF?

eBPF (extended Berkeley Packet Filter) is a technology that allows custom programs to run inside the Linux kernel — safely, efficiently, and without modifying kernel source code.

Think of it as a programmable extension point within the kernel. You write a small program (typically in C), compile it to eBPF bytecode, and load it into the kernel. The kernel’s built-in eBPF verifier checks the program for safety (no infinite loops, no illegal memory access, no crashes) before allowing it to execute.

Once loaded, an eBPF program runs at kernel speed — not as an external application making system calls, but as native kernel code executing within the kernel’s own context. There’s no context switching, no user-kernel boundary crossing, no overhead.

eBPF was originally designed for packet filtering (hence “Packet Filter” in the name), but it’s evolved into a general-purpose kernel extension framework. Today it’s used for tracing, security, networking, and observability. Major companies including Google, Facebook, Netflix, and Cloudflare run eBPF in production at massive scale.

What Is XDP?

XDP (eXpress Data Path) is a specific eBPF hook point — and it’s the one that matters most for DDoS mitigation.

XDP attaches eBPF programs to the network card driver — before the kernel networking stack processes the packet. When a packet arrives:

1. NIC hardware receives the packet
2. NIC driver invokes the XDP program immediately
3. XDP program inspects the raw packet and makes a decision:
   • XDP_DROP — discard the packet (never enters the kernel)
   • XDP_PASS — forward to normal kernel processing
   • XDP_TX — send back out the same interface
   • XDP_REDIRECT — forward to a different interface

If the XDP program returns XDP_DROP, the packet is discarded at the driver level. No sk_buff allocation. No netfilter traversal. No routing lookup. No socket delivery. The kernel never knows the packet existed.

This is what makes XDP transformative for DDoS mitigation: attack packets are eliminated before they consume any system resources.

Performance: XDP vs Everything Else

The numbers tell the story:

XDP in native mode delivers 24+ million drops per second per CPU core. On a modern server with 16 cores, that’s 384+ million PPS of filtering capacity — from a single commodity server running standard Linux.

For comparison: 384 MPPS at minimum packet size (64 bytes) is roughly 196 Gbps of attack traffic filtered by one server. With larger packets, the bandwidth capacity is even higher.

Why Not DPDK?

DPDK (Data Plane Development Kit) achieves similar raw performance by bypassing the kernel entirely — the application takes exclusive ownership of the NIC and handles all packet processing in userspace.

The problem: DPDK requires dedicating CPU cores and NIC queues exclusively to the DPDK application. Those resources are unavailable to the operating system and other applications. You essentially split your server into two separate machines — one for DPDK, one for everything else.

XDP doesn’t require this tradeoff. The eBPF program runs within the existing kernel framework. Normal kernel networking continues to function for packets that pass the XDP filter. No dedicated cores, no NIC ownership conflicts, no operational complexity.

Why Not Hardware Appliances?

Dedicated hardware appliances (Arbor, A10, Radware) use custom ASICs to achieve high packet rates. They work. They’re also:

• Expensive. $50,000-$500,000+ per unit, plus annual licensing
• Capacity-fixed. The ASIC’s processing capacity is determined at manufacturing
• Inflexible. New attack patterns require firmware updates from the vendor
• Single point of failure. One device, one point of failure

XDP runs on commodity hardware. Capacity scales by adding servers. New filtering logic deploys in seconds by loading a new eBPF program. There’s no vendor dependency for filter updates.

How CoreEdge™ Uses XDP

CoreEdge™ is built entirely on XDP. Every filtering decision — every rule evaluation, every rate limit check, every GeoIP lookup, every TCP flag inspection — happens at the XDP hook point, before the kernel processes the packet.

The Rule Processing Pipeline

When a packet arrives at a CoreEdge™ scrubbing server:

1. XDP program loads — the eBPF program is pre-compiled and attached to the NIC driver
2. Packet headers parsed — source/destination IP, protocol, ports, TCP flags (at wire speed)
3. Rule set evaluated — customer-configured rules checked in priority order
4. Match conditions tested — IP ranges, ports, packet length, GeoIP, TCP flags, ICMP type
5. Action executed — DROP, ACCEPT, RATE_LIMIT_RULE, RATE_LIMIT_SRC, MATCH_CONNECTION, or CUSTOM_DEFAULT
6. Decision made — XDP_DROP for attack traffic, XDP_PASS for clean traffic

This entire pipeline executes in approximately 100 nanoseconds per packet. At that speed, a single CPU core can evaluate and decide on 24+ million packets per second.

Stateful Tracking in eBPF

One of eBPF’s most powerful features is eBPF maps — kernel-space data structures that persist between packet evaluations. CoreEdge™ uses eBPF maps for:

• Connection tracking — recording TCP handshake state per source IP (used by MATCH_CONNECTION)
• Rate counters — per-source packet counters with time windows (used by RATE_LIMIT_SRC)
• GeoIP tables — IP-to-country mapping loaded as an eBPF hash map
• Rule configuration — the complete rule set stored as eBPF maps, updated atomically from the control plane

This means CoreEdge™ isn’t just a stateless packet filter — it maintains stateful intelligence at XDP speed. Connection validation, rate limiting, and behavioral tracking all happen before the packet enters the kernel.

Rule Updates Without Downtime

When you change a firewall rule through the Client Portal, the update propagates to CoreEdge™ and is applied by updating the eBPF maps. The XDP program itself doesn’t need to be reloaded — only the data structures it references change.

This means rule updates are atomic and zero-downtime. There’s no window where old rules are removed and new rules aren’t yet active. The transition is instantaneous.

eBPF/XDP in the Industry

CoreTech isn’t alone in recognizing XDP’s potential. The technology is backed by an increasingly large ecosystem:

Cloudflare uses XDP for their entire DDoS mitigation pipeline, processing millions of packets per second across their global network.

Facebook deployed XDP-based load balancing (Katran) to handle hundreds of millions of connections per second.

Cilium and Calico use eBPF for Kubernetes networking and security policies at scale.

The Linux kernel community continues to expand eBPF capabilities with every release — adding new hook points, improving the verifier, and expanding map types.

The trajectory is clear: eBPF/XDP is becoming the standard technology for high-performance packet processing. Systems built on iptables, userspace proxies, or proprietary hardware are legacy — functional today, but increasingly outperformed by eBPF-based alternatives.

What This Means for DDoS Mitigation

The practical implications for organizations evaluating DDoS mitigation services:

Ask your provider where filtering happens. If the answer is “iptables,” “application-level proxy,” or “proprietary hardware,” you’re paying for technology that operates orders of magnitude slower than XDP.

Ask about latency. XDP-based filtering adds ~100 nanoseconds. Kernel-based filtering adds microseconds. Application-level filtering adds milliseconds. For latency-sensitive applications (gaming, trading, real-time communication), this difference matters.

Ask about capacity scaling. XDP scales linearly with CPU cores on commodity hardware. Hardware appliances scale by purchasing more appliances. The cost curves are dramatically different.

Ask about update speed. XDP rule updates via eBPF maps are instantaneous. Hardware ASIC updates require firmware deployments. The difference during an active attack is the difference between seconds and minutes of exposure.

CoreEdge™ answers all four: XDP filtering at the NIC driver, ~100ns added latency, linear scaling on commodity servers, and instantaneous rule deployment through the Client Portal.

10-day free trial — experience XDP-speed mitigation with full CoreEdge™ and CoreDetection™ capabilities.

Get started now →