- 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 ;).high_start_speed=yes even_division=no continuous_control=no check_always=yes squid_support=no divide_upload=yes extended_queue=no nomasq=no class_type=cbq upload_class_type=cbq jump_type=5 speed_ext=bit debug=0 delay=10 write_delay=0 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:- high_start_speed - sposób przydzielania łącza przy pojawieniu się nowego numeru ip. Dla yes 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 no przydzielona szybkość jest minimalna (taka jak podana w parametrze lospeed w konfiguracji interfejsu internetowego).
- 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.
- check_always - włączanie kontroli transferu nawet w przypadku gdy nałączu pracuje jeden numer IP. Bez tego nie będzie kontroli transferu wychodzącego gdy ktos będzie sam na łączu wisiał.
- squid_support - włączanie współpracy ze SQUID'em. 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/qos/. Klasy tworzone komendą tc a opisane w sekcji Użycie tworzy shaperd więc nie ma potrzeby robić z nimi czegokolwiek. Squid musi używać portu 8192.
- 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.
- 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!).
- class_type - typ klasy zarządzający pasmem w kierunku download. Możliwe do wyboru klasy to: standardowa CBQ oraz HTB.
- upload_class_type - typ klasy zarządzający pasmem w kierunku upload. Możliwe do wyboru klasy to: standardowa CBQ oraz HTB.
- 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.
- debug - jak coś nie działa to można ustawić poziom śledzenia w logu (dostepne poziomy 0 - brak, 1, 2, 3)
- 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.
- 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)
- 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).
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.
high_start_speed=yes even_division=no continuous_control=no check_always=yes squid_support=no divide_upload=yes extended_queue=no nomasq=no class_type=cbq upload_class_type=cbq jump_type=5 speed_ext=Kbit debug=0 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.
high_start_speed=yes even_division=no continuous_control=no check_always=yes squid_support=no divide_upload=yes extended_queue=no nomasq=no 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
gcc /usr/src/shaperd/shaperd.c -o /sbin/shaperd
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 ppp1Wprowadził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 ppp1Co 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 ppp0Jest to podział między dwoma interfejsami. Przy włączonej opcji even_division=1 możemy zaczynać działalność providerską :)
- lospeed - minimalna gwarantowana szybkość. Nie może być większa (ale mniejsza może być) od wartości wyliczonej na podstawie tego prostego wzoru:
lospeed = hispeed / liczba_IP
gdzie:- hispeed - maksymalna szybkość z jaką można ściągać dane z łącza internetowego
- liczba_IP - maksymalna ilość numerów IP, które mogą pracować przez to łącze.
Proszę nie podawać bzdurnych wartości lospeed sugerując się nazwą "minimalna gwarantowana przepustowość". Jeśli mamy łącze SDI gdzie hispeed wynosi 92000 (jednostka bit) a userów do tej sieci jest podpiętych 10 to bezsensem jest dać każdemu lospeed równe 16000 (czyli transfer 2KB/sek) ponieważ gdy będzie na łączu pracowało 10 userów i każdy dostanie przydział 16000 to po prostym przemnożeniu wychodzi, że łącze powinno mieć szybkość ok 160Kbit! Skutek takiego ustawienia będzie taki, że część userów "załapie się" na przydział a część pomimo, że dostanie przydział to nigdy go nie wykorzysta (jeśli wogóle uda im się cokolwiek pociągnąć z internetu). Analogicznie liczymy upload_lospeed na podstawie upload_hispeed. - hispeed - należy podawać szybkość łącza nie deklarowaną przez provider'a lecz rzeczywistą, jaką udaje się uzyskać ciągnąc (lub wysyłając dla upload_hispeed) coś przez dłuższy czas przez to łącze. Inaczej dzielenie wirtualnej szybkości mija się z celem. Łącze SDI nie pracuje z szybkością 115kbit tylko 92kbit (w jedną stronę) więc wpisywanie większych wartości powoduje tylko tyle, że ktoś dostanie w sieci przydział szybkości, którego nigdy nie uda mu się osiągnąć. Po co więc kogoś oszukiwać. Ja dla SDI ustawiam dla parametru hispeed wartość 92000 a upload_hispeed wartość70000.
Jeśli nie znasz możliwości swojego łącza, ustaw na początek deklarowaną szybkość, zainstaluj (i skonfiguruj) program lstat do robienia statystyk a następnie obciąż maksymalnie łącze przez kilkadziesiąt minut (pociągnij coś dużego - najlepiej kilka dużych plików na raz) zapuszczając kilka (lub kilkanaście) pracujących równolegle wget na serwerze. Na statystykach zobaczysz ile poszło w tym czasie przez łącze.
Jeśli łącze nie pracuje równomiernie w ciągu doby (najczęściej jest tak jak się ma kupione łącze u jakiegoś nieuczciwego provider'a, który sprzedał w sumie więcej łącz niż sam posiada to trzeba sobie zrobić kilka konfiguracji shapera (dublujemy wszystkie pliki konfiguracyjne (shaper.X.cfg, ignore.X oraz iplist.X) z katalogu /etc/shaper i zmieniamy im cyferki w nazwach np. shaper.0.cfg - dla normalnej pracy łącza, shaper.1.cfg - gdy łącze pracuje beznadziejnie (w godzinach popołudniowych i w weekend? ;) (oczywiście shaper.1.cfg trzeba odpowiednio zmodyfikować dla beznadziejnej pracy łącza - np. obniżyć hispeed i lospeed :). Potem wrzucamy do crontab odpowiednie wpisy:00 00 * * * root killall shaperd;/sbin/shaperd -config=0 00 15 * * * root killall shaperd;/sbin/shaperd -config=1
Co spowoduje, że shaperd będzie używał konfiguracji 0 w godzinach od 00:00-15:00 a od 15:00-00:00 konfiguracji 1. - upload_hispeed - podobnie jak z hispeed - powinno się wpisać taką wartość z jaką szybkością da się przepchać dane przez łącze w kierunku od userów do internetu. W przypadku łącz synchronicznych wartość ta będzie równa hispeed a w przypadku łącz asynchronicznych może być również taka sama lecz w przypadku pchania danych z pełną szybkością można zauważyć spadek szybkości ściągania. Można więc sobie tą wartość ustawić na poziomie takim, na jakim nie zauważamy jeszcze wpływu szybkości wysyłania do szybkości pobierania. W przypadku łącz DSL wartość upload_speed jest dużo niższa niż hispeed i należy ustawić ją o kilka procent mniej niż deklarowana dla danego typu łącza szybkość upload (np. dla DSL 512/128 upload_speed można próbować ustawić na 110Kbit).
tc -s class show dev eth0moż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: 15581A dla upload:
tc -s class show dev eth0zobaczymy 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 0Dodatkowe 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 mnieprzesłany przez klasy z wyższym priorytetem). Teraz przykład regułek dla firewalla, które spowodują rozdzielenie ruchu do użytkownika zgodnie z priorytetami. Dajemy ssh i telnet najwyższy priorytet:
iptables -t mangle -A FORWARD -p tcp -s 0/0 --sport 22:23 -d 192.168.1.2/32 -j MARK --set-mark 2120 iptables -t mangle -A FORWARD -p udp -s 0/0 --sport 22:23 -d 192.168.1.2/32 -j MARK --set-mark 2120Znacznik (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 848i dostajemy w wyniku:
filter parent 2: protocol ip pref 10 fw handle 0x848 classid 2:120Czyli 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 eth1i 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: 39721I jak widać 10644 bajty przeszły przez klasę 2:120
Teraz stworzymy regułkę na firewallu dla ruchu wychodzącego:
iptables -t mangle -A FORWARD -p tcp -s 192.168.1.2/32 -d 0/0 --dport 22:23 -j MARK --set-mark 1120 iptables -t mangle -A FORWARD -p udp -s 192.168.1.2/32 -d 0/0 --dport 22:23 -j MARK --set-mark 1120Wzó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 460i dostajemy w wyniku:
filter parent 1: protocol ip pref 10 fw handle 0x460 classid 1:120Czyli wszystko jest prawidłowo. Możemy teraz obserwować klasę 1:120 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 0Czyli 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 1164numer 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 48ci wynik:
filter parent 1: protocol ip pref 10 fw handle 0x48c classid 1:164I 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 shaperd dołożonych zostało 9 dodatkowych plików, które są uzywane przy tworzeniu regułek tylko w przypadku gdy używany jest firewall na iptables:
/etc/shaper/queue_download_high.X /etc/shaper/queue_download_med.X /etc/shaper/queue_download_low.X /etc/shaper/queue_upload_high.X /etc/shaper/queue_upload_med.X /etc/shaper/queue_upload_low.X /etc/shaper/queue_upload_server_high.X /etc/shaper/queue_upload_server_med.X /etc/shaper/queue_upload_server_low.XPliki te zawierają przykładową konfigurację.
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.
- Proxy musi używać portu 8192.
- 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.
- Nie testowałem działania shaperd wraz ze squid przy ustawionej na firewallu translacji DNAT z portu docelowego 80 na port 8192 (takie wymuszenie na chama - aby wszystkie połączenia www były przekierowane na proxy). Nie wiem, jak się zachowają w takiej sytuacji regułki liczące ruch wychodzący z portu 8192 do lokalnych userów.
- shaperd tworzy dla squida specjalne regułki na firewallu - przykład:
iptables -t mangle -vxL OUTPUT -n | grep 8192
modprobe sch_cbq modprobe sch_tbf modprobe cls_u32Dla HTB trzeba załadować następujące moduły:
modprobe sch_htb modprobe sch_sfq modprobe cls_u32
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 shownatW dostarczonym przykładowym pliku są zrobione wpisy dla popularnych komunikatorów np. GaduGady, Tlen oraz dla kilku czatów i MUD'ów.
- 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 58000lub 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
tc -s qdisc show dev eth1gdzie: 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 eth1Wyniki 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.
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.
- 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
<p><a href="http://sp9wun.republika.pl/"> <img src="http://sp9wun.republika.pl/linux/pics/shaper.png" border="0" width="89" height="32" alt="Powered by Shaper CBQ"></a></p>
