XDP and eBPF: Next-Gen Packet Filtering for Gaming Servers

When a DDoS attack hits your Minecraft server with 50 million packets per second, iptables can not keep up. Not because it is bad software. Because it operates too high in the Linux network stack to handle that volume. Every packet passes through dozens of kernel layers before iptables even sees it. By that point, the CPU cycles are already spent.

There is a different approach. XDP (eXpress Data Path) intercepts packets at the NIC driver level, before the Linux kernel begins processing them. And eBPF (extended Berkeley Packet Filter) lets you write a program that decides the fate of each packet in nanoseconds. Pass, drop, or redirect.

This technology is already running in production at Cloudflare, Meta, and Netflix for DDoS mitigation. And it is exactly what we use at MineGuard to filter traffic heading to gaming servers.

What is eBPF

eBPF is a technology that lets you run custom programs inside the Linux kernel. Not kernel modules (which can crash the entire system on a bug), but programs in a sandboxed environment. The kernel verifies every eBPF program before loading it: checking for infinite loops, out-of-bounds memory access, division by zero.

If a program fails verification, it does not load. If it passes, it runs at native kernel speed because the JIT compiler (Just-In-Time) translates it into machine instructions for the specific CPU.

In practical terms, eBPF turned the Linux kernel into a programmable platform. Before eBPF, adding custom packet processing logic to the kernel meant writing a kernel module in C, compiling it for a specific kernel version, and risking a kernel panic with every bug. With eBPF, you write a small program, the kernel guarantees its safety, and it runs with minimal overhead.

Key properties of eBPF:

• Safety. The kernel verifier checks every instruction before loading
• Speed. JIT compilation to native machine code
• Flexibility. Programs can be updated without system reboots
• Isolation. An eBPF program crash does not take down the kernel

What is XDP

XDP (eXpress Data Path) is a hook point in Linux located at the lowest level of the network stack, inside the NIC driver itself. When the network card receives a packet, XDP processes it BEFORE the kernel creates an sk_buff structure, BEFORE netfilter, BEFORE conntrack, BEFORE iptables.

Why does this matter? Because most CPU cost in packet processing comes from the upper stack layers. Creating sk_buff, traversing netfilter chains, updating conntrack tables - all of this takes hundreds of nanoseconds per packet. During a DDoS attack with millions of packets per second, those "hundreds of nanoseconds" translate to 100% CPU usage.

XDP operates where the packet is still just raw bytes in a DMA buffer. No memory allocations, no conntrack. The XDP program gets a pointer to raw packet data and makes one of four decisions:

• XDP_DROP - discard the packet. The fastest action, the packet never reaches the kernel stack
• XDP_PASS - forward the packet to the normal kernel stack for processing
• XDP_TX - send the packet back out the same interface (useful for SYN cookies)
• XDP_REDIRECT - redirect the packet to another interface or program

Here is a simplified XDP program in C:

SEC("xdp")
int xdp_filter(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_DROP;

    if (eth->h_proto != htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_DROP;

    // Check blocklist
    __u32 src_ip = ip->saddr;
    if (bpf_map_lookup_elem(&blocklist, &src_ip))
        return XDP_DROP;

    // Check rate limit
    struct rate_info *rate = bpf_map_lookup_elem(&rate_counters, &src_ip);
    if (rate && rate->pps > MAX_PPS_PER_IP)
        return XDP_DROP;

    return XDP_PASS;
}

This code executes in 50-100 nanoseconds. For comparison, a packet passing through the full iptables stack takes 2000-5000 nanoseconds.

Why iptables is too slow

To understand XDP's advantage, look at the path a packet takes with iptables.

When a packet arrives at the network card:

1. NIC places the packet in the ring buffer via DMA
2. Kernel receives an interrupt, starts NAPI polling
3. An sk_buff structure is created (memory allocation)
4. Packet passes through ingress qdisc (traffic control)
5. netfilter: raw table, PREROUTING chain
6. conntrack: hash table lookup, new entry creation
7. netfilter: mangle table, PREROUTING chain
8. Routing decision
9. netfilter: filter table, INPUT chain
10. iptables: check EVERY rule in sequence

Only at step 10 does iptables decide: DROP or ACCEPT. But by that point, the kernel has already spent CPU on steps 1-9. During a DDoS attack, 90% of packets are garbage, and running each one through the full stack is pointless waste.

XDP operates between steps 1 and 2. The packet is intercepted before sk_buff creation, before conntrack, before netfilter. If it needs to be dropped, it is dropped instantly with zero memory allocation.

The numbers

Real benchmarks show the gap in orders of magnitude:

Method	Packets/sec (1 core)	Latency
iptables	~1M	2-5 us
nftables	~2M	1-3 us
XDP (generic)	~5M	0.5-1 us
XDP (native)	~14M	0.05-0.1 us

XDP in native mode (supported by the NIC driver) processes 14x more packets than iptables. On an 8-core server, that is theoretically 100+ million packets per second. For context, most DDoS attacks on Minecraft servers generate between 5 and 50 million pps.

BPF maps: stateful filtering

Dropping by IP alone is not enough. Real protection requires state: packet counters, blocklists, session information. eBPF has BPF maps for this, data structures shared between the eBPF program in the kernel and the user-space application.

Key map types:

Hash map - classic hash table. Perfect for IP blocklists:

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 100000);
    __type(key, __u32);         // IP address
    __type(value, __u64);       // timestamp
} blocklist SEC(".maps");

LRU hash - hash table with automatic eviction of old entries. Good for rate limiting:

struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 1000000);
    __type(key, __u32);            // IP address
    __type(value, struct rate_info); // packet count, timestamp
} rate_counters SEC(".maps");

Per-CPU array - array with a separate copy for each CPU core. No locks, maximum speed:

struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 1);
    __type(key, __u32);
    __type(value, struct stats);
} packet_stats SEC(".maps");

The user-space application can update the blocklist, read statistics, and change rate limit thresholds in real time. The eBPF program in the kernel picks up changes without reloading. This is a key difference from iptables, where adding 10,000 rules takes seconds and blocks packet processing.

How traditional DDoS protection works

Most DDoS protection services for Minecraft still use iptables or nftables as their primary filtering tool. The setup is straightforward: traffic passes through a proxy server where iptables rules filter "bad" packets.

The problems with this approach:

Linear rule checking. iptables checks rules in order. 1,000 rules in a blocklist means 1,000 checks per packet. ipset helps (O(1) lookup), but still goes through conntrack and netfilter.

Conntrack overhead. Every new connection creates a conntrack entry. During a SYN flood, the conntrack table fills up in seconds and starts dropping legitimate connections. We covered this in detail in our article about SYN flood attacks on Minecraft.

Context switches. iptables runs in softirq context, but every rule modification (add, delete) requires locks, creating contention under high load.

Limited logic. Complex filtering (Minecraft payload analysis, stateful rate limiting, adaptive thresholds) is either impossible in iptables or requires hacks with u32/string match modules.

XDP/eBPF solves all of these. Blocklist in a BPF hash map gives O(1) lookup without conntrack. Rate limiting on per-CPU counters runs without locks. Minecraft protocol analysis in eBPF gives full access to packet data. Rule updates through BPF maps need no reload and do not block processing.

Why gaming servers need XDP

Gaming servers, especially Minecraft, have specific DDoS protection requirements.

Low latency. Every millisecond of added delay is felt by players. If the filter adds 5 ms per packet, players notice lag. XDP adds less than 0.1 ms, unnoticeable even with 100+ players online.

High pps attacks. Modern DDoS attacks on Minecraft generate tens of millions of packets per second. This is not volumetric flooding (Gbps) but packet rate flooding, designed to overload the server CPU. iptables physically can not handle this rate. We covered the difference between volumetric and packet rate attacks in our article on TCP and UDP attacks on Minecraft.

Protocol-level bot attacks. Attackers simulate the Minecraft handshake, sending valid SYN packets followed by login packets. iptables has no ability to inspect Minecraft packet contents. An eBPF program can parse the payload at kernel level and drop a fake handshake before it reaches userspace.

Fast rule switching. During an attack, the traffic profile changes every few seconds. New IPs, new patterns, adaptive botnets. BPF maps allow instant blocklist and counter updates without reloading the filter.

At MineGuard, we use XDP/eBPF as the first layer of filtering. Packets that fail XDP-level checks are dropped before sk_buff creation even occurs. Only legitimate traffic is passed up the stack for additional Minecraft protocol validation.

Real-world adoption: who uses eBPF

XDP/eBPF is not experimental technology. The largest companies use it in production.

Cloudflare processes all incoming traffic through eBPF programs on their edge servers. Their Magic Firewall is built entirely on XDP, handling tens of terabits per second of DDoS attacks.

Meta (Facebook) uses XDP for load balancing (Katran) and DDoS protection. Their solution processes billions of packets per second on production servers.

Netflix uses eBPF for network analytics and protecting their CDN infrastructure.

Cilium is a Kubernetes networking plugin built entirely on eBPF, replacing iptables for routing and filtering in container environments.

The trend is clear: eBPF is replacing iptables everywhere high performance is needed. The gaming industry is no exception. We compiled the latest data on Minecraft DDoS attacks and defense methods in our 2026 Minecraft DDoS trends overview.

Limitations of XDP/eBPF

It would be dishonest to only discuss the advantages. The technology has real limitations.

Kernel version. XDP requires Linux 4.8+, and many useful features (BPF_MAP_TYPE_LRU_HASH, bpf_fib_lookup) only appeared in 5.x kernels. Most VPS hosts for Minecraft still run 4.x or even 3.x kernels. On those kernels, XDP either does not work or runs in limited generic mode.

Driver support. For full speed, XDP needs NIC driver support (native XDP). Not all drivers support it. Without native mode, XDP runs in generic mode, which is faster than iptables but does not reach the maximum 14M+ pps.

Development complexity. Writing an eBPF program for packet filtering is non-trivial. You need to know:

• C (eBPF programs are written in a subset of C)
• The Linux network stack at kernel level
• Packet structures (Ethernet, IP, TCP/UDP)
• eBPF verifier constraints (no arbitrary-length loops, limited stack size)
• BPF maps and their concurrency model
• Game server protocols (Minecraft protocol for payload analysis)

Verifier restrictions. The eBPF verifier is strict. No infinite loops, 512-byte stack limit, every memory access must be bounds-checked. Good for safety, but makes writing complex logic harder.

Debugging. Debugging eBPF programs is significantly harder than regular code. printk in eBPF is limited, and errors often surface as "verifier rejected program" with cryptic messages.

Why you can not just set up XDP yourself

In theory, XDP is open technology and anyone can write an eBPF filtering program. In practice, it requires:

1. A suitable kernel (5.10+ for comfortable development)
2. A NIC with native XDP support (Intel i40e, Mellanox mlx5, virtio in some configurations)
3. Deep knowledge of the Linux network stack
4. Understanding of the Minecraft protocol (for application-level filtering)
5. Monitoring and analytics (to understand what the filter is doing)
6. Constant updates (attacks evolve, filters must adapt)

Writing a basic XDP rate limiter takes half a day. Building a production-ready DDoS filter with Minecraft protocol analysis, adaptive thresholds, BPF map rotation, graceful reload, and monitoring takes months of development.

For a Minecraft server owner, this is roughly like building your own antivirus instead of buying one. Technically possible, practically pointless. Your time is better spent growing your server, not fighting eBPF verifier quirks.

It is far more effective to use DDoS protection where XDP/eBPF is already configured and optimized. Basic iptables setup is still needed as the last line of defense on your server, but primary traffic filtering should be handled by specialized solutions.

The future: programmable networking

XDP and eBPF are not just an iptables replacement. They represent a fundamental shift in network security. Instead of static rules ("block this IP", "rate limit to N/s"), you can run arbitrary logic directly in the kernel at wire speed.

What this means for DDoS protection:

Adaptive filtering. An eBPF program can analyze traffic patterns in real time and change filtering strategy without involving userspace. Detected a spike in SYN packets from a specific subnet? Automatically applies stricter rate limits for it.

Kernel-level ML. Projects are already emerging that run simple machine learning models in eBPF for traffic classification. This enables detecting packet anomalies that static rules miss.

Hardware offload. Some NICs (SmartNICs) allow loading eBPF programs directly onto the card. In this case, packets are filtered without any server CPU involvement. Filtering speed: 100+ Gbps on a single port.

Composable datapath. Multiple eBPF programs can be chained together (tail calls), creating a modular filtering system. One module checks IPs, another analyzes rates, a third parses the game protocol.

For the gaming industry, this means DDoS attacks that seem unstoppable today (100M+ pps) will be filtered by a single SmartNIC in fractions of a microsecond within a couple of years. And complex application-level attacks will be detected by ML models running directly in the kernel, with no delay from shipping data to userspace.

XDP/eBPF is not a silver bullet. It is a tool that, when used properly, delivers an order of magnitude better filtering performance than traditional methods. And in gaming server DDoS protection, where every microsecond of delay and every extra packet matters, that order of magnitude is the difference between a crashed server and a stable 20 TPS under attack.