classic.ISPforum.cz

Vim ze uz to tu bylo asi hodnekrat ale porad to nejak nechapu, nebo mozna ano, ale nevim jestli spravne.

Co jsem se tak docetl tak packet nelze oznacit dvakrat, takze moznost priorizovat web jsem se pokusil vyresit takto. Dal jsem si v mangle jako prvni manglovani port 80 ven, port 80 dovnitr dale porty 443 110 a 25 a zaskrtl vzdy u mangle packet troughtput. Coz je 8 podminek, pod to jsem si dal zmenu TOS na max troughtput.

Pak uz mam dalsi maglovani potrebne pro deleni rychlosti pro jednotlive IP v QT. Podle toho co jsem se docetl mi pak dalsi manglovani prepise tu prvni znacku co to melo pro vyuziti u zmeny TOS na web ale to uz je jedno protoze to mam priorizovane tim TOS.

Pochopil jsem to dobre nebo jsem si jen v MIkrtoiku udelal desnej bordel ale funkcnost zadnou?

Kdyz zmenis TOS tak ti to neprepise paket mark ktery uz mel jen to nastavi paketu hodnotu TOS.Prijde mi zbytecne slozity delat pro kazdeho Qtree a efektivita QOS je stejna, ale zatez CPU rapidne vzroste

Maxik píše:Kdyz zmenis TOS tak ti to neprepise paket mark ktery uz mel jen to nastavi paketu hodnotu TOS.Prijde mi zbytecne slozity delat pro kazdeho Qtree a efektivita QOS je stejna, ale zatez CPU rapidne vzroste

bud jsi ho nepochopil ty, nebo ja

jde o to, ze si napred omangluje to, u ceho chce zmenit TOS, necha ty packety protyct dal a nasledne u takto omanglovanych to TOS zmeni a zase je necha tyct dal a pak prepisuje ty mangly tak, jak se mu to hodi pro qt (cili rusi ty stare pro zmenu TOS)...

jinak osobne bych se uchylil spise k action=jump do jineho chainu, v nem zmenil TOS u vseho, co do neho vteklo a pak dal action=return ... tak by to melo fungovat stejne (jen rychleji), nebo se mylim?

fra.iesus píše:

Maxik píše:Kdyz zmenis TOS tak ti to neprepise paket mark ktery uz mel jen to nastavi paketu hodnotu TOS.Prijde mi zbytecne slozity delat pro kazdeho Qtree a efektivita QOS je stejna, ale zatez CPU rapidne vzroste

bud jsi ho nepochopil ty, nebo ja

jde o to, ze si napred omangluje to, u ceho chce zmenit TOS, necha ty packety protyct dal a nasledne u takto omanglovanych to TOS zmeni a zase je necha tyct dal a pak prepisuje ty mangly tak, jak se mu to hodi pro qt (cili rusi ty stare pro zmenu TOS)...

jinak osobne bych se uchylil spise k action=jump do jineho chainu, v nem zmenil TOS u vseho, co do neho vteklo a pak dal action=return ... tak by to melo fungovat stejne (jen rychleji), nebo se mylim?

Pochopil si mi dobre ty

K tomu SQ a QT bylo mi doporuceno pouzivat QT ze v nem jde delat vice veci, kdyz chci treba davat uzivatele do skupin atd ted nemyslim pres userlist. Je mi jasne ze je treba vetsiho vykonu kvuli QT vzhledem k tomu ze packety musim oznackovat.

A jak si to myslel s tim jump? Mohl bys napsat priklad co kam kde? V tomhle se jeste nejak moc neorientuju.

Zatim mi RB stiha v pohode, mam 532 a mam na nem 20 lidi. Problem s vykonem nastane jen pri kopirovani v ramci lokalni site kde to nemam vubec omezene ale to neni zas tak casto. Testuju RB600 na nemz by to melo byt zas o neco lepsi.

Diky

Benny píše:A jak si to myslel s tim jump? Mohl bys napsat priklad co kam kde? V tomhle se jeste nejak moc neorientuju.

tam kde mas ty pravidla na manglovani pro jednotlive porty, tak prepis action na jump a vymysli si nejaky nazev noveho chainu (treba "tos-throughtput"). dale pod to si pridej pravidlo chain=tos-throughtput action=change-tos a dalsi chain=tos-throughtput action=return
...tim vlastne omanglujes vsechno, co ti do toho jainu vejde a nasledne to vratis do puvodniho (nevim, jestli tam mas forward, nebo prerouting). teorie by mela byt takova, ze by se tim mel zrychlit pruchod packetu, napr pokud mas na prvni pozici ve vyhodnocovani port=80, tak ten hned skoci do noveho chainu, omangluje a vrati se do puvodniho na pravidlo nasledujici po tom action=return - cili se preskoci vsechny dalsi vyhodnocovani, zase packety, ktere neobstoji ani pri jednom vyhodnoceni (a tech je hadam v siti vetsina) se vyhnou jednomu pravidlu na podminenou zmenu tos. samozrejme ty packety, ktere jsou posledni ve vyhodnocovani se o 2 pravidla zpomali (jump a return), ale celkove by se to melo vyplatit

ja teda nevim jak vy ale ja si na klientskym AP si vytvorim chainy ktere detekuji to co maji a skoci to do chainu, kde se to omarkuje. Tam se to omarkuje (conn, tos, packet), posledni ma passthrough=no , coz by melo znamenat, ze se packet dale nezpracovava a jde dale.

Trochu nevim proc po omarkovani pouzivate return.

pokud po ceste nezpracovavas omarkovane TOS pakety, tak je nema cenu ani markovat TOSem. Osobne doporucuji TOS vyuzivat, odpada tim zbytecna analyza na routrech po ceste ven i dovnitr.