SNMP nie raportuje danych do serwera

SNMP nieraportujące danych do serwera wskazuje na niepoprawnie skonfigurowany community string lub docelowy adres IP menedżera SNMP.

SNMP nie raportuje danych do serwera – na czym polega problem

SNMP, czyli Simple Network Management Protocol, służy do przekazywania informacji o stanie urządzeń do systemu nadzorującego. W praktyce monitorowany może być przełącznik sieciowy, router, punkt dostępowy, drukarka, zasilacz awaryjny, urządzenie pamięci masowej albo inny element infrastruktury. Gdy SNMP nie raportuje danych do serwera, system monitoringu przestaje otrzymywać odpowiedzi, wykresy pozostają puste, a wartości dotyczące obciążenia, temperatury, dostępności interfejsów lub błędów nie są aktualizowane.

Sama niedostępność danych nie musi oznaczać awarii sprzętu. Często urządzenie działa prawidłowo, lecz nie może rozpoznać zapytania, nie wie, dokąd wysłać komunikat albo odrzuca ruch na poziomie zapory sieciowej. Znaczenie ma również wersja protokołu, sposób uwierzytelniania, zakres udostępnianych obiektów oraz to, czy monitoring korzysta z odpytywania, czy z komunikatów wysyłanych samoczynnie przez urządzenie.

W starszych konfiguracjach często stosowany jest community string, pełniący funkcję wspólnego identyfikatora między urządzeniem a systemem monitorującym. Jeżeli identyfikator wpisany w urządzeniu różni się od wartości używanej przez menedżera SNMP, zapytanie może zostać odrzucone mimo poprawnej łączności sieciowej. W nowszych wdrożeniach wykorzystywane są wersje SNMPv3, które uwzględniają użytkownika, uwierzytelnianie i szyfrowanie. W takim przypadku błąd może wynikać z niezgodności parametrów bezpieczeństwa, a nie z samego adresu IP.

SNMP nie raportuje danych – kontekst techniczny i porównanie trybów pracy

Warto odróżnić dwa sposoby działania SNMP. W trybie odpytywania system monitorujący wysyła żądanie do urządzenia, a następnie oczekuje odpowiedzi zawierającej określone obiekty z bazy MIB. Jeżeli pakiet nie dociera do celu, odpowiedź jest blokowana albo urządzenie nie udostępnia żądanego obiektu, wynik pozostaje pusty. W trybie powiadomień urządzenie samo wysyła komunikat, na przykład po wykryciu zmiany stanu portu lub przekroczeniu ustalonego progu. Wtedy szczególne znaczenie ma adres odbiorcy trapów, port docelowy oraz reguły zezwalające na ruch przychodzący.

Brak odpowiedzi na zapytania nie zawsze jest równoznaczny z brakiem powiadomień. Możliwa jest sytuacja, w której odpytywanie działa, ale trapy nie docierają do systemu nadzorującego. Zdarza się też odwrotnie: urządzenie wysyła pojedyncze alarmy, lecz nie udostępnia wartości, które powinny być regularnie pobierane. Dlatego diagnoza powinna obejmować osobno zapytania GET, odpowiedzi urządzenia oraz komunikaty trap.

Podczas porównywania konfiguracji powinno się sprawdzić adres źródłowy i docelowy, używaną wersję protokołu, community string albo dane SNMPv3, a także identyfikator urządzenia w systemie monitorującym. Znaczenie ma również wybór właściwego interfejsu sieciowego. Urządzenie może posiadać kilka adresów, lecz komunikaty mogą być wysyłane z innego interfejsu niż ten, który został dopuszczony w regułach dostępu. W rezultacie odpowiedź dociera do systemu, ale zostaje odrzucona, ponieważ pochodzi z nieoczekiwanego adresu.

Przydatne bywa zestawienie wyników z kilku punktów sieci. Jeżeli zapytanie działa z jednego komputera, a nie działa z hosta monitorującego, większe prawdopodobieństwo dotyczy filtrowania ruchu, tablic routingu lub reguł dostępu. Jeżeli problem występuje z każdego miejsca, należy sprawdzić usługę SNMP w samym urządzeniu, jej stan po restarcie oraz ostatnie zmiany konfiguracji.

SNMP nie raportuje danych do serwera – typowe problemy i objawy

• Niepoprawny community string jest jednym z najczęstszych powodów braku odpowiedzi w SNMPv1 i SNMPv2c. Nawet pojedyncza różnica w wielkości liter, spacji lub znaku specjalnym może spowodować odrzucenie zapytania.

• Wpisanie niewłaściwego adresu IP menedżera sprawia, że urządzenie kieruje komunikaty do innego hosta albo do nieistniejącego odbiorcy. Dotyczy to zarówno odpytywania, jak i konfiguracji trapów.

• Zablokowanie ruchu UDP może uniemożliwić wymianę danych. Dla standardowego odpytywania używany jest zwykle port 161, natomiast komunikaty trap są najczęściej kierowane na port 162. Własne reguły lub niestandardowa konfiguracja mogą jednak zmieniać ten schemat.

• Wyłączona usługa SNMP, ograniczenie dostępu do wybranych adresów albo przypisanie usługi wyłącznie do konkretnego interfejsu może wyglądać jak awaria połączenia.

• Niezgodność wersji protokołu powoduje brak komunikacji, gdy system wysyła zapytanie w SNMPv3, a urządzenie oczekuje SNMPv2c, albo gdy niezgodne są mechanizmy uwierzytelniania i szyfrowania.

• Ograniczony widok MIB może sprawić, że urządzenie odpowiada, lecz nie zwraca oczekiwanych danych. W monitoringu widoczny bywa wtedy częściowy zestaw parametrów, komunikat o nieznanym obiekcie albo puste pola.

• Zmiana adresacji, podsieci, bramy lub tras może przerwać komunikację bez widocznych zmian w ustawieniach SNMP. Szczególnie często problem pojawia się po wymianie routera, zmianie segmentacji albo odtworzeniu konfiguracji z kopii.

• Błędny czas systemowy nie zawsze blokuje starsze wersje SNMP, ale w SNMPv3 może wpływać na ochronę przed odtwarzaniem komunikatów i prowadzić do odrzucania poprawnie wyglądających żądań.

SNMP nie raportuje danych – praktyczne wskazówki diagnostyczne

Diagnozę warto rozpocząć od ustalenia zakresu problemu. Należy sprawdzić, czy nie raportuje jedno urządzenie, cała grupa urządzeń, czy tylko wybrane parametry. Istotne jest również określenie momentu wystąpienia usterki. Jeżeli dane zniknęły po zmianie adresacji, aktualizacji oprogramowania, wymianie zapory albo przywróceniu ustawień fabrycznych, te zdarzenia powinny zostać potraktowane jako ważne wskazówki.

Następnie można potwierdzić podstawową łączność przy użyciu narzędzi dostępnych w danym środowisku. Odpowiedź na test połączenia nie potwierdza jeszcze działania SNMP, ale jej brak wskazuje na problem niższej warstwy. Kolejnym krokiem jest sprawdzenie, czy host monitorujący może dotrzeć do właściwego adresu i portu UDP. W razie potrzeby analizuje się przechwycony ruch sieciowy, aby ustalić, czy zapytanie opuszcza hosta, dociera do urządzenia i czy wraca odpowiedź.

W konfiguracji urządzenia powinno się porównać adres dozwolonego menedżera z rzeczywistym adresem hosta monitorującego. Przy użyciu translacji adresów trzeba ustalić, jaki adres widzi urządzenie po drugiej stronie połączenia. Warto także zweryfikować, czy system monitorujący nie korzysta z kilku interfejsów i czy zapytania nie wychodzą z innego adresu niż zakładany.

Przy SNMPv2c sprawdza się community string oraz zakres obiektów dostępnych dla danego identyfikatora. Przy SNMPv3 należy porównać nazwę użytkownika, poziom bezpieczeństwa, metodę uwierzytelniania, klucz, sposób szyfrowania i dane synchronizacji czasu. Każda zmiana powinna być wprowadzana w sposób kontrolowany, z zapisaniem poprzednich ustawień. Pozwala to łatwo odtworzyć działającą konfigurację, gdy korekta nie przyniesie oczekiwanego rezultatu.

Nie powinno się ograniczać testu do jednego wskaźnika. Po przywróceniu komunikacji należy sprawdzić kilka różnych obiektów, na przykład stan interfejsu, licznik ruchu i podstawowe informacje o urządzeniu. Dzięki temu można odróżnić całkowity brak dostępu od sytuacji, w której działa tylko część MIB. W przypadku trapów trzeba dodatkowo wywołać kontrolowane zdarzenie testowe albo przeanalizować dzienniki, aby potwierdzić, że komunikat został wygenerowany i odebrany.

SNMP nie raportuje danych do serwera – kiedy zgłosić się do serwisu

Zgłoszenie do serwisu jest uzasadnione, gdy samodzielne porównanie ustawień nie wyjaśnia przyczyny, problem powraca po restarcie, występują równocześnie inne objawy albo potrzebna jest analiza konfiguracji kilku urządzeń. Dotyczy to także sytuacji, w której brak danych z monitoringu utrudnia ocenę temperatur, obciążenia, stanu dysków, interfejsów lub zasilania. Przed przekazaniem urządzenia warto przygotować informację o modelu, adresie używanym w monitoringu, wersji SNMP, chwili pojawienia się problemu oraz ostatnich zmianach w sieci.

W Warszawie takie przypadki może przeanalizować Warszawskie Pogotowie Komputerowe 24/7, przy czym ustalenie przyczyny powinno obejmować zarówno ustawienia urządzenia, jak i komunikację z systemem monitorującym. Własny transport ułatwia przekazanie sprzętu do sprawdzenia, jeśli analiza na miejscu nie jest wystarczająca. Po zakończeniu prac przekazywane są informacje o źródle problemu, wykonanych czynnościach i zaleceniach dotyczących dalszej konfiguracji.

Nie zaleca się pochopnego przełączania całego środowiska na inną wersję SNMP ani zmieniania wielu parametrów jednocześnie. Takie działanie może utrudnić ustalenie przyczyny i spowodować utratę działających ustawień. Bezpieczniejsze jest wykonanie kopii konfiguracji, zmiana jednego elementu, przeprowadzenie testu oraz zapisanie wyniku. Jeżeli komunikacja nadal nie działa, analizie powinny zostać poddane kolejno: adres odbiorcy, reguły dostępu, porty, wersja protokołu, dane uwierzytelniające, zakres MIB i stan usługi SNMP.