XDP és eBPF a nagy teljesítményű csomagfeldolgozáshoz

Az XDP (eXpress Data Path) és az eBPF (extended Berkeley Packet Filter) lehetővé teszi a Linux számára, hogy a hálózati csomagokat feldolgozza, mielőtt a rendszermag normál hálózati stackje bekapcsolódna. Ahelyett, hogy minden bejövő csomaghoz memóriastruktúrákat allokálna, az XDP közvetlenül a NIC-illesztőprogramnál fogja meg a forgalmat, eldönti, mit kell vele tenni, majd eldobja, továbbítja vagy átirányítja. Az eredmény: csomagfeldolgozás másodpercenként több millió csomaggal magonként, a hagyományos eszközök, mint például a iptables.

Hogyan működik együtt az eBPF és az XDP

Az eBPF egy virtuális gép a Linux kernelen belül. Biztonsági szempontból ellenőrzött (nincs végtelen ciklus, nincs jogosulatlan memóriához való hozzáférés) egyéni bájtkódot futtat, amelyet aztán JIT-kompilálnak natív CPU-utasításokká. A programok hatóköre korlátozott. Nem hívhatnak meg tetszőleges kernel-függvényeket, csak egy előre definiált segédfüggvény-készletet olyan feladatokhoz, mint a térképkeresés és a csomagátirányítás.

Az állapotkezeléshez az eBPF térképeket használ, amelyek kulcs/érték tárolók (hash táblák, tömbök, LPM-trie-k), amelyek a csomagok érkezése során is megmaradnak. A térképek olvashatók és írhatók a felhasználói térből, így a program újratöltése nélkül frissítheti a blokkolási listákat vagy az útválasztási szabályokat.

Az XDP egy eBPF hook pont. A NIC-illesztőprogram vételi útvonalához kapcsolódik, még mielőtt a kernel sk_buff struktúrát (a hagyományos hálózati stack által használt, csomagonként 200–300 bájt méretű metaadatelemet). A teljesítménynövekedés abból származik, hogy kihagyják ezt az allokációt.

Az XDP három módban fut:

• Natív mód: a NIC-illesztőprogramon belül fut. A legjobb teljesítmény.
• Kiszerelt mód: a NIC ASIC-jén fut. Teljesen felszabadítja a CPU-t.
• Általános mód: a sk_buff allokáció után fut. Hasznos nem támogatott hardverek teszteléséhez, de nincs teljesítményelőnye.

Minden csomag feldolgozása után az XDP program eredményt ad vissza:

XDP vs iptables: Teljesítmény-összehasonlítás

A számok egyértelműek. iptables másodpercenként körülbelül 200 000 csomagot kezel magonként. nftables ezt körülbelül 400 000 pps-re növeli. Az XDP natív módban ugyanazon a hardveren magonként 10–40 millió pps-t dolgoz fel.

Az ok egyszerű: egy XDP_DROP egy határellenőrzést és egy visszatérési értéket igényel. Egy iptables DROP sk_buff allokációt, a netfilter lánc átfutását, a kapcsolatkövetés lekérdezését, magát a DROP műveletet, majd a deallokációt. 100 Gbps sebességnél 64 bájtos csomagokkal egy szerver másodpercenként 148 millió csomaggal szembesül, ami csomagonként körülbelül 100 nanoszekundumot jelent. Ilyen méretarányban sk_buff az allokáció válik a szűk keresztmetszetté.

A CPU-megtakarítás éppoly jelentős. Egy blokkolási lista áthelyezése iptables XDP-be egy benchmarkban 1 millió pps-nél 28%-ról 3%-ra csökkentette a szoftveres megszakítások CPU-használatát. Ezzel felszabadult kapacitás alkalmazásfolyamatok, adatbázisok vagy virtuális gépek futtatására használható ugyanazon a szerveren.

DDoS-csökkentés és biztonság

Az XDP legerősebb hosting felhasználási esete a DDoS-csökkentés. Mivel illesztőprogram szinten működik, a rosszindulatú csomagokat még azelőtt eldobja, hogy azok elérnék a rendszermag hálózati rétegét. Egyetlen, XDP-t futtató mag másodpercenként 26 millió csomagot képes eldobni.

A Cloudflare legalább 2018 óta használ egy L4Drop nevű, XDP-alapú rendszert a volumetrikus DDoS-csökkentéshez. A rendszer az XDP-kontextusban feldolgozza és eldobja a támadó forgalmat, megakadályozva, hogy az eljusson az alkalmazásrétegig. A Meta Katran nevű, nyílt forráskódú XDP 4. rétegű terheléselosztója magonként több mint 10 millió csomagot kezel a Facebook és az Instagram forgalmában.

A dinamikus szűréshez az eBPF-térképek, mint például BPF_MAP_TYPE_LPM_TRIE lehetővé teszik az egyes IP-címeket és CIDR alhálózatokat lefedő IP-blokkolási listák kezelését egyetlen lekérdezéssel. A frissítések valós időben történnek a felhasználói térből, program újraindítására nincs szükség. Aktív támadás során milliszekundumok alatt új szignatúrákat tölthet fel a bpftool:

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

A megfigyelhetőség érdekében az eBPF alkalmazásonkénti, IP-címenkénti és forgalomáramlásonkénti mutatókat gyűjt közvetlenül a rendszermag adatútvonalából. A xdp_md kontextus olyan telemetriai adatokat biztosít, mint ingress_ifindex és rx_queue_index, így azonosíthatja, melyik interfész vagy sor áll terhelés alatt. A hosszú távú felügyelethez olyan eszközök, mint a ebpf_exporter a nyers eBPF-térképadatokat Prometheus-kompatibilis mutatókká alakítják át a Grafana-ban történő megjelenítéshez.

Eszközök, telepítés és hardverkövetelmények

Az eszközlánc a Clanggal és az LLVM-mel kezdődik, amelyek a korlátozott C-t eBPF-bájtkóddá fordítják. Ehhez szükség van egy betöltő könyvtárra:

• libbpf: a termeléshez használt szabványos C-könyvtár. Támogatja a CO-RE-t (Compile Once, Run Everywhere) a kernelt átívelő hordozhatóság érdekében.
• libxdp: XDP-specifikus, támogatja több XDP-program futtatását egyetlen interfészen.
• cilium/ebpf: tiszta Go-könyvtár Go-alapú veremhez.

A kezeléshez bpftool lehetővé teszi az élő programok és a tartalomtérképek ellenőrzését. xdp-loader (a xdp-tools csomagból) kezeli a betöltést és a kiürítést. A BCC hasznos prototípusok készítéséhez Python/Lua front-endekkel, de libbpf termeléshez a CO-RE a jobb választás.

A telepítés előtt engedélyezze a BPF JIT fordítót:

sysctl -w net.core.bpf_jit_enable=1

A leállásmentes frissítésekhez használja a XDP_FLAGS_REPLACE flagot a futó program atomikus cseréjéhez. Rögzítse a térképeket a /sys/fs/bpf/ , hogy azok a betöltő kilépése után is megmaradjanak.

Hardver- és kerneltársaság

Az XDP a 4.8-as kerneltől került bevezetésre, de a teljes funkciókészlethez a 5.x vagy újabb verzió ajánlott. Ellenőrizze a kernelt a uname -r parancsot, és ellenőrizze, hogy a BPF fájlrendszer létezik-e a /sys/fs/bpf/.

A hálózati kártya illesztőprogramja határozza meg, hogy mely XDP funkciók állnak rendelkezésre:

Ellenőrizze az illesztőprogramot a ethtool -i <interface>. Ha a natív mód nem támogatott, a rendszer visszatér az általános módra, amely az sk_buff az allokációt követően fut, és nem nyújt teljesítménybeli előnyt.

Tiltsa le a GRO-t és az LRO-t, mielőtt csatlakoztatna egy XDP programot, mivel azok ütköznek egymással:

ethtool -K <iface> gro off lro off

A standard XDP megköveteli, hogy a csomagok egy 4096 bájtos memórialapra férjenek el. i40e és ice az x86 MTU-korlát 3046 bájt.

Az XDP használatának megkezdése

Kezdje a környezet felmérésével. Futtassa a uname -r parancsot a 4.8-as vagy újabb (lehetőleg 5.x) kernelt, majd a ethtool -i <interface> parancsot a natív XDP-illesztőprogram támogatásának ellenőrzéséhez.

Kezdje a megfigyelhetőséggel, ne a kényszerítéssel. Használjon eBPF-térképeket a forgalom osztályozására és számlálására, hogy legyen egy alapja a normál tevékenységnek. Miután megértette a forgalmi mintákat, térjen át a kényszerítésre: először teszteljen xdpgeneric móddal, majd váltson xdpdrv (natív) módra a termeléshez.

Ne feledje, hogy az XDP csomagszintű szűrést végez, nem pedig nyers sávszélességet. 100 Gbps-es nagyméretű támadások esetén párosítsa bare-metal infrastruktúrával és BGP FlowSpec-kel, hogy kezelje a felfelé irányuló forgalmat, mielőtt az eléri a szervert.

Ha nagy forgalmú munkaterheléseket futtat, amelyek gyors csomagszűrést igényelnek, az FDC dedikált szerverei biztosítják a bare-metal alapot az XDP maximális kihasználásához.