Instrukcja ograniczenia prędkości na wybranym porcie w switchach MikroTik CRS 3xx

 Wymagania: RouterOS w wersji 6.46.x

 

 

Instrukcja ograniczenia prędkości dla VLAN w switchach MikroTik CRS 3xx

 

Wymagania: RouterOS w wersji 6.47.x ze względu na możliwość wykonania poprzez WinBox

 

UWAGA: Ograniczenie po VLAN możemy wykonywać wyłącznie dla ruchu wchodzącego danym portem z VLAN. Żeby zapewnić dwukierunkową kontrole przepustowości musimy ustawić ograniczenia dla VLAN na obu portach.

 

 

Problem z wykrywaniem ilości akumulatorów w Ubiquiti EdgePower EP-54V-150W

Mini siłownia Ubiquiti EdgePower EP-54V-150W poprzez moduł bateryjny EP-54V-150W-DC umożliwia podłączenie 2, 3 lub 4 akumulatorów szeregowo.

O ile podłączenie 2 akumulatorów szeregowo zawsze działa poprawnie to podłączenie większej ilości akumulatorów nie zawsze jest wykrywane poprawnie przez EP-54V-150W-DC.

Niestety w tym przypadku korzystanie z oprogramowania Ubiquiti UNMS nie wiele pomoże, nie potrafi ono wykryć problemu niepoprawnego wykrycia ilości akumulatorów co prowadzi do braku włączenia ładowania akumulatorów w odpowiednim momencie. Jest to spowodowane nieprawidłową detekcję ilości podłączonych akumulatorów. Bardzo wyraziście to widać na poniższym wpisie z logów urządzenia:

psu-monitor[452]: PSU#1 [DC] operational, standby, not-charging, batteries: 2, U: 50.958V (Uoc: 51.066V), I: 0.146A, Temp: 26C

Efektem jest rozładowania się 4 akumulatorów do poziomu 27V, czyli poziomu dla 2 akumulatorów podłączonych szeregowo. Na poziomie 27V siłownia załącza ładowanie akumulatorów i dalej nie występuje już ich rozładowanie. Rozładowanie na poziomie 27V dla 4 akumulatorów 12V podłączonych szeregowo można kwalifikować jako poważną usterkę, która prowadzi do uszkodzenia akumulatorów i na pewnie nie zagwarantuje właściwego podtrzymania zasilania urządzeń.

Niestety support UBNT na poziomie "tier 1" nie potrafił mi przez 1,5 tygodnia pomóc, po prostu nie rozumiał problemu, nie eskalował tego do wyższych poziomów wsparcia - zapewne trafiłem na nie odpowiedniego pracownika. Akurat w tym samym czasie miałem inne zgłoszenie na poziomie "tier 3" i przy jego okazji uzyskałem rozwiązanie tego problemu w ciągu 12h. 

 Z linii poleceń należy wydać komendę:

psuctl -b 4 1

gdzie "4" to ilość baterii w podłączeniu szeregowym.

Weryfikację poprawności zmiany ustawień wykonujemy komendą:

psuctl -i

W moim przypadku uzyskałem taki wynik:

EP.v1.8.0-beta1.3569f4.200904.0936# psuctl -i
PSU#0 [AC]:
  enabled: yes
  connected: yes
  standby: disabled
  charge: disabled
PSU#1 [DC]:
  enabled: yes
  connected: yes
  standby: enabled
  charge: enabled
  batteries [4]: 50.274V
    operational: yes
    charging: yes
    temperature: 35C
    current: -0.190A

Nie wiemy dlaczego EdgePower nieprawidłowo wykrywa 4 baterie podłączone szeregowo jako tylko 2 baterie, na pewno ten problem nie dotyczy każdego użytkownika. W moim przypadku cała partia kilkunastu EdgePower była skażona tym problemem. Problem nadal zostaje w suporcie Ubiquiti i mam nadzieję, że kolejne wydania firmware rozwiążą ten problem.

Prosty VRF na MikroTik RouterOS - to samo IP jako gw od 2 różnych ISP

 

Ostatnio spotkałem się z pytaniem o pomoc w konfiguracji MikroTik RouterOS z dosyć niestandardowym problemem. Otóż firma posiada dwa łącza, jedno po światłowodzie od ogólnopolskiego operatora, drugie zapasowe po radiu od lokalnego operatora i obaj operatorzy wymagają od niego pobierania IP z DHCP, gdzie jako bramę domyślną rozgłaszają na każdym z łączy to samo IP.

Pierwszym odruchem było zaproponowanie sugestii wystosowania prośby do jednego z operatorów o zmianę puli adresacji IP rozgłaszanej do klienta.

Drugim pomysłem było zastosowanie prostej konfiguracji VRF.

 

W rzeczywistym przypadku nie było problemów by operator lokalny dokonał szybkiej zmiany adresacji IP, ale co w przypadku gdyby to było nie możliwe ? 

Odpowiedzią jest załączony przykład konfiguracji.

 

Cambium cnMaestro i problemy z urządzeniami cnPilot i ePMP.

W ostatnim czasie zostałem poproszony o pomoc w diagnozie problemu i opracowaniu propozycji naprawy problemów z urządzeniami Cambium cnPilot i ePMP w połączeniu z zarządzaniem chmurowym w cnMeastro.

Problem wyglądał tak, że urządzenia Cambium miały problem z synchronizacją profili oraz traciły kontakt z cnMaestro, a ponowna rejestracja urządzenia (onboarding) w cnMeaestro nie dochodziła do skutku, a na urządzeniu pojawiał się komunikat "Connecting" i tak zostawało.

Z kolejnymi dniami problem rozszerzył się też na inne projekty w podobnej konfiguracji, które wcześniej przez wiele tygodni wszystko działało bez problemów. Co było dosyć ciekawe problem nie objął wszystkich projektów zrealizowanych za pomocą rozwiązań Cambium.

Zgodnie z sugestią Supportu Cambium w Polsce wykonaliśmy zrzutu komunikacji urządzeń i wspólnie z technikami Cambium rozpoczęliśmy ich analizę w programie Wireshark. W każdym przypadku komunikacja z cnMaestro była resetowana po próbie negocjacji MSS, następnie występował ciąg retransmisji pakietów, następnie komunikat "TCP Out-Of-Order" i reset połączenia. Analiza wielkości pakietów wykazała, że w projektach w których występował problem, MTU jest ustawione na 1430 bajty (cześć urządzeń projektu podłączona za pomocą VPN i połączeń LTE, pozostałe lokalizacje miały MTU 1500). Według zaleceń Supportu Cambium minimum jakie jest akceptowane przez cnMaestro to MTU 1434 bajty, który nie może być defragmentowany oraz zasugerowali podniesienie MTU do wartości 1460.
Niestety podniesienie MTU dla połączeń realizowanych za pomocą VPN i LTE do wartości MTU 1460 poprawiła nieznacznie sytuację i część urządzeń (ePMP) uzyskała możliwość synchronizacji z cnMeastro.

Poszedłem dalej tym tropem ... zbudowałem środowisko testowe w którym w łatwy sposób mogłem regulować MTU i fragmentacje pakietów. Każde podniesienie MTU powodowało kolejne postępy, dla wartości MTU 1480 wszystkie cnPilot, które były już zarejestrowane nawiązały ponowną synchronizacje z cnMaestro, ale nowe urządzenia nadal nie potrafiły się prawidłowo zarejestrować w cnMeastro nawet przy wartości MTU 1496. Wszystko prawidłowo działo dopiero przy MTU 1500.

Wszystkie te informacje zostały przekazane w czwartek do Suportu Cambium, który miał dalej zająć się analizą sytuacji i naprawieniem problemu poprzez ponowne umożliwianie rejestracji i synchronizacji dla urządzeń z mniejszym MTU oraz włączona fragmentaryzacją pakietów. Według nieoficjalnych informacji problem pojawił się po zmianie wersji cnMaestro z 2.3 do 2.4.

Propozycja rozwiązania problemu.

Rozwiązanie jest niby proste, trzeba zwiększyć MTU do wartości 1500 bajty, ale jak tego dokonać mając np połączenie VPN/LTE ?

Proponuje do tego użyć tunelu IP w którym definiujemy MTU na 1500 bajty oraz pozwalamy na defragmentacje pakietów wewnątrz tego tunelu.

W moim przypadku wykorzystaliśmy routery MikroTik. W lokalizacji urządzeń  Cambium na punkcie styku z internetem LTE używany jest router MikroTik, a w jednych z centrów kolokacji był już użytkowany router MikroTik. W związku z tym, ze połączenie LTE nie posiadało publicznego stałego adresu IP użyłem połączenia vpn L2TP i na tej warstwie uruchomiłem tunel EoIP. Tunel EoIP wybrałem jedynie z uwagi na możliwość transportowania w nim również vlanów, których używam do różnych ustawień nadajników i profilów dostępu do sieci bezprzewodowej realizowanej za pomocą Cambium.

Posiadacze innych rozwiązań mogą spróbować ustawień np: z tunelami GRE opartymi o vpn ipsec.

Istnieje jeszcze możliwość zmiany MTU na samym urządzeniu cnPilot, w tym wypadku chodzi o zmniejszenie tej wartości. Ja tej opcji nie weryfikowałem z uwagi na ilość urządzeń Cambium w każdym z projektów. Informacje jak to zrobić jest opublikowana w tym wpisie na Cambium Networks Community.

Aktualizacja:

W chwili przygotowania tego wpisu w cnMaestro pojawił się komunikat:

W niedziele o godzinie 11:43 CEST (5:43 ET) cnMaesto wykazywał wersję 2.4.0-r9

Jeszcze nie otrzymałem informacji od Supportu Cambium o rozwiązaniu problemów, planuje w poniedziałek/wtorek przetestować czy naprawili problem z MTU.

Wireless networks and radio boosting

Spotykam się często z pytaniami klientów o sposoby zwiększenia zasięgu nadajników w sieciach bezprzewodowych.

Najczęściej użytkowniki nadajników zaczynają od zwiększenia mocy nadawania urządzeń poprzez różne sposoby omijające ograniczenia narzucone przez przepisy. Uważam to za jeden z gorszych pomysłów. Jeśli producent przygotował urządzenie do pracy z domyślną konfiguracją przy danej mocy nadajnika to zmiana tego parametru może generować niepoprawne działanie urządzenia, zakłócanie innych urządzeń bezprzewodowych czy też po prostu brak efektu.

Przy okazji testów rożnych urządzeń postanowiłem pokazać jak wpływa zmiana domyślnej mocy nadajnika na sposób jak to urządzenie nadaje na przykładzie popularnych modeli urządzeń MikroTik.


1) MikroTik hAP ac2

Producent w specyfikacji sprzętowej podał, że w tym modelu maksymalna moc nadawcza jaką potrafi obsłużyć nadajnik wynosi 26 dBm. Jak widać z załączonych pomiarów po zwiększeniu mocy z 17 dBm do 26 dBm efekt jest bardzo mizerny. Zwiększenie mocy nie przyniosło oczekiwanego efektu.

2) MikroTik Audience

Urządzenie wyposażone aż w dwa nadajniki "5GHz", pierwszy według producenta potrafi pracować z mocą do 28 dBm, drugi nadajnik według producenta potrafi pracować maksymalnie z mocą 32 dBm.

Jak widać poniżej, urządzenie pracując z mocą 17 dBm tylko nieznacznie powoduje zakłócenia na sąsiednich kanałach.

Natomiast po zwiększeniu mocy nadajnika tylko do 30 dBm, moc nadawcza faktycznie wzrosła (ale raczej nie o +13 dBm), ale za to uzyskaliśmy bardzo duże zakłócenia na sąsiednich kanałach.

3) MikroTik RB4011iGS+5HacQ2HnD-IN

Kolejne urządzenie według producenta można skonfigurować do pracy maksymalnie aż do 33 dBm.
Przy pracy przy standardowej mocy nadawczej 17 dBm tylko nieznacznie powoduje zakłócenia na sąsiednich kanałach.

Po zwiększeniu mocy jedynie do 30 dBm (+13 dBm) widać tylko nieznacznie zwiększenie mocy nadajnika ale za to powstają bardzo duże zakłócenia na sąsiednich kanałach.

Podsumowanie:

Próby zwiększenia zasięgu poprzez podnoszenie mocy nadajnika w szczególności w urządzeniach klasy WiFi niesie więcej zagrożeń niż pożytku. Pomijając aspekty zgodności urządzeń z przepisami jako jednym z lepszych pomysłów jest zastosowanie lepszych anten. Anteny dostarczane w tańszych urządzeniach często nie mają najlepszych parametrów. Zastosowanie anteny o innej charakterystyce, markowego producenta, bardziej dostrojonej do aktualnie ustawionej częstotliwości przyniesie zdecydowanie lepsze efekty.
Inna metodą jest budowanie sieci bezprzewodowej z gęściej rozstawionych nadajników radiowych, a w przypadku braku sieci kablowej możemy wykorzystać funkcjonalność sieci bezprzewodowej full mesh lub nawet prostych repeaterów WiFi.

Uwaga: Powyższe pomiary zostały wykonane w czasie symulowania pełnego wysycenia nadajnika pod względem jego możliwości, każdy pomiar trwał 60 sekund. Jest to tylko prosta symulacja pokazujące jakie skutki może mieć nieodpowiedzialne zwiększanie mocy nadajników i nie wyczerpuje wszystkich zagadnień i niuansów związanych z takimi pomiarami. Urządzenia MikroTik są tylko przykładowe i wybrane całkiem przypadkowo, jako będące w chwili pomysłu na artykułu na moim biurku i podobnie będą się zachowywać prawie wszystkie urządzenia z podobnego pułapu cenowego ze względu o oparcie ich o te same schematy konstrukcji referencyjnych. Urządzenia znaczących producentów jak na przykład Cambium wygląda to zdecydowanie lepiej.

Mikrotik - Failover connection via backup (LTE)

Stabilny internet jest coraz ważniejszy, zwłaszcza w czasie COVID19, kiedy znaczna cześć społeczeństwa musi pracować zdalnie. Jednam z działań zapewniającym dostęp do internetu jest zakup łącza u drugiego operatora internetu, wiele osób decyduje się wybrać tutaj dostęp  w postaci łącza LTE.

Pomysłów jak obsługiwać drugie łącze, które jest z zasady ma być tylko zapasowe było już wiele. Niestety, żadne rozwiązanie nie spełniło moich oczekiwać, choć wszystkie „działały”. 

W szukaniu inspiracji trafiłem na artykuł opublikowany na łamach Server Management autorstwa Timo Puistaja z 2017 roku. (https://serman.maxdesk.com/user/viewarticle/9378).

Opisany sposób wykrywania łącza poprzez wydłużanie i manipulacje routingiem okazał się dosyć sprawny, jednak nie potrafił wykrywać awarii łącza kiedy występują utraty pakietów lub drastyczny wzrost czasy przesyłania pakietów przez główne łącze. Postawiłem rozbudować ten pomysł o wszystkie moje potrzeby.

Założenia:

• Szybkie wykrycie utraty z połączeniem głównym;
• Wykrywanie wzrostu czasów opóźnień na łączu głównym i ich interpretacja jako problemu;
• Wykrycie awarii łącz internetu dalej niż moja lokalna brama u dostawcy internetu;
• Wykrycie naprawy połączenia łącza głównego;
• Przejście z łącza zapasowego na główne realizowane z opóźnieniem;
• Pełna automatyka;
• Wykorzystanie posiadanego routera MikroTik

Poglądowy schemat połączeń

Zasada działania opiera się na wykorzystaniu działania narzędzia Netwatch zaimplementowanego w MikroTik RouterOS ze wsparciem skryptów oraz dodatkowej weryfikacji poprzez wydłużenie trasy routingu i sprawdzanie dostępności bramy domyślnej.

Konfiguracje zacznijmy od skryptów.

/system script
add dont-require-permissions=no name=NetWatch-check owner=admin policy=\
    reboot,read,write,policy,test source="#Tutaj mozesz zmienic wartosc\r\
    \n# ilosc czasu w minutach jak dlugo lacze BACKUP bedzie preferowane\r\
    \n# zanim sprawdzimy czy lacze glowne dziala prawidlowo\r\
    \n#\r\
    \n:global nwwait 15;\r\
    \n# pozostaw bez zmian\r\
    \n:global nwgw2;\r\
    \n:tonum nwgw2;\r\
    \n:local nwstatus;\r\
    \n:local nwgwstatus;\r\
    \nset nwgwstatus ([/tool netwatch get value-name=status [find comment=\
    \"NetWatch\"]]);\r\
    \nset nwstatus ([/ip route get value-name=distance number=[/ip route f\
    ind comment=\"BACKUP\"]]);\r\
    \n:if (\$nwstatus = \"6\") do={\r\
    \nset nwgw2 (nwgw2 + 1)\r\
    \n}\r\
    \n:if ((\$nwgw2 > \$nwwait) and (\$nwgwstatus = \"up\")) do={ :log err\
    or \"Master GW: OK\"\r\
    \n/ip route set [find comment=\"BACKUP\"] distance=66;\r\
    \nset nwgw2 (0)\r\
    \n}\r\
    \n"
add dont-require-permissions=no name=NetWatch owner=admin policy=\
    reboot,read,write,test source="/log error \"Master GW: PROBLEM\"\r\
    \n/ip route set [find comment=\"BACKUP\"] distance=6\r\
    \n\r\
    \n"
add dont-require-permissions=no name=NetWatch-init owner=admin policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    source="#ilosc sprawdzen zanim lacze sie przelaczy\r\
    \n:global nwwait 20;\r\
    \n"

Skrypty:

NetWatch: skrypt uruchamiany w przypadku awarii głównego łącza
NetWatch-check: skrypt uruchamiany czasowo weryfikujący przełączanie się z powrotem na łącze główne, w tym skrypcie możemy zdefiniować jak długo łącze BACKUP od czasu przełączenia pozostanie łączem wiodącym zanim sprawdzimy czy łącze główne działa już prawidłowo. W domyśnej sytuacji jest to 15 minut.

Kolejnym krokiem jest zdefiniowanie czasowego uruchamiania skryptów.

/system scheduler
add interval=1m name=NetWatch on-event=\
    "/system script run NetWatch-check\r\
    \n" policy=\
    ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
    start-date=apr/11/2020 start-time=17:31:44

Czas skonfigurować narzędzie Netwatch Mikrotika. w miejsce A.B.C.D należy podać adres domyślny bramy głównego łącza. Wartość timeout możemy określać jak czułe będzie wykrywanie awarii łącza głównego.

/tool netwatch
add comment=NetWatch down-script="/system script run NetWatch\r\
    \n" host=A.B.C.D interval=5s timeout=100ms

Na koniec należy skonfigurować routing, wykorzystujemy tutaj sztuczkę z wydłużoną trasą routingu i sprawdzaniem dostępności bramy domyślnej.
W miejsce A.B.C.D należy podać adres domyślny bramy głównego łącza, a w miejsce E.F.G.H należy podać adres domyślny bramy łącze zapasowego BACKUP.

/ip route
add comment=MASTER distance=10 gateway=10.255.66.1
add comment=BACKUP distance=66 gateway=10.255.67.1
add check-gateway=ping distance=1 dst-address=10.255.66.1/32 gateway=\
    208.67.220.220 scope=10
add check-gateway=ping distance=1 dst-address=10.255.66.1/32 gateway=\
    8.8.8.8 scope=10
add check-gateway=ping distance=1 dst-address=10.255.67.1/32 gateway=\
    208.67.222.222 scope=10
add check-gateway=ping distance=1 dst-address=10.255.67.1/32 gateway=\
    8.8.4.4 scope=10
add distance=1 dst-address=8.8.4.4/32 gateway=E.F.G.H scope=10
add distance=1 dst-address=8.8.8.8/32 gateway=A.B.C.D scope=10
add distance=1 dst-address=208.67.220.220/32 gateway=A.B.C.D scope=10
add distance=1 dst-address=208.67.222.222/32 gateway=E.F.G.H scope=10

Wykorzystujemy popularne adres ip usług dns Google (8.8.8.8, 8.8.4.4) i OpenDNS (208.67.220.220, 208.67.222.222), które sprawdzamy czy są osiągalne przez łącze danego operatora. Jeśli są dostępne to uaktywnia się brama domyślna dla danego łącza.

W powyższym rozwiązaniu użyliśmy podwójnej weryfikacji poprawnego działania łącza internetowego, raz poprzez sprawdzanie bramy domyślnej głównego łącza oraz dodatkowo sprawdzania dostępności hostów "daleko w internecie" osiąganych z konkretnych łączy.

Rozwiązanie to ma pewne ograniczenie, w przypadku kiedy jeden z operatorów przy renegocjacji połączenia zmienia parametr bramy domyślnej nie jesteśmy w stanie to skonfigurować bezpośrednio.
W takim przypadku należy użyć osobny router dla tego połączenia jak w schematach poniżej i jego wskazać jako bramę połączenia.

 

Jestem przekonany, że rozwiązanie można poprawić i dalej rozbudować, skrypty które przygotowałem można inaczej napisać przy utrzymaniu głównej zasady działania rozwiązania.

W razie pytań zapraszam do kontaktu poprzez profil na FaceBook lub LinkedIn.