
ADSL svszlessg-gazdlkods HOGYANDan Singletary

   dvsing@sonicspike.net

   Verzitrtnet
   Verzi: 1.3 2003.04.07 tdolgozta: ds
   A [1]hivatkozsok rsz hozzadsa.
   Verzi: 1.2 2002.09.26 tdolgozta: ds
   Az j [2]levelezlistra mutat hivatkozs hozzadsa. Hozzadva egy
   kis fejtr a fenntartott rszhez az j, tovbbfejlesztett Linux
   QoS-hez, amit specifikusan a hamarosan kiadand ADSL-hez
   fejlesztettek.
   Verzi: 1.1 2002.08.26 tdolgozta: ds
   Nhny javts (Ksznet sokaknak, akik felhvtk rjuk a figyelmet!).
   Informcis kiktsek hozzadsa a megvalstsi rszhez.
   Verzi: 1.0 2002.08.21 tdolgozta: ds
   Jobb ellenrzs a svszlessg felett, tbb teria, frisstve a
   2.4-es kernelekhez
   Verzi: 0.1 2001.08.06 tdolgozta: ds
   Els kiads

   A dokumentum lerja, hogyan lltsunk be egy Linux tvlasztt, hogy
   hathatsabban kezelje a kimen forgalmat egy ADSL modemen vagy ms
   olyan eszkzn, ami hasonl svszlessg-tulajdonsgokkal rendelkezik
   (kbelmodem, ISDN stb.). Hangslyt fektettnk az interaktv forgalom
   vrakozsi, lappangsi idejnek cskkentsre mg akkor is, ha a
   feltltsi s/vagy letltsi svszlessg teljesen teltett.
     _________________________________________________________________

   Tartalomjegyzk
   1. [3]Bevezets

        1.1. [4]A dokumentum j verzii
        1.2. [5]Levelezlista
        1.3. [6]A felelssg teljes elhrtsa
        1.4. [7]Szerzi jog s licenc
        1.5. [8]Visszajelzsek s javtsok
        1.6. [9]Magyar fordts

   2. [10]Httr

        2.1. [11]Elzetesen szksges dolgok
        2.2. [12]Elrendezs
        2.3. [13]Csomagok vrakozsorai

   3. [14]Hogyan mkdik?

        3.1. [15]A HTB alkalmazsa a kimen forgalom visszafogsra
        3.2. [16]Prioritsos vrakozsor kialaktsa HTB-vel
        3.3. [17]A kimen csomagok osztlyozsa iptables-szel
        3.4. [18]Mg nhny fogs...
        3.5. [19]Prblkozs a bejv forgalom visszafogsra

   4. [20]Megvalsts

        4.1. [21]Kiktsek
        4.2. [22]Szkript: myshaper

   5. [23]Az j vrakozsor tesztelse
   6. [24]Rendben, mkdik! Hogyan tovbb?
   7. [25]Kapcsold hivatkozsok

1. Bevezets

Jelen dokumentum clja, hogy ajnljon egy mdszert egy internethez
kapcsold ADSL (vagy kbel) modemen kimen forgalom kezelshez. A
problma az, hogy a legtbb ADSL vonalat lekorltoztk 128kbs vagy e krli
adatfeltltsi sebessgre. Mg slyosabb teszi a problmt a csomagok
vrakozsi sora az ADSL modemen bell, ami ha tele van, 2 vagy 3 msodpercet
is ignybe vesz, mg kirl. Ez egyttesen azt jelenti, hogy amikor a
feltltsi svszlessg teljesen teltve van, a tbbi csomagnak 3
msodpercet is ignybe vehet, amg kijutnak az Internetre. Ez megbnthatja
az interaktv alkalmazsokat, mint a telnet vagy a tbbszerepls jtkok.
     _________________________________________________________________

1.1. A dokumentum j verzii

Mindig megtallod a jelen dokumentum legjabb verzijt a vilghln a
[26]http://www.tldp.org webhelyen.

Az j verzik ezen kvl klnbz Linux WWW s FTP szerverre is fel vannak
tve, belertve az LDP honlapjt a [27]http://www.tldp.org webhelyen.
     _________________________________________________________________

1.2. Levelezlista

Az ADSL svszlessg-gazdlkodst illet krdsek s friss informcik
vonatkozsban krlek, iratkozz fel a tma levelezsi listjra a
[28]http://jared.sonicspike.net/mailman/listinfo/adsl-qos honlapon.
     _________________________________________________________________

1.3. A felelssg teljes elhrtsa

Sem a szerz, sem a terjesztk, sem ms kzremkd munkatrs nem
felels semmilyen mdon a fizikai, pnzgyi, morlis vagy brmely ms
tpus krrt, amit a szvegben ajnlott dolgok kvetse okozott.
     _________________________________________________________________

1.4. Szerzi jog s licenc

A jelen dokumentum Dan Singletary (2002) szellemi tulajdona, amelyet a GNU
FDL (GNU Szabad Dokumentcis Licenc) alatt adtak ki, amelyet ezennel
hivatkozsknt beolvasztottunk.
     _________________________________________________________________

1.5. Visszajelzsek s javtsok

Ha krdseid vagy ajnlsaid vannak a dokumentumhoz kapcsoldan, nyugodtan
lpj kapcsolatba a szerzvel a [29]dvsing@sonicspike.net e-mail cmen.
     _________________________________________________________________

1.6. Magyar fordts

A magyar fordtst [30]Szjjrt Lszl ksztette (2002.07.28). A
lektorlst [31]Daczi Lszl vgezte el (2002.09.05). A dokumentum
legfrissebb vltozata megtallhat a [32]Magyar Linux Dokumentcis Projekt
honlapjn.
     _________________________________________________________________

2. Httr

2.1. Elzetesen szksges dolgok

A dokumentumban vzolt mdszernek mkdnie kell ms Linux konfigurcikon
bell is, de nem teszteltk mson, csak a kvetkezk alatt:

     * Red Hat Linux 7.3
     * 2.4.18-5 Kernel teljes QoS tmogatssal (modulok: OK) s belertve
       a kvetkez kernel-foltokat (amik trtnetesen az jabbakban
       benne is lehetnek mr):
          + HTB vrakozsor - [33]http://luxik.cdi.cz/~devik/qos/htb/

            Megjegyzs

   jelentettk, hogy a 2.4.18-3 kernelverzit kveten a Mandrake (8.1,
   8.2) mr a HTB-hez adott folttal szlltja a rendszert.
          + IMQ eszkz - [34]http://luxik.cdi.cz/~patrick/imq/
     * iptables v1.2.6a vagy ksbbi (a Red Hat 7.3-mal szlltott
       iptables verzibl hinyzik a "length" modul)

   Megjegyzs

   a dokumentum elz verziiban olyan svszlessg-kezelsi mdszert
   adtunk meg, ami magban foglalta a meglv sch_prio vrakozsor
   megfoltozst. Ksbb gy talltuk, hogy ez a folt teljesen
   felesleges. Ezen fell a jelen dokumentumban taglalt mdszer jobb
   eredmnyt ad (br a doksi rsa idejn 2 kernelfolt szksges :)
   Szerencss foltozst.)
     _________________________________________________________________

2.2. Elrendezs

A dolgok egyszerstse rdekben, a dokumentumban az sszes hlzati
eszkzre s belltsra vonatkoz hivatkozs a kvetkez hlzati
elrendezst tkrzi:

               <-- 128kbit/s      --------------     <-- 10Mbit -->
  Internet <--------------------> | ADSL modem | <--------------------
                1.5Mbit/s -->     --------------                     |
                                                                     | eth0
                                                                     V
                                                         ----------------------
--------
                                                         |
       |
                                                         | Linux tvlaszt (ro
uter)  |
                                                         |
       |
                                                         ----------------------
--------
                                                          | .. | eth1..ethN
                                                          |    |
                                                          V    V

                                                       Helyi hlzat
     _________________________________________________________________

2.3. Csomagok vrakozsorai

A csomagok vrakozsi sorai (queue) olyan "ednyek", amik az adatokat
troljk a hlzati eszkz szmra, amikor azokat nem lehet azonnal
elkldeni. A legtbb vrakozsor egy FIFO ("ami elsnek megy be, elsnek
megy ki") fegyelmezsi rendszert, diszciplnt hasznl (rviden qdisc - a
ford.), hacsak specilisan msra nem lltjk be. Ez azt jelenti, hogy
amikor egy eszkz vrakozsora teljesen tele van, a vrakozsi sorba
utoljra kerlt csomagot csak akkor tovbbtja az eszkz, amikor az sszes
tbbit mr elkldte.
     _________________________________________________________________

2.3.1. A kimen g

ADSL csatlakozs esetn a svszlessg aszimmetrikus, tipikusan 1.5Mbit/s a
bejv s 128kbit/s a kimen g teljestmnye. Br ez a vonali sebessg, a
Linux tvlaszt PC s az ADSL modem kztti illeszt tipikusan 10Mbit/s
vagy a feletti sebessget tud. Ha a helyi hlzat fel nz csatol szintn
10Mbit/s sebessg, akkor tipikusan NEM LESZ vrakozsor az tvlasztnl,
amikor a helyi hlzat kld csomagokat az Internet fel. Az eth0 eszkzn
keresztl olyan sebessggel mennek ki a csomagok, ahogy a helyi hlzatbl
rkeztek. Ehelyett viszont a csomagok bellnak a sorba az ADSL modemnl,
mivel 10Mbit/s-el rkeznek, s csak 128 kbit/s-el mehetnek ki. Idlegesen a
csomagok vrakozsora a modemnl megtelhet, s minden tovbbi csomag, amit
kldenek neki, csendben eldobsra kerl. A TCP protokollt gy terveztk,
hogy kezelje ezt, s be fogja lltani a kldsi ablak (transmit window)
mrett gy, hogy teljesen kihasznlja a rendelkezsre ll svszlessget.

Amg a vrakozsorok a TCP-vel kombinlva a svszlessg lehet legjobb
kihasznlst teszik lehetv, a nagy FIFO sorok megemelik az interaktv
forgalom lappangsi idejt.

Egy msik, a FIFO-ra hasonlt vrakozsor az n-svos prioritsos sor. Ennl
ahelyett, hogy csak egy vrakozsort alaktannk ki a bejv csomagok
szmra, az n-svos sornak n darab FIFO sora van, amibe a csomagokat az
osztlyozsuk alapjn helyezzk be. Minden sornak van egy prioritsa, s a
csomagok mindig a legnagyobb priorits, csomagokat tartalmaz sorbl jnnek
ki. Ezt a fegyelmezsi szablyt alkalmazva az FTP csomagok egy alacsonyabb
priorits sorba helyezhetk, mint a telnet csomagjai, gy mg egy FTP
feltlts alatt is, egy darab telnet csomag is kijuthat a sorbl s azonnal
tovbbkldsre kerlhet.

A dokumentumot talaktottuk az j linuxos vrakozsor, a Hierarchical Token
Bucket (HTB) hasznlathoz. A HTB sor nagyban hasonlt a fent lert n-svos
sorra, de megvan az a tulajdonsga, hogy kpes minden osztlynak forgalmt
korltozni. Ezen kvl kpes arra, hogy forgalmi osztlyokat alaktson ki
ms osztlyok alatt, egy hierarchikus osztlyokbl ll rendszert
ltrehozva. A HTB teljes lersa meghaladja a dokumentum kereteit, de
tovbbi informci tallhat a [35]http://www.lartc.org webhelyen.
     _________________________________________________________________

2.3.2. A bejv g

Az ADSL modembe befel rkez forgalom a kimenhz hasonl mdon ll
vrakozsorba, azonban a sor a szolgltatdnl helyezkedik el. Emiatt
valsznleg nincs kzvetlen befolysod arra, hogyan lljanak sorba a
csomagok vagy melyik fajta forgalom kapjon megklnbztetett kezelst. Az
egyetlen md a vrakozsi id alacsonyan tartsra itt az, hogy
megbizonyosodsz, miszerint nem kldik az adatokat tl gyorsan szmodra.
Sajnos nincs md az rkez csomagok sebessgnek kzvetlen befolysolsra,
de mivel a forgalmazs tbbsge valsznleg TCP, van nhny mdja a
kldk lelasstsnak:

     * Szndkosan eldobni a bejv csomagokat - a TCP protokollt gy
       terveztk, hogy kihasznlja a rendelkezsre ll teljes
       svszlessget, mikzben prblja elkerlni a kapcsolaton bell a
       torldst. Ez azt jelenti, hogy nagy mennyisg adat kldsekor a
       TCP tbb s tbb adatot kld, amg vgl is egy csomag eldobsra
       kerl. A TCP rzkeli ezt, s cskkenti az tviteli ablak mrett.
       Ez a folyamat ismtldik a kapcsolat alatt, gy biztostja az
       adatok lehet leggyorsabb tvitelt.
     * A meghirdetett vteli ablak manipullsa - A TCP forgalmazs alatt
       a fogad oldal az ACK (elfogads) csomagok folyamatos sort kldi
       vissza. Az ACK csomagokban tallhat az ablakmret meghirdetse,
       ami kifejezi annak a nem elfogadott adatnak a mennyisgt, amit a
       fogad kldeni tud. A kimen ACK csomagok ablakmretnek
       babrlsval szndkosan lelassthatjuk a kldt. Ennek a
       folyamatszablyozsnak jelen pillanatban nincs (szabadon
       elrhet) megvalstsa Linuxon (de lehet, hogy dolgozom egyen!)
     _________________________________________________________________

3. Hogyan mkdik?

Kt alapvet lpssel optimalizlhatjuk a kifel men svszlessget.
Elszr tallnunk kell egy mdot arra, hogy megakadlyozzuk az ADSL modemet
a csomagok sorba lltsban, mivel nincs rhatsunk a vrakozsor
kezelsre. Ennek rdekben visszafogjuk az tvlaszt ltal az eth0-n
kikldtt adat mennyisgt, kicsit kevesebbre, mint a modem teljes kimen
svszlessge. Ez azt eredmnyezi, hogy az tvlaszt rakja vrakozsorba a
helyi hlzatrl rkez csomagokat, amik gyorsabban rkeznek, mint
megengedett kikldsk.

A msodik lps egy prioritsos vrakozsor-fegyelmi szably fellltsa az
tvlasztn. Meg fogunk valstani egy olyan sort, amit be lehet lltani
gy, hogy elsbbsget adjon az interaktv forgalomnak, mint a telnet vagy a
tbbszerepls jtkok.

   A HTB vrakozsor hasznlatval meg tudjuk valstani a svszlessg
   korltozst s prioritsos vrakozsort, egyidejleg meggyzdnk,
   hogy nincs olyan osztly, amit egy msik "kiheztetne". A kiheztets
   elkerlse rdekben nem vlaszthat a dokumentum 0.1-es javtsnl
   megadott mdszer.

   A vgs lps a tzfal belltsa, hogy az fwmark segtsgvel
   biztostsa a csomagok elsbbsgt.
     _________________________________________________________________

3.1. A HTB alkalmazsa a kimen forgalom visszafogsra

Br az tvlaszt s a modem kzti kapcsolat 10 Mbit/s sebessg, a modem
csak 128 kbit/s sebessggel tud adatokat kldeni. Minden ezt a rtt
meghalad sebessg csomag vrakozsorba ll a modemnl. Ezrt egy ping
csomag, amit az tvlasztrl kldnk, azonnal elmehet a modemhez, de nhny
msodpercet vehet ignybe, amg tnylegesen kikerl az Internetre, ha a
modem vrakozsora tartalmaz mr valamennyi csomagot. Sajnos a legtbb ADSL
modem esetben nem adhatjuk meg a vrakozsor kezelsnek mdjt illetve
annak nagysgt. gy elszr a kimen csomagokat tirnytjuk oda, ahol
mindezt megtehetjk.

Ezt a HTB sorral valstjuk meg, gy cskkentve az ADSL modemhez kldtt
csomagok szmt. Mg ha a kifel men svszlessgnk a 128kbit/s is
lehetne, kicsivel ez al korltozzuk le a csomagklds mrtkt. Ha
cskkenteni akarjuk a lappangsi idt, BIZONYOSNAK kell lennnk, hogy soha
egyetlen csomag sem ll sorba a modemnl. Ksrletezsek sorn azt talltam,
hogy a kimen forgalom krlbell 90kbit/s-ra val visszavtelvel a
svszlessg majdnem 95%-t tudom elrni a HTB vezrls nlkl. A HTB
engedlyezsvel ennl a mrtknl kivdjk, hogy a modem vrakozsorba
rakja a csomagokat.
     _________________________________________________________________

3.2. Prioritsos vrakozsor kialaktsa HTB-vel

   Megjegyzs

   Megjegyzs: az ebben a rszben lv elz ignyek (eredetileg
   N-svos prioritsos vrakozsor kialaktsnak hvtk) ksbb
   hibsnak talltattak. LEHETETLEN volt a vrakozsor klnbz
   svjaiba tartoz csomagok megjellse csak a fwmark mez ltal,
   viszont ezt gyengn dokumentltuk a dokumentum 0.1-es verzijnak
   rsakor.

   Ennl a pontnl mg nem vesznk szre semmi vltozst a
   teljestmnyben. Pusztn csak thelyezzk a FIFO sort az ADSL
   modemtl az tvlaszthoz. Valjban, a Linux alaprtelmezsben
   belltott 100 csomag mret FIFO sorval, valsznleg mg
   rosszabb is tettk a helyzetnket! De nem sokig...

   Minden szomszdos osztlynak adhatunk egy prioritst a HTB soron
   bell. A klnbz tpus forgalom klnbz osztlyokba
   helyezsvel, majd ezen osztlyokhoz klnbz prioritsok
   csatolsval, vezrelhetjk a csomagok vrakozsi sorbl val
   kivtelt s elkldst. A HTB lehetv teszi ezt, mikzben
   megakadlyozza egy osztly "kiheztetst", mivel megadhatjuk a
   minimlisan garantlt mrtket minden osztly szmra. Ezenfell a HTB
   megengedi azt is, hogy megadjuk egy osztlynak: hasznlhatja msik
   osztlyok nem hasznlt svszlessgt, egy bizonyos fels hatrig.

   Miutn belltottuk az osztlyainkat, szrket helyeznk el, hogy a
   forgalmat elhelyezzk beljk. Tbb tja is van ennek, de az itt lert
   mdszer az ismers iptables/ipchains-t hasznlja a csomagok fwmark-al
   (tzfal jellse a csomagon) trtn megjellsre. A szrk a
   csomagok fwmark-jt figyelembe vve helyezik el a forgalmat a HTB sor
   osztlyaiba. Ezen a mdon kpesek lesznk megfelel szablyok
   fellltsra az iptables-en bell, hogy bizonyos tpus forgalmat egy
   bizonyos osztlyba kldjn.
     _________________________________________________________________

3.3. A kimen csomagok osztlyozsa iptables-szel

   Megjegyzs

   eredetileg a dokumentumban az ipchains-t hasznltuk a csomagok
   besorolsra. Most az jabb iptables-t hasznljuk.

   Az utols lps ahhoz, hogy az tvlaszt elsbbsget adjon az
   interaktv forgalomnak - a tzfal belltsa: adjuk meg a forgalom
   besorolsnak mdjt. Ez a csomag fwmark mezjnek belltsval
   rhet el.

   Anlkl, hogy tlzottan a rszletekbe merlnnk, lljon itt az
   egyszerstett lersa annak, hogyan lehet a kimen csomagokat 4
   osztlyba sorolni gy, hogy a legmagasabb priorits lesz a 0x00:

    1. Jelljnk MINDEN csomagot 0x03-al. Ez alaprtelmezsben minden
       csomagot a legalacsonyabb priorits sorba helyez el.
    2. Jelljk az ICMP csomagokat 0x00-al. Szeretnnk, ha a ping mutatn
       a legmagasabb priorits csomagok vrakozsi idejt.
    3. Jelljnk minden csomagot, aminek clportja 1024 vagy kisebb,
       0x01-el. Ez elsbbsget biztost az olyan
       rendszerszolgltatsoknak, mint a Telnet s SSH. Az FTP portja
       szintn ebbe a krbe esik, de az FTP adatforgalom a magasabb
       portokon helyezkedik el s marad a 0x03 svban.
    4. Jelljnk minden csomagot, aminek a clportja 25 (SMTP), a
       0x03-al. Ha valaki levelet fog kldeni egy nagy csatolt
       llomnnyal, nem akarjuk, hogy elrassza az interaktv forgalmat.
    5. Jelljnk minden csomagot, aminek clja egy tbbszerepls
       jtk-szerver, 0x02-vel. Ez a jtkosoknak alacsony lappangsi
       idt biztost, de megakadlyozza, hogy elfoglaljk az alacsony
       vrakozst ignyl rendszerszolgltatsokat.
       Jelljnk minden "kicsi" csomagot 0x02-vel. A kimen ACK
       csomagokat a befel irnyul letltsekbl azonnal ki kell
       kldennk, hogy biztostsuk a megfelel letltseket. Ez az
       iptables "length" moduljval lehetsges.

   Termszetesen ezeket a kvnalmaknak megfelelen talakthatod.
     _________________________________________________________________

3.4. Mg nhny fogs...

Kt tovbbi dolgot tehetsz a lappangsi id javtsra. Elszr is, a
maximlis tvihet egysg (MTU) mrett kisebbre veheted, mint az
alaprtelmezett 1500 bjt. Ennek a szmnak a cskkentse egyben az tlagos
idt is cskkenti, amit az elsbbsget lvez csomagok elkldsre kell
fordtani, ha mr egy teljes mret alacsony priorits csomag kldse
folyamatban van. Ennek az rtknek a cskkentse kicsit cskkenti a
teljestmnyt is, mivel minden csomag legalbb 40 bjtnyi IP s TCP
fejlc-informcit tartalmaz.

A msik dolog a javtshoz, mg alacsony priorits forgalom esetn is, hogy
cskkented a vrakozsi sor mrett az alaprtelmezett 100-rl, ami egy ADSL
vonalon 10 msodperc alatt rl ki egy 1500 bjtos MTU-t alapul vve.
     _________________________________________________________________

3.5. Prblkozs a bejv forgalom visszafogsra

A "kzbens vrakozsor-eszkz" (Intermediate Queuing Device, IMQ)
hasznlatval az sszes bejv csomagot ugyangy egy vrakozsoron
futtathatjuk t, mint amilyen mdon a kimenket is. A csomagok prioritsa
ebben az esetben jval egyszerbb. Mivel csak a bejv TCP forgalmat
(prbljuk meg) vezrelni, az sszes nem-TCP forgalmat a 0x00 osztlyba
rakjuk, az sszes TCP forgalmat pedig a 0x01 osztlyba. A "kis" TCP
csomagokat szintn a 0x00 osztlyba soroljuk, mert ezek nagy
valsznsggel a mr elkldtt kimen adatok ACK csomagjai. Egy standard
FIFO sort lltunk be a 0x00 osztlyhoz, illetve egy "vletlenszer korai
eldobs" (Random Early Drop, RED) vrsort a 0x01 osztlyhoz. A RED jobb a
FIFO-nl a TCP vezrlst tekintve, mert eldobja a csomagokat mr a sor
olyan tlcsordulsa eltt, mikor megprblja lelasstani a forgalmat az
ellenrzs fenntartsa rdekben. Ezen kvl mindkt osztlyt le fogjuk
korltozni egy maximlis bejv forgalmi hatrra, ami kisebb, mint a vals,
ADSL modemen bejv sebessg.
     _________________________________________________________________

3.5.1. Mirt nem olyan j a bejv forgalom korltozsa?

Korltozni szeretnnk a bejv forgalmunkat, hogy elkerljk a vrakozsor
betelst a szolgltatnl, ami nha 5 msodpernyi adat pufferelst
jelentheti. A problma abban ll, hogy jelenleg a bejv TCP forgalom
korltozsnak egyetlen mdja a teljesen j csomagok eldoblsa. Ezek a
csomagok mr foglaltak nmi svszlessget az ADSL modemen, csak a Linux gp
dobta el ket abbl a clbl, hogy a jvbeni csomagokat lelasstsa. Ezek
az eldobott csomagok idnknt jra elkldsre kerlnek, mg tbb
svszlessget foglalva. Amikor korltozzuk a forgalmat, korltozzuk azon
csomagok mrtkt, amiket elfogadunk a hlzatunk szmra. Mivel az aktulis
bejv adatrta valahol efltt van az eldobott csomagok miatt, a bejv
gunkat sokkal jobban le kell korltoznunk az ADSL modem aktulis rtjnl,
az alacsony lappangsi id biztostsa rdekben. A gyakorlatban az n
1.5Mbit/s bejv gamat 700kbit/s-re kellett korltoznom, hogy elfogadhat
szinten tartsam a lappangst 5 egyidej letltsnl. Minl tbb TCP
folyamatod van, annl tbb svszlessget vesztesz az eldobott csomagok
miatt, s annl kisebbre kell venned a korltozs mrtkt.

A bejv TCP forgalom ellenrzsnek sokkal jobb mdja a TCP ablak
manipulcija, de ebben a pillanatban nincs (szabadon elrhet)
megvalstsa ennek Linuxra (amennyire n tudom...).
     _________________________________________________________________

4. Megvalsts

Mindezen okfejts utn most mr ideje, hogy megvalstsuk a
svszlessg-gazdlkodst Linuxon.
     _________________________________________________________________

4.1. Kiktsek

A DSL modemhez aktulisan kldtt adatok mrtknek korltozsa nem olyan
egyszer, mint amilyennek ltszik. A legtbb DSL modem igazbl csak egy
ethernet hd, amik tovbbtjk az adatokat oda-vissza a Linux gp s a
szolgltatnl lv gateway kztt. A legtbb DSL modem ATM-et hasznl
adattviteli csatolfelletknt. Az ATM mindig 53 bjtos cellkban kldi az
adatokat. Ezekbl 5 bjt a fejlc informci, s 48 bjt marad az
adatoknak. Mg ha csak 1 bjt adatot kldesz is, a teljes 53 bjt
svszlessget foglal, mivel az ATM cellk mindig 53 bjt hosszak. Ez azt
jelenti, hogy ha egy tipikus TCP ACK csomagot kldesz, ami 0 bjt adatot +
20 bjt TCP fejlcet + 20 bjt IP fejlcet + 18 bjt Ethernet fejlcet
tartalmaz. Valjban, mg ha a kikldtt ethernet csomagnak csak 40 bjtnyi
"hasznos terhe" van is (TCP s IP fejlc), a legkisebb mret egy Ethernet
csomagnl 46 bjtnyi adat, gy a maradk 6 bjt 0-val tltdik ki. Ez azt
jelenti, hogy az Ethernet csomag plusz a fejlc informcik aktulis hossza
18 + 46 = 64 bjt. Az ATM-mel 64 bjt tkldshez kt ATM cellt kell
kldened, ami 106 bjt svszlessget foglal. Vagyis minden TCP ACK
csomagnl 42 bjt svszlessget vesztesz. Ez rendben van, ha a Linux
figyelembe veszi a DSL modem ltal hasznlt csomag-begyazst, de ehelyett a
Linux csak a TCP s IP fejlcet s 14 bjtos MAC cmet jegyzi (a Linux nem
szmolja a 4 bjtos CRC-t, mivel ezt a hardver szint kezeli). A Linux nem
szmol a 46 bjtos minimlis Ethernet csomagmrettel, sem a fix mret ATM
cellval.

Mindez azt jelenti, hogy a kimen svszlessget valamivel kisebbre kell
lltani, mint a vals kapacits (amg nem tallunk egy csomag-idztt,
ami jegyzi a klnbz tpus csomag-begyazsokat). Azt tallhatod, hogy
sikerlt egy j rtkre belltani a svszlessget, de amikor egy nagy
fjlt tltesz le, a lappangs felszkik 3 msodperc fl. Ez
legvalsznbben amiatt van, mivel a Linux rosszul szmtja ki a bizonyos
kis ACK csomagok ltal ignyelt svszlessget.

Nhny hnapot dolgoztam ennek a problmnak a megoldsn, s majdnem
lezrtam a dolgot egy olyan megoldssal, amit hamarosan kzreadok tovbbi
tesztelsre. A megolds egy felhasznli szint vrakozsor hasznlatt
mutatja be a Linux QoS-e helyett a csomagok korltozsra. Alapveten egy
egyszer HTB sort alkalmaztam, ami a Linux felhasznli szint sorait
hasznlja. Ez a megolds (eddig) kpes volt a kimen forgalom OLYAN J
korltozsra, hogy mg egy masszv letlts (tbb szlon) s ugyanilyen
feltlts (gnutella, tbb szlon) alatt is, a lappangs 400 ms CSCSRTKET
rt csak el a nvleges, forgalom nlkli 15 ms-hoz kpest. Tovbbi
informcirt errl a QoS mdszerrl, iratkozz fel a frisstsek
levelezlistjra vagy ksbb nzd meg ennek a HOGYANnak a frissebb
vltozatait.
     _________________________________________________________________

4.2. Szkript: myshaper

A kvetkezkben egy ltalam a Linux tvlasztn a svszlessg
korltozsra hasznlt szkript listja tallhat. Ez tbb, a dokumentumban
foglalt koncepcit is felhasznl. A kimen forgalom a 7 tpustl fgg
vrsor egyikbe kerl. A bejv forgalom kt sorba kerl, a TCP csomagokat
(alacsonyabb prioritsak) elbb eldobjuk, ha a bejv adatok a mrtk
flttiek. A szkriptben megadott rtk gy tnik, jl mkdnek az n
belltsomban, de az eredmnyek vltozhatnak.

   A szkript eredetileg az ADSL WonderShaper-en alapult, amint
   megtallhat a [36]LARTC webhelyen.

#!/bin/bash
#
# myshaper - DSL/kabelmodem kimeno forgalmanak szabalyozasa.
#            Az ADSL/Cable wondershaper (www.lartc.org) szkripten alapszik.
#
# Irta: Dan Singletary (8/7/02)
#
# FIGYELEM: a szkript feltetelezi,  hogy a kernelt megfoltoztuk a megfelelo HTB

# sor s  IMQ foltokkal,  amik hozzaferhetok  itt (megj.:  az ujabb kerneleknel

# lehet, hogy nem kell folt):
#
#       http://luxik.cdi.cz/~devik/qos/htb/
#       http://luxik.cdi.cz/~patrick/imq/
#
# Konfiguracios beallitasok:
#  DEV    - ethX-re allitsuk, ami kapcsolodik a DSL/kabelmodemhez
#  RATEUP - allitsuk valamivel kisebbre, mint a modem kimeno savszelessege.
#           Nekem 1500/128  DSL vonalam  van, es a  RATEUP=90 jol mukodik a
#           128 kbps-os feltoltessel. De ahogy jonak latod.
#  RATEDN - allitsd valamivel kisebbre, mint a bejovo savszelesseg.
#
#
# Teoria az imq hasznalatarol a bejovo forgalom alakitasahoz:
#
#
# BEJOVO  TCP  KAPCSOLATOK  BEFOLYASOLASAT.  Ennek  ertelmeben  minden   nem-TC
P
# forgalmat egy  magas prioritasu  osztalyba kell  sorolnunk, mivel  egy nem-TC
P
# csomag eldobasa valoszinuleg a csomag  ujrakuldeset okozza. Ez semmi mast  ne
m
# jelent,  csak  a  savszelesseg  szuksegtelen  lefoglalasat,  hogy specifikusa
n
# valaszthatunk:  NEM  dobunk  el  bizonyos  tipusu  csomagokat, amiket magasab
b
# prioritasu tarolokba  helyezunk el  (ssh, telnet  stb). Ez  azert van,  mert
a
# csomagok  mindig  az  alacsonyabb  prioritasu  osztalybol  jonnek  elo azzal
a
# kikotessel,  hogy  a  csomagok  meg  minden osztalybol egyforman egy minimali
s
# mertekben jonnek ki (ebben a szkriptben minden tarolo legalabb a  tisztessege
s
# 1/7 savszelessegnyivel A TCP csomag  eldobasa egy kapcsolaton belul a  fogada
s
# alacsonyabb mertekehez vezet, a torlodas-elkerulo algoritmus miatt.
#
#     *  Semmit  nem  nyerunk  a  nem-TCP  csomagok  eldobasaval.  Valojaban, h
a
#     fontosak  voltak,  ugyis  ujra  elkuldik  oket, igy megprobaljuk azt, hog
y
#     sosem dobjuk el oket. Ez azt jelenti, hogy a telitett TCP kapcsolatok  ne
m
#     befolyasoljak  negativan  azokat  a  protokollokat,  amelyeknel  nincs
a
#     TCP-hez hasonlo beepitett ujrakuldes.
#
#     * A TCP kapcsolatok lelassitasa  ugy, hogy a teljes bejovo  rata kevesebb
,
#     mint az eszkoz  valos kapacitasa AZT  OKOZHATJA, hogy keves  vagy egyetle
n
#     csomag   sem   all   varakozosorba   a   szolgaltatoi   oldalon    (DSLAM
,
#     kabel-koncentrator  stb).   Mivel  ezek  a  sorok  kepesek  megtartani
4
#     masodpercnyi adatot 1500Kbps sebessegen  vagy 6 megabitnyi adatot,  ha eg
y
#     csomag sem all sorba, az alacsonyabb lappangast okoz.
#
# Kikotesek (kerdesfeltevesek a teszteles elott):
# * A bejovo forgalom ezen a modon valo korlatozasa gyenge TCP-teljestmenyt ad
?
#       - Az elozetes valsz: nem! Ugy nez ki, hogy az ACK csomagok prioritasana
k
#       beallitasa (kicsi <64b) anelkul  maximaljuk a kimeno telesitmenyt,  hog
y
#       nem  vesztunk  savszelesseget a mar meglevo ujrakuldott  csomagok miatt
.

# Megjegyzes: a kovetkezo konfiguracio jol mukodik az en beallitasaimmal:
# 1.5M/128K ADSL a Pacific Bell Internet-en keresztul (SBC Global Services)

DEV=eth0
RATEUP=90
RATEDN=700      # Figyeld meg, hogy ez jelntosen kisebb mint az 1500-as kapacit
as.
                # Emiatt nem kell a bejovo  forgalom korlatozasaval torodnod, a
mig
                # nem hasznalhatunk  jobb megvalositast,  mint pldul a TCP ab
lak
                # manipulacioja.
#
# konfiguracios beallitasok vege
#

if [ "$1" = "status" ]
then
        echo "[qdisc]"
        tc -s qdisc show dev $DEV
        tc -s qdisc show dev imq0
        echo "[class]"
        tc -s class show dev $DEV
        tc -s class show dev imq0
        echo "[filter]"
        tc -s filter show dev $DEV
        tc -s filter show dev imq0
        echo "[iptables]"
        iptables -t mangle -L MYSHAPER-OUT -v -x 2> /dev/null
        iptables -t mangle -L MYSHAPER-IN -v -x 2> /dev/null
        exit
fi

# Mindent visszaalitunk alapallapotba (torlunk)
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev imq0 root 2> /dev/null > /dev/null
iptables -t mangle -D POSTROUTING -o $DEV -j MYSHAPER-OUT 2> /dev/null > /dev/n
ull
iptables -t mangle -F MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-OUT 2> /dev/null > /dev/null
iptables -t mangle -D PREROUTING -i $DEV -j MYSHAPER-IN 2> /dev/null > /dev/nul
l
iptables -t mangle -F MYSHAPER-IN 2> /dev/null > /dev/null
iptables -t mangle -X MYSHAPER-IN 2> /dev/null > /dev/null
ip link set imq0 down 2> /dev/null > /dev/null
rmmod imq 2> /dev/null > /dev/null

if [ "$1" = "stop" ]
then
        echo "Shaping removed on $DEV."
        exit
fi

###########################################################
#
# Kimeno korlatozas (a teljes savszelesseg RATEUP-ra allitva)

# a varakozosor meretet ugy allitjuk be, hogy kb. 2 mp lappangas legyen az alac
sony
# prioritasu csomagoknal
ip link set dev $DEV qlen 30

# a kimeno eszkozon MTU-t allitunk. Az MTU csokkentese alacsonyabb lappangast
# ad, de valamivel kisebb kimeno teljesitmenyt is az IP es TCP protokoll
# felulvezerlese miatt

ip link set dev $DEV mtu 1000

# a HTB-t gyoker qdisc-nek allitjuk be
tc qdisc add dev $DEV root handle 1: htb default 26

# hozzaadjuk a fobb korlatozo osztalyokat
tc class add dev $DEV parent 1: classid 1:1 htb rate ${RATEUP}kbit

# hozzadjuk  az  alosztalyokat  -  garantaljuk  minden  osztalynak  LEGALABB
a
# "tisztesseges" osztozast  a savszelessegen.  Emiatt egy  osztalyt sem  fog eg
y
# masik kieheztetni.  Ezenkivul mindegyik  osztaly hasznalhatja  a rendelkezesr
e
# allo savszelesseget, ha a tobbi nem hasznalja.

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[$RATEUP/7]kbit ceil ${
RATEUP}kbit prio 0
tc class add dev $DEV parent 1:1 classid 1:21 htb rate $[$RATEUP/7]kbit ceil ${
RATEUP}kbit prio 1
tc class add dev $DEV parent 1:1 classid 1:22 htb rate $[$RATEUP/7]kbit ceil ${
RATEUP}kbit prio 2
tc class add dev $DEV parent 1:1 classid 1:23 htb rate $[$RATEUP/7]kbit ceil ${
RATEUP}kbit prio 3
tc class add dev $DEV parent 1:1 classid 1:24 htb rate $[$RATEUP/7]kbit ceil ${
RATEUP}kbit prio 4
tc class add dev $DEV parent 1:1 classid 1:25 htb rate $[$RATEUP/7]kbit ceil ${
RATEUP}kbit prio 5
tc class add dev $DEV parent 1:1 classid 1:26 htb rate $[$RATEUP/7]kbit ceil ${
RATEUP}kbit prio 6


# az  alosztalyokhoz  qdisc-eket adunk - SFQ-t adunk  minden osztalyhoz. Az SFQ

# biztositja,  hogy minden osztalyon  belul a kapcsolatokat (majdnem) egyenloen

# kezeljuk.


tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev $DEV parent 1:21 handle 21: sfq perturb 10
tc qdisc add dev $DEV parent 1:22 handle 22: sfq perturb 10
tc qdisc add dev $DEV parent 1:23 handle 23: sfq perturb 10
tc qdisc add dev $DEV parent 1:24 handle 24: sfq perturb 10
tc qdisc add dev $DEV parent 1:25 handle 25: sfq perturb 10
tc qdisc add dev $DEV parent 1:26 handle 26: sfq perturb 10

# az fwmark-kal  szurjuk osztalyokba a   forgalmat - itt  a csomagon  beallitot
t
# fwmark-nak megfeleloen iranyitjuk a forgalmat az osztalyokba (az fwmark-ot  a
z
# iptables  segitsegevel  kesobb  allitjuk  be).  Figyeld  meg,  hogy fentebb a
z
# alapertelmezett  prioritasu  osztalyt  1:26-ra  allitottuk,  igy  a nem jelol
t
# csomagok (vagy a nem  ismert ID-ju csomagok) alapertelmezesben  az alacsonyab
b
# prioritasu osztalyba mennek.

tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:22
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 23 fw flowid 1:23
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 24 fw flowid 1:24
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 25 fw flowid 1:25
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 26 fw flowid 1:26

#
# a MYSHAPER-OUT lanc hozzadasa az  iptables "mangle" tablajahoz - ez beallitja

# azt a tablat, amit a csomagok szuresehez es megjelolesehez hasznalunk.

iptables -t mangle -N MYSHAPER-OUT
iptables -t mangle -I POSTROUTING -o $DEV -j MYSHAPER-OUT

# a fwmark ertekek  beallitasa a kulonbozo  tipusu forgalomhoz - a  fwmark-ot 2
0-26
# kozottire allitjuk a kivant osztalynak megfeleloen. A 20 a legmagasabb priori
tas.

iptables -t mangle -A MYSHAPER-OUT -p tcp --sport 0:1024 -j MARK --set-mark 23
# Alapertek az
# alacsony portokon zajlo forgalomhoz
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 0:1024 -j MARK --set-mark 23
# ""
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 20 -j MARK --set-mark 26
# ftp-data port, alacsony prioritas
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport 5190 -j MARK --set-mark 23
# aol instant messenger
iptables -t mangle -A MYSHAPER-OUT -p icmp -j MARK --set-mark 20
# ICMP (ping) - magas prioritas, baratok ismertetojegye
iptables -t mangle -A MYSHAPER-OUT -p udp -j MARK --set-mark 21
# DNS nevfeloldas (kis csomagok)
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport ssh -j MARK --set-mark 22
# secure shell
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport ssh -j MARK --set-mark 22
# secure shell
iptables -t mangle -A MYSHAPER-OUT -p tcp --dport telnet -j MARK --set-mark 22
# telnet (ew...)
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport telnet -j MARK --set-mark 22
# telnet (ew...)
iptables -t mangle -A MYSHAPER-OUT -p ipv6-crypt -j MARK --set-mark 24
# IPSec - viszont nem tudjuk, mi a "hasznos teher"...
iptables -t mangle -A MYSHAPER-OUT -p tcp --sport http -j MARK --set-mark 25
# helyi webszerver
iptables -t mangle -A MYSHAPER-OUT -p tcp -m length --length :64 -j MARK --set-
mark 21 # kis csomagok (valoszinuleg csak ACK-k)
iptables -t mangle -A MYSHAPER-OUT -m mark --mark 0 -j MARK --set-mark 26
# redundans- jeloljunk minden nem jelolt csomagot 26-tal (alacsony prioritas)

# vegeztunk a kimeno korlatozassal
#
####################################################

echo "Outbound shaping added to $DEV.  Rate: ${RATEUP}Kbit/sec."

# tavolitsd el a megjegyzest a kovetkezo sor elol, ha csak kimeno forgalomszaba
lyozast akarsz
# exit

####################################################
#
# Bejovo korlatozas (a teljes savszelesseg RATEDN-re allitva)

# megnezzuk, hogy az imq modul betoltodott-e

modprobe imq numdevs=1

ip link set imq0 up

# a qdisc hozzadasa - alapertelmezett alcsony prioritasu 1:21-es osztaly

tc qdisc add dev imq0 handle 1: root htb default 21

# a fo korlatozo osztalyok hozzaadasa
tc class add dev imq0 parent 1: classid 1:1 htb rate ${RATEDN}kbit

# alosztalyok hozzaadasa - TCP forgalom a 21-ben, nem-TCP forgalom a 20-ban
#
tc class add dev imq0 parent 1:1 classid 1:20 htb rate $[$RATEDN/2]kbit ceil ${
RATEDN}kbit prio 0
tc class add dev imq0 parent 1:1 classid 1:21 htb rate $[$RATEDN/2]kbit ceil ${
RATEDN}kbit prio 1

# az alosztalyokhoz qdisc-eket  adunk - SFQ-t adunk minden osztalyhoz. Az SFQ
# biztositja, hogy minden osztalyon belul a kapcsolatokat (majdnem) egyenloen
# kezeljuk.

tc qdisc add dev imq0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev imq0 parent 1:21 handle 21: red limit 1000000 min 5000 max 100
000 avpkt 1000 burst 50

# az fwmark-kal  szurjuk osztalyokba  a forgalmat  - itt  a csomagon  beallitot
t
# fwmark-nak megfeleloen iranyitjuk a forgalmat az osztalyokba (az fwmark-ot  a
z
# iptables  segitsegevel  kesobb  allitjuk  be).  Figyeld  meg,  hogy fentebb a
z
# alapertelmezett  prioritasu  osztalyt  1:21-re  allitottuk,  igy  a nem jelol
t
# csomagok (vagy a nem  ismert ID-ju csomagok) alapertelmezesben  az alacsonyab
b
# prioritasu osztalyba kerulnek.


tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 20 fw flowid 1:20
tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 21 fw flowid 1:21


# a MYSHAPER-IN lanc hozzadasa az iptables "mangle" tablajahoz - ez beallitja a
zt a tablat,
#               amit a csomagok szuresehez es megjelolesehez hasznalunk.

iptables -t mangle -N MYSHAPER-IN
iptables -t mangle -I PREROUTING -i $DEV -j MYSHAPER-IN

# a fwmark ertekek beallitasa a kulonbozo tipusu forgalomhoz - a fwmark-ot 20-2
6 kozottire
#               allitjuk a kivant osztalynak megfeleloen. A 20 a legmagasabb pr
ioritas.


iptables -t mangle -A MYSHAPER-IN -p ! tcp -j MARK --set-mark 20              #
 A nem-tcp csomagokat a legnagyobb prioritasura allitja
iptables -t mangle -A MYSHAPER-IN -p tcp -m length --length :64 -j MARK --set-m
ark 20 # rovid TCP csomagok, valoszinuleg ACK-k
iptables -t mangle -A MYSHAPER-IN -p tcp --dport ssh -j MARK --set-mark 20    #
 secure shell
iptables -t mangle -A MYSHAPER-IN -p tcp --sport ssh -j MARK --set-mark 20    #
 secure shell
iptables -t mangle -A MYSHAPER-IN -p tcp --dport telnet -j MARK --set-mark 20 #
 telnet (ew...)
iptables -t mangle -A MYSHAPER-IN -p tcp --sport telnet -j MARK --set-mark 20 #
 telnet (ew...)
iptables -t mangle -A MYSHAPER-IN -m mark --mark 0 -j MARK --set-mark 21
       # redundans- minden nem jelolt csomagot 21-el jelolunk (alacsony priorit
as)

# vegul utasitjuk ezeket a csomagokat, hogy menjenek keresztul a fent beallitot
t imq0-on

iptables -t mangle -A MYSHAPER-IN -j IMQ

# vegeztunk a bejovo forgalommal
#
####################################################

echo "Inbound shaping added to $DEV.  Rate: ${RATEDN}Kbit/sec."
     _________________________________________________________________

5. Az j vrakozsor tesztelse

A legknnyebben azzal tesztelheted az j belltst, hogy telted a felfel
irnyul gat alacsony priorits forgalommal. Ez a prioritsok
belltstl fgg. A plda kedvrt, mondjuk a telnet s a ping forgalmat
helyezted magasabb prioritsba (alacsonyabb fwmark), a tbbi magasabb portot
(amik FTP tvitelhez stb. hasznlatosak) pedig alacsonyabba. Ha indtasz egy
FTP feltltst a kifel men svszlessg teltsre, csak a gateway fel
(a DSL vonal msik feln lv) men ping idk kis mrtk nvekedst
tapasztalhatod, sszehasonltva a prioritsos vrsor nlkli rtkekkel. A
100 ms alatti ping idk tipikusak attl fggen, hogyan lltottad be a
dolgokat. Az egy vagy kt msodpercnl nagyobb idk valsznleg az
jelzik, hogy nem mkdnek rendben a dolgok.
     _________________________________________________________________

6. Rendben, mkdik! Hogyan tovbb?

Most, hogy sikeresen elkezdtl gazdlkodni a svszlessgeddel,
elgondolkodhatsz azon, hogyan hasznlod ki. Vgl is, valsznleg fizetsz
rte!

     * Gnutella kliens hasznlata s FJLJAID MEGOSZTSA a hlzat
       teljestmnynek kedveztlen befolysolsa nlkl.
     * Web szervert futtathatsz anlkl, hogy a weblapok kiszolglsa
       lelasstan a Quake partit.
     _________________________________________________________________

7. Kapcsold hivatkozsok

     * Bandwidth Controller for Windows -
       [37]http://www.bandwidthcontroller.com
     * [38]dsl_qos_queue - (bta) Linuxhoz. Nincs kernel-foltozs, s
       jobb a teljestmny.

References

   1. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#links
   2. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#emaillist
   3. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#intro
   4. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN43
   5. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#emaillist
   6. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN53
   7. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#copyright
   8. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN59
   9. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN63
  10. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#background
  11. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN71
  12. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN93
  13. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN97
  14. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#how-it-works
  15. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN122
  16. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN126
  17. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN133
  18. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN152
  19. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN156
  20. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#implementation
  21. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN168
  22. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#AEN173
  23. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#testing
  24. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#onward
  25. file://localhost/home/dacas/temp/ADSL-Bandwidth-Management-HOWTO-hu.html#links
  26. http://www.tldp.org/
  27. http://www.tldp.org/
  28. http://jared.sonicspike.net/mailman/listinfo/adsl-qos
  29. mailto:dvsing@sonicspike.net
  30. mailto: laca[AT]janus.gimsz.sulinet.hu_NO_SPAM
  31. mailto:dacas[AT]freemail.hu_NO_SPAM
  32. http://tldp.fsf.hu/index.html
  33. http://luxik.cdi.cz/~devik/qos/htb/
  34. http://luxik.cdi.cz/~patrick/imq/
  35. http://www.lartc.org/
  36. http://www.lartc.org/
  37. http://www.bandwidthcontroller.com/
  38. http://www.sonicspike.net/software#dsl_qos_queue
