eBPF hands-on series covers XDP

eBPF and XDP are Linux’s fast path for touching packets before the kernel’s normal networking machinery wakes up. That makes them catnip for anyone chasing low latency, high packet rates, or just tighter control over what hits a server. The news here is simple but useful — Teodor Janez Podobnik’s hands-on XDP series on iximiuz Labs is getting renewed attention because it does the rare thing: it teaches the mechanics by building real networking tools, not toy demos. The labs now span the full arc from parsing packets to rate limiting, firewalling, and load balancing. ### What is XDP, in plain English? XDP stands for Express Data Path. It lets an eBPF program run extremely early in Linux packet processing — basically at the network driver edge — so the machine can drop, redirect, or rewrite traffic before the usual stack adds overhead. That early hook is the whole point. If you can make a decision there, you save cycles and time. (labs.iximiuz.com) ### Why are these tutorials getting noticed? Because they’re organized like a skill path, not a pile of disconnected blog posts. iximiuz Labs frames the series as a progression from XDP fundamentals into advanced use cases, and iximiuz has been actively pointing readers toward Podobnik’s work as a standout eBPF learning resource. That combination matters — strong author, guided path, runnable labs. (labs.iximiuz.com) ### What do you actually build? You start with packet parsing across IPv4, IPv6, TCP, UDP, and ICMP, plus the basic XDP actions. From there the labs move into a per-client ICMPv6 rate limiter, an IP-range firewall using `BPF_MAP_TYPE_LPM_TRIE`, and multiple load-balancer designs — including NAT-based layer 4 balancing and layer 2 direct server return. These are not abstract architecture diagrams. They’re concrete packet-path programs. (labs.iximiuz.com) ### Why does rate limiting at XDP matter? Because the kernel can reject abusive traffic before it burns more CPU higher up the stack. Podobnik’s rate-limiting lab tracks client activity in eBPF maps and enforces limits without user-space interaction. That’s the important pattern. The example uses ICMPv6 and keeps the scope intentionally small, but the lesson is broader — state in maps, decision in kernel, no round trip to a daemon. (labs.iximiuz.com) ### What’s interesting about the firewall lab? It uses longest-prefix matching with an LPM trie, which is exactly the kind of data structure you want when filtering by IP ranges instead of one-off addresses. That turns XDP from a blunt packet-drop hook into something closer to a programmable access-control layer. You can see the shape of production ideas in it, even if the lab is designed for learning first. (labs.iximiuz.com) ### And the load balancer pieces? This is where the series gets especially practical. The labs cover NAT-based balancing, weighted round robin, weighted least connections, and DSR. Each one teaches a different tradeoff — whether the balancer rewrites traffic and tracks connections, or whether backends reply directly to clients to bypass the balancer on the return path. That’s real networking design, not just eBPF syntax practice. (labs.iximiuz.com) ### Is this “kernel bypass”? Not in the pure DPDK sense people sometimes mean. XDP still lives in the kernel, but it bypasses a lot of the normal network stack’s work by acting at a much earlier layer. Basically, you keep Linux in the loop while dodging a big chunk of its packet-processing overhead. That’s why XDP is so attractive for firewalls, DDoS filtering, and very fast service edges. (labs.iximiuz.com) ### Who should care? Platform engineers, network engineers, and performance-minded backend teams. Also anyone in latency-sensitive systems — trading is the obvious example — where in-kernel filtering, shaping, and steering can matter more than fancy application logic. The catch is that these labs teach the patterns, not a drop-in production system. But that’s exactly wh(labs.iximiuz.com)inely useful learning path now exists that shows how XDP becomes real infrastructure — one packet decision at a time.