Nebula Rozwiązywanie problemów – Najczęstsze problemy

Ten artykuł będzie dotyczył rozwiązywania najczęstszych problemów – jeśli urządzenia pozostają offline, nie można zobaczyć żadnych danych/logów (PoE, zużycie CPU, zużycie danych, logi itp.), konfiguracje nie są przesyłane (zarządzanie oprogramowaniem), korzystanie z logów zdarzeń.

Jesteśmy bardzo zadowoleni, że nasze Nebula Cloud Solution zyskuje na popularności w terenie oraz staje się coraz ważniejszym elementem naszej oferty. To, co zaczęło się jako rozwiązanie „spin-off”, stało się, zgodnie z naszymi inwestycjami i przewidywaniami, kamieniem węgielnym naszych operacji i produktów. Jednak wraz z tym przesunięciem uwagi, sprzęt obsługujący Nebula jest coraz częściej używany w profesjonalnych środowiskach sieciowych. To przesunięcie rodzi pytanie dla wielu naszych klientów: „Co mogę zrobić, aby samodzielnie przeanalizować moje problemy, zanim zwrócę się do kogoś innego?”

Ten przewodnik dostarczy kilka pomysłów i wskazówek, co sprawdzić, jeśli Twoje urządzenia nie działają prawidłowo – niektóre z nich mają charakter ogólny (= przykłady najlepszych praktyk), inne są bardziej specyficzne dla różnych dziedzin technologii.

Uwaga: urządzenia zarządzane przez Nebula nie są przeznaczone do konfiguracji w jakiejkolwiek formie przez połączenie konsolowe – prosimy używać dostępu SSH do urządzeń Nebula wyłącznie do monitorowania oraz, ewentualnie we współpracy z naszym działem wsparcia/R&D, do pomiarów debugowania.

Urządzenia pozostają offline

Wyobraź sobie – zarejestrowałeś swoje urządzenie pomyślnie, może nawet skonfigurowałeś je według własnych preferencji i jesteś teraz w fazie wdrożenia urządzenia. Jednak z powodów jeszcze dla Ciebie nieznanych, dane urządzenie po prostu nie chce się połączyć z siecią, zarówno na miejscu, podczas pracy, jak i nie pokazuje się jako online i responsywne.

To jeden z najczęstszych problemów podczas wdrażania urządzeń Nebula – powód tego jest w skrócie taki, że urządzenia domyślnie próbują rozwiązać adresy s.nebula.zyxel.com lub d.nebula.zyxel.com. To powoduje dwa problemy:

1. Wielokrotnie zagnieżdżona subdomena (np. this.that.andthis.alsothis.domain.com) może powodować problemy u niektórych dostawców DNS
2. Zgodnie z nowszymi standardami subdomena może składać się także z pojedynczego znaku, podczas gdy wcześniej minimalna długość wynosiła trzy znaki. Niektóre serwery DNS mają z tym problemy.

Bardzo często widzimy, że serwery DNS dostawców usług internetowych mają z tym problemy. Nasza rekomendacja: zmień domyślny serwer DNS na 8.8.8.8 lub 1.1.1.1. Więcej informacji znajdziesz tutaj:

Co zrobić, jeśli moje urządzenie Nebula nie może się połączyć / ma problemy z połączeniem / nie komunikuje się z NCC?

Nie widzę żadnych danych!

Czasem klienci zgłaszają się do nas, skarżąc się, że zalogowali się po dłuższym czasie i ich dane albo zniknęły, albo „nic się nie wyświetla”. Może się zdarzyć, że z powodu dłuższej nieaktywności na portalu, organizacja została ustawiona w Tryb oszczędzania w chmurze, który zasadniczo przerywa zbieranie informacji po okresie bezczynności wynoszącym 30 dni. Tryb oszczędzania w chmurze powinien być sygnalizowany komunikatem oraz banerem (jasnoniebieski baner). Rozwiązanie: wyłącz Tryb oszczędzania w chmurze i poczekaj kilka minut, dane powinny wkrótce powrócić.

Więcej informacji można znaleźć tutaj: Tryb oszczędzania w chmurze (Nebula BASE Pack)

Konfiguracje nie są przesyłane

Może się zdarzyć, że urządzenie pokazuje się jako online, ale zmiany konfiguracji nie są stosowane? Sprawdź oprogramowanie układowe! Niektóre zmiany mogą wymagać najnowszej wersji oprogramowania, aby działać prawidłowo, a czasem zmiany są wstrzymywane z tego powodu:

To doskonały przykład tego, czego nie chcielibyśmy zobaczyć – w tym przypadku oprogramowanie zapory jest przestarzałe, co blokuje zastosowanie nowych bloków konfiguracji, podczas gdy wszystkie inne wskaźniki (zużycie CPU, RAM, liczba klientów, stan online/offline) wydają się poprawne. Wstrzymanie fragmentów konfiguracji dotyczy szczególnie, ale nie wyłącznie, nowych funkcji zaimplementowanych w najnowszym oprogramowaniu. Poza opisanym powyżej „problemem DNS” mogą to być cenne wskazówki.

Monitorowanie przez Nebula – przydatne informacje na wyciągnięcie ręki!

Funkcje monitorowania dostarczają realne korzyści i narzędzia do Twoich zasobów monitorujących i analitycznych. Na początek coś prostego – urządzenie pokazuje się jako offline, ale masz wrażenie, że nadal komunikuje się z Nebula Cloud Center? Po prostu przejdź do strony głównej urządzenia – dla bramek będzie to:

Devices -> Firewall

i wykonaj test Ping – jeśli test ping faktycznie wyśle komunikat „Ping destination W.X.Y.Z” i urządzenie go odbierze oraz zwróci potwierdzenie udanego pinga, oznacza to, że urządzenie w rzeczywistości nadal komunikuje się z NCC, a stan offline może być spowodowany problemem z pamięcią podręczną przeglądarki lub ciasteczkami.

Inny przykład z życia: wiele portów przełącznika stale wyświetla w logach zdarzeń komunikaty o przełączaniu między połączeniami 10Mb/s i 1Gb/s, a Ty nie jesteś pewien, czy przełącznik powoduje problemy?

Sprawdź tabelę MAC przez:

Devices > Switches > (wybierz przełącznik) > Live Tools > Switch Tables > Run-Button

Masz teraz informacje, które mogą pomóc – w podanym przykładzie okazało się, że wszystkie porty przełącznika pokazujące takie zachowanie miały bardzo specyficznego producenta MAC, co wskazuje raczej na konkretny typ klienta mającego ten problem, a nie na problem z przełącznikiem – możliwym rozwiązaniem może być ustawienie stałej prędkości na tych klientach i odpowiednich portach przełącznika.

Istnieje wiele innych przykładów, jak monitoring może zdziałać cuda w rozwiązywaniu błędów, ale chyba rozumiesz już sedno.

Korzystanie z logów zdarzeń, aby lepiej zrozumieć procesy „pod maską”

Logi zdarzeń, które każda dziedzina technologii posiada osobno, oferują ogromną pomoc w informowaniu o powodach, dla których coś nie działa – szczególnie w problemach związanych z WiFi.
Spójrzmy na jeden przykład dotyczący sieci WiFi, pokazujący trzy różne wpisy:

Przeanalizujmy po kolei trzy różne punkty:

1. Informuje nas, że konkretna stacja o określonym adresie MAC połączyła się z danym punktem dostępowym. Połączenie nastąpiło z siłą sygnału -81dBm, co ostatecznie jest zbyt słabe.
2. Stacja opuściła określony SSID, AP, kanał z powodu kodu WiFi 3. Kody przyczyn WiFi to zunifikowane kody służące do identyfikacji i zrozumienia zachowania WiFi. Kod przyczyny WiFi 3 oznacza, że stacja świadomie zdecydowała się opuścić SSID.
3. Miał miejsce proces roamingu (= przejście z jednego AP na inny) konkretnego klienta.

To oczywiście tylko przelotne spojrzenie na to, co mogą powiedzieć logi zdarzeń, ale pokazuje, że mogą one być potężnym narzędziem do zrozumienia, co faktycznie dzieje się w Twojej sieci. Szczególnie w odniesieniu do problemów z WiFi, istnieją dodatkowe narzędzia do oceny jakości WiFi, takie jak Wireless Health, listy klientów itd. Następujące artykuły mogą również dostarczyć więcej informacji na ten temat:

Nebula AP „Łatwe rozwiązywanie problemów”

Rozwiązanie Wireless Health od Zyxel Networks