sobota, 22 stycznia 2022

Instalacja Check_MK RAW w systemie Debian 11 (Linux)

 

Do wykonania instalacji Check_MK RAW (wersja bez opłat) potrzebny nam będzie pakiet gdebi. Jest to prosty instalator pakietów deb, który pobiera i instaluje również zależne pakiety. Instalacje możemy wykonać poprzez sudo z poziomu konta głównego użytkownika lub z poziomu shella z uprawnieniami root.

 sudo apt install gdebi-core

 

Instalacja

Pakiet Check_MK RAW w najnowszej wersji możemy pobrać ze strony: 

https://checkmk.com/download?edition=cre&version=stable

W czasie przygotowania niniejszego wpisu była to wersja 2.0.0p18, którą pobrałem na serwer za pomocą komendy wget.

wget https://download.checkmk.com/checkmk/2.0.0p18/check-mk-raw-2.0.0p18_0.bullseye_amd64.deb

 Instalacja pobranego pakietu Check_MK RAW:

sudo gdebi check-mk-raw-2.0.0p18_0.bullseye_amd64.deb 

sobota, 31 października 2020

poniedziałek, 5 października 2020

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.


środa, 19 sierpnia 2020

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.

 

niedziela, 3 maja 2020

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.


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.