Po co centralne zarządzanie routerami MikroTik?
Jednym routerem łatwo zarządzać przez WinBox. Kiedy urządzeń jest kilkanaście, codzienne zadania zaczynają się powtarzać: sprawdzenie wersji RouterOS, stanu portów, obciążenia CPU, dostępności czy zmian w topologii. Każde kolejne logowanie pochłania czas, a niespójna konfiguracja utrudnia diagnostykę.
CMR (Centralized Management for RouterOS) ma uporządkować właśnie tę część pracy. Jeden z routerów uruchamia serwer CMR, pozostałe łączą się z nim jako klienci. Kontroler pokazuje stan urządzeń, pomaga zarządzać aktualizacjami, generuje alerty, wykonuje polecenia i udostępnia narzędzia do konfiguracji Wi-Fi oraz VLAN-ów.
W laboratorium MWTC sprawdziliśmy te możliwości na dwóch routerach: hAP ax S i hAP ax². Dodatkowy switch MikroTik włączyliśmy do CMR na potrzeby testu automatycznego wykrywania topologii.
Czym jest CMR, a czym nie jest?
CMR nie zastępuje wszystkich narzędzi dostępnych w WinBox. Nie konfiguruje adresacji IP, serwerów DHCP, routingu, reguł firewalla ani kont użytkowników. Te ustawienia nadal zmieniamy bezpośrednio na urządzeniu lub za pomocą skryptów, z uwzględnieniem uprawnień dostępnych w CMR.
Uruchomienie serwera wymaga dodatkowego pakietu cmr, dostępnego dla architektur ARM, ARM64 i x86. Klient jest częścią głównego pakietu RouterOS, z wyjątkiem urządzeń z architekturą SMIPS i PowerPC. Do obsługi CMR służą WinBox 4 lub WebFig. Klient nawiązuje połączenie z kontrolerem przez TCP 54321, a parowanie wymaga zgody obu stron. Urządzenia nie muszą znajdować się w jednej podsieci, ale muszą mieć zapewnioną łączność IP.
Z poziomu kontrolera otrzymujemy między innymi:
- Inwentaryzacja routerów, wersji RouterOS, pakietów i etykiet.
- Dashboard z informacjami o zasobach, ruchu, dostępności i klientach Wi-Fi.
- Reguły alertów i aktualizacji oraz narzędzia do zdalnego wykonywania poleceń i restartowania urządzeń.
- Graficzna topologia oraz widok portów i podstawowych parametrów PoE.
- Centralne wdrażanie wybranych ustawień Wi-Fi i VLAN, z ograniczeniami opisanymi dalej.
Stanowisko laboratoryjne i wersje oprogramowania
Testy wykonaliśmy 3–4 listopada 2026 roku na RouterOS 7.26beta5 z kanału development. Serwer CMR działał na hAP ax S, a hAP ax² pełnił rolę klienta. Do pracy z graficzną mapą topologii użyliśmy WinBox 4.5.
To test wersji rozwojowej. Opisane wyniki dotyczą RouterOS 7.26beta5, nie wydania stabilnego. Nie traktujemy ich jako rekomendacji do instalowania wersji beta w sieci produkcyjnej. Przed zmianami konfiguracji warto przygotować kopię zapasową, eksport ustawień i niezależny sposób dostępu do urządzeń.
| Element | Kontroler | Klient |
|---|---|---|
| Model | MikroTik hAP ax S | MikroTik hAP ax² |
| Rola | Serwer CMR (MWTC-CMR) | Router zarządzany (MWTC-AX2) |
| Architektura | ARM | ARM64 |
| Pamięć RAM | 512 MiB | 1024 MiB |
| RouterOS w teście | 7.26beta5 | 7.26beta5 |
| Dostęp do sieci | Łącze Ethernet / DHCP | Łącze Ethernet / DHCP |
W późniejszym teście topologii dodaliśmy switch z rodziny CRS109, także z RouterOS 7.26beta5. Nie był on głównym obiektem doświadczenia. Wspólna sieć Ethernet zapewniała komunikację IP między wszystkimi urządzeniami.
Instalacja i uruchomienie kontrolera na hAP ax S
Na hAP ax S zaktualizowaliśmy RouterOS do 7.26beta5, a następnie w System → Packages włączyliśmy dodatkowy pakiet cmr i zatwierdziliśmy zmiany. Router wymagał restartu. Po ponownym uruchomieniu w menu WinBox pojawiła się sekcja Controller z Dashboard, Devices, Alerts, Topology i innymi narzędziami.
Pierwsze otwarcie Dashboardu pokazało komunikat „ERROR: cmr not running”. To ważna różnica: instalacja pakietu nie uruchamia automatycznie serwera. W Controller → Settings zaznaczyliśmy Enabled i zastosowaliśmy zmiany.
Tę samą operację można wykonać przez CLI na hAP ax S:
/cmr set enabled=yes
/cmr print
/cmr/device/print
Po uruchomieniu kontrolera pojawił się on na liście Devices jako urządzenie lokalne z flagą L. W ustawieniach pozostawiliśmy Pairing Requirement = confirm, dzięki czemu każde nowe urządzenie wymaga świadomego zatwierdzenia.
Dodanie hAP ax² i bezpieczne parowanie
Połączenie IP i konfiguracja klienta
Oba routery zostały podłączone do wspólnego switcha. Każdy otrzymał adres z DHCP w tej samej podsieci. CMR nie wymaga bezpośredniego kabla między urządzeniami: wystarczy osiągalny adres kontrolera oraz możliwość nawiązania połączenia TCP 54321. W teście połączenie zadziałało bez dodatkowej zmiany zasad firewalla.
Na hAP ax², również z RouterOS 7.26beta5, w System → CMR Client włączyliśmy Enabled. Kontroler wskazaliśmy adresem IP. Alternatywnie można to zrobić przez terminal, zastępując adres przykładowy rzeczywistym adresem swojego serwera:
/cmr/client set enabled=yes controller-addresses=192.0.2.10
/cmr/client print
Adres 192.0.2.10 należy do zakresu przeznaczonego do przykładów w dokumentacji. W poleceniu trzeba zastąpić go adresem własnego kontrolera. Na zrzutach ekranu widoczne są adresy używane w naszym laboratorium.
Dwa etapy autoryzacji
Klient zgłosił stan „waiting-for-pairing,connected”. Po stronie kontrolera był już widoczny jako oczekujący. Na serwerze ustawiliśmy confirm, a klient wymagał hasła RouterOS. W Controller → Devices otworzyliśmy Pair Tool, podaliśmy dane użytkownika hAP ax² i uruchomiliśmy parowanie.
Narzędzie zwróciło status paired. Na liście Devices flaga P zniknęła, a hAP ax² otrzymał flagę C (connected). Kontroler zachował flagę L (local). Parowanie nie oznacza jeszcze automatycznego zarządzania każdym parametrem routera: zakres zmian zależy od osobnych reguł CMR.
Monitoring zasobów i interfejsów
Po sparowaniu Dashboard wyświetlił 2/2 Devices Online i 2/2 Devices Paired. Z jednego ekranu mogliśmy odczytać wykorzystanie CPU, pamięci RAM oraz pamięci urządzenia. W przykładowym odczycie hAP ax S zajmował około 18% RAM i 53% pamięci urządzenia, a hAP ax² około 33% RAM i 28% pamięci urządzenia. Były to chwilowe odczyty monitoringu, a nie pomiar wydajności kontrolera.
Po dodaniu pomocniczego switcha zakładka Controller → Ports pokazała zestawienie portów wszystkich trzech urządzeń. Dla aktywnych połączeń raportowała prędkość 1 Gb/s, bieżące liczniki Tx/Rx, PVID oraz stan PoE, jeśli dany port udostępnia takie informacje. To przydatny skrót diagnostyczny: do wstępnego sprawdzenia łącza nie trzeba otwierać osobnych sesji każdego urządzenia.
Alert po utracie i przywróceniu łączności
Aby sprawdzić reakcję CMR na problem z dostępnością, utworzyliśmy regułę lab-ax2-offline, ograniczoną etykietą do hAP ax². Warunek „Disconnected more than” ustawiliśmy na 00:00:30, kategorię availability, ważność high, a akcję logowania na tematy cmr i warning.
- Przy działającym połączeniu oba routery były online, a reguła nie była aktywna (Devices 0/1).
- Odłączyliśmy przewód Ethernet wyłącznie od hAP ax². Kontroler pozostał dostępny.
- Dashboard pokazał 1/2 Devices Online, ale nadal 2/2 Devices Paired.
- Pojawił się alert lab-ax2-offline (high). Licznik Fired wzrósł do 1, Action Failures pozostał 0.
- Po ponownym podłączeniu przewodu dostępność wróciła do 2/2, a alert zniknął z listy aktywnych. Licznik Fired zachował wartość 1.
Według naszych obserwacji alert pojawił się po około 30 sekundach. Nie mierzyliśmy tego czasu stoperem, dlatego jest to wartość orientacyjna. Licznik Action Failures = 0 informował o braku zgłoszonych błędów akcji, ale nie sprawdzaliśmy osobno treści wpisu w logu RouterOS.
Script Tool: zdalne polecenia z poziomu kontrolera
Następnie wykorzystaliśmy Script Tool na hAP ax S. Wybraliśmy etykietę MWTC-AX2 i polecenie diagnostyczne /system/resource/print. Wynik pojawił się w tym samym oknie, a status zadania przyjął wartość success.
/system/resource/print
W odpowiedzi otrzymaliśmy parametry hAP ax², w tym RouterOS 7.26beta5, architekturę ARM64, cztery rdzenie procesora i 1024 MiB RAM. Funkcja rzeczywiście umożliwiła odczyt danych z klienta z poziomu kontrolera.
Przy automatyzacji trzeba uwzględnić ograniczenia uprawnień. Polecenie run-script działa z uprawnieniami read, write, test i reboot, ale bez policy, sniff i sensitive. Nie daje więc takiego samego dostępu jak konto administratora z pełnymi uprawnieniami, na przykład do zarządzania użytkownikami RouterOS.
Mapa topologii: dlaczego potrzebny był trzeci MikroTik?
W WinBox 4.5 utworzyliśmy układ Laboratorium-MWTC i dodaliśmy do niego oba routery. Widok graficzny był dostępny w WinBox 4.5; we wcześniejszej wersji WinBox mapa nie była wyświetlana. MikroTik dodał oficjalnie obsługę topologii w WinBox 4.5, wydanym 3 listopada 2026 roku.
Początkowo operacja Rebuild Links nie narysowała linii między hAP ax S a hAP ax². Oba routery łączyły się przez zewnętrzny switch, który nie był wtedy klientem CMR. Zgodnie z opisem funkcji automatyczne połączenia są tworzone na podstawie danych o sąsiadach i portach zarządzanych urządzeń.
Do testu dołączyliśmy więc switch z rodziny CRS109, zaktualizowany do RouterOS 7.26beta5 i sparowany z kontrolerem. Po jego uwzględnieniu w układzie i wykonaniu Rebuild Links mapa pokazała trzy węzły oraz dwa połączenia.
| Połączenie wykryte przez CMR | Port routera | Port switcha |
|---|---|---|
| hAP ax S ↔ switch | ether1 | ether4 |
| hAP ax² ↔ switch | ether1 | ether7 |
Połączenia widoczne na mapie sprawdziliśmy również w terminalu. Polecenie /cmr/layout/link/print detail pokazało te same pary portów, a także liczniki ruchu i informacje o PoE. Potwierdziliśmy więc nie tylko wyświetlenie linii na mapie, lecz także poprawne rozpoznanie portów po obu stronach połączenia.
/cmr/layout/link/print detail where layout="Laboratorium-MWTC"
Polityki aktualizacji RouterOS w jednym miejscu
CMR oferuje reguły aktualizacji przypisywane do urządzeń według etykiet. Domyślna reguła default wskazywała kanał stable. Ponieważ laboratorium pracowało na wydaniu rozwojowym, przygotowaliśmy osobną regułę lab-development z kanałem development, strategią sequential i Fail Policy = stop.
Nie wykonywaliśmy aktualizacji przez CMR. Ekran Show Upgrade Devices potwierdził, że reguła obejmuje trzy urządzenia. Nie ustawialiśmy Auto Install Time ani nie uruchamialiśmy polecenia Start. Sprawdziliśmy konfigurację reguły i wybór urządzeń, nie przebieg instalacji nowej wersji RouterOS.
Przy większej infrastrukturze można porządkować reguły według grup, ustalać ich kolejność i harmonogramy. Kolejność aktualizacji musi jednak zaplanować administrator. Nie należy zakładać, że CMR sam wyznaczy ją na podstawie topologii sieci.
Centralna konfiguracja Wi-Fi i ograniczenia wersji beta
CMR ma również zakładki WiFi → Interfaces, Radios, Clients, Network Configuration oraz Radio Configuration. Najpierw potwierdziliśmy inwentaryzację interfejsów hAP ax S i hAP ax². Następnie przeszliśmy do rzeczywistej konfiguracji nowego SSID na kliencie.
Nowe SSID i wybór radia 5 GHz
Na kontrolerze utworzyliśmy sieć MWTC-CMR-LAB dla etykiet MWTC-AX2,+5ghz, w trybie ap i z metodami WPA2-PSK oraz WPA3-PSK. W Radio Configuration ustawiliśmy kraj Poland. Selektor z plusem jest opisany w dokumentacji MikroTik jako dodatkowy warunek dopasowania; +5ghz powinien ograniczać regułę do radia tego pasma.
Wynik testu był jednak inny niż oczekiwaliśmy. Na hAP ax² obie konfiguracje zarządzane przez CMR otrzymały przypisania do dwóch adresów radiowych. Po ustawieniu band=5ghz-ax także radio 2,4 GHz próbowało pracować w paśmie 5 GHz i wyświetliło błąd „no available channels”. Samo radio 2,4 GHz obsługuje wyłącznie własny zakres częstotliwości, co potwierdziliśmy przez /interface/wifi/radio/print detail.
W laboratorium usunęliśmy z reguły Radio Configuration jawne wymuszenie 5ghz-ax. Po tej zmianie obydwa interfejsy otrzymały dostępne kanały: wifi1 w paśmie 5 GHz (5805 MHz) oraz wifi2 w paśmie 2,4 GHz (2427 MHz). Oba pokazywały SSID MWTC-CMR-LAB. Rozwiązaliśmy więc bezpośredni problem doboru kanału, ale nie przywróciliśmy pierwotnego ograniczenia do wyłącznie 5 GHz.
Czego nie sprawdzaliśmy?
To nie był pełny test działania sieci Wi-Fi. Nie podłączaliśmy telefonu, nie sprawdzaliśmy ruchu IP, DHCP ani dostępu do internetu. Potwierdziliśmy przesłanie konfiguracji SSID i wybór kanałów po korekcie ustawień.
Nie skonfigurowaliśmy również VLAN ID. Zgodnie z dokumentacją CMR dostępną w czasie testu bez tego ustawienia zarządzany interfejs Wi-Fi nie jest dodawany do bridge, przez co klienci nie uzyskują dostępu do sieci. Samo wyświetlenie SSID nie potwierdza więc, że konfiguracja jest gotowa do obsługi użytkowników.
Nie ustaliliśmy, dlaczego warunek +5ghz objął oba radia mimo zapisu zgodnego z dokumentacją. To obserwacja z naszego zestawu z RouterOS 7.26beta5, nie potwierdzenie błędu występującego na wszystkich urządzeniach. Trzeba też pamiętać, że CMR może zastąpić dotychczasową konfigurację radia, a usunięcie reguły nie musi jej automatycznie przywrócić.
VLAN Rules: przegląd dostępnych ustawień
W Controller → VLAN Rules przejrzeliśmy formularz, ale nie zapisaliśmy ani nie zastosowaliśmy żadnej reguły VLAN. Funkcja pozwala wybierać urządzenia, konkretne porty, zakresy VLAN oraz role access i trunk. Dla portu access pierwszy identyfikator z podanego zakresu staje się PVID. Port trunk przenosi wybrane VLAN-y z tagami 802.1Q.
Reguła VLAN może odciąć dostęp do urządzenia. CMR tworzy cmr-bridge i przenosi do niego porty objęte regułą. Zbyt szeroki wybór, na przykład Labels=all i Port Labels=all, może objąć także port używany do zarządzania. Przed zastosowaniem reguł do aktywnych uplinków trzeba sprawdzić konfigurację i zapewnić niezależny dostęp administracyjny.
Wnioski: dla kogo CMR będzie przydatny?
W naszym laboratorium CMR poprawnie sparował urządzenia, prezentował monitorowane zasoby, wyzwolił i wygasił alert po odłączeniu klienta, wykonał zdalną komendę diagnostyczną oraz zbudował mapę fizycznych połączeń po dołączeniu zarządzanego switcha. Sprawdziliśmy także konfigurację polityki aktualizacji, centralną inwentaryzację portów i Wi-Fi oraz rzeczywiste przesłanie SSID na hAP ax².
Największą wartość CMR widać przy powtarzalnej obsłudze większej liczby routerów: zbiorczym sprawdzaniu stanu, alertach, uruchamianiu poleceń i kontroli wersji. Wersja 7.26beta5 nadal wymaga ostrożności. W szczególności konfiguracja Wi-Fi i VLAN potrafi przejąć interfejsy zarządzane wcześniej lokalnie, dlatego przed zastosowaniem jej w środowisku operacyjnym trzeba zaplanować sposób powrotu do działającej konfiguracji.
Test nie zastępuje sprawdzenia stabilności przy większej liczbie urządzeń ani prób z klientami Wi-Fi. Pokazuje jednak, co CMR potrafi już na niewielkim stanowisku: zbiorczy podgląd sieci, alerty, zdalne polecenia i mapę połączeń. Do uruchomienia kontrolera wystarczył router MikroTik, bez osobnego serwera Linux czy maszyny wirtualnej.
Źródła i wersje
- MikroTik CMR: oficjalna dokumentacja.
- Konfiguracja i parowanie klienta CMR.
- CMR Wi-Fi: parametry konfiguracji sieci.
- CMR Radio: ustawienia interfejsów radiowych.
- CMR VLAN: opis reguł i parametrów.
- WinBox i lista zmian wersji 4.5.
- Historia wydań RouterOS.
Dokumentację producenta zweryfikowano 5 listopada 2026 r. Opis doświadczenia dotyczy RouterOS 7.26beta5 i WinBox 4.5.