Materiały video:
– https://youtu.be/i5zezvoflro?feature=shared
– https://youtu.be/P9p2MmAT3PA?feature=shared
– https://youtu.be/HXu0Ifj0oWU?feature=shared
– https://youtu.be/nX38mWxtWf0?feature=shared
– https://youtu.be/RAqMP_NnGec?feature=shared
– https://youtu.be/dZfN3uYtC2I?feature=shared
– https://youtu.be/7bp9COm0K1M?feature=shared
– https://youtu.be/Lq7j-QipNrI?feature=shared
Wprowadzenie
1. Podstawowe elementy
Protokół SNMP (ang. Simple Network Management Protocol) jest rozwiązaniem o wieloletniej tradycji (od roku 1988) i obecności w świecie IT. Aktualnie to jest raczej framework a nie sam, pojedynczy protokół. Wywodzi się z protokołów SGMP (Simple Gateway Management Protocol) protokołu monitorującego routery oraz protokołu CMIP (ang. Common Management Information Protocol). Dokumentami bazowymi są RFC 1065, 66, 76 (dotyczą one wersji 1). Aktualnie mamy w użyciu wersję 1 (chyba już nie jest używana) nie wspierającą szyfrowania czy autentykacji, wersję 2c (też nie obsługuje szyfrowania ale pozwala na efektgywne pobieranie danych, wiele za jednym poleceniem) oraz wersję 3 z autentykacją i szyfrowaniem transmisji.
Protokół SNMP jest typu klient/serwer, tutaj zwany manager/agent. Mamy zatem dwa rodzaje użądzeń.
Urządzenia monitorowane: serwerem jest agent działający na monitorowanym urządzeniu. Zazwyczaj jest to oprogramowanie wbudowane przez producenta. Takie urządzenie zwane tez jest MNE (ang. Managed Network Entity). Agent monitoruje różne parametry urządzenia i może być odczytywany przez klienta (stację monitorującą) w trybie tzw. polling (ankietowanie) lub samodzielnie wysyłać informacje na bazie tzw. pułapek (ang. traps).
Urządzenia monitorujące: klientem jest oprogramowaniem działające na stacji monitorującej (np. libreNMS, openNMS, Zabbix, Observium, MikrotTik The Dude i wiele innych). Nazwany NMS (ang. Network Management Station) i jest to centralny punkt monitorowania. To on decyduje co i jak oraz kiedy monitorować, w jakich interwałach czasu itd.
Stacja NMS może być w mare prostą aplikacją (np. iReasoning MIB Browser) bardzo złożonym oprogramowaniem z dużą bazą przechowującą historię zdarzeń z wielu monitorowanych urządzeń oraz prezentującą wyniki w postaci graficznej (np. libreNSM, Grafna+Prometheus, Zabbix i wiele innych).
SNMP Manager zajmuje się wysyłaniem zapytań, odbieraniem odpowiedzi oraz pułapek z urządzeń nadzorowanych. Przykładem jest Prometheus.
SNMP frontend to aplikacja pozwalająca zarządzać managerem, budować zapytania, prezentować odpowiedzi i wyniki. Przykładem jest snmpwalk (wiersz poleceń Linux) oraz Grafana, potężny system graficznej prezentacji statystyk SNMP.
Urządzenie zarządzane takie jak serwer, router, przełącznik, accesspoint i wiele innych zawiera:
Agent SNMP jest to oprogramowanie najczęściej wbudowane w urządzenie zbierające dane z różnych jego komponentów. Aby to wykonać posiada wbudowaną bazę MIB zawierającą ustandaryzowane identyfikatory obiektów, które mogą być monitorowane. Każdy obiekt ma przyporządkowany numer OID (ang. Object Identifier) i jest zapisany w bazie MIB (o czym jest napisane dalej). Obiektem może być temperatura CPU, stan interfejsu itp.
2. Komunikacja
Protokół SNMP używa portów 161 i 162 UDP. Jest to protokół typu żądanie/odpowiedź. Protokół UDP jest bezpołączeniowy, nie gwarantuje dostarczenia danych. Nie jest to problemem ponieważ w tym wypadku NMS może ponowić żądanie. Protokół wykorzystuje kilka komunikatów:
GetRequest: menadżer (NMS) żąda informacji (Get, GetNext, GetBulk w SNMPv2)
GetResponse: agent odpowiada menadżerowi
SetRequest: menadżer może wysłać do agenta (czyli monitorowanego urządzenia) polecenie zmiany jakiegoś parameteru
Trap/Inform: agent wysyła menadżerowi informacje o pewnym zdarzeniu
Komunikacja może odbywać sie w trzech trybach:
a. Ankietowanie (polling): stacja monitorująca (manager) odpytuje agentów o stan różnych parametrów danego urządzenia. Zaletą jest minimalne obciążenie urządzenia monitorowanego, wadą jest brak informacji dla NMS w czasie rzeczywistym. Jeśli odpytywanie jest ustawione na np. co 5 minut, NMS nie zna stanu urządzenia między kolejnymi zapytaniami. Tego typu zapytania wysyłane są na port UDP 161 agenta.
b. Pułapki (trap): w tym wypadku urządzenie monitorowane samodzielnie wysyła informacje o różnych zdarzeniach (np. przekroczenie temperatury CPU, awaria interfejsu) do NMS. Tego typu informacje wysyłane są na port UDP 162 menadżera.
c. Stacja monitorująca wysyła do urządzenia monitorowanego zlecenia zmiany pewnego parametru, np. nazwy.
3. Typy komunikatów SNMP
Protokół SNMP korzysta z kilku typów poleceń i zawartych w nich wiadomości. Poniżej kilka przykładów.
Przykład poleceń SNMP w RouterOS:
Szczegóły poleceń SNMP tutaj.
4. Identyfikatory i bazy MIB
Wszelkie obiekty, które można monitorować (takie jak CPU, pamięć itp.) zostały opisane za pomocą SMI (ang. Structure of Management Information). Jest znormalizowany sposób prezentacji danych (RFC1155, 1065). Bazuje on unikalnych identyfikatorach obiektów OID. Te identyfikatory najczęściej są przedstawiane w postaci drzewa natomiast przechowywane są tekstowych bazach MIB (ang. Management Information Base). Dobry opis tematu baz MIB znajdziesz na stronie Oracle. Przydatną przeglądarką online jest Free MIB Browser.
Każdy obiekt do monitorowania ma swój unikalny numer i pozycje w drzewie OID. Pokazano to niżej.
Struktura drzewiasta zapewnia elastyczne i unikalne nazewnictwo obiektów. Większość urządzeń różnych producentów znajduje się w gałęzi drzewa .1.3.6.1.4.1. Powyższy przykład pokazuje, że firma Tp-Link ma ID 11863 w gałęzi .1.3.6.1.4.1. Podobnie jak w systemie DNS cała struktura zaczyna się od korzenia symbolizowanego kropką (ang. root). Dobrym miejscem na szukanie OID jest serwis OID-INFO.
Wpisy i numery jak i nazwy OID dzielą sie na dwie grupy: standardowe oraz prywatne (producentów sprzętu). Przykładem standardowego OID jest nazwa systemu (którą posiada chyba każdy sprzęt sieciowy), ma ona numer:
.1.3.6.1.2.1.1.5 (na początku jest kropka, to ważne!).
Według drzewa OID nazwę można także zapisać jako:
.iso.org.dod.internet.mgmt.mib-2.system.sysName
Poniżej przykład na bazie polecenia snmpwalk:
Na przykładzie systemu RouterOS możemy wyświetlić OID dla interfejsów radiowych. Pierwsza część .1.3.6.1.4.1 prowadzi nas do części drzewa przeznaczonej dla producentów. Kolejno mamy numer 14988 przydzielony MikroTik. Dalej mamy to, co ustaliła ta firma jeśli chodzi o numery ODI. W tym wypadku jest to częstotliwość wybranej karty radiowej (5560 MHz).
#/interface wireless print oid
Łącząc obie ilustracje:
Dla opisu zasobów systemu RouterOS wygląda to nieco inaczej (korzystamy ze standardowej bazy i ścieżki):
Te wpisy prowadzą nas do bazy MIB.
5. Baza MIB
Baza ta przechowuje odwzorowania OID – nazwa i pozwala na efektywny zapis obiektów celem ich monitorowania. Zapis danych w bazie jest zgodny z Abstract Syntax Notification v1.
Istnieją trzy rodzaje baz MIB
Bazy MIB są standardowym zapisem obiektów. Znajduje się w nich szereg obiektów systemów Unix
Bazy MIB2 (MIBII) są rozszerzeniem baz MIB o możliwości monitorowania TCP/IP
Bazy prywatne tworzone są przez producentów sprzętu i rozszerzają możliwości MIB2 o obiekty specyficzne dla danego urządzenia.
Aby odczytać bazę prywatną system NMS musi znać jej format i przeznaczenie OID. Na szczęście producenci dobrze dokumentują te kwestie oraz istnieje wiele systemów typy NMS z różnymi wtyczkami dla konkretnego producenta. Proces łącznia baz MIB nazywa się kompilacją i polega na połączeniu bazy producenta z bazami standardowymi.
Standardowe bazy MIB (po ich uprzednim pobraniu za pomocą mibs-download) znajdziemy w systemie Linux w katalogu:
/home/jnowak/.snmp/mibs:/usr/share/snmp/mibs:/usr/share/snmp/mibs/iana:/usr/share/snmp/mibs/ietf (tutaj pojawią się po instalacji oprogramowania SNMP)
lub
/var/lib/mibs/iana oraz ietf (tutaj pojawią się po instalacji oprogramowania SNMP i ręcznym ich pobraniu).
Baza taka zawiera obiekty do monitorowania wraz z ich parametrami, poniżej przykład bazy dla urządzenia UPS
Mamy tu informacje na temat jednego z parametrów do monitorowania: „upsIdentManufacturer” czyli ID producenta UPSa. Jest to wartość typu łańcuch znaków o maksymalnej długości 32 znaki i tylko do odczytu.
Producenci tworzą własne bazy, przykładem jest MikroTik i jego baza specyficzna dla systemu RouterOS oraz urządzeń RouterBoard. Dzięki takiej bazie można korzystać z nazw obiektów nie tylko z ich numerów.
Przykładową bazę dla MikroTik można pobrać ze strony: https://mikrotik.com/download:
Bazę taką możemy pobrać i umieścić w standardowym katalogu np. /var/lib/mibs/ietf
#wget https://download.mikrotik.com/routeros/7.17/mikrotik.mib
#sudo cp mikrotik.mib /var/lib/mibs/ietf
Kolejno zmieniamy jej nazwę na „MIKROTIK-MIB”. Teraz możemy z niej korzystać jak niżej (więcej informacji w dalszej części)
#snmpwalk -v 2c -c public -m MIKROTIK-MIB 192.168.53.6 .1.3.6.1.4.1.14988.1.1.3.17 -Of
Przełącznik -Of pozwala pokazać nazwy a nie tylko identyfikatory numeryczne
Więcej informacji na temat SNMP MikroTik: https://wiki.mikrotik.com/Manual:The_Dude/MIB_Nodes.
Kompilacja nowej bazy
Pod pojęciem kompilacji rozumiemy dodanie nowej bazy MIB do managera celem rozszerzenia jego możliwości o monitorowanie dodatkowych urządzeń. Kompilacja polega na pobraniu bazy MIB producenta i wykonaniu czynności w zależności od posiadanego oprogramowania. Po kompilacji mamy możliwość odczytu specyficznych OID z danego urządzenia. Operacje taką przeprowadziny w przykładowym systemie NMS w dalszej części materiałów.
