• Strona nr 1 - Konfiguracja transferu na komputerze łączącym się z Internetem poprzez modem SDI (ppp0) zgodnie ze schematem:
  INTERNET ----- ppp0 - [Linux] - eth0 --------------[client]
• Strona nr 2 - Konfiguracja transferu na komputerze łączącym się z Internetem poprzez karte sieciową (eth0) zgodnie ze schematem:
  INTERNET ----- eth0 - [Linux] - eth1 --------------[client]
• Strona nr 3 (jesteśmy na niej) - Tłumaczenie pliku cbq.init v0.7.2 autorstwa Pavela Golubeva pg@ksi-linux.com
• Strona nr 4 - Przykłady plików konfiguracyjnych moich znajomych z Internetu oraz ich uwagi i pytania.

TŁUMACZENIE PLIKU cbq.init v0.7.2

README CBQ

Po pierwsze, niniejszy opis to tylko prosty przykład tego, co naprawdę potrafi CBQ. Nie pytaj mnie "dlaczego" i "jak" :) Ten skrypt powstał, aby uprościć pracę przy nadzorze połączeń w sieci postawionej na Linuksie. Dostęp do bardziej zaawansowanych właściwości pracy w sieci jest możliwy poprzez narzędzia "ip" i "tc" z pakietu A. Kuznetsova, dostępnego na ftp://ftp.inr.ac.ru/ip-routing . Ponieważ wspomniane narzędzia są używane przede wszystkim do tłumaczenia życzeń użytkownika na komendy RTNETLINK, ich interfejs jest spartański, nieprzyjazny i wymagający długotrwałego wklepywania danych. Aby ułatwić sobie pracę i uniknąć mozolnego wstukiwania na klawiaturze - autor Pavel Golubev utworzył niniejszy skrypt :) Ponieważ za prostotę trzeba płacić, nie oczekuj bardzo wyrafinowanych możliwości po tym skrypcie. Być może za jakiś czas sięgniesz po narzędzia "ip" i "tc" z pakietu A. Kuznetsova, dostępnego na ftp://ftp.inr.ac.ru/ip-routing.

Aby przyspieszyć komendę start, od wersji 0.6.4 zastosowano prosty caching (keszowanie). Caching ten pracuje tak, że następstwo komendy "tc" dla danej konfiguracji jest przechowywane domyślnie w pliku (/var/cache/cbq.init). Dzięki temu, gdy komenda "start" jest ponownie uruchamiana, można uniknąć powtórnego ustawiania plików konfiguracyjnych. Cache został tak zaprojektowany, że jego zawartość zostaje unieważniana, gdy jakikolwiek z plików konfiguracyjnych CBQ zmienia się. Jeśli chcesz uruchomić polecenie cbq.init start bez funkcji cachingu, uruchom go z opcją nocache: cbq.init start nocache (polecane na poczatku nauki, gdyż tylko wtedy sprawdzana jest poprawność konfiguracji). Jeśli chcesz wyczyścić zawartość cache, uruchom plik zleceniem cbq.init start invalidate. Uwaga na marginesie: caching jest niemożliwy, jeśli masz zablokowane logowanie (np. CBQ_DEBUG nie jest pusty).

W przypadku bardziej zaawansowanych wymagań, jeśli chcesz, aby CBQ jedynie tłumaczył Twoją konfigurację na komendy "tc" użyj polecenia cbq.init start compile, która wyprodukuje komendy "tc" mające zbudować twoją konfigurację. Zapamiętaj, że "compile" nie sprawdza, czy komendy "tc" są prawidłowe - tak dzieje się tylko, jeżeli jest używane polecenie cbq.init start nocache

Wszystkie parametry CBQ są ważne tylko dla interfejsów Ethernet. Skrypt był testowany na różnych wersjach jądra Linuksa, od serii 2.1 do 2.4 i wielu dystrybucjach.

Schemat sieci (będę go kopiował we właściwych miejscach objaśnień, w celu ułatwienia ich rozumienia).

INTERNET ----- eth0 - [Linux ] - eth1 --------------[client]
lub
INTERNET ----- ppp0 - [Linux ] - eth0 --------------[client]

W pierwszym przykładzie Internet jest dostarczany poprzez kartę sieciową (interfejs eth0), a w drugim za pośrednictwem modemu (interfejs ppp0).

JAK TO DZIAŁA?

CBQ (podobnie jak zresztą HTB) umożliwia jedynie ograniczenie wychodzącego ruchu. Uzyskamy więc bez problemu kontrolę przepływu od klientów do netu. Niestety najczęściej jest to za mało. Dlatego aby założyć ograniczenia transferu z Internetu do klienta wykorzystano logiczną sztuczkę i wprowadzono ograniczenie na transfer o kierunku: od serwera do klienta. Co uzyskano? Skoro transfer z netu musi przejść przez serwer i następnie dojść do klienta, to wystarczy ograniczyć ten kierunek, a ostatecznie uzyskamy kontrolę nad transferem z netu do klienta ;) Minusem jest lekkie przyblokowanie wewnętrznej komunikacji pomiędzy klientami korzystającymi z netu i jednocześnie na tym samym interfejsie przerzucającymi duże pakiety do innych klientów w swojej wewnętrznej sieci ;( Rozwiązaniem tego problemu są narzędzia dla bardziej zaawansowanych...

Skrypt cbq.init pobiera dane z plików konfiguracyjnych umieszczonych w /etc/sysconfig/cbq/ . Każdy klient-host z sieci może mieć dla siebie dwa pliki konfiguracyjne. Jeden z parametrami interfejsu dostarczającego transfer OD SERWERA DO KLIENTA (np. kartą sieciową na interfejsie [eth1]), a drugi z parametrami interfejsu dostarczającego transfer OD KLIENTA DO Internetu (kartą sieciową na serwerze, na interfejsie [eth0] lub modemie [ppp0]). Tzw. klasa komunikacyjna to nic innego jak parametry pobrane z jednego pliku.

Teoretycznie i wyjątkowo można utworzyć tylko jeden plik konfiguracyjny (oczywiście osobno dla każdego klienta w podsieci) zamiast pary. Przejmie on na siebie jedynie regulację transferu wyjściowego (od klienta do netu) na interfejsie (eth0) - opiszę to za chwilę. Teraz zajme się konfiguracją opartą na parze plików dla każdego hosta.

Na początek zajmiemy się nazwami w/w plików konfiguracyjnych (przyjmijmy, że są to na razie puste pliki tekstowe). Przykład możliwych nazw klas konfiguracyjnych (czyli niniejszych plików konfiguracyjnych) dla pierwszego hosta:

cbq-0002.nazwapliku_nr1
cbq-0003.nazwapliku_nr2

Dla drugiego hosta będą numery:

cbq-0004.nazwapliku_nr1
cbq-0005.nazwapliku_nr2

dla trzeciego hosta itd:

cbq-0006.nazwapliku_nr1
cbq-0007.nazwapliku_nr2

W nazwiepliku_nrx można dla swojej wygody umieścić nazwę interfejsu i kierunek transferu (skąd_dokąd). Wtedy bedzie wyglądała nieco inaczej:

INTERNET ----- eth0 - [Linux ] - eth1 --------------[client]

cbq-0002.eth1_serwer_klient
cbq-0003.eth0_klient_net

lub w przypadku dostarczania netu poprzez modem:

INTERNET ----- ppp0 - [Linux ] - eth0 --------------[client]

cbq-0002.eth0_serwer_klient
cbq-0003.ppp0_klient_net

Dla pewnego porządku przyjąłem, że pierwszy plik zajmuje się interfejsem pomiedzy serwerem, a klientem, (czyli nadzoruje transfer z netu do klienta), natomiast drugi z danej pary zajmuje się interfejsem działajacym pomiedzy klientem, a netem. Konsekwentnie stosuj tę zależność podczas konfiguracji.

W nazwy nie wolno wprowadzać spacji! Zauważyłeś, że część tytułu pliku może się dowolnie zmieniać, a część musi być zgodna ze stałymi, narzuconymi rygorami? Nazwy plików konfiguracyjnych muszą bowiem przestrzegać określonego formatu: cbq-<clsid>.<nazwa> (oczywiście znaki < > służą jedynie poprawieniu przejrzystości zapisu i NIE WOLNO ich wprowadzać w oryginalnych zapisach!). Wyjaśnienie: <clsid> jest dwubajtową hexagonalną liczbą rzędu <0002-FFFF> (która tak naprawdę jest numerem porządkowym formatu CBQ - zwróć uwagę, że pierwszy możliwy numer to 0002, a nie np. 0000, 0001) . <nazwa> jest nazwą klasy komunikacyjnej. W małej sieci, przy małej ilości klas jest często możliwe (i wskazane) pozwolić <clsid> być podobnym do <bandwidth> klasy (czym jest bandwidth powiem za chwilę, teraz przyjmujemy, że nasza numeracja zaczyna się od 0002).

Plik konfiguracyjny zawiera następujące parametry:

INTERNET ----- eth0 - [Linux ] - eth1 --------------[client]

Parametr DEVICE.

DEVICE=<ifname>,<bandwidth>[,<weight>]

Uwaga: nie wpisujemy nawiasów < > [ ] czyli w praktyce pierwszy wiersz będzie wyglądać np. tak:

DEVICE=eth0,10Mbit,1Mbit
lub tak:
DEVICE=eth0,100Mbit,10Mbit

w zależności od szybkości transferu na interfejsie eth0.

Wyjaśnienie:

ifname> jest nazwą interfejsu, na którym chcesz kontrolować komunikację, np. eth0, eth1, ppp0.

bandwidth> jest w tym przypadku zmierzoną, maksymalną wielkością transferu na danym interfejsie (karty sieciowe ethernetu mogą mieć 10Mbit lub 100Mbit, natomiast arcnet ma aż 2Mbit). Uwaga: parametr bandwidth znaczy MAKSYMALNA DOPUSZCZALNA WIELKOŚĆ TRANSFERU na danym łączu i może być ograniczony możliwościami sprzętowymi (j.w.) lub programowymi (przy pomocy CBQ - o tym za chwilę). <weight> jest wynikiem podzielenia wartości <bandwidth> przez 10. Taka proporcja jest wskazana do poprawnej pracy scryptu, więc nie kombinuj tylko przelicz.

Tu dotykamy pierwszego poważnego problemu: jak ustalić wielkość transferu na poszczególnych interfejsach? Wiadomo, że karty sieciowe mogą pracować z wydajnością 100Mbit lub 10Mbit, choć w rzeczywistości wielkości te mogą być inne np. 83Mbit. Musisz zmierzyć ten parametr, ale to jest materiał na inną opowieść. Możesz mieć Internet dostarczany na kartach sieciowych, ale dużo poniżej ich możliwości np. na poziomie 65 Kbit. Podobnie rzecz ma się z interfejsem ppp0 na modemie. Proszę zwrócić uwagę, że usługa SDI-HIS powinna gwarantować transfer na poziomie 115Kbit, czyli w zaokrągleniu 100Kbit, ale jest to suma transferu przychodzącego i wychodzącego. Pamiętaj też, że różne wartości może mieć transfer z netu i do netu (dużo zależy od umowy zawartej z dostarczycielem usług internetowych).

Jeśli w jednym interfejsie masz więcej klas, czyli - jeżeli w jednym interfejsie pracuje większa ilość hostów, które będziesz nadzorować przy pomocy CBQ, to wystarczy tylko w jednym pliku określić <bandwidth>[i <weight>]. Wówczas w innych plikach wystarczy wpisać tylko DEVICE=<ifname> (ale jeżeli podasz powtórnie <bandwidth>[i <weight>] to nic się nie stanie, ale uważaj i nie pomyl się).

O tym czy dany plik konfiguracyjny zajmuje się transferem w jedną lub w drugą stronę (biorąc pod uwagę kolejność wpisów w nim), decyduje przecinek na końcu adresu IP w linii RULE (o tym za chwilę).

Parametry klas komunikacyjnych

INTERNET ----- eth0 - [Linux ] - eth1 --------------[client]

Parametr RATE.

RATE=<speed>

Uwaga nie wpisujemy nawiasów < > [ ] czyli w praktyce drugi wiersz będzie wyglądać np. tak:

RATE=5Mbit

Ustalamy wielkość maksymalnego, dopuszczalnego transferu dla danego hosta na danym interfejsie. Przy próbie przekroczenia tego parametru nastąpi automatyczna reakcja CBQ i przyblokowanie transferu. Fachowo to się nazywa przydzieleniem dopuszczalnego transferu do klasy komunikacyjnej. Możesz używać jednostek Kbit, Mbit lub bps, Kbps i Mbps, jednak dla własnej wygody lepiej będzie, jeżeli je ujednolicisz i zastosujesz jeden rodzaj we wszystkich wpisach. Jeśli nie określisz żadnej jednostki, użyte zostaną bity na sekundę.

Uwaga:

• w pierwszym pliku z danej pary (przypominam, że jeden host jest właścicielem jednej pary plików, z której pierwszy odpowiada za interfejs łączacy serwer z klientem, a drugi klienta z netem) określamy wielkość maksymalnego transfereu z serwera do klienta.
  Jeżeli Internet jest dostarczany do serwera poprzez modem, to prawdopodobnie szybkość transferu jest znacznie gorsza od wewnętrznego interfejsu opartego na kartach sieciowych i logicznym jest, że na tej wartości się oprzemy. Należy więc ustalić z dostawcą usług internetowych wielkość maksymalnego transferu z netu do naszego Linuksa i następnie podzielić go na równe części zależne od ilości klientów. Oczywiście można też dzielić nierównomiernie, jednak należy pamiętać, aby suma przydziału pokrywała się z wielkością transferu dostarczanego z netu.

• w drugim pliku z danej pary określamy wielkość maksymalnego transferu od klienta do Internetu. Zwróć uwagę na przecinek umieszczony za numerem IP w linii RULE.

INTERNET ----- eth0 - [Linux ] - eth1 --------------[client]

Parametr WEIGHT

WEIGHT=<speed>

Uwaga nie wpisujemy nawiasów < > [ ] czyli w praktyce trzeci wiersz będzie wyglądać np. tak:

WEIGHT=500Kbit

Ustalamy parametr, który powinien być proporcjonalny do RATE. Praktyczna zasada: WEIGHT~=RATE /10 czyli WEIGHT w przybliżeniu równa się jednej dziesiątej wyżej wpisanego RATE. Uwaga: w przypadku, gdy wynik 1/10 nie będzie liczbą całkowitą, musisz zaokraglić ją do pełnej wartości. Inaczej mówiąc będziesz musiał przeliczyć jednostkę na mniejszą lub... zaokrąglić wynik (rezygnując ze ścisłej proporcji 1/10 na rzecz np. 1/5).

INTERNET ----- eth0 - [Linux ] - eth1 --------------[client]

Parametr PRIO

PRIO=<1-8>

Uwaga nie wpisujemy nawiasów < > [ ] czyli w praktyce czwarty wiersz będzie wyglądać np. tak:

PRIO=5

Priorytet komunikacji klasy. Im wyższa liczba, tym mniejszy priorytet. Priorytet 5 jest w sam raz. Dla ważnych klientów daj 1 lub 2, a dla niepłacących np. 8 ;)

INTERNET ----- eth0 - [Linux ] - eth1 --------------[client]

Parametr RULE

Parametr RULE daje znaczne możliwości konfiguracyjne, które zostały opisane szerzej w części zielonej. Tutaj jedynie podam, że do poprawnej pracy CBQ wystarczą wpisy:

• w pierwszym pliku z danej pary określamy wielkość maksymalnego transfereu z serwera do klienta. Wpisujemy więc adres klienta. np. 192.168.0.2 (bez przecinka!)
  RULE=192.168.0.2

• w drugim pliku z danej pary określamy określamy wielkość maksymalnego transfereu od klienta do netu biorąc pod uwagę możliwości interfejsu eth0 (ewentualnie ppp0). Zwróć uwagę, że na końcu jest umieszczony przecinek (w powyższym pliku przecinka nie ma)! Przecinek wskazuje, że kierunek transferu odbywa się od klienta z IP 192.168.0.2 do netu.
  RULE=192.168.0.2,

Wzór pojedyńczego pliku konfiguracyjnego: cbq-1280.my_first_shaper

dla sieci:INTERNET -----eth0--[ Linux ] - eth1 -----[klienty w sieci 192.168.0.0/24 ]

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DEVICE=eth0,10Mbit,1Mbit
RATE=128Kbit
WEIGHT=10Kbit
PRIO=5
RULE=192.168.0.0/24

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Taka konfiguracja mówi nam, że pracujemy na interfejsie eth0 (karcie sieciowej) o przepustowości 10Mbit. Transfer od każdego klienta (z sieci 192.168.1.0/255.255.255.0) do netu, będzie przebiegać na poziomie maksymum 128Kbit. z priorytetem 5.

Zauważ, że możesz w ten sposób kontrolować tylko wychodzący transfer. Jeśli chcesz kontrolować komunikację w obu kierunkach, musisz ustawić CBQ na oba interfejsy, tworząc parę plików dla każdego hosta-klienta.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Rozpatrz następujący przykład:

INTERNET ----- eth0 - [Linux ] - eth1 -------------[client 192.168.1.1]

Wyobraź sobie, że chcesz przydusić transfer z INTERNEu do klienta na poziomie 28Kbit i komunikację w przeciwnym kierunku na poziomie 128Kbit. Musisz ustawić CBQ zarówno na interfejs eth0, jak i eth1, tak więc potrzebujesz dwóch plików konfiguracyjnych.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

cbq-028.backbone-client

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DEVICE=eth1,10Mbit,1Mbit
RATE=28Kbit
WEIGHT=2Kbit
PRIO=5
RULE=192.168.1.1

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

cbq-128.client-backbone

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

DEVICE=eth0,10Mbit,1Mbit
RATE=128Kbit
WEIGHT=10Kbit
PRIO=5
RULE=192.168.1.1,

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Zwróć uwagę na przecinek (,) w polu RULE - oznacza on adres źródła, czyli wskazuje kierunek transferu!

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

i pozostałe parametry (wskazane dla zaawansowanych użytkowników)

PARENT=<clsid> opcjonalne, domyślnie nieustawiane

Uwaga nie wpisujemy nawiasów < > [ ] czyli w praktyce czwarty wiersz będzie wyglądać np. tak:

PARENT=1280

Dotykamy tutaj nowego pojęcia: hierarchicznej struktury typu rodzic-dziecko. Jeżeli komputer-rodzic będzie miał mały pobór danych, to ewentualną nadwyżkę spożytkuje komputer-dziecko (lub grupa komputerów-dzieci). W parametrze PARENT ustawiamy numer komputera-rodzica (czyli ID rodzicielskiej klasy - parent class). Jeżeli użyjesz LEAF=none lub LEAF= sfq , to możliwe stanie się stworzenie prostych hierarchicznych struktur klas CBQ. Ustawianie takie jest ważne, bo rodzicielskie klasy są skonstruowane priorytetowo do swoich dzieci. Patrz LEAF , BOUNDED oraz ISOLATED.

LEAF=tbf|none|sfq opcjonalne, domyślne jest "tbf"

Narzuca metodę pracy (dyscyplinę klasy): CBQ lub TBF (ew. None). Przy braku wpisu, domyślnie używane jest TBF. Zapamiętaj, ze powiązywanie TBF z klasą CBQ kształtuje komunikację do dostosowania do parametrów TBF i powstrzymuje klasę (czyli dany plik konfiguracyjny) przed pożyczaniem transferu od swoich rodziców nawet, jeśli masz BOUNDED ustawione na "no". By pozwolić klasie na pożyczanie transferu (o ile oczywiście nie jest to blokowane w innym parametrze), musisz ustawić LEAF na "none" lub "sfq".

Uwaga: jeśli chcesz zapewnić sprawiedliwe (w przybliżeniu) dzielenie transferu pomiędzy różne hosty w tej samej klasie, określ LEAF=sfq, by ustalić SFQ jako metodę pracy dla tej klasy (tego pliku konfiguracyjnego).

BOUNDED=yes/no opcjonalne, przy braku wpisu widziane jako "yes"

Jeśli ustawione na "yes", klasa nie może pożyczać transferu od swojej rodzicielskiej klasy. Jeśli ustawione jest na "no", klasa będzie mogła pożyczać transfer od swojego rodzica.

Uwaga: nie zapomnij ustawić LEAF na "none" lub "sfq", bo inaczej klasa będzie miała powiązane ze sobą TBF i nie będzie mogła pożyczyć nieużywanego transferu (bandwidth) od swojego rodzica.

ISOLATED=no/yes opcjonalne, przy braku wpisu widziane jako "no"

Jeśli ustawiono na "yes", to klasa (czyli plik konfiguracyjny) nie pożyczy dzieciom swojej nieużywanej nadwyżki normy transferu.

###Ustalenie parametrów TBF qdisc

BUFFER=<bytes>[/<bytes>] opcjonalne, przy braku wpisu wynosi "10Kb/8"

Ten parametr kontroluje rozmiar token bucket. Innymi słowy, reprezentuje maksymalny rozmiar (burst size) jaki klasa może wysłać. Opcjonalna część parametru jest używana do określenia wielkości odstępstw(intervals in packet sizes)w rozmiarach pakietów, wobec których czas transmisji będzie utrzymywany.

LIMIT=<bytes> opcjonalne, przy braku wpisu wynosi "15Kb"

Ten parametr określa maksymalną długość backlog. Jeśli kolejka zawiera więcej danych niż określono przez LIMIT, nowo przybywające pakiety są odrzucane. Długość backlog jest parametrem regulującym tzw. ukrycie kolejki (czyli zatrzymanie jej działania) w przypadku przeciążenia.

PEAK=<speed> opcjonalne, przy brak wpisu jest u nieokreślone

Maksymalna szczytowa norma dla krótkotrwałego wzrostu wysyłanego transferu. Pozwoli Ci to na kontrolowanie teoretycznie nieograniczonej szczytowej normy, do której klasa może wysyłać. Niezorientowanym przypominam, że TBF bada sume pakietu w sekundowym interwale, co ma znaczenie, gdy część sekudy będzie bez transferu, a pozostała ze znacznie zwiększonym. Np. pojedynczy pakiet TBF ustawiony na 256Kbit/s może przepuścić 512Kbit na pół sekundy lub 1Mbit na ćwierć sekundy.

MTU=<bytes> opcjonalne, przy braku wpisu ustalone jest na "1500"

Maksymalna liczba bajtów które mogą być wysłane na raz. Ten parametr jest żądany, gdy określasz parametr PEK. Nie zgadza się z MTU ethernet - dla innych typów mediów możesz chcieć go zmienić. Patrz parametr QUANTUM. Przeczytaj notatkę o MTU w WinXP.

Notka: ustawienie TBF jako qdisc (TBF as leaf qdisc) efektownie powstrzyma klasę przed pożyczaniem transferu od klasy prządkowej, ponieważ nawet gdy klasa pozwala przejść większej ilości transferu, jest wtedy kształtowana tak, aby dostosować się do TBF.

###Parametry SFQ qdisc

Dyscyplina kolejkowa SFQ jest tanim sposobem na dzielenie transferu pomiędzy wiele hostów. Pamiętaj jednak, że jest to sposób ograniczony w mozliwościach konfiguracyjnych i jeśli chcesz precyzyjnego narzędzia prawdopodobnie powinieneś użyć WRR lub WFQ do kolejkowych dyscyplin. Zauważ, że SFQ nie kształtuje komunikacji - kształtowanie jest zrobione przez klasę CBQ z którą powiązane jest SFQ.

QUANTUM=<bytes> opcjonalne, przy braku nieokreślone

Ten parametr nie powinien być ustawiany na niższy niż link MTU, dla ethernet wynosi 1500b lub ( z MAC header) 1514b, która jest liczbą używaną w przykładach Alexego Kuznetsova.

PERTURB=<seconds> opcjonalne, przy braku 10"

Okres funkcji dopuszczalnego zamieszania. Jeśli nie jest ustawiony, bałagan rekonfiguracji nigdy nie będzie miał miejsca. Ilość dziesięciu sekund jest najprawdopodobniej tą właściwą.

###Parametry filtra

RULE=[[saddr[/prefix]][:port[/mask]],][daddr[/prefix]][:port[/mask]]

Te parametry tworzą zasady filtrów "u32" które wybierają komunikację dla każdej z klas. Możesz używać wielokrotnych RULE do konfiguracji.

Opcjonalny port mask powinien być używany tylko przez zaawansowanych użytkowników, którzy rozumieją pracę filtra "u32".

Kilka przykładów:

RULE=10.1.1.0/24:80

Wybiera komunikację idącą do portu 80 w domowej sieci 10.1.1.0/24

RULE=10.2.2.5

Wybiera komunikację idącą do każdego portu na pojedynczym hoście domowej sieci 10.2.2.5

RULE=10.2.2.5:20/0xfffe

Wybiera komunikację idącą do portów 20 i 21 na hoście z domowej sieci 10.2.2.5

RULE=:50,10.2.2.128/26:5000

Wybiera komunikację idącą z obojętnego miejsca nadanego na porcie 50 do portu 5000 w sieci 10.2.2.128/26

RULE=10.5.5.5:80,

Wybiera komunikację idącą z portu 80 na pojedynczym hoście 10.5.5.5

REALM=[srealm,][drealm]

Parametry REALM tworzą zasady filtrów "route", które klasyfikują komunikację zgodnie ze źródłem/przeznaczeniem dziedziny pakietu. Informacje o dziedzinach znajdziesz w Alexey Kuznetsovs IP Command Reference. Ten skrypt nie definiuje żadnych dziedzin, tylko buduje komendę "tc filter" dla Ciebie (jeśli chcesz sklasyfikować w ten sposób komunikację).

Dziedzina jest także dziesiętną liczbą lub ściśle powiązanym wejściem w /etc/iproute2/rt_realms (zazwyczaj).

Kilka przykładów:

REALM=russia,internet

Wybiera komunikację z dziedziny "russia" do dziedziny "internet"

REALM=freenet,

Wybiera komunikację idącą z dziedziny "freenet"

REALM=10

Wybiera komunikację idącą do dziedziny 10

MARK=<mark>

Te parametry tworzą zasady filtra "fw" które wybierają komunikację dla każdej z klas zgodnie z parametrem "mark" firewalla. Znak "mark" jest liczbą dziesiętną, którą pakiety są związane jeśli tak mówią zasady firewalla. Możesz używać kilkakrotnie pól MARK do konfiguracji.

Notka: Zasady dla różnych rodzajów filtrów mogą być łączone. Należy zwracać uwagę na priorytety zasad filtrów, które mogą być ustawione poniżej przez zmienne PRIO_{RULE,MARK,REALM}.

###Parametry zasięgu czasu.

TIME=[<dow>,<dow>,... ,<dow>/]<from>-<till>;<rate>/<weight>[/<peak>]

TIME=0,1,2,5/18:00-06:00;256Kbit/25Kbit

TIME=60123/18:00-06:00;256Kbit/25Kbit

TIME=18:00-06:00;256Kbit/25Kbit

Powyższy przykład TIME=0,1,2,5/18:00-06:00;256Kbit/25Kbit oznacza: że w niedzielę(0), poniedziałek(1), wtorek i piątek pomiędzy 18.00, a 6.00 rano transfer maksymalny będzie wynosił 256 Kbit. Parametr TIME może powtarzać się kilka razy w pliku konfiguracyjnym (tak jak np. RULE), co umożliwi rozplanowanie obciążenia na całą dobę. Tak więc parametr TIME pozwala na zróżnicowanie normy transferu w zależności od pory dnia. Możesz określić kilkakrotne parametry TIME, ale jeśli czasy pokryją się, to brana jest pod uwagę ostatnia dyrektywa. Pola <rate>, <weight> i <peak> odpowiadają parametrom RATE, WEIGHT i PEAK (który jest opcjonalny i stosowany jedynie do TBF qdisc).

Możesz także określać dni tygodnia kiedy zasada TIME jest stosowana. <dow> jest numeryczny, 0 odpowiada niedzieli, 1 - poniedziałkowi, itd.

Uwaga: otrzymałem z Internetu informację, że nie może być wpisu 16:00-17:00 , tylko musi być 16:00-16:59 . Ponadto, należy do crona wstawić wpis /etc/rc.d/init.d/cbq timecheck odpalany co np. 10 minut (lub jako root dawać od czasu do czasu polecenie /etc/rc.d/init.d/cbq timecheck z konsoli).

W tym miejscu autor umieścił skrypt CBQ, który usunałem. Był zbyt mocno rozbudowany (zawierał kilkaset wierszy) i ponieważ nie umieszczono już w nim komentarzy, uznałem za bezcelowe drukowanie go.

Tłumaczyli: Gosia i Mirek Twarogal
05.02.2003