Ruter - Linux 2.4
Ruter - Linux 2.4
Ruter - Linux 2.4
Ruter - Linux 2.4
FI REWALL, KONTROLA PRZEPA
YWU, ZL I CZANI E RUCHU
wersja dokumentu 0.9
Dubas Bartłomiej (dubcio@hoga.pl)
AGH Kraków - Informatyka IV  Administracja Systemami Komputerowymi
2002
O PRAWACH AUTORSKICH
Niniejsze opracowanie powstało w głównej mierze w oparciu o materiał
 Kształtowanie Ruchu i Zaawansowany Ruting HOWTO w tłumaczeniu A
ukasza
Bromirskiego. Wykorzystano również inne dokumenty i opracowania o czym mowa
jest w Bibliografi na końcu tego opracowania. Nie jest zabronione rozpowszechnianie
tego dokumentu, z wyłączeniem sytuacji, w których naruszało by to w jakikolwiek
sposób prawa autorskie opracowań z
ródłowych. Zabronione jest również czerpanie
jakichkolwiek korzyści majątkowych z tytułu rozpowszechniania niniejszego
opracowania.
Grafika wykorzystana w dokumencie pochodzi ze strony www.wiretree.com.
Bartłomiej Dubas
Spis Treści
Spis Treści .................................................................................................................................1
Tytułem Wstępu........................................................................................................................4
IP i TC - nowe narzędzie konfiguracji....................................................................................5
Narzędzie IP ...........................................................................................................................5
Narzędzie TC..........................................................................................................................6
Dyscypliny kolejkowania  qdisc.......................................................................................6
Klasy  class .......................................................................................................................7
Terminologia .............................................................................................................................8
Dyscypliny kolejkowania .......................................................................................................10
Proste, bezklasowe dyscypliny kolejkowania ......................................................................10
Kolejka pfifo_fast.............................................................................................................10
Parametry kolejki..........................................................................................................10
Opis pola ToS ...............................................................................................................11
TBF  Tocken Bucket Filter.............................................................................................11
Parametry kolejki..........................................................................................................12
Przykładowa konfiguracja ............................................................................................12
SFQ  Stochastic Fairness Queueing ...............................................................................13
Parametry kolejki..........................................................................................................13
Dyscypliny kolejkowania z klasami .....................................................................................14
HTB  Hierarchical Token Bucket...................................................................................15
Dzielenie połączenia.....................................................................................................16
Wypożyczanie pasma ...................................................................................................16
Opróżnianie kolejki ......................................................................................................17
Priorytety ruchu ............................................................................................................17
Parametry kolejki..........................................................................................................17
Kolejka PRIO ...................................................................................................................17
Parametry kolejki..........................................................................................................18
1
Przykłady użycia...........................................................................................................18
CBQ  Class Based Queue ...............................................................................................19
Kolejka ruchu przychodzącego ............................................................................................19
Klasyfikowanie pakietów filtrami .........................................................................................21
Filtry i klasyfikowanie pakietów ..........................................................................................21
Najczęściej używane filtry................................................................................................22
Testy na adresach z
ródłowym i docelowym.................................................................22
Testy na portach z
ródłowym i docelowym...................................................................22
Testy na protokół (tcp, udp, icmp, gre, ipsec) ..............................................................22
Testy na znacznik (fwmark) .........................................................................................22
Testy na polu ToS.........................................................................................................22
Przygotowanie serwera ..........................................................................................................23
Kompilacja i instalacja jądra ................................................................................................23
Przygotowanie z
ródeł .......................................................................................................23
Uzupełnienie jądra obsługą kolejki HTB .....................................................................24
Konfiguracja jądra ............................................................................................................24
Kompilacja .......................................................................................................................26
Instalacja...........................................................................................................................26
Instalacja iproute2.................................................................................................................27
Jądro 2.2.x.............................................................................................................................27
Opis zadań...............................................................................................................................28
Jedna podsieć, łącze radiowe (serwer 1) ..............................................................................28
Dwie podsieci, łącze szeregowe (serwer 2)..........................................................................28
Konfiguracje serwerów ..........................................................................................................29
Konfiguracja firewall a.........................................................................................................29
Mechanizm kontroli użytkowników.....................................................................................30
Statystyki ..............................................................................................................................31
Zliczanie ruchu IP.............................................................................................................31
Statystyki klas...................................................................................................................32
2
Serwer 1................................................................................................................................33
Konfiguracja kolejek ........................................................................................................34
Serwer 2................................................................................................................................34
Konfiguracja kolejek ........................................................................................................35
Interfejs ppp0................................................................................................................35
Interfejs eth1 i eth0 .......................................................................................................36
Zawartość CD .........................................................................................................................37
Bibliografia..............................................................................................................................38
Podstawowe materiały..........................................................................................................38
Materiały pomocnicze ..........................................................................................................38
3
Tytułem Wstępu
W ostatnim czasie znaczącą role w sieciach IP zaczęła odgrywać kontrola jakości usług. Aż
do jądra Linuks a oznaczonego numerem 2.2 system ten nie gwarantował jakość przepływu.
Alexey Kuznetsov przepisał znaczną część kodu jądra Linux a zajmującą się rutowaniem i
kontrolą ruchu. Napisał również programy narzędziowe pozwalające na ustawianie
parametrów rutingu w jądrze (ip), jak również pozwalające na sterowanie przepływem (tc),
które pozwala na zarządzanie jakością usługi (ang. guality of serwice - QoS).
W niniejszym dokumencie zostało przedstawione zagadnienia związane z tematem QoS, jak
również przedstawiono przykłady wykorzystania nowych narzędzi, w oparciu o serwery w
sieciach osiedlowych.
Przy użyciu kolejkowania określamy, które dane są wysyłane. Ważne jest, aby zrozumieć, że
możemy jedynie kontrolować dane, które wysyłamy. Z uwagi na budowę sieci IP, nie mamy
bezpośredniej kontroli nad tym, co jest wysyłane do nas. TCP/IP nie zna przepustowości sieci
pomiędzy dwoma komputerami, zaczyna więc od wysyłania danych za małą prędkością, a
następnie szybciej i szybciej i kiedy zaczyna gubić pakiety, ponieważ nie ma już dla nich
pasma, zwalnia (mechanizm ten nazwa się wolnym startem).
Jeśli posiadamy ruter i chcemy zapobiec sytuacji, w której określone komputery ściągają dane
za szybko, musimy wprowadzić ograniczenia na wewnętrznym interfejsie rutera tego, który
wysyła dane do tych komputerów.
4
IP i TC - nowe narzędzie konfiguracji
Jak już wcześniej wspomniano wraz z iproute2 otrzymujemy nowe narzędzie konfiguracji
interfejsów sieciowych i tras rutowania.
Narzędzie IP
Aby ustawić interfejs sieciowy a następnie umieścić go w tablicy rutingu należało wykonać
sekwencję komend:
#ifconfig eth0 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255
#route add  net 192.168.1.0 netmask 255.255.255.0
#route add default gw 192.168.1.1
przy użyciu ip to samo zadanie wykonujemy:
#ip address add 192.168.1.10/24 broadcast 192.168.1.255 dev eth0
#ip link set dev eth0 up
#ip route add default via 192.168.1.1
Podgląd aktualnego stanu aktywnych interfejsów przy użyciu ifconfig wygląda następująco:
#ifconfig
eth0 Link encap:Ethernet HWaddr 00:50:DA:E3:52:77
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6556978 errors:1 dropped:0 overruns:44 frame:1
TX packets:5613800 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2755421382 (2627.7 Mb) TX bytes:1765035412 (1683.2 Mb)
Interrupt:6 Base address:0xd800
natomiast przy użyciu ip:
#ip address show
2: eth0: mtu 1500 qdisc pfifo
link/ether 00:50:da:e3:52:77 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
Podgląd tablicy routingu wykonujemy poprzez:
#route  n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 1 0 0 eth0
a poprzez ip:
#ip route show
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10
default via 192.168.1.1 dev eth0 metric 1
Podgląd tablicy translacji adresów MAC na adresy IP wykonujemy:
#arp -a  n
5
Address HWtype HWaddress Flags Mask Iface
192.168.1.1 ether 00:50:BA:F2:82:1C C eth0
192.168.1.12 ether 00:80:AD:40:67:F8 C eth0
192.168.1.34 ether 00:E0:7D:9F:11:F4 C eth0
...
przy użyciu ip:
#ip neighbour show
192.168.1.1 dev eth1 lladdr 00:50:ba:f2:82:1c nud delay
192.168.1.12 dev eth1 lladdr 00:80:ad:40:67:f8 nud delay
192.168.1.34 dev eth1 lladdr 00:e0:7d:9f:11:f4 nud delay
...
Uwaga: Szczegółowy opis polecenia ip znajduje się w dokumencie  IP Command
Reference , autorstwa Alexey a N. Kuznetsov a, zawitego na dołączonym CD.
Narzędzie TC
Nazwa narzędzia pochodzi od angielskiego określenia na Kontrolę Ruchu (ang. Traffic
Control). Jej zadaniem definiowanie kolejek, klas i filtrów opisanych dalszych rozdziałach
tego dokumentu, a ponieważ jest to podstawowe zagadnienie niniejszego opracowania
składnia polecenia tc zostanie opisana stosunkowo dokładnie.
Składnia polecenia tc wygląda następująco:
#tc [ OPTIONS ] OBJECT { COMMAND | help }
gdzie:
" OBJECT := { qdisc | class | filter }  określa czy polecenie dotyczy odpowiednio
kolejki z dyscypliną, klasy czy filtru,
" OPTIONS := { -s[statistics] | -d[details] | -r[raw] }  określa dodatkowe opcje
polecenia,
" COMMAND := {add | del | ls | ...}  określa jaka komenda ma być wykonana na
OBJECT.
W poniższych sekcjach opisano skrótowy opis składni komendy tc dla obiektów qdisc i
klass. Opis składni dla obiektu filter znajduje się w rozdziale dotyczącym filtrów.
Dyscypliny kolejkowania  qdisc
Podstawowa składnia polecenia definiującego dyscyplinę kolejkowania przedstawia się
następująco:
#tc qdisc [ add | del | replace | change | get ] dev STRING
> [ handle QHANDLE ] [ root | parent CLASSID ]
> [ [ QDISC_KIND ] [ help | OPTIONS ] ]
#tc qdisc show [ dev STRING ]
gdzie
6
" STRING  jest nazwą urządzenia,
" QDISC_KIND  określa rodzaj dyscypliny (nazwę kolejki),
" QHANDLE  określa uchwyt kolejki,
" CLASSID - definiuje rodzica kolejki, w przypadku gdy kolejka nie jest korzeniem root,
" OPTIONS  w dużej mierze zależy od typu kolejki.
Drugie polecenie pozwala na pokazanie aktualnie zdefiniowanych kolejek.
Klasy  class
Podstawowa składnia polecenia definiująca klasy wygląda następująco:
#tc class [ add | del | change | get ] dev STRING
> [ classid CHANDLE] [ root | parent CLASSID ]
> [ [ QDISC_KIND ] [ help | OPTIONS ] ]
#tc class show [ dev STRING ] [ root | parent CLASSID ]
gdzie poszczególne parametry pełnia identyczną funkcje jak w przypadku dyscyplin
kolejkowania, natomiast parametr:
" CHANDLE  określa uchwyt klasy.
Drugie polecenie pozwala wylistować zdefiniowane klasy dla urządzenia względem korzenia
root, lub względem korzenia poddrzewa.
7
Terminologia
Aby prawidłowo zrozumieć opisywane tu zagadnienie, niezbędne jest zapoznanie się z
używaną w tym dokumencie odpowiednią terminologią1.
" Dyscyplina kolejkowania (ang. Queueing Discipline)  algorytm zarządzający kolejką
urządzenia, dla ruchu przychodzącego (ang. ingrees) lub wychodzącego (ang. egrees).
" Bezklasowa dyscyplina kolejkowania (ang. Classless qdisc)  dyscyplina kolejkowania
bez możliwości tworzenia wewnętrznych podziałów.
" Dyscyplina kolejkowania z klasami (ang. Classful qdisc)  dyscyplina kolejkowania
może zawierać wiele klas. Każda z nich może zawierać następne dyscypliny kolejkowania
i tak dalej i tak dalej - ale nie musi.
" Klasyfikator (ang. Classifier)  każda dyscyplina kolejkowania z klasami musi wiedzieć,
do której klasy ma wysłać pakiet. Wykonuje to właśnie na podstawie klasyfikatora.
" Filtr (ang. Filter)  klasyfikacja może zostać wykonana na podstawie filtrów. Filtr
zawiera pewną liczbę warunków, które jeśli pasują, sprawiają że filtr również pasuje.
" Planowanie (ang. Scheduling)  dyscyplina kolejkowania z klasami (qdisc), z pomocą
klasyfikatora może zdecydować, że niektóre pakiety powinny zostać wysłane wcześniej
niż inne. Proces ten nazywamy planowaniem. Planowanie nazywa się również
porządkowaniem, ale jest to raczej mylące.
" Kształtowanie (ang. Shaping)  proces odwlekania momentu wypuszczenia pakietu tak
by pasował do zdefiniowanych charakterystyk ruchowych i jego maksymalnych wartości.
Kształtowanie ruchu wykonywane jest przy opuszczaniu przez pakiet systemu.
" Narzucanie polityki (ang. Policing)  proces odwrotny do kształtowania, wykonywany
na ruchu przychodzącym. Może on tylko odrzucać pakiety a nie odwlekać ich obsługę
ponieważ nie ma kolejki dla ruchu przychodzącego.
" Kolejka bezstratna (ang. Work-Conserving)  ta kolejka zawsze dostarcza pakiet, jeśli
tylko jest dostępny. Innymi słowy, nigdy nie odwleka wysłania pakietu, jeśli urządzenie
sieciowe jest gotowe do przyjęcia go (w przypadku ruchu wychodzącego).
" Kolejka stratna (ang. non-Work-Conserving)  niektóre kolejki, takie jak na przykład
TBF mogą być zmuszone przytrzymać pakiet przez pewien czas, by dopasować się do
ustalonego limitu na przepustowość. Oznacza to, że czasami nie wyślą pakietu, mimo że
gdzieś w nich się znajduje.
Poniższy rysunek przedstawia teoretyczne działanie rutera:
1
Na podstawie  Kształtowanie Ruchu i Zaawansowany Ruting HOWTO
8
Rysunek 1 Teoretyczne działanie routera
Duży kwadrat reprezentuje jądro. Lewa strzałka reprezentuje ruch docierający do komputera z
sieci. Zostaje on następnie wrzucony do klasyfikatora ruchu przychodzącego, który może
zastosować filtry i być może odrzucić ten ruch. Nazywamy to narzucaniem polityki. Dzieje
się to we wczesnym stadium, zanim pakiet obejrzy sobie większość jądra, jest to więc dobre
miejsce by odrzucać ruch bez zbędnego angażowania cykli CPU.
Jeśli pakiet zostanie przepuszczony, może być skierowany do aplikacji działającej lokalnie -
trafia wtedy na stos IP by zostać przetworzony, a potem do tej konkretnej aplikacji. Pakiet
może jednak być przekazywany dalej, trafia wtedy do klasyfikatora dla ruchu wychodzącego.
Programy przestrzeni użytkownika wysyłające pakiety również dostarczają danych dla
klasyfikatora ruchu wychodzącego.
Ruch wychodzący z takiego czy innego z
ródła trafia następnie do przetworzenia w określonej
liczbie skonfigurowanych kolejek qdisc. W domyślnym, nie skonfigurowanym stanie, istnieje
jedynie jedna kolejka dla ruchu wychodzącego - jest to pfifo_fast, która zawsze odbiera
pakiet. Nazywamy to kolejkowaniem (ang. enqueueing). Pakiet czeka zatem w qdisc na
decyzję jądra powodującą wysłanie go przez któryś z interfejs sieciowy. Nazywamy to z kolei
opróżnianiem kolejki (ang. dequeueing).
Rysunek ten ma zastosowanie również dla sytuacji z jednym urządzeniem sieciowym -
strzałki skierowane do i od jądra nie powinny być brane zbyt dosłownie. W każ dym
urządzeniu sieciowym obsługiwane jest zarówno odebranie pakietu jak i jego wysłanie.
Uwaga: Dokładny opis tego zagadnienia znajduje się w dokumencie  Linux Traffic Control -
Implementation Overview (dołączone na CD).
Do specyfikacji pasma tc używa następujących reguł:
" mb = 1024 kb = 1024 * 1024 b => bajtów/s
" mbit = 1024 kbit = 1024 * 1024 bit => bitów/s.
9
Dyscypliny kolejkowania
Proste, bezklasowe dyscypliny kolejkowania
Tak jak to już powiedziano, dyscyplinami kolejkowania zmieniamy sposób w jaki dane są
wysyłane. Bezklasowe dyscypliny kolejkowania to te, które zajmują się jedynie odbieraniem
danych, przesuwaniem ich transmisji w czasie lub ewentualnie odrzucaniem.
Mogą być użyte do kontroli pasma dla całego interfejsu, bez żadnych dodatkowych
podziałów na klasy i kolejki. Najczęściej używaną dyscypliną kolejkowania jest pfifo_fast
i jest ustawiana jako domyślna. Istnieją również inne typy kolejek zapewniających określone
pasmo jak również sprawiedliwy podział przepustowości dla każdej konwersacji. Zazwyczaj
używa się ich w połączeniu z innymi klasami.
Kolejka pfifo_fast
Kolejka ta to tradycyjne pierwszy wszedł, pierwszy wyjdzie (ang. First In First Out, FIFO),
co oznacza, że żaden pakiet nie jest specjalnie traktowany. Przynajmniej nie wprost. Kolejka
ta ma 3 pasma (ang. band). W każdym paśmie z osobna działają reguły FIFO. Jednak dopóki
w paśmie 0 są jeszcze pakiety, pasmo 1 nie zostanie obsłużone. Tak samo dzieje się w
przypadku pasm 1 i 2.
Jądro honoruje tak zwaną flagę typu usługi (ang. Type of Service, ToS) i zajmuje się
ustawianiem opcji minimalna zwłoka w pakietach z pasma 0.
Parametry kolejki
Nie można konfigurować kolejki pfifo_fast, ponieważ jest ustawiona na sztywno w
domyślnej konfiguracji. Poniżej opisano jak to jest zrobione:
" priomap  określa w jaki sposób priorytety dla pakietów, przydzielane przez kernel,
odwzorowywane są na pasma. Odwzorowywanie zachodzi na podstawie oktetu ToS
pakietu, opis poniżej.
" Txqueuelen  długość tej kolejki odpowiada konfiguracji interfejsu. Można ją sprawdzić i
ustawić posługując się poleceniami ifconfig i ip . By ustawić długość kolejki na 10,
wykonaj polecenie ifconfig eth0 txqueuelen 10. Nie można ustawić tego parametru
za pomocą polecenia tc.
10
Opis pola ToS
Oktetu ToS pakietu, wygląda następująco:
Rysunek 2 Oktet ToS pakietu
Czterobitowe pole ToS definiowane jest w następujący sposób:
Binarnie Decymalnie Znaczenie
1000 8 Zminimalizuj zwłokę
0100 4 Maksymalizuj przepustowość
0010 2 Maksymalizuj niezawodność
0001 1 Zminimalizuj koszt
0000 0 Normalna usługa
Ponieważ naprawo od pola ToS znajduje się jeszcze jeden bit, pole ToS jest równe
podwojonej wartości bitów ToS.
Domyślna mapa priorytetów (priomap) w linii poleceń , wygląda następująco:
1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
TBF  Tocken Bucket Filter
Token Bucket Filter (TBF) to prosta kolejka z dyscypliną, która przepuszcza tylko dane
przychodzące z pewną częstotliwością nie przekraczającą nałożonych ograniczeń, ale z
możliwością przyjęcia krótkich serii danych, które przekraczają to ustawienie. Co również nie
jest bez znaczenia TBF jest bardzo precyzyjna, przyjazna zarówno dla sieci jak i procesora.
Implementacja TBF składa się z wiadra (ang. bucket), wypełnianego pewnymi wirtualnymi
porcjami danych, żetonami (ang. token) z określoną częstotliwością. Najważniejszym
parametrem wiadra jest jego rozmiar, określający ilość żetonów, które może ono przechować.
Każdy nadchodzący żeton wyjmuje jeden przychodzący pakiet z kolejki danych i jest
kasowany z wiadra.
Skojarzenie tego algorytmu z dwoma przepływami - żetonów i danych, daje trzy możliwe
scenariusze:
" Dane docierają do kolejki z częstotliwością równą częstotliwości napływania żetonów. W
tym przypadku każdy przychodzący pakiet pobiera z wiadra swój żeton i przechodzi przez
kolejkę bez zwłoki.
" Dane docierają do kolejki z częstotliwością mniejszą niż częstotliwość napływania
żetonów. Tylko ich część jest używana, więc te puste zbierane są do momentu osiągnięcia
rozmiaru wiadra. W takim przypadku może zaistnieć sytuacja, w której dane zaczynają
napływać bardzo szybko, w takim wypadku pakiety opróżniane są z kolejki wychodzącej
tworząc krótką serię pakietów przekraczających normalny limit przepustowości.
11
" Dane docierają do kolejki z częstotliwością większą niż częstotliwość napływania
żetonów. W takim wypadku wiadro zostanie w końcu opróżnione z żetonów, powodując
przez moment zwiększenie przepustowości, nazywa się to przekroczeniem limitu. Jeśli
pakiety nadal będą napływały z niezmienną częstotliwością , niektóre będą odrzucane.
Ostatni scenariusz umożliwia kształtować przepustowość, dostępną dla danych, które
przechodzą przez filtr. Należy również zwrócić uwagę, że w przedstawianej implementacji
żetony odpowiadają bajtom a nie pakietom.
Parametry kolejki
Parametry dostępne zawsze:
" limit lub latency  limit lub opóz
nienie  limit to ilość bajtów, które mogą zostać
skolejkowane w oczekiwaniu na wolne żetony. Można również określić ten parametr
wskazując opóz
nienie, określające maksymalny czas jaki pakiet może spędzić w kolejce,
w takim wypadku brany jest pod uwagę rozmiar wiadra, częstotliwość i ewentualnie
częstotliwość szczytową (jeśli zostanie ustawiona).
" burst/buffer/maxburst  seria/bufor/maksymalna seria  rozmiar wiadra określa
maksymalna ilość bajtów dla których jednocześnie mogą być dostępne żetony.
Generalnie, kształtowanie ruchu większych przepustowości wymaga większego bufora.
Dla ruchu 10mbit/s na karcie Intel, wymagane jest przynajmniej 10 kilobajtowy bufor.
Jeśli bufor będzie za mały, pakiety mogą być odrzucane dlatego, że przepływa więcej
żetonów na jednostkę zegara, niż mieści się w wiadrze
" mpu  Pakiet długości zero bajtów nie zużywa zero przepustowości. Dla ethernetu, pusty
pakiet zużywa mniej niż 64 bajty. Minimalna Jednostka Pakietu (ang. Minimum Packet
Unit) określa minimalną zajętość żetonu przez pakiet.
" rate  częstotliwość  ustawienie szybkości.
Jeśli wiadro zawiera żetony i nie może być puste (domyślnie pracuje z nieograniczoną
prędkością), a jest to nie akceptowalne, można użyć dodatkowych parametrów. Po więcej
szczegółów odsyłam do dokumentacji.
Przykładowa konfiguracja
Prosta, ale bardzo przydatna konfiguracja.
#tc qdisc add dev eth0 root tbf rate 220kbit latency 50ms burst 1540
Jeśli mamy urządzenie sieciowe z całkiem dużą kolejką, tak jak na przykład modem kablowy,
a po drugiej stronie podłączymy szybkie urządzenie takie jak na interfejs ethernetowy, można
zauważyć, że wysyłanie czegoś od razu niszczy interaktywność. Dzieje się tak dlatego,
ponieważ wysyłanie pakietów zapełni kolejkę w modemie, która jest prawdopodobnie duża
(taka konfiguracja pomaga uzyskać dużą przepustowość).
Linia powyżej spowalnia wysyłanie do częstotliwości, która nie prowadzi do zapełniania
kolejki w modemie  kolejka będzie już na ruterze, gdzie mamy swobodę jej konfiguracji.
12
SFQ  Stochastic Fairness Queueing
Sprawiedliwe Kolejkowanie Stochastyczne (ang. Stochastic Fairness Queueing - SFQ) to
prosta implementacja rodziny algorytmów ze sprawiedliwym podziałem pasma. Jest mniej
dokładna niż inne, ale wymaga również mniejszej ilości wyliczeń. Dodatkowo SFQ jest
praktycznie samo konfigurowalna.
Kluczowym słowem przy omawianiu SFQ jest konwersacja (ang. conversation) lub
przepływ (ang. flow), które odpowiadają prawie sesjom TCP czy strumieniom UDP. Ruch
dzielony jest na znaczną liczbę kolejek FIFO, jedną dla każdej konwersacji, a następnie
rozsyłany algorytmem round-robin, dzięki czemu każda sesja ma zawsze szansę wysłania
pakietu.
Zapewnia to sprawiedliwy podział pasma i uniemożliwia jednej konwersacji zajęcie całego
pasma. SFQ nazywana jest stochastyczną, ponieważ tak naprawdę nie alokuje kolejki dla
każdej sesji, a używa procedury dzielącej ruch na ograniczoną liczbę kolejek przy pomocy
algorytmu mieszającego (ang. hash).
Ponieważ używana jest wartość mieszająca, więcej niż jedna sesja mogą skończyć w tym
samym wiadrze. Oznaczałoby to w praktyce zmniejszenie szansy wysłania pakietu o połowę i
podzielenie tym samym na pół dostępną efektywną prędkość. By temu zapobiec, SFQ
zmienia często algorytm mieszający i nawet jeśli dojdzie do opisanej sytuacji będzie to działo
się tylko przez parę sekund.
SFQ jest użyteczne w przypadku gdy jeden z interfejsów wychodzących jest często
zapełniony. W przeciwnym wypadku, nie zostanie stworzona kolejka i tak naprawdę nie
będzie żadnego efektu.
W dalszej części dokumentu bardzo często będziemy używać kolejki SFQ w połączeniu z
innymi dyscyplinami kolejkowania.
Parametry kolejki
" perturb  wartość określająca co ile sekund zmieniany będzie algorytm mieszający. Jeśli
nie zostanie podana, wyliczona wartość mieszająca nie będzie rekonfigurowana.
Generalnie pomijanie tego parametru nie jest zalecane, wartość 10 sekund wydaje się
dobrym wyborem.
" quantum  ilość bajtów, którą strumień może zdjąć z kolejki zanim szansę wysłania
otrzyma następna kolejka. Domyślnie ustawione jest na równowartość maksymalnej
jednostki transmisji 1 pakietu (MTU). Zaleca się nie stosowanie wartości mniejszej niż
MTU gdyż uniemożliwi to większych pakietów.
13
Dyscypliny kolejkowania z klasami
Ruch, który dociera do korzenia kolejki z dyscypliną (qdisc) zawierającą klasy, jest
klasyfikowany, a następnie przesyłany do odpowiedniej klasy podrzędnej. Aby określić co
dzieje się z konkretnym pakietem używa się filtrów. Ważne jest aby zrozumieć że to filtry
wywoływane są w kolejce a nie na odwrót. Filtry dołączone do określonych kolejek z
dyscypliną, są przez nią używane do podjęcia decyzji skolejkowania pakietu w jedną z klas.
Każda podklasa może zawierać własne filtry, dopasowując pakiet do swoich założeń. W
przypadku braku filtrów klasa kolejkuje pakiet do kolejki, która ją zawiera.
Poniższy rysunek w uproszczeniu przedstawia budowę i funkcjonowanie kolejek, klas i
filtrów dołączonych do kolejki głównej.
Rysunek 3 kolejki, klasy i filtry
Oprócz zawierania w sobie innych kolejek, większość kolejek z dyscypliną zawierające klasy
wykonuje również kształtowanie. Pozwala to na jednoczesne planowanie kolejności
wysyłania pakietów jak i częstotliwości z jaką będą one wysyłane
Każdy interfejs ma jedną wychodzącą kolejkę-korzeń, którą domyślnie jest wspomniana
wcześniej bezklasowa pfifo_fast. Każdej z kolejek z dyscypliną można nadać uchwyt, który
będzie potem używany przez polecenia konfigurujące filtry by odwołać się do tej konkretnej
kolejki. Poza wychodzącymi kolejkami, interfejs może posiadać również przychodzące, które
podlegają narzuceniu polityki.
Uchwyt kolejki składa się ze starszego i młodszego numeru (starszy:młodszy).
Charakterystyczną nazwą dla kolejki-korzenia jest 1:, które równe jest 1:0. Młodszy numer
kolejki z dyscypliną zawsze równy jest 0. Klasy muszą mieć ten sam starszy numer,
określający ich kolejkę rodzica, natomiast numer młodszy określa numer podklasy.
Przykładowy rysunek przedstawia definicję różnych dyscyplin kolejkowania w postaci
drzewa.
14
Rysunek 4 Przykładowe drzewo kolejek i klas
Numerowanie klas i kolejek jest dowolne, poza sytuacjami opisanymi wcześniej, jednak
proponowana tu konwencja pozwala na sprawniejsze poruszanie się w strukturze drzewa i
łatwiejsze rozpoznacie rodziców i potomków.
Kiedy jądro zdecyduje że musi zdjąć pakiet z i wysłać go interfejsem, kolejka będąca
korzeniem całego drzewa (root 1:) odbiera od jądra żądanie rozkolejkowania. Następnie
żądanie to wysyłane jest do potomków kolejki (w tym wypadku klas), które z kolei przesyłają
je dalej w głąb drzewa do swoich potomków (tutaj już klas lub kolejek). Na podstawie
ustawień specyfikujących klasy (np. szerokość pasma, priorytet) podejmowana jest decyzja,
który pakiet, z której kolejki trafia do kolejki rodzica, a jeden z nich do kolejki w korzeniu
skąd jest wysyłany przez interfejs. W przypadku gdy w całym drzewie znajduje się tylko
jeden pakiet jądro musi przeglądnąć całe drzewo.
Precyzując, zagnieżdżone klasy rozmawiają tylko ze swoimi rodzicami, nigdy z interfejsem.
Wynika z tego ważny fakt, że klasa nie jest rozkolejkowana szybciej niż pozwala na to jej
rodzic. Dodatkowo tylko kolejka w korzeniu całego drzewa rozmawia bezpośrednio z
interfejsem i jest prze niego rozkolejkowywana2.
HTB  Hierarchical Token Bucket
Kolejka HTB jest została stworzona jako bardziej zrozumiała i intuicyjna alternatywa dla
opisywanej poniżej kolejki CBQ. Pozwala na kontrolę ruchu wychodzącego z serwera,
symulacji kilku wolniejszych połączeń, jak również wysyłanie różnego rodzaju ruchu na
różnych symulowanych połączeniach. HTB określa sposób odwzorowania fizycznego
połączenia w symulowane połączenia i decyduje, które z nich powinno być użyte dla
określonego połączenia.
Kolejka HTB nie jest integralną częścią jądra Linux a. Sposób instalacji opisano w
odpowiednim rozdziale poniżej.
2
Szerszy opis tego zagadnienia znajduje się w opracowaniu  Linux Traffic Control  Iplementation Overview ,
autorstwa Werner a Almensberger a (na CD)
15
Dzielenie połączenia
Kolejka HTB zapewnia obsługę usługi odpowiadającej pewnej klasie na co najmniej
minimalnym poziomie. W przypadku gdy klasa wymaga mniejszej przepustowości, pozostałe
pasmo jest współdzielone z innymi klasami, które mogą wymagać większego pasma.
Użyjemy następującego polecenia aby podpiąć kolejkę HTB do korzenia urządzenia:
#tc qdisc add dev eth0 root handle 1: htb default 12
Ta komenda podpina dyscyplinę kolejkowania HTB do urządzenia eth0 i nadaje mu uchwyt
1:. Parametr default 12 oznacza że każdy niesklasyfikowany ruch pakietów będzie
przekazywany do klasy 1:12.
Przyjrzyjmy się następnym poleceniom
#TC= tc class add dev eth0
#$TC parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
#$TC parent 1:1 classid 1:10 htb rate 30kbps ceil 100kbps
#$TC parent 1:1 classid 1:11 htb rate 10kbps ceil 100kbps
#$TC parent 1:1 classid 1:12 htb rate 60kbps ceil 100kbps
Pierwsza linia tworzy klasę korzeń identyfikowaną jako 1:2 w kolejce qdisc 1:. Definicja
klasy korzenia jest tylko jedna a jej rodzicem jest kolejka z dyscypliną. Klasa korzeń,
podobnie jak inne klasy pozwala na pożyczanie pasma pomiędzy klasami dziećmi. W
następnych trzech linkach tworzone są klasy potomne 1:1.
Parametr rate określa pasmo używane przez daną klasę. Parametr ceil zostanie opisany w
dalszej części rozdziału
Możemy również określić dyscyplinę kolejkowania w każdej z klas. Domyślnie używaną jest
kolejka pfifo.
Poniższe trzy liniki definiują określone dyscypliny kolejkowania dla każdej z klas
#tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5
#tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5
#tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10
W ten sposób stworzyliśmy drzewo podziału pasma, w którym klasy współdzielą
przepustowość 100 kbps w stosunku 3:1:6 i każda z klas może pożyczać pasmo od innej w
przypadku gdy wypożyczający nie wykorzystuje całego zasobu.
Wypożyczanie pasma
Parametr ceil określa maksymalną przepustowość jaką klasa może wykorzystać, a więc i ile
może wypożyczać od swojego rodzeństwa. Domyślną wartością jest parametr rate.
Parametr ten jest użyteczny w przypadku gdy chcemy ograniczyć maksymalną przepustowość
dla danej klasy tak by nie przekroczyła określonej częstotliwości. Należy pamiętać że klasa
która jest korzeniem nie może wypożyczać pasma.
Parametr ceil dla klasy powinien mieć wartość większą, lub równą, parametrowi rate.
Również parametr ten dla klasy powinien być większy lub równy parametrowi ceil jej dzieci.
16
Opróżnianie kolejki
Sprzęt sieciowy może wysyłać tylko jeden pakiet w tym samym czasie i z określona przez
jego parametry techniczne częstotliwością. Oprogramowanie dzielące połączenie
wykorzystuje możliwość aproksymacji, która pozwala na osiągnięcie efektu wielu połączeń
działających z różną, zazwyczaj mniejszą częstotliwością. W przypadku gdy fizyczne łącze
dzielimy na logiczne pasma parametry burst i cburst pozwalają kontrolować maksymalną
ilość danych, które mogą być wysłane z maksymalną prędkością bez dzielenia pasma z
innymi klasami.
Kiedy określimy parametr burst, dla klasy rodzica, mniejszy niż dla niektórych klas
potomnych, możemy się spodziewać, że te klasy będą się czasami przytykać. W przypadku
gdy określimy zbyt małą wartość dla parametru burst możemy otrzymać mniejsze pasmo niż
ustawiliśmy.
Priorytety ruchu
Nadawanie priorytetu ma dwie strony. Pierwsza określa w jaki sposób pasmo jest dzielone
klasy potomne. W użytym do tej pory przykładzie ruch był dzielony zgodnie z częstotliwością
klasy. W przypadku gdy określimy priorytety najpierw brane są pod uwagę klasy posiadające
priorytet o wartości najniższej zachowując zasadę częstotliwości miedzy klasami tego samego
priorytetu.
Druga strona wiąże się z opóz
nieniami pakietów. Trudno jest je określić dla szybkich
interfejsów takich jak ethernet. W takim wypadku można wykorzystać kolejki. W takim
przypadku możemy dodać klasę z pasmem ograniczonym do wartości mniejszej niż 100 kbps,
następnie stworzyć jej potomka, który będzie nam symulował wolniejsze łącze.
Parametry kolejki
Kolejka HTB może przyjmować następujące parametry
" default  domyślna klasa przyjmująca ruch niesklasyfikowany, parametr ten przypisuje
się tylko do qdisc, a nie do klas.
" rate  parametr określający szybkość pasma.
" ceil  parametr określający maksymalny rozmiar pasma, osiągany poprzez wypożyczanie
go od innych kolejek posiadających tego samego rodzica.
" burst i cburst  parametry określają maksymalną ilość danych, które mogą być wysłane z
maksymalną prędkością bez dzielenia pasma z innymi klasami.
" prio  określa priorytet kolejki.
Kolejka PRIO
Kolejka PRIO nie zajmuje się tak naprawdę kształtowaniem ruchu, dzieli jedynie ruch na
podstawie tego, jak zostały skonfigurowane filtry. Można ją traktować jak rozszerzoną
17
kolejkę pfifo_fast (zamiast pasma jest osobna klasa zamiast prostej kolejki FIFO). Kolejka
PRIO jest bardzo użyteczna, gdy należy priorytetować określone rodzaje ruchu nie tylko na
podstawie flag ToS, ale całej potęgi, którą zapewniają filtry tc. Może równie ż zawierać inne
kolejki, podczas gdy pfifo_fast jest ograniczona do prostych kolejek FIFO.
Kiedy pakiet zostaje skolejkowany w qdisc PRIO, na podstawie komend filtrujących
wybierana jest klasa. Domyślnie, stworzone są trzy klasy zawierające czyste kolejki FIFO bez
żadnej struktury wewnętrznej, ale można zastąpić je dowolnymi kolejkami qdisc.
Zawsze gdy pakiet musi zostać wyjęty z kolejki, sprawdza się klasę :1. Wyższe klasy są
sprawdzane tylko wtedy, gdy poprzednie nie zwróciły pakietu.
Ponieważ kolejka ta nie zajmuje się kształtowaniem ruchu, należy używać jej tylko jeśli
fizyczne łącze jest naprawdę obciążone, lub powiązać ją z kolejką qdisc z klasami, która nie
zajmuje się kształtowaniem ruchu. Formalnie rzecz biorąc, kolejka PRIO jest planującą
kolejką bezstratną .
Pasma są klasami i domyślnie nazywane są od numer_starszy:1 do numer_starszy:3, więc
jeśli kolejka PRIO nazywa się 12:, można użyj tc do przefiltrowania ruch na 12:1 dla
podniesienia priorytetu.
Uwaga: Należy pamiętać że pasmo 0 trafia na młodszy numer 1, a pasmo 1 na młodszy
numer 2 i tak dalej.
Parametry kolejki
Następujące parametry rozpoznawane są przez tc dla kolejki PRIO:
" bands  pasma  ilość pasm do utworzenia. Każde pasmo to tak naprawdę klasa. Jeśli
zmieniamy ten numer, należy zmienić również priomap.
" priomap - mapa priorytetów  jeśli nie dostarczymy filtrów tc do klasyfikowania ruchu,
kolejka PRIO będzie sprawdzać priorytety TC_PRIO stwierdzić, jak kolejkować ruch.
Działa to tak jak kolejka pfifo_fast wspomniana wcześniej.
Przykłady użycia
Przyjrzyjmy się następującej sekwencji poleceń.
#tc qdisc add dev eth0 root handle 1: prio
#tc qdisc add dev eth0 parent 1:1 handle 10: sfq
#tc qdisc add dev eth0 parent 1:2 handle 20: sfq
#tc qdisc add dev eth0 parent 1:3 handle 30: sfq
Pierwsze polecenie od razu tworzy klasy 1:1, 1:2 i 1:3. Drzewo urządzenia wygląda
następująco.
18
Rysunek 5 Przykład z kolejką PRIO
CBQ  Class Based Queue
Kolejka CBQ jest najbardziej skomplikowaną i często jest błędnie utożsamiana z całym
zagadnieniem. Nie dzieje się tak dlatego, że jej autorzy byli złośliwi lub niekompetentni -
przeciwnie, po prostu algorytm CBQ nie jest zbyt precyzyjny i niezbyt pasuje do sposobu w
jaki działa Linux.
Poza tym że jest to kolejka z klasami, CBQ zajmuje się również kształtowaniem ruchu i tego
właśnie nie robi zbyt dobrze. CBQ pobiera czas bezczynności z ilości mikrosekund pomiędzy
wywołaniami sprzętowymi o więcej danych, skąd CBQ aproksymuje jak bardzo łącze jest
zajęte.
W związku z tym, że parametry konfiguracji CBQ są bardzo zawiłe, i trudne to ogarnięcia,
pominiemy szczegóły ustawień tej kolejki w tym dokumencie, a wspominamy o niej tylko ze
względów historycznych. Obecnie istnieją prostsze i skuteczniejsze kolejki jak choćby
wspomniana wcześniej HTB.
Kolejka ruchu przychodzącego
Wszystkie omawiane do tej pory kolejki qdisc to kolejki dla ruchu wychodzącego. Każdy
interfejs ma jednak również kolejki dla ruchu przychodzącego, które nie zajmują się
wysyłaniem pakietów do karty sieciowej. Zamiast tego, kolejki te umożliwiają zastosowanie
filtrów kontroli ruchu dla pakietów przychodzących do interfejsu, niezależnie czy
adresowanych lokalnie czy przekazywanych dalej.
Ponieważ filtry tc zawierają pełną implementację Filtra Wiadra Żetonów (TBF) i mogą
dopasowywać pakiety na podstawie estymatora przepływu jądra, mają całą masę
funkcjonalności. Umożliwia to stosować politykę do nadchodzącego ruchu nawet zanim
dotrze do stosu IP.
Oto przykład konfiguracji kolejki przychodzącej dla połączenia szeregowego w SDI.
#tc qdisc add dev $DEV handle ffff: ingress
#tc filter add dev $DEV parent ffff: protocol ip prio 50
> u32 match ip src 0.0.0.0/0
> police rate 128kbit burst 10k drop
> flowid :1
19
Pierwsze polecenie podpina uchwyt ffff: do kolejki przychodzącej. Następna na podstawie
testu u32 i określonej polityki odrzucającej pakiety przychodzące zbyt szybko. Takie
ustawienie zapobiega zapychaniu się kolejki wychodzącej na domyślnej bramce.
20
Klasyfikowanie pakietów filtrami
Aby rozdzielić ruch do odpowiednich pasm (klas), wykorzystywane są filtry. Wysyłany
pakiet trafia najpierw do kolejki korzenia 1: a stamtąd w zależności od typu kolejki i/lub
ustawionych filtrów kierowany jest dalej. Każda kolejka i klasa może posiadać własne filtry
przekazujące pakiet w głąb struktury drzewa.
Oto przykład użycia filtru.
#tc filter add dev eth0 protocol ip parent 1: prio 2 flowid 1:10
Filtr ten mówi że każdy pakiet przez niego przeważany, który trafił do korzenia, ma zostać
przekazany do klasy o numerze 1:10. Tam może zostać ponownie sklasyfikowany i
przekazany w duł drzewa.
Klasyfikatory ogólnie rzecz biorąc, akceptują kilka podstawowych argumentów. Oto one.
" protocol  protokół, który ten klasyfikator zaakceptuje. W zasadzie będziesz akceptował
ruch IP. Argument wymagany.
" parent  oznaczenie, do którego ten klasyfikator będzie podpięty. Musi być już
zdefiniowane dla istniejącej klasy. Parametr wymagany.
" prio  priorytet klasyfikatora. Niższy numer będzie sprawdzany szybciej.
" handle  uchwyt oznacza różne rzeczy dla różnych filtrów.
Filtry i klasyfikowanie pakietów
Oto spis klasyfikatorów, których można użyć do rozsyłania pakietów do kolejek
" fw  podejmuje decyzję na podstawie tego, jak firewall oznaczył pakiet. Użycie go może
być prostsze, niż uczenie się całej składni tc.
" u32  podejmuje decyzję na podstawie pól w pakiecie (np. z
ródłowego adresu IP).
" route  podejmuje decyzję na podstawie trasy, którą pakiet będzie rutowany.
" rsvp, rsvp6  kieruje pakiety na trasy określone przez standard RSVP3. Użyteczne tylko
w sieciach, które w całości są kontrolowane przez jednego administratora (Internet nie
respektuje RSVP).
" tcindex  używane w kolejce DSMARK.
3
więcej o standardzie pod adresem: http://www.isi.edu/div7/rsvp/overview.html
21
Najczęściej używane filtry
W większości przypadków kształtowanie ruchu odbywa się przy użyciu testów u32. Poniżej
przedstawiono najczęściej używane testy. Przykłady wykorzystania testów znajdują się w
opisie konfiguracji ruterów.
Testy na adresach z
ródłowym i docelowym
Maska z
ródłowa.
... u32 match ip src 1.2.3.0/24 ...
Maska docelowa.
... u32 match ip dst 4.3.2.0/24 ...
By wskazać pojedynczy komputer, należy użyć /32 lub po prostu pominąć maskę .
Testy na portach z
ródłowym i docelowym
Port z
ródłowy.
... u32 match ip sport 80 0xffff ...
Port docelowy.
... u32 match ip dport 0xffff ...
Testy na protokół (tcp, udp, icmp, gre, ipsec)
Używamy tutaj numerków z /etc/protocols, dla przykładu ICMP ma przydzielony numer 1,
wi ęc test dla tego protokołu jest następujący.
... u32 match ip protocol 1 0xff ...
Testy na znacznik (fwmark)
Można oznaczać pakiety przy użyciu iptables, taki znacznik przeżywa ruting pomiędzy
interfejsami. Jest to użyteczne dla kształtowania ruchu na interfejsie eth1, który przyszedł z
eth0. Oto przykład testu.
... handle 5 fw ...
Należy zwrócić uwagę, że nie jest to test u32. Wartość 5 określa oznaczenie pakietu. Aby
oznaczyć pakiet wykonujemy następujące polecenie.
#iptables -A FORWARD -t mangle -i eth0 -j MARK --set-mark 5
Oznaczenia takie przezywają ruting i mogą być wykorzystywane w filtrach na innych
interfejsach.
Testy na polu ToS
By wybrać ruch interaktywny z minimalną zwłoką.
... u32 match ip tos 0x10 0xff ...
Dla ruchu typowego należy użyć 0x08 0xff.
22
Przygotowanie serwera
Kompilacja i instalacja jądra
Ponieważ kolejka HTB nie jest integralną częścią jądra Linux a w wersji 2.4.x należy
skompilować jądro z jej obsługą. Dodatkowo podczas kompilacji dołączona zostanie obsługa
zawansowanego rutowania, inne kolejki, filtrowanie pakietów i iptables dla ustawiania
zliczania pakietów i konfiguracji firewall a.
W procesie opisującym przygotowanie jądra pomijamy informacje o wszelkich
optymalizacjach kompilatora, jak również opis innych opcji ustawianych podczas
konfiguracji. Wszelkie pliki niezbędne do wykonania poniższej procedury opisane są w
rozdziale  Zawartość CD .
Przygotowanie z
ródeł
Na początku należy usunąć poprzednią wersje z
ródeł jądra jak również link o nazwie linux.
Można to wykonać następującą komendą.
#rm -rf /usr/src/linux-wersja_jadra/
#rm -rf /usr/src/linux/
Po drugie należy rozpakować i przygotować pliki z
ródłowe jądra. W tym celu kopiujemy plik
linux-2.4.18.tar.gz do katalogu /usr/src/.
Następnie wykonujemy odpowiednie polecenia
#cd /var/src/
#tar xzpf linux-2.4.18.tar.gz
#rm  f linux-2.4.18.tar.gz
Teraz w katalogu /usr/src/ powinien znajdować się katalog linux ze z
ródłami jądra. Aby
nadać dodatkowe rozszerzenie w celu identyfikacji wersji jądra można w pliku Makefile
znajdującym się w tym katalogu ustawić parametr (w opisywanym tu przypadku dodajemy
sufiks .BaS):
VERSION = 2
PATCHLEVEL = 4
SUBLEVEL = 18
EXTRAVERSION = .BaS
23
Uzupełnienie jądra obsługą kolejki HTB
Aby uzupełnić z
ródła jądra o obsługę kolejek HTB należy przekopiować plik
htb3.5_2.4.17.diff znajdujący się w pakiecie HTB3 do katalogu /usr/src/ i wykonać
polecenia.
#mv linux linux-2.4
#patch  p0 < htb3.5_2.4.17.diff
#rm  f htb3.5_2.4.17.diff
Pierwsza linijka zmienia domyślną nazwę katalogu ze z
ródłami jądra. Jest to wymagane dla
następnej komendy patch.
Konfiguracja jądra
Należy również uaktualnić skróty do plików nagłówkowych jądra w katalogu /usr/include/.
W tym celu wykonujemy następujące polecenia.
#cd /usr/include/
#rm -rf asm linux scsi
#ln -s /usr/src/linux-2.4/include/asm-i386 asm
#ln -s /usr/src/linux-2.4/include/linux linux
#ln -s /usr/src/linux-2.4/include/scsi scsi
Teraz możemy już wysprzątać ewentualne pliki pozostawione przez programistów jądra i
uruchomić program konfiguracyjny.
#cd /us r/src/linux-2.4/
#make mrproper
#make menuconfig
Ostatnie polecenie przygotuje nam odpowiednie menu, w którym będziemy mogli zaznaczać
interesujące nas opcje jądra.
Wszystko co dotyczy niniejszego treści dokumentu znajduje się w podmenu Networking
options. Poniższy wydruk przedstawia przybliżoną zawartość ekranu po wybraniu tej opcji.
Najbardziej interesujące nas opcje zostały pogrubione.
Networking options --->
[*] Packet socket
[ ] Packet socket: mmapped IO
[ ] Netlink device emulation
[*] Network packet filtering (replaces ipchains)
[ ] Network packet filtering debugging
[ ] Socket Filtering
[*] Unix domain sockets
[*] TCP/IP networking
[ ] IP: multicasting
[*] IP: advanced router
[*] IP: policy routing
[*] IP: use netfilter MARK value as routing key
[*] IP: fast network address translation
[*] IP: equal cost multipath
[*] IP: use TOS value as routing key
[*] IP: verbose route monitoring
[ ] IP: large routing tables
[ ] IP: kernel level autoconfiguration
[ ] IP: tunneling
24
[ ] IP: GRE tunnels over IP
[ ] IP: TCP Explicit Congestion Notification support
[*] IP: TCP syncookie support (disabled per default)
IP: Netfilter Configuration --->
---
[ ] The IPX protocol
[ ] Appletalk protocol support
[ ] DECnet Support
[ ] 802.1d Ethernet Bridging
QoS and/or fair queueing --->
Po wybraniu opcji IP: Netfilter Configuration zawartość menu wygląda następująco.
IP: Netfilter Configuration --->
[*] Connection tracking (required for masq/NAT)
[*] FTP protocol support
[*] IRC protocol support
[*] IP tables support (required for filtering/masq/NAT)
[*] limit match support
[*] MAC address match support
[*] netfilter MARK match support
[*] Multiple port match support
[*] TOS match support
[*] AH/ESP match support
[*] LENGTH match support
[*] TTL match support
[*] tcpmss match support
[*] Connection state match support
[*] Packet filtering
[*] REJECT target support
[*] Full NAT
[*] MASQUERADE target support
[*] REDIRECT target support
[*] Packet mangling
[*] TOS target support
[*] MARK target support
[*] LOG target support
[ ] ULOG target support (NEW)
[*] TCPMSS target support
Następne podmenu dotyczy gwarantowanego poziomu usług i wygląda następująco.
QoS and/or fair queueing --->
[*] QoS and/or fair queueing
[*] CBQ packet scheduler
[*] HTB packet scheduler
[ ] CSZ packet scheduler
[*] The simplest PRIO pseudoscheduler
[ ] RED queue
[*] SFQ queue
[ ] TEQL queue
[*] TBF queue
[ ] GRED queue
[*] Diffserv field marker
[*] Ingress Qdisc
[*] QoS support
[*] Rate estimator
[*] Packet classifier API
[*] TC index classifier
[*] Routing table based classifier
[*] Firewall based classifier
[*] U32 classifier
[*] Special RSVP classifier
25
[*] Special RSVP classifier for IPv6
[*] Traffic policing (needed for in/egress)
Teraz po naciśnięciu klawisza Enter na przycisku Exit w głównym menu konfiguracji i
wybraniu opcji zapisu ustawianych parametrów możemy przejść do kompilacji jądra.
Uwaga: Pozostałe zaznaczone do włączenia opcje, ale nie pogrubione są albo wymaganymi
modułami do działania sieci TCP/IP, lub zostały wykorzystane w celu sprawdzenia informacji
zawartych w niniejszym dokumencie. Po więcej szczegółów dotyczących konfiguracji jądra
odsyłam do dokumentacji.
Kompilacja
Aby wykonać proces kompilacji jądra należy wykonać poniższą linie poleceń.
#make dep; make clean; make bzImage
Pierwsza z nich aktualizuje pliki z
ródłowe zgonie z ustawioną konfiguracją. Następna czyści
ewentualne pliki, które mogły by być wynikiem poprzedniej kompilacji. Ostatnia uruchamia
właściwy proces kompilacji zakończony stworzeniem spakowanej wersji jądra.
W przypadku gdy została zaznaczona opcja wsparcia dla modułów w jądrze należy
dodatkowo uruchomić proces kompilacji modułów i ich instalacji, co wykonują następujące
polecenia.
#make modules
#make modules_install
Instalacja
Po prawidłowym przebiegu procesu kompilacji można przejść do instalacji i testowania
nowego jądra.
Pierwszą czynnością jest przekopiowanie pliku z obrazem jądra do katalogu /boot/, co
wykonuje następującą komenda.
#cp /usr/src/linux-2.4/arch/i386/boot/bzImage /boot/vmlinuz-2.4.18.BaS
Następnie kopiujemy plik z mapą systemu.
#cp /usr/src/linux-2.4/System.map /boot/System.map-2.4.18.BaS
Teraz jeszcze stworzenie odpowiedniego katalogu zawierającego pliki nagłówkowe
odpowiednie dla nowego jądra, dla póz
niejszych kompilacji innych programów.
#mkdir -p /usr/src/linux-2.4.18.BaS/include
#cp -r /usr/src/linux-2.4/include/asm-generic
> /usr/src/linux-2.4.18.BaS/include
#cp -r /usr/src/linux-2.4/include/asm-i386 \
> /usr/src/linux-2.4.18.BaS/include
#cp -r /usr/src/linux-2.4/include/linux /usr/src/linux-2.4.18.BaS/include
#cp -r /usr/src/linux-2.4/include/net /usr/src/linux-2.4.18.BaS/include
#cp -r /usr/src/linux-2.4/include/video /usr/src/linux-2.4.18.BaS/include
#cp -r /usr/src/linux-2.4/include/scsi /usr/src/linux-2.4.18.BaS/include
#cd /usr/src
#ln -s /usr/src/linux-2.4.18.BaS linux
26
Pozostało jeszcze włączenie nowego jądra do LILO. W pliku /etc/lilo.conf dopisujemy
następującą sekwencję.
image=/boot/vmlinuz-2.4.18.BaS
label=linux-2.4.18
root=/dev/hda5
read-only
Aby uaktualnic konfigurację LILO wykonujemy.
#lilo
Teraz pozostaje nam tylko restart komputera i wybranie naszego jądra z menu LILO.
Instalacja iproute2
Ponieważ pracujemy w oparciu o system Linux Slackware 8.0 wykorzystamy narzędzie
pkgtool i pakiet binarny iproute2-2.4.7-now-ss020116-try-i386-1.tgz.
Dodatkowo należy zaktualizować plik tc znajdujący się w katalogu /sbin/ do wersji
obsługującej kolejki HTB w wersji 3. Znajduje się on w pliku htb3.5-020521.tgz.
Jądro 2.2.x
Wszystkie opisane tutaj sposoby kolejkowania i filtrowania pakietów działają również dla
jąder z serii 2.2.x. Różnica polega tylko na sposobie ustawiania reguł firwall a. Zamiast
narzędzia iptables i tablic w jądrze, zajmujących się filtrowaniem pakietów. W jądrze 2.2.x
istnieje narzędzie zwane ipchains, natomiast tablice są reprezentowane przez łańcuchy.
Funkcjonalność tego rozwiązania jest mniejsza niż w opisywanym tu przypadku jądra 2.4.x,
gdyż jest to rozwiązanie starsze, będące prekursorem tablic.
Odpowiednie pliku dołączające kolejkę HTB do jądra 2.2.x znajduje się na stronie domowej
tej kolejki, obecnie istnieje tylko w wersji 2. Na stronie domowej HTB nie ma informacji czy
kod kolejki będzie nadal rozwijany dla tej wersji jądra.
27
Opis zadań
W rozpatrywanych tu obu przypadkach, ponieważ są to sieci osiedlowe, należy zapewnić
łatwy mechanizm podłączania i odłączania użytkowników (np. zalęgających z opłatami).
Dodatkowym zadaniem jest zliczanie ruchu jaki odbywa się na serwerze w celu określenia
obciążenia generowanego przez poszczególnych użytkowników.
Jedna podsieć, łącze radiowe (serwer 1)
Serwer dostępowy do Internetu, dla sieci lokalnej, posiadający dwa interfejsy sieciowe oparte
o karty Ethernet. Jedna z nich podłączona do terminala pozwalającego na bezprzewodowy
transfer danych drogą radiową ze zmiennym pasmem 512 kbps w godzinach szczytu i 768
kbps poza tymi godzinami i w weekendy. Druga podłączona do sieci lokalnej opartej o
technologię Ethernet 10 Mbps. Zadanie polega na takiej konfiguracji serwera aby pozwalał on
na dostęp do wszelkich usług związanych z Internetem, przy założeniu że preferowanymi
usługami są DNS, SSH, poczta, WWW.
Sieć zapewnia dostęp do Internetu 20 użytkownikom.
Dwie podsieci, łącze szeregowe (serwer 2)
Serwer dostępowy do Internetu, dla sieci lokalnej, posiadająca trzy interfejsy sieciowe oparte
o technologię Ethernet i połączenie modemowe. Obie karty sieciowe zapewniają obsługę
dwóch podsieci korzystających z technologii Fast Ethernet 100 Mbps, natomiast połączenie
szeregowe zapewnia dostęp do Internetu o przepustowości 1 Mbps. Zadanie polega na takim
skonfigurowaniu serwera aby jedna z podsieci miała dostęp z pełną przepustowością łączą,
natomiast druga ograniczony do 416 kbps. Dodatkowo ruch pomiędzy podsieciami powinien
odbywać bez jakichkolwiek ograniczeń.
Sieć zapewnia dostęp do Internetu 57 użytkownikom. Z czego niektóre osoby posiadają adres
rutowalny.
28
Konfiguracje serwerów
Obydwa serwery skonfigurowano w oparciu o Linux Slackware 8.0 i jądro skompilowane
zgodnie z opisem zawartym we wcześniejszym rozdziale.
Konfiguracja firewall a
Dla obu serwerów zastosowano podobne pliki konfiguracyjne dla firewall a, nieznaczne
różnice odnotowano. Ze względów objętościowych, jak i rozmiarów zagadnienia jakim jest
ściana ognia, ograniczono się tylko do niezbędnych wpisów, pozwalających na prawidłowe
działanie serwerów.
Poniżej przedstawiono podstawowy plik konfiguracyjny dla serwera pierwszego.
#!/bin/bash
echo "[iptables] Seting firewall rules"
############################################################
echo " - clear tables"
iptables -F
iptables -F -t nat
############################################################
echo " - masqaerade"
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -p all -j MASQUERADE
############################################################
echo " - input"
iptables -P INPUT DROP
# ruch zewnetrzny
iptables -A INPUT -i eth0 -j ACCEPT
echo " - forward"
iptables -P FORWARD DROP
iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
############################################################
echo " - output"
iptables -P OUTPUT DROP
# ruch zewnetrzny
iptables -A OUTPUT -o ppp0 -j ACCEPT
Poniżej przedstawiono podstawowy plik konfiguracyjny dla serwera drugiego.
#!/bin/bash
echo "[iptables] Seting firewall rules"
############################################################
echo " - clear tables"
iptables -F
29
iptables -F -t nat
############################################################
echo " - masqaerade"
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o ppp0 -p all -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o ppp0 -p all -j MASQUERADE
############################################################
echo " - input"
iptables -P INPUT DROP
# ruch zewnetrzny
iptables -A INPUT -i ppp0 -j ACCEPT
# ruch w podsieciach
iptables -A INPUT -i eth0 -d 192.168.2.0/24 -j ACCEPT
iptables -A INPUT -i eth1 -d 192.168.1.0/24 -j ACCEPT
echo " - forward"
iptables -P FORWARD DROP
iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT
# forward localnet adresses
iptables -A FORWARD -i eth1 -s 192.168.2.0/24 -o eth0 -d 192.168.1.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -s 192.168.1.0/24 -o eth1 -d 192.168.2.0/24 -j ACCEPT
############################################################
echo " - output"
iptables -P OUTPUT DROP
# ruch zewnetrzny
iptables -A OUTPUT -o ppp0 -j ACCEPT
# ruch w podsieciach
iptables -A OUTPUT -s 192.168.1.0/24 -o eth1 -j ACCEPT
iptables -A OUTPUT -s 192.168.2.0/24 -o eth0 -j ACCEPT
Jak widać w obu przypadkach wszelkich ruch jest praktycznie odrzucany, co pozwala nam na
zastosowanie mechanizmu kontroli użytkowników, który został opisany poniżej.
Mechanizm kontroli użytkowników
W celu zarządzania użytkownikami podłączonymi do podsieci lokalnych, stworzono
mechanizm pozwalający użytkownikom mającym dostęp do odpowiedniego katalogu na
zarządzanie komputerami.
W takim katalogu znajdują się pliki, których nazwa wygląda określa nazwę komputera, a
parametr po pauzie sposób jego obsługi przez serwer (ok  pełny dostęp, warn  brak
Internetu, out  brak Internetu i dostępu do serwera). Zawartość pliku wygląda następująco.
DEV=eth1
IP_INT=192.168.1.15
IP_SERV=192.168.1.1
IP_EXT=
MAC=00:C0:DF:E8:FA:43
Znaczenie poszczególnych zmiennych przedstawia się następująco.
" DEV  interfejs podsieci
" IP_INT  adres IP w sieci lokalnej
30
" IP_SERW  adres serwera dla tej podsieci
" IP_EXT  adres rutowalny dla komputera
" MAC  sprzętowy adres karty sieciowej
Odpowiedni skrypt znajdujący się w katalogu /serwer/ o nazwie rc.userconf znajduje się na
dołączonym CD.
Aby całość mogła w pełni funkcjonować do pliku konfiguracji firewall a dopisujemy
następujące liniki.
echo " - user config"
# tworzymy odpowiednie lancuchy
iptables -X I_USER 2> /dev/null
iptables -X O_USER 2> /dev/null
iptables -X F_USER 2> /dev/null
iptables -N I_USER
iptables -N O_USER
iptables -N F_USER
iptables -A INPUT -j I_USER
iptables -A OUTPUT -j O_USER
iptables -A FORWARD -j F_USER
# wywolanie skryptu
. /etc/rc.d/rc.userconf
Ponadto aby konfiguracja była aktualizowana co 15 minut dopisujemy do tablicy crontab
następującą linkę.
0,15,30,45 * * * * /etc/rc.d/rc.userconf 1> /dev/null 2> /dev/null
Statystyki
Zliczanie ruchu IP
Aby można było zastosować zliczanie pakietów przechodzących przez serwer stworzymy
nową tablicę odpowiedzialną za statystyki i podepniemy ją na początku tablicy FORWARD.
Oto co należy dodać do pliku konfiguracyjnego firewall a.
echo " - ip account"
# tables definition
iptables -X F_ACCOUNT 2> /dev/null
iptables -N F_ACCOUNT
iptables -I FORWARD 1 -j F_ACCOUNT
# calosciowy ruch przychodzacy
iptables -A F_ACCOUNT -d 192.168.1.0/24 -i eth0
# calosciowy ruch wychodzacy
iptables -A F_ACCOUNT -s 192.168.1.0/24 -i eth1
31
# pojedynczy ruch przychodzacy
iptables -A F_ACCOUNT -d 192.168.1.27 -i eth0
...
# pojedynczy ruch wychodzacy
iptables -A F_ACCOUNT -s 192.168.1.27 -i eth1
...
Tworzymy również skrypt zrzucający statystyki i zerujący liczniki co godzinę (plik znajduje
się w katalogu /serwer/ pod nazwą cron.ipaccount).
#!/bin/sh
# katalog na statystyki
STAT_DIR="/var/stat/"
ACT_MIN=`date +%M`
ACT_HOUR=`date +%H`
ACT_DAY=`date +%d`
ACT_MOUNTH=`date +%m`
ACT_YEAR=`date +%Y`
# nazwa pliku
ACT_FILE="${STAT_DIR}${ACT_YEAR}.${ACT_MOUNTH}.${ACT_DAY}.${ACT_HOUR}.log"
#############################################################################
if [ "${ACT_MIN}" -ge "55" ]; then
# zapisz statystyki I zeruj licznik
iptables -L F_ACCOUNT -Z F_ACCOUNT -v -n -x >> ${ACT_FILE}
else
# zapisz statystyki
iptables -L F_ACCOUNT -v -n -x >> ${ACT_FILE}
fi
I podpinamy go do tablicy crontab (całość w jednej lnice), tak by statystyki generowane były
co 5 minut.
0,5,10,15,20,25,30,35,40,45,50,55 * * * * /etc/rc.d/cron.ipaccount
1> /dev/null 2> /dev/null
Statystyki klas
Możliwe jest podglądniecie aktualnego użycia pasma dla klass. Oto przykład statystyk dla
serwera pierwszego
#tc class ls dev eth0
class htb 1:1 root rate 768Kbit ceil 768Kbit burst 15Kb cburst 2582b
class htb 1:10 parent 1:1 leaf 10: prio 1 rate 48Kbit ceil 768Kbit burst 15Kb
cburst 2582b
class htb 1:100 parent 1:1 leaf 100: prio 3 rate 48Kbit ceil 768Kbit burst 15Kb
cburst 2582b
class htb 1:20 parent 1:1 leaf 20: prio 1 rate 144Kbit ceil 768Kbit burst 15Kb
cburst 2582b
class htb 1:30 parent 1:1 leaf 30: prio 2 rate 288Kbit ceil 768Kbit burst 15Kb
cburst 2582b
class htb 1:40 parent 1:1 leaf 40: prio 2 rate 240Kbit ceil 768Kbit burst 15Kb
cburst 2582b
Poszerzone statystyki można uzyskać przy pomocy parametru  s.
#tc -s class ls dev eth0
32
class htb 1:1 root rate 768Kbit ceil 768Kbit burst 15Kb cburst 2582b
Sent 6030142 bytes 5111 pkts (dropped 0, overlimits 0)
rate 28651bps 21pps
lended: 3387 borrowed: 0 giants: 0
tokens: 90203 ctokens: -16273
class htb 1:10 parent 1:1 leaf 10: prio 1 rate 48Kbit ceil 768Kbit burst 15Kb
cburst 2582b
Sent 233 bytes 3 pkts (dropped 0, overlimits 0)
lended: 3 borrowed: 0 giants: 0
tokens: 2039468 ctokens: 20991
class htb 1:100 parent 1:1 leaf 100: prio 3 rate 48Kbit ceil 768Kbit burst 15Kb
cburst 2582b
Sent 5989924 bytes 4906 pkts (dropped 0, overlimits 0)
rate 28546bps 20pps
lended: 1519 borrowed: 3387 giants: 0
tokens: -103633 ctokens: -16273
class htb 1:20 parent 1:1 leaf 20: prio 1 rate 144Kbit ceil 768Kbit burst 15Kb
cburst 2582b
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 682666 ctokens: 21524
class htb 1:30 parent 1:1 leaf 30: prio 2 rate 288Kbit ceil 768Kbit burst 15Kb
cburst 2582b
Sent 778 bytes 13 pkts (dropped 0, overlimits 0)
lended: 13 borrowed: 0 giants: 0
tokens: 339200 ctokens: 20726
class htb 1:40 parent 1:1 leaf 40: prio 2 rate 240Kbit ceil 768Kbit burst 15Kb
cburst 2582b
Sent 39207 bytes 189 pkts (dropped 0, overlimits 0)
rate 104bps
lended: 189 borrowed: 0 giants: 0
tokens: 407042 ctokens: 20726
Na potrzeby przykładu wygenerowano znaczny ruch poprzez program Kazza, który poszedł
przez klasę 1:100, co widać na powyższym wydruku. Można zauważyć że klasa wypożyczyła
pasmo do wysłania 3387 pakietów a tylko 1519 przeszło z podstawową szybkością.
Serwer 1
Poniższy rysunek przedstawia konfigurację interfejsów rutera.
Rysunek 6 Interfejsy pierwszego serwera
33
Konfiguracja kolejek
Budowa kolejki dla obydwóch interfejsów jest identyczna zmienia się tylko wartość
określająca pasmo.
Rysunek 7 Konfiguracja kolejek dla interfejsu eth0 i eth1 (serwer 1)
Jak widać ruch nie sklasyfikowany trafia do klasy 1:100. Odpowiednie klasy mają
następujące przyporządkowanie:
" 1:10  usługa rozwiązywania nazw DNS
" 1:20  połączenia zdalne SSH i Telnet
" 1:30  poczta, połączenia POP3 i IMAP
" 1:40  strony WWW i proxy WWW
" 1:100  wszystkie inne usługi
Dodatkowo klasom nadano priorytety zgodnie z założeniami co do ruchu interaktywnego (1),
z małymi opóz
nieniami (2) i ruch ciężki (3). Poprzez tak wysoki priorytet DNS uzyskujemy
szybsze nawiązywanie połączenia.
Wszystkie reguły filtrujące podpinane są do kolejki qdisc 1:, a dokładne reguły znajdują się w
katalogu /serwer/1/ w pliku rc.qos i rc.qos_eth1. Dodatkowo w pierwszym przypadku plik
rc.qos jest wykonywany przez cron a co godzinę w celu konfiguracji odpowiedniej
przepustowości łącza. Oto wpis w tablicy crontab.
0 * * * * /etc/rc.d/rc.qos 1> /dev/null 2> /dev/null
Ponadto w pliku rc.qos znajduje się również definicja kolejki przychodzącej.
Dla ruchu wychodzącego do sieci lokalnej ustawione szerokość pasma na 8 Mbps w celu
zabezpieczenia serwera i sieci przed nadmiernym obciążeniem np. przez usługę FTP
bezpośrednio z serwera do sieci lokalnej.
Serwer 2
Poniższy rysunek przedstawia konfigurację interfejsów rutera.
34
Rysunek 8 Interfejsy drugiego serwera
Konfiguracja kolejek
W celu identyfikacji pakietów pochodzących z interfejsu eth1 a wychodzących przez ppp0,
jak i w przeciwnym kierunku do pliku konfiguracyjnego firewall a dodano następujące liniki.
iptables -F -t mangle
iptables -t mangle -A PREROUTING -i eth1 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i ppp0 -j MARK --set-mark 1
Pierwsza z nich czyści łańcuchy w rozszerzeniu mangle. Druga markuje pakiety
przychodzące z interfejsu eth1 druga markuje pakiety przychodzące z interfejsu ppp0.
Interfejs ppp0
Konfigurację kolejek i klas dla interfejsu ppp0 przedstawia rysunek poniżej.
Rysunek 9 Konfiguracja kolejek dla interfejsu ppp0 (serwer 2)
Jak widać konfiguracja jest oparta o dwa poddrzewa dla każdej z podsieci. Młodsze numery
klas w poddrzewach mają analogiczną funkcję jak klasy w przypadku konfiguracji kolejek na
interfejsach sieciowych serwera pierwszego.
Jedynym filtrem jaki został podpięty do korzenia jest klasyfikator fw kierujący pakiety
oznaczone znacznikiem 1 do klasy 1:20, a składowane są w kolejce qdisc 20:. Pozostały ruch
35
trafia do kolejki 20:. Zarówno w kolejce 10: i 20: pakiety są ponownie filtrowane i rozsyłane
do odpowiednich klas podobnie jak w przypadku serwera pierwszego.
Również do tego interfejsu podpięto kolejkę dla ruchu przychodzącego i filtr określający
maksymalną szybkość pakietów przychodzących.
Dokładne reguły filtrowani znajdują się w katalogu /serwer/2/ w pliku rc.qos_ppp0.
Interfejs eth1 i eth0
Konfiguracja kolejek dla ruchu wychodzącego przez interfejs eth1 wygląda następująco.
Rysunek 10 Konfiguracja kolejek dla interfejsu eth1 (serwer 2)
Podobnie jak w przypadku interfejsu ppp0 mamy tu poddrzewo dla ruchu pochodzącego z
Internetu. Jedyny filtr podpięty do korzenia kieruje pakiety oznaczone znacznikiem 1 do
kolejki 20:, gdzie następne filtry kierują pakiety konkretnych usług do konkretnych kolejek.
Cały ruch związany z danymi pochodzącymi z serwera i podsieci kierowany jest do kolejki
10:.
Interfejs eth0 drzewo klas i kolejek, jak i filtry klasyfikujące pakiety są identyczne jak w
przypadku serwera pierwszego.
Z tych samych powodów co w przypadku serwera pierwszego również i tu maksymalne
pasmo ograniczono poniżej wartości maksymalnej. W tym przypadku na 95 Mbps.
Dokładne reguły filtrowani znajdują się w katalogu /serwer/2/ w pliku rc.qos_eth0 i
rc.qos_eth1.
36
Zawartość CD
Zawartość CD ze względu na objętość nie została dołączona do pakietu, z wyłączeniem
katalogu serwer.
" /Pliki/  pliku niezbędne do wykonania zadań
" linux-2.4.18.tar.gz  wersja z
ródłowa jądra4
" iproute2-2.4.7-now-ss020116-try.tar.gz  z
ródła iproute2
" iproute2-2.4.7-now-ss020116-try-i386-1.tgz  wersja binarna iproute2 dla Slackware
" htb3.5-020521.tgz  pakiet zawierający poprawki dla jądra w wersji 2.4.x i iproute2,
jak również poprawiona wersja binarna pliku tc do obsługi kolejki HTB w wersji 3
" /Dokumentacja/ - katalog z dokumentami z bibliografii
" /serwer/ - pliki konfiguracyjne serwerów
" Referat.doc  aktualny dokument w wersji MS Word 2000
4
http://www.kernel.org
37
Bibliografia
Podstawowe materiały
" Kształtowanie Ruchu i Zaawansowany Ruting HOWTO (ang. Linux 2.4 Advanced
Routing & Traffic Shaping HOWTO)  Tłumaczenie: A
ukasz Bromirski 
http://mr0vka.eu.org/tlumaczenia/2.4routing.pl.html (http://ds9a.nl)
" Linux Network Administrators Guide - http://www.linuxdoc.org/
" http://luxik.cdi.cz/~devik/qos/htb - HTB Home Page
" Securing and Optimizing Linux: RedHat Edition v1.3  Autor: Gerhard Mourani 
http://www.linuxdoc.org
Materiały pomocnicze
Wszystkie materiały pomocnicze znajdują się w odpowiednim katalogu na CD dołączonym
do niniejszego opracowania.
Adresy
Poniżej przedstawiono kilka adresów skąd można poprać ciekawe dokumenty na temat
kształtowania ruchu, filtrowania w Linux ie.
" Adresy plików z dokumentacją poleceń i funkcjonowania kolejek i kontroli ruchu 
http://defiant.coinet.com/iproute2/.
" Filtrowanie w pakietów w Linuksie 2.4 - http://mr0vka.eu.org/tlumaczenia/linux24-
pf.html.
" Linux 2.4 NAT HOWTO w wersji polskiej  http://mr0vka.eu.org/tlumaczenia/linux24-
pf.html.
38


Wyszukiwarka

Podobne podstrony:
Referaty
Obciążęnia podatkowe i ubezpieczeniowe referat
Referat Bermana
Tajny referat
uslugi wet referat
Referat kult ped
poranny krag referat
referat alkohole
Sytuacja instytucji bankowych na polskim rynku 2011 (referat)
Analiza ilościowo jakościowa procesów projektowania REFERAT
referat red hat
referat fizjo oddychanie na duzych wys i głębokościach
referat
Katyń [referat]
referat
Spinoza referat
04 referat Pieprzyk szczelność powietrzna

więcej podobnych podstron