Názory k článku HTB - FAQ

Dobry den, nevi nekdo, ktery algoritmus pro omezeni sirky pasma je nejrychlejsi (CBQ,HTB,TBF...)? A v kombinaci s jakym oznacovanim paketu? Pouzival jsem CBQ, pak jsem presel na HTB, ale porad to neni ono. (vyzkousel jsem jak MARK tak 32ku) Mam 2GHz router, nekolik stovek uzivatelu s vetsinou 100Mbit pristupem a jde to vsechno pres jednu masinu (musi). Bohuzel, jakmile zacnu uzivatelum omezovat sirku pasma, zatez stroje vyskoci strasne nahoru (presneji softirq). Ma nekdo napad?
diky

co jsem zatim videl tak CBQ, vychazelo oproti HTB v narocich o neco lip, ale mozna se jedna o subjektivni pocit, protoze naroky na sit nejsou nikdy jednoznacne...

Ono je to presne ako s firewallovymi pravidlami, daju sa napisat efektivne a menej efektivne a potom podla toho vyzera aj zatezenie stroja.
Odporucam sa pozriet na lartc.org a hlavne prehladat prislusny mailing list lartc@. Ale na stroji s 2GHz procesorom, nieje problem shapovat niekolko stoviek zakaznikov a na dual-proc masinach az niekolko tisic, co by malo na bezne pomery byt dostacujuce...
Co sa tyka tej narocnosti CBQ a HTB, tak na strankach Devik-a (autor HTB) su grafy, kde je jasne vidiet, ako je HTB rychlejsie oproti CBQ.
Inak hit poslednych mesiacov v shapingu je hsfc, ktore dosahuje daleko lepsie vysledky pri zdielani pasma ako HTB a je aj viac presnejsie ako HTB.

Dekuji za info. Podle mych zkusenosti je opravdu HTB rychlejsi(docela vyrazne), ale i tak to nestaci (uplink ven je totiz 1GBs a uzivatelu temer tisic). Pravdou ale je, ze jsem jeste nezkousel nektere parametry z devikova manu. Za tip na hsfc diky.

S tou hardwarovou náročností bych to opravdu neviděl až tak zle. Shapujeme cca. 200 klientů, na 3 rozhraních, v obou směrech na CPU Duron 700. Bez jakýchkoliv problémů. Chybku by ale mohli dělat třebas i síťové karty, nějaký chybka v markování či něco podobného. Pokud budete potřebovat pomoc, stačí napsat...

ziju v domneni, ze vice CPU v tomhle pripade je celkem k nicemu. Pokud se hlavni rezie s frontovanim packetu deje v ramci kodu volaneho hw prerusenim pri prichodu packetu, pak vice CPU muze mit naopak negativni vliv ne? (volani multi cpu zamku atd). Preruseni od hw zpracovava stejne v jednom case jen jeden CPU.
Rad se necham vyvest z omylu...

Pokud se nepletu tak i na x86 SMP arch pod rozumnym OS lze diky APIC smerovat HW preruseni(obsluhu) na urcite CPU. x86 na to sice nebyla nikdy stavena, ale diky ruznym HW/SW berlickam ktere se casem objevily to funguje. Pro klasicke UNIXove arch (Alpha, Sparc, Power...) je to zamozrejmost.

Nejak nemuzu najit patch ana HSFC. Nemuzes dat link na patch? Nebo to je zabudovane v kernelu 2.6? Mozna neumim hledat, ale v googlu to nevidim.

HSFC je sucastou vanila kernelu a nieje treba nic patchovat. Tak isto aj iproute2 ma v sebe podporu pre HSFC - treba ale pouzit najnovsiu verziu z http://developer.osdl.org/dev/iproute2/

Priklady a dokumentaciu treba hladat v ALTQ, kedze linuxova implementacia HSFC vznikla podla implementacie v ALTQ.

Hledejte HFSC, a ne HSFC.

Ahojky vsem! Rad bych se zeptal predevsim tech, kteri maji nejake *osobni* zkusenosti s ALTQ a PF (FreeBSD/OpenBSD), zda by se nejak daly secist a podtrhnou rozdily, resp. klady a zapory reseni oproti HTB + TC.
Na internetove brane nam cca 2 roky beha RH s HTB a v zasade nemame s touto kombinaci problemy. Trochu mi vsak prekazi uroven abstrakce, konkretne nemoznost pouziti logickych jmen u trid (toto kdysi devik planoval, reps. byl o to zadan) a take nutnost vytvareni trid pro prichozi a odchozi datovy tok na ruznych rozhranich. Tusim, ze tohle bylo mozne resit pomoci IMQ, ktere je vsak jiz delsi dobu neudrzovane.

Diky vsem za informace...

Také jsem si myslel, že je neudržované, ale pak jsem narazil na tohle: http://www.linuximq.net/. Nezkoušel jsem, ale očividně v tom někdo pokračuje...

Fajn, diky moc

mate nekdo zkusenosti s ALTQ ?? (zatim pouzivam linux/HTB a chtel bych prejit na openbsd)

dik

Nu, v pripade rozsahlych firewallu je nekdy dobre vyuzit modulu time (iptables -m time --help) a znackovat pakety takto. Pak neni nutna uprava firewallu (a jeho pripadny restart) cronem.

Nicmene nekdy muze byt samozrejme vhodnejsi cron, kazdemu dle chuti.

Jak jinak nez cronem vyresis treba svatky....

Mozna jsem trochu OT, ale nemate nekdo praktickou zkusenost s HSFC a to zejmena ve srovnani s HTB?

no mne to IMQ nepripada mrtve http://www.linuximq.net/ alebo mas iny nazor? posledny patch je na 2.6.9 jadro a 2.4 myslim tiez aktualny, inak je to vyborna vec .

Mas pravdu a nikdo se ani nepre. Pokud se podivas na originalni sajt (http://trash.net/~kaber/imq/), tak tam nic tak zajimaveho neni. IMQ se nechtel delsi dobu nikdo ujmout, a tak mi nepripadalo moudre na nem neco produktivniho stavet, hlavne z duvodu drivejsiho problemu s nestabilitou.
Bla bla. No vlastne moje slova potvrzuje pred momentem nalezeny clanek - http://www.root.cz/clanek/2446

I tak Ti diky za info

No ono to s historiou IMQ je dost zaujimave. Len pre pripomenutie:
- prvotny napad a implementaciu spravil Devik (quick & dirty)
- potom sa toho ujal Patrick McHardy - Kaber, ktory to spravoval pocas doby kedy to pouzival. Pocas skoro 1 roka prispelo zopar ludi patchmi, ale aj tak sa IMQ velmi nevylepsilo (stale tam bol problem s lokalne generovanymi packetmi a ich dropovanim)
- kedze Kaber to prestal pouzivat a aj udrzovat, a vseobecne sa vedelo a designovych problemoch povodneho IMQ, tak vznikli 2 nove implementacie:
* www.linuximq.net
* pupa.da.ru/imq/
z toho www.linuximq.net sa povazuje za lepsiu a stabilnejsiu implementaciu.
- aby to nebolo este dost, nedavno vznikla dalsia nova implementacia z ceskych luhu a haju od Jiriho Fojtaseka - http://hyperfighter.jinak.cz/qos/

Cize IMQ je zive viac ako dost, ale pokial sa nezmenia urcite designove veci, tak vzdy je tu riziko, ze to moze padat v 2 konkretnych situaciach:
- dropovanie lokalne generovanych packetov (krasny vertex storm efekt - cim viac packetov sa zahodi o to viac ich kernel vygeneruje a tak sa vlastne pochova) [toto uz nejako vyriesili ludia od netfilter-u a uvazuje sa so zaclenenim do www.linuximq.net]
- ingress shaping (ono v podstate ingress shaping nieje vobec dobry napad a lepsie je pouzit namiesto toho predradeny shaping bridge i ked samozrejme, ze to vo vsetkych pripadoch nieje mozne)

Takze pokial mate router, na ktorom chcete pouzivat IMQ a nebudete sa snazit shapovat lokalne generovane packety, tak mozete s kludom nasadit www.linuximq.net a skoro pokojne spavat.

skor by som doporucil - man 5 crontab

Muzete nekdo hodit maly priklad jak to resit s NATem?
Dik Honza

pomoci tohoto to resim ja

#!/bin/sh

# **************************** Definice parametru ****************************
TC=/sbin/tc
IPTABLES=/usr/sbin/iptables

INET_IFACE=eth0
LAN_IFACE=eth1

INET_SPEED_UPLOAD=256Kbit
INET_SPEED_DOWNLOAD=256Kbit

GARANCE1=32Kbit
GARANCE2=64Kbit
GARANCE3=128Kbit
GARANCE4=256Kbit

MAXIMUM1=64Kbit
MAXIMUM2=128Kbit
MAXIMUM3=256Kbit
MAXIMUM4=512Kbit

BURST=64k

USER_01=192.168.1.55 #Uzivatel 1
USER_02=192.168.1.62 #Uzivatel 2
# **************************** Definice parametru ****************************

#
############################### DOWNLOAD ############################
#
# Smazani vsech qdiscu na LAN interfacu

$TC qdisc del dev $LAN_IFACE root >/dev/null

# Pridani ROOT tridy na LAN interface

$TC qdisc add dev $LAN_IFACE root handle 1:0 htb default 20

#Nastaveni rychlosti tridy dle rychlosti pripojeno do internetu

$TC class add dev $LAN_IFACE parent 1:0 classid 1:1 htb rate $INET_SPEED_DOWNLOAD burst $BURST

#Nastaveni rychlosti trid na LAN rozhrani

$TC class add dev $LAN_IFACE parent 1:1 classid 1:11 htb rate $GARANCE1 ceil $MAXIMUM2 burst $BURST #Klient 1
$TC class add dev $LAN_IFACE parent 1:1 classid 1:12 htb rate $GARANCE1 ceil $MAXIMUM2 burst $BURST #Klient 2

# ******************** Markovani paketu **************************************

# Oznaceni paketu dle cilove IP adresy

$IPTABLES -t mangle -A POSTROUTING -o $LAN_IFACE -d $USER_01 -j MARK --set-mark 1
$IPTABLES -t mangle -A POSTROUTING -o $LAN_IFACE -d $USER_02 -j MARK --set-mark 2

# Trizeni paketu do pridelenych trid

$TC filter add dev $LAN_IFACE parent 1:0 protocol ip handle 1 fw flowid 1:11
$TC filter add dev $LAN_IFACE parent 1:0 protocol ip handle 2 fw flowid 1:12

#
############################### UPLOAD ############################
#

# Smazani vsech qdiscu na INET interfacu

$TC qdisc del dev $INET_IFACE root >/dev/null

# Pridani ROOT tridy na LAN interface

$TC qdisc add dev $INET_IFACE root handle 1:0 htb default 20

#Nastaveni rychlosti tridy dle rychlosti pripojeno do internetu

$TC class add dev $INET_IFACE parent 1:0 classid 1:1 htb rate $INET_SPEED_UPLOAD burst $BURST

#Nastaveni rychlosti trid na INET rozhrani

$TC class add dev $INET_IFACE parent 1:1 classid 1:11 htb rate $GARANCE1 ceil $MAXIMUM1 burst $BURST #Klient 1
$TC class add dev $INET_IFACE parent 1:1 classid 1:12 htb rate $GARANCE1 ceil $MAXIMUM3 burst $BURST #Klient 2



#******************** Markovani paketu **************************************

# Oznaceni paketu dle cilove IP adresy

$IPTABLES -t mangle -A PREROUTING -i $LAN_IFACE -s $USER_01 -j MARK --set-mark 31
$IPTABLES -t mangle -A PREROUTING -i $LAN_IFACE -s $USER_02 -j MARK --set-mark 32

# Trizeni paketu do pridelenych trid

$TC filter add dev $INET_IFACE parent 1:0 protocol ip handle 31 fw flowid 1:11
$TC filter add dev $INET_IFACE parent 1:0 protocol ip handle 32 fw flowid 1:12

Dotazka, jake vyhody ma markovani v chainu PREROUTING oproti FORWARDU?

Že ty pakety omarkujete ještě dříve, než je dostane router. Takže pak můžete značky použít mimo jiné jako kritérium pro policy routing.

hehe odkad ten script mas ? Tohle jsem narychlo psal asi pred 1,5 rokem :), ale chodi to celkem dobre u jolegy na tom fici 40 useru na ADSLku

velmi pekny priklad, az na to ze to upload vubec nefunguje, alespon me, nevim jak komu

caves mohol by si sem hodit ake mas nastavenie samotneho firewallu ?

Mozna by to slo resit malou klickou.
-na eth0 (sitovka vedouci do Inetu) vytvorit alias eth0:1, dat mu adresu lokalni adresu a na nem shapovat, zatimco NAT pobezi dale na eth0.

berte toto ale spis jako otazku :)
Lama

Shapovat sa da len na realnych interfaces, takze ziadne eth0:1 nehrozi ....

a da se shapovat na bridgovanem rozhrani? kdyz mam eth0 + eth1 = br0, muzu shapovat na br0 nebo musim na eth0 a eth1 zvlast?

Br0 je realny interface, takze sa da na nom shapovat.

Spíše bych to řekl takto: žádné virtuální rozhraní eth0:1 už dávno neexistuje, je to jen iluze, která se udržuje jen proto, že spousta lidí dodnes používá ifconfig.

...a mohu se zeptat jak se to tedy dela "dnes"?

Je mozne shapovat na stroji, kde bezi NAT HTBckem prichozi i odchozi provoz, pri rozdelovani do jednotlivych trid nejen podle IP adres, ale i podle MAC adres?
Mate nekdo priklad? Dik Pepe

Lze to, viz markování pomocí ebtables, ale tobě asi jde spíš o to, aby každý klient s přidělenou IP byl ten s tou správnou MAC, a to lze elegantně udělat ve Shorewall maclist, eventuelně ručně.

Dik za tip.
Neznam Shorewall. Je mozne neco nakonfigurovat tak, ze v pripade, ze MAC a IP nesedi, bude tento traffic smerovan na nejakou lokalni www stranku, popr. oriznuty na hodne malou rychlost (2kbit)?

Zajimalo by me zda ten NAT obejit timto:

eth0 - internet
eth1 - LAN

masquerade se provadi az tesne pred odeslanim na eth0 tak proc nepovesit qdiscy na eth1? tam uz prece maj vsechny pakety jak prichozi tak odchozi adresu z LAN ne?

kdyz uz pisu, jak zmerit nebo kontrolovat rychlost? presneji receno nejaky softik, ktery by mi ukazoval jakou aktualni rychlosti stahuje to ktere PC podle IP adres

Doporucuji netwatch. Nevim, z jakeho duvodu, ale na Cyrix 166MHz se mi tuhnul. V kazdem pripade i tak je to extreme nabuseny program. Ja ted shanim nejaky bandwidth manager, ktery by prubezne blil nejake tabulky a z nich delal grafy jednotlivych ip.

Dobrý den,
mohl by mi někdo napovědět, jak by se dal monitorovat traffic na jednotlivých třídách (počet dat za určitý časový úsek)? Děkuji

iptables -L -v

Vypise, kolik byte a kolik packetu proslo pres ktere pravidlo.

tc -s class show dev $DEV

a z toho si to periodicky vytahuj sh&&(awk||sed||perl||c) nebo jinak :)

Děkuji

...neb take http://rousse.pm.org/sasacct/ .

Ne přímo pro třídy, ale pravěpodobně pro tvé potřeby dostatečné: ipaccounting.standus.com

Zdravim,
do oblibenych otazek bych jeste pridal
"Jak osahapovat download procesu bezici na routeru"

Podnikl jsem v tomto smeru nejaky uspech(
http://www.czfree.net/forum/showthread.php?threadid=9822&referrerid=0 )

ale nebyl cas to dokoncit. Nechce v tom nekdo pokracovat a dat vedet jak to dopadlo?
Dik & shapovani zdar

Pri cteni vsech techto clanku, jsem dostal chut si HBT taky vyzkouset. Ale nez neco delam, tak planuju jak na to.

Jestli jsem to dobre pochopil, tak pokud by slo jen o pristup na internet funguje deleni pasma v pohode. Pokud by nekdo pristupoval k tomutop serveru jako na File server, a chtel vyuzit maximalky sitovky, coz je 100Mbit tak ma smulu a dostane jen pridelenych napr. 80kB. Mam pravdu?

Jestli ano, nesel by tento problem resit virtualnim rozhranim? A povesit IMAP, SAMBU ... treba jen na tento virtualni interface? Prave ze nevim, jestli dojde k shapovani i na virtualnim interface kdyz byl vytvoren z fyzickeho?

Muze mi nekdo potvrdit nebo vyvratit tuto ideu?

Diky

Tak jsem vyzkoušel - to s tim eth1:0 a bohuzel to nefungovalo, provoz byl shapovan stejne. Mozna, kdyby se tam dal ten interfaces byl fyzicky, tak by to slo. To bohužel neodzkoušim.

Moc dekuju za pokus, alespon to teda vyzkousim s tim fyzickym rozhranim. Tam uz to musi makat :) Pri cenach sitovek, jde jen o to mit volny slot :)))

Proc tak slozite? Ja mam nastaveny v htb filtr, ze pokud je src ip == <ip adresa vnitrniho iface serveru> tak soupnout do 100mbit class a samba jede full speed... Druha vec ze to vylucuje squid.

No nevim , mozna kecam (HTB jsem nestudoval detailne), ale logicky tam nemuze byt src ip (zdrojova ip adresa serveru - vzdyt tam ma byt ip adresa pc v lokalni siti) serveru, ale musi to byt jako cilova adresa spojeni (src=PC -> destination=server).

Markujte v OUTPUTU a pak je jasny, ze traffic je lokalni...

Do routeru mi tecou data viz. predmet. Na nem je potrebuju rozdelit HTBckem, jakou mam ale nastavit RATE korenove tridy, kdyz se meni od 320 do 640?
320/640 plati pro upload i download.
Dik

Shapovat s HTB (a pokud vím tak i se všemi ostatními disciplínami s třídami) pouze linku s pevným rate, to znamená, že by jsi musel dát u kořenu rate 320 (nebo ještě lépe o pár procent nižší, dle ztrát na uplinku a kvality shapování u providera), a na ten převis do 640 se vybodnout.

To jsem ještě já :-) Teoreticky by asi šlo modifikovat HTB nebo vytvořit novou disciplínu, která by rate u kořenu měnila podle délky front, a rate a ceil u listů by byly dány poměrem k rate kořenu. Těžko ale říct, jestli se do toho někdo pustí, asi to nebude úplně triviální ;-)

A ještě já ... Stejně by pak ale byl problém s frontami u ISP. Možná by to šlo, kdyby tam byly nastaveny na co nejmenší, aby byla co nejkratší reakční doba pro změnu kořenového rate. Ale fakt už možná říkám bludy.