sobota, 18 kwietnia 2020

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.




sobota, 11 kwietnia 2020

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.