ADSL s�vsz�less�g-gazd�lkod�s HOGYANDan Singletary
dvsing@sonicspike.net
Verzi�t�rt�net
Verzi�: 1.3 2003.04.07 �tdolgozta: ds
A [1]hivatkoz�sok r�sz hozz�ad�sa.
Verzi�: 1.2 2002.09.26 �tdolgozta: ds
Az �j [2]levelez�list�ra mutat� hivatkoz�s hozz�ad�sa. Hozz�adva egy
kis fejt�r� a fenntartott r�szhez az �j, tov�bbfejlesztett Linux
QoS-hez, amit specifikusan a hamarosan kiadand� ADSL-hez
fejlesztettek.
Verzi�: 1.1 2002.08.26 �tdolgozta: ds
N�h�ny jav�t�s (K�sz�net sokaknak, akik felh�vt�k r�juk a figyelmet!).
Inform�ci�s kik�t�sek hozz�ad�sa a megval�s�t�si r�szhez.
Verzi�: 1.0 2002.08.21 �tdolgozta: ds
Jobb ellen�rz�s a s�vsz�less�g felett, t�bb te�ria, friss�tve a
2.4-es kernelekhez
Verzi�: 0.1 2001.08.06 �tdolgozta: ds
Els� kiad�s
A dokumentum le�rja, hogyan �ll�tsunk be egy Linux �tv�laszt�t, hogy
hathat�sabban kezelje a kimen� forgalmat egy ADSL modemen vagy m�s
olyan eszk�z�n, ami hasonl� s�vsz�less�g-tulajdons�gokkal rendelkezik
(k�belmodem, ISDN stb.). Hangs�lyt fektett�nk az interakt�v forgalom
v�rakoz�si, lappang�si idej�nek cs�kkent�s�re m�g akkor is, ha a
felt�lt�si �s/vagy let�lt�si s�vsz�less�g teljesen tel�tett.
_________________________________________________________________
Tartalomjegyz�k
1. [3]Bevezet�s
1.1. [4]A dokumentum �j verzi�i
1.2. [5]Levelez�lista
1.3. [6]A felel�ss�g teljes elh�r�t�sa
1.4. [7]Szerz�i jog �s licenc
1.5. [8]Visszajelz�sek �s jav�t�sok
1.6. [9]Magyar ford�t�s
2. [10]H�tt�r
2.1. [11]El�zetesen sz�ks�ges dolgok
2.2. [12]Elrendez�s
2.3. [13]Csomagok v�rakoz�sorai
3. [14]Hogyan m�k�dik?
3.1. [15]A HTB alkalmaz�sa a kimen� forgalom visszafog�s�ra
3.2. [16]Priorit�sos v�rakoz�sor kialak�t�sa HTB-vel
3.3. [17]A kimen� csomagok oszt�lyoz�sa iptables-szel
3.4. [18]M�g n�h�ny fog�s...
3.5. [19]Pr�b�lkoz�s a bej�v� forgalom visszafog�s�ra
4. [20]Megval�s�t�s
4.1. [21]Kik�t�sek
4.2. [22]Szkript: myshaper
5. [23]Az �j v�rakoz�sor tesztel�se
6. [24]Rendben, m�k�dik! Hogyan tov�bb?
7. [25]Kapcsol�d� hivatkoz�sok
1. Bevezet�s
Jelen dokumentum c�lja, hogy aj�nljon egy m�dszert egy internethez
kapcsol�d� ADSL (vagy k�bel) modemen kimen� forgalom kezel�s�hez. A
probl�ma az, hogy a legt�bb ADSL vonalat lekorl�tozt�k 128kbs vagy e k�r�li
adatfelt�lt�si sebess�gre. M�g s�lyosabb� teszi a probl�m�t a csomagok
v�rakoz�si sora az ADSL modemen bel�l, ami ha tele van, 2 vagy 3 m�sodpercet
is ig�nybe vesz, m�g ki�r�l. Ez egy�ttesen azt jelenti, hogy amikor a
felt�lt�si s�vsz�less�g teljesen tel�tve van, a t�bbi csomagnak 3
m�sodpercet is ig�nybe vehet, am�g kijutnak az Internetre. Ez megb�n�thatja
az interakt�v alkalmaz�sokat, mint a telnet vagy a t�bbszerepl�s j�t�kok.
_________________________________________________________________
1.1. A dokumentum �j verzi�i
Mindig megtal�lod a jelen dokumentum leg�jabb verzi�j�t a vil�gh�l�n a
[26]http://www.tldp.org webhelyen.
Az �j verzi�k ezen k�v�l k�l�nb�z� Linux WWW �s FTP szerverre is fel vannak
t�ve, bele�rtve az LDP honlapj�t a [27]http://www.tldp.org webhelyen.
_________________________________________________________________
1.2. Levelez�lista
Az ADSL s�vsz�less�g-gazd�lkod�st illet� k�rd�sek �s friss inform�ci�k
vonatkoz�s�ban k�rlek, iratkozz fel a t�ma levelez�si list�j�ra a
[28]http://jared.sonicspike.net/mailman/listinfo/adsl-qos honlapon.
_________________________________________________________________
1.3. A felel�ss�g teljes elh�r�t�sa
Sem a szerz�, sem a terjeszt�k, sem m�s k�zrem�k�d� munkat�rs nem
felel�s semmilyen m�don a fizikai, p�nz�gyi, mor�lis vagy b�rmely m�s
t�pus� k�r�rt, amit a sz�vegben aj�nlott dolgok k�vet�se okozott.
_________________________________________________________________
1.4. Szerz�i jog �s licenc
A jelen dokumentum Dan Singletary (2002) szellemi tulajdona, amelyet a GNU
FDL (GNU Szabad Dokument�ci�s Licenc) alatt adtak ki, amelyet ezennel
hivatkoz�sk�nt beolvasztottunk.
_________________________________________________________________
1.5. Visszajelz�sek �s jav�t�sok
Ha k�rd�seid vagy aj�nl�said vannak a dokumentumhoz kapcsol�d�an, nyugodtan
l�pj kapcsolatba a szerz�vel a [29]dvsing@sonicspike.net e-mail c�men.
_________________________________________________________________
1.6. Magyar ford�t�s
A magyar ford�t�st [30]Sz�jj�rt� L�szl� k�sz�tette (2002.07.28). A
lektor�l�st [31]Daczi L�szl� v�gezte el (2002.09.05). A dokumentum
legfrissebb v�ltozata megtal�lhat� a [32]Magyar Linux Dokument�ci�s Projekt
honlapj�n.
_________________________________________________________________
2. H�tt�r
2.1. El�zetesen sz�ks�ges dolgok
A dokumentumban v�zolt m�dszernek m�k�dnie kell m�s Linux konfigur�ci�kon
bel�l is, de nem tesztelt�k m�son, csak a k�vetkez�k alatt:
* Red Hat Linux 7.3
* 2.4.18-5 Kernel teljes QoS t�mogat�ssal (modulok: OK) �s bele�rtve
a k�vetkez� kernel-foltokat (amik t�rt�netesen az �jabbakban
benne is lehetnek m�r):
+ HTB v�rakoz�sor - [33]http://luxik.cdi.cz/~devik/qos/htb/
Megjegyz�s
jelentett�k, hogy a 2.4.18-3 kernelverzi�t k�vet�en a Mandrake (8.1,
8.2) m�r a HTB-hez adott folttal sz�ll�tja a rendszert.
+ IMQ eszk�z - [34]http://luxik.cdi.cz/~patrick/imq/
* iptables v1.2.6a vagy k�s�bbi (a Red Hat 7.3-mal sz�ll�tott
iptables verzi�b�l hi�nyzik a "length" modul)
Megjegyz�s
a dokumentum el�z� verzi�iban olyan s�vsz�less�g-kezel�si m�dszert
adtunk meg, ami mag�ban foglalta a megl�v� sch_prio v�rakoz�sor
megfoltoz�s�t. K�s�bb �gy tal�ltuk, hogy ez a folt teljesen
felesleges. Ezen fel�l a jelen dokumentumban taglalt m�dszer jobb
eredm�nyt ad (b�r a doksi �r�sa idej�n 2 kernelfolt sz�ks�ges :)
Szerencs�s foltoz�st.)
_________________________________________________________________
2.2. Elrendez�s
A dolgok egyszer�s�t�se �rdek�ben, a dokumentumban az �sszes h�l�zati
eszk�zre �s be�ll�t�sra vonatkoz� hivatkoz�s a k�vetkez� h�l�zati
elrendez�st t�kr�zi:
<-- 128kbit/s -------------- <-- 10Mbit -->
Internet <--------------------> | ADSL modem | <--------------------
1.5Mbit/s --> -------------- |
| eth0
V
----------------------
--------
|
|
| Linux �tv�laszt� (ro
uter) |
|
|
----------------------
--------
| .. | eth1..ethN
| |
V V
Helyi h�l�zat
_________________________________________________________________
2.3. Csomagok v�rakoz�sorai
A csomagok v�rakoz�si sorai (queue) olyan "ed�nyek", amik az adatokat
t�rolj�k a h�l�zati eszk�z sz�m�ra, amikor azokat nem lehet azonnal
elk�ldeni. A legt�bb v�rakoz�sor egy FIFO ("ami els�nek megy be, els�nek
megy ki") fegyelmez�si rendszert, diszcipl�n�t haszn�l (r�viden qdisc - a
ford.), hacsak speci�lisan m�sra nem �ll�tj�k be. Ez azt jelenti, hogy
amikor egy eszk�z v�rakoz�sora teljesen tele van, a v�rakoz�si sorba
utolj�ra ker�lt csomagot csak akkor tov�bb�tja az eszk�z, amikor az �sszes
t�bbit m�r elk�ldte.
_________________________________________________________________
2.3.1. A kimen� �g
ADSL csatlakoz�s eset�n a s�vsz�less�g aszimmetrikus, tipikusan 1.5Mbit/s a
bej�v� �s 128kbit/s a kimen� �g teljes�tm�nye. B�r ez a vonali sebess�g, a
Linux �tv�laszt� PC �s az ADSL modem k�z�tti illeszt� tipikusan 10Mbit/s
vagy a feletti sebess�get tud. Ha a helyi h�l�zat fel� n�z� csatol� szint�n
10Mbit/s sebess�g�, akkor tipikusan NEM LESZ v�rakoz�sor az �tv�laszt�n�l,
amikor a helyi h�l�zat k�ld csomagokat az Internet fel�. Az eth0 eszk�z�n
kereszt�l olyan sebess�ggel mennek ki a csomagok, ahogy a helyi h�l�zatb�l
�rkeztek. Ehelyett viszont a csomagok be�llnak a sorba az ADSL modemn�l,
mivel 10Mbit/s-el �rkeznek, �s csak 128 kbit/s-el mehetnek ki. Id�legesen a
csomagok v�rakoz�sora a modemn�l megtelhet, �s minden tov�bbi csomag, amit
k�ldenek neki, csendben eldob�sra ker�l. A TCP protokollt �gy tervezt�k,
hogy kezelje ezt, �s be fogja �ll�tani a k�ld�si ablak (transmit window)
m�ret�t �gy, hogy teljesen kihaszn�lja a rendelkez�sre �ll� s�vsz�less�get.
Am�g a v�rakoz�sorok a TCP-vel kombin�lva a s�vsz�less�g lehet� legjobb
kihaszn�l�s�t teszik lehet�v�, a nagy FIFO sorok megemelik az interakt�v
forgalom lappang�si idej�t.
Egy m�sik, a FIFO-ra hasonl�t� v�rakoz�sor az n-s�vos priorit�sos sor. Enn�l
ahelyett, hogy csak egy v�rakoz�sort alak�tan�nk ki a bej�v� csomagok
sz�m�ra, az n-s�vos sornak n darab FIFO sora van, amibe a csomagokat az
oszt�lyoz�suk alapj�n helyezz�k be. Minden sornak van egy priorit�sa, �s a
csomagok mindig a legnagyobb priorit�s�, csomagokat tartalmaz� sorb�l j�nnek
ki. Ezt a fegyelmez�si szab�lyt alkalmazva az FTP csomagok egy alacsonyabb
priorit�s� sorba helyezhet�k, mint a telnet csomagjai, �gy m�g egy FTP
felt�lt�s alatt is, egy darab telnet csomag is kijuthat a sorb�l �s azonnal
tov�bbk�ld�sre ker�lhet.
A dokumentumot �talak�tottuk az �j linuxos v�rakoz�sor, a Hierarchical Token
Bucket (HTB) haszn�lat�hoz. A HTB sor nagyban hasonl�t a fent le�rt n-s�vos
sorra, de megvan az a tulajdons�ga, hogy k�pes minden oszt�ly�nak forgalm�t
korl�tozni. Ezen k�v�l k�pes arra, hogy forgalmi oszt�lyokat alak�tson ki
m�s oszt�lyok alatt, egy hierarchikus oszt�lyokb�l �ll� rendszert
l�trehozva. A HTB teljes le�r�sa meghaladja a dokumentum kereteit, de
tov�bbi inform�ci� tal�lhat� a [35]http://www.lartc.org webhelyen.
_________________________________________________________________
2.3.2. A bej�v� �g
Az ADSL modembe befel� �rkez� forgalom a kimen�h�z hasonl� m�don �ll
v�rakoz�sorba, azonban a sor a szolg�ltat�dn�l helyezkedik el. Emiatt
val�sz�n�leg nincs k�zvetlen befoly�sod arra, hogyan �lljanak sorba a
csomagok vagy melyik fajta forgalom kapjon megk�l�nb�ztetett kezel�st. Az
egyetlen m�d a v�rakoz�si id� alacsonyan tart�s�ra itt az, hogy
megbizonyosodsz, miszerint nem k�ldik az adatokat t�l gyorsan sz�modra.
Sajnos nincs m�d az �rkez� csomagok sebess�g�nek k�zvetlen befoly�sol�s�ra,
de mivel a forgalmaz�s t�bbs�ge val�sz�n�leg TCP, van n�h�ny m�dja a
k�ld�k lelass�t�s�nak:
* Sz�nd�kosan eldobni a bej�v� csomagokat - a TCP protokollt �gy
tervezt�k, hogy kihaszn�lja a rendelkez�sre �ll� teljes
s�vsz�less�get, mik�zben pr�b�lja elker�lni a kapcsolaton bel�l a
torl�d�st. Ez azt jelenti, hogy nagy mennyis�g� adat k�ld�sekor a
TCP t�bb �s t�bb adatot k�ld, am�g v�g�l is egy csomag eldob�sra
ker�l. A TCP �rz�keli ezt, �s cs�kkenti az �tviteli ablak m�ret�t.
Ez a folyamat ism�tl�dik a kapcsolat alatt, �gy biztos�tja az
adatok lehet� leggyorsabb �tvitel�t.
* A meghirdetett v�teli ablak manipul�l�sa - A TCP forgalmaz�s alatt
a fogad� oldal az ACK (elfogad�s) csomagok folyamatos sor�t k�ldi
vissza. Az ACK csomagokban tal�lhat� az ablakm�ret meghirdet�se,
ami kifejezi annak a nem elfogadott adatnak a mennyis�g�t, amit a
fogad� k�ldeni tud. A kimen� ACK csomagok ablakm�ret�nek
babr�l�s�val sz�nd�kosan lelass�thatjuk a k�ld�t. Ennek a
folyamatszab�lyoz�snak jelen pillanatban nincs (szabadon
el�rhet�) megval�s�t�sa Linuxon (de lehet, hogy dolgozom egyen!)
_________________________________________________________________
3. Hogyan m�k�dik?
K�t alapvet� l�p�ssel optimaliz�lhatjuk a kifel� men� s�vsz�less�get.
El�sz�r tal�lnunk kell egy m�dot arra, hogy megakad�lyozzuk az ADSL modemet
a csomagok sorba �ll�t�s�ban, mivel nincs r�hat�sunk a v�rakoz�sor
kezel�s�re. Ennek �rdek�ben visszafogjuk az �tv�laszt� �ltal az eth0-n
kik�ld�tt adat mennyis�g�t, kicsit kevesebbre, mint a modem teljes kimen�
s�vsz�less�ge. Ez azt eredm�nyezi, hogy az �tv�laszt� rakja v�rakoz�sorba a
helyi h�l�zatr�l �rkez� csomagokat, amik gyorsabban �rkeznek, mint
megengedett kik�ld�s�k.
A m�sodik l�p�s egy priorit�sos v�rakoz�sor-fegyelmi szab�ly fel�ll�t�sa az
�tv�laszt�n. Meg fogunk val�s�tani egy olyan sort, amit be lehet �ll�tani
�gy, hogy els�bbs�get adjon az interakt�v forgalomnak, mint a telnet vagy a
t�bbszerepl�s j�t�kok.
A HTB v�rakoz�sor haszn�lat�val meg tudjuk val�s�tani a s�vsz�less�g
korl�toz�s�t �s priorit�sos v�rakoz�sort, egyidej�leg meggy�z�d�nk,
hogy nincs olyan oszt�ly, amit egy m�sik "ki�heztetne". A ki�heztet�s
elker�l�se �rdek�ben nem v�laszthat� a dokumentum 0.1-es jav�t�s�n�l
megadott m�dszer.
A v�gs� l�p�s a t�zfal be�ll�t�sa, hogy az fwmark seg�ts�g�vel
biztos�tsa a csomagok els�bbs�g�t.
_________________________________________________________________
3.1. A HTB alkalmaz�sa a kimen� forgalom visszafog�s�ra
B�r az �tv�laszt� �s a modem k�zti kapcsolat 10 Mbit/s sebess�g�, a modem
csak 128 kbit/s sebess�ggel tud adatokat k�ldeni. Minden ezt a r�t�t
meghalad� sebess�g� csomag v�rakoz�sorba �ll a modemn�l. Ez�rt egy ping
csomag, amit az �tv�laszt�r�l k�ld�nk, azonnal elmehet a modemhez, de n�h�ny
m�sodpercet vehet ig�nybe, am�g t�nylegesen kiker�l az Internetre, ha a
modem v�rakoz�sora tartalmaz m�r valamennyi csomagot. Sajnos a legt�bb ADSL
modem eset�ben nem adhatjuk meg a v�rakoz�sor kezel�s�nek m�dj�t illetve
annak nagys�g�t. �gy el�sz�r a kimen� csomagokat �tir�ny�tjuk oda, ahol
mindezt megtehetj�k.
Ezt a HTB sorral val�s�tjuk meg, �gy cs�kkentve az ADSL modemhez k�ld�tt
csomagok sz�m�t. M�g ha a kifel� men� s�vsz�less�g�nk a 128kbit/s is
lehetne, kicsivel ez al� korl�tozzuk le a csomagk�ld�s m�rt�k�t. Ha
cs�kkenteni akarjuk a lappang�si id�t, BIZONYOSNAK kell lenn�nk, hogy soha
egyetlen csomag sem �ll sorba a modemn�l. K�s�rletez�sek sor�n azt tal�ltam,
hogy a kimen� forgalom k�r�lbel�l 90kbit/s-ra val� visszav�tel�vel a
s�vsz�less�g majdnem 95%-�t tudom el�rni a HTB vez�rl�s n�lk�l. A HTB
enged�lyez�s�vel enn�l a m�rt�kn�l kiv�dj�k, hogy a modem v�rakoz�sorba
rakja a csomagokat.
_________________________________________________________________
3.2. Priorit�sos v�rakoz�sor kialak�t�sa HTB-vel
Megjegyz�s
Megjegyz�s: az ebben a r�szben l�v� el�z� ig�nyek (eredetileg
N-s�vos priorit�sos v�rakoz�sor kialak�t�s�nak h�vt�k) k�s�bb
hib�snak tal�ltattak. LEHETETLEN volt a v�rakoz�sor k�l�nb�z�
s�vjaiba tartoz� csomagok megjel�l�se csak a fwmark mez� �ltal,
viszont ezt gyeng�n dokument�ltuk a dokumentum 0.1-es verzi�j�nak
�r�sakor.
Enn�l a pontn�l m�g nem vesz�nk �szre semmi v�ltoz�st a
teljes�tm�nyben. Puszt�n csak �thelyezz�k a FIFO sort az ADSL
modemt�l az �tv�laszt�hoz. Val�j�ban, a Linux alap�rtelmez�sben
be�ll�tott 100 csomag m�ret� FIFO sor�val, val�sz�n�leg m�g
rosszabb� is tett�k a helyzet�nket! De nem sok�ig...
Minden szomsz�dos oszt�lynak adhatunk egy priorit�st a HTB soron
bel�l. A k�l�nb�z� t�pus� forgalom k�l�nb�z� oszt�lyokba
helyez�s�vel, majd ezen oszt�lyokhoz k�l�nb�z� priorit�sok
csatol�s�val, vez�relhetj�k a csomagok v�rakoz�si sorb�l val�
kiv�tel�t �s elk�ld�s�t. A HTB lehet�v� teszi ezt, mik�zben
megakad�lyozza egy oszt�ly "ki�heztet�s�t", mivel megadhatjuk a
minim�lisan garant�lt m�rt�ket minden oszt�ly sz�m�ra. Ezenfel�l a HTB
megengedi azt is, hogy megadjuk egy oszt�lynak: haszn�lhatja m�sik
oszt�lyok nem haszn�lt s�vsz�less�g�t, egy bizonyos fels� hat�rig.
Miut�n be�ll�tottuk az oszt�lyainkat, sz�r�ket helyez�nk el, hogy a
forgalmat elhelyezz�k bel�j�k. T�bb �tja is van ennek, de az itt le�rt
m�dszer az ismer�s iptables/ipchains-t haszn�lja a csomagok fwmark-al
(t�zfal jel�l�se a csomagon) t�rt�n� megjel�l�s�re. A sz�r�k a
csomagok fwmark-j�t figyelembe v�ve helyezik el a forgalmat a HTB sor
oszt�lyaiba. Ezen a m�don k�pesek lesz�nk megfelel� szab�lyok
fel�ll�t�s�ra az iptables-en bel�l, hogy bizonyos t�pus� forgalmat egy
bizonyos oszt�lyba k�ldj�n.
_________________________________________________________________
3.3. A kimen� csomagok oszt�lyoz�sa iptables-szel
Megjegyz�s
eredetileg a dokumentumban az ipchains-t haszn�ltuk a csomagok
besorol�s�ra. Most az �jabb iptables-t haszn�ljuk.
Az utols� l�p�s ahhoz, hogy az �tv�laszt� els�bbs�get adjon az
interakt�v forgalomnak - a t�zfal be�ll�t�sa: adjuk meg a forgalom
besorol�s�nak m�dj�t. Ez a csomag fwmark mez�j�nek be�ll�t�s�val
�rhet� el.
An�lk�l, hogy t�lzottan a r�szletekbe mer�ln�nk, �lljon itt az
egyszer�s�tett le�r�sa annak, hogyan lehet a kimen� csomagokat 4
oszt�lyba sorolni �gy, hogy a legmagasabb priorit�s� lesz a 0x00:
1. Jel�lj�nk MINDEN csomagot 0x03-al. Ez alap�rtelmez�sben minden
csomagot a legalacsonyabb priorit�s� sorba helyez el.
2. Jel�lj�k az ICMP csomagokat 0x00-al. Szeretn�nk, ha a ping mutatn�
a legmagasabb priorit�s� csomagok v�rakoz�si idej�t.
3. Jel�lj�nk minden csomagot, aminek c�lportja 1024 vagy kisebb,
0x01-el. Ez els�bbs�get biztos�t az olyan
rendszerszolg�ltat�soknak, mint a Telnet �s SSH. Az FTP portja
szint�n ebbe a k�rbe esik, de az FTP adatforgalom a magasabb
portokon helyezkedik el �s marad a 0x03 s�vban.
4. Jel�lj�nk minden csomagot, aminek a c�lportja 25 (SMTP), a
0x03-al. Ha valaki levelet fog k�ldeni egy nagy csatolt
�llom�nnyal, nem akarjuk, hogy el�rassza az interakt�v forgalmat.
5. Jel�lj�nk minden csomagot, aminek c�lja egy t�bbszerepl�s
j�t�k-szerver, 0x02-vel. Ez a j�t�kosoknak alacsony lappang�si
id�t biztos�t, de megakad�lyozza, hogy elfoglalj�k az alacsony
v�rakoz�st ig�nyl� rendszerszolg�ltat�sokat.
Jel�lj�nk minden "kicsi" csomagot 0x02-vel. A kimen� ACK
csomagokat a befel� ir�nyul� let�lt�sekb�l azonnal ki kell
k�lden�nk, hogy biztos�tsuk a megfelel� let�lt�seket. Ez az
iptables "length" modulj�val lehets�ges.
Term�szetesen ezeket a k�v�nalmaknak megfelel�en �talak�thatod.
_________________________________________________________________
3.4. M�g n�h�ny fog�s...
K�t tov�bbi dolgot tehetsz a lappang�si id� jav�t�s�ra. El�sz�r is, a
maxim�lis �tvihet� egys�g (MTU) m�ret�t kisebbre veheted, mint az
alap�rtelmezett 1500 b�jt. Ennek a sz�mnak a cs�kkent�se egyben az �tlagos
id�t is cs�kkenti, amit az els�bbs�get �lvez� csomagok elk�ld�s�re kell
ford�tani, ha m�r egy teljes m�ret� alacsony priorit�s� csomag k�ld�se
folyamatban van. Ennek az �rt�knek a cs�kkent�se kicsit cs�kkenti a
teljes�tm�nyt is, mivel minden csomag legal�bb 40 b�jtnyi IP �s TCP
fejl�c-inform�ci�t tartalmaz.
A m�sik dolog a jav�t�shoz, m�g alacsony priorit�s� forgalom eset�n is, hogy
cs�kkented a v�rakoz�si sor m�ret�t az alap�rtelmezett 100-r�l, ami egy ADSL
vonalon 10 m�sodperc alatt �r�l ki egy 1500 b�jtos MTU-t alapul v�ve.
_________________________________________________________________
3.5. Pr�b�lkoz�s a bej�v� forgalom visszafog�s�ra
A "k�zbens� v�rakoz�sor-eszk�z" (Intermediate Queuing Device, IMQ)
haszn�lat�val az �sszes bej�v� csomagot ugyan�gy egy v�rakoz�soron
futtathatjuk �t, mint amilyen m�don a kimen�ket is. A csomagok priorit�sa
ebben az esetben j�val egyszer�bb. Mivel csak a bej�v� TCP forgalmat
(pr�b�ljuk meg) vez�relni, az �sszes nem-TCP forgalmat a 0x00 oszt�lyba
rakjuk, az �sszes TCP forgalmat pedig a 0x01 oszt�lyba. A "kis" TCP
csomagokat szint�n a 0x00 oszt�lyba soroljuk, mert ezek nagy
val�sz�n�s�ggel a m�r elk�ld�tt kimen� adatok ACK csomagjai. Egy standard
FIFO sort �ll�tunk be a 0x00 oszt�lyhoz, illetve egy "v�letlenszer� korai
eldob�s" (Random Early Drop, RED) v�r�sort a 0x01 oszt�lyhoz. A RED jobb a
FIFO-n�l a TCP vez�rl�s�t tekintve, mert eldobja a csomagokat m�r a sor
olyan t�lcsordul�sa el�tt, mikor megpr�b�lja lelass�tani a forgalmat az
ellen�rz�s fenntart�sa �rdek�ben. Ezen k�v�l mindk�t oszt�lyt le fogjuk
korl�tozni egy maxim�lis bej�v� forgalmi hat�rra, ami kisebb, mint a val�s,
ADSL modemen bej�v� sebess�g.
_________________________________________________________________
3.5.1. Mi�rt nem olyan j� a bej�v� forgalom korl�toz�sa?
Korl�tozni szeretn�nk a bej�v� forgalmunkat, hogy elker�lj�k a v�rakoz�sor
betel�s�t a szolg�ltat�n�l, ami n�ha 5 m�sodpernyi adat pufferel�s�t
jelentheti. A probl�ma abban �ll, hogy jelenleg a bej�v� TCP forgalom
korl�toz�s�nak egyetlen m�dja a teljesen j� csomagok eldob�l�sa. Ezek a
csomagok m�r foglaltak n�mi s�vsz�less�get az ADSL modemen, csak a Linux g�p
dobta el �ket abb�l a c�lb�l, hogy a j�v�beni csomagokat lelass�tsa. Ezek
az eldobott csomagok id�nk�nt �jra elk�ld�sre ker�lnek, m�g t�bb
s�vsz�less�get foglalva. Amikor korl�tozzuk a forgalmat, korl�tozzuk azon
csomagok m�rt�k�t, amiket elfogadunk a h�l�zatunk sz�m�ra. Mivel az aktu�lis
bej�v� adatr�ta valahol ef�l�tt van az eldobott csomagok miatt, a bej�v�
�gunkat sokkal jobban le kell korl�toznunk az ADSL modem aktu�lis r�t�j�n�l,
az alacsony lappang�si id� biztos�t�sa �rdek�ben. A gyakorlatban az �n
1.5Mbit/s bej�v� �gamat 700kbit/s-re kellett korl�toznom, hogy elfogadhat�
szinten tartsam a lappang�st 5 egyidej� let�lt�sn�l. Min�l t�bb TCP
folyamatod van, ann�l t�bb s�vsz�less�get vesztesz az eldobott csomagok
miatt, �s ann�l kisebbre kell venned a korl�toz�s m�rt�k�t.
A bej�v� TCP forgalom ellen�rz�s�nek sokkal jobb m�dja a TCP ablak
manipul�ci�ja, de ebben a pillanatban nincs (szabadon el�rhet�)
megval�s�t�sa ennek Linuxra (amennyire �n tudom...).
_________________________________________________________________
4. Megval�s�t�s
Mindezen okfejt�s ut�n most m�r ideje, hogy megval�s�tsuk a
s�vsz�less�g-gazd�lkod�st Linuxon.
_________________________________________________________________
4.1. Kik�t�sek
A DSL modemhez aktu�lisan k�ld�tt adatok m�rt�k�nek korl�toz�sa nem olyan
egyszer�, mint amilyennek l�tszik. A legt�bb DSL modem igaz�b�l csak egy
ethernet h�d, amik tov�bb�tj�k az adatokat oda-vissza a Linux g�p �s a
szolg�ltat�n�l l�v� gateway k�z�tt. A legt�bb DSL modem ATM-et haszn�l
adat�tviteli csatol�fel�letk�nt. Az ATM mindig 53 b�jtos cell�kban k�ldi az
adatokat. Ezekb�l 5 b�jt a fejl�c inform�ci�, �s 48 b�jt marad az
adatoknak. M�g ha csak 1 b�jt adatot k�ldesz is, a teljes 53 b�jt
s�vsz�less�get foglal, mivel az ATM cell�k mindig 53 b�jt hossz�ak. Ez azt
jelenti, hogy ha egy tipikus TCP ACK csomagot k�ldesz, ami 0 b�jt adatot +
20 b�jt TCP fejl�cet + 20 b�jt IP fejl�cet + 18 b�jt Ethernet fejl�cet
tartalmaz. Val�j�ban, m�g ha a kik�ld�tt ethernet csomagnak csak 40 b�jtnyi
"hasznos terhe" van is (TCP �s IP fejl�c), a legkisebb m�ret egy Ethernet
csomagn�l 46 b�jtnyi adat, �gy a marad�k 6 b�jt 0-val t�lt�dik ki. Ez azt
jelenti, hogy az Ethernet csomag plusz a fejl�c inform�ci�k aktu�lis hossza
18 + 46 = 64 b�jt. Az ATM-mel 64 b�jt �tk�ld�s�hez k�t ATM cell�t kell
k�ldened, ami 106 b�jt s�vsz�less�get foglal. Vagyis minden TCP ACK
csomagn�l 42 b�jt s�vsz�less�get vesztesz. Ez rendben van, ha a Linux
figyelembe veszi a DSL modem �ltal haszn�lt csomag-be�gyaz�st, de ehelyett a
Linux csak a TCP �s IP fejl�cet �s 14 b�jtos MAC c�met jegyzi (a Linux nem
sz�molja a 4 b�jtos CRC-t, mivel ezt a hardver szint kezeli). A Linux nem
sz�mol a 46 b�jtos minim�lis Ethernet csomagm�rettel, sem a fix m�ret� ATM
cell�val.
Mindez azt jelenti, hogy a kimen� s�vsz�less�get valamivel kisebbre kell
�ll�tani, mint a val�s kapacit�s (am�g nem tal�lunk egy csomag-id�z�t�t,
ami jegyzi a k�l�nb�z� t�pus� csomag-be�gyaz�sokat). Azt tal�lhatod, hogy
siker�lt egy j� �rt�kre be�ll�tani a s�vsz�less�get, de amikor egy nagy
f�jlt t�ltesz le, a lappang�s felsz�kik 3 m�sodperc f�l�. Ez
legval�sz�n�bben amiatt van, mivel a Linux rosszul sz�m�tja ki a bizonyos
kis ACK csomagok �ltal ig�nyelt s�vsz�less�get.
N�h�ny h�napot dolgoztam ennek a probl�m�nak a megold�s�n, �s majdnem
lez�rtam a dolgot egy olyan megold�ssal, amit hamarosan k�zreadok tov�bbi
tesztel�sre. A megold�s egy felhaszn�l�i szint� v�rakoz�sor haszn�lat�t
mutatja be a Linux QoS-e helyett a csomagok korl�toz�s�ra. Alapvet�en egy
egyszer� HTB sort alkalmaztam, ami a Linux felhaszn�l�i szint� sorait
haszn�lja. Ez a megold�s (eddig) k�pes volt a kimen� forgalom OLYAN J�
korl�toz�s�ra, hogy m�g egy massz�v let�lt�s (t�bb sz�lon) �s ugyanilyen
felt�lt�s (gnutella, t�bb sz�lon) alatt is, a lappang�s 400 ms CS�CS�RT�KET
�rt csak el a n�vleges, forgalom n�lk�li 15 ms-hoz k�pest. Tov�bbi
inform�ci��rt err�l a QoS m�dszerr�l, iratkozz fel a friss�t�sek
levelez�list�j�ra vagy k�s�bb n�zd meg ennek a HOGYANnak a frissebb
v�ltozatait.
_________________________________________________________________
4.2. Szkript: myshaper
A k�vetkez�kben egy �ltalam a Linux �tv�laszt�n a s�vsz�less�g
korl�toz�s�ra haszn�lt szkript list�ja tal�lhat�. Ez t�bb, a dokumentumban
foglalt koncepci�t is felhaszn�l. A kimen� forgalom a 7 t�pust�l f�gg�
v�r�sor egyik�be ker�l. A bej�v� forgalom k�t sorba ker�l, a TCP csomagokat
(alacsonyabb priorit�s�ak) el�bb eldobjuk, ha a bej�v� adatok a m�rt�k
f�l�ttiek. A szkriptben megadott r�t�k �gy t�nik, j�l m�k�dnek az �n
be�ll�t�somban, de az eredm�nyek v�ltozhatnak.
A szkript eredetileg az ADSL WonderShaper-en alapult, amint
megtal�lhat� 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-teljes�tmenyt 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 p�ld�ul 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 v�rakoz�sor tesztel�se
A legk�nnyebben azzal tesztelheted az �j be�ll�t�st, hogy tel�ted a felfel�
ir�nyul� �gat alacsony priorit�s� forgalommal. Ez a priorit�sok
be�ll�t�s�t�l f�gg. A p�lda kedv��rt, mondjuk a telnet �s a ping forgalmat
helyezted magasabb priorit�sba (alacsonyabb fwmark), a t�bbi magasabb portot
(amik FTP �tvitelhez stb. haszn�latosak) pedig alacsonyabba. Ha ind�tasz egy
FTP felt�lt�st a kifel� men� s�vsz�less�g tel�t�s�re, csak a gateway fel�
(a DSL vonal m�sik fel�n l�v�) men� ping id�k kis m�rt�k� n�veked�s�t
tapasztalhatod, �sszehasonl�tva a priorit�sos v�r�sor n�lk�li �rt�kekkel. A
100 ms alatti ping id�k tipikusak att�l f�gg�en, hogyan �ll�tottad be a
dolgokat. Az egy vagy k�t m�sodpercn�l nagyobb id�k val�sz�n�leg az
jelzik, hogy nem m�k�dnek rendben a dolgok.
_________________________________________________________________
6. Rendben, m�k�dik! Hogyan tov�bb?
Most, hogy sikeresen elkezdt�l gazd�lkodni a s�vsz�less�geddel,
elgondolkodhatsz azon, hogyan haszn�lod ki. V�g�l is, val�sz�n�leg fizetsz
�rte!
* Gnutella kliens haszn�lata �s F�JLJAID MEGOSZT�SA a h�l�zat
teljes�tm�ny�nek kedvez�tlen befoly�sol�sa n�lk�l.
* Web szervert futtathatsz an�lk�l, hogy a weblapok kiszolg�l�sa
lelass�tan� a Quake partit.
_________________________________________________________________
7. Kapcsol�d� hivatkoz�sok
* Bandwidth Controller for Windows -
[37]http://www.bandwidthcontroller.com
* [38]dsl_qos_queue - (b�ta) Linuxhoz. Nincs kernel-foltoz�s, �s
jobb a teljes�tm�ny.
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