MikroTik Queue
Więcej miejsc do posłuchania:
Link do artykułu.
0:00 Wprowadzenie
0:19 Przygotowanie środowiska testowego
2:23 Instalacja Speedtest CLI
5:58 Konfiguracja MikroTika
9:57 Podsumowanie
Transkrypcja
Chcesz dowiedzieć się jak ograniczyć prędkość na interfejsach na routerze MikroTik? Jeśli tak, to dobrze trafiłeś. W tym odcinku pokażę jak to zrobić. Zapraszam.
Zanim przeprowadzę konfigurację dotyczącą obniżenia prędkości na interfejsie, najpierw przygotuję testowe środowisko. W tym celu dodam nowy obiekt z szablonu Linux. Naciskamy Save i należy podłączyć do routera MikroTik i nacisnąć Save. Następnie uruchomić router MikroTik. Podłączyć się do niego programem WinBox. Będziemy analizowali środowisko programem Speedtest CLI. Musimy sprawdzić jaka jest aktualna prędkość Internetu i jaka będzie po wprowadzeniu konfiguracji. Na stronie speedtest.net w menu Apps mamy pozycję CLI. Jest to dokładnie ta strona, którą tutaj widać. Niżej mamy opcje konfiguracyjne. Będzie nam potrzebny curl, skrypt instalacyjny w bash-u i ostateczna instalacja programu speedtest. Ten skrypt dodaje repozytorium Speedtest-u w celu zainstalowania klienta Speedtest CLI. Pokażę jak wygląda właśnie działanie tego klienta na komputerze gospodarzu. Ręcznie wprowadzam sprawdzony serwer testowy. Także średnia prędkość pobierania między 150-160 Mbps. Upload prawie 10 Mbps. Teraz zainstaluję Speedtest CLI bezpośrednio na EVE-NG. Dla wygody można skopiować każde z poleceń. Po zalogowaniu się do klienta SSH wklejamy po kolei te polecenia i zatwierdzamy enterem. Jak widać curl jest zainstalowany. Teraz poleceniem curl z przekierowaniem do bash-a pobieramy ten skrypt i go wykonujemy. Repozytorium jest gotowe. Teraz pora zainstalować Speedtest CLI. Speedtest został zainstalowany. Tą samą komendą można sprecyzować serwer testowy aby mieć pewność, że będzie taki sam lub zbliżony odczyt. Dwukrotnie akceptujemy warunki i odbywa się test. Na wirtualnej maszynie mamy około 150 Mbps pobierania i ok 10 Mbps wysyłania. Otrzymujemy też link, który możemy otworzyć w przeglądarce.
Teraz uruchamiam dodany system Linux. I otwieram konsolę Linuxa. Zalogujemy się na root-a z hasłem Test123. Tutaj dopasuję interfejs, żeby był bardziej czytelny. Teraz pobieram archiwum ze skryptem Speedtest CLI. Niestety repozytorium, które było stosowane w EVE-NG nie jest zgodne z najnowszą wersją Ubuntu. Archiwum musi zostać pobrane poleceniem wget. Teraz stworzyłem katalog roboczy do działania skryptu. Najpierw poleceniem mv zmienię nazwę na poprawną. Teraz przeniosę archiwum do katalogu roboczego. Poleceniem cd przechodzę do katalogu roboczego i poleceniem tar zxvf nazwa pliku wypakowuję do niego archiwum. Poleceniem ll sprawdzam, czy speedtest posiada atrybut wykonywalny. Jako właściciel pliku można wykonać ten skrypt jako z uprawnieniami do wykonania. Podobnie grupa i pozostali. A więc teraz można przetestować jaka jest faktyczna prędkość maszyny Linux. W tym celu wystarczy wykonać polecenie ./speedtest -s i numer serwera z którym ma się połączyć w celu wykonania testu prędkości internetu. Dwukrotnie akceptujemy warunki i test jest wykonywany. Jak widać tutaj prędkość pobierania to “aż” 1mb/s i tutaj aż w cudzysłowiu i warto zauważyć że został na końcu wyświetlony błąd. Dodatkowo też nie może wykonać testu wysyłania. Jest to związane z tym, że wersja Cloud Hosted Router jest ograniczona w wersji darmowej do prędkości 1 Mbps na interfejs. Dlatego właśnie pokazałem jak najpierw wygląda aktualny test na gospodarzu i EVE-NG. Jak to się przedstawia z poziomu maszyny wirtualnej, która jest uruchomiona w EVE-NG i podłączona do MikroTika. Bo tu tak faktycznie w tym przypadku to MikroTik obniżył tą prędkość. Nie jest to wada EVE-NG. Aby to zweryfikować jeszcze raz wykonamy test z tym samym serwerem. Też widać. Najpierw jakoś dobił do 2 Mbps i granicznie spada do 1 Mbps.
Teraz możemy przejść do konfiguracji MikroTika. Z tego względu, że licencja ma ograniczenie a w zasadzie brak licencji ma ograniczenie z prędkością do 1mb/s to prędkość na interfejsie w konfiguracji zostanie obniżona znacznie poniżej tego 1 Mbps. W tym celu przechodzimy do Queues. Tutaj zobaczmy jak wyglądają ustawienia kolejek. Mamy tutaj zbridżowany interfejs LAN. On nie ma naniesionych żadnych kolejek, ale warto zwrócić uwagę, że interfejsy 2,3,4 które wchodzi w bridge LAN. One mają zastosowaną sprzętową kolejkę. Czyli właśnie tutaj chodzi o te ograniczenie prędkości na interfejsie do 1 Mbps. Tutaj mamy listę z typami kolejek, dodamy prostą kolejkę, zmienimy na nazwę na queue_LAN aby było to w przyszłości dla nas wskazówką, że ona dotyczy tego bridga. Na liście rozwijanej target wybieramy LAN. Jak było widać można było wskazać konkretny zakres adresów, ale też nic nie stoi na przeszkodzie aby wybrać interfejs lub interfejsy. Tutaj mamy konfigurację właśnie docelowych interfejsów, jakie one mają mieć ograniczenia. Max Limit – wpisujemy tutaj maksymalny limit prędkości interfejsu jaki ma być osiągalny. Czyli np jeśli wybierzemy 64k to prędkość interfejsu będzie maksymalnie miała 64k na wyjściu. To jest upload. I analogicznie 128, 256 maksymalnie możemy wybrać 10M. Ale i tak w tym przypadku jeżeli przekroczymy 1M, czyli np wybierzemy 2,3,4,5 lub 10 to i tak fizycznie będziemy mieli maksymalnie 1 Mbps. Aby na demo pokazać jak działa faktycznie ograniczenie prędkości wybiorę np 256 kbps upload, 512 kbps pobierania. Tutaj mamy też listę z kategorią Time. Możemy sprecyzować zakres czasu w jakim ma obowiązywać ta prosta kolejka. Ale teraz nie będziemy ustawiali czasu. W zakładce Advanced możemy określić limit od – jest to minimalna prędkość jaką ma przepuszczać interfejs. Chodzi o to aby klient nie otrzymał zbyt niskiej prędkości przy dużym obciążeniu. Możemy tutaj zadeklarować, że obiecujemy mu, że będzie miał 64 kbps na wysyłaniu a minimalna prędkość pobierania to 256 kbps. Warto przypomnieć, że ustawiliśmy, że maksymalny próg to 256 kbps wysyłania i 512 kbps pobierania. Naciskamy OK. Kolejka jest dodana. Widać tutaj maksymalny upload 256 kbps i maksymalny download 512 kbps. To jest dla bridge.
Teraz przetestujemy tą konfigurację. Przechodzimy z powrotem do Ubuntu Server i wykonujemy polecenie speed testu. Jak widać nie dochodzi nawet do 1 Mbps ale też zauważalnie jest jeden plus. Że teraz nawet w pełni test został wykonany. Ponownie wykonujemy dla potwierdzenia. Wszystko z powrotem przechodzi. Jak widać ograniczenie prędkości spowodowało, że przy obciążonym pobieraniu upload nie został wycięty. Aby potwierdzić, że to dotyczyło właśnie tej kolejki, wyłączę tutaj kolejkę i jeszcze raz zostanie wykonany test. Widać ograniczenie do ok 1 Mbps pobierania i z powrotem zadyszka na wysyłaniu. Włączamy z powrotem kolejkę i limity z tymi prędkościami z powrotem obowiązują.
Jak widzisz proste kolejki są łatwym sposobem na dokonanie tego typu ograniczenia. Przydaje się to w szczególności jeśli właśnie masz podobnie jak w pokazanym demo problem z ucinaniem ruchu podczas wysyłania plików. Do następnego razu.
