Klasifikaci provozu site rozumime doplneni sluzeb standardnich siti o moznost, jakym zpusobem ma sit resit problem sveho velkeho vytizeni. Sit nam dokaze hodne zatizit jedina sluzba (napriklad FTP). Pote nam jiz budou velice spatne fungovat ostatni sluzby, protoze pro ne zustane pouze kousek kapacity site.
Diky klasifikaci provozu site muzeme nastavit ruznym sluzbam ruzne priority - napr. ssh by melo mit vyssi prioritu nez ostatni sitove sluzby. Dale muzeme podle ruznych pravidel nastavovat minimalni (garantovane) a maximalni rychlosti ruznym sluzbam, ale i jednotlivym stanicim na lokalni siti. Diky omezovani sirky pasma mohou dnesni ISP (Internet Service Provideri) nastavovat svym klientum ruzne sirky pasma, mohou nastavit, aby jednu linku sdilelo vice uzivatelu, a tim ji efektivne vyuzili.
K usmernovani sitoveho provozu se pouzivaji tyto fronty paketu (qdiscs) :
Tyto fronty jsou az na vystupu ze zarizeni, tj. je zde problem omezovat rychlost na vstupu.
HTB je shaper s podporou trid. Diky nemu muzeme vytvorit stromovou strukturu - tj. pro kazdy pocitac nebo sluzbu pouzijeme list stromu. Na tyto listy muzeme zavesit nekterou z predeslych front, pokud zadnou nezavesime, tak se pouzije standardni fronta FIFO.
Priklad vytvoreni htb stromu za pomoci tc
#napred smazeme koren byvaleho stromu tc qdisc del dev eth0 root #vytvorime novy koren tc qdisc add dev eth0 root handle 1:0 htb #nastavime rychlost pro koren tohoto stromu tc class add dev eth0 parent 1:0 classid 1:1 htb rate 1Mbit #Vytvorime syny, kteremu nastavime minimalni (garantovanou) rychlost, maximalni, a prioritu paketu tc qdisc add dev eth0 parent 1:1 classid 1:10 htb rate 128Kbit ceil 256Kbit prio 3 tc qdisc add dev eth0 parent 1:1 classid 1:11 htb rate 128Kbit ceil 256Kbit prio 3 #trida s vyssi prioritou (napr. pro ssh apod.) tc qdisc add dev eth0 parent 1:1 classid 1:12 htb rate 128Kbit prio 1 #na tyto tridy povesime SFQ #perturb je hodnota v sekundach, po ktere dochazi k nejakemu prepocitavani tc qdisc add dev eth0 parent 1:10 handle 10:0 sfq perturb 10 tc qdisc add dev eth0 parent 1:11 handle 11:0 sfq perturb 10 tc qdisc add dev eth0 parent 1:12 handle 12:0 sfq perturb 10
Nyni mame vytvoreny htb strom, a potrebujeme nastavit pravidla, ktera jednotlive pakety priradi do jednotlivych listu ve strome. Toto delame pomoci univerzalniho nastroje U32 matcher. Dokaze pakety srovnavat dle zakladnich veci jako jsou cilova a zdrojova adresa, ale nabizi mnoho dalsich moznosti - diky nemu muzeme porovnavat hlavicku paketu doslova po bitech.
#nyni nastavime, ktere sluzby poslat do ktereho listu stromu #u32match dle dst ip tc filter add dev eth0 parent 1:0 protocol ip u32 match ip dst 10.0.0.10 flowid 1:10 #dle src a dst ip tc filter add dev eth0 parent 1:0 protocol ip u32 \ match ip dst 10.0.0.11 match ip src 147.251.205.1 flowid 1:11 #dle ciloveho portu tc filter add dev eth0 parent 1:0 protocol ip u32 match tcp dst 22 0xffff flowid 1:12
V mnoha pripadech je lepsi si paket napred oznacit pomoci firewallu a pote pouze matchovat toto oznaceni.
iptables -t mangle -A FORWARD -p tcp -d 10.0.0.10 -j MARK --set-mark 10 tc filter add dev eth0 parent 1:0 protocol ip handle 100 fw flowid 1:10
IMQ - Intermediate Queueing Device - je virtualni zarizeni, diky kteremu muzeme omezovat traffic i na vstupnim zarizeni.
IMQ muzeme nainstalovat podle tohoto navodu.
IMQ je virtualni zarizeni, tudiz s nim pracujeme obdobne, jako s ostatnimi zarizenimi :
modprobe IMQ #napred toto zarizeni vypneme - zda se mi, ze zde je nejaky bug, diky kteremu po vice imq0 up za sebou dochazi ke zduplikovani IMQ stromu ifconfig imq0 down ifconfig imq0 up
Dale musime presmerovat vstupni traffic ze zarizeni do tohoto IMQ zarizeni jeste pred jeho jakymkoliv zpracovanim
iptables -t mangle -A PREROUTING -j IMQ
Nyni nam jiz nic nebrani udelat IMQ strom, ne nepodobny htb stromu
tc qdisc del dev imq0 root tc qdisc add dev imq0 root handle 1:0 htb tc class add dev imq0 parent 1:0 classid 1:1 htb rate 1Mbit ...
IMQ je velice uzitecna vec z ceskych luhu a haju, ale ma jeste nekolik bugu a neni extra moc stabilni - snad proto se zatim nedostala do oficialniho jadra.
Jednim ze zpusobu, jak resit traffic shaping na nejakem routeru, je povesit na kazdy interface na vystup HTB a na vstup IMQ - timto dosahneme omezeni trafficu v obou smerech.
Efektivni je zaroven pouzivat pro zarazovani do htb trid firewall, diky kteremu muzeme zajistit pakety, ktere nepatri do zadne tridy :
#napred oznackuju kazdy paket, ktery router forwarduje nejakym defaultnim cislem
iptables -t mangle -A FORWARD -j MARK --set-mark 1000
pro kazde zarizeni
{
VYTVORENI_HTB_STROMU
VYTVORENI_IMQ_STROMU
}
#pote oznackuju pakety podle prislusnosti k jednotlivym tridam
iptables -t mangle -A FORWARD -p tcp -d 10.0.0.10 -j MARK --set-mark 10
...
#a pakety, ktere nepadly do zadne tridy zahodim
iptables -t mangle -A POSTROUTING -t mangle --match mark --mark 1000 -j REJECT
Pokud se vam nelibi vytvareni htb a imq stromu rucne, je zde mozno pouzit programy :
Pokud v kernelu povolime tzv. bonding - (CONFIG_BONDING=y) - mame moznost sloucit vice fyzickych rozhrani do jednoho virtualniho (napr. bond0). Na toto virtualni zarizeni muzeme jiz povesit htb stromy, popr. dalsi fronty paketu. Je mnohem efektivnejsi mit zarizeni sloucena do jednoho a zde rozdelovat rychlost, nez nastavovat rychlost na kazdem zvlast. Vice o jeho nastaveni najdeme v $kernel_directory/Documentation/networking/bonding.txt
Pro testovani provozu se da pouzit znamy program iptraf.