MK verze 5.X pocet simple q. ??

[Kaja]

To HAPI

muzes napsat neco konkretniho k optimalizaci manglu. Nebo poslat nejaky relevantni link.
Pripadne poslat demo ucet na stroj kde je optimalizace pouzita?

K.

[hapi]

nasazený to nikde nemám protože nám to generuje script ale snad brzo se zákazníci systems4isp dočkají optimalizace včetně mě takže pak to mohu předvést.

O co jde? jde o to správně použít jumpy v mangle. Vem si, že máš třeba 1000 uživatelů. Což dává 2000 pravidel. Nevim jestli se bere v úvahu in/out iface a rozděluje se to pak do dvou stromů samo ale kdyby ne, tak je to průměrně kontrola paketu v 1000 pravidlech. Každá síť má ale nějaký bloky IP adres. Většina sítí jede na neveřejkách a pokud aspoň trochu dává smysl tak je rozdělená do určitných subnetů a nejčastěji na /24.

My třeba máme co bod to jeden neveřejnej /24. Takže jednoduchý počty. Máš 50 bodů po 20 lidech (jeden /24 subnet na bod). (20x50=1000 userů). Takže to nám dává šupu 2000 (1000down/1000up) pravidel. No jo ale co kdybych udělal na začátku mangle 50 pravidel s jumpama do nových chainů kam budu směrovat /24 subnety? a do těch nových chainů bych zařazoval jednotlivý usery pověšených v tom subnetu. Ano, defakto přibude nějakých 100 pravidel s jumpy k těm 2000 pravidle ale jakej to má výsledek? Bez jumpů máš jeden velkej seznam s obsahem 2000 řádků. Ovšem s jumpy procházím max 50 prvních jumpů, jump mě pošle do jinýho seznamu kde je podle příkladu max 20 userů tedy jump mě hodi do jinýho seznamu s 20 řádky. Kratší seznamy se prohledávaji rychleji a hlavně když pravidlo nevyhovuje, projde mas 70 řádků a ne 2000 řádků. Takže průměr nebude 1000 ale nějakých 35.

Jistě se sluší říct, že je vhodný aby síť byla nějak logicky číslovaná nebo se dala nějak rozdělit subnety na větší bloky. Není nutné mít /24 ale klidně menší, větší je to fuk. Samozřejmě, že pokud máš v jednotlivých subnetech málo klientů tak to zase tolik nepřinese ale u zákazníků v řádech stovek a víc to přinese hodně moc úspor na CPU.

Příklad kterej jsem testoval. Měly jsme na pár hodin místo našeho xeonu na bráně RB1100AHx2. Nahodit tam 1300 QTček, 1300 mangle a 700 natů trvalo snad 2 minuty (pomalost nandů v RBčku). Hrůza. No ale větší hrůza přišla potom. Při cca 25-30Mbit šlo cpu do kolen. Tak sem začal zkoušet nějaký věci. QT nejsou zátěž, nat neni zátěž, filtr neni zátěž, mangle to položilo. Pokud se vypnuly mangle, RBčko běhalo na 1-2 procenta vytížení. Takže jsem začal ručně přepisovat mangle do jumpů a už po chvíly se objevily úspěchy. Neříkám že jsem to udělal kompletně ale jisté snížení CPU a ne zrovna malí tam bylo. Troufám si říct že takovej duální atom při důsledném optimalizování by snesl i 75-100Mbit konektivity rozshapovat.

[hocimin1]

ja tedy nevim, ale zkousel jsem v Mangle udelat jump a sviti me radek cervene.

/ip firewall mangle add action=jump chain=forward disabled=no jump-target=SC104 src-address=192.168.104.0/24

[net.work]

az pridas nejake pravidlo, ktere bude zachytavat packety z toho noveho chainu, co jump vytvari, tak uz invalid nebude, neboj

[Tomáš Nesrsta]

To co tu pise Hapi zni celkem logicky a opravdu by melo shapingu celkem pomoct. Neodpustim si recnickou otazku jak dlouho bude trvat ISPadminu nez by tohle implementoval.

[Viktor Novotný]

zni to logicky, dokonce si vzpominam na stare doby kdy jsem tohle delal ve forwardu a take to cosi pomohlo, ne moc ale nejake procento jo. V podstate to bylo na stejne brdo, proste system nemusi prolezt vse ale na zacatku si vybere dle subnetu s jakym packetem jde ..

[net.work]

no ja sem si tu praci dal, a cele mangle prehazel do jumpu a je to dost znat... Mam docela stare supermicro PDSMA+ s C2D na 2Ghz, SG-I2 sitovku, pres spicky pres to tece ke 100Mbitum, 900manglu, cca. 400queues a pres ty spicky nejde cpu pres 16% a to ne ze by to jelo treba souvisle 14-16 - tech 16 tam skoci fakt spickove, jednou za minutu.. jinak si to chrochta kolem 8-10% cca...

[hapi]

true... true

[Tomáš Nesrsta]

to network:
tak zkus ty jumpy na chvilku vypnout at mame srovnani kolik to tomu pomuze...

[net.work]

ty ses dobry, no.. to bych musel u vsech manglu menit chainy, a to se mi faaaaakt nechce

[hapi]

Kód: Vybrat vše

/ip firewall mangle set chain=forward [find]

předtim export mangle samozřejmě.

Jestli to zkusíš tak si tipnu. Vytížení při klasickym mangle bude cca 2-3x větší.

[net.work]

uprime rad bych to vyzkousel, ale fakt se mi do toho nechce vrtat

[hapi]

ok, technicky vzato můžu upravit script pro systems4isp a nechat ho vygenerovat novou sadu mangle ale to bude na několik hodin práce a testování na který aktuálně neni čas takže si budeme muset počkat.

[pepulis]

To co napsal hapi pouzivam cca 2 roky, mozna i vice. Jiz drive se to tady zminovalo a musim souhlasit, ze uspora u CPU je znat. Co se tyka predelani i 100 vek uzivatelu do jumpu. Jde to a neni to zadny problem. Postupne pri chvilce casu, predelat denne jeden subnet a za tyden dva je to hotove, takze nevymlouvat se .

[net.work]

a nebo treba taky za jednu bezesnou noc i tak se da