- 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
- 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.
- 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
- 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
- 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
- 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
- Inne przykłady wpisów w iplist.X:
- 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
- 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
- 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:
- class_type
- upload_class_type
- squid_support
- squid_port
- extended_queue
- ceil_download
- ceil_upload
- speed_ext
- last_rate_perm
- pos_diff
- inter_int
- 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
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
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.
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:
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.
