Jo, Slibu ze se udela PORADNY QoSko v CZF jsem slysel od zalozeni CZF hromady. Bohuzel po vic jak pulroce fungovani CZF nebyli QoSovany ani zakladni uzly site. Proto jsem s pomoci nekolika malo lidi (diky jim za to) dal dohromady vyse uvedeny script. Neni idealni, ale bez nej by nase cast site CZF byla naprosto nepruchozi, v niz vypadava i routovani, protoze si nekdo zrovna sosa filmecek. A musim rict, ze trafik ktery bezi nasi casti site je jeden z nejvetsich (Jarov, STB) a napr ping do inetu je pod 50ms i ve spicce a propustnost je vyvazena, tedy klienti se napriklad nepysni 100kb/s. Proste si tady lebedime ))
Kurva ze to ale dalo zabrat - Nemyslim jen QoS (to byla brnkacka oproti nekterym vecem)
Jo a jeste neco, samo jsem se snazil ten script prepsat do pokrocilejsi formy. Treba jednotlivym klientum priradit jednu tridu. Bohuzel jsem ale zjistil po vikendovem klepani do klavesnice, ze pokrocilejsi script vykazuje mnohem horzi vysledky nez tenhle prvni trivialni. Skratka, jestli me neco prinuti prepsat QoS na nasi vetvy CZF, HTB tam nejspis uz vubec nebude. To je muj nazor po rok a pul zkusenosti s QoS a HTB.
A jeste neco.
QoS Base a jeho tridy jsou udelany tak, aby naopak klient dbal toho, aby jeho trafik spadal do zpravnych trid. Tedy SSH do tridy s vysokou prioritou, rychlou odezvou, ftp trafic do tridy se sirokym pasmem atd.
Napisu Devikovi, xchaosi, a zkusim mu vyridit tvuj napad, bylo by to nejlepsi reseni. Kazdopadne si mylim, ze ESFQ je zatim to nejlepsi, co muzeme udelat, stale vsak prosim o nejaky tutorial, abych to mohl dat do FAQ, zatim treba bez jakehokoli shapovani, jen ciste ESFQ, ale nejak dobre udelane jak pro prijem, tak pro posilani.
No budu predpokladat, ze eth2 je linka, ktera vede do toho switche na kterem jsou ti dva pripojeni a chces shapovat download (jestli to tak neni tak ty informace upresni).
Potom u filtru musi byt "match ip dst" a ne "match ip src".
A nejak mi nedochazi proc je u root class definovany default 100, kdyz takova trida neexistuje, ale to je uz detail, ktery by snad nemel vadit.
btw. nic ve zlym, ale zda se mi to v tomhle threadu trosku OT - tranzitniho trafficu se to netyka
Ano eth2 je linka k switchi....dekuju za odpoved....a omlouvam ze za ten off topic...nicmene jsem se chtel jeste zeptat jaky ma vliv NAT na HTB. Konkretne jestli se bude muset neco zmenit v pripade ze tito dva uzivatele A,B se budou NATovat na nejajou public IP ?
Ne nemusis nic menit - natem (SNAT nebo maskarada) se modifikuji prichozi a odchozi pakety na rozhrani vedoucim do internetu. Z hlediska eth0 je to plne transparentni proces a pakety opoustejici toto rozhrani jiz budou mit destination nastaveny na adresy tvoji vnitrni site.
OK ale jak omezit tedy upload podle zdrojovych adres. Dejme tomu ze jsou dve rozhrani eth1 (vnitrni sit) a eth2 (internet). V iptablech je nastaven SNAT ze vnitrni sit (nebo jednotliva IP) se bude NATovat na virtualni IP adresu ktera bude nastavena jako sekundarni IPcko na eth2 (treba....muze to byt klidne IPcko eth2). Pro nastaveni omezeni downloudu pro jednotliva IP se to provede na eth1 pomoci filtru jak jsi spravne poznamenal kde bude dst adresa. Ale jak to bude u omezeni uploadu protoze ten se bude muset udelat na eth1 a eth1 uz bude mit public ip adresu takze se tam asi neda pouzit filtr v kterem budou nastaveny src. adresy z vnitrni site?
16.06.2003 v 21:18
))
