XDP och eBPF för högpresterande paketbearbetning

XDP (eXpress Data Path) och eBPF (extended Berkeley Packet Filter) låter Linux bearbeta nätverkspaket innan kärnans normala nätverksstack kopplas in. Istället för att allokera minnesstrukturer för varje inkommande paket, avlyssnar XDP trafiken direkt vid NIC-drivrutinen, bestämmer vad som ska göras med den och antingen släpper den, vidarebefordrar den eller omdirigerar den. Resultatet blir en paketbearbetning på miljontals paket per sekund per kärna, med en bråkdel av den CPU-belastning som traditionella verktyg som iptables.

Hur eBPF och XDP fungerar tillsammans

eBPF är en virtuell maskin inuti Linux-kärnan. Den kör anpassad bytecode som har verifierats för säkerhet (inga oändliga loopar, ingen obehörig minnesåtkomst) och sedan JIT-kompilerats till inbyggda CPU-instruktioner. Programmen har begränsad räckvidd. De kan inte anropa godtyckliga kärnfunktioner, utan endast en uppsättning fördefinierade hjälpfunktioner för uppgifter som kartuppslag och paketomdirigering.

För tillståndshantering använder eBPF kartor, som är nyckel/värdelagringar (hash-tabeller, arrayer, LPM-träd) som består över paketankomster. Kartor är läsbara och skrivbara från användarutrymmet, så du kan uppdatera blocklistor eller routningsregler utan att ladda om programmet.

XDP är en eBPF-krokpunkt. Den kopplas till NIC-drivrutinens mottagningsväg, innan kärnan allokerar en sk_buff struktur (det 200–300 byte stora metadataobjektet per paket som den traditionella nätverksstacken är beroende av). Det är genom att hoppa över den allokeringen som prestandavinst uppnås.

XDP körs i tre lägen:

• Native-läge: körs inuti NIC-drivrutinen. Bästa prestanda.
• Avlastat läge: körs på NIC:s ASIC. Frigör CPU:n helt.
• Generiskt läge: körs efter sk_buff allokering. Användbart för testning på icke-stödd hårdvara, men ger ingen prestandafördel.

Efter bearbetning av varje paket returnerar XDP-programmet ett utlåtande:

XDP vs iptables: Prestandajämförelser

Siffrorna talar sitt tydliga språk. iptables hanterar ungefär 200 000 paket per sekund per kärna. nftables förbättrar det till cirka 400 000 pps. XDP i native-läge bearbetar 10 till 40 miljoner pps per kärna på samma hårdvara.

Anledningen är enkel: en XDP_DROP kostar en gränskontroll och ett returvärde. En iptables DROP kräver sk_buff allokering, genomgång av netfilter-kedjan, uppslagning av anslutningsspårning, själva DROP-åtgärden och sedan avallokering. Vid 100 Gbps med 64-byte-paket möter en server 148 miljoner paket per sekund, vilket lämnar cirka 100 nanosekunder per paket. I den skalan sk_buff blir allokeringen flaskhalsen.

CPU-besparingarna är lika betydande. Att flytta en blocklista från iptables till XDP i ett benchmarktest minskade CPU-användningen för programvaruavbrott från 28 % till 3 % vid 1 miljon pps. Det frigjorda utrymmet kan användas för att köra applikationsprocesser, databaser eller virtuella maskiner på samma server.

DDoS-skydd och säkerhet

XDP:s starkaste användningsområde inom hosting är DDoS-skydd. Eftersom det fungerar på drivrutinsnivå avvisas skadliga paket innan de når kärnans nätverksstack. En enda kärna som kör XDP kan avvisa 26 miljoner paket per sekund.

Cloudflare har använt ett XDP-baserat system som kallas L4Drop för volymetrisk DDoS-skydd sedan åtminstone 2018. Systemet bearbetar och avvisar attacktrafik i XDP-kontexten, vilket förhindrar att den når applikationslagret. Metas Katran, en öppen källkodsbaserad XDP Layer 4-lastbalanserare, hanterar trafik för Facebook och Instagram med över 10 miljoner pps per kärna.

För dynamisk filtrering låter eBPF-mappar som BPF_MAP_TYPE_LPM_TRIE låter dig hantera IP-blocklistor som täcker enskilda IP-adresser och CIDR-undernät i en enda sökning. Uppdateringar sker från användarutrymmet i realtid, utan att programmet behöver laddas om. Under en aktiv attack kan du skicka nya signaturer på millisekunder med hjälp av bpftool:

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

För observabilitet samlar eBPF in mätvärden per applikation, per IP och per flöde direkt från kärnans dataväg. xdp_md kontexten tillhandahåller telemetri som ingress_ifindex och rx_queue_index, så att du kan identifiera vilket gränssnitt eller vilken kö som är under press. För långsiktig övervakning kan verktyg som ebpf_exporter omvandlar råa eBPF-kartdata till Prometheus-kompatibla mätvärden för visualisering i Grafana.

Verktyg, distribution och hårdvarukrav

Verktygskedjan börjar med Clang och LLVM för att kompilera begränsad C till eBPF-bytecode. Därefter behövs ett laddarbibliotek:

• libbpf: standardbiblioteket för C för produktionsanvändning. Stöder CO-RE (Compile Once, Run Everywhere) för portabilitet mellan olika kärnor.
• libxdp: XDP-specifikt, stöder körning av flera XDP-program på ett enda gränssnitt.
• cilium/ebpf: ett rent Go-bibliotek för Go-baserade stackar.

För hantering bpftool låter dig inspektera live-program och kartlägga innehåll. xdp-loader (från xdp-tools sviten) hanterar in- och utläsning. BCC är användbart för prototyputveckling med Python/Lua-front-ends, men libbpf med CO-RE är det bättre valet för produktion.

Aktivera BPF JIT-kompilatorn innan distribution:

sysctl -w net.core.bpf_jit_enable=1

För uppdateringar utan driftstopp, använd XDP_FLAGS_REPLACE flaggan för att atomärt byta ut ett program som körs. Fäst kartor till /sys/fs/bpf/ så att de kvarstår efter att laddaren avslutas.

Kompatibilitet med hårdvara och kärna

XDP introducerades i kärna 4.8, men 5.x eller senare rekommenderas för full funktionalitet. Kontrollera din kärna med uname -r och verifiera att BPF-filsystemet finns på /sys/fs/bpf/.

Din NIC-drivrutin avgör vilka XDP-funktioner som är tillgängliga:

Kontrollera din drivrutin med ethtool -i <interface>. Om inbyggt läge inte stöds faller systemet tillbaka till generiskt läge, vilket körs efter sk_buff allokering och ger inga prestandafördelar.

Inaktivera GRO och LRO innan du ansluter ett XDP-program, eftersom de är oförenliga:

ethtool -K <iface> gro off lro off

Standard-XDP kräver att paket får plats på en enda minnessida på 4 096 byte. På i40e och ice drivrutinerna är x86-MTU-gränsen 3 046 byte.

Komma igång med XDP

Börja med att utvärdera din miljö. Kör uname -r för att bekräfta att du har kärna 4.8+ (5.x rekommenderas) och ethtool -i <interface> för att kontrollera om det finns inbyggt stöd för XDP-drivrutiner.

Börja med observabilitet, inte tillämpning. Använd eBPF-kartor för att klassificera och räkna trafik så att du har en baslinje för normal aktivitet. När du förstår dina trafikmönster går du vidare till tillämpning: testa först i xdpgeneric läge först, och byt sedan till xdpdrv (inbyggt) för produktion.

Tänk på att XDP hanterar filtrering på paketnivå, inte rå bandbredd. För storskaliga attacker på 100 Gbps bör du kombinera det med bare-metal-infrastruktur och BGP FlowSpec för att hantera uppströmstrafiken innan den når servern.

Om du kör arbetsbelastningar med hög trafik som kräver snabb paketfiltrering, ger FDC:s dedikerade servrar den bare-metal-grund som krävs för att få ut det mesta av XDP.