HTB principy a priklady

POZOR!! tato sekce je velmi velmi stara a zustava zde jen jako pozustatek z minulosti

Znaceni trid a qdiscu:

handle ("id"): identifikator tvoreny dvojici x:y kde X oznacuje qdisc a Y tridu v danem qdiscu. id qdiscu ma za Y vzdy 0 (nebo se vynecha y:) trida ma vzdy na pozici Y hodnotu od 1-ffff (X-hlavni cislo major, Y-vedlejsi cislo minor) (mam pocit ze nekolik poslednich hodnot (FFFF:FFFF) je rezervovanych pro neco specialniho ?)

Typy trid:

root: trida zavesena primo na qdisc
inner: trida ktere ma parent class ale neni do ni smerovan zadny provoz (obsahuje jen dalsi child tridy)
leaf: koncova trida (list pomyslneho stromu) zde se odehrava shaping a zdrzeni paketu kdyz neni dostatek tokenu pro odesilani

Strom trid z prikaldu:

tc prikazy pro vytvoreni pravidel

1) $TC qdisc del dev $IF root &>/dev/null
2) $TC qdisc add dev $IF root handle 1: htb default ff r2q 10

3)  $TC class add dev $IF parent 1: classid 1:2 htb rate 8Mbit prio 0
4)   $TC class add dev $IF parent 1:2 classid 1:10 htb rate 1000kbit ceil 2Mbit  prio 1
5)     $TC qdisc add dev $IF parent 1:10 handle 10: sfq
6)   $TC class add dev $IF parent 1:2 classid 1:12 htb rate 1000kbit ceil 2Mbit  prio 2
7)     $TC class add dev $IF parent 1:12 classid 1:20 htb rate 500kbit ceil 2Mbit prio 2
8)     $TC class add dev $IF parent 1:12 classid 1:21 htb rate 500kbit ceil 2Mbit prio 2
9)   $TC class add dev $IF parent 1:2 classid 1:ff htb rate 33kbit prio 3

10)  $TC class add dev $IF parent 1:2 classid 1:11 htb rate 6Mbit prio 0
11)    $TC qdisc add dev $IF parent 1:11 handle 2: htb r2q 3 default ff   
12)      $TC class add dev $IF parent 2: classid 2:1 htb rate 6Mbit prio 0
13)   	   $TC class add dev $IF parent 2:1 classid 2:5 htb rate 3Mbit ceil 6Mbit prio 0
14) 	   $TC class add dev $IF parent 2:1 classid 2:6 htb rate 2Mbit ceil 6Mbit prio 0
15) 	   $TC class add dev $IF parent 2:1 classid 2:ff htb rate 33kbit prio 3

-----------------------------------------------------------------------
1,2) vytvoreni noveho qdisc zaveseneho na rozhrani ethX, imqX, atd.. s default tridou 1:ff

3) vytvoreni root tridy 1:2 (tridy zavesene primo na qdisc nemuzou mezi sebou sdilet pasmo, proto byva na qdics zavesena pouze jedna jedina root trida a vse ostatni je az v teto tride)

4,6) vytvoreni inner trid ktere mezi sebou sdili pasmo root tridy a to tak ze trida 1:10 ma pro plneni ceil prednost pred 1:12

5) zaveseni qdiscu na tridu 1:10 s disciplinou sfq zajisti priblizne rovnomerne rozdeleni pasma v teto tride mezi jednotlive tcp,udp spojeni

7,8) vytvoreni leaf tridy 1:20 a 1:21 ktere se rovnomerne deli o pasmo sve parent tridy 1:12

9) vytvoreni pomale default tridy 1:ff s malou prioritou a rychlosti

10) vytvoreni tridy 1:11 ktera bude "novym korenem" pro dalsi tridy

11) vytvoreni noveho qdiscu ktery je potomkem tridy 1:11 a vytvari nove "hlavni cislo" 2: timto sme si vytvorily novy "koren" se kterum budeme zachazet stejne jako s 1: defaultni trida je zde 2:ff

12) vytvoreni root tridy 2:1 v novem qdiscu 2:0, tato trida ma stejny vyznam jako root trida 1:2 v 1: qdiscu

13,14) vytvoreni leaf trid ktere mezi sebou mohou sdilet pasmo z root tridy 2:1

15) vytvoreni pomale default tridy 2:ff s malou prioritou a rychlosti

tc prikazy pro filtry

1) $TC filter add dev $IF parent 1: protocol ip prio 5 u32 match ip src 192.168.0.0/16 flowid 1:11
2) $TC filter add dev $IF parent 1: protocol ip prio 10 u32 match ip src 10.1.1.1/32 flowid 1:10
3) $TC filter add dev $IF parent 1: protocol ip prio 20 u32 match ip src 10.1.0.0/16 flowid 1:20
4) $TC filter add dev $IF parent 1: protocol ip prio 20 u32 match ip src 10.2.0.0/16 flowid 1:21

5) $TC filter add dev $IF parent 2: protocol ip prio 20 u32 match ip src 192.168.0.0/24 flowid 2:5
6) $TC filter add dev $IF parent 2: protocol ip prio 20 u32 match ip src 192.168.1.0/24 flowid 2:6

-----------------------------------------------------------------------
1) filtr s nejmensim prio je vyhodnocen jako prvni a posila vse z 192.168.0.0/16 rovnou na 1:11 tedy na qdisc 2:
2) filtr s prio 10 je vyhodnocen pred 3,4) a posila 10.1.1.1/32 do tridy 1:10 (jeden host napr. server)
3) filtr s prio 20 je vyhodnocen posila 10.1.0.0/16 do tridy 1:20
4) filtr s prio 20 je vyhodnocen posila 10.2.0.0/16 do tridy 1:21
5,6) filtr zavesny na qdiscu 2:0 vyhodnocuje podrobneji to co prislo z filtru 1) a radi do prislusne tridy

Principy a detaily v nastaveni

Token and bucket (poukazka a kyblik)

Je system pridelovani pasma tridam, kdy pro dany casovy interval ma root trida urcity pocet tokenu a ty rozdeluje mezi child tridy, pokud leaf trida ma pridelen token, pripadne ma nekolik tokenu v "kyblicku" (viz. burst) muze odeslat tolik bytu kolik ma volnych tokenu. Kdyz nema laef trida nic ve sve fronte co by cekalo na odeslani, muze si tokeny "nasetrit (napustit do kyblicku)" a potom odeslat az maximalne burst bytu najednou.

Tabukla stavu a prislusnych akci

typ tridy	stav tridy	HTB internal state	akce
leaf	<rate	HTB_CAN_SEND	Leaf trida muze odeslat bytu do vyse dostupnych tokenu (ne vice nez burst)
leaf	>rate,<ceil	HTB_MAY_BORROW	Leaf trida si muze pozadat o tokens/ctokens z parent tridy. kdyz jsou tokeny k dispozici, potom je ji posilano po "QUANTUM" tokenu a leaf trida muze odeslat az cburst bytu z fronty
leaf	>ceil	HTB_CANT_SEND	Zadne pakety nejsou posilany a jsou zpozdovany ve fronte
inner, root	<rate	HTB_CAN_SEND	Inner class posila tokeny child tridam
inner, root	>rate,<ceil	HTB_MAY_BORROW	Inner class pozada o zapujceni tokens/ctokens z parent tridy, a preda je po quantech svim child tridam.
inner, root	>ceil	HTB_CANT_SEND	Inner class nemuze pozadat o dalsi ctokeny a nejsou tedy predavany dal.

Parametry pro htb tridy

Usage: qdisc add ... htb [default N] [r2q N]
 default  minor id of class to which unclassified packets are sent {0}
 r2q      DRR quantums are computed as rate in Bps/r2q {10}
 debug    string of 16 numbers each 0-3 {0}

Usage: class add ... htb rate R1 burst B1 [prio P] [slot S] [pslot PS] [ceil R2] [cburst B2] [mtu MTU] [quantum Q]
 rate     rychlost alokovana pro tuto tridu
 burst    max bytes burst ktere muze byt naakumulovano v prubehunecinosti {computed}
 ceil     definovani maximani vypujcene rychlosti {rate}
 cburst   burst ale pro ceil {computed}
 mtu      max packet size we create rate map for {1600}  ????
 prio     priorita pro leaf tridu; nizsi hodnota je obslouzena jako prvni {0}
 quantum  kolik bytu muze byt z tridy obslouzeno na jednou (tyka se sdilene casti pasma){use r2q}
 slot,pslot ?? sem nikde v dokumentaci nevidel :(

prikad zapisu pravidla:
tc class add dev eth0 parent 1:2 classid 1:3 htb rate 400kbit burst 1600 prio 2 ceil 2Mbit cburst 1600 quantum 1600

Sdileni rychlosti

kdyz vice trid chce sdilet pasmo potom je kazde pridelen urcity pocet bytu nez je obslouzena dalsi trida. to to mnozstvi se naziva quantum, pro precizni rizeni je potreba aby quantum bylo co nejmensi ale vetsi nez MTU (1500B). Normalne se automaticky vypocitava z (rate/r2q) pokud je to potreba je mozne quantum stanovit rucne kazde tride a potom je parametr r2q ignorovan pro danou tridu. Quantum se tyka pouze "koncovich" trid odebirajicich toky NAD rychlost stanovenou pomoci rate. Pokud maji tridy stejnou prio je jim pridelovano pasno nad hodnotu rate rovnomerne (maji-li stejne quantum) napr.:

tridy jsou vyuzity na plno
root \ rate 500k
     |- leaf - rate 100k ceil 500k   (dostane 250k)
     |- leaf - rate 100k ceil 300k   (dostane 250k)

pokud by mela trida s ceil 500k vetsi quantum mnela by teoreticky dostat vice napr. 300-350kbit protoze pri jednom cylku algoritmu by dostavala za jeden pruchod vice tokenu k pouziti. (toto je moje uvaha na zaklade toho co sem precetl takze to NEMUSI byt uplne presne tak!!)

chybove hlasky
HTB: quantum of class xxxxx is small. Consider r2q change.
HTB: quantum of class xxxxx is big. Consider r2q change.
jsou zpusobeny prave nevhodne automaticky vypoctenou Q proto je lepsi stanovit Q primerene velke pro danou rate rucne a zlepsit tak preciznost sdileni pasma.

velikost quantum a ostnich hodnot muzeme vypsat pomoci "tc -d class show dev ethX"

Burst

rate a ceil nejsou "vykonavany" v case presne ale po urcitych blocich, ktere prumerne za nejaky cas daji stanovenou rychlost. V jeden cas je odeslano z jedne tridy tolik paketu kolik tokenu je "nasetreno" maximalni rychlosti daneho rozhrani a pote se pokracuje obsluhou dalsi tridy.Burst se da vyuzit k "zrychlenemu" nacitani www, kdy na pozadavek prijde "naval" dat a pri cteni dane stranky se v dobe klidu pomyslny "burst kyblicek" naplni a je pouzitelny pro dalsi burst dat. TC automaticky vypocitava nejmensi optimalni hodnotu pro burst a cburst. Hodnota burst vlastne udava velkost toho "kyblicku", kdyz je "kyblicek" vypusten dale propousti pouze tolik tokenu ktere do neho pomalu pritekaji na tomto principu funguje TBF disciplina
Parent (rodicovska) trida musi mit vzdy vetci, nebo alespon stejne velky burst jako jakehokoliv jeji podtrida.

Priority

0 (default hodnota) nejvyssi priorita, nejmensi prioritou je 7 (je to definovano v include/linux/pkt_sched.h volba TC_HTB_NUMPRIO), priorita se vztahuje k ceil casti pasma, trida s vyssi prioritou je naplnena az po ceil a tim co z volneho pasma zbyde se naplni dalsi trida s prioritou nizsi, proto by prioritnejsi tridy nemely mit ceil moc velke (mohly by zabrat cele dostupne pasmo). Bohuzel mi neni jasne v jakem "rozsahu" priorita plati: a) v ramci trid na stejne urovni v stromove hierarchi
b) v ramci celeho stromu od korene po posledni tridu

nastroje:

http://www.docum.org/docum.org/monitor - script pro zobrazovani toku v HTB, pro uspesne debugovani htb pravidel naprosto nezbytne!!

zdroje:

http://www.tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html
http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
http://www.docum.org/

vsechno NEmusi byt uplne pravda!!! pokud nekdo najde nejakou blbost at mi napise mrak(zavinac)mrak.cz a ja to opravim at to nemate ostatni lidi
poznamky:

---

ARP trafic 
     tc class add dev $DEV parent 1:2 classid 1:10 htb rate 50kbit ceil 500kbit prio 3
        tc filter add dev $DEV parent 1: protocol arp prio 1 u32 match u32 0 0 flowid 1:10