XDP und eBPF für hochleistungsfähige Paketverarbeitung

XDP (eXpress Data Path) und eBPF (extended Berkeley Packet Filter) ermöglichen es Linux, Netzwerkpakete zu verarbeiten, bevor der normale Netzwerkstack des Kernels zum Einsatz kommt. Anstatt für jedes eingehende Paket Speicherstrukturen zuzuweisen, fängt XDP den Datenverkehr direkt am NIC-Treiber ab, entscheidet, was damit geschehen soll, und verwirft, leitet weiter oder umleitet ihn. Das Ergebnis ist eine Paketverarbeitung von Millionen von Paketen pro Sekunde und Kern, bei einem Bruchteil des CPU-Overheads herkömmlicher Tools wie iptables.

Wie eBPF und XDP zusammenarbeiten

eBPF ist eine virtuelle Maschine innerhalb des Linux-Kernels. Sie führt benutzerdefinierten Bytecode aus, der auf Sicherheit geprüft wurde (keine Endlosschleifen, kein unbefugter Speicherzugriff) und anschließend per JIT in native CPU-Befehle kompiliert wurde. Programme sind in ihrem Umfang begrenzt. Sie können keine beliebigen Kernel-Funktionen aufrufen, sondern nur eine Reihe vordefinierter Hilfsfunktionen für Aufgaben wie Map-Lookups und Paketumleitung.

Für die Zustandsverwaltung verwendet eBPF Maps, also Schlüssel-Wert-Speicher (Hash-Tabellen, Arrays, LPM-Tries), die über das Eintreffen von Paketen hinweg bestehen bleiben. Maps sind vom Userspace aus les- und beschreibbar, sodass Sie Blocklisten oder Routing-Regeln aktualisieren können, ohne das Programm neu zu laden.

XDP ist ein eBPF-Hook-Punkt. Es wird an den Empfangspfad des NIC-Treibers angehängt, bevor der Kernel eine sk_buff Struktur zuweist (das 200–300 Byte große Metadatenobjekt pro Paket, auf das der traditionelle Netzwerkstack angewiesen ist). Das Überspringen dieser Zuweisung ist der Grund für den Leistungsgewinn.

XDP läuft in drei Modi:

• Native-Modus: läuft innerhalb des NIC-Treibers. Beste Leistung.
• Offload-Modus: läuft auf dem ASIC der Netzwerkkarte. Entlastet die CPU vollständig.
• Generischer Modus: läuft nach der sk_buff Zuweisung. Nützlich für Tests auf nicht unterstützter Hardware, bietet jedoch keinen Leistungsvorteil.

Nach der Verarbeitung jedes Pakets gibt das XDP-Programm ein Ergebnis zurück:

XDP vs. iptables: Leistungsbenchmarks

Die Zahlen sprechen für sich. iptables verarbeitet etwa 200.000 Pakete pro Sekunde pro Kern. nftables verbessert dies auf rund 400.000 pps. XDP im nativen Modus verarbeitet 10 bis 40 Millionen pps pro Kern auf derselben Hardware.

Der Grund ist einfach: Ein XDP_DROP kostet eine Bereichsprüfung und einen Rückgabewert. Ein iptables DROP erfordert sk_buff eine Zuweisung, das Durchlaufen der Netfilter-Kette, eine Verbindungskontrolle, die DROP-Aktion selbst und anschließend eine Freigabe. Bei 100 Gbit/s mit 64-Byte-Paketen muss ein Server 148 Millionen Pakete pro Sekunde verarbeiten, was etwa 100 Nanosekunden pro Paket lässt. In dieser Größenordnung sk_buff wird die Zuweisung zum Engpass.

Die CPU-Einsparungen sind ebenso bedeutend. Die Verlagerung einer Blockliste von iptables auf XDP reduzierte in einem Benchmark die CPU-Auslastung durch Software-Interrupts bei 1 Million pps von 28 % auf 3 %. Der dadurch gewonnene Spielraum kann zur Ausführung von Anwendungsprozessen, Datenbanken oder virtuellen Maschinen auf demselben Server genutzt werden.

DDoS-Abwehr und Sicherheit

Der stärkste Anwendungsfall von XDP im Hosting-Bereich ist die DDoS-Abwehr. Da es auf Treiber-Ebene arbeitet, werden bösartige Pakete abgewehrt, bevor sie den Netzwerkstack des Kernels erreichen. Ein einzelner Kern, auf dem XDP läuft, kann 26 Millionen Pakete pro Sekunde abweisen.

Cloudflare setzt seit mindestens 2018 ein XDP-basiertes System namens L4Drop zur Abwehr volumetrischer DDoS-Angriffe ein. Das System verarbeitet und verwirft Angriffsverkehr im XDP-Kontext und verhindert so, dass dieser die Anwendungsschicht erreicht. Metas Katran, ein Open-Source-XDP-Layer-4-Load-Balancer, verarbeitet den Datenverkehr für Facebook und Instagram mit über 10 Millionen Paketen pro Sekunde pro Kern.

Für die dynamische Filterung ermöglichen eBPF-Maps wie BPF_MAP_TYPE_LPM_TRIE die Verwaltung von IP-Blocklisten, die einzelne IPs und CIDR-Subnetze in einem einzigen Lookup abdecken. Aktualisierungen erfolgen in Echtzeit aus dem Userspace, ein Neuladen des Programms ist nicht erforderlich. Während eines aktiven Angriffs können Sie neue Signaturen innerhalb von Millisekunden über bpftool:

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

Zur Observability sammelt eBPF Metriken pro Anwendung, pro IP und pro Datenfluss direkt aus dem Kernel-Datenpfad. Der xdp_md Kontext liefert Telemetriedaten wie ingress_ifindex und rx_queue_index, sodass Sie erkennen können, welche Schnittstelle oder Warteschlange unter Druck steht. Für die Langzeitüberwachung wandeln Tools wie ebpf_exporter wandeln rohe eBPF-Map-Daten in Prometheus-kompatible Metriken um, die in Grafana visualisiert werden können.

Tools, Bereitstellung und Hardwareanforderungen

Die Toolchain beginnt mit Clang und LLVM zum Kompilieren von Restricted C in eBPF-Bytecode. Von dort aus benötigen Sie eine Loader-Bibliothek:

• libbpf: die Standard-C-Bibliothek für den produktiven Einsatz. Unterstützt CO-RE (Compile Once, Run Everywhere) für kernübergreifende Portabilität.
• libxdp: XDP-spezifisch, unterstützt die Ausführung mehrerer XDP-Programme auf einer einzigen Schnittstelle.
• cilium/ebpf: eine reine Go-Bibliothek für Go-basierte Stacks.

Zur Verwaltung bpftool können Sie mit Live-Programme und Map-Inhalte überprüfen. xdp-loader (aus der xdp-tools Suite) übernimmt das Laden und Entladen. BCC eignet sich gut für das Prototyping mit Python-/Lua-Frontends, aber libbpf mit CO-RE ist die bessere Wahl für die Produktion.

Aktivieren Sie den BPF-JIT-Compiler vor der Bereitstellung:

sysctl -w net.core.bpf_jit_enable=1

Für Updates ohne Ausfallzeiten verwenden Sie das XDP_FLAGS_REPLACE Flag, um ein laufendes Programm atomar auszutauschen. Heften Sie Maps an /sys/fs/bpf/ , damit sie nach Beendigung des Loaders erhalten bleiben.

Hardware- und Kernel-Kompatibilität

XDP wurde in Kernel 4.8 eingeführt, für den vollen Funktionsumfang wird jedoch 5.x oder höher empfohlen. Überprüfen Sie Ihren Kernel mit uname -r und überprüfen Sie, ob das BPF-Dateisystem unter /sys/fs/bpf/.

Ihr NIC-Treiber bestimmt, welche XDP-Funktionen verfügbar sind:

Überprüfen Sie Ihren Treiber mit ethtool -i <interface>. Wenn der native Modus nicht unterstützt wird, weicht das System auf den generischen Modus aus, der nach der sk_buff Zuweisung läuft und keinen Leistungsvorteil bietet.

Deaktivieren Sie GRO und LRO, bevor Sie ein XDP-Programm anhängen, da sie miteinander in Konflikt stehen:

ethtool -K <iface> gro off lro off

Standard-XDP erfordert, dass Pakete auf eine einzelne 4.096-Byte-Speicherseite passen. Bei i40e und ice Treiber beträgt die x86-MTU-Grenze 3.046 Byte.

Erste Schritte mit XDP

Beginnen Sie mit der Bewertung Ihrer Umgebung. Führen Sie uname -r aus, um zu überprüfen, ob Kernel 4.8+ (vorzugsweise 5.x) installiert ist, und ethtool -i <interface> um die native XDP-Treiberunterstützung zu prüfen.

Beginnen Sie mit der Beobachtbarkeit, nicht mit der Durchsetzung. Verwenden Sie eBPF-Maps, um den Datenverkehr zu klassifizieren und zu zählen, damit Sie eine Basislinie für normale Aktivitäten erhalten. Sobald Sie Ihre Datenverkehrsmuster verstanden haben, gehen Sie zur Durchsetzung über: Testen Sie zunächst im xdpgeneric Modus und wechseln Sie dann xdpdrv (native) für die Produktion.

Beachten Sie, dass XDP die Filterung auf Paketebene übernimmt, nicht die reine Bandbreite. Bei groß angelegten Angriffen mit 100 Gbit/s sollten Sie es mit einer Bare-Metal-Infrastruktur und BGP FlowSpec kombinieren, um den Upstream-Datenverkehr zu verwalten, bevor er den Server erreicht.

Wenn Sie Workloads mit hohem Datenverkehr ausführen, die eine schnelle Paketfilterung erfordern, bieten die dedizierten Server von FDC die Bare-Metal-Grundlage, um das Beste aus XDP herauszuholen.