Názory k článku HTB - další krůčky
-
Jerry (neregistrovaný)
K tomu proxy serveru - nešlo by to vyřešit pomocí IMQ? Nejsem si teď jist, jak se IMQ chová v případě, kdy data končí na lokálním rozhraní (a kompilovat kvůli tomu kernel a hrabat se v konfiguraci se mi nechce ;-), nicméně pokud by v něm pakety nekončily, nýbrž jen virtuálně "procházely", mohlo by to fungovat...
Zkoušel to někdo? -
Vladimir Smelhaus (neregistrovaný)
No s tim je docela legrace. Vse do vnitrni site jde sice pres proxy a HTB shaper. Pokud ale neshapujete vylozene natvrdo, jako je to zde, ale hlidate hlavne pomer pasem, dokaze i tak jeden stahovac shrabnout skoro cele pasmo. HTB sice funguje, ale kdyz ty pakety prichazeji od providera pro toho stahovace dostatecne rychle (a pro ostatni pomalu), tak mate smulu. Pak je potreba vymyslet schema, kde omezujete i na vstupu. Ja osobne pouzivam jeste na vstupu sfq.
-
MaKr (neregistrovaný)
IMQ tohle nevyresi, do IMQ muzes posilat (pres mangle) jen veci z PREROUTINGU...
Kdyz jsem zkousel do toho pridat jeste transparentni proxynu (z POSTROUTINGU nebo OUTPUTu do IMQ tak nastala krasna hlaska: KERNEL PANIC (ale byla videz az po pripojeni monitoru k serveru )
Jinak pokud shapujete provoz nezapomente shapovat i to co od vas odchazi (imq je dobra vec) ale neshapne jeste to co odchozi ze serveru, takze tam je jeste dobre oshapovat primo rozhrani. (Poskytovatel nas take pocita pomoci imq) a to byste se divili co takova kazza ci jine SHAREprogramy dokazi s linkou, kdyz od vas nekdo sosa......
Jinak velmi dobra stranka jak rozhodit IMQ je
http://alfa.tailor.com.pl/imqhtb/imq_htb.html
a te trosce polstiny se da porozumet :)
-
Jerry (neregistrovaný)
Mě taky nepanikařil. Ale je fakt, že co si tak vzpomínám, HTB se mi nad pakety posílanými na IMQ přes prerouting opravdu rozběhat nepodařilo, prostě je ignoroval. Když jsem potřeboval přidat pro HTB nějaké pravidlo, které šlo ošetřit jen v preroutingu (typicky kontrola vstupního rozhraní), musel jsem si paket označkovat a hodit ho na IMQ až v postroutingu...
-
Vladimir Smelhaus (neregistrovaný)
Nevím, jestli jsem to pochopil. Ale já například posílám všechno co se octne na vstupním rozhraní v PREroutingu na virtuální rozhraní IMQ. Na imq sedí HTB a shapuje tak, jak mu zadám.
Jen mě napadá, že já ty pakety vůbec neznačkuji a místo toho je rozlišuji pomocí tc a jeho u32 filtrů. -
Jerry (neregistrovaný)
Mně se to nějak nechytalo, nevylučuju, že byl problém mezi klávesnicí a židlí. Takže to řeším tak, že si na preroutingu přes "iptables <filtr> -j MARK --set mark <cislo>" příslušně označím to, co chci posílat na IMQ (jak jsem psal, potřeboval jsem to třídit podle vstupní síťové karty, tu v postroutingu nezjistím) a v postroutingu si takto označkované pakety ochytávám a házím na IMQ, na kterém mám pověšený shaper (přes zmíněné tc a u32 filtry ;-).
Jak říkám, možná jsem něco dělal blbě. Nicméně teď to funguje, takže nevidím důvod, proč se v tom znovu šťourat ;-) -
Lišák (neregistrovaný)
Ha, to mi neco pripomina... nevim jestli tohle je ten samy pripad, ale invalid argument mi hlasily iptables pote, co jsem opatchoval jadro novym patchomaticem verze xy. Reseni bylo stahnout a skompilovat nove iptables, kdesi uvnitr se pri prechodu mezi verzi xx a xy menila jakasi struktura, a to se starym iptablesum nelibi...
-
Michal Kara (neregistrovaný)
Jo, tohle je taky mozne. Jestli jsem to dobre pochpil, umoznuje to rozlisit packety, ktere sly z cache a ty, ktere se stahovaly.
My pouzivame zase jiny patch, ktery umoznuje v squidovych acl definovat odchozi IP adresu pozadavku. Na desitky trid nic moc (aby mel kazdy uzivatel garantovane pasmo), ale par (rychli/pomali uzivatele) se s tim udelat da pomerne transparentne. -
Vaclav Dvorak (Brno) (neregistrovaný)
Zdravim, pouzivam HTB pres 1/2 roku a mam par postrehu z delsiho provozu :
oklnosti : UPC 128/96
0) "KDO TO TED BLOKUJE"
-prvotni otazka na pocatku kazdeho shapingu... u jednodussich pripadu vystacime s tcpdumpem, ale jak bezi vic doloadu na vic IP uz je potreba sahnout jinam :
1) IPtraf . Je vyborna vec, ktera ma ovsem jednu zasadni chybu - neda se jim zjistit, kolik jaka IP adresa prave taha.
Na co je iptraf dobry : ukazuje Total upload/download traffic(detailed interface statistics, na rozhrani do inetu)...hodi se na zjisteni, jestli je upload/download pretizeny.
Jak pouzivat : nechat 5 sekund bezet, potom setridit spojeni podle velikosti("s"-"b") -na vrch vyplavou akutni dowloady. Problem IPtrafu je, ze zobrazuje i spojeni co uz nic netahaji
2) Trafshow : je zhruba to nejlepsi co jsem nasel.
a) je potreba si davat pozor na to ze existuji nejmene 2 projekty se stejnym nazvem..ten ktery pouzivam je standartni distribuci Debianu v balicku "netdiag"
b) zasadne volam skriptem, ve kterem je : "trafshow -nS -i eth0 -s 1 -u 1 ", coz setridi traffic podle rychlosti, prumeruje po 5sekundach a obnovuje obrazovku po 1 sec. Nastavenim trafshow je treba hybat opatrne, protoze to pak dela dalsi neznamou v procesu :)
Pouzivani : -poustime na vnitrni rozhrani. za 5 sekund ustaleni uz vidime nejak rozumny cisla, jediny co je potreba vedet( sloupcne nejsou popsane): predposledni sloupec je tok zleva doprava, a posledni sloupec tok zprava doleva, pro ty dve IPadresy na prislusnem radku.
Obvykle byvaji lokalni adresy v pravem sloupci, ale obcas se to pomicha, nevim proc. Je si na to potreba davat pozor. Ve slozitejsich pripadech pauzuju obrazovku ctrl+s a vklidu si ji prohlidnu.
*MACHROVINA* - udelat na routeru uzivatele 'pozorovatel', ssh na nej udelat na klice, jako login shell mu dat skript ktery pres 'sudo' vola trafshow, na svym desktopu si dat ikonku ktera vola "ssh pozorovatel@router" a VOILA - staci jednou kliknout, a je videt co tece pres router ! [- tisice dekovnych dopisu - -spokojenost zarucena - ]
Poznamka : obecne nedoporucuju mit zaply DNS resolv, protoze to zpomaluje, dela dalsi traffic, a ukazuje na spusetny sniffer.
1) metody mereni a testovani
Pri slozitejsich pripadech ladeni shapingu jsem najednou zjistil, ze vubec nevim jak "kvalitni" je moje linka do internetu - respektive jestli problemy zpusobuje shaping, nebo provider. Porad nad tim jeste badam, nicmene zatim jsem v tomto stadiu : a) merit ping co 5 minut b) merit upload/download co 5 minut, vynaset do grafu.
Pouziti a interpretace : -zobrazuje co se deje v noci,
- da se zjistit kdy maji uzivatele biorytmus tahani dat
- pokud je velky ping a maly traffic => problem u providera
- velky ping a velky traffic => shaping nezabira jak by mel
Zdroje : google smokeping, rrdtool
Vytizeni procesoru : nekdo tu posledne machroval, ze ma 70 classu a jak mu to bezva jede. Akorat zapomel napsat, jak vykonny HW ma na routeru. Ja osobne mam Pentiu 133MHz a z toho strach - dejmetomu, ze shaping bude vyrazne zatizi procesor, k tomu pobezi nejaky ten Squid a sejde se to vsechno dohromady - no tak to mam zadelano na dlouhou noc, protoze jsem si pridal dalsi slaby clanek do retezce,ktery se navic bude projevovat velmi nahodne...a to se pak bezvadne hleda :-\
Nebylo by od veci zobrazovat do grafu i zatizeni CPU (treba ze 'sar'-u) ..nemate to nekdo ?
Packetloss : v ted v zari 2003 UPC zrychlilo na dvojnasobek, bohuzel soudruzi nekde udelali chybu a o te doby je packetloss bezne 0-10%. Drive byval 0%. Nejsem si jisty jaky to ma vliv na funknoct sluzeb, ale pozitivni to urcite nebude :-\
Squid - kapitola sama pro sebe.
Ve zkratce : rozhodl jsem se ho zrusit.
Okolnosti - UPC 128/96, 3 furt aktivni uzivatele, obcas i vic.
Duvody :
- je to dalsi velmi slozity prvek, ktery se dlouho a blbe konfiguruje, tezko pozna ze je zkonfigurovany spravne, zatezuje pocitac a hlavne - NEUVERITELNE zesloziti shaping
- vyteznost squidu mou merena (cca 1-2 mesice) byla tak maximalne 10-15%. Pravda, nijak jsem to netunil.
Zaver : to mi za to nestoji
Obecna zasada : co nejmin a co nejjednodussi pravidla, co nejmene SW - jinak se z tech kombinaci a moznosti zblaznim. Presneji : zabiju veskery volny cas sedenim za pocitacem a pozorovanim trafficu...nechci takhle stravit mladi.
Cizi skripty jsou pekny, ale preferuju si postavit vlastni radek po radku, kdy po kazdym vyzkousim funkcnost. Protoze kdyz to chodit nebude, tak se nedohledam...
HINT : zasadni a zcela trivialni : obcas shaping kompletne vypnout, odstrihnout vsechny ostatni od linky a vyzkouset si, jestli se to zlepsi nebo ne. Jestli ano - v shapingu jeste neco hnije.
(Na jednoho uzivatele staci i tohle :
iptables -I FORWARD -s <jeho ip> -j DROP
iptables -I FORWARD -d <jeho ip> -j DROP )
Varovani ! : pred tim nez si zacneme hrat s DROP, ujistime se ze se k routeru muze nekdo dostat aby ho restartnul :)) [krajni varianta je restartovat router v cizim byte jisticem na chodbe....ale je to ponekud..netaktni :) ] Plati to i pro shaping obecne...a vubec nejlepsi je zaridit roter tak,aby po restartu nabihala ta konfigurace co urcite spolehlive fungovala.
Podpora a diskuzni fora :
je pekny si na to prijit sam, ale nekdy se fakt neda - moznosti vidim 3 :
overclocking.cz, czfree.cz, linux.cz. Na OC tomu rozumi akorat Jezevec, na linux.cz je zase moc
lidi, tudiz za optimalni povazuji diskuzni board czfree, sekci Unixove systemy
Dale doporucuji k precteni - HTB : Optimizing Game performance
http://mailman.ds9a.nl/pipermail/lartc/2002q3/004827.html -
si (neregistrovaný)
na kreslenie grafov zataze mozes pouzit mrtg alebo cricket (ja pouzivam to prve, mam na tom riesene aj monitorovanie zataze linky od jednotlivych uzivatelov (je to zviazane s iptables), v principe sa s tym da kreslit cokolvek z coho vies citat neake cislo, teda hoci aj ten load average na CPU)
pokial budes potrebovat, tak mailni a neake scriptiky ti na to mozem spachat... -
Vaclav Dvorak (Brno) (neregistrovaný)
Par prikladu, jak sejmout sam sebe :
1) v jiste verzi shapingu jsem orezaval veskery provoz do vnitrni site
V te dobe se projevil tento ukaz - doba spousteni gnome terminalu byla znacne
nahodna, a dosahovala az 10sec !
Po pul dni hloubani jsem prisel na tohle : na desktopu jsem mel blbe nastaveny
/etc/hosts - chybelo tam jmeno stroje na radku 127.0.0.1
Diky tomu se pri kazdem spusteni GnomeTerminalu jmeno resolvovalo po siti(!),
a protoze dns byla tez shapovana, obcas se na ni nedostalo...
2)S tim souvisi druhy efekt - pri plnem zatizeni linky zacal podezrele "umirat" internet - nic nejelo.
Pricinou byly ztracejici se DNS resolvy, kterymi zacina kazde nacitani stranky...
Od te doby mam DNS zasadne v nejrychlejsim pasmu, aby se nacitani stranek(vlastne vseho) maximaln urychlilo.
3) osementne take je, ze v momente kdy fyzicka propustnost linky se snizi, cele shapovani jde do pryc, protoze rychlostni stropy jsou samozrejme nastaveny ve skriptech natvrdo
4) Dalsi neprijemny efekt : zalozky v broswserech. Je to sice bezva vec, ale pokud si zvyknete otvirat 10zalozek ze zive.cz / mobilmanie.cz zaroven, kazda stranka ma tak 100kB, a je znacna pravdepodobnost ze do toho, ze nekdo dalsi zacne natahovat dalsi stranku. Shaping to sice vychyta, ale vsichni se pak divime proc to jede 1/2 rychlosti, kdyz jenom brouzdame, ze...
Reseni : pokud je "spicka", neklikat na tolik zalozek soucasne.
Moje otazky :
1)Co je pravdy na tom, ze priority u HTB by mohly byt funkcnejsi ?
Je mozne mit soucet CEIL-u u childu vetsi nez CEIL parent-a ? Kdyz zacnou tahat vsichni childi, nepujde shaping do pryc ?
2)Jaky presne efekt ma burst, cburst ?
3)** A hlavne, co dela perturb ? **
4)Mate nekdo zkusenosti s timto ?
http://www.ab66-70.dk/trafficshaping.php#shaping
Jsou tam velice pekne obrazky (http://www.ab66-70.dk/stats/shape/) jak rrdtolem zobrazovat kolik jakou tridou proteklo..nanestesti ten skript je dost zbastleny...
5)Odhlasovani GnomeICU - je orisek na kterem jsem si vylamal zuby. Pripada mi, ze GnomeICU je ALERGICKE na shaping, ale nevim proc. Spatne se to ladi - na lince bez shaping(lhostejno jak zatizene) me gnomeicu odhlasi tak maximane 1 tydne, staci zapnout shaping, ani se nemusi moc tahat a uz je to 3-10x za den...a to uz je opruz..Stravil jsem nad tim spoustu casu, mam ho v prioritni fronte, ale furt nic :-\
(sousedi pouzivaji jine klienty(SIM,GAIM) zcela bez problemu, protoze u nich reconnect funguje spravne..me jde ale o to, co tomu gnomeicu vadi...)
6) Jake byly cile vaseho shapingu, a jak moc se je podarilo naplnit ? -
Vaclav Dvorak (Brno) (neregistrovaný)
And now, something completely different : Jak neshapovat
Osobne doporucuji se shapingu vyhnout, pokud to jde - par duvodu : Spravcovat provoz je nevdecna prace, vsichni si stezuji a nikdo tomu nerozumi. Prinasi to neprijemnou povinnost kecat lidem do toho, jak a co maji kdy tahat, vytvaret pravidla ktera nikdo nema rad a kafrat pri jejich nedodrzovani. Proto doporucuji si hned od zacatku ujasnit, kdo kolik bude paltit a kolik bandwithu za to bude dostavat.
Ne ze by shapovat neslo...ale neni to prochazka ruzovou zahradou...
HINT : zvlast v pocatecnich fazich, mit na kazdem pocitaci icq aby se bylo mozno zeptat kdo tam co dela...
Jak se obejit bez shapingu :
-dohodnout se a netahat velky veci - pri brouzdani se pozadavky krasne casove rozlozi, lidi tahaji plnou rychlosti v kratkych narazech - bezva. [Vsechno jde do pryc v momente, kdy jeden pusti konstantni download ]
-dohodnout se na spickach/mimospickach a tahat v noci, nebo kdyz jsou vsichni ve skole.
Poznamka : zari 2003 / UPC shapuje...zda se.
Protoze kdyz vypnu shaping, firewall a downloaduju, tak ping je jako na prazdno. Kdyz pustim dva downloady soucasne, nejedeou sice fifty-fifty, ale kolisaji mezi 1/3 a 2/3, coz take neni nejhorsi. Kdyz se v prubehu downladu browsuje, v pohode to jede. Kdyz jsem pred rokem zacinal s shapingem, myslim ze vsechno chovalo daleko, daleko hur.
Motorola(kabelovy modem) umi docela dost(DHCP,NAT), zere jen 5W a nehuci. Co se tyce korun ceskych za elektriku, nevim kolik to dela mesicne ale neni to zanedbatelne. Prosim dobrovolnika o vypocet, kolik takovy router mesicne 'sezere' :) -
Jezevec (neregistrovaný)
Mam na svem routriku HTB. Protoze mam (zatim, da-li nevyssi bude vic) linku 64k a na tom jsou 3 PC ma kazdy 1/3 + moznost vyuzit pasmo do (temer, viz nize) maxima kdyz je volno.
Pro data z routeru na lokal mam tridu o rychlosti 10Mb (je tam 10kova karta). HTB sice pri startu krici (do logu) ze nesedi nastaveni, ale protoze si kreslim grafiky pomoci rrdtool tak vim ze se to chova spravne, takze popisovany problem nemam. Ovsem tech dat nebude zase tolik, obcasna synchronizace zalohy + ssh, mozna by problemy nastaly pri vetsi zatezi z LAN.
K tomu maximu. Doporucuju nechat cast pasma jako rezervu, protoze shaping ma urcitou setrvacnost. Pri umozneni vyuziti volneho pasma je pak delsi odezva treba na HTTP pozadavek i pres to, ze ja nic nestahuju a mam tedy k dispozici sve zarucene minimum, ktere ale aktualne nekdo pouziva. Toto se neprojevuje pri omezeni "natvrdo".
Pouzivam HTB cca 1/2 roku, predtim jsem mel CBQ, ktere se chovalo ponekud hure (pri takto malych rychlostech dost nepresne)
2Vaclav Dvorak: Diky za pochvalu ;-) -
xChaos (neregistrovaný)
Moje open source aplikace Prometheus postavena nad HTB, iptables a tc, ktera resi dynamicke vytvareni trid, denni limity pro uzivatele, generovani statistik, apod. (a jeste nebyla releasnuta ;-) to samozrejme resi presne takhle, nic lepsiho me nenapadlo (a tohle jsem opsal od kolegu z CZFree)
S tou proxy jsem si taky pekne lamal hlavu ;-) Jedno reseni je mit proxy na extra stroji, a vyhradit pro ni nejakou uchazejici zarucenou rychlost s pujcovanim do cele sirky pasma (kdyz je volne). To by urcite chodilo, ale zatim to tak udelane nemame. Jednim z duvodu jsou denni datove limity, ktere by se na proxy a na ne-proxy pak musely generovat zvlast (sosalum snizujeme "ceil" az na uroven "rate").
Mozna by se ale ten port 80 mohl nejak tunelovat (spis nez presmerovat) na port 3120, a ten port 80 by mohl byt markovany pro kazde uzivatele extra, a ten port 3128 by mel celou vlastni tridu na outputu ? Hmm, ja tedy nechci lidem vnucovat transparentni proxy - oni z verejne pristupnych statistik stejne vsichni vidi, ze se jim vyplati ji pouzivat. Mozna bych tedy mohl mit skutecnou proxy treba na portu 8080, a port 3128 shapovat na vystupu per-IP, zatimco portu 8080 nastavit plosne nejakych treba 25% rate (zaruceno pro web) 100% linky ceil ? Mohlo by to chodit ? -
Uzi (neregistrovaný)
Ma niekto skusenosti s $SUBJ? Mame 802.11b siet, kde sa shaping sprava dost nedeterministicky by som to nazval. Mozno je to konfiguraciou zatial, lebo je to trosku komplexnejsie, ale chcel by som pocut nejake skusenosti s tym, ako sa WLAN AP spravaju k trafficu a ci to moze nejako rusit shaping. Podotykam, ze vzdialenosti su velke a signal velmi slaby ("metropolitna siet" :)
-
z0x (neregistrovaný)
Nazdar, ja som to robil povodne cez 2 WLANovske interfejsy, na WLANoch je dost slusna stratovost a errorovost, takze sa pekety opetovne preposielaju, co podla mojho nazoru dost vadi sejpingu, laboroval som s tym jak xora vrana, nakoniec som tam smahol 2x AP a medzi to som dal linuxa so sejpingom cez 2 3com 10/100 sitovice, odvtedy to ide celkom dobre
celkovo, WLAN ci uz PCI alebo PCMCIA na Linuxe a slusnom trafficu sa mne ukazalo ako dost nespolahnive riesenie, este k tomu, ak z toho spravis router, a nie len bridge, tak pri velkom traffiku ma mashinka dost roboty. Sem tam sa mu strati link, a to je sejpinfg z toho uplne v kybli
Zdar a hura hura,
z0x -
Mik (neregistrovaný)
Super clanek.
Chtel bych se zeptat, neni mi jasna jedna vec. Jak bude fungovat kdyz si vytvorim classu treba
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 32kbit ceil 256kbit
a pres filter do teto classy poslu treba tri pocitace. Jak to bude fungovat? Poperou se uplne chaoticky tyto pocitace o konektivitu 32-256, anebo kazdy pocitac dostane prideleno 32-256?
Diky za odpoved.
ČLÁNKY DO MAILU