XDP i eBPF do wysokowydajnego przetwarzania pakietów

XDP (eXpress Data Path) i eBPF (extended Berkeley Packet Filter) pozwalają systemowi Linux przetwarzać pakiety sieciowe, zanim zaangażowany zostanie normalny stos sieciowy jądra. Zamiast przydzielać struktury pamięci dla każdego przychodzącego pakietu, XDP przechwytuje ruch bezpośrednio w sterowniku karty sieciowej, decyduje, co z nim zrobić, i albo go odrzuca, przekazuje dalej, albo przekierowuje. Wynikiem tego jest przetwarzanie milionów pakietów na sekundę na rdzeń, przy ułamku obciążenia procesora w porównaniu z tradycyjnymi narzędziami, takimi jak iptables.

Jak współpracują eBPF i XDP

eBPF to maszyna wirtualna wewnątrz jądra systemu Linux. Uruchamia ona niestandardowy kod bajtowy, który został zweryfikowany pod kątem bezpieczeństwa (brak pętli nieskończonych, brak nieautoryzowanego dostępu do pamięci), a następnie skompilowany metodą JIT do natywnych instrukcji procesora. Programy mają ograniczony zakres działania. Nie mogą wywoływać dowolnych funkcji jądra, a jedynie zestaw predefiniowanych funkcji pomocniczych do zadań takich jak wyszukiwanie w mapach i przekierowywanie pakietów.

Do zarządzania stanem eBPF wykorzystuje mapy, które są magazynami kluczy/wartości (tabele skrótów, tablice, drzewa LPM) utrzymującymi się między kolejnymi przybyciami pakietów. Mapy są czytelne i zapisywalne z przestrzeni użytkownika, więc można aktualizować listy blokowanych adresów lub reguły routingu bez ponownego ładowania programu.

XDP jest punktem zaczepienia eBPF. Dołącza się do ścieżki odbiorczej sterownika karty sieciowej, zanim jądro przydzieli strukturę sk_buff struktury (obiektu metadanych o wielkości 200–300 bajtów na pakiet, od którego zależy tradycyjny stos sieciowy). Pominięcie tej alokacji jest źródłem wzrostu wydajności.

XDP działa w trzech trybach:

• Tryb natywny: działa wewnątrz sterownika karty sieciowej. Najlepsza wydajność.
• Tryb odciążony: działa na układzie ASIC karty sieciowej. Całkowicie odciąża procesor.
• Tryb generyczny: działa po sk_buff alokacji. Przydatny do testowania na nieobsługiwanym sprzęcie, ale bez korzyści wydajnościowych.

Po przetworzeniu każdego pakietu program XDP zwraca werdykt:

XDP a iptables: testy wydajności

Liczby są surowe. iptables Obsługuje około 200 000 pakietów na sekundę na rdzeń. nftables poprawia ten wynik do około 400 000 pps. XDP w trybie natywnym przetwarza od 10 do 40 milionów pps na rdzeń na tym samym sprzęcie.

Powód jest prosty: XDP_DROP kosztuje jedno sprawdzenie granic i wartość zwracaną. iptables DROP wymaga sk_buff alokacji, przejścia przez łańcuch netfilter, wyszukiwania śledzenia połączeń, samej akcji DROP, a następnie deallokacji. Przy przepustowości 100 Gb/s i pakietach o wielkości 64 bajtów serwer obsługuje 148 milionów pakietów na sekundę, co pozostawia około 100 nanosekund na pakiet. W tej skali sk_buff alokacja staje się wąskim gardłem.

Oszczędności w zakresie obciążenia procesora są równie znaczące. Przeniesienie listy blokowanych adresów z iptables do XDP w jednym teście porównawczym zmniejszyło wykorzystanie procesora przez przerwy programowe z 28% do 3% przy 1 milionie pps. To zwolnione miejsce pozwala na uruchamianie procesów aplikacji, baz danych lub maszyn wirtualnych na tym samym serwerze

Ograniczanie ataków DDoS i bezpieczeństwo

Najsilniejszym argumentem przemawiającym za wykorzystaniem XDP w hostingu jest łagodzenie skutków ataków DDoS. Ponieważ działa on na poziomie sterownika, złośliwe pakiety są odrzucane, zanim dotrą do stosu sieciowego jądra. Pojedynie rdzeń z uruchomionym XDP może odrzucić 26 milionów pakietów na sekundę.

Cloudflare używa systemu opartego na XDP o nazwie L4Drop do łagodzenia ataków DDoS typu volumetric przynajmniej od 2018 roku. System przetwarza i odrzuca ruch ataku w kontekście XDP, zapobiegając jego dotarciu do warstwy aplikacji. Katran firmy Meta, open-source'owy balanser obciążenia warstwy 4 XDP, obsługuje ruch dla Facebooka i Instagrama z prędkością ponad 10 milionów pps na rdzeń.

W przypadku filtrowania dynamicznego mapy eBPF, takie jak BPF_MAP_TYPE_LPM_TRIE pozwalają zarządzać listami blokowanych adresów IP obejmującymi pojedyncze adresy IP i podsieci CIDR w ramach jednego wyszukiwania. Aktualizacje odbywają się z przestrzeni użytkownika w czasie rzeczywistym, bez konieczności ponownego ładowania programu. Podczas aktywnego ataku można przesyłać nowe sygnatury w ciągu milisekund za pomocą bpftool:

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

W celu zapewnienia obserwowalności eBPF gromadzi metryki dla poszczególnych aplikacji, adresów IP i przepływów bezpośrednio ze ścieżki danych jądra. xdp_md kontekst dostarcza telemetrię, taką jak ingress_ifindex i rx_queue_index, dzięki czemu można zidentyfikować, który interfejs lub kolejka jest obciążona. W celu długoterminowego monitorowania narzędzia takie jak ebpf_exporter przekształcają surowe dane mapy eBPF w metryki zgodne z Prometheusem w celu wizualizacji w Grafanie.

Narzędzia, wdrożenie i wymagania sprzętowe

Zestaw narzędzi zaczyna się od Clang i LLVM do kompilacji ograniczonego języka C do kodu bajtowego eBPF. Następnie potrzebna jest biblioteka ładująca:

• libbpf: standardowa biblioteka C do użytku produkcyjnego. Obsługuje CO-RE (Compile Once, Run Everywhere) w celu zapewnienia przenośności między jądkami.
• libxdp: specyficzna dla XDP, obsługuje uruchamianie wielu programów XDP na jednym interfejsie.
• cilium/ebpf: biblioteka napisana w czystym Go dla stosów opartych na Go.

Do zarządzania bpftool umożliwia sprawdzanie programów działających na żywo oraz mapowanie zawartości. xdp-loader (z xdp-tools pakietu) obsługuje ładowanie i wyładowywanie. BCC jest przydatne do prototypowania z front-endami w Python/Lua, ale libbpf w środowisku produkcyjnym lepszym wyborem jest CO-RE.

Włącz kompilator BPF JIT przed wdrożeniem:

sysctl -w net.core.bpf_jit_enable=1

Aby uzyskać aktualizacje bez przestojów, użyj flagi XDP_FLAGS_REPLACE flagi, aby atomowo zamienić uruchomiony program. Przypnij mapy do /sys/fs/bpf/ , aby zachowały się po zamknięciu modułu ładującego.

Zgodność sprzętowa i z jądrem

XDP został wprowadzony w jądrze 4.8, ale do korzystania z pełnego zestawu funkcji zalecane jest jądro 5.x lub nowsze. Sprawdź swoje jądro za pomocą uname -r i sprawdź, czy system plików BPF istnieje w /sys/fs/bpf/.

Twój sterownik karty sieciowej określa, które funkcje XDP są dostępne:

Sprawdź sterownik za pomocą ethtool -i <interface>. Jeśli tryb natywny nie jest obsługiwany, system przechodzi do trybu ogólnego, który uruchamia się po sk_buff alokacji i nie zapewnia żadnych korzyści w zakresie wydajności.

Wyłącz GRO i LRO przed dołączeniem programu XDP, ponieważ powodują one konflikt:

ethtool -K <iface> gro off lro off

Standardowy XDP wymaga, aby pakiety mieściły się na jednej stronie pamięci o rozmiarze 4096 bajtów. W i40e i ice , limit MTU dla x86 wynosi 3046 bajtów.

Pierwsze kroki z XDP

Zacznij od oceny swojego środowiska. Uruchom uname -r , aby sprawdzić, czy masz jądro 4.8+ (preferowane 5.x), oraz ethtool -i <interface> , aby sprawdzić obsługę natywnego sterownika XDP.

Zacznij od obserwowalności, a nie egzekwowania. Użyj map eBPF do klasyfikacji i zliczania ruchu, aby uzyskać punkt odniesienia dla normalnej aktywności. Gdy już zrozumiesz wzorce ruchu, przejdź do egzekwowania: najpierw przetestuj w xdpgeneric trybu, a następnie przejdź do xdpdrv (natywny) w środowisku produkcyjnym.

Pamiętaj, że XDP obsługuje filtrowanie na poziomie pakietów, a nie surową przepustowość. W przypadku ataków na dużą skalę przy 100 Gb/s połącz go z infrastrukturą typu bare-metal i BGP FlowSpec, aby zarządzać ruchem upstream, zanim dotrze on do serwera.

Jeśli obsługujesz obciążenia o dużym natężeniu ruchu, które wymagają szybkiego filtrowania pakietów, serwery dedykowane FDC zapewniają podstawę typu bare-metal, pozwalającą w pełni wykorzystać możliwości XDP.