XDP - eXpress Data Path
Sissejuhatus
Mõisted
- xdp - xpress data path
Tööpõhimõte
Väited
- xdp paketifilter on stateless (st erinevalt iptables ja nftables nö tavalisest stateful kasutuse režiimist)
- xdp kasutab üldisemat bpf lahendust (mille kohta vahel väljendatakse 'in-kernel-virtual-machine)
Rakendus - stateless paketifilter
Tööpõhimõte
TODO
server - http://10.40.135.66/ xdp rakenduskoht _______ | | | | |_______| | | enp6s18 võrguliides internet | | ___|___ ___|___ | | | | | | | | |_______| |_______| 10.40.13.246 10.40.13.242 klient-kontroll klient-generaator httping -> server hping3 -> server
kus
- klient arvutid on füüsilised
- ühendused on 25 Gbit/s
- server on füüsiliselt Proxmox PVE arvutil töötav virtuaalne KVM arvuti
- ilusti st iperf abil väikese mss väärtusega kõrvutisi 6-8 tcp ühendusi pidades saavutab 24.5 Gbit/s ja 18 mpps
- hping3 ei ole antud juhul eriti efektiivne syn flood allikas
Kasutuskoha ettevalmistamine
Nt Debian v. 12 ja Ubuntu v. 24.04 sisaldavad vajalikku kerneli poolset tuge ning user-space utiliitide komplekti, paigaldamiseks sobib öelda
server# apt-get install xdp-tools
Muu hulgas paigaldatakse failisüsteemi
- /usr/bin/xdp-filter
Kasutamine
Tuumas XDP osakonna aktiveerimiseks võrgukaardi jaoks sobib öelda
server# xdp-filter load ens6s18
Paketifiltri keelava reegli kehtestamiseks
server# xdp-filter ip 10.40.13.242 -m src
XDP paketifiltri olukorra hindamiseks sobib öelda
server# xdp-filter status ...
Reegli eemaldamiseks
server# xdp-filter ip 10.40.13.242 -m src -r
Jõudlus
Jõudlusega tegelemisel pööratakse tähelepanu sellistele asjaoludele
- top + 'klahv 1' + 'shift ja h' - näeb kõigi protsessorite ja threads vaadet - kuidas läheb cpu load'il, nt istub 'is' peal, ja aktiivselt töötavad soft-interrupt osakond
- 'tcpdump -ni enp6s18' vs 'xdpdump -i enp6s18' - kui takistada liiklust xdp kihis, siis tcpdump ei näe midagi; xdpdump näeb
- milline on arvuti koormatus kui on rakendatud tava-iptables (tegelikult ubuntu 24.04 kasutab sisemiselt nftables'it); kui on rakendatud xdp-filter; kui ei ole rakendatud midagi
- milline mõju on synflood tegemisel porti kus ei ole midagi kuulamas (ja pole rakendatud ka paketifiltrit - siis vastatakse rst paketiga); milline on mõju kuis synflood teha porti kus teenus kuulab tcp peal (ja pole rakendatud paketifiltrit - siis vastatakse syn-ack millele omakorda hping3 vastab rst paketiga; seejuures tehakse conntrack sissekanne - vt 'conntrack -L')
- milline mõju on üldisel operatsioonisüsteemi käitumisel, nt samaaegselt avatud failde arv, erinevate portide arvu piirang 64k; arvutil on ühel võrguliidesel palju ip aadresse vs üks ip aadress
Jõudlus - syn flood
syn flood koormuse tekitamiseks sobib öelda
klient-generaator# cat run-hping3-to-66.sh timeout 260 hping3 -S -c 400000000 --flood -p 80 10.40.135.66 -m 200 & timeout 260 hping3 -S -c 400000000 --flood -p 80 10.40.135.66 -m 200 & timeout 260 hping3 -S -c 400000000 --flood -p 80 10.40.135.66 -m 200 & timeout 260 hping3 -S -c 400000000 --flood -p 80 10.40.135.66 -m 200 & timeout 260 hping3 -S -c 400000000 --flood -p 80 10.40.135.66 -m 200 & timeout 260 hping3 -S -c 400000000 --flood -p 80 10.40.135.66 -m 200 & timeout 260 hping3 -S -c 400000000 --flood -p 80 10.40.135.66 -m 200 & timeout 260 hping3 -S -c 400000000 --flood -p 80 10.40.135.66 -m 200 & klient-generaator# sh run-hping3-to-66.sh
Tulemusena tekib sihtpunkti võrguliidesele mõni miljon paketti sekundis võrguliiklust (syn paketid ja syn-ack vastuspaketid)
TODO
ning operatsioonisüsteemile nö arvestatav interrupt load
TODO
Seejärel rakendatakse paketifilter server osakonnas.
Tulemusena on eraldi kontroll-klient arvutist rakendadatud http päringute teenindamise juures näha selge muudatus
klient-kontroll# httping -G http://10.40.135.66/ PING 10.40.135.66:80 (/): connected to 10.40.135.66:80 (242 bytes), seq=0 time=262.70 ms connected to 10.40.135.66:80 (242 bytes), seq=1 time=1063.66 ms connected to 10.40.135.66:80 (242 bytes), seq=2 time= 54.99 ms connected to 10.40.135.66:80 (242 bytes), seq=3 time= 53.62 ms connected to 10.40.135.66:80 (242 bytes), seq=4 time= 54.85 ms connected to 10.40.135.66:80 (242 bytes), seq=5 time=239.43 ms connected to 10.40.135.66:80 (242 bytes), seq=6 time=1005.36 ms connected to 10.40.135.66:80 (242 bytes), seq=7 time= 0.89 ms connected to 10.40.135.66:80 (242 bytes), seq=8 time= 1.00 ms connected to 10.40.135.66:80 (242 bytes), seq=9 time= 1.01 ms connected to 10.40.135.66:80 (242 bytes), seq=10 time= 0.94 ms connected to 10.40.135.66:80 (242 bytes), seq=11 time= 1.00 ms connected to 10.40.135.66:80 (242 bytes), seq=12 time= 0.97 ms connected to 10.40.135.66:80 (242 bytes), seq=13 time= 1.02 ms connected to 10.40.135.66:80 (242 bytes), seq=14 time= 0.89 ms connected to 10.40.135.66:80 (242 bytes), seq=15 time= 0.85 ms
Lisaks server arvutis kaob interrupt load. Seejuures on server arvutis näha ethtool statistikas, et xdp osakonnas nö unustatakse pakette
server# ethtool -S enp6s18 | grep xdp | grep drops rx_queue_0_xdp_drops: 82764866 rx_queue_1_xdp_drops: 83376792 rx_queue_2_xdp_drops: 85489797 rx_queue_3_xdp_drops: 83264354 rx_queue_4_xdp_drops: 82815276 rx_queue_5_xdp_drops: 84101472 rx_queue_6_xdp_drops: 82785532 rx_queue_7_xdp_drops: 84213379
Jõudlus - kokkuvõte
Väited
- ilma paketifiltrita tekib süsteemil 'si' interrupt suur koormus (kõik 100%) nii 2.8 mpps juures ja operatsioonisüsteem ei ole eriti juhitav, st käsurida reageerib vaevaliselt
- iptables/nftables paketifiltri kasutamisel tekib umbes samas 2.8 mpps syn flood juures 'si' interrupt suur koormus
- xdp-filter kasutamisel ei teki 2.8 mpps juures probleeme; peaks leidma võimaluse koormust tõsta ja vaadata millal tekivad probleemid
Debugimine
- xdpdump
Kasulikud lisamaterjalid
- https://www.iovisor.org/technology/xdp
- https://github.com/Xilinx-CNS/onload
- 'Migrating from DPDK to AF_XDP for High-Performance Networking in... - Maryam Tahhan & Dave Tucker' - https://www.youtube.com/watch?v=yGZhzXN31SA
- https://www.electronicdesign.com/markets/automation/article/21136402/xilinx-smartnic-architectures-a-shift-to-accelerators-and-why-fpgas-are-poised-to-dominate
- https://github.com/aterlo/afxdp-rs
- https://www.bizety.com/2020/06/24/open-source-load-balancers-neutrino-katran-maglev-seesaw-traefix-and-haproxy/
- https://github.com/facebookincubator/katran
- https://fedepaol.github.io/blog/2023/09/06/ebpf-journey-by-examples-l4-load-balancing-with-xdp-and-katran/
- https://blog.cloudflare.com/how-to-receive-a-million-packets/
- https://blog.cloudflare.com/l4drop-xdp-ebpf-based-ddos-mitigations/
- https://events19.linuxfoundation.cn/wp-content/uploads/2017/11/Accelerating-VM-Networking-through-XDP_Jason-Wang.pdf
- https://www.knot-dns.cz/docs/latest/html/man_kxdpgun.html
- https://github.com/yeze
- https://cilium.io/blog/2021/05/20/cilium-110/#standalonelb
- https://developer.nvidia.com/blog/accelerating-with-xdp-over-mellanox-connectx-nics/
- https://blog.path.net/application-filters/
- https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/using-xdp-filter-for-high-performance-traffic-filtering-to-prevent-ddos-attacks_configuring-and-managing-networking#dropping-network-packets-that-match-an-xdp-filter-rule_using-xdp-filter-for-high-performance-traffic-filtering-to-prevent-ddos-attacks