Jak zrobić dzielenie łącza pod Linux'em - shaperd


UWAGA
Dzielenie łącza to uproszczona nazwa określająca różne metody regulowania szybkości pobierania danych z internetu przez użytkowików. Dzielenie łącza nie ma nic wspólnego z udostępnianiem łącza czyli z umożliwieniem użytkownikom wewnątrz sieci łączenia się z internetem za pośrednictwem serwera. Udostępnianie jest osobnym zagadnieniem i nie jest omówione na tej stronie (szukaj na wyszukiwarkach hasła: maskarada, masquerade, nat, firewall)




  1. Historia zmian
  2. Zasada działania
  3. Pobierz pliki
  4. Warunki działania
  5. Znane błędy
  6. Problemy
  7. FAQ
  8. Księga Gości

historia:

Na wstępie chciałbym zaznaczyć, że program ten jest w wersji beta a to znaczy, że jest niedostatecznie przetestowany i może sprawiać nijakie problemy. Należy się spodziewać, że będzie jeszcze nie raz uaktualniany.


Zasada działania:

Po włączeniu się w sieć nowego użytkownika i rozpoczęciu transmisji z internetem (lokalne połączenia nie rezerwują łącza), daemon przydziela część łącza wynikającą z prostego podziału szybkości maksymalnej łącza przez ilość aktualnie przez nie pracujących komputerów.
Po określonym czasie (zależnie od konfiguracji) - np. po 10 sekundach - shaperd sprawdza, czy użytkownik wykorzystał co najmniej 50% z przydzielonego łącza. Jeśli nie wykorzystał to zostaje mu przydział zmniejszony o 25%. Jeśli użytkownik wykorzystuje przydział w granicach 50%-75% to program niczego nie zmienia a jeśli wykorzystuje więcej od 75% to shaperd zwiększa mu transfer o minimalny transfer - pod warunkiem, że coś jeszcze zostało do przydzielenia. Zasada jest taka, że w pierwszej części daemon sprawdza, komu można obciąć a dopiero na samym końcu z tego co zostanie z przydzielania szybkości dodaje tym co dużo ciągną.
Dzięki temu program zapobiega przejęciu całkowitej kontroli nad łączem przez jednego nawiedzonego maniaka programów P2P lub idioty otwierającego kilkadziesiąt sesji WWW. Program ten reguluje transfer przychodzący z internetu do użytkowników, transfer wychodzący od użytkowników do internetu oraz transfer wychodzący z serwera do internetu.
Przy włączonej opcji extended_queue shaperd dodatkowo dla każdego użytkownika tworzy 4 podklasy z różnymi priorytetami.
Shaperd jest programem napisanym w języku C funkcjonalnie odpowiadającym skryptowi shaper_cbq.


Shaperd sam nie ogranicza transferu - on tylko tworzy odpowiednie reguły dla kernela. Resztą zajmuje sięjuż system. Shaperd jest więc w pewnym sensie nakładką na iproute2.


Uwaga

Istnieje, jak na razie nie rozwiązany, bład w kernelach 2.4.x polegający na tym iż niektóre połącznia wiszą ma maskaradzie przez 5 dni pomimo tego, że komputer, dla którego je utworzono nie był od kilku dni włączony w sieć. W przypadku shaperd problem wiszących połączeń obszedłem ignorując połączenia z czasem wygaśnięcia większym niż 600 sekund).


OSTRZEŻENIE

Autor tego oprogramowania nie bierze odpowiedzialności za jakiekolwiek błedy, awarie i uszkodzenia wywołane przez działanie tego programu. Wszystko co robisz - robisz na własną odpowiedzialność.
Program ten testowany jest na systemach opartych na jądrzach: 2.4.8, 2.4.12 i 2.4.18-grsec, 2.4.20-grsec, 2.4.21, 2.4.24, 2.6.8, firewall'ach na ipchains i iptables (1.2.6a, 1.2.7a) oraz na dystrybucjach: Mandrake 8.1, Mandrake 9.1, Mandrake 10.1 - łączach: SDI, iDSL 512Kbit, iDSL 1Mbit, DSL 768Kbit, asynchroniczne 1Mbit, Polpak 1Mbit, Polpak 2Mbit.


Jeśli masz jakiś problem z uruchomieniem tego programu - zanim do mnie napiszesz zaglądnij do sekcji Problemy.



Ostatnia wersja:shaperd.2.2.50.tar.gz (01.11.2009)

Starsze wersje 2.XX:
shaperd.2.2.47.tar.gz (26.08.2007)
shaperd.2.2.43.tar.gz (08.12.2006)
shaperd.2.2.42.tar.gz (05.08.2006)
shaperd.2.2.41.tar.gz (15.05.2006)
shaperd.2.2.23.tar.gz (18.10.2004)
shaperd.2.2.22.tar.gz (17.10.2004)
shaperd.2.2.11.tar.gz (20.03.2004)
shaperd.2.2.2.tar.gz (11.07.2003)
shaperd.2.200beta61.tar.gz (2.00beta61-26.04.2003)
shaperd.2.200beta59.tar.gz (2.00beta59-05.04.2003)
shaperd.2.200beta56.tar.gz (2.00beta56-07.03.2003)
shaperd.2.200beta44.tar.gz (2.00beta44-03.02.2003)
shaperd.2.200beta36.tar.gz (2.00beta36-19.01.2003)
shaperd.2.200beta28.tar.gz (2.00beta28-03.01.2003)
shaperd.2.200beta27.tar.gz (2.00beta27-28.12.2002)
shaperd.2.200beta26.tar.gz (2.00beta26-15.12.2002)
shaperd.2.200beta23.tar.gz (2.00beta23-08.12.2002)
shaperd.2.200beta22.tar.gz (2.00beta22-03.12.2002)
shaperd.2.200beta19.tar.gz (2.00beta19-15.11.2002)
shaperd.2.200beta17.tar.gz (2.00beta17-13.11.2002)
shaperd.2.200beta14.tar.gz (2.00beta14-12.11.2002)
shaperd.2.200beta11.tar.gz (2.00beta11-04.11.2002)
shaperd.2.200beta8.tar.gz (2.00beta8-01.11.2002)
shaperd.2.200beta6.tar.gz (2.00beta6-27.10.2002)
shaperd.2.200beta4.tar.gz (2.00beta4-26.10.2002)
shaperd.2.200beta3.tar.gz (2.00beta3-25.10.2002)

Starsze wersje 1.XX


Warunki działania

Aby wogóle dzielenie łącza pod Linuxem zaczęło działać to musi być spełnione wiele warunków:
  1. zainstalowany pakiet iproute2

  2. program tc oraz ipchains lub iptables powinny znajdować się w /sbin lub należy ustawic prawidłowo ścieżki do tych plików w pliku konfiguracyjnym (parametry: ipchains_path, iptables_path, tc_path).


  3. przekompilowane jądro aby obsługiwało CBQ (i/lub HTB) (nie wiem jak jest z innymi dystrybucjami ale w Mandrake od wersji 8.1 (i nowszych) oraz RedHat 9 (i nowszydh) CBQ (QoS) było wkompilowane standardowo przez dystrybutora więc nic nie musiałem kompilować. Od kerneli w wersji 2.4.18 róznież HTB jest wkompilowane standardowo.
    Jeśli nie wiesz, co ustawić do kompilacji to zaglądnij tutaj.

  4. Daemon współpracuje zarówno z ipchains jak i iptables (rodzaj firewalla jest rozpoznawany automatycznie).

  5. Nie jest potrzebne robienie jakichkolwiek wpisów na firewall'u specjalnie dla shaperd. Daemon robi wszystkie potrzebne wpisy sam przy starcie.

  6. Aby przetestować jądro pod kątem zgodności z CBQ trzeba zainstalować iproute2 (na Mandrake 8.1 iproute2 jest instalowane domyślnie) i wpisać komendę:
    tc -d qdisc
    Jeśli w wyniku jej działania pojawi się jakiś komunikat typu RTNETLINK error to jądro nie obsługuje CBQ (lub nie ma załadowanego modułu).
    Jeśli jest gotowe to ta komenda nic nie wyświetli (lub wyświetli przydzielone widełki).

  7. Aby działało dzielenie łącza wychodzącego oraz kolejkowanie (opcja extended_queue) firewall musi prawidłowo zaznaczać (MARK) pakiety. Niestety - na niektórych systemach jest z tym problem i nic na to nie jestem w stanie poradzić oprócz uaktualnienia firewalla/kernela/iproute2 (* - niepotrzebne skreślić ;)

Konfiguracja

  1. shaperd działa przy pewnych założeniach:
    • parametry łącz lokalnych w sieci należy wpisać do pliku konfiguracyjnego /etc/shaper/shaper.X.cfg - gdzie X to cyfra od 0-7 oznaczająca numer konfiguracji dla kolejnych, pracujących równolegle daemonów shaperd. W przypadku, gdy nie mamy zamiaru uruchamiać kilku shaper'ów - wystarczy używać cyfry 0 dla wszystkich plików konfiguracyjnych.

      Przykładowy plik konfiguracyjny dla serwera z 1 interfejscem lokalnym eth0 o przepustowości 10Mbit i łączem internetowym ppp0 o maksymalnej przepustowości 115Kbit (SDI). Używam go dla SDI i normalnej dzierżawki (po zmianie parametrów dotyczących szybkości ;).
      ipchains_path=/sbin/ipchains
      iptables_path=/sbin/iptables
      tc_path=/sbin/tc
      timeout_ipchains_22=3600
      timeout_ipchains_24=7200
      timeout_iptables_24=432000
      timeout_global=300
      start_speed=0
      even_division=no
      continuous_control=yes
      squid_support=no
      squid_port=8080
      divide_upload=yes
      extended_queue=no
      nomasq=yes
      check_sum_of_bandwidth=yes
      class_type=cbq
      upload_class_type=cbq
      check_download_factor_cnt=5
      check_upload_factor_cnt=5
      remove_dead_class=yes
      refresh_dead_fwrule=yes
      burst_type=maximum
      cburst_type=maximum
      htb_burst=8
      htb_cburst=8
      jump_type=5
      nop_factor=60
      add_factor=80
      speed_ext=bit
      delay_mesg=yes
      mask_mesg=yes
      check_firewall_counters=12
      debug=0
      delay=10
      write_delay=1
      delay_pools_download=0/100,5000/75,20000/50
      delay_pools_upload=0/100,5000/75,20000/50
      inter_int=ppp0;8000;92000;1000;60000;auto;1
      local_int=eth0;10485760;192.168.0.0/16;192.168.1.0/24;2
      
      Gdzie:
      • ipchains_path - ścieżka do ipchains
      • iptables_path - ścieżka do iptables
      • tc_path - ścieżka do tc
      • timeout_ipchains_22 - czas trzymania połączeń TCP na maskaradzie dla kerneli 2.2.x. Wartość ta jest wpisywana komendą ipchains -M -S. Po tym czasie wszystkie starsze, nieaktywne połączenia będą usuwane z tablicy maskarady.
      • timeout_ipchains_24 - czas trzymania połączeń TCP na maskaradzie ipchains dla kerneli 2.4.x - standardowo - na nieprzerabianych kernelach - ten czas wynosi 7200 minut czyli 5 dni. W przypadku gdyby ktoś sobie przerobił źródła ip_conntrack tak aby zmniejszyć ten czas to tu należy podać taki sam czas. Podobno w kernelu 2.4.20 jest już dołączona łatka pozwalająca zmieniać ten czas w prosty sposób bez potrzeby rekompilowania kernela.
      • timeout_iptables_24 - czas trzymania połączeń TCP na maskaradzie iptables dla kerneli 2.4.x - standardowo - na nieprzerabianych kernelach - ten czas wynosi 432000 sekund czyli 5 dni. W przypadku używania kerneli z przerobionym ip_conntrack i innym czasem należy tu podać prawdziwą wartość.
      • start_speed - sposób przydzielania łącza przy pojawieniu się nowego numeru ip. Dla 0 początkowa szybkość jest równą częścią szybkości łącza wynikłą z podziału szybkości przez ilość userów aktualnie z niego korzystających (np. dla SDI z 5 pracującymi userami = 100000/5 czyli 20000 (kbitów)). Dla wartości większych od 0 przydzielona szybkość jest wielokrotnością minimalnej prędkości gwarantowanej (takiej jak podana w parametrze lospeed w konfiguracji interfejsu internetowego inter_int).
      • even_division - yes załącza podział łącza po równo niezależnie od jego wykorzystania.
      • continuous_control - yes włącza ciągłą kontrolę transferów przez regułki QoS.
      • squid_support - włączanie współpracy ze SQUID'em (działa tylko z iptables). Wymagane jest aby squid pracował na serwerze którego numer IP mieści się w zakresie podanym w local_int (pierwszy numer z maską) (czyli najprościej - squid może działać na tym samym serwerze na którym działa shaperd). Ponadto aby squid działał należy go załatać zgodnie z opisem na stronie http://sed.pl/~mrk/qos/. Klasy tworzone komendą tc a opisane w sekcji Użycie tworzy shaperd więc nie ma potrzeby robić z nimi czegokolwiek. Testowałem ze squid-2.4.STABLE7 i działa. Dostępna jest już łatka na wersję squida 2.5STABLE3. Ponadto kolega Andrzej Romanowski podesłał mi swoją wersję łatki dla squida 2.5STABLE3 - squid-2.5_hit_miss_mark.patch. Dodatkowo dodałem wartość rules_olny która wymusza na shaperze tworzenie regułek liczących ruch dla squida ale nie kontrolujących ruchu ze squida. Używam tego na systemie gdzie są dwa łącza internetowe z tym, że dodatkowe łącze jest skonfigurowane tylko dla proxy.
      • squid_port - numer portu na którym pracuje squid.
      • divide_upload - yes włącza dzielenie łącza w kierunku wychodzącym do internetu.
      • extended_queue - yes włącza kolejkowanie w ramach indywidualnych przydziałów użytkowników (tylko dla iptables).
      • nomasq - yes wyłącza kontrolę aktualnych połączeń na maskaradzie. W przypadku wyłączenia, kontrola jest robiona na zasadzie obserwacji liczników odpowiednich regułek na firewall'u. Jeśli licznik jakiegoś numeru IP zwiększy się w czasie cyklu pracy o pewien próg (lospeed/4) to shaperd przydzieli dla niego widełki. Opcja przydatna dla tych, którzy nie używają maskarady lub posiadają przydzielone dodatkowe numery IP na lokalne interfejsy sieciowe (opcja w fazie testów!).
      • check_sum_of_bandwidth - yes włącza kontrolę sumy wszystkich przydzielonych widełek. Shaperd pilnuje aby suma przydziałów nie była większa niż szybkość łącza (z wyjątkiem sytuacji gdy ustawimy za dużą wartość lospeed
      • class_type - typ klasy zarządzający pasmem w kierunku download. Możliwe do wyboru klasy to: standardowa CBQ oraz HTB. Dodatkowe eksperymentalne klasy to: EHTB,SHTB,CWRR,HWRR,HFSC,SHFSC.
        • EHTB - shaperd nie kontroluje w HTB parametru rate a jedynie zmienia dynamicznie parametr ceil
        • . Powoduje to że klasy mają możliwość pożyczania między sobą niewykorzystanego pasma.
        • SHTB - shaperd nie kontroluje ani rate ani ceil. Jeśli shaperd wykryje ruch generowany przez użytkownika - tworzy klasę z parametrem rate o wartości lospeed czyli minimum gwarantowane dla usera (CIR) i z parametrem ceil o wartości hispeed czyli maksimum możliwe do osiągnięcia (EIR). Na tym się właściwie działanie shapera kończy. Klasy HTB w takiej konfiguracji same kontrolują ruch i wzajemnie od siebie pożyczają niewykorzystane pasmo (w teorii to wygląda ładnie). Rola shapera w tym przypadku sprowadza się jedynie do kontroli co cykl czy ruch rzeczywisty generowany przez usera nie jest większy od hispeed - w razie jego przekroczenia shaperd próbuje zmieniać wartość ceil do momentu aż szybkość będzie zgodna z założeniami.
          Po co taka kombinacja? Niektórzy twierdzą, że nie ma sensu używać shapera bo wystarczy utworzyć statycznie klasy HTB dając wszystkim userom jakiś minimalny rate i maksymalny ceil - w takim przypadku ruch będzie "sprawiedliwie" rozdzielany między użytkownikami. Włączając tą metodę podziału możemy sprawdzić jak to się ma do rzeczywistości. Generalnie z moich obserwacji wynika, że zarówno klasy CBQ jak i HTB bardzo chętnie pożyczają niewykorzystane pasmo - ale bardzo niechętnie je oddają. Jest oczywiście różnica w używaniu takiego podziału a nie używaniu żadnego podziału - ale ze sprawiedliwym podziałem nie ma to raczej wiele wspólnego. Używanie tego typu podziału ma jednak sens w pewnych specyficznych warunkach. Mamy sieć w której nie interesuje nas aby było sprawiedliwie - mamy spory zapas łącza a użytkownicy nie dostają nigdy dostępu do całego pasma a jedynie każdy dostaje wąskie widełki. Ruch taki będzie w ramach tych klas puszczony na żywioł. Zalety za to są inne - shaperd praktycznie nic tutaj nie robi - więc na słabych konfiguracjach sprzętowych i dużej ilości użytkowników będzie sens go używać (służy tu tylko do nadzoru czy któraś klasa się nie "wysypała").
      • upload_class_type - typ klasy zarządzający pasmem w kierunku upload. Możliwe do wyboru klasy to: standardowa CBQ,HTB,EHTB,SHTB,CWRR,HWRR,HFSC,SHFSC.
      • delay_pools_download - limity ilości przesłanych danych na sesję (działanie podobne do delay_pools w squidzie) - parametry podajemy w parach: ilość_danych/szybkość_w_procentach - kolejne stopnie oddzielamy przecinkiem - max ilość stopni - 10. W przykładowym pliku konfiguracyjnym zapis:
        delay_pools_download=0/100,5000/75,20000/50
        oznaczać będzie, że po otrzymaniu przydziału user będzie miał normalny przydział szybkości (100%), po pobraniu 5MB w czasie sesji przydział zostanie zmniejszony do 75% normalnego przydziału, po pobraniu 20MB prędkość będzie zmniejszona do 50% oryginalnego przydziału szybkości.
      • delay_pools_upload - analogicznie do delay_pools_download
      • check_download_factor_cnt - licznik zmniejszajacy się co cykl jeśli jakiś użytkownik pobiera dane z szybkością większą niż przydzielone widełki. Gdy licznik osiągnie 0 - w logu pojawia się komunikat Can't control download bandwidth of IP i jeśli jest włączona opcja remove_dead_class=yes shaperd usuwa tą klasę i w kolejnym cyklu tworzy ją ponownie. Dodatkowo gdy refresh_dead_fwrule=yes to wraz z klasą usuwane są z firewalla odpowiednie regułki usera a następnie ponownie tworzone. W przypadku używania CBQ wartość tego parametru powinna być większa od 0 ponieważ klasy z CBQ są niedokładne i obliczanie współczynnika korekcyjnego może potrwać nawet kilka cykli. Dla HTB pojawienie się takiego komunikatu może oznaczać nieprawidowe działanie klasy HTB lub znakowania pakietów MARK na firewallu.
      • check_upload_factor_cnt - licznik zmniejszajacy się co cykl jeśli jakiś użytkownik wysyła dane z szybkością większą niż przydzielone widełki. Gdy licznik osiągnie 0 - w logu pojawia się komunikat Can't control upload bandwidth of IP i jeśli jest włączona opcja remove_dead_class=yes shaperd usuwa tą klasę i w kolejnym cyklu tworzy ją ponownie. W przypadku używania CBQ wartość tego parametru powinna być większa od 0 ponieważ klasy z CBQ są niedokładne i obliczanie współczynnika korekcyjnego może potrwać nawet kilka cykli. Dla HTB pojawienie się takiego komunikatu może oznaczać nieprawidowe działanie klasy HTB lub znakowania pakietów MARK na firewallu.
      • ceil_download - (Tylko dla HTB) procentowa wielkość pasma w kierunku pobierania jakie użytkownik może pożyczyć od innych użytkowników. Wartość 50 oznacza, że uzytkownik może pożyczyć od innych dodatkowo 50% dla swojego przydziału.
      • ceil_upload - (Tylko dla HTB) procentowa wielkość pasma w kierunku wysyłania jakie użytkownik może pożyczyć od innych użytkowników. Wartość 50 oznacza, że uzytkownik może pożyczyć od innych dodatkowo 50% dla swojego przydziału.
      • burst_type - (Tylko dla HTB,EHTB,SHTB) tryb obliczania wielkości burst. Dla current - brany jest aktualny przydział szybkości. Dla maximum - brany jest maksymalny możliwy dla danego usera przydział szybkości.
      • cburst_type - (Tylko dla HTB,EHTB,SHTB) tryb obliczania wielkości cburst. Dla current - brany jest aktualny przydział szybkości. Dla maximum - brany jest maksymalny możliwy dla danego usera przydział szybkości.
      • htb_burst - (Tylko dla HTB,EHTB,SHTB) współczynnik na podstawie którego obliczana jest ilość danych możliwa do przesłania przez klasę bez ograniczenia szybkości. Ilość danych = szybkość / współczynnik. Gdy współczynnik htb_burst jest 0 to klasy HTB same sobie automatycznie wyliczają ten parametr.
      • htb_cburst - (Tylko dla HTB,EHTB,SHTB) współczynnik na podstawie którego obliczana jest ilość danych możliwa do przesłania przez klasę bez ograniczenia szybkości. Ilość danych = szybkość / współczynnik. Gdy współczynnik htb_cburst jest 0 to klasy HTB same sobie automatycznie wyliczają ten parametr.
      • remove_dead_class - yes włącza usuwanie klas, gdy shaperd nie może przy ich pomocy kontrolować szybkości. Usunięcie jakiejś klasy objawia się błędem w logu: Removing download class of IP. Jeśli taki komunikat pojawi się sporadycznie to można przeżyć ale jak pojawia się ciągle to znaczy, że problem jest nie w jednej uszkodzonej klasie a w systemie.
      • refresh_dead_fwrule - yes włącza dodatkowo usuwanie regułek firewalla gdy włączony jest parametr remove_dead_class.
      • check_firewall_counters - wartość parametru określa co ile cykli shaper będzie sprawdzał czy regułki na firewallu nie są "przepełnione". Jeśli 0 to kontrola firewalla jest wyłączona. Parametr dodałem ponieważ na niektórych systemach zdażyło mi się, że po wyczyszczeniu liczników regułek - liczniki się nie zerowały tylko "przepełniały" tzn ustawiała się na nich maksymalna możliwa 32 bitowa wartość: 4294967295 i przestawały liczyć ruch (nie przekręcały się). W związku z powyższym wprowadziłem w shaperze kontrolę wyzerowania liczników po sygnale SIGUSR1 a dodatkowo shaper może kontrolować liczniki na firewallu i jeśli którykolwiek osiągnie wielkość większą niż 2147483647 (2GB) to wszystkie liczniki są automatycznie zerowane.
      • speed_ext - jednostka szybkości (bit, Kbit lub Mbit). Pamiętaj o przeliczeniu wszystkich parametrów zawierających szybkość na nową jednostkę:
        • inter_int
        • local_int
        • w pliku iplist.X również trzeba przeliczyć jeśli narzucone zostały indywidualne limity dla poszczególnych numerów IP
      • jump_type - wielkość skoku przy zwiększaniu przydziałów. 0 - przydział reszty niewykorzystanego łącza (podzielonej na ilość userów, którym ma być zwiększony transfer). Wielkość większa od 0 jest mnożnikiem parametru lospeed czyli np 1 oznacza zwiększanie szybkości o lospeed a 2 - o 2*lospeed. Odradzam stosowanie 0 jako wyjątkowo przykre dla rozpędzonych userów - shaperd przy tej wielkości bardzo szarpie transferem.
      • nop_factor - 1 współczynnik wykorzystania łącza. Wartość podajemy w procentach. Jeśli użytkownik będzie pracował z szybkością o ten faktor mniejszą od przydziału (domyślna wartość 50 procent) to wtedy widełki zostaną mu obcięte.
      • add_factor - 2 współczynnik wykorzystania łącza. Wartość podajemy w procentach. Jeśli użytkownik będzie pracował z szybkością większą niż przyznany limit pomnożony przez ten faktor (domyślnie 75 procent) to widełki zostaną zwiększone. Jeśli szybkość utrzymuje się między nop_factor a add_factor to przydział nie jest zmieniany. te dwa współczynniki można wykorzystać do zwiększenia wykorzystania łącza. Jeśli ktoś ma o tym pojęcie i ma ochotę poeksperymentować to życzę miłej zabawy.
      • debug - jak coś nie działa to można ustawić poziom śledzenia w logu (dostepne poziomy 0 - brak, 1, 2, 3, 4)
      • debug_output - cel komunikatów o błędach wysyłanych z powłoki w trakcie uruchamiania komend systemowych. Domyślnie /dev/null - można wpisać zamiast tego nazwę pliku i po ustawieniu wartości debug większej niż 0 można zobaczyć jakie błędy wyrzucają komendy uruchamiane przez shapera.
      • delay - czas oczekiwania między kolejnymi cyklami (minimum 10 sekund - przy większej ilości numerów IP może pojawić się potrzeba ustawienia dłuższego czasu.
      • delay_mesg - no wyłącza pojawianie się w logu informacji typu: Delay parameter has too low amount for this number of IP's or possibility of server., Increasing delay to XX seconds. Dla wrażliwych na wpisy w logu.
      • mask_mesg - no wyłącza pojawianie się w logu informacji typu Can't find mask for IP.
      • write_delay - co ile cykli ma być generowany plik bitrate_user_sh.X.old, który zawiera listę numerów IP i spis aktualnie przydzielonych widełek (potrzebne jedynie do wizualizacji przy pomocy skryptu kto.php - przykład działania). Jeśli 0 to tworzenie plików z przydziałami zostanie wyłączone.
      • pos_diff - różnica położenia pozycji na firewallu między download a upload. Przykład:
        • Fragment wpisów w iplist.0:
          [root@frodo root]# grep -E -v "^$|^#" /etc/shaper/iplist.0 | head -3
          217.97.124.128=eth0 eth0 0 0 0 0 1 1
          192.168.1.2=eth1 eth0
          192.168.1.3=eth1 eth0
          
        • Czyli w tablicy shaper0 przy działającym shaperze powinniśmy mieć takie wpisy:
          [root@frodo root]# iptables -L shaper0 -n --line-numbers | head -5
          Chain shaper0 (1 references)
          num  target     prot opt source               destination
          1    RETURN     all  -- !192.168.1.0/24       192.168.1.2
          2    RETURN     all  -- !192.168.1.0/24       192.168.1.3
          3    RETURN     all  -- !192.168.1.0/24       192.168.1.4
          
        • A w tablicy shaout0:
          [root@frodo root]# iptables -L shaout0 -n --line-numbers | head -5
          Chain shaout0 (2 references)
          num  target     prot opt source               destination
          1    RETURN     all  --  217.97.124.128       0.0.0.0/0
          2    RETURN     all  --  192.168.1.2         !192.168.1.0/24
          3    RETURN     all  --  192.168.1.3         !192.168.1.0/24
          
        • Jak widać - dla użytkowników lokalnych - między tablicą shaout0 a tablicą shaper0 jest jedna pozycja różnicy (192.168.1.2 w shaout0 na pozycji 2 a w shaper0 na pozycji 1) - co daje nam wartość pos_diff=1

        Jeśli nie wpisujemy numeru IP zewnętrznego serwera do iplist.X to różnicy nie będzie i wtedy pos_diff=0. Parametr ten jest potrzebny do odświeżania konfiguracji sygnałem SIGHUP.
      • default_download_limit - 0 - wyłącza indywidualne limity ilości pobranych danych. Więcej informacji w przykładzie Limity.
      • default_upload_limit - 0 - wyłącza indywidualne limity ilości wysłanych danych. Więcej informacji w przykładzie Limity.
      • default_download_hispeed - 0 - oznacza że po przekroczeniu limitu ściągania maksymalna możliwa prędkość w kierunku ściągania będzie ograniczona do połowy. Więcej informacji w przykładzie Limity.
      • default_upload_hispeed - 0 - oznacza że po przekroczeniu limitu wysyłania maksymalna możliwa prędkość w kierunku wysyłania będzie ograniczona do połowy. Więcej informacji w przykładzie Limity.
      • write_last_rate - co ile cykli shapera ma być tworzony plik /var/shaper/last.X zawierający aktualnie wykorzystane limity. 0 - wyłącza uaktualnianie tego pliku (plik i tak jest tworzony przy każdym restarcie shapera - by zapamiętać "osiągnięcia" użytkowników nawet pomimo skasowania liczników regułek na firewallu.
      • last_rate_perm - prawa dostępu do pliku /var/shaper/last.X (wpisane ósemkowo).
      • write_type - 0 - klasyczny format zapisu plików w katalogu /var/shaper/bitrate_user_*, 1 - alternatywny format zapisu (niekompatybilny z kto.php) ale łatwy do wyświetlania na konsoli w formie tabelek - autorem zmian jest Marek Chłopek.
      • inter_int - parametry zewnętrznych interfejsów (internetowych)
        • ppp0 - nazwa interfejsu internetowego.
        • 8000 - lospeed - minimalna gwarantowana szybkość pobierania.
        • 92000 - hispeed - maksymalna możliwa szybkość pobierania.
        • 1000 - upload_lospeed - minimalna gwarantowana szybkość wysyłania.
        • 60000 - upload_hispeed - maksymalna możliwa szybkość wysyłania (upload) dla interfejsu. Jest to szybkość z jaką maksymalnie może pracować łącze w czasie wysyłania danych z sieci do internetu. Wartość 0 wyłącza całkowicie ograniczenie szybkości upload.
        • auto - IP - Numer IP interfejsu. auto - włącza automatyczne pobieranie numeru IP z interfejsu.
        • 1 - identyfikator klasy (starszy bajt) (dla każdego interfejsu musi być inny - najlepiej kolejny po 1).
      • local_int - parametry lokalnych interfejsów
        • eth0 - nazwa interfejsu lokalnego. Nie wpisuj tutaj interfejsu łączącego z internetem!
        • 10485760 - szybkośc interfejsu w bitach/sek (10MBit=10*1024*1024 bit)
        • 192.168.0.0/16 - numer ip serwera wraz z maską (w tym przypadku jest to maska sieci klasy C co powoduje, że wszystkie transfery od numerów ip pasujących do tej maski nie będą miały ograniczeń. Chodzi o to aby transfer lokalny z serwera bądź rutowany przez interfejsy od ludzi lokalnych w sieci nie był przycinany).
        • 192.168.1.0/24 - numer ip docelowy z maską dla którego stosowany jest shaper (czyli maska podsieci stosowana na danym interfejsie - np eth0 może mieć 192.168.1.0/24 a eth1 192.168.2.0/24 - numery ip w podsieci to 192.168.2.0-255).
        • 2 - identyfikator klasy (starszy bajt) (dla każdego interfejsu musi być inny - najlepiej kolejny po 1).
      • squid_ingress_support - 0 - włącza kontrolę szybkości wysyłania do internetu przez squida (proxy).
      • squid_factor - (domyślna wartość 1.00) Przy włączonej opcji squid_ingress_support. Współczynnik przez który jest mnożony aktualny przydział szybkości w kierunku wysyłania i wynik tej operacji jest przydziałem szybkości wysyłania dla squida (proxy). Przydatna opcja jeśli używamy dwóch łącz internetowych - jednego do ruchu podstawowego a drugiego dla squida tylko dla ruchu www. Jeśli łącze podstawowe ma dużo większą max szybkość upload (np łącze symetryczne FR 2Mbit/2Mbit) a łącze dla squida mniejszą (np DSL 2Mbit/256Kbit) to jeśli jakiś użytkownik otrzymałby przydział szybkości wysyłania na poziomie np 256Kbit - to z takąszybkością może wysyłać również przez squida (i zapchałby nam cały upload) - i dlatego można ustawić ten współczynnik dla squida na poziomie 0.125 (czyli jak ktoś dostanie przydział upload 2Mbit to na squidzie będzie miał max upload 2Mbit x 0.125 = 256Kbit
      • natstat_download_sensivity - (domyślna wartość 5000) ilość bajtów przesłana do użytkownika w czasie 1 cyklu shapera (domyślnie 10 sekund) której przekroczenie powoduje, że shaper uzna iż należy utworzyć przydział szybkości w kierunku ściągania dla danego użytkownika.
      • natstat_upload_sensivity - (domyślna wartość 5000) ilość bajtów przesłana od użytkownika w czasie 1 cyklu shapera (domyślnie 10 sekund) której przekroczenie powoduje, że shaper uzna iż należy utworzyć przydział szybkości w kierunku wysyłania dla danego użytkownika.
      • ban_user - 0 Włącza na firewallu okresowe blokady ruchu użytkownika który wychodzi poza widełki. Jednym z problemów które czasem występująprzy używaniu HTB i CBQ jest efekt który nazywam "rozwalaniem" klas. Objawia się ten efekt tym, że przez jakiśczas użytkownik pracyje zgodnie ze swoim przydziałem szybkości po czym nagle zaczyna wychodzić poza ten przydział aż do np kompletnego zapchania łącza. Restart shapera (lub jakiegokolwiek innego softu do kontroli ruchu skutkuje tym, że przez jakiś czas znowu jest wszystko ok - po czym ten sam user znowu rozwala klasy. Shaper posiada od dawna możliwość kontrolowania czy klasy nie są "rozwalane". Kontrola ta polega na pomiarze szybkości rzeczywistej usera i porównaniu jej z prędkością jaką user powinien mieć teoretycznie - jeśli rzeczywista szybkości jest dużo większa od ustawionej to shaper próbuje zmniejszyć przydział szybkości sprawdzając jednocześnie czy zmiana tego przydziału spowoduje zmniejszenie się szybkości usera - jeśli nie będzie resultatu tej operacji to w zależności od ustawienia parametrów check_download_factor, check_upload_factor, check_download_factor_cnt, check_upload_factor_cnt jeśli włączony jest remove_dead_class=yes to shaper usunie klasę kontrolującą ruch danego użytkownika i utworzy ją ponownie. W przypadku gdy włączona jest opcja ban_user=yes to jeśli w czasie mniejszym niż godzina od ostatniego skasowania/ponownego utworzenia klasy user znowu ją "rozwali" to shaper "zabanuje go"(zablokuje mu dostęp do internetu) na okres co najmniej 1 cyklu swojej pracy (minimum 10 sekund). Po tym cyklu ban jest zdejmowany i jeśli user znowu "rozwali" klasę ograniczającą mu szybkość to ban jest nakładany ponownie na okres 2 cykli aż do osiągnięcia maksymalnego czasu banowania zawartego w parametrach max_ban_download i max_ban_upload (domyślne wartości tych parametrów to 5 (czyli maksymalny czas banowania to 1 minuta).
      • common_limit - 0 Włączenie tego parametru powoduje, że gdy użytkownik przekroczy jeden z limitów (np limit ilości przesłanych danych w kierunku do internetu (upload)) to automatycznie shaper załączy mu ograniczenia w obu kierunkach (tak jakby przekroczył również limit w kierunku ściągania (download)).
      • total_limit - 0 Włączenie tego parametru powoduje, że gdy użytkownik przekroczy sumę wszystkich limitów (download+upload) to shaper załączy mu ograniczenie szybkości w obu kierunkach. Mały przykład. Sprzedajemy użytkownikowi łącze z limitem miesięcznym 10GB (i nie interesuje nas to czy on tyle ściągnie czy wyśle) - może on ściągnąć 1GB a wysłać 9GB - i limit przekroczy). W przypadku stosowania tego parametru nie ma sensu wpisywać obu limitów (i tak są sumowane) - można wpisać to w pliku /etc/shaper/iplist.0 np tak (zakładam że speed_ext=Kbit oraz total_limit=yes):
        192.168.1.10=eth1 eth0 8 128 8 128 10485760 0 8 24 8 24
        
        Wpis ten oznacza, że użytkownik 192.168.1.10 ma szybkość 128/128Kbit i ustawiony limit ilości przesłanych danych 10GB a po jego przekroczeniu szybkość max 24/24Kbit.
      • extended_download_limits - 0 "Od jakiegos czasu chodzil mi po glowie pomysl aby rozszerzyc funcjonalnosc ograniczania downloadu userow po przekroczeniu pewnego limitu sciagniecia. Chodzilo mi ogolnie o to aby po przekroczeniu okreslonego limitu, user nie byl przycinany do sztywnej wartosci bitrate'u, a jedynie by byl zakladany na niego jakis mniejszy priorytet, aby 'ustepowal' predkoscia innym. Ma to sens gdy na laczu siedzi jeden user, ciagnie na maxa lecz pozwalamy mu na to, dopoki nie pojawi sie ktos inny. W tym momencie jesli ten drugi user bedzie aktywnie korzystal z lacza, shaperd nie bedzie dzielil po rowno, lecz da priorytet sciagania temu uzytkownikowi bez limitow. Moja poprawka nie uwzglednia wogole nowych limitowanych CIRow i EIRow (poza globalnymi), chodzi tylko o oddawanie priorytetu sciagania innym userom. Narazie rozszerzone limity obsluguja download ale jesli uznasz ze poprawki sa ok to nie problem bedzie dorobic to dla uploadu." Adam 'ZQ' Mencwal)
      • static_dnload_class - 0 Włączenie tego parametru spowoduje, że shaper nie będzie sprawdzał kto jest aktywny w sieci - tylko od razu zakłada klasy ograniczające ruch do usera dla każdego numeru IP (rezerwując tym samym CIR) - user może być wyłączony i nie używać netu ale jego klasa cały czas istnieje. Parametry te włączają statyczne klasy dla wszystkich userów. Indywidualnie można każdemu utworzyć taką klasę stawiając znak minus przed interfejsem (dla lokalnego interfejsu minus oznacza statycznš klasę w kierunku ściagania z internetu a dla internetowego interfejsu statyczną klasę w kierunku wysyłania do internetu). Przykładowy plik iplist.0:
        192.168.1.2=-eth1 eth0
        
      • static_upload_class - 0 Włączenie tego parametru spowoduje, że shaper nie będzie sprawdzał kto jest aktywny w sieci - tylko od razu zakłada klasy ograniczające ruch od usera dla każdego numeru IP (rezerwując tym samym CIR) - user może być wyłączony i nie używać netu ale jego klasa cały czas istnieje. Parametry te włączają statyczne klasy dla wszystkich userów. Indywidualnie można każdemu utworzyć taką klasę stawiając znak minus przed interfejsem (dla lokalnego interfejsu minus oznacza statycznš klasę w kierunku ściagania z internetu a dla internetowego interfejsu statyczną klasę w kierunku wysyłania do internetu). Przykładowy plik iplist.0:
        192.168.1.2=eth1 -eth0
        
      • enable_eir_factor - 0 włączenie innego rodzaju podziału łącza.
        Sytuacja hipotetyczna - mamy 10 userów - wszyscy ściągają na max w ramach swoich przydziałów szybkości (wykorzystują więcej niż 80% swoich przydziałów). Większość z userów ma ograniczoną max szybkość ściągania do 256kbit - ale 2 userów ma ustawione do 512kbit. W standardowym shaperze - w przypadku gdy łącze będzie zapchane, serwer będzie dążył do ustawienia wszystkim userom identycznych przydziałów (po równo) czyli dla łącza 2Mbit mamy taki stan końcowy:
        user1 ma EIR 256 -> przydział 204kbit
        user2 ma EIR 256 -> przydział 204kbit
        user3 ma EIR 256 -> przydział 204kbit
        user4 ma EIR 256 -> przydział 204kbit
        user5 ma EIR 512 -> przydział 204kbit
        user6 ma EIR 512 -> przydział 204kbit
        user7 ma EIR 256 -> przydział 204kbit
        user8 ma EIR 256 -> przydział 204kbit
        user9 ma EIR 256 -> przydział 204kbit
        user10 ma EIR 256 -> przydział 204kbit
        
        Jak widać - wszyscy mają po równo - ponieważ jednak dwóch userów ma max przydział do 512Kbit (bo płacą więcej) to oni są poszkodowani - powinni mieć lepiej niż reszta użytkowników.

        Teraz symulacja z włączoną opcją

        enable_eir_factor=yes
        user1 ma EIR 256 -> przydział 163Kbit
        user2 ma EIR 256 -> przydział 163Kbit
        user3 ma EIR 256 -> przydział 163Kbit
        user4 ma EIR 256 -> przydział 163Kbit
        user5 ma EIR 512 -> przydział 327Kbit
        user6 ma EIR 512 -> przydział 327Kbit
        user7 ma EIR 256 -> przydział 163Kbit
        user8 ma EIR 256 -> przydział 163Kbit
        user9 ma EIR 256 -> przydział 163Kbit
        user10 ma EIR 256 -> przydział 163Kbit
        
        I jak widać - userzy z wyższym EIR mają wiekszą szybkość od reszty. Należy pamiętać, że przy włączonej tej opcji - przyznanie jakiemukolwiek użytkownikowi max szybkości większej od innych spowoduje że w w przypadku zapchanego łącza ten użytkownik bedzie osiągał większe szybkości kosztem pozostałych użytkowników.
      • alt_delay_handle - 0 Włączenie tego parametru spowoduje zmianę sposobu obliczania opóźnienia między cyklami. "Zamieniłem również wyliczanie czasu w ten sposób, iż shapred zwiększa delay do wartości czasu tworzenia klas + 1s w każdym cyklu aż nie wejdzie w stan równowagi. Jeżeli userów ubywa, to czas się zmniejsza o 1s na cykl. Moja uwaga - ta poprawka nie jest krytyczna do działania shaperda, więc można jej nie uwzględniać w konfiguracji. Na pewno spowoduje zwiększenie średniego obciążenia serwera jeżeli czas wykonania będzie notorycznie przekraczał czas delay. Przy moich założeniach shaperd przy dużej ilości adresów ip, będzie powtarzał swoje cykle najszybciej jak potrafi. (Co uważam, za prawidłowe, skoro czas wykonania przekracza delay). Dzięki tym eksperymentom z czasem okazało się, że przy włączonym continuous_control czasy tworzenia klas i pętli głównej są o wiele mniejsze niż przy wyłączonym continuous_control. Więc stąd wniosek, że z włączonym continuous_control shaperd działa szybciej.

      O co chodzi z tymi dwoma numerami IP? Jeśli masz w systemie tylko jeden interfejs lokalny to nie masz się co kłopotać. Ustawiasz pierwszy numer IP z maską /32 (np. 192.168.1.1/32) a drugi z maską jak dla interfejsu lokalnego (np. 192.168.1.1/24 co jest rónoznaczne z wpisem 192.168.1.0/24) i tyle. Wpis taki pozwala shaperowi stworzyć regułkę, która nie będzie ograniczała szybkości przy wystąpieniu transferów między tymi numerami IP. Czyli wszystko co będzie lecieć bezpośrednio z serwera (192.168.1.1) do któregoś z userów (192.168.1.0/24) będzie miało pełny transfer taki jak podana szybkość interfejsu lokalnego. W przypadku kilku lokalnych interfejsów musimy rozważyć, czy chcemy aby userzy łączący się między tymi interfejsami (czyli trasa prowadzi przez serwer) mieli ograniczony transfer czy pełną lokalną szybkość. Jeśli chcemy aby mieli pełną szybkość to pierwszy numer IP musi mieć taką maskę aby wszyscy userzy z wszystkich interfejsów lokalnych pasowali do tej maski. Czyli np dla interfejsów z numerami ip 192.168.1.0/24 i 192.168.2.0/24 możemy stworzyć źródłowy numer IP 192.168.0.0/16 który obejmie swoją maską wszystkie interfejsy. Jak ktoś tego nie zrozumie to polecam lekturę NET-3-HOWTO.


    • Przykładowy plik konfiguracyjny dla serwera z 2 interfejsami lokalnymi eth0 i eth1 o przepustowości 10Mbit i 100Mbit i stosując jednostkę szybkości Kbit. Łacze internetowe ppp0 od ISP o szybkości 930Kbit.
      divide_upload=yes
      class_type=cbq
      upload_class_type=cbq
      jump_type=5
      speed_ext=Kbit
      delay=10
      write_delay=0
      inter_int=ppp0;16;900;1;300;auto;1
      local_int=eth0;10240;192.168.0.0/16;192.168.1.0/24;2
      local_int=eth1;102400;192.168.0.0/16;192.168.2.0/24;3
      

      Przykładowy plik konfiguracyjny dla serwera z 3 interfejsami lokalnymi eth1, eth2, ppp2 (łącze dzierżawione miedzy np dwoma budynkami) o przepustowości 10Mbit, 100Mbit i 768Kbit (dla tego interfejsu ograniczamy transfery również lokalne). Łącza internetowe ppp0 (SDI) i eth0 (DSL 0.5Mbit) (UWAGA! shaperd nie tworzy regułek na firewallu tak aby część userów pracowała przez jedno łącze a część przez drugie - zadbać o to należy w trakcie konfiguracji firewall'a.
      divide_upload=yes
      class_type=cbq
      upload_class_type=cbq
      jump_type=5
      speed_ext=Kbit
      debug=0
      delay=10
      write_delay=0
      inter_int=eth0;8;440;1;100;auto;1
      inter_int=ppp0;8;92;1;60;auto;2
      local_int=eth1;10240;192.168.0.0/16;192.168.1.0/24;3
      local_int=eth2;102400;192.168.0.0/16;192.168.2.0/24;4
      local_int=ppp2;768;192.168.3.0/24;192.168.3.0/24;5
      

      IMQ
      Współpraca shapera z imq jest w fazie eksperymentów. Używanie tej opcji zalecam tylko osobom które mają pojęcie o imq. Opis działania imq znaleźć można na stronie http://www.linuximq.net/.
      Aby włączyć współpracę shapera z imq należy w pliku konfiguracyjnym dodać wpis:
      imq_support=yes
      
      Współpraca shapera z imq polega na podmianie interfejsów zdefiniowanych w konfiguracji w sekcji local_int i inter_int na interfejsy imq0 i imq1. Interfejsy wirtualne imq używane są tylko do tworzenia kolejek regulujących szybkość więc po włączeniu imq kontrolę działania shapera przeprowadzimy komendą:
      tc -s class show dev imq0
      
      W pliku iplist.X nie wolno wpisywać interfejsów wirtualnych - muszą być tam wpisane rzeczywiste interfejsy!

      Jednym z zastosowań imq jest możliwość łatwego regulowania szybkości użytkowników podczas używania wielu równolegle dołączonych łącz internetowych (np przy pomocy techniki load balancing'u). Standardowo shaper tworzy reguły na firewall'u które zawierają dla każdego użytkownika interfejs internetowy z jakiego do tego użytkownika przychodzi ruch. W przypadku używania load balancingu shaper widziałby tylko ruch przychodzący z interfejsu zadeklarowanego w pliku iplist.X aby tego uniknąc można posłużyć się opcją load_balancing=yes której włączenie spowoduje że shaper będzie dla każdego użytkownika liczył ruch z internetu z wszystkich interfejsów a nie tylko z tego zadeklarowanego w pliku iplist.X

      WRR
      Ktoś może spytać - po co używać shapera jeśli WRR można odpalić ze skryptu i efekt będzie ten sam. Teoretycznie to prawda - jednak shaper dodaje do WRR kilka możliwości których samo WRR nie zapewnia - takich jak:
      • limity ilości przesłanych danych nadal działają, po przekroczeniu limitu użytkownikowi usuwana jest klasa WRR i dostaje normalny przydział szybkości według wpisu w konfiguracji
      • można mieszać użytkowników - część może używać WRR co oznacza brak górnego ograniczenia szybkości a część może być odgórnie ograniczona - wpisanie w iplist.X przydziałów szybkości powoduje tworzenie normalnej klasy CBQ lub HTB - brak wpisu przydziałów szybkości lub wpisanie zera powoduje włączenie dla usera WRR
      • statystyki nadal można generować na podstawie liczników shapera

      UWAGA! Używanie WRR wymaga rekompilacji kernela! WRR nie jest dołączone do standardowych kerneli!

      Proszę nie pisać do mnie z pytaniami "jak zainstalować WRR". Opis instalacji WRR znajduje się na stronie: http://www.zz9.dk/wrr

      UWAGA! Shaper nie przeprowadza żadnej kontroli gotowości systemu do współpracy z WRR - włączenie współpracy z WRR na systemie do tego nie przystosowanym może spowodować różne nieprzewidziane konsekwencje począwszy od braku kontroli szybkości łącza a skończywszy na zawieszeniu się systemu.
      Włączenie w shaperze współpracy z WRR polega na ustawieniu w konfiguracji rodzaju klasy na: cwrr lub hwrr. Przykład:
      class_type=hwrr
      upload_class_type=hwrr
      
      Klasa cwrr to połączenie CBQ i WRR.
      Klasa hwrr to połączenie HTB i WRR.
      W swoich testach używam hwrr i jest to najlepiej przeze mnie przetestowana opcja.
      Po włączeniu WRR należy sprawdzić czy tworzone są klasy WRR - można tego dokonać komendą:
      tc -s class show dev eth1
      
      Zobaczymy coś mniej więcej takiego:
      class htb 2:1 root prio 1 rate 102400Kbit ceil 102400Kbit burst 14387b cburst 14387b
       Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
       lended: 0 borrowed: 0 giants: 0
       tokens: 1152 ctokens: 1152
      
      class htb 2:2 root prio 1 rate 102400Kbit ceil 102400Kbit burst 14387b cburst 14387b
       Sent 1403692 bytes 25081 pkts (dropped 0, overlimits 0)
       rate 24bit
       lended: 25081 borrowed: 0 giants: 0
       tokens: 1146 ctokens: 1146
      
      class htb 2:3 root leaf 2000: prio 1 rate 4096Kbit ceil 4096Kbit burst 2111b cburst 2111b
       Sent 2596247541 bytes 2888194 pkts (dropped 0, overlimits 0)
       rate 97384bit 136pps
       lended: 2888194 borrowed: 0 giants: 0
       tokens: 1280 ctokens: 1280
      
      class wrr 2000:1 parent 2000:
        (address: 192.168.1.223)
        (total weight: 0.0999998) (current position: 1) (counters: 5 2951496119 : 2147483648 2888188)
        Pars 1: (weight 0.999998) (decr: 4.48261e-10) (incr: 0.00133333) (min: 0.2) (max: 1)
        Pars 2: (weight 0.1) (decr: 0) (incr: 0) (min: 0.01) (max: 1)
      class wrr 2000:2 parent 2000:
        (address: 192.168.1.78)
        (total weight: 0.1) (current position: 0) (counters: 0 0 : 0 0)
        Pars 1: (weight 1) (decr: 4.48261e-10) (incr: 0.00133333) (min: 0.2) (max: 1)
        Pars 2: (weight 0.1) (decr: 0) (incr: 0) (min: 0.01) (max: 1)
      class wrr 2000:3 parent 2000: (unused)
      class wrr 2000:4 parent 2000: (unused)
      class wrr 2000:5 parent 2000: (unused)
      
      Jeśli nie zobaczymy ani jednej linijki zawierającej wrr to znaczy, że nasz system nie współpracuje z WRR i nic nam nie da używanie tej opcji.

      PPPoE
      Uzywanie shapera do kontrolowania ruchu na interfejsach tworzonych przez pppoe wymaga uzywania opcji imq_support. Dodatkowo na chwile obecna nie ma mozliwosci uzywania rozszerzonego kolejkowania extended_queue wiec nalezy ta opcje wylaczyc.
      Ponizej przykladowe pliki konfiguracyjne uzywane przeze mnie - plik shaper.0.cfg :
      check_download_factor=50
      check_upload_factor=50
      check_download_factor_cnt=2
      check_upload_factor_cnt=2
      ban_user=yes
      max_ban_download=12
      max_ban_upload=12
      remove_dead_class=yes
      refresh_dead_fwrule=yes
      pos_diff=1
      divide_upload=yes
      # UWAGA! opcja extended_queue musi byc wylaczona dla imq
      extended_queue=no
      class_type=shtb
      upload_class_type=shtb
      # obowiazkowo musi byc wkompilowany w kernel i wlaczony imq
      imq_support=yes
      ceil_download=0
      ceil_upload=0
      speed_ext=Kbit
      jump_type=10
      delay_mesg=no
      mask_mesg=yes
      write_delay=1
      write_last_rate=1
      last_rate_perm=644
      write_type=0
      inter_int=eth0;8;1024;8;128;auto;1
      local_int=eth1;102400;192.168.1.0/24;192.168.1.0/24;2
      local_int=ppp+;102400;10.1.1.0/24;10.1.1.0/24;3
      
      zalozenia:
      eth0 - lacze internetowe 1Mbit/128Kbit (np DSL z Tepsy 1Mbit)
      eth1 - lacze lokalne (jesli bedziemy mieli dopisanych w shaperze uzytkownikow pracujacych bez pppoe)
      ppp+ - lacza pppoe (obowiazkowo wpisywac ze znakiem '+'; w moim przypadku pracujace na tym samym laczu eth1 (pppoe-server jest odpalony na eth1)

      Plik konfiguracyjny uzykownikow - plik iplist.0:
      192.168.1.2=eth1 eth0
      192.168.1.3=eth1 eth0 8 128 8 32
      10.1.1.2=ppp+ eth0
      10.1.1.3=ppp+ eth0
      
      userzy 192.168.1.X sa podpieci standardowo bez pppoe (czyli np korzystaja z dhcp)
      userzy 10.1.1.X sa podpieci fizycznie do tej samej sieci (eth1) ale uzywaja polaczenia pppoe

      Przed uruchomieniem shapera trzeba jeszcze wprowadzic do systemu nastepujace regulki iptables (aktualna wersja shapera tego jeszcze nie robi):
      iptables -t mangle -I PREROUTING -i eth1 -j IMQ --todev 1
      iptables -t mangle -I PREROUTING -i eth1 -j IMQ --todev 0
      iptables -t mangle -I PREROUTING -i ppp+ -j IMQ --todev 1
      iptables -t mangle -I PREROUTING -i ppp+ -j IMQ --todev 0
      iptables -t mangle -I POSTROUTING -o eth1 -j IMQ --todev 0
      iptables -t mangle -I POSTROUTING -o ppp+ -j IMQ --todev 0
      
      Mozna sobie te linijki dopisac do firewall'a.

      I tyle - mozna sie bawic w testowanie shapera i pppoe.

      Limity
      1. Na początek ustalamy - co jaki okres czasu limity są kasowane. Załóżmy że robimy limity miesięczne. Należy wprowadzić odpowiedni wpis do pliku /etc/crontab (UWAGA - format zapisu w pliku /etc/crontab może się różnić na innych dystrybucjach linuxa - ten dotyczy Mandrake 9.1):
        0 0 1 * * root nice -n 19 killall -USR1 shaperd
        
        Zgodnie z tym zapisem limity będą kasowane o godzinie 00:00 pierwszego dnia każdego miesiąca.


      2. Przykładowa konfiguracja z limitami - plik /etc/shaper/shaper.X.cfg (pomijam resztę wpisów konfiguracyjnych - skupmy się na nowych parametrach) - wartości domyślne:
        default_download_limit=0
        default_upload_limit=0
        default_download_hispeed=0
        default_upload_hispeed=0
        
      3. Kolejny przykład: limity ściągania i wysyłania wynoszą 100Mbajtów (102400Kbajt - dla parametru speed_ext=Kbit - tu również przedrostkiem jest Kilo). Po przekroczeniu limitu w danym kierunku szybkość maksymalna (hispeed) dla danego kierunku zostanie obcięta o połowę.
        default_download_limit=102400
        default_upload_limit=102400
        default_download_hispeed=0
        default_upload_hispeed=0
        
      4. Limity ściągania i wysyłania wynoszą 100Mbajtów (zakładamy jak poprzednio że speed_ext=Kbit). Po przekroczeniu limitu 100Mbajtów w kierunku ściągania użytkownik będzie miał ograniczoną szybkość ściągania do 32Kbit. Po przekroczeniu 100Mbajtów w kierunku wysyłania użytkownik będzie miał ograniczoną szybkość wysyłania do 16Kbit.
        default_download_limit=102400
        default_upload_limit=102400
        default_download_hispeed=32
        default_upload_hispeed=16
        
      5. Przykładowa konfiguracja dla łącza DSL 512Kbit - wprowadzamy tylko limity na wysyłanie (limit powinien być dobowy - trzeba zrobić odpowiedni wpis w /etc/crontab). Po wysłaniu 50Mbajtów - szybkość wysyłania zostanie ograniczona do 8Kbit. Limit zostanie zdjęty o godzinie 00:00 dnia następnego. Jak jest w sieci jakieś miłośnik P2P i od tygodni nie wyłącza komputera to swój limit wykorzysta od północy do rana i potem przez cały dzień będzie miał ruch wychodzący przycięty - a inni użytkownicy będą mieć wyższe przydziały jak będą wysyłać duże maile z załącznikami na konta pocztowe np na onecie :)
        Wpis w pliku /etc/shaper/shaper.X.cfg:
        default_download_limit=0
        default_upload_limit=51200
        default_download_hispeed=0
        default_upload_hispeed=8
        
        A ponieważ administrator nie może sobie ograniczać dostępu do internetu to robimy odpowiedni wpis w pliku /etc/shaper/iplist.X
        192.168.1.2=eth1 eth0 0 0 0 0 1 1
        
        Wpis oznacza, że lospeed i hispeed dla ściągania i wysyłania bierzemy globalne (z definicji inter_int w pliku /etc/shaper/shaper.X.cfg) a limit ściągania i wysyłania wyłączamy (wartość 1 dla wielkości limitu ściągania i wysyłania oznacza wyłączenie, 0 oznacza wartość globalną braną z pliku /etc/shaper/shaper.X.cfg)
        Wpis w pliku iplist.X dla innego użytkownika wygląda przykładowo tak:
        192.168.1.3=eth1 eth0 8 128 4 64
        
        Ponieważ mamy ustawione wartości globalne dla limitów to wpis ten można zastąpić w celach edukacyjnych wpisem równoważnym:
        192.168.1.3=eth1 eth0 8 128 4 64 0 51200 0 0 4 8
        
        I jak widać - limit ściągania wynosi 0 - a wartość globalna tego limitu również wynosi 0 więc limit ściągania jest wyłączony. Limit wysyłania wynosi 50Mbajtów. Prędkość ściagania lospeed (CIR) jest domyślna jak również hispeed (EIR) ale w tym przypadku nie ma to znaczenia (ale wpisane cyfry musi być bo inaczej składnia pliku konfiguracyjnego będzie nieprawidłowa). Prędkość wysyłania lospeed po przekroczeniu limitu jest równa 4Kbit a hispeed po przekroczeniu limitu wynosi 8kbit


      6. Inne przykłady wpisów w iplist.X:
        1. Widełki 8 (CIR) i 64 (EIR) dla ściągania oraz 4 (CIR) i 32 (EIR) dla wysyłania ale gdy użytkownik ściągnie od godziny 00:00 więcej niż 400MB danych to zostaną mu włączone ograniczenia 8 (CIR) i 32 (EIR) w kierunku ściągania. Analogicznie - gdy użytkownik wyśle do internetu od godziny 00:00 więcej niż 100MB to włączane są dla niego widełki 4 (CIR) i 16 (EIR) w kierunku wysyłania.
          192.168.1.2=eth1 eth0 8 64 4 32 409600 102400 8 32 4 16
          
        2. Limit w kierunku ściągania jest wyłączony, w kierunku wysyłania limit wynosi 100MB.
          192.168.1.2=eth1 eth0 8 64 4 32 1 102400 0 0 4 16
          
        3. W pliku /etc/shaper/shaper.0.cfg ustawiamy globalne wartości:
          default_download_limit=409600
          default_upload_limit=102400
          default_download_hispeed=0
          default_upload_hispeed=0
          
          Po takim zapisie poniższy wpis w pliku /etc/shaper/iplist.0:
          192.168.1.2=eth1 eth0 8 64 4 32
          
          oznacza, że user po przekroczeniu domyślnego limitu ściągania 400MB (brak wpisanej cyfry oznacza wpisanie zera) będzie miał limit szybkości 8 (CIR) i 32 (EIR) w kierunku ściagania (domyślny EIR po przekroczeniu limitu jest dzielony przez 2). Po przekroczeniu 100MB w kierunku wysyłania limit szybkości wysyłania wyniesie 4 (CIR) i 16 (EIR). Wpis taki jest więc równoważny pełnemu wpisowi:
          192.168.1.2=eth1 eth0 8 64 4 32 409200 102400 8 32 4 16
          

    • Program shaperd jest dostarczony w postaci archiwum zawierającego zarówno wersję skompilowaną dla procesorów x86 jak i plik źródłowy. Wersja skompilowana może nie działać na starszych systemach i w związku z tym zaleca się samodzielne skompilowanie pliku źródłowego. Aby to zrobić należy napisać:
      cd /usr/src/shaper
      make
      
      lub dla wersji starszych niż 2.2.2
      gcc /usr/src/shaperd/shaperd.c -o /sbin/shaperd
      
    • Należy wklepać wszystkie lokalne numery ip i obok nazwy interfejsów przez które te numery pracują (zarówno interfejs lokalny jak i internetowy) w pliku /etc/shaper/iplist.X - gdzie X to numer konfiguracji. Przykład:
      192.168.1.2=eth0 ppp0
      192.168.1.3=eth0 ppp0
      192.168.1.4=eth0 ppp0 8000 16000 1000 16000
      192.168.1.5=eth0 ppp0
      192.168.2.2=eth1 ppp0
      192.168.2.3=eth1 ppp0
      192.168.2.4=eth1 ppp1
      192.168.2.5=eth1 ppp1
      
      Wprowadziłem dodatkowo możliwość ustawiania indywidualnych limitów dla poszczególnych numerów IP. W powyższym przykładzie dla numeru IP 192.168.1.4 ustawiłem następujące widełki dla ściągania (download): 8000 (1KB - minimum gwarantowane) i 16000 (2KB - maksymalna możliwa przydzielona szybkość) oraz dla wysyłania (upload): 8000 (1KB - minimum gwarantowane) i 16000 (2KB - maksymalna możliwa do osiągnięcia prędkość wysyłania). Pamiętaj, że wartości te są podawane w jednostce szybkości takiej samej jak ustawiona jednostka w pliku shaper.cfg w parametrze speed_ext. W przypadku braku wpisów shaperd przyjmuje dla każdego numeru IP wartości ustawione globalnie w pliku shaper.X.cfg.
      Istnieje możliwość wpisu numerów IP wraz z maskami. Przykład:
      192.168.1.2=eth0 ppp0
      192.168.1.3=eth0 ppp0
      # numery 192.168.1.4 i 192.168.1.5 mają jeden wspólny przydział łącza
      192.168.1.4/31=eth0 ppp0
      192.168.2.2=eth1 ppp0
      192.168.2.3=eth1 ppp0
      192.168.2.4=eth1 ppp1
      192.168.2.5=eth1 ppp1
      
      Co spowoduje, że numery IP od 192.168.1.4-192.168.1.5 będą traktowane jako jeden i otrzymają wspólnie widełki.
      Inny przykład:
      192.168.1.0/24=eth0 ppp0
      192.168.2.0/24=eth1 ppp0
      
      Jest to podział między dwoma interfejsami. Przy włączonej opcji even_division=1 możemy zaczynać działalność providerską :)


    • Istnieje limit maksymalnie 250 numerów IP na jednym interfejsie - więcej numerów IP proszę rozdzielić na kilka interfejsów.


    • Jak wyznaczyć parametry lospeed, hispeed, upload_lospeed, upload_hispeed dla łącza internetowego.
    • Sygnał SIGUSR1 służy do wymuszenia na shaperze wyzerowania liczników ilości przesłanych przez uzytkowników danych oraz wyłączeniu ograniczeń załączonych po przekroczeniu limitów. Po otrzymaniu sygnału shaper podejmie odpowiednie działania po zakończeniu aktualnego cyklu (więc czas reakcji zalezy od czasu trwania cyklu - domyślnie 10 sekund). Ponadto wyzerowanie liczników powoduje że przez parę cykli shaperd "głupieje". Przykład użycia:
      killall -USR1 shaperd
      
    • Sygnał SIGUSR2 służy do wymuszenia na shaperze odczytania pliku /var/shaper/diff.X zawierającego poprawki do stanu liczników ilości przesłanych przez uzytkowników danych oraz wyłączeniu ograniczeń załączonych po przekroczeniu limitów. Po otrzymaniu sygnału shaper podejmie odpowiednie działania po zakończeniu aktualnego cyklu (więc czas reakcji zalezy od czasu trwania cyklu - domyślnie 10 sekund). Przykład użycia:
      killall -USR2 shaperd
      
      Format pliku /var/shaper/diff.X jest identyczny jak format pliku ze stanem liczników /var/shaper/last.X Po otrzymaniu sygnału SIGUSR2 shaperd odczytuje zawartość tego pliku i dla każdego numeru IP który będzie w tym pliku wprowadza poprawki odejmując od odpowiednich liczników w pliku /var/shaper/last.X wartości znajdujące się na tych samych pozycjach w pliku /var/shaper/diff.X Przykład - wyzerowanie liczników pojedyńczego użytkownika: Przykładowa zawartość pliku /var/shaper/last.0 (fragment):
      192.168.1.17/32 0 0 19619239 376089797 2449730 38422314
      192.168.1.18/32 0 0 522872 50936564 513868 6156332
      192.168.1.10/32 0 0 4306649848 68952545 3879551339 14294842
      192.168.1.13/32 0 0 0 0 0 0
      
      Chcemy wyzerować wszystkie liczniki użytkownika o IP 192.168.1.10 - tworzymy plik /var/shaper/diff.0 o zawartości
      192.168.1.10/32 0 0 4306649848 68952545 3879551339 14294842
      
      Liczniki się wyzerują po otrzymaniu sygnału SIGUSR2 ponieważ od aktualnej wartości odpowiedniego licznika zostanie odjęta odpowiednia liczba z pliku /var/shaper/diff.0 Nic nie stoi na przeszkodzie również zwiększyć komuś stan licznika - wystarczy wpisać w pliku /var/shaper/diff.0 wartości ujemne:
      192.168.1.10/32 0 0 -1000000 0 0 0
      
      Wyjątkiem jest tutaj ustawianie/kasowanie dwóch pierwszych cyfr po numerze IP (są to znaczniki przekroczenia limitu ilości ściągniętych danych i ilości wysłanych danych) - znaczniki te kasuje się wpisując wartość dla nich 0 a ustawia się wpisując wartość 1. Przykład: plik /var/shaper/last.0 (fragment):
      192.168.1.17/32 0 0 19619239 376089797 2449730 38422314
      192.168.1.18/32 0 0 522872 50936564 513868 6156332
      192.168.1.10/32 1 1 4306649848 68952545 3879551339 14294842
      
      Aby skasować znaczniki przekroczenia limitu wystarczy wpisać w pliku /var/shaper/diff.0 wartości:
      192.168.1.10/32 0 0 0 0 0 0
      
      Zwracam uwagę, że zostaną skasowane tylko znaczniki a liczniki nie - więc jeśli użytkownik nadal w konfiguracji ma wpisane te same limity ilości przesłanychdanych to ponownie za moment będzie miał te znaczniki ustawione (należy więc pamiętać przy zerowaniu znaczników przekroczenia limitów albo o zmniejszeniu liczników albo o zwiększeniu w pliku konfiguracyjnym limitów dla tego użytkownika (i przeładowaniu konfiguracji!))
      Plik /var/shaper/diff.0 po przetworzeniu przez shapera jest usuwany więc za każdym razem trzeba tworzyć nowy.


    • Sygnał SIGHUP służy do wymuszenia na shaperze przeładowania konfiguracji (reload). W szczególności służy do wprowadzania zmian widełek poszczególnym użytkownikom w trakcie pracy shapera bez konieczności całkowitego restartowania. Należy zwrócić uwagę, że nie każda zmiana jest możliwa do uaktualnienia.
      Nie wolno uaktualnić konfiguracji tą metodą po zmianie następujących parametrów:
      1. class_type
      2. upload_class_type
      3. squid_support
      4. squid_port
      5. extended_queue
      6. ceil_download
      7. ceil_upload
      8. speed_ext
      9. last_rate_perm
      10. pos_diff
      11. inter_int
      12. local_int

      Przykład użycia:
      killall -HUP shaperd
      
      Jako eksperyment należy potraktować możliwość dodania do konfiguracji pracującego shapera nowo dopisanego użytkownika w pliku /etc/shaper/iplist.X. Po wysłaniu sygnału SIGHUP shaperd sprawdza w pliku /etc/shaper/iplist.X czy nie pojawił się jakiś nowy wpis. W optymistycznej wersji - wpis pojawi się na samym końcu pliku - wtedy shaper utworzy na firewallu regułki dla tego użytkownika i problemu nie będzie. W innym przypadku - dodania użytkownika ale gdzieś w środek pliku - shaper dopisze dla tego użytkownika regułki na firewallu na pozycji w jakiej ten użytkownik dopisany - a wszystkie wpisy znajdujące się "poniżej" tego wpisu będą kasowane z firewalla i tworzone od nowa z nowymi pozycjami (co zajmie już trochę czasu) - dlatego należy tego unikać. Najgorszym scenariuszem jest usunięcie jakiegoś wpisu z pliku /etc/shaper/iplist.X. Shaper jak na razie nieszczególnie sobie z tym radzi - dlatego po usunięciu jakiegoś użytkownika z konfiguracji shapera zalecam kompletny restart shapera.


    • Przy włączonym kolejkowaniu (extended_queue=yes) tworzona jest jedna klasa główna i 4 podklasy dla każdego pracującego użytkownika. Klasa główna ma numer tworzony na zasadzie X:Y - gdzie X to identyfikator klasy, Y - pozycja (wiersz) wpisu numeru IP w pliku iplist.X (licząc same wpisy bez komentarzy i pustych lini) plus 4. I tak na przykład jeśli w pliku iplist.X mamy wpisany pierwszy numer IP 192.168.1.2, identyfikator interfejsu internetowego (np. eth0) tego użytkownika (inter_int) mamy 1 a interfejsu lokalnego (np. eth1), przez który ten użytkownik pracuje mamy 2 to numer klasy dla download mamy 2:5 a dla upload 1:5. Wpisując komendę
      tc -s class show dev eth0
      
      możemy zobaczyć miedzy innymi klasę dla tego numeru IP (w przykładzie używana klasa HTB):
      class htb 2:5 parent 2:1 prio 3 rate 214Kbit ceil 214Kbit burst 27391b cburst 1872b
       Sent 27025335 bytes 34960 pkts (dropped 0, overlimits 0)
       rate 21702bps 28pps
       lended: 0 borrowed: 0 giants: 0 injects: 0
       tokens: 778767 ctokens: 15581
      
      A dla upload:
      tc -s class show dev eth0
      
      zobaczymy coś takiego (w przykładzie używana klasa CBQ):
      
      class cbq 1:5 parent 1:1 rate 14Kbit (bounded) prio 5
       Sent 554775 bytes 4674 pkts (dropped 0, overlimits 0)
        borrowed 30 overactions 0 avgidle 379301 undertime 0
      
      Dodatkowe 4 podklasy do kolejkowania mają numery tworzone zgodnie z zasadą X:Y gdzie X to identyfikator klasy, Y = (4*(A+4))+PRIO
      gdzie A - pozycja numeru IP w pliku iplist.X, PRIO - priorytet, możliwe są 4 priorytety: 100 (najwyższy), 101, 102 i 103 (najniższy - wpada do tej klasy cały ruch nieprzesłany przez klasy z wyższym priorytetem). Poniżej znajdują się regułki dla iptables dla jednego uzytkownika tworzone przy starcie shapera. Niestety - nie są tworzone odpowiednie regułki dla ipchains - i proszę mnie nie prosić o przykłady - jak bym wiedział jak to na ipchains zrobić to w shaperze by to było. Przykład:
      # download
      # najwyzszy priorytet download - klasa 2:120
      iptables -t mangle -A FORWARD -d 192.168.1.2 -m tos --tos 0x10 -j MARK --set-mark 2120
      # sredni priorytet download - klasa 2:121
      iptables -t mangle -A FORWARD -d 192.168.1.2 -m tos --tos 0x08 -j MARK --set-mark 2121
      # niski priorytet download - 2:122
      iptables -t mangle -A FORWARD -d 192.168.1.2 -m tos --tos 0x04 -j MARK --set-mark 2122
      # Pozostały ruch z polem tos innym niż podane trafi do klasy 2:123.
      
      Teraz przykład skryptu do tworzenia regułek dla firewalla na podstawie wpisów w pliku /etc/shaper/queue_download_high.0, które ustawią odpowiednie TOS dla odpowiedniego ruchu. Analogicznie do tego przykładu należy sobie dorobić pętle dla pozostałych plików konfiguracyjnych.
      #!/bin/sh
      extqueue=`grep extended_queue=yes /etc/shaper/shaper.0.cfg | wc -l`
      IFS=';'
      if [ $extqueue -eq 1 ];then
      	grep -E -v "^#|^$" /etc/shaper/queue_download_high.0 | while read prot src sport dst dport
      	do
      		if [ "$prot" == "*" ];then
      			prot="!icmp"
      		fi
      		if [ "$src" == "*" ];then
      			src="0/0"
      		fi
      		if [ "$dst" == "*" ];then
      			dst="0/0"
      		fi
      		if [ "$sport" == "*" ];then
      			sport="0:65535"
      		fi
      		if [ "$dport" == "*" ];then
      			dport="0:65535"
      		fi
      		if [ "$prot" != "icmp" ];then
      			iptables -t mangle -I FORWARD -p $prot -s $src --sport $sport -d $dst --dport $dport -j TOS --set-tos 0x10
      		else
      			iptables -t mangle -I FORWARD -p $prot -s $src -d $dst -j TOS --set-tos 0x10
      		fi
      	done
      fi
      
      Znacznik (MARK) wyliczamy ze wzoru:
      M = (1000 * X) + PRIO + (4 * (A + 4))
      gdzie: M - znacznik, X - identyfikator klasy (w tym przypadku 2 - dla local_int), A - pozycja numery IP w pliku iplist.X
      Sprawdźmy teraz czy dobrze wyliczyliśmy. Po przeliczeniu tej liczby na system szesnastkowy dostajemy w wyniku liczbę 0x848. Piszemy:
      tc -s filter show dev eth1 | grep 848
      i dostajemy w wyniku:
      filter parent 2: protocol ip pref 10 fw handle 0x848 classid 2:120
      Czyli ruch zaznaczony przez tą regułkę trafi do klasy 2:120. Teraz możemy sobie obserwować ruch wpadający do tej klasy:
      watch tc -s class show dev eth1
      i jeśli tylko połączymy się pod ssh lub telnetem z jakimś zewnętrznym serwerem to zobaczymy:
      class htb 2:120 parent 2:5 leaf a688: prio 0 rate 273Kbit ceil 273Kbit burst 15Kb cburst 1948b
       Sent 10644 bytes 133 pkts (dropped 0, overlimits 0)
       rate 11bps
       lended: 133 borrowed: 0 giants: 0 injects: 0
       tokens: 315623 ctokens: 39721
      
      I jak widać 10644 bajty przeszły przez klasę 2:120
      Teraz stworzymy regułkę na firewallu dla ruchu wychodzącego:
      # upload
      # najnizszy priorytet upload - klasa 1:123
      iptables -t mangle -A FORWARD -s 192.168.1.2 -d ! 192.168.0.0/16 -j MARK --set-mark 1123
      # najwyzszy priorytet upload - klasa 1:120
      iptables -t mangle -A FORWARD -s 192.168.1.2 -d ! 192.168.0.0/16 -m tos --tos 0x10 -j MARK --set-mark 1120
      # sredni priorytet upload - klasa 1:121
      iptables -t mangle -A FORWARD -s 192.168.1.2 -d ! 192.168.0.0/16 -m tos --tos 0x08 -j MARK --set-mark 1121
      # niski priorytet upload - klasa 1:122
      iptables -t mangle -A FORWARD -s 192.168.1.2 -d ! 192.168.0.0/16 -m tos --tos 0x10 -j MARK --set-mark 1122
      
      Wzór do obliczenia znacznika jest identyczny jak powyżej - zwracam uwagę, że upload ograniczany jest na interfejsie internetowym a nie jak download na lokalnym więc w tym przypadku identyfikator klasy mamy taki jak dla inter_int czyli w tym przypadku 1. Teraz sprawdzamy:
      tc -s filter show dev eth0 | grep 460
      i dostajemy w wyniku:
      filter parent 1: protocol ip pref 10 fw handle 0x460 classid 1:120
      Czyli wszystko jest prawidłowo. Możemy teraz obserwować klasę 1:120:
      watch tc -s class show dev eth0
      aby zobaczyć czy coś przez nią przechodzi. I widzimy:
      class cbq 1:120 parent 1:5 leaf a69c: rate 18Kbit prio 3
       Sent 12122 bytes 208 pkts (dropped 0, overlimits 0)
        borrowed 0 overactions 0 avgidle 8.07342e+06 undertime 0
      
      Czyli jak widać, przez klasę przeszły 12122 bajty.

      Teraz tworzymy regułki dla ruchu od serwera do internetu:
      iptables -t mangle -A POSTROUTING -p tcp -s 213.97.124.129/32 --sport 22:23 -d 0/0 -j MARK --set-mark 1164
      iptables -t mangle -A POSTROUTING -p udp -s 213.97.124.129/32 --sport 22:23 -d 0/0 -j MARK --set-mark 1164
      
      numer IP serwera znajduje się w pliku iplist.X na pozycji 12 (wpis w iplist.X: 213.97.124.129=eth0 eth0).
      tc -s filter show dev eth0 | grep 48c
      i wynik:
      filter parent 1: protocol ip pref 10 fw handle 0x48c classid 1:164
      I cały ruch wychodzący z serwera z portu 22 lub 23 będzie miał najwyższy priorytet.

      Wszystkie przykłady bazują na iptables ponieważ nie posiadam systemu na ipchains i nie mam jak tego przetestować.
      W archiwum shapera dołożonych zostało 12 dodatkowych plików, w tym 3, które są uzywane przez shapera przy tworzeniu regułek tylko w przypadku gdy używany jest firewall na iptables (queue_upload_serwer_high|med|low):
      /etc/shaper/queue_download_default.X
      /etc/shaper/queue_download_high.X
      /etc/shaper/queue_download_med.X
      /etc/shaper/queue_download_low.X
      /etc/shaper/queue_upload_default.X
      /etc/shaper/queue_upload_high.X
      /etc/shaper/queue_upload_med.X
      /etc/shaper/queue_upload_low.X
      /etc/shaper/queue_upload_server_default.X
      /etc/shaper/queue_upload_server_high.X
      /etc/shaper/queue_upload_server_med.X
      /etc/shaper/queue_upload_server_low.X
      
      Trzy ostatnie pliki konfiguracyjne są używane przez shaperd do tworzenia regułek. Pozostałe 6 plików w chwili obecnej nie są używane przez shaperd i trzeba sobie napisać skrypt operujący na nich.

      Jeśli komuś nic nie przechodzi przez klasy to proszę do mnie nie pisać - nie daję żadnych gwarancji, że będzie to działać na każdej dystrybucji i systemie. Jak komuś bardzo zależy aby to działało - to pofatyguję się do niego osobiście i mu zainstaluję taki system że będzie to działać - zgodnie z tym co napisałem w ofercie.

    • W przypadku używania shaperd wraz ze squid chciałbym zwrócić uwagę na kilka istotnych faktów i ograniczeń:
      • Shaperd musi mieć wpisany taki sam numer portu jak squid.
      • Należy ustawić w przeglądarce w miejscu konfiguracji PROXY aby nie używała PROXY do wczytywania lokalnych stron WWW. Jest to o tyle istotne, że jeśli się tego nie zrobi to shaperd będzie ograniczał (lub nie - w zależności od "trafień" squida) lokalne połączenia.
      • Testowałem działanie shaperd wraz ze squid przy ustawionej na firewallu translacji DNAT z portu docelowego 80 na port squida (takie wymuszenie na chama - aby wszystkie połączenia www były przekierowane na proxy - tzw transparent proxy). I wygląda na to, że to działa.
      • shaperd tworzy dla squida specjalne regułki na firewallu - przykład:
        iptables -t mangle -vxL POSTROUTING -n | grep 8080
        pokazuje regułki do znakowania pakietów (MARK)
        oraz
        iptables -vxL squid0 -n
        pokazuje rzeczywisty transfer ze squida.
      • Jeśli nie wiesz czy twój squid prawidłowo zaznacza pole TOS to możesz to sprawdzić wpisując:
        iptables -vxL squid0 -n | grep -E -v "destination|squid" | awk '{print $9,"\t",$2}'
        Wynik prawidłowo działającego squida będzie wyglądał mniej więcej tak:
        192.168.1.3      135967
        0.0.0.0/0        2074683
        192.168.1.7      2432944
        192.168.1.6      18121074
        
        Oznacza to, że np user 192.168.1.3 ściągnął przez squida 135967 bajtów danych (nietrafionych czyli takich - które trzeba było ściągać z internetu i zrobione to zostało w ramach przydziału tego usera). Wpis 0.0.0.0/0 oznacza, że 2074683 zostało przesłanych w sumie do wszystkich userów, były to dane trafione (z cache) i nie było na nie nałożonego ograniczenia.
        Jeśli tylko licznik obok 0.0.0.0/0 rejestruje ruch a liczniki użytkowników już nie to znaczy, że squid nie znakuje prawidłowo TOS - wtedy cały ruch ze squida jest puszczony bez ograniczeń.

    • Jeśli CBQ jest w modułach to przy starcie systemu trzeba wrzucić następujące moduły:
      modprobe sch_cbq
      modprobe sch_tbf
      modprobe cls_u32
      
      Dla HTB trzeba załadować następujące moduły:
      modprobe sch_htb
      modprobe sch_sfq
      modprobe cls_u32
      
  2. Daemon musi działać na prawach root i mieć możliwość zapisu do katalogu /var/shaper. Katalog taki trzeba założyć z właścicielem root i prawami 755

  3. W /etc/shaper/ignore.X sa wpisane wyjątki dla których shaper nie rezerwuje łącza (Dotyczy tylko w przypadku gdy opcja nomasq=no). Mogą to być przykładowo:
    217.96.55.5 411 - numer ip i port 411
    213.180.130.190 - numer ip i kazdy port
    22$ - każdy numer ip i port 22 (telnet)
    Zrobione jest to po to, żeby skrypt nie rezerwował łącza na transmisje nie generujące praktycznie ruchu (np. GaduGadu, IRC, telnet, Chaty itp). Należy pamiętać aby każdy numer IP kończył się znakiem spacji. Proszę nie wstawiać pustych linii w tym pliku oraz nie edytować go pod systemem Windows (problem z CR+LF).
    Aktualną listę branych pod uwagę przy podziale numerów ip i portów na maskaradzie (czyli po wyeliminowaniu połączeń z pliku /etc/shaper/ignore.X) można podglądnąć pisząc:
    /sbin/shaperd shownat
    W dostarczonym przykładowym pliku są zrobione wpisy dla popularnych komunikatorów np. GaduGady, Tlen oraz dla kilku czatów i MUD'ów.


  4. W katalogu /var/shaper generowane są pliki:
    • bitrate_user_sh.X.old - zawiera numery ip oraz przydzielone widełki dla download.
    • bitrate_user_up.X.old - zawiera numery ip oraz przydzielone widełki dla upload.
    • Można to wykorzystać do wizualizacji na stronie www - przykład użycia. Zawartość tych plików może wyglądać mniej-więcej tak:
      192.168.1.2/32 40000
      192.168.1.9/32 58000
      
      lub gdy speed_ext jest ustawiony inny niż bit (w tym przypadku Kbit):
      192.168.1.2/32 40 Kbit
      192.168.1.9/32 58 Kbit
      
    • Warto sprawdzić jak program działa wydając komendę:
      tc -s qdisc show dev eth1
      
      gdzie: eth1 to nazwa interfejsu lokalnego jeśli sprawdzamy dzielenie download
      Jeśli używasz HTB zamiast CBQ to sprawdzaj komendą:
      tc -s class show dev eth1
      
      Wyniki jej działania mogą wyglądać tak:
       qdisc tbf d09f: dev eth0 rate 5430bps burst 10Kb lat 1.2s              
       Sent 108930 bytes 73 pkts (dropped 0, overlimits 0)                   
                                                                             
       qdisc tbf d09e: dev eth0 rate 5430bps burst 10Kb lat 1.2s             
       Sent 126618 bytes 89 pkts (dropped 0, overlimits 0)                   
                                                                             
      
       qdisc tbf d09d: dev eth0 rate 1638bps burst 10Kb lat 3.8s             
       Sent 54699 bytes 65 pkts (dropped 0, overlimits 321)                  
       backlog 6110b 5p                                                      
                                                                             
       qdisc tbf d09c: dev eth0 rate 10Mbit burst 10Kb lat 4.8ms             
       Sent 0 bytes 0 pkts (dropped 0, overlimits 0)                         
                                                                             
       qdisc tbf d09b: dev eth0 rate 10Mbit burst 10Kb lat 4.8ms             
       Sent 5690 bytes 53 pkts (dropped 0, overlimits 0)                     
                                                                             
      
       qdisc cbq 10: dev eth0 rate 10Mbit (bounded,isolated) prio no-transmit
       Sent 310829 bytes 302 pkts (dropped 0, overlimits 1555)               
       backlog 5p                                                            
        borrowed 0 overactions 0 avgidle 624 undertime 0
      
      Nalezy zwrócić szczególną uwagę na linie z rate innym niż 10Mbit (lub innym w przypadku posiadania łącza lokalnego o innej szybkości maksymalnej). W tym przypadku trzy pierwsze klasy obrazują transfery trzech różnych komputerów w sieci lokalnej. Należy zwrócić uwagę, czy rejestrowane są wielkości wysłanych danych Sent. Jeśli tak to znaczy, że CBQ działa i obcina transfer przekraczający widełki.

    • W razie wystąpienia problemów przy uruchomieniu tego daemona, zanim do mnie napiszesz - postaraj się przeczytać ten opis jeszcze raz i sprawdź, czy nie popełniłeś gdzieś błedu. Potem dopiero możesz pisać. Ze względu na brak czasu moja pomoc może być trochę opóźniona (lub może jej nie być wcale) więc polecam zaglądnięcie do Księgi gości. Może ktoś z wpisanych tam adminów zechce pomóc wcześniej niż ja będę w stanie to zrobić.

    • Poniżej można zobaczyć jak zachowuje się w praktyce shaperd (łącze DSL).


      Statystyki wygenerowano programem lstat 2.2


      Ponieważ część z Was zanudza mnie mailami z prośbą o pomoc w konfiguracji programu lstat do współpracy z shaperd to poniżej postaram się wyjaśnić jak to zrobić.
      • Zakładamy nowy wykres Statystyki Pakietów i jakoś go tam nazywamy (dla identyfikacji). Właściwie to domyślna konfiguracja jest wystarczająca do współpracy z shaperd więc nie zmieniamy w ustawieniach wykresu niczego.
      • Pod wykresem klikamy na przycisk Nowy element i w tabelce, która pojawi się poniżej wpisujemy w pozycji Filtr danych nazwę filtru dla lokalnego usera oraz jego nazwę. Nazwę filtru dla transferów przychodzących (download) znajdujemy wpisując:
        /usr/local/lstat/bin/show_filters | grep shaper | awk '{print $1,$11}'
        
        a dla wychodzących (upload):
        /usr/local/lstat/bin/show_filters | grep shaout | awk '{print $1,$10}'
        
        Dostaniemy listę z nazwami filtrów po lewej stronie i numerami ip im odpowiadającymi Kolejność jest taka sama jak wpisy w pliku iplist dlatego lepiej potem nie przestawiać linijek w iplist.
        Zakładamy osobne wykresy dla download i upload (z tego co zauważyłem to można maksymalnie 10 userów na jeden wykres wpisać a potem trzeba tworzyć kolejne wykresy) i to jest cała filozofia. Mam nadzieję, że mi wreszcie dacie spokój z lstat'em.

    • Jeśli przebrniesz przez instalację i uda Ci się skonfigurować ten program na swoim serwerze, może zechcesz się wpisać do Księgi gości. Proszę, podaj w niej:
      • Wersja shaper'a
      • Opis systemu na serwerze (dystrybucja, wersja kernela, inne uwagi)
      • swój e-mail kontaktowy (możesz go zakończyć jakimś "ściemniaczem anyspamowym" ;) typu .NOSPAM)
      • url strony www (jesli isnieje) serwera
      Może pomożesz innym w instalacji tego daemona a mnie trochę odciążysz. Będę bardzo wdzięczny.

    • Będzie mi miło, jeśli jakiś szczęśliwy administrator wrzuci gdzieś na swoją stronę sieciową ten mały banerek:

      Powered by Shaper CBQ

      A tutaj jest kod html do wklejenia:
      <p><a href="http://sp9wun.republika.pl/">
      <img src="http://sp9wun.republika.pl/linux/pics/shaperd.gif" border="0" 
      width="102" height="47" alt="Powered by Shaper CBQ"></a></p>
Zobacz skrypt PHP kto.php (dodatkowy skrypt ckwintalk do kontroli wintalka - u mnie w sieci wintalk jest obowiązkowy) do generowania listy aktywnych komputerów wraz z przydzielonymi im widełkami przez shaper'a. Skrypt trzeba wyedytować i powpisywać dane ze swojej sieci. Wywołuje się go odwołując się do kto.php.
60 - oznacza, że skrypt będzie odświerzany co 60 sekund. Skrypt wymaga skonfigurowania DNSa dla lokalnych numerów ip. Ponadto mogą wystąpić błędy z niektórymi wersjami binda. Trzeba się pobawić w przerabianie.

Znane błędy

Komunikaty w logu:
  • shaperd0: BUG: download: x=2
    - Wpis miał służyć do czegoś innego ale obecnie świadczy o wykryciu przez shapera podwójnego wpisu jakiegoś numeru IP w pliku iplist.X


  • shaperd0: BUG: upload: x=2
    - Wpis miał służyć do czegoś innego ale obecnie świadczy o wykryciu przez shapera podwójnego wpisu jakiegoś numeru IP w pliku iplist.X


  • shaperd0: Can't find mask for IP v]ţ.Ň
    - Tak objawia się bug, którego jeszcze nie zlokalizowałem. Wygląda na to, że coś jeździ mi po pamięci ale nie mogę tego zlokalizować. Wpis pojawia się sporadycznie i jeśli kogoś denerwuje to może sobie wyłączyć wyrzucanie przez shapera komunikatu "Can't find mask for IP ..." ustawiając w konfiguracji mask_mesg=no


  • kernel: CBQ: class XXXXXXXX has bad quantum==0, repaired
    - Błąd pojawiający się na niektórych systemach i jak na razie przyczyny jego występowania nie znalazłem. Znana jest mi strona http://cbq.med.cz/ - niestety - nie pomogła.


  • kernel: CBQ: class XXXXXXXX has bad quantum==YYYYY, repaired
    - Błąd pojawiający się na niektórych systemach i jak na razie przyczyny jego występowania nie znalazłem.


  • kernel: HTB init, kernel part version 3.7
    - Wpis pojawia się przy inicjalizacji klasy HTB dla wersji 3.X. Nie oznacza on niczego złego jednak fakt, że przy każdym tworzeniu klasy HTB tworzony jest taki wpis powoduje, że nie ma sensu używać shapera z wyłączoną opcją continuous_control bo co parę sekund będzie ten komunikat w logu zapisywany.


  • Feb 27 23:52:43 frodo kernel: htb*g j=3799623                  
    Feb 27 23:52:43 frodo kernel: htb*r7 m=0                       
    Feb 27 23:52:43 frodo kernel: htb*r6 m=0                       
    Feb 27 23:52:43 frodo kernel: htb*r5 m=0                       
    Feb 27 23:52:43 frodo kernel: htb*r4 m=0                       
    Feb 27 23:52:43 frodo kernel: htb*r3 m=0                       
    Feb 27 23:52:43 frodo kernel: htb*r2 m=0                       
    Feb 27 23:52:43 frodo kernel: htb*r1 m=0                       
    Feb 27 23:52:43 frodo kernel: htb*r0 m=0                       
    
    pojawia się u mnie przy inicjalizacji klasy HTB 3.X. Uwagi jak wyżej.


  • kernel: HTB: need tc/htb version 3 (minor is 7), you have 10
    - uaktualnij sobie komendę tc - najlepiej pobierz ją ze strony autora HTB.


  • kernel: HTB: mindelay=500, report it please !
    - Błąd opisany na stronie HTB FAQ. Przyczyna jego może być taka, że jakiś user dostał przydział mniejszy niż zalecany przez autora HTB 4Kbit. Aby go uniknąć wystarczy wpisać lospeed nie mniejsze niż 4Kbit.


  • kernel: assertion (cl && cl->un.leaf.q->q.qlen) failed at sch_htb.c(959)
    htb: class 10159 isn't work conserving ?!
    - Błąd opisany na liście dyskusyjnej lartc - u mnie występuje przy inicjalizacji HTB - żadnych przykrych objawów nie zauważyłem.


Problemy

Aby ustrzec się pewnych problemów, które mogą wyniknąć w trakcie normalnej eksploatacji daemona należy przestrzegać kilku zasad (zasady te będą ulegać zmianom w trakcie wprowadzania zmian w kolejnych wersjach programu - na razie jednak mysząbyć ponieważ nie jestem wszechwiedzący i nie z każdym problemem potrafię sobie poradzić)

  1. Jeśli shaperd wiesza się lub nie chce się uruchomić - zacznij od skompilowania na swoim systemie kodów źródłowych. Plik wykonywalny dostarczany w archiwum jest skompilowany na dość świeżym systemie i mogą być problemy z uruchomieniem na bardziej wiekowych dystrybucjach.


  2. Jeśli shaperd działał a po np "zwisie" systemu przy starcie sie zawiesza to przed jego uruchomieniem usuń plik: /var/shaper/last.X - gdzie X to numer konfiguracji shapera (zwykle jest to 0). Problem jest spowodowany tym, że shaper nie ma zrobionej kontroli składni zawartości tego pliku. Jakiekolwiek uszkodzenie zawartości tego pliku shapera nam położy kompletnie. W przyszłości nad tym popracuję a na razie jest jak jest. Lepiej żeby się nic nie wieszało :)


  3. Przy starcie systemu skrypt startowy /etc/init.d/shaperd uruchamiaj możliwie na końcu a w szczególności zawsze uruchamiaj go po jakichkolwiek skryptach, które mogą modyfikować firewall (np. wszelkie skrypty do konfiguracji maskarady, firewalla itp.).


  4. Jeśli wykonywałeś jakiekolwiek operacjie na firewallu (wyczyściłeś liczniki regułek, dopisałeś lub skasowałeś jakieś regułki, przeładowałeś firewall itp.) obowiązkowo zrestartuj shaperd. Zaniechanie tego może skutkować zdławieniem całego transferu przychodzącego, ponieważ shaperd przy starcie tworzy własne regułki na firewall'u i muszą być one sprawdzane w pierwszej kolejności. Zmiana kolejności reguł na firewallu może (choć nie musi) skutkować tym, że reguły rejestrujące ruch przychodzący dla shaper'a niczego nie będą rejestrować i daemon stwierdzi, że nikt nie wykorzystuje przydzielonych widełek więc zacznie obniżać przydziały (aż do minimum gwarantowanego). Aby sprawdzić czy reguły dla shapera znajdują się na właściwym miejscu i pracują prawidłowo wystarczy zrobić następującą operację:
    • dla ipchains:
      • ipchains -L output -n
        tablica shaperX powinna być na najwyższej pozycji
        Chain output (policy ACCEPT):                                            
        target     prot opt     source                destination           ports
        shaout0    all  ------  0.0.0.0/0             0.0.0.0/0             n/a
        shaper0    all  ------  0.0.0.0/0             0.0.0.0/0             n/a
        ppp-out    all  ------  0.0.0.0/0             0.0.0.0/0             n/a  
        eth-out    all  ------  0.0.0.0/0             0.0.0.0/0             n/a  
        


      • ipchains -L shaper0 -n
        w tej tablicy powinny znajdować się reguły dla wszystkich numerów IP z pliku /etc/shaper/iplist.0. Przykład:
        Chain shaper0 (1 references):                                               
        target     prot opt     source                destination           ports   
        RETURN     tcp  ------ !192.168.1.1           192.168.1.2           * ->   *
        RETURN     tcp  ------ !192.168.1.1           192.168.1.3           * ->   *
        RETURN     tcp  ------ !192.168.1.1           192.168.1.4           * ->   *
        RETURN     tcp  ------ !192.168.1.1           192.168.1.5           * ->   *
        RETURN     tcp  ------ !192.168.1.1           192.168.1.6           * ->   *
        RETURN     tcp  ------ !192.168.1.1           192.168.1.7           * ->   *
        RETURN     tcp  ------ !192.168.1.1           192.168.1.8           * ->   *
        
        Analogicznie jest dla tablicy upload shaout, z tym, że w kolumnie source będą numery IP userów.
      • watch ipchains -vxL shaper0 -n
        watch ipchains -vxL shaout0 -n
        
        pozwoli na obserwowanie, czy regułki liczą ilość pobranych danych przezd poszczególne numery IP. Generalnie - jeśli jakiś numer aktualnie coś ciągnie z internetu to jego regułka musi liczyć. Jeśli tego nie robi to należy próbować zrestartować shapera

    • dla iptables:
      • iptables -L FORWARD -n --line-numbers | grep sha
        tablica shaoutX powinna mieć pozycję 1 a shaperX pozycję numer 2:
        1    shaout0     all  --  0.0.0.0/0            0.0.0.0/0
        2    shaper0     all  --  0.0.0.0/0            0.0.0.0/0
        
      • iptables -L shaper0 -n
        w tej tablicy powinny znajdować się reguły dla wszystkich numerów IP z pliku /etc/shaper/iplist.0. Przykład:
        Chain shaper0 (1 references)                          
        target     prot opt source               destination 
        RETURN     all  -- !192.168.0.0/16       192.168.1.2 
        RETURN     all  -- !192.168.0.0/16       192.168.1.3 
        RETURN     all  -- !192.168.0.0/16       192.168.1.4 
        RETURN     all  -- !192.168.0.0/16       192.168.1.5 
        RETURN     all  -- !192.168.0.0/16       192.168.1.6 
        RETURN     all  -- !192.168.0.0/16       192.168.1.7 
        RETURN     all  -- !192.168.0.0/16       192.168.1.8 
        RETURN     all  -- !192.168.0.0/16       192.168.1.9 
        RETURN     all  -- !192.168.0.0/16       192.168.1.10
        
        Analogicznie jest dla tablicy upload shaout, z tym, że w kolumnie source są numery IP userów.
      • watch iptables -vxL shaper0 -n
        watch iptables -vxL shaout0 -n
        
        pozwoli na obserwowanie, czy regułki liczą ilość pobranych danych przezd poszczególne numery IP. Generalnie - jeśli jakiś numer aktualnie coś ciągnie z internetu to jego regułka musi liczyć. Jeśli tego nie robi to należy próbować zrestartować shapera

  5. Nie wolno samodzielnie ustawiać czasów utrzymywania połączeń na maskaradzie (np. komendą ipchains -M -S) - dotyczy posiadaczy kerneli 2.2.x (ponieważ w 2.4.x komenda ta nie działa ;). Czasy te ustawia shaperd i na ich podstawie kontroluje, który numer IP jest aktywny na łączu. Ustawienie tych czasów przy pracującym shaperze może spowodować, że shaperd nie będzie widział niektórych połączeń przez maskaradę a co za tym idzie - nie przydzieli dla nich widełek.


  6. Generalnie odradzam niewpisywania wybranych (uprzywilejowanych?) numerów IP do pliku /etc/shaper/iplist.X w celu uniknięcia przydzielenia im widełek. Skutek takiego działania wcale nie jest oczywisty i może być daleki od zamierzonego. W zależności od systemu i wersji zainstalowanego na nim oprogramowania, na jednych systemach coś takiego może zadziałać i wybrany numer IP będzie mógł przejąć całe łącze dla siebie. Na innych systemach może być problem z dopchaniem się do łącza bez przydzielonych widełek. Niemniej skutek zawsze będzie jeden - shaperd będzie bardzo gwałtownie zmieniał przydziały innym użytkownikom "szarpiąc" im szybkościami. Prowadzi to niewątpliwie do nierównomiernego obciążenia łącza i wypacza ideę stosowania shapera.


  7. Kolega Grzegorz Cichowski stwierdził, że w przypadku wpisywania w pliku /etc/shaper/shaper.X.cfg parametrów dla łącza lokalnego 100Mbit należy podać szybkość 8Gbit co po przeliczeniu na bity dałoby w wyniku liczbę 8589934592, która jest z kolei liczbą 33 bitową i przekracza wielkość rejestrów procesora. Aby wpisać taką liczbę należy przeliczyć ją na kbit a nie podawać w bit. Po przeliczeniu liczba ta wynosi 8388608 i jednostka kbit. Proszę pamiętać o przeliczeniu na tą jednostkę wszystkich szybkości podawanych w konfiguracji jak i w lini poleceń!


  8. Proszę nie używać do edytowania plików konfiguracyjnych programów pracujących pod Dosem/Windowsem z powodu niestandardowego formatu końca linii (CR+LF).


  9. Nie należy wstawiać pustych linii do plików konfiguracyjnych.


  10. Proszę nie wstawiać pustych znaków (spacja, tabulacja itp) przed parametrami w pliku konfiguracyjnym!


  11. Zauważyłem na niektórych konfiguracjach (w szczególności gdy łącze jest niesymetryczne - np DSL), że czasem użycie w obu kierunkach klas typu HTB powoduje zdławienie szybkości ściągania całego łącza do szybkości upload (np przy DSL 2Mbit/256Kbit - download jest ograniczony do 256Kbit). Nie wiem od czego to zależy - ale w takich przypadkach zalecam używanie dwóch różnych typów klas dla download i upload. Przykład:
    class_type=htb
    upload_class_type=cbq
    


FAQ

  1. Nie rozumiem jaka jest idea funkcji "jump". Jakie ustawienie by mi Pan polecał dla łącza 256 downstream i 64 upstream. Przydzielane minimum u mnie wynosi 16kbit/s?


  2. Jeśli na łączu 230 kbit siedzą dwie osoby i dostają one po 50 i 35 kbit to oznacza to ze skrypt określił, że więcej one nie potrzebują ? (Te wartości w konfiguracji oznaczają wartości minimalne dla tych hostow).


  3. Gdy w pliku iplist.0 nic nie jeste wpisane to shaperd uruchamia się bez błędów, gdy wpiszę tam jakiś lokalny adres to zaraz pojawia się błąd "interface name for IP number 192.168.42.12/32 not found in /etc/shaper/iplist.0. Co jest tego przyczyną?


  4. Mam server-router na Freesco i chciałbym wiedzieć czy jest wersja shaperd'a dla niego?


  5. Shaperd czasem nie widzi maski (jak sądze podsieci). Kartę sieciową mam ustawioną statycznie 192.168.0.1/24 i działa kilka, kilkanaście minut po czym pisze "can't find mask for IP....". Jedyne co zaobserwowałem, to że dzieje się to zwykle po podłączeniu się kogoś do sieci (dhcp).


  6. Czy shaperd udałoby się odpalić na systemie rodziny OpenBSD?


  7. Według tego co jest napisane na stronie - jest możliwość konfiguracji żeby do jednych widełek przypisywać 2 ipki. Czy jest też taka możliwość jeśli ipki nie są sąsiadujące? np 192.168.1.4 i 192.168.1.14 żeby miały ten sam przydział?


  8. Coś mi nie gra - mianowicie ustawienie w Kbit transferow sdi - czy ta linia jest prawidlowa ??
    inter_int=ppp0;0,5;92;0,5;60;auto;1
    i nie wiem czy mam prawidłowo ustawione?? Bo chciałbym żeby było download min 0,5kbit max 9kbit a upload min 0.5kbit max 6kbit


  9. ----[router]--tu jest podsiec (adresy publiczne) z serwerami www, poczty, proxy---[router]---tu podsieć (adresy publiczne), do której jest podłączony router z shaperkiem :)----[router z shaperkiem]--- klienci, podsieć 192.168.1.0/24.
    Czy jest możliwe, aby ruch do sieci z proxy, www, pocztą był ogólnie pomijany w dzieleniu - po wpisaniu do ignorowanych z tego co rozumiem transfer nie będzie obcięty tylko w momencie, gdy podczas sprawdzania aktywnych połączeń na maskaradzie będzie tam ruch do ip tej podsieci.


  10. Jak mam dopisywac 'virualne' karty sieciowe do shapera ? Chodzi mi o sytuacje kiedy jedna karta siecowa ma dwa IP i w systemie sa to dwa rozne urzadzenia, np.: eth0 i eth0:0. Nie moge przekonac shapera aby przyjal urzadzenie eth0:0.


  1. Policz - jeśli cykl pracy (delay) masz ustawiony na 10 sekund i co cykl shaperd zwiększa komuś widełki od 16kbit to pełnej szybkosci to ile czasu mu to zajmie? 15 cykli czyli 150 sekund dla jump_type=1 (skok co cykl o 16kbit). Jeśli to wartość do zaakceptowania przez Ciebie to sobie zostaw tyle.


  2. Tak (pod warunkiem, że shaperd pracuje prawidłowo - jest pewien objaw nieprawidłowego działania shaperd jeśli wszyscy mają zawsze przydzielone minimalne widełki i nigdy się one nie zwiększają (oprócz momentów kiedy ktoś się włącza po przerwie w pracy. Można sprawdzić czy shaperd rozpędza połączenie czekając na minimalny przydział a potem otwierając dużą ilość połączeń i ciągnąc ile się da. Powinien się rozpędzać. Jeśli tego nie robi to polecam lekturę sekcji Problemy.)


  3. Brak przypisanego interfejsu dla tego numeru IP wpis w iplist powinien wyglądać przykładowo tak (należy wpisać odpowiednie nazwy interfejsów - podane nazwy eth0 i eth1 to przykład):
    192.168.42.12/32=eth1 eth0
  4. Nie ma - fressco nie ma czegoś takiego jak CBQ i shaperd nawet jakby zadziałał to i tak nic nie ograniczy bo nie ma czym (nie ma odpowiednich narzędzi w kernelu do zarządzania pasmem). Istnieje za to skrypt dynamicznego ograniczania pasma dla FreeSCO (dla innych systemów opartych na jądrach 2.0.3x po drobnym przystosowaniu też powinno działać). Skrypt ten nazywa się justice, i jest ciągle niedokończoną prowizorką :), ale jest bardzo skuteczny w zakresie ruchu przychodzącego. http://www.freesco.internetdsl.pl/justice.htm (podał Robert R "RaaDaaR" z *Polska Grupa FreeSCO*)


  5. To jest efekt tego, że dla iptables w tablicy ipconntrack pojawiają się czasem takie połączenia, które shaperd nie potrafi wyeliminować - jak na przykład w Twoim przypadku 192.168.0.1 czyli numer IP serwera - rozwiązania są dwa:
    • wpisać do ignore.0 numer ip 192.168.0.1
      gdzie to znak spacji - to ważne bo inaczej shaperd będzie ignorował wszystkie numery ip zaczynające sie od 192.168.0.1 czyli np 192.168.0.1 ale i 192.168.0.10-19, 192.168.0.100-199
    • lub włączyć opcję nomasq=yes - wtedy shaperd nie sprawdza tablicy ipconntrack tylko regułki na firewallu

  6. Nie.


  7. Nie. Numery IP muszą być sąsiadujące i spełniać takie same warunki jak numery IP ze wspólną maską. Czyli pierwszy IP musi być podzielny przez 2^n gdy chcemy połączyć 2^n numerów IP w jeden przydział.


  8. Na komputerach znak dziesiętny to nie przecinek tylko kropka. Nawiasem mówiąc shaperd i tak ułamków nie przyjmuje więc wpisywanie z przecinkiem spowoduje tylko tyle, że wartość zostanie zaokrąglona do pełnej liczby bez przecinka - czyli 0.5 = 0. Przelicz sobie wszystko na bity jak musisz mieć mniejsze wartości.


  9. Nie jest możliwe. Ignore na to nie pomoże. Można by próbować wpisywać z zewnątrz dodatkowe filtry u32 z tymi wyjątkami (pamiętaj aby wpisywać po każdym restarcie shapera). Na przykład:
    tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip src 217.97.124.128/32 flowid 1:1
    Gdzie:
    • eth1 - to interfejs lokalny do sieci
    • 1:0 - dla numeru klasy dla tego interfejsu lokalnego (wpis w shaper.cfg sekcja local_int - ostatnia cyfra w definicji - 1)
    • 217.97.124.128/32 numer IP wcześniejszego routera, dla którego transfer ma być nieograniczany
    • 1:1 - analogicznie jak dla 1:0
    Należałoby też oczywiście wpisać ten numer IP wcześniejszego routera w pliku ignore.


  10. Shaperd nie dopuszcza wpisu aliasów interfejsów. Generalnie iproute2 wogóle nie rozpoznaje czegoś takiego jak nazwa interfejsu z dwukropkiem. Można shaperd zmusić do pracy z dodatkowymi numerami IP ale z pewnymi kombinacjami i ograniczeniami.
    Załóżmy, że mamy interfejs lokalny eth1 na którym jest założony alias eth1:1 z numerem ip zewnętrznym. W local_int definiujemy numery IP lokalne podstawowe dla danego interfejsu:
    local_int=eth1;10240;192.168.1.1/32;192.168.1.0/24;2
    ustawiamy opcje:
    nomasq=1
    i w iplist oprócz numerów IP lokalnych wpisujemy dodatkowo ten zewnetrzny IP.
    Problem takiego wpisu jest tylko jeden - user posługujący się tym numerem zewnętrznym będzie miał ograniczony transfer lokalny z serwera. Można oczywiście to ominąć dopisując dodatkową regułkę filtru u32 - coś a la przykład
    wcześniejszy. Lepsze rozwiązanie to wogóle nie stosowanie aliasów tylko zrobienie translacji SNAT/DNAT zewnętrznych numerów IP tak aby były widziane wewnątrz sieci jak lokalne. Wtedy problemów nie ma żadnych.




Powrót Linux
@
Webmaster Grzegorz Fitrzyk

Google-Pagerank.pl - Pozycjonowanie + SEO