XDP en eBPF voor hoogwaardige pakketverwerking

Met XDP (eXpress Data Path) en eBPF (extended Berkeley Packet Filter) kan Linux netwerkpakketten verwerken voordat de normale netwerkstack van de kernel in actie komt. In plaats van voor elk binnenkomend pakket geheugenstructuren toe te wijzen, onderschept XDP het verkeer direct bij de NIC-driver, beslist wat ermee moet gebeuren en laat het vallen, stuurt het door of leidt het om. Het resultaat is pakketverwerking van miljoenen pakketten per seconde per kern, met een fractie van de CPU-overhead van traditionele tools zoals iptables.

Hoe eBPF en XDP samenwerken

eBPF is een virtuele machine binnen de Linux-kernel. Het voert aangepaste bytecode uit die op veiligheid is gecontroleerd (geen oneindige lussen, geen ongeautoriseerde toegang tot het geheugen) en vervolgens JIT-gecompileerd is naar native CPU-instructies. Programma's zijn beperkt in omvang. Ze kunnen geen willekeurige kernel-functies aanroepen, alleen een reeks vooraf gedefinieerde helpers voor taken zoals map-lookups en pakketomleiding.

Voor statusbeheer maakt eBPF gebruik van maps, dit zijn sleutel/waarde-opslagplaatsen (hash-tabellen, arrays, LPM-tries) die blijven bestaan naarmate er pakketten binnenkomen. Maps zijn leesbaar en beschrijfbaar vanuit de gebruikersruimte, zodat u blokkeerlijsten of routeringsregels kunt bijwerken zonder het programma opnieuw te laden.

XDP is een eBPF-hookpunt. Het koppelt zich aan het ontvangstpad van de NIC-driver, voordat de kernel een sk_buff structuur toewijst (het metadata-object van 200-300 bytes per pakket waar de traditionele netwerkstack van afhankelijk is). Het overslaan van die toewijzing is waar de prestatiewinst vandaan komt.

XDP draait in drie modi:

• Native-modus: draait binnen het NIC-stuurprogramma. Beste prestaties.
• Offloaded-modus: draait op de ASIC van de NIC. Maakt de CPU volledig vrij.
• Generieke modus: draait na sk_buff toewijzing. Handig voor het testen op niet-ondersteunde hardware, maar geen prestatievoordeel.

Na het verwerken van elk pakket geeft het XDP-programma een oordeel:

XDP versus iptables: prestatiebenchmarks

De cijfers spreken voor zich. iptables verwerkt ongeveer 200.000 pakketten per seconde per kern. nftables verbetert dat tot ongeveer 400.000 pps. XDP in native mode verwerkt 10 tot 40 miljoen pps per core op dezelfde hardware.

De reden is simpel: een XDP_DROP kost één grenscontrole en een retourwaarde. Een iptables DROP vereist sk_buff toewijzing, het doorlopen van de netfilter-keten, het opzoeken van de verbindingstracking, de DROP-actie zelf en vervolgens het vrijgeven van geheugen. Bij 100 Gbps met pakketten van 64 bytes krijgt een server 148 miljoen pakketten per seconde te verwerken, wat neerkomt op ongeveer 100 nanoseconden per pakket. Op die schaal sk_buff wordt toewijzing de bottleneck.

De besparing op de CPU is net zo aanzienlijk. Het verplaatsen van een blokkeerlijst van iptables naar XDP in één benchmark verminderde het CPU-gebruik door software-interrupts van 28% naar 3% bij 1 miljoen pps. Die vrijgekomen ruimte kan worden gebruikt om applicatieprocessen, databases of virtuele machines op dezelfde server te draaien.

DDoS-beperking en beveiliging

De sterkste use case van XDP voor hosting is DDoS-mitigatie. Omdat het op driverniveau werkt, worden kwaadaardige pakketten verwijderd voordat ze de netwerkstack van de kernel bereiken. Een enkele core waarop XDP draait, kan 26 miljoen pakketten per seconde verwijderen.

Cloudflare gebruikt al sinds minstens 2018 een op XDP gebaseerd systeem genaamd L4Drop voor volumetrische DDoS-beperking. Het systeem verwerkt en verwijdert aanvalsverkeer in de XDP-context, waardoor het de applicatielaag niet kan bereiken. Meta's Katran, een open-source XDP Layer 4-loadbalancer, verwerkt verkeer voor Facebook en Instagram met meer dan 10 miljoen pps per core.

Voor dynamische filtering laten eBPF-maps zoals BPF_MAP_TYPE_LPM_TRIE kun je IP-blokkeerlijsten beheren die individuele IP's en CIDR-subnetten in één zoekopdracht omvatten. Updates vinden in realtime plaats vanuit de gebruikersruimte, zonder dat het programma opnieuw hoeft te worden geladen. Tijdens een actieve aanval kun je binnen milliseconden nieuwe handtekeningen pushen met behulp van bpftool:

bpftool map update id <MAP_ID> key <KEY_VALUE> value <VALUE>

Voor observability verzamelt eBPF per applicatie, per IP en per flow metrics rechtstreeks vanuit het kernel-datapad. De xdp_md context biedt telemetrie zoals ingress_ifindex en rx_queue_index, zodat u kunt vaststellen welke interface of wachtrij onder druk staat. Voor monitoring op de lange termijn zetten tools zoals ebpf_exporter zetten ruwe eBPF-kaartgegevens om in Prometheus-compatibele statistieken voor visualisatie in Grafana.

Tools, implementatie en hardwarevereisten

De toolchain begint met Clang en LLVM voor het compileren van restricted C naar eBPF-bytecode. Vervolgens hebt u een loader-bibliotheek nodig:

• libbpf: de standaard C-bibliotheek voor productiegebruik. Ondersteunt CO-RE (Compile Once, Run Everywhere) voor cross-kernel-portabiliteit.
• libxdp: XDP-specifiek, ondersteunt het draaien van meerdere XDP-programma's op één interface.
• cilium/ebpf: een pure Go-bibliotheek voor op Go gebaseerde stacks.

Voor beheer bpftool kunt u live programma's en mapinhoud inspecteren. xdp-loader (uit de xdp-tools suite) regelt het laden en ontladen. BCC is handig voor prototyping met Python/Lua-front-ends, maar libbpf met CO-RE is de betere keuze voor productie.

Schakel de BPF JIT-compiler in vóór de implementatie:

sysctl -w net.core.bpf_jit_enable=1

Gebruik voor updates zonder downtime de XDP_FLAGS_REPLACE vlag om een draaiend programma atomair te wisselen. Pin kaarten vast /sys/fs/bpf/ zodat ze behouden blijven nadat de loader is afgesloten.

Hardware- en kernelcompatibiliteit

XDP werd geïntroduceerd in kernel 4.8, maar 5.x of hoger wordt aanbevolen voor de volledige functieset. Controleer uw kernel met uname -r en controleer of het BPF-bestandssysteem bestaat op /sys/fs/bpf/.

Uw NIC-driver bepaalt welke XDP-functies beschikbaar zijn:

Controleer je driver met ethtool -i <interface>. Als de native modus niet wordt ondersteund, schakelt het systeem over naar de generieke modus, die na sk_buff toewijzing en biedt geen prestatievoordeel.

Schakel GRO en LRO uit voordat u een XDP-programma koppelt, aangezien ze conflicteren:

ethtool -K <iface> gro off lro off

Standaard XDP vereist dat pakketten in één geheugenpagina van 4.096 bytes passen. Op i40e en ice drivers is de x86 MTU-limiet 3.046 bytes.

Aan de slag met XDP

Begin met het beoordelen van uw omgeving. Voer uname -r om te controleren of u kernel 4.8+ (bij voorkeur 5.x) hebt, en ethtool -i <interface> om te controleren of er native ondersteuning is voor XDP-stuurprogramma's.

Begin met observatie, niet met handhaving. Gebruik eBPF-maps om verkeer te classificeren en te tellen, zodat u een basisniveau van normale activiteit hebt. Zodra u uw verkeerspatronen begrijpt, gaat u over tot handhaving: test eerst met xdpgeneric de modus en schakel vervolgens over naar xdpdrv (native) voor productie.

Houd er rekening mee dat XDP filtering op pakketniveau afhandelt, niet de ruwe bandbreedte. Voor grootschalige aanvallen van 100 Gbps combineert u het met bare-metal-infrastructuur en BGP FlowSpec om upstream-verkeer te beheren voordat het de server bereikt.

Als u workloads met veel verkeer uitvoert die snelle pakketfiltering vereisen, bieden de dedicated servers van FDC de bare-metal basis om het maximale uit XDP te halen.