Dotaz: P2P sítě a vytížení routru počtem spojení

[jirka]

zdravim, zjistil sem, že je můj routr ve večerních hodinách čím dál víc zatížený , a to až na 100% (xp2200 512ram). Kkyž sem sledoval sítovej provoz uživatelů co maj puštěný p2o programy tak sem zjistil že jejich počítač i když stahuje třeba jen rychlosti 5kb/s strasně vytěžuje sít a routr, protože doslova chrlí spoustu malej nesmyslnech paketů na spoustu ipadres. třeba až 50/s. Zkoušel sem to vyřešit přes modul connlimit, ale to je ceklem k ničemu protože počítač defakto pouze skenuje a konekce se vytvoří jen vyjímečně. da se to nějak řešit ? krom toho než to zakázat uplně (vyskoý pory)

Odpovědi

[xxl]

http://www.wallfire.org/misc/netfilter_conntrack_perf.txt

Ale nejspíš to bude něčím jiným. Neříkej mi, že jsi ISP s tak velkým provozem, aby ho zmíněné PC, použité jako router, neutáhlo.

[Heron]

Neřekl bych, že to bude vysokým počtem paketů. Můj komp sám o sobě zvládal stahovat přes více než 512 connectů v conntrack (v azureusu) a vytížení CPU bylo pod 10%. (xp2400, 1GB). Možná je to divnou síťovkou, nebo ti tam běží nějakej odchytávač a analyzátor paketů (nebo nějakej měřič traficu). 50packetů / s by nemělo představovat problém.

[jirka]

ale kdys mamtech 50 spojeni za sekundu (ne paketů), proste s pojení, vidim že za každou vteřinu vyšle ten komp minimalne na 50 pokazdech jinejch verejnejch ipcek nakej paket. to p2p us se chova jak blaster ve vnitrni siti. Ale de oto když si to pustí třeba cca 50-100 lidí tak už to bordel udělá.

[Thunder.m]

Doporučuji kernel 2.6 ideálně jeden z posledních spolu s nejnovějšími iptables, se starými verzemi jsme měli v síti podobné problémy, cca 400 aktivních počítačů v síti natovaných skrze router P3 650MHz a už to drhlo tak, že se po dobu okolo 6 - 10 večer nebyl router dostupný ani skrze ssh, po instalaci nového systému (někde jsem tu o něm psal vlastní blog, můžeš to zkusit), stoupnul počet PC asi na 600 a zátěž se drží na 5-10%, se stejnou konfigurací. Pokud tam máš blbě zkompilovaný kernel, tak to taky může dělat bordel i u 2.6, například preemptivní kernel je na takvéto místo velmi nevhodný.

[Thunder.m]

Ještě něco, zkoušel jsem na jiném routeru limitovat počet spojení na jednu adresu, ale po čase už to uplně přestal stíhat (cca 100 PC).

iptables -A FORWARD -p TCP -m connlimit --connlimit-above 300 -j REJECT --reject-with tcp-reset

to je příkaz na limitování spojení, jen by tam asi mělo být například -s 10.93.105.105 a to samé pro -d to už nevím přesně...

[jirka]

kernel 2.6 tam mam. je tam fedora 3.0 . Ted sem si hral zase s tim connlimitem, ale furt to tam v commvievu(na windows routru) strašně lítá. ty konekce se ani třeba nenavažou,(prostě ty p2p srač.. mimo to ze stahujou jeste hledaj(skenujou net) kam by se mohli pipojit na ip a porty) takže to connlimit nepohlida, potreboval bych zjisti jak se menuje modul co povoli pripojeni treba na max 10 jinejch ip za sekundu za sebou. Už jenom kuli tomu že je to všechno přes wifi,tim zytečně ty lidi zatěžujou sit.

[Jiny jirka]

Jo tohle znám, jedná se o to, že nějaký p2p klient se pokouší navazovat spoustu spojení na různých IP adresách. Tyto adresy neodpovídají a zaplňuje se tabulka neukončených spojení. Asi by to vyřešilo, pokud by se značně zkrátila životnost některých paketů a současně se zvětšila tabulka.

Změnit hodnoty pro:

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 65528>/proc/sys/net/ipv4/netfilter/ip_conntrack_max
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 1200>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

a restartovat

Případně ještě:

echo 50>/proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo 5>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 120>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 120>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait
echo 60>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 10>/proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

[jirka]

tak sem po dnešní noci zjistil že jedina cesta je přes iplimit. ale ma to haček. mam iptables v1.3.4 a kernel 2.6.12-prep. Problem je v tom ze ten iplimit byl naposled ve verzi iptables 1.2.8.(tady je pouze limit,hashlimit,connlimit atd ale iplimit ne) Verze 1.2.8 mi tam dostat nejde. A když použiju path z verze 1.2.8 na 1.2.9 a výš, tak ten iplimit po aplikovani patche zmizi. Da se to nak vyresit jinak, nes tam tam dat starej kernel s iptables ?

[xxl]

Ještě jsi nenapsal, jaký máš datový tok a kolik máš klientů.

[Thunder.m]

Co třeba toto:

$IPTABLES -I FORWARD -s 10.93.32.143 -p tcp --syn -m state --state NEW -m limit --limit 20/s --limit-burst 100 -j ACCEPT

$IPTABLES -I FORWARD 2 -s 10.93.32.143 -p tcp --syn -m state --state NEW -j DROP

[jirka]

linka do netu je zatim 4mega na cca 550 PC, do tydne bude 10M , to zlepšení asi bude, ale nejde mi o ten datovej tok těch lidí, oni stahujou ve výsledku treba kilobajt ale ten bordel udělaj tisíci maljma paketama,. Ted sem skousel to
iptables -I FORWARD -s 10.0.39.9 -p tcp --syn -m state --state NEW -m limit --limit 20/s --limit-burst 100 -j ACCEPT
iptables -I FORWARD 2 -s 10.0.39.9 -p tcp --syn -m state --state NEW -j DROP
a stejne nic, podle me je to jen filtr na počet paketů a na povolení počtu spojení najednou.
Potrebuju udelat třeba to, že když si dam limit 10/m na port 25, tak aby to nenechalo poslat víc jak 10 emailu za minutu, a tim se chranit třeba pred rozesilanim spamu.

[xxl]

Zvýšil bych limity conntracku, případně snížil timeouty. Nasadil bych htb na vstupu i na výstupu z/do vnitřní sítě. Použil bych imq. Limitoval bych to pro každé ip. Jednotlivým ip bych nedovolil použít celou šířku pásma. Iptables bych nechal dělat pouze firewall a to řízení toku bych nastavil pomocí filtrů tc. Ale pomocí hashe. Sice tisíce tříd htb, ale pouze pár skoků ve filtrech.

[Thunder.m]

No mrknu na to jeste jednou doma, kde jsi zjistil, ze ti ten limit pomuze? Neni nahodou v patch-o-matic-ng, nebo tak neco? Jinak shapovani ti moc pri takovehle prasarne nepomuze, taky to znam, jeden kokot mi takhle znicil rychly ping na wifine, nejdriv jsem to resil pres ten connlimit, ale pak to router prestal zvladat, tak jsem ho za to odpojil :) Zkousel jsem mu i nastavovat minimalni rychlost, napriklad 6KB/s, nezmenilo to vubec nic.

[xxl]

Ty jsi mu nejspíš nastavoval jenom rychlost stahování. Ale já mluvil o řízení toku ve směru dovnitř i ven.

[Thunder.m]

Samozřejmě že jsem řídil tok na obou rozhraních, jak vstupním tak výstupním :) K čemu by mi bylo řídit download na wifi kartě, která je halfduplexní.

[xxl]

To je na mě moc hluboká úvaha. Ale napadá mě, jestli v tvém případě není náhodou nejslabším článkem ta wifina.