| Zawansowany routing oraz sterowanie prędkością łącza za pomocą kolejki HTB i IMQ. |
|
|
|
| Redaktor: Administrator | |
| 29.06.2009. | |
|
System operacyjny: Linux Slackware 9.0 kernel 2.4.21
Problem: Gdy zarządzamy serwerem i udostępniamy łącze innym komputerom zdarza się czasem że jeden użytkownik zapcha nam całą sieć bo ściąga np. film albo dużo muzyki przez co inni użytkownicy praktycznie nie mogą korzystać z łącza. Aby temu zapobiec wymyślono wiele różnych rozwiązań np. skrypty CBQ , kolejki (TBF,SFQ,PRIO oraz HTB). Niestety nie rozwiązują one całkowicie tego problemu ponieważ obsługują tylko ruch wychodzący z serwera. Poniżej przedstawię jak to rozwiązać.
Spis treści:
I.Opis kolejek ruchu wychodzącego. II.Opis kolejki ruchu przychodzącego. III.Ustawienie routingu oraz rozwiązanie problemu na przykładzie kolejek HTB i IMQ. -Założenia -Instalacje interfejsów sieciowych
-Routing
-Ograniczenie prędkości dla interfejsów na dane ip wewnętrzne
a1) Polecenia i opis kolejki HTB -Przykład 1 i opis przykładu (HTB) -Przykład 2 i opis przykładu (HTB)
a2) Opis i przygotowanie kolejki IMQ -Przykład 1 i opis przykładu (IMQ) -Przykład 2 i opis przykładu (IMQ) IV. Materiały z których korzystałem.
I.Opis kolejek wychodzących:
Kolejka bezstratna (ang.Work-Conserving) Ta kolejka zawsze dostarcza pakiet, jeśli tylko jest dostępny. Innymi słowy nigdy nie odwleka wysłania pakietu, jeśli urządzenie jest gotowe do przyjęcia go (w przypadku ruchu wychodzącego).
Kolejka stratna (ang.non-Work-Conserving) Niektóre kolejki takie jak na przykład TBF mogą być zmuszone przytrzymać pakiet przez pewien czas, by dopasować sie do ustalonego limitu na przepustowość. Oznacza to, że czasami nie wyślą pakietu, mimo że gdzieś w nich się znajduje.
Kolejka pfifo_fast Kolejka ta to tradycyjnie pierwszy wszedł, pierwszy wyjdzie co oznacza że żaden pakiet nie jest specjalnie traktowany.
Kolejka TBF – Tocken Bucket FilterToken Bucket Filter (TBF) to prosta kolejka z dyscypliną, która przepuszcza tylko daneprzychodzące z pewną częstotliwością nie przekraczającą nałożonych ograniczeń, ale z możliwością przyjęcia krótkich serii danych, które przekraczają to ustawienie. Co również nie jest bez znaczenia TBF jest bardzo precyzyjna, przyjazna zarówno dla sieci jak i procesora. Implementacja TBF składa się z wiadra (ang. bucket), wypełnianego pewnymi wirtualnymi porcjami danych, żetonami (ang. token) z określoną częstotliwością. Najważniejszym parametrem wiadra jest jego rozmiar, określający ilość żetonów, które może ono przechować. Każdy nadchodzący żeton wyjmuje jeden przychodzący pakiet z kolejki danych i jest kasowany z wiadra.
Skojarzenie tego algorytmu z dwoma przepływami - żetonów i danych, daje trzy możliwe scenariusze:
Dane docierają do kolejki z częstotliwością równą częstotliwości napływania żetonów. W tym przypadku każdy przychodzący pakiet pobiera z wiadra swój żeton i przechodzi przez kolejkę bez zwłoki.
Dane docierają do kolejki z częstotliwością mniejszą niż częstotliwość napływania żetonów. Tylko ich część jest używana, więc te puste zbierane są do momentu osiągnięcia rozmiaru wiadra. W takim przypadku może zaistnieć sytuacja, w której dane zaczynają napływać bardzo szybko, w takim wypadku pakiety opróżniane są z kolejki wychodzącej tworząc krótką serię pakietów przekraczających normalny limit przepustowości.
Dane docierają do kolejki z częstotliwością większą niż częstotliwość napływania żetonów. W takim wypadku wiadro zostanie w końcu opróżnione z żetonów, powodując przez moment zwiększenie przepustowości, nazywa się to przekroczeniem limitu. Jeśli pakiety nadal będą napływały z niezmienną częstotliwością , niektóre będą odrzucane.
Ostatni scenariusz umożliwia kształtować przepustowość, dostępną dla danych, które przechodzą przez filtr. Należy również zwrócić uwagę, że w przedstawianej implementacji żetony odpowiadają bajtom a nie pakietom.
Kolejka SFQ – Stochastic Fairness QueueingSprawiedliwe Kolejkowanie Stochastyczne (ang. Stochastic Fairness Queueing - SFQ) to prosta implementacja rodziny algorytmów ze sprawiedliwym podziałem pasma. Jest mniej dokładna niż inne, ale wymaga również mniejszej ilości wyliczeń. Dodatkowo SFQ jest praktycznie samo konfigurowalna. Kluczowym słowem przy omawianiu SFQ jest konwersacja (ang. conversation) lub przepływ (ang. flow), które odpowiadają prawie sesjom TCP czy strumieniom UDP. Ruch dzielony jest na znaczną liczbę kolejek FIFO, jedną dla każdej konwersacji, a następnie rozsyłany algorytmem round-robin, dzięki czemu każda sesja ma zawsze szansę wysłania pakietu. Zapewnia to sprawiedliwy podział pasma i uniemożliwia jednej konwersacji zajęcie całego pasma. SFQ nazywana jest stochastyczną, ponieważ tak naprawdę nie alokuje kolejki dla każdej sesji, a używa procedury dzielącej ruch na ograniczoną liczbę kolejek przy pomocy algorytmu mieszającego (ang. hash). Ponieważ używana jest wartość mieszająca, więcej niż jedna sesja mogą skończyć w tym samym wiadrze. Oznaczałoby to w praktyce zmniejszenie szansy wysłania pakietu o połowę i podzielenie tym samym na pół dostępną efektywną prędkość. By temu zapobiec, SFQ zmienia często algorytm mieszający i nawet jeśli dojdzie do opisanej sytuacji będzie to działo się tylko przez parę sekund. SFQ jest użyteczne w przypadku gdy jeden z interfejsów wychodzących jest często zapełniony. W przeciwnym wypadku, nie zostanie stworzona kolejka i tak naprawdę nie będzie żadnego efektu. W dalszej części dokumentu bardzo często będziemy używać kolejki SFQ w połączeniu z innymi dyscyplinami kolejkowania.
Kolejka HTB – Hierarchical Token BucketKolejka HTB jest została stworzona jako bardziej zrozumiała i intuicyjna alternatywa dla opisywanej poniżej kolejki CBQ. Pozwala na kontrolę ruchu wychodzącego z serwera, symulacji kilku wolniejszych połączeń, jak również wysyłanie różnego rodzaju ruchu na różnych symulowanych połączeniach. HTB określa sposób odwzorowania fizycznego połączenia w symulowane połączenia i decyduje, które z nich powinno być użyte dla określonego połączenia.
Kolejka PRIOKolejka PRIO nie zajmuje się tak naprawdę kształtowaniem ruchu, dzieli jedynie ruch na podstawie tego, jak zostały skonfigurowane filtry. Można ją traktować jak rozszerzoną kolejkę pfifo_fast (zamiast pasma jest osobna klasa zamiast prostej kolejki FIFO). Kolejka PRIO jest bardzo użyteczna, gdy należy priorytetować określone rodzaje ruchu nie tylko na podstawie flag ToS, ale całej potęgi, którą zapewniają filtry tc. Może równie ż zawierać inne kolejki, podczas gdy pfifo_fast jest ograniczona do prostych kolejek FIFO. Kiedy pakiet zostaje skolejkowany w qdisc PRIO, na podstawie komend filtrujących wybierana jest klasa. Domyślnie, stworzone są trzy klasy zawierające czyste kolejki FIFO bez żadnej struktury wewnętrznej, ale można zastąpić je dowolnymi kolejkami qdisc. Zawsze gdy pakiet musi zostać wyjęty z kolejki, sprawdza się klasę :1. Wyższe klasy są sprawdzane tylko wtedy, gdy poprzednie nie zwróciły pakietu. Ponieważ kolejka ta nie zajmuje się kształtowaniem ruchu, należy używać jej tylko jeśli fizyczne łącze jest naprawdę obciążone, lub powiązać ją z kolejką qdisc z klasami, która nie zajmuje się kształtowaniem ruchu. Formalnie rzecz biorąc, kolejka PRIO jest planującą kolejką bezstratną .
Kolejka CBQ – Class Based QueueKolejka CBQ jest najbardziej skomplikowaną i często jest błędnie utożsamiana z całym zagadnieniem. Nie dzieje się tak dlatego, że jej autorzy byli złośliwi lub niekompetentni - przeciwnie, po prostu algorytm CBQ nie jest zbyt precyzyjny i niezbyt pasuje do sposobu w jaki działa Linux.
Poza tym że jest to kolejka z klasami, CBQ zajmuje się również kształtowaniem ruchu i tego właśnie nie robi zbyt dobrze. CBQ pobiera czas bezczynności z ilości mikrosekund pomiędzy wywołaniami sprzętowymi o więcej danych, skąd CBQ aproksymuje jak bardzo łącze jest zajęte.
W związku z tym, że parametry konfiguracji CBQ są bardzo zawiłe, i trudne to ogarnięcia, pominiemy szczegóły ustawień tej kolejki w tym dokumencie, a wspominamy o niej tylko ze względów historycznych. Obecnie istnieją prostsze i skuteczniejsze kolejki jak choćby wspomniana wcześniej HTB.
II.Kolejka ruchu przychodzącegoWszystkie omawiane do tej pory kolejki qdisc to kolejki dla ruchu wychodzącego. Każdy interfejs ma jednak również kolejki dla ruchu przychodzącego, które nie zajmują się wysyłaniem pakietów do karty sieciowej. Zamiast tego, kolejki te umożliwiają zastosowanie filtrów kontroli ruchu dla pakietów przychodzących do interfejsu, niezależnie czy adresowanych lokalnie czy przekazywanych dalej. Ponieważ filtry tc zawierają pełną implementację Filtra Wiadra Żetonów (TBF) i mogą dopasowywać pakiety na podstawie estymatora przepływu jądra, mają całą masę funkcjonalności. Umożliwia to stosować politykę do nadchodzącego ruchu nawet zanim dotrze do stosu IP.
III.Ustawienie routingu oraz rozwiązanie problemu na przykładzie kolejek HTB i IMQ.
Założenia : Komputer z dwiema kartami sieciowymi. Jedna podłączona do Internetu druga do sieci lokalnej. Pierwszą nazywamy eth0 drugą eth1. System: slackware 9.0 Kernel: 2.4.21 Zainstalowany TC i skompilowane jądro pod obsługę HTB i IMQ. Adresy ip dla kart sieciowych: eth0 -------------- 212.160.140.3 netmask 255.255.255.248 eth1 -------------- 192.168.0.1 netmask 255.255.255.0 getaway ---------- 212.160.140.1 nameserwer ----- 194.204.152.34
Instalacja interfejsów sieciowych :
~#ifconfig eth0 212.160.140.3 netmask 255.255.255.248
Powyższa linia przypisuje do interfejsu eth0 adres ip sieci zewnętrznej. Po tym poleceniu nasz komputer jest widoczny w sieci zewnętrznej pod adresem ip który mu przypisaliśmy.
~#ifconfig eth1 192.168.0.1 netmask 255.255.255.0
polecenie ustawia numer ip dla interfejsu eth1. Obie sieciówki zostały zdefiniowane.
2.Sprawdzenie ustawień dla kart sieciowych:
W jaki sposób są skonfigurowane interfejsy sieciowe można sprawdzić wydając polecenie
~#ifconfig
System pokaże ustawienia interfejsów :
eth0 Link encap:Ethernet HWaddr 00:09:2C:10:00:15 inet addr:212.160.140.193 Bcast:212.160.140.199 Mask:255.255.255.248 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:42612580 errors:0 dropped:0 overruns:0 frame:0 TX packets:30991870 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:345223983 (329.2 Mb) TX bytes:2165926142 (2065.5 Mb) Interrupt:11 Base address:0xc000
eth1 Link encap:Ethernet HWaddr 00:C0:26:31:AD:01 inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2735775 errors:3 dropped:0 overruns:0 frame:0 TX packets:3776849 errors:267 dropped:0 overruns:3 carrier:534 collisions:893944 txqueuelen:100 RX bytes:764160026 (728.7 Mb) TX bytes:4256463046 (4059.2 Mb) Interrupt:5 Base address:0xc400
ROUTING1.Routing dla 212.160.140.193
Aby komputer mógł korzystać z Internetu należy mu również ustawić routing dla swojego adresu.
~#route add -net 0.0.0.0 netmask 0.0.0.0 gw 212.160.140.191
tym poleceniem dodajemy do tablicy routingu routowanie dla naszego komputera. Proszę zwrócić uwagę na składnie polecenia pod koniec jest odwołanie do bramy domyślnej. Mówi to systemowi z którego routera ma korzystać.
Wyświetlić tablice routingu możemy wydając polecenie
~#route
system powinien wyświetlić informacje w postaci:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface localnet * 255.255.255.248 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo
default 212.160.140.193 0.0.0.0 UG 0 0 0 eth0 default 212.160.140.193 0.0.0.0 UG 1 0 0 eth0
2.Routing dla sieci wewnętrznej :
Korzystając z usługi iptables można dodać routing dla komputera w sieci wewnętrznej poleceniem:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 192.168.0.2 -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -s 192.168.0.3 -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -s 192.168.0.4 -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -s 192.168.0.5 -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -s 192.168.0.6 -o eth0 -j MASQUERADE iptables -t nat -A POSTROUTING -s 192.168.0.7 -o eth0 -j MASQUERADE
jak widać dodaliśmy routing dla komputerów z numerami ip 192.168.0.2-7
aby wyświetlić reguły ipetables które są używane w systemie wpisujemy polecenie
iptables –t nat –L
pokaże nam tabele dla routingu iptables:
Chain PREROUTING (policy ACCEPT) target prot opt source destination
Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 192.168.0.2 anywhere MASQUERADE all -- 192.168.0.3 anywhere MASQUERADE all -- 192.168.0.4 anywhere MASQUERADE all -- 192.168.0.5 anywhere MASQUERADE all -- 192.168.0.6 anywhere MASQUERADE all -- 192.168.0.7 anywhere
aby komputery w sieci mogły korzystać z Internetu wystarczy ustawić im bramę domyślną 192.168.0.1 czyli interfejs eth1 naszego routera.
Ograniczenie prędkości dla interfejsów na dane ip wewnętrzne
1.Kolejka HTB
Angielskie „traffic control” przetłumaczyć można jako kontrolowanie ruchu. W tym przypadku ruch tworzą pakiety przesyłane po sieci natomiast kontrolowanie dotyczy ograniczenia szybkości.
W praktyce chodzi o to aby: - ograniczyć korzystanie z programów typu Kazaa - zapewnić sprawiedliwy dostęp do Internetu. - nie dopuścić do sytuacji w której jeden z użytkowników blokuje innym dostęp do czegokolwiek przez jednoczesne ściąganie trzech filmów i dziesięciu mp3. - Zapewnianie gwarantowanej szybkości połączenia z Siecią serwera(ów)
a1) Polecenia i opis kolejki HTB.
Przykład pierwszy:
tc qdisc del root dev eth1 tc qdisc add dev eth1 root handle 1:0 htb tc class add dev eth1 parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit tc class add dev eth1 parent 1:1 classid 1:2 htb rate 256kbit ceil 512kbit tc class add dev eth1 parent 1:1 classid 1:3 htb rate 256kbit ceil 512kbit tc filter add dev eth1 protocol ip parent 1:0 u32 match ip dst 192.168.0.2 flowid 1:2 tc filter add dev eth1 protocol ip parent 1:0 u32 match ip dst 192.168.0.3 flowid 1:3
ten zbiór poleceń ustawia dla dwóch komputerów w sieci równy podział łącza.
tc qdisc del root dev eth1 - kasuje główną kolejkę dla interfejsu eth1
tc qdisc add dev eth1 root handle 1:0 htb - zakłada główna kolejkę dla interfejsu eth1
tc class add dev eth1 parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit – zakłada klasę która odwołuje się do kolejki głównej z ograniczeniem interfejsu do 512 kbit z 512 kibit
tc class add dev eth1 parent 1:1 classid 1:2 htb rate 256kbit ceil 512kbit - zakłada podklasę do klasy 1:1 i ustawia prędkość 256 kbitów minimum z 512kbit maksymalnie.
tc filter add dev eth1 protocol ip parent 1:0 u32 match ip dst 192.168.0.2 flowid 1:2 – ustawia filtr dla adresu ip 192.168.0.2 który odwołuje się do klasy 1:2.
Działa to w ten spsób że rozdziela dynamicznie prędkość dwóm użytkownikom. np. Obaj użytkownicy są wpięci do sieci i ciągną pliki z Internetu z pełną prędkością każdy z nich nie może przekroczyć 256 kbitów natomiast gdy jeden z nich potrzebuje mniej niż 256 kbitów drugi dostaje to czego tamten nie używa do sumy 512 kbitów.
Działa to tylko w jedną stronę czyli tylko pakiety wychodzące z interfejsu eth0 są kontrolowane przychodzące są cały czas nie ograniczone. Aby ograniczyć pakiety przychodzące należy użyć usługi imq.
Parametry kolejki
Kolejka HTB może przyjmować następujące parametry:
default- domyślna klasa przyjmująca ruch niesklasyfikowany, parametr ten przypisuje się tylko do qdisc , a nie do klas.
rate – parametr określający szybkość pasma
ceil – parametr określający maksymalny rozmiar pasma ,osiągany poprzez wypożyczenie go od innych kolejek posiadających tego samego rodzica.
burst i cburst – parametry określające maksymalną ilość danych , które mogą być wysłane z maksymalna prędkością bez dzielenia pasma z innymi klasami.
pio – określa priorytet kolejki.
u32 – podejmuje decyzje na podstawie pól w pakiecie (np. źródłowego adresu ip)
Przykład drugi:
tc qdisc add dev eth1 root handle 1:0 htb tc class add dev eth1 parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit tc class add dev eth1 parent 1:1 classid 1:2 htb rate 256kbit ceil 512kbit tc class add dev eth1 parent 1:1 classid 1:3 htb rate 128kbit ceil 256kbit tc class add dev eth1 parent 1:1 classid 1:4 htb rate 64kbit ceil 256kbit tc class add dev eth1 parent 1:1 classid 1:5 htb rate 64kbit ceil 128kbit
tc filter add dev eth1 protocol ip parent 1:0 u32 match ip dst 192.168.0.2 flowid 1:2 tc filter add dev eth1 protocol ip parent 1:0 u32 match ip dst 192.168.0.3 flowid 1:3 tc filter add dev eth1 protocol ip parent 1:0 u32 match ip dst 192.168.0.4 flowid 1:4 tc filter add dev eth1 protocol ip parent 1:0 u32 match ip dst 192.168.0.5 flowid 1:5
W tym przykładzie pokazane jest ustalanie różnych prędkości dla różnych użytkowników. Ma to na celu przydzielanie każdemu ip danej prędkości minimalnej i maksymalnej w przypadku kiedy chcemy zróżnicować prędkość poszczególnym adresom ip.
Np.
Użytkownik z adresem 192.168.0.5 ma zagwarantowane w przypadku maksymalnego wykorzystania łącza przez innych użytkowników łącza prędkość 64 kbit a w przypadku kiedy łącze będzie miało zapas wolny maksymalna prędkość 128 kbitów mimo że było by więcej do przydzielenia.
Aby wyświetlić kolejki danego interfejsu należy wydać polecenie :
tc qdisc show
na ekranie powien ukazać się raport o kolejkach:
qdisc htb 1: dev eth1 r2q 10 default 0 direct_packets_stat 1677
2.Kolejka IMQ – ruch przychodzący
a2)Opis i przygotowanie kolejki IMQ
IMQ – działa podobnie jak kolejka HTB natomiast ma możliwość ograniczania ruchu przychodzącego. Aby można było używać tej kolejki należy wkompilować w kernel patch z imq oraz włączyć obsługę tej kolejki w kernelu.
Aby podpiąć kolejkę imq pod interfejs eth1 wydajemy polecenie :
iptables -t mangle -A PREROUTING -i eth1 -j IMQ ip link set imq0 up
pierwsza linia polecenia podpina IMQ pod eth1 na ruch wycvhodzący natomiast druga linkuje kolejkę pod imq0.
Aby sprawdzić czy kolejka jest poprawnie podpięta pod interfejs eth1 należy wydać polecnie
ifconfig
powinien ukazać się raport wyglądający tak :
imq0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP RUNNING NOARP MTU:1500 Metric:1 RX packets:6145 errors:0 dropped:0 overruns:0 frame:0 TX packets:6133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:30 RX bytes:3732110 (3.5 Mb) TX bytes:3722664 (3.5 Mb)
Przykład 1
tc qdisc del root dev imq0 tc qdisc add dev imq0 root handle 1:0 htb default 2 tc class add dev imq0 parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit tc class add dev imq0 parent 1:1 classid 1:2 htb rate 256kbit ceil 512kbit tc class add dev imq0 parent 1:1 classid 1:3 htb rate 256kbit ceil 512kbit tc filter add dev imq0 protocol ip parent 1:0 u32 match ip dst 192.168.0.2 flowid 1:2 tc filter add dev imq0 protocol ip parent 1:0 u32 match ip dst 192.168.0.3 flowid 1:3
ten zbiór poleceń ustawia dla dwóch komputerów w sieci równy podział łącza dla ruchu przychodzącego na interfejs eth1.
Jak widać powyżej kolejkę imq ustawia się identycznie jak HTB tylko w miejsce interfejsu wpisuje się link imq0. Działa ona identycznie jak kolejka HTB tylko nie na ruch wychodzący z interfejsu eth0 a na ruch przychodzący.
Przykład 2
tc qdisc del root dev imq0 tc qdisc add dev imq0 root handle 1:0 htb default 2 tc class add dev imq0 parent 1:0 classid 1:1 htb rate 512kbit ceil 512kbit tc class add dev imq0 parent 1:1 classid 1:2 htb rate 128kbit ceil 512kbit tc class add dev imq0 parent 1:1 classid 1:3 htb rate 128kbit ceil 256kbit tc class add dev imq0 parent 1:1 classid 1:3 htb rate 128kbit ceil 128kbit tc filter add dev imq0 protocol ip parent 1:0 u32 match ip dst 192.168.0.2 flowid 1:2 tc filter add dev imq0 protocol ip parent 1:0 u32 match ip dst 192.168.0.3 flowid 1:3 tc filter add dev imq0 protocol ip parent 1:0 u32 match ip dst 192.168.0.4 flowid 1:4
W tym przykładzie pokazane jest ustalanie różnych prędkości dla różnych użytkowników. Ma to na celu przydzielanie każdemu ip danej prędkości minimalnej i maksymalnej w przypadku kiedy chcemy zróżnicować prędkość poszczególnym adresom ip.
Np. Użytkownik z adresem 192.168.0.4 ma zagwarantowane w przypadku maksymalnego wykorzystania łącza przez innych użytkowników łącza prędkość 128 kbit a w przypadku kiedy łącze będzie miało zapas wolny maksymalna prędkość 256 kbitów mimo że było by więcej do przydzielenia. |
| następny artykuł » |
|---|