XDP et eBPF pour le traitement haute performance des paquets

XDP (eXpress Data Path) et eBPF (extended Berkeley Packet Filter) permettent à Linux de traiter les paquets réseau avant que la pile réseau normale du noyau n'intervienne. Au lieu d'allouer des structures mémoire pour chaque paquet entrant, XDP intercepte le trafic directement au niveau du pilote de carte réseau, décide quoi en faire, puis le rejette, le transfère ou le redirige. Il en résulte un traitement de paquets à des millions de paquets par seconde et par cœur, avec une fraction de la charge CPU des outils traditionnels tels que iptables.

Comment eBPF et XDP fonctionnent ensemble

eBPF est une machine virtuelle intégrée au noyau Linux. Elle exécute un bytecode personnalisé dont la sécurité a été vérifiée (pas de boucles infinies, pas d’accès non autorisé à la mémoire), puis compilé en temps réel (JIT) en instructions CPU natives. Les programmes ont une portée limitée. Ils ne peuvent pas appeler des fonctions du noyau de manière arbitraire, mais uniquement un ensemble d’assistants prédéfinis pour des tâches telles que la recherche dans des tables de correspondance et la redirection de paquets.

Pour la gestion de l'état, eBPF utilise des cartes, qui sont des magasins de clés/valeurs (tables de hachage, tableaux, arbres LPM) qui persistent entre les arrivées de paquets. Les cartes sont lisibles et modifiables depuis l'espace utilisateur, ce qui permet de mettre à jour des listes de blocage ou des règles de routage sans recharger le programme.

XDP est un point de hook eBPF. Il s'attache au chemin de réception du pilote NIC, avant que le noyau n'alloue une sk_buff structure (l'objet de métadonnées de 200 à 300 octets par paquet dont dépend la pile réseau traditionnelle). C'est en sautant cette allocation que l'on obtient le gain de performances.

XDP fonctionne selon trois modes :

• Mode natif : s'exécute à l'intérieur du pilote de la carte réseau. Meilleures performances.
• Mode déchargé : s'exécute sur l'ASIC de la carte réseau. Libère entièrement le CPU.
• Mode générique : s'exécute après sk_buff allocation. Utile pour les tests sur du matériel non pris en charge, mais sans gain de performances.

Après avoir traité chaque paquet, le programme XDP renvoie un verdict :

XDP vs iptables : tests de performance

Les chiffres sont éloquents. iptables traite environ 200 000 paquets par seconde et par cœur. nftables XDP en mode natif traite entre 10 et 40 millions de paquets par seconde par cœur sur le même matériel.

La raison est simple : un XDP_DROP coûte une vérification de limites et une valeur de retour. Un iptables DROP nécessite sk_buff une allocation, un parcours de la chaîne netfilter, une recherche de suivi de connexion, l’action DROP elle-même, puis une désallocation. À 100 Gbps avec des paquets de 64 octets, un serveur traite 148 millions de paquets par seconde, ce qui laisse environ 100 nanosecondes par paquet. À cette échelle, sk_buff l'allocation devient le goulot d'étranglement.

Les gains en termes de CPU sont tout aussi significatifs. Le passage d’une liste noire iptables vers XDP lors d’un test de performance a réduit l’utilisation du processeur par les interruptions logicielles de 28 % à 3 % à 1 million de paquets par seconde. Cette marge de manœuvre ainsi libérée permet d’exécuter des processus d’application, des bases de données ou des machines virtuelles sur le même serveur.

Atténuation des attaques DDoS et sécurité

Le principal cas d'utilisation de l'hébergement XDP est l'atténuation des attaques DDoS. Comme il fonctionne au niveau du pilote, les paquets malveillants sont rejetés avant d'atteindre la pile réseau du noyau. Un seul cœur exécutant XDP peut rejeter 26 millions de paquets par seconde.

Cloudflare utilise depuis au moins 2018 un système basé sur XDP appelé L4Drop pour l'atténuation des attaques DDoS volumétriques. Le système traite et rejette le trafic malveillant dans le contexte XDP, l'empêchant ainsi d'atteindre la couche applicative. Katran de Meta, un équilibreur de charge open source de couche 4 basé sur XDP, gère le trafic de Facebook et d'Instagram à un débit de plus de 10 millions de paquets par seconde par cœur.

Pour le filtrage dynamique, les mappages eBPF tels que BPF_MAP_TYPE_LPM_TRIE vous permettent de gérer des listes noires d'adresses IP couvrant des adresses IP individuelles et des sous-réseaux CIDR en une seule recherche. Les mises à jour s'effectuent depuis l'espace utilisateur en temps réel, sans qu'il soit nécessaire de recharger le programme. Lors d'une attaque en cours, vous pouvez pousser de nouvelles signatures en quelques millisecondes à l'aide de bpftool:

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

En matière d'observabilité, eBPF collecte des métriques par application, par adresse IP et par flux directement à partir du chemin de données du noyau. Le xdp_md contexte fournit des données de télémétrie telles que ingress_ifindex et rx_queue_index, ce qui vous permet d'identifier quelle interface ou file d'attente est sous pression. Pour la surveillance à long terme, des outils tels que ebpf_exporter convertissent les données brutes de la carte eBPF en métriques compatibles avec Prometheus pour une visualisation dans Grafana.

Outils, déploiement et configuration matérielle requise

La chaîne d'outils commence par Clang et LLVM pour compiler du C restreint en bytecode eBPF. À partir de là, vous avez besoin d'une bibliothèque de chargement :

• libbpf: la bibliothèque C standard pour une utilisation en production. Prend en charge CO-RE (Compile Once, Run Everywhere) pour la portabilité inter-noyaux.
• libxdp: spécifique à XDP, prend en charge l'exécution de plusieurs programmes XDP sur une seule interface.
• cilium/ebpf: une bibliothèque purement Go pour les piles basées sur Go.

Pour la gestion, bpftool vous permet d'inspecter les programmes en cours d'exécution et de cartographier le contenu. xdp-loader (issu de la xdp-tools suite) gère le chargement et le déchargement. BCC est utile pour le prototypage avec des interfaces Python/Lua, mais libbpf avec CO-RE, c'est le meilleur choix pour la production.

Activez le compilateur JIT BPF avant le déploiement :

sysctl -w net.core.bpf_jit_enable=1

Pour des mises à jour sans interruption de service, utilisez le XDP_FLAGS_REPLACE indicateur pour remplacer de manière atomique un programme en cours d'exécution. Épinglez les mappages afin /sys/fs/bpf/ afin qu'elles persistent après la fermeture du chargeur.

Compatibilité matérielle et du noyau

XDP a été introduit dans le noyau 4.8, mais la version 5.x ou ultérieure est recommandée pour bénéficier de l'ensemble des fonctionnalités. Vérifiez votre noyau avec uname -r et vérifiez que le système de fichiers BPF existe à l'emplacement /sys/fs/bpf/.

Votre pilote de carte réseau détermine les fonctionnalités XDP disponibles :

Vérifiez votre pilote avec ethtool -i <interface>. Si le mode natif n'est pas pris en charge, le système bascule en mode générique, qui s'exécute après sk_buff l'allocation et n'offre aucun avantage en termes de performances.

Désactivez GRO et LRO avant de lier un programme XDP, car ils sont en conflit :

ethtool -K <iface> gro off lro off

Le XDP standard exige que les paquets tiennent dans une seule page mémoire de 4 096 octets. Sur i40e pilotes ice pilotes, la limite MTU x86 est de 3 046 octets.

Premiers pas avec XDP

Commencez par évaluer votre environnement. Exécutez uname -r pour vérifier que le noyau est en version 4.8 ou supérieure (5.x de préférence), et ethtool -i <interface> pour vérifier la prise en charge native du pilote XDP.

Commencez par l'observabilité, pas par l'application. Utilisez des cartes eBPF pour classer et compter le trafic afin d'établir une base de référence de l'activité normale. Une fois que vous comprenez vos schémas de trafic, passez à l'application : testez d'abord en xdpgeneric mode, puis passez au xdpdrv (mode natif) pour la production.

Gardez à l'esprit que XDP gère le filtrage au niveau des paquets, et non la bande passante brute. Pour les attaques à grande échelle à 100 Gbps, associez-le à une infrastructure bare-metal et à BGP FlowSpec pour gérer le trafic en amont avant qu'il n'atteigne le serveur.

Si vous exécutez des charges de travail à fort trafic nécessitant un filtrage rapide des paquets, les serveurs dédiés de FDC fournissent la base bare-metal nécessaire pour tirer le meilleur parti de XDP.