XDP ed eBPF per l'elaborazione dei pacchetti ad alte prestazioni

XDP (eXpress Data Path) ed eBPF (extended Berkeley Packet Filter) consentono a Linux di elaborare i pacchetti di rete prima che entri in gioco il normale stack di rete del kernel. Invece di allocare strutture di memoria per ogni pacchetto in entrata, XDP intercetta il traffico direttamente al driver della scheda di rete, decide cosa farne e lo scarta, lo inoltra o lo reindirizza. Il risultato è un'elaborazione di milioni di pacchetti al secondo per core, con una frazione del carico della CPU rispetto agli strumenti tradizionali come iptables.

Come funzionano insieme eBPF e XDP

eBPF è una macchina virtuale all'interno del kernel Linux. Esegue bytecode personalizzato che è stato verificato per la sicurezza (nessun ciclo infinito, nessun accesso non autorizzato alla memoria) e poi compilato JIT in istruzioni native della CPU. I programmi hanno un ambito limitato. Non possono chiamare funzioni arbitrarie del kernel, ma solo un insieme di helper predefiniti per attività come la ricerca nelle mappe e il reindirizzamento dei pacchetti.

Per la gestione dello stato, eBPF utilizza mappe, ovvero archivi chiave/valore (tabelle hash, array, LPM tries) che persistono tra un arrivo di pacchetti e l'altro. Le mappe sono leggibili e scrivibili dallo spazio utente, quindi è possibile aggiornare le liste di blocco o le regole di routing senza ricaricare il programma.

XDP è un punto di aggancio eBPF. Si collega al percorso di ricezione del driver NIC, prima che il kernel allochi una sk_buff struttura (l'oggetto di metadati da 200-300 byte per pacchetto da cui dipende lo stack di rete tradizionale). Il salto di tale allocazione è la fonte del guadagno in termini di prestazioni.

XDP funziona in tre modalità:

• Modalità nativa: funziona all'interno del driver della scheda di rete. Massime prestazioni.
• Modalità offloaded: funziona sull'ASIC della scheda di rete. Libera completamente la CPU.
• Modalità generica: funziona dopo l' sk_buff l'allocazione. Utile per i test su hardware non supportato, ma senza alcun vantaggio in termini di prestazioni.

Dopo aver elaborato ogni pacchetto, il programma XDP restituisce un verdetto:

XDP vs iptables: benchmark delle prestazioni

I numeri sono evidenti. iptables gestisce circa 200.000 pacchetti al secondo per core. nftables migliora tale valore portandolo a circa 400.000 pps. XDP in modalità nativa elabora da 10 a 40 milioni di pps per core sullo stesso hardware.

Il motivo è semplice: un XDP_DROP costa un controllo dei limiti e un valore di ritorno. Un iptables DROP richiede sk_buff un'allocazione, l'attraversamento della catena di netfilter, la ricerca del tracciamento delle connessioni, l'azione DROP stessa e infine la deallocazione. A 100 Gbps con pacchetti da 64 byte, un server deve gestire 148 milioni di pacchetti al secondo, il che lascia circa 100 nanosecondi per pacchetto. A quella scala, sk_buff l'allocazione diventa il collo di bottiglia.

Il risparmio in termini di CPU è altrettanto significativo. Il passaggio di una lista di blocco da iptables a XDP in un benchmark ha ridotto l’utilizzo della CPU per gli interrupt software dal 28% al 3% a 1 milione di pps. Lo spazio liberato può essere utilizzato per eseguire processi applicativi, database o macchine virtuali sullo stesso server.

Mitigazione DDoS e sicurezza

Il caso d'uso più significativo di XDP nell'hosting è la mitigazione degli attacchi DDoS. Poiché opera a livello di driver, i pacchetti dannosi vengono eliminati prima che raggiungano lo stack di rete del kernel. Un singolo core che esegue XDP può eliminare 26 milioni di pacchetti al secondo.

Cloudflare utilizza un sistema basato su XDP chiamato L4Drop per la mitigazione degli attacchi DDoS volumetrici almeno dal 2018. Il sistema elabora e elimina il traffico di attacco nel contesto XDP, impedendogli di raggiungere il livello applicativo. Katran di Meta, un bilanciatore di carico open source XDP di livello 4, gestisce il traffico per Facebook e Instagram a oltre 10 milioni di pps per core.

Per il filtraggio dinamico, le mappe eBPF come BPF_MAP_TYPE_LPM_TRIE consentono di gestire liste di blocco IP che coprono singoli IP e sottoreti CIDR in un'unica ricerca. Gli aggiornamenti avvengono dallo spazio utente in tempo reale, senza necessità di ricaricare il programma. Durante un attacco attivo, è possibile inviare nuove firme in pochi millisecondi utilizzando bpftool:

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

Per l'osservabilità, eBPF raccoglie metriche per applicazione, per IP e per flusso direttamente dal percorso dati del kernel. Il xdp_md contesto fornisce telemetria come ingress_ifindex e rx_queue_index, in modo da poter identificare quale interfaccia o coda è sotto pressione. Per il monitoraggio a lungo termine, strumenti come ebpf_exporter convertono i dati grezzi della mappa eBPF in metriche compatibili con Prometheus per la visualizzazione in Grafana.

Strumenti, implementazione e requisiti hardware

La catena di strumenti inizia con Clang e LLVM per la compilazione di C ristretto in bytecode eBPF. Da lì, è necessaria una libreria di caricamento:

• libbpf: la libreria C standard per l'uso in produzione. Supporta CO-RE (Compile Once, Run Everywhere) per la portabilità tra kernel.
• libxdp: specifica per XDP, supporta l'esecuzione di più programmi XDP su una singola interfaccia.
• cilium/ebpf: una libreria Go pura per stack basati su Go.

Per la gestione, bpftool consente di ispezionare i programmi in esecuzione e mappare i contenuti. xdp-loader (dalla xdp-tools suite) gestisce il caricamento e lo scaricamento. BCC è utile per la prototipazione con front-end Python/Lua, ma libbpf con CO-RE è la scelta migliore per la produzione.

Abilita il compilatore JIT BPF prima della distribuzione:

sysctl -w net.core.bpf_jit_enable=1

Per aggiornamenti senza tempi di inattività, utilizzare il XDP_FLAGS_REPLACE flag per sostituire in modo atomico un programma in esecuzione. Fissare le mappe in modo /sys/fs/bpf/ in modo che rimangano dopo l'uscita del caricatore.

Compatibilità hardware e del kernel

XDP è stato introdotto nel kernel 4.8, ma si consiglia la versione 5.x o successive per l'insieme completo di funzionalità. Verifica il tuo kernel con uname -r e verificare che il filesystem BPF esista in /sys/fs/bpf/.

Il driver della scheda di rete determina quali funzionalità XDP sono disponibili:

Verifica il tuo driver con ethtool -i <interface>. Se la modalità nativa non è supportata, il sistema ricorre alla modalità generica, che viene eseguita dopo l' sk_buff l'allocazione e non offre alcun vantaggio in termini di prestazioni.

Disattiva GRO e LRO prima di collegare un programma XDP, poiché sono in conflitto:

ethtool -K <iface> gro off lro off

L'XDP standard richiede che i pacchetti entrino in una singola pagina di memoria da 4.096 byte. Su i40e e ice , il limite MTU x86 è di 3.046 byte.

Introduzione a XDP

Inizia valutando il tuo ambiente. Esegui uname -r per verificare che il kernel sia 4.8+ (preferibilmente 5.x) e ethtool -i <interface> per verificare il supporto nativo del driver XDP.

Inizia con l'osservabilità, non con l'applicazione. Usa le mappe eBPF per classificare e contare il traffico in modo da avere una linea di base dell'attività normale. Una volta compresi i tuoi modelli di traffico, passa all'applicazione: esegui i test in xdpgeneric modalità, poi passa a xdpdrv (nativo) per la produzione.

Tenete presente che XDP gestisce il filtraggio a livello di pacchetto, non la larghezza di banda grezza. Per attacchi su larga scala a 100 Gbps, abbinatelo a un'infrastruttura bare-metal e a BGP FlowSpec per gestire il traffico a monte prima che raggiunga il server.

Se si eseguono carichi di lavoro ad alto traffico che richiedono un filtraggio veloce dei pacchetti, i server dedicati di FDC forniscono la base bare-metal per ottenere il massimo da XDP.