classic.ISPforum.cz

Máme hlavní bránu na linuxu a pro počítání přesených dat z IP adres jednotlivých zákazníků jsem používal mnoho let nějaký jednoduchý skript. Ten pro každou zákaznickou IP adresu udělal v iptables samostatné pravidlo na počítání dat, každých 5 minut vyčetl hodnotu a uložil do RRD. Při nárustu zákazníků a trafficu už ale velké množství pravidel v iptables začalo dělat problém. Chci se proto zeptat, co efektivního použít na linuxu, abych mohl grafovat přenosy zákazníků?

DD,

pouzivame vlastni modul do jadra integrovany s iptables. Mereni je pak rychle a nezatezuje CPU. Mam pocit, ze ted jiz existuje nejaky podobny verejne dostupny accounting modul (ipt_account ? ale ten nevypada na prvni pohled jako udrzovany)

Stačí si pohrát s těmi pravidly a optimalizovat je - místo 1000 pravidel pod sebou (každý paket se musí matchnout průměrně 500x) je rozdělit do více chainů, např. po celých /24 na síti nebo tak něco.
Pokud mám např. na síti 1000 lidí na 15ti sitech a na kařdém site mám jednu /24 (a něco mezi 30 a 100 uživateli), udělám 15 JUMP pravidel na jednotlivé /24 a v každém tom chainui pak bude cca 70 záznamů. Potom se každý paket v prvním kole matchne průměrně 8x a v druhém 35x=celkem 43x. To je oproti původním 500 matchům zásadní zrychlení!

Se stejnými pravidly by se pak dal dělat nějaký shaper (pokud již se nedělá někde jinde).

Počítat také umí ipset. Pak je to jedno pravidlo.

Po dostupnych modulech do iptables kouknu.

O optimalizaci rozdelenim na mensi bloky vim, ale prijde mi to jen jako oddaleni problemu. Navic ten skript, o kterem jsem psal, si ty pravidla tvori sam a zasahnout do neho nelze (je zkompilovany a nemam zdrojaky).

Pouzit na to ipset me nenapadlo, zkusim se mrknout, jak by se to dalo provest.

Idealne jsem si predstavoval nejakeho demona na styl softflowd (sbirani dat pro Netflow), ktery by podle zachyceneho provozu pocital prenesena data. Ono by to teda slo dostat i z tech dat, co posbira softflowd, ale asi by dalo dost prace napsat si neco, co by z toho dostavalo mnou potrebne statistiky pro IP.

To co psal rsaf je opravdu rozumná cesta, pokud vyrobíš skritp, který řeší i víc jak dvě úrovně, tak opravdu není problém s výkonem, je to hodně dobrý hlavně s ohledem na shaping.
Další možnost je ipt_NETFLOW a následně analyzovat na jiném kompu (a hlavně také uchovávat netflow data pro policii).

M.

moc sem nepochopil jestli máš problém s výkonem kvůli pravidlům pro počítání přenesených dat a nebo problém s výkonem při sběru dat. Každopádně nechápu na co se chceš dívat když do toho nemůžeš zasahovat takže jak chceš jednu nebo druhou věc vůbec řešit když nemáš zdrojáky?

jo a optimalizaci mangle přesně jak popisuje "rsaf" máme a přesně podle /24 subnetů a kdo to neviděl předtim a potom tak prostě neuvěří. Řekněme že zátěž lezla večer přes 50-60% a po optimalizaci je to na cca 20%. Totální flákárna.

A teď si vezmi, že existuje i target CLASIFY, který rovnou určí paketu QOS třídu ... Případně hash tabulky.

a mangle neurčuje rovnou název queue tree? sorry, sem mikrotikář, v linuxu jako router se hrabat nechci.

mangle je tabulka. Sama o sobě nedělá nic

Mikrotik způsob je markovat pakety a ty pak zpracovávat v QOS.
Linux způsoby jsou ještě dva: v mangle místo MARK použít CLASIFY. Pak tím se určí class toho paketu, přímo koncová větev HTB stromu. Případně se QOS staví na hash tabulkách, kdy si třídy paketů přímo vytahuje HTB (tedy ... nikdy jsem to nepoužil, snad se vyjadřuji správně) - náročnost QOS klesá snad exponenciálně.
První způsob jsem použil, už je to fakt spousta let (a je to součásti scriptu prometheus) - vytížení routeru kleslo tak, že jsem si myslel, že se htop seknul. Předtím tam bylo klasicky markování (a dost optimalizované do stromu).

hapi píše:moc sem nepochopil jestli máš problém s výkonem kvůli pravidlům pro počítání přenesených dat a nebo problém s výkonem při sběru dat. Každopádně nechápu na co se chceš dívat když do toho nemůžeš zasahovat takže jak chceš jednu nebo druhou věc vůbec řešit když nemáš zdrojáky?

jo a optimalizaci mangle přesně jak popisuje "rsaf" máme a přesně podle /24 subnetů a kdo to neviděl předtim a potom tak prostě neuvěří. Řekněme že zátěž lezla večer přes 50-60% a po optimalizaci je to na cca 20%. Totální flákárna.

Problém mám s množstvím pravidel v iptables, které každý paket musel projít. Skript, který mi to do teď řešil, si zapisoval pravidla pro počítání dat do iptables sám. Cílem je tedy najít jiné (optimalizovanější) řešení, které nebude potřebovat tolik pravidel v iptables, resp. konkrétní paket jich nebude tolik procházet.
Navrhovaná optimalizace do stromu je samozřejmě taky řešením. Ostatně takovou optimalizaci už mám udělanou v pravidlech na markování paketů, takže vím, jak pomáhá.
Zajímalo mě, jaké jsou ještě jiné způsoby, jak data počítat.

o kolika pravidlech se bavíme?

DarkLogic píše:Problém mám s množstvím pravidel v iptables, které každý paket musel projít. Skript, který mi to do teď řešil, si zapisoval pravidla pro počítání dat do iptables sám. Cílem je tedy najít jiné (optimalizovanější) řešení, které nebude potřebovat tolik pravidel v iptables, resp. konkrétní paket jich nebude tolik procházet.
Navrhovaná optimalizace do stromu je samozřejmě taky řešením. Ostatně takovou optimalizaci už mám udělanou v pravidlech na markování paketů, takže vím, jak pomáhá.
Zajímalo mě, jaké jsou ještě jiné způsoby, jak data počítat.

Když už máš pravidla na markování packetů tak čti počítadla z nich.
Za mnoho let jsem si prošel celým tím vývojem od markování "na hromadě" + stejně blbě "tc filter" až po ten stromový systém s classify v iptables a vždy to byl obrovský výkonový skok
Ještě se to dá optimalizovat setříděním pravidel tak, aby "ta, kterými teče nejvíce dat" byla nahoře (nebo třeba jen pravidla pro vyšší tarify dávat nahoru).

Použij