Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: vecino 17. 09. 2023, 15:10:17
-
Zdravím,
je tu někdo kdo úspěšně používá flowtable ? Podle níže uvedených článků a návodů se mi ho podařilo nějak rozběhnout. Bohužel nemám síťovku s HW podporou, abych rozjel [HW_OFFLOAD] - nepodařilo se mi ani dohledat nějaký seznam podporovaných NIC... pouze v posledním odkaze dole se píše o značce Mellanox.
Máte s tím někdo osobní zkušenost? Jakých s tím dosahujete výsledků? Má to nějaké "pasti"? Jednou je nemožnost použít markování nftables map pro prioritizaci provozu či shaperu.
Mikrotik má svůj Fast Path: https://wiki.mikrotik.com/wiki/Manual:Fast_Path . Dívám se na to na jakousi alternativu pro software linux router.
[UPDATE] tcp 6 86400 LAST_ACK src=10.***.***.9 dst=128.***.***.4 sport=51329 dport=443 src=128.***.***.4 dst=10.***.***.9 sport=443 dport=51329 [OFFLOAD]
[UPDATE] tcp 6 86400 SYN_RECV src=10.***.***.75 dst=8.***.***.53 sport=41430 dport=443 src=8.***.***.53 dst=10.***.***.75 sport=443 dport=41430 [OFFLOAD]
[UPDATE] tcp 6 86400 SYN_RECV src=10.***.***.9 dst=128.***.***.4 sport=51370 dport=443 src=128.***.***.4 dst=10.***.***.9 sport=443 dport=51370 [OFFLOAD]
zdroje:
Flowtables:
https://wiki.nftables.org/wiki-nftables/index.php/Flowtables
Netfilter's flowtable infrastructure:
https://www.kernel.org/doc/html/latest/networking/nf_flowtable.html
Flowtables - Part 1: A Netfilter/Nftables Fastpath:
https://thermalcircle.de/doku.php?id=blog:linux:flowtables_1_a_netfilter_nftables_fastpath
Flowtables - Part 2: IPsec gateway in tunnel-mode:
https://thermalcircle.de/doku.php?id=blog:linux:flowtables_2_ipsec_gateway_in_tunnel_mode
netfilter flowtable hardware offload:
https://lwn.net/Articles/804384/
Díky
-
Ještě doplním jeden odkaz - může se vám hodit.
Connection tracking (conntrack) - Part 3: State and Examples:
https://thermalcircle.de/doku.php?id=blog:linux:connection_tracking_3_state_and_examples
-
je tu někdo kdo úspěšně používá flowtable
Úspěšně to používá například každý, kdo má dostatečně nové OpenWrt a zaškrtne si tam takové zaškrtávátko, používat offload. Tam to funguje. Je tam kernel 5.xx.
Ale v nových kernelech to nefunguje (minimálně softwarový offload), protože je tam nějaká chyba, díky které flowtable kašle na nastavený timeout a toky z ní neustále vypadávají.
-
Díky za reakci - zajímavé. Já doma testuji na kernelu 6.5.3 (Arch Linux) a problémy nepozoruju. Na druhou stranu nejsem asi ani schopnej zjistit jestli něco vypadává nebo ne. V conntracku [OFFLOAD] vidím, ale nevím jestli něco vypadlo / nebo se tam ani nedostalo.
Myslíš tyhle timeouty?
$ sysctl -a -r nf_flowtable
net.netfilter.nf_flowtable_tcp_timeout = 30
net.netfilter.nf_flowtable_udp_timeout = 30
Nemáš k tomu nějaký info? Odkaz na nějaký bugtracker, kde by byly podrobnosti?
-
Pokud to je ono, tak je to už dávno fixnutý...
https://bugs.launchpad.net/ubuntu/+source/linux-bluefield/+bug/1975649/
https://lore.kernel.org/lkml/20220523165840.182710201@linuxfoundation.org/
-
Myslíš tyhle timeouty?
$ sysctl -a -r nf_flowtable
net.netfilter.nf_flowtable_tcp_timeout = 30
net.netfilter.nf_flowtable_udp_timeout = 30
Ano, myslím tyhle timeouty.
Pokud to je ono, tak je to už dávno fixnutý...
Vzhledem k tomu, že to pozoruji na kernelu 6.5.3, tak se mi to moc fixnutý nezdá.
Nemáš k tomu nějaký info? Odkaz na nějaký bugtracker, kde by byly podrobnosti?
Mám k tomu vlastní pozorování. Dlouhé udp spojení (wireguard) přes natující router s kernelem 6.5.3, zvenku na stroj v lokální síti. Přes wireguard tečou nějaká data, pár paketů za vteřinu, občas vteřina dvě pauza. Spojení v conntracku routeru přeskakuje z ASSURED do OFFLOAD a zase nazpátek. Je to přitom pořád jedno spojení.
Totéž přes OpenWRT s kernelem 5.xx - spojení je pořád OFFLOAD.
Ty timeouty... Nastavování nf_flowtable_udp_timeout nemá vůbec žádný vliv na stav v conntracku. Tedy do té doby, než nastavím nf_flowtable_udp_timeout na hodnotu rovnu nebo vyšší, než nf_conntrack_udp_timeout_stream. Pak to spojení úplně vytuhne.
Takže, s OpenWRT s kernelem 5.xx na nevýkonném routeru offloading pomocí flowtable zvyšuje propustnost. S kernelem 6.xx to něco dělá, pro některá spojení to skutečně offloaduje, ale nedá se na to spolehnout. Ale vzhledem k tomu, že to běží na normálním počítači, tak je to víceméně fuk, protože ten to výkonově zvládá i bez offloadingu.
-
Fajn - super postřeh. WireGuard mi tam také běží - zkusím to na něm vypozorovat. S výkonem routeru také nemám výkonnostní problém, ale když jádro / netfilter umožňuje zkrátit cestu paketů, tak proč toho nevyužít.
@rmrf: Čistě náhodou jsi neřešil kombinaci flowtable + balancování přes Cake: https://www.bufferbloat.net/projects/codel/wiki/Cake/ ?
-
Čistě náhodou jsi neřešil kombinaci flowtable + balancování přes Cake: https://www.bufferbloat.net/projects/codel/wiki/Cake/ ?
To jsem neřešil. Ale mám na tom routeru řízení rychlostí pomocí htb + tc a funguje to i s offloadingem. Tj. přes forward nebo přes flowtable, pořád to řídí správně.
-
A přes tc matchuješ takto, že?
u32 match ip src xx.xx.xx.xx
Bohužel tc match ip src/dst je dost náročný (ale na domácí krabičku oukej). Přes nftables a mapy je to výkonnostně úplně jinde - myslím pro desítky / stovky+ záznamů (LAN někde v paneláku apod).
-
A přes tc matchuješ takto, že? u32 match ip src xx.xx.xx.xx
https://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.adv-filter.hashing.html
-
Jj to je ono - používal jsem dříve.
Mrkni třeba na: https://walda.starhill.org/pocitace/nftables/ na mapy:
# mapy shaperu pro download lokalniIP:tcclass
add map MANGLE map_DOWNLOAD { type ipv4_addr: classid\; }
# mapy shaperu pro upload lokalniIP:tcclass
add map MANGLE map_UPLOAD { type ipv4_addr: classid\; }
Původní firewall s iptables měl 3600 pravidel pro DNAT, SNAT a značkování paketů pro traffic shaper. Ten pak obsahoval pravidla tc filter pro zařazování označkovaného paketu do odpovídající třídy. Po přechodu na nftables s mapami a přímým zařazováním paketů do tříd (classify) došlo se snížení zátěže CPU serveru na zhruba 30% původního stavu.
-
Jj to je ono - používal jsem dříve.
Mrkni třeba na: https://walda.starhill.org/pocitace/nftables/ na mapy:
Už jsem na tvoje stránky narazil dříve.
Nicméně, já používám hashing filtry (až dole na lartc stránce). Nic ve firewallu nemarkuji, jak ty píšeš na svém webu. A tím pádem je zátěž routeru výrazně snížena.
-
Není to můj web - poslal jsem to jen jako příklad co jsem pogooglil pro názornost. :)
ad OpenWrt) Je potřeba MediaTek MT7621A
(https://i.ibb.co/7K8VSm3/Open-Wrt-offload.png) (https://ibb.co/RcZPgwX)
MediaTek MT7621A:
https://www.mediatek.com/products/home-networking/mt7621
Ale díky za tip mám u pár známých TP-Link Archer C6 v3.2 a ten ho má. Tak jim to zkusím zapnout.
-
TP-Link Archer C6 v3.2 + OpenWrt s HW_OFFLOAD:
[UPDATE] tcp 6 120 TIME_WAIT src=10.11.12.13 dst=104.**.**.124 sport=50616 dport=443 src=104.**.**.124 dst=10.**.**.39 sport=443 dport=50616 [HW_OFFLOAD]
[UPDATE] tcp 6 120 FIN_WAIT src=10.11.12.13 dst=77.**.79.90 sport=57672 dport=110 src=77.**.79.90 dst=10.**.**.39 sport=110 dport=57672 [HW_OFFLOAD]
...
-
HW offloading flowtable umí v současnosti mlx5 a mt7621 a mt7622. Ty mediateky určitě i HW NAT pro IPv4.
-
To jsem neřešil. Ale mám na tom routeru řízení rychlostí pomocí htb + tc a funguje to i s offloadingem. Tj. přes forward nebo přes flowtable, pořád to řídí správně.
Nicméně, já používám hashing filtry.
Prosím tě @rmrf - zkouším použít tc + hashing filtry jak jsi tu psal viz. výše. Chci se tě zeptat - funguje ti to i s NATem?
Díky