Co zrobić, kiedy liczba urządzeń wymagających monitorowania drastycznie wzrasta i po prostu brakuje czasu na indywidualną kontrolę każdej maszyny? Temu wyzwaniu pomaga sprostać protokół SNMP, będący standardem zarządzania siecią.
Simple Network Management Protocol (SNMP) to prosty protokół zarządzania siecią, który działa w warstwie aplikacji modelu ISO/OSI, umożliwiając wymianę informacji kontrolnych pomiędzy urządzeniami sieciowymi. Niestety, z racji tego, że jest on wykorzystywany przez wąską grupę specjalistów, nie słyszy się o nim tyle, co np. o SMTP, POP3 czy DNS.
Ideę SNMP można łatwo zrozumieć, przywołując codzienne, rutynowe sprawdzanie temperatury. To normalne, że mieszkając w Krakowie, po spojrzeniu na termometr za oknem odczytamy temperaturę krakowskiego powietrza. Gdyby jednak ulepszyć termometr w taki sposób, aby jednocześnie pokazywał temperaturę ze wszystkich miast w Polsce, moglibyśmy powiedzieć, że z jednego miejsca w kraju monitorujemy stan temperatury w całej Polsce. Jeśli dodatkowo wyposażyć ten cudowny termometr w możliwość odczytu innych informacji (np. liczby osób w danym mieście, ilości kolizji drogowych, etc.), a także ich zmiany, powstałby supertermometr.
SNMP jest właśnie takim supertermometrem. Dzięki niemu, w jednym miejscu sieci (na stacji roboczej administratora) można zebrać informacje z kilkunastu miejsc reprezentowanych przez urządzenia sieciowe – routery, switche, komputery, a nawet drukarki. Mierzyć, czy raczej monitorować możemy praktycznie każdą własność danego urządzenia: liczbę aktualnie zalogowanych użytkowników, obciążenie pamięci, ilość wolnego miejsca na dysku twardym, temperaturę podzespołów lub prędkość przesyłania danych. Dodatkowo, z jednej stacji roboczej za pomocą SNMP możemy ustawić parametry urządzeń w całej sieci, wpływając zdalnie na ich konfigurację.
Jak działa SNMP?
Model SNMP oparty został o architekturę klient-serwer, której nazwę zmieniono na zarządca-agent. Jeden zarządca monitoruje od kilku do kilkuset agentów.
Agenci rezydują na każdym urządzeniu sieciowym (routerze, punkcie dostępowym, stacji roboczej czy nawet drukarce obsługującej SNMP) i tworzą bazę danych zwaną MIB (ang. Management Information Base). W bazie przechowywane są obiekty opisujące właściwości danego urządzenia. Na żądanie zarządcy, obiekty te są udostępniane, ujawniając informacje takie, jak np. temperatura procesora, ilość wolnego miejsca na dysku, bieżące obciążenie interfejsu sieciowego czy liczba aktualnie zalogowanych użytkowników.
Rys. 1 Topologia protokołu SNMP
Rolą zarządcy, oprócz odpytywania poszczególnych agentów, jest archiwizowanie informacji i przedstawianie ich w czytelnej formie administratorowi sieci, by ten mógł natychmiastowo podjąć odpowiednie działania.
Im bardziej rozbudowane oprogramowanie zarządcy, tym więcej funkcji może on pełnić. Z ciekawszych opcji warto wymienić wizualizacje topologii sieci, logiczne i fizyczne grupowanie urządzeń, analizę trendów, sporządzanie wykresów czy też szybkie wykrywanie anomalii i powiadamianie administratora za pomocą SMS.
Tryb „pułapka”
SNMP przewiduje także tryb pracy o nazwie pułapka (ang. trap). Pułapkę należy utożsamić z alarmem ustawionym na agencie. Jeśli jedna z monitorowanych wartości przekroczy zdefiniowany uprzednio próg (np. temperaturę krytyczną), agent bezzwłocznie powiadamia o tym fakcie zarządcę, nie czekając aż ten zgłosi się po kolejny odczyt danych.
Drzewo MIB
Nie ulega wątpliwości, że w całym tym procesie monitoringu i zarządzania, to właśnie baza danych agenta (MIB) jest najistotniejsza. Jest ona zarówno źródłem danych, jak i interfejsem umożliwiającym sterowanie urządzeniem.
Baza MIB ma strukturę drzewiastą. Liście drzewa są obiektami. Każdy z obiektów posiada swój unikalny identyfikator Object ID (OID), składający się z ciągu cyfr oddzielonych kropką (np. 1.3.6.1.2.1.1.1). OID reprezentuje unikalną ścieżkę na drzewie MIB.
Rys. 2 Przykładowe drzewo MIB
Ponieważ tego typu oznaczenie jest raczej ukłonem w stronę maszyny, a nie człowieka, każdy obiekt, można również zidentyfikować za pomocą jednoznacznej nazwy. Wspomniany wcześniej ciąg cyfr 1.3.6.1.2.1.1.1 identyfikuje nazwę sysDescr.
Świetnym narzędziem tłumaczącym OID na nazwy obiektów (i odwrotnie) jest SNMP Object Navigator, którego interfejs udostępniono na stronie http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en. Za pomocą tego narzędzia możesz również “przechadzać się” po poszczególnych gałęziach drzewa MIB, nie znając ani nazw, ani identyfikatorów obiektów.
Obiekty mają jeden z trzech rodzajów praw dostępu:
- read-only (RO) – tylko do odczytu,
- write-only (WO)- tylko do zapisu,
- read-write (RW) – do odczytu i zapisu.
Dostęp do obiektów wymaga również znajomości community-string, czyli łańcucha znaków, o którym możesz myśleć jak o haśle. Community-string przybiera różne wartości dla dostępu RO i RW. Domyślne ustawienia to odpowiednio public i private. Ze względów bezpieczeństwa zaleca się ich zmianę, ale z drugiej strony trzeba sobie zdawać sprawę, że community-string przesyłany jest przez sieć w postaci jawnego tekstu.
Dopiero wersja trzecia protokołu SNMP implementuje mechanizmy bezpieczeństwa. Niestety, rzadko kiedy spotyka się urządzenia z uruchomionym SNMPv3, nawet jeśli został on zaimplementowany przez producenta. Powodów można doszukiwać się w bardziej skomplikowanej konfiguracji agenta – administrator musi wygenerować i rozesłać klucze służące do szyfrowania i uwierzytelniania. Wiąże się to z ręczną konfiguracją każdego urządzenia z osobna.
Żądania i odpowiedzi SNMP przesyłane są na portach 161 i 162 za pomocą datagramów bezpołączeniowego protokołu UDP i połączeniowego protokołu TCP. Decydując się na implementację SNMP we wszystkich segmentach sieci, pamiętaj aby odpowiednio skonfigurować firmowy firewall.
Komunikaty SNMP
Prostota protokołu SNMP polega m.in. na sposobie komunikacji urządzeń sieciowych. Poniżej przedstawione zostały rodzaje komunikatów i zdarzeń rozsyłanych pomiędzy agentami i zarządcami:
- GetRequest – żądanie odczytania wartości obiektu z bazy MIB agenta, wysyłane przez zarządcę.
- GetNextRequest – żądanie podania kolejnego obiektu (w stosunku do ostatnio pobieranego) z bazy MIB agenta, wysyłane przez zarządcę. Wykorzystywane np. do odczytywania tablic.
- GetBulkRequest – zarządca prosi jednocześnie o kilka wartości z bazy MIB agenta (od wersji drugiej protokołu).
- SetRequest – żądanie zmiany w bazie MIB agenta.
- GetResponse – agent odpowiada na żądanie zarządcy. Datagram zawiera odczytaną wartość lub potwierdzenie wykonania zmiany w bazie w przypadku odpowiedzi na żądanie SetRequest.
- Trap – agent informuje zarządcę o pojawieniu się zdefiniowanego zdarzenia (pułapka).
- InformRequest – datagram z komunikatem trap, ale przesyłany pomiędzy dwoma różnymi stacjami zarządzania celem wymiany informacji (od wersji drugiej protokołu).
Rys. 3 Komunikaty protokołu SNMP
Wady protokołu SNMP
Warto podkreślić, że praktycznie każdy producent sprzętu sieciowego uznaje SNMP za standard i implementuje jego obsługę w swoich urządzeniach. Dzięki temu została zapewniona kompatybilność urządzeń sieciowych pochodzących od różnych producentów. Zwiększa to użyteczność protokołu, bo zamiast tracić czas na pisanie odpowiednich rozszerzeń konwertujących różne sposoby przesyłania wiadomości kontrolnych, całość po prostu działa. Nie należy także bagatelizować prostoty SNMP. Pozwala ona szybką wymianę danych i sprawia, że SNMP prawie w ogóle nie obciąża urządzenia, na którym pracuje.
Trzeba jednak przyznać, że prostota nigdy nie szła w parze z bezpieczeństwem. Reguła ta potwierdza się w przypadku SNMP. Najpopularniejsza i zarazem najprostsza wersja protokołu niestety jest podatna na szereg ataków. Intruz może stosunkowo łatwo przechwycić community-string, a następnie uwierzytelnić się za jego pomocą i całkowicie zmienić konfigurację monitorowanego urządzenia.
Konfiguracja SNMP
Powyższe akapity objaśniły podstawy protokołu SNMP niezbędne do jego implementacji. Czas zakasać rękawy i rozpocząć przystosowywanie swojej sieci do obsługi protokołu SNMP
Konfiguracja SNMP na urządzeniach sieciowych
Ponieważ wiele przedsiębiorstw, niezależnie od wielkości, buduje swoją sieć w oparciu o rozwiązania firmy Cisco, spróbujmy skonfigurować SNMP na routerze (czy też przełączniku) tej marki. Jeśli w sieci, którą się opiekujesz, działają urządzenia pochodzące od innego producenta, to z dużym prawdopodobieństwem również i one obsługują protokół SNMP. Dodatkowo, możesz liczyć, że popularność systemu operacyjnego Cisco IOS odcisnęła piętno także na sposobie ich konfiguracji.
Poniższy zestaw komend został tak dobrany, by możliwie jak najbardziej schematycznie potraktować zagadnienie i móc posłużyć jako wytyczne dla wszelkiej maści urządzeń sieciowych.
Warto wspomnieć, że większość routerów Cisco może odgrywać rolę zarówno zarządcy SNMP, jak i agenta. My zajmiemy się tylko drugim przypadkiem, głównie z powodu słabej dokumentacji dotyczącej wykorzystywania routera jako zarządcy, ale również ze względu na wyjątkowo niską jakość pracy z zarządcą w środowisku IOS.
Zacznijmy od skonfigurowania dostępu do routera poprzez protokół SNMP. Jak wiemy z wcześniejszej części hasła, jedynym parametrem wymaganym przy zestawianiu połączenia zarządca-agent jest community-string pełniący rolę hasła.
celt(config)#snmp-server community public ro
celt(config)#snmp-server community abrakadabra rw 50
celt(config)#access-list 50 permit 10.6.6.6
celt(config)#access-list 50 permit 10.6.6.7
Pierwsza z komend ustawia wartość community-string na “public” dla dostępu po SNMP w trybie RO (tylko dla odczytu). Druga komenda ogranicza dostęp do SNMP w trybie RW (odczyt-zapis) tylko do osób znających hasło “abrakadabra”, których adresy IP nie zostaną zablokowane przez listę dostępową (ang. Access Control List, ACL) o numerze 50.
Należy zdawać sobie sprawę z tego, że nawet po zastąpieniu domyślnej wartości łańcucha (“private”) skomplikowanym ciągiem znaków i tak będzie on przesyłany przez sieć w jawnej postaci. Stąd, tak ważne jest, abyś odpowiednio strzegł dostępu do trybu RW za pomocą mechanizmu ACL (choć i tu niestety, ewentualny intruz ma pewne pole do popisu – spoofing). Niezabezpieczony dostęp do trybu RW pozwala bowiem na całkowite przejęcie kontroli nad routerem.
Dociekliwy czytelnik zauważy, że do obsługi SNMP w całej sieci wystarczy jeden zarządca. Dlaczego więc pozwalamy na dostęp i drugiej maszynie? Powód jest prosty: w przypadku awarii jednej z maszyn, drugie stanowisko umożliwi nam bezproblemowe i nieprzerwane zarządzanie siecią. Dodatkowo, korzystając z możliwości protokołu SNMPv2, możemy tak ustawić obu zarządców, by jednocześnie sprawowali opiekę nad siecią i wymieniali między sobą pozyskane informacje. Kluczem do takiej konfiguracji jest obsługa wspomnianego wcześniej komunikatu InformRequest (wersje protokołu SNMP począwszy od drugiej).
Nic nie stoi na przeszkodzie, aby za pomocą ACL ograniczyć dostęp także do trybu RO. Dodatkowo, możesz zdefiniować widok (ang. view), który wprowadzi kolejne restrykcje dostępu do poszczególnych obiektów drzewa MIB.
celt(config)#snmp-server community prawiewszystko ro view bezRoutingu
celt(config)#snmp-server view noRouteTable internet included
celt(config)#snmp-server view noRouteTable ip.21 excluded
celt(config)#snmp-server view noRouteTable ip.22 excluded
celt(config)#snmp-server view noRouteTable ifMIB excluded
Router w powyższej konfiguracji nie udostępni odpytującemu informacji o tablicach routingu. Przez jednych może to być postrzegane jako restrykcja, inni mogą to odebrać jako ochronę zarządcy przed zalaniem go (zbyt) dużą ilością danych.
Pułapki – ustawianie parametrów do monitorowania
Po skonfigurowaniu bezpiecznego dostępu do urządzenia sieciowego, warto wdać się w głębsze dostrajanie działającego nań agenta. Prawdopodobnie jedyne, o czym teraz myślisz, to odpowiednie skonfigurowanie pułapek, czyli komunikatów trap. Właściwie, to nie możesz myśleć o niczym innym, bo SNMP to tak prosty protokół, że nie pozostało nam już praktycznie nic innego, niż zajęcie się pułapkami.
Przypomnijmy, że pułapka to komunikat wysyłany przez agenta działającego na urządzeniu sieciowym, informujący o zdefiniowanym problemie. Uruchamiamy obsługę pułapek na routerze:
celt(config)#snmp-server enable traps
Za pomocą poniższych komend włączysz tylko specjalnie zdefiniowane rodzaje pułapek:
snmp-server enable traps frame-relay
snmp-server enable traps envmon temperature
Aby komunikat o zdarzeniu został wysłany do zarządcy, router musi znać jego adres:
celt(config)#snmp-server host 10.6.6.6 jawnehaslo
Po wydaniu powyższej komendy, router rozpocznie przesyłanie komunikatów trap do zarządcy o numerze IP 10.6.6.6, uwierzytelniając się łańcuchem “jawnehaslo”. Możemy również rozsyłać pułapki do wielu zarządców, segregując je ze względu na typ:
celt(config)#snmp-server host 10.6.6.6 jawnehaslo snmp envmon
celt(config)#snmp-server host 10.6.6.7 jawnehaslo2 snmp bgp
Zgodnie z powyższym, pierwszy zarządca (10.6.6.6) otrzyma komunikaty dotyczące SNMP i ENVMON, a drugi odbierze komunikaty SNMP i BGP. Takie rozgraniczenie jest korzystne, jeśli siecią opiekuje się kilku administratorów, a każdy z nich specjalizuje się w innych zagadnieniach. Dodatkowo, powyższa metoda może pomóc przy sporządzaniu dziennika zdarzeń, trzymanego na innej maszynie.
Z pewnością najbardziej przydatną administratorowi pułapką jest config. Dzięki niej możesz monitorować kto i kiedy wprowadził zmiany w konfiguracji routera. Kolejnym rarytasem jest pułapka o nazwie syslog. Za jej pomocą możesz wymusić konwersję komunikatów o błędach (pokazujących się zwykle w konsoli) do formatu SNMP i przesyłanie ich do zarządcy. Przydatne zwłaszcza, jeśli nie masz możliwości uruchomienia osobnego serwera syslog w swojej sieci.
Niektóre sieci mają skomplikowaną budowę. Poniższe komendy pozwalają łatwiej odnaleźć się w gąszczu konfigurowanych urządzeń:
snmp-server contact Jan Kowalski, NetCorp, tel. 888123456
snmp-server location pok 303, Palac Kultury i Nauki, Warszawa
Wreszcie, aby zbadać, czy konfiguracja SNMP przynosi spodziewane rezultaty, użyj komendy show snmp, która pokaże wszystkie wiadomości na temat obsługi SNMP na Twoim routerze.
Konfiguracja SNMP na stacjach roboczych
SNMP nie należy utożsamiać wyłącznie z urządzeniami sieciowymi typu routery, switche, czy drukarki. Równie ważne pod względem monitoringu i zarządzania są zwykłe stacje robocze, często wyposażone w krytyczne dla firmy oprogramowanie.
Zacznijmy od skonfigurowania agentów na najpopularniejszym wśród użytkowników końcowych systemie operacyjnym – Windows XP. Konfiguracja usług SNMP na systemach Windows NT, 2000, czy 2003 Server jest analogiczna.
Microsoft Windows
Istnieje sporo niezależnych wersji agentów, które bez problemu dają się zainstalować na Windows XP. Wiele z nich przychodzi od razu w pakiecie z zarządcą. Jeśli jednak oprogramowanie SNMP używane w twojej sieci nie ma własnej wersji agenta, możesz rozważyć instalację domyślnej usługi systemowej Windows XP. Potrafi ona współpracować z zewnętrznymi zarządcami.
Aby zainstalować usługę SNMP, wykonaj następujące kroki:
- Przejdź do panelu sterowania.
- Kliknij ikonę Dodaj lub usuń programy.
- Wybierz Składniki systemu Windows z panelu po lewej stronie.
- Zaznacz Narzędzia zarządzania i monitorowania i kliknij Dalej.
Instalator poprosi o włożenie płyty instalacyjnej, a następnie skonfiguruje Windows do obsługi SNMP.
Rys. 4 Instalacja usługi agenta SNMP w Windows XP
Wszelkie parametry agenta SNMP można ustawić w konsoli services.msc. Aby się do niej dostać, otwórz Panel sterowania/Narzędzia administracyjne/Usługi. Odszukaj na liści i kliknij dwukrotnie pozycję Usługa SNMP.
Rys. 5 Konfiguracja usługi agenta SNMP w Windows XP
Najistotniejsze opcje znajdują się na zakładce Zabezpieczenia – to właśnie tam możesz zdefiniować community-string i listę komputerów, którym agent zezwoli na dostęp do konfiguracji i monitorowania systemu.
Szczegółowe wskazówki i zalecenia dotyczące konfiguracji SNMP w systemie Windows znaleźć można na stronie http://support.microsoft.com/kb/315154/pl
Przetestuj SNMP
Narzędzia z pakietu net-snmp implementują poszczególne komunikaty protokołów SNMPv1, SNMPv2 i SNMPv3. Za ich pomocą możesz przetestować konfigurację SNMP w Windows z linii polecenia. Zamiast zdobywać pojedyncze wartości obiektów przy użyciu snmpget.exe, odczytaj wszystkie obiekty z gałęzi systemowej, używając programu snmpwalk.exe.
Pakiet net-snmp dostępny jest zarówno dla systemów Windows jak i Linux. Możesz go pobrać ze strony http://net-snmp.sourceforge.net/.
Uruchom wiersz polecenia i wpisz poniższe komendy:
cd usr\bin
snmpwalk -Os -c public -v 1 127.0.0.1 system
Zwrócą one następujące wyniki:
sysDescr.0 = STRING: Hardware: x86 Family 15 Model 4 Stepping 10 AT/AT
COMPATIBLE – Software: Windows 2000 Version 5.1 (Build 2600
Uniprocessor Free)
sysObjectID.0 = OID: enterprises.311.1.1.3.1.1
sysUpTimeInstance = Timeticks: (10394776) 1 day, 4:52:27.76
sysContact.0 = STRING:
sysName.0 = STRING: CELT
sysLocation.0 = STRING:
sysServices.0 = INTEGER: 76
Aby przejrzeć (zapisując do pliku) całe drzewo MIB udostępniane przez agenta w systemie Windows XP, możesz wydać komendę:
snmpwalk -Os -c public -v 1 127.0.0.1 > drzewo.txt
GNU/Linux
Do obsługi SNMP na komputerach pracujących pod kontrolą systemu Linux potrzebujesz daemona snmpd. Jego instalacja różni się w zależności od dystrybucji Linuksa, z której korzysta twoja firma (przykładowo: apt-get install snmd w Debianie lub emerge snmpd w Gentoo). Warto od razu zainstalować narzędzia wchodzące w skład paczki snmp. Pozwolą one na wykonywanie podstawowych czynności diagnostycznych.
Zwróć uwagę, że daemon snmpd występuje w roli agenta SNMP, a nie serwera! Warto o tym pamiętać, gdyż konwencje nazw i zwyczaje panujące w systemach *niksowych w przypadku SNMP mogą wprowadzać w błąd.
Plik konfiguracyjny agenta SNMP to /etc/snmp/snmpd.conf – to właśnie tam możesz ograniczyć dostęp do agenta z zewnątrz, ustawić community-string, itd. Tak jak w przypadku Windows, po zainstalowaniu i wstępnych ustawieniach SNMP, zaleca się przeprowadzenie testów konfiguracji narzędziami z pakietu net-snmp.
Praktyczne wykorzystanie SNMP
Zainstalowaliśmy już agenty zarówno na urządzeniach sieciowych, jak i stacjach roboczych pracujących pod kontrolą Windows oraz Linuksa. Skonfigurowaliśmy odpowiednie community-string i ograniczyliśmy dostęp jedynie do zaufanej stacji administratora. Pora zacząć korzystać z udostępnianych danych!
MRTG – monitorowanie interfejsów sieciowych
MRTG (Multi Router Traffic Grapher) to darmowe oprogramowanie służące do monitorowania obciążenia łączy sieciowych, przedstawiające wyniki w postaci wykresu. Program został napisany w Perlu i działa zarówno w systemach Microsoftu, jak i plaftormach *niksowych. Pobierzesz go ze strony http://oss.oetiker.ch/mrtg.
MRTG, za pomocą protokołu SNMP, w równych odstępach czasu odpytuje agentów o wartości obiektów w drzewie MIB. Gromadzone dane przedstawia w postaci strony WWW zawierającej odpowiednie wykresy.
Konfiguracja MRTG jest prosta, i wygląda tak samo dla obu systemów operacyjnych. Wystarczy wskazać na agenta, uwierzytelnić się odpowiednim community-string i wyszczególnić, które z OID chcemy monitorować. Reszta odbywa się automatycznie.
1. Utwórz plik konfiguracyjny dla MRTG.
xerror@szynszyl:~# /usr/bin/cfgmaker \
–output=/etc/mrtg/celt_traffic.cfg \
–global “WorkDir: /var/www/localhost/htdocs/mrtg” \
–global “Options[_]: bits,growright” \
public@127.0.0.1
Jak widać, pliki zawierające dane zbierane przez MRTG znajdować będą się w katalogu /var/www/localhost/htdocs, a odpytywany agent pracuje na lokalnym komputerze (127.0.0.1). Uwierzytelnianie następuje za pomocą community-string ustawionego na public.
MRTG obsługuje język polski. Zmienną language w pliku konfiguracyjnym (tu: /etc/mrtg/celt_traffic.cfg) można ustawić na polish.
2. Utwórz strukturę strony WWW przedstawiającej wyniki.
xerror@szynszyl:~# indexmaker \
–output var/www/localhost/htdocs/mrtg/index.html \
/etc/mrtg/celt_traffic.cfg
3. Uruchom MRTG poleceniem
mrtg /etc/mrtg/celt_traffic.cfg
By zapewnić automatyczną aktualizację wykresów, poniższe polecenie warto dodać do crontaba:
xerror@szynszyl:~# crontab -e
*/5 * * * * /usr/bin/mrtg /etc/mrtg/celt_traffic.cfg
Dzięki temu MRTG będzie uaktualniał swoje dane co pięć minut.
Po chwili, MRTG powinien zebrać już dostatecznie dużo danych, by wygenerować czytelny wykres, dostępny pod adresem http://127.0.0.1/mrtg.
Rys. 6 Wykres obciążenia interfejsów wygenerowany przez program MRTG.
Oczywiście wcale nie musisz ograniczać MRTG do zbierania danych wyłącznie na temat obciążenia interfejsów. Równie dobrze możesz badać liczbę aktywnych użytkowników w sieci czy też liczbę użytkowników zalogowanych na router za pomocą SSH lub telnetu.
Rys. 7 Monitorowanie liczby użytkowników w sieci.
MRTG przewidziany został do użytku na maszynach z uruchomionym serwerem WWW (np. IIS w indows lub Apache do Linuksa). Dzięki temu, administrator ma dostęp do najświeższych wykresów z każdego miejsca w sieci, które pozwala na połączenie HTTP z komputerem z uruchomionym MRTG. Serwer HTTP nie jest jednak warunkiem koniecznym do pracy MRTG. Bez aktywnego serwera HTTP wykresy dalej będą generowane, jednakże dostęp do nich będzie można uzyskać tylko lokalnie.
Network Management Systems
MRTG to prosty przykład programu wykorzystującego protokół SNMP do monitorowania i analizy trendów w sieci. Nie ulega wątpliwości, że większe sieci potrzebują poważniejszych rozwiązań. Dlatego właśnie powstały rozbudowane aplikacje zarządzania siecią (Network Management Systems, NMS).
NMS, oprócz standardowych zadań monitoringu agentów, może zapewniać również tak zaawansowane funkcje, jak graficzne przedstawienie topologii sieciowej, automatyczne tworzenie dokumentacji i dziennika zdarzeń, generowanie zaawansowanych raportów, grupowanie logiczne i fizyczne urządzeń sieciowych, możliwość długofalowego planowania strategii rozwoju sieci, analizowanie trendów i ryzyka.
Mówiąc o NMS-ach, grzechem byłoby nie wspomnieć o takim oprogramowaniu, jak Tivoli (IBM), MOM (Microsoft) czy OpenView (Hewlett-Packard). Są to potężne kombajny, opierające swoje funkcje nie tylko na protokole SNMP, ale również na szeregu innych źródłach danych o sieci. Wdrożenia w/w systemów zazwyczaj są jeszcze droższe od wykupienia samej licencji, stąd pozwolić na nie mogą sobie przeważnie firmy z potężnie rozwiniętymi sieciami, międzynarodowe korporacje lub banki, w których monitoring i zarządzanie odgrywa istotną rolę.
Niestety, jedną z wad systemów monitoringu sieci jest ich prawie całkowita niekompatybilność. Większość z NMS-ów to naprawdę rozbudowane i zaawansowane aplikacje, które nierzadko wprowadzają swój własny pseudojęzyk służący do konfiguracji środowiska monitoringu.
Jeśli jednak pracujesz w średniej wielkości firmie, nie załamuj się. Istnieje kilka mocno rozbudowanych aplikacji, za które wcale nie musisz płacić! Poniżej wymieniamy najważniejsze z nich, okraszone tylko krótkim opisem, gdyż systemy te nie polegają wyłącznie na protokole SNMP, a więc wykraczają poza ramy tego artykułu.
OpenNMS
OpenNMS (www.opennms.org/index.php/Main_Page) jest próbą stworzenia otwartego i darmowego systemu zarządzania siecią, który byłby konkurencyjny w stosunku do znanych, komercyjnych rozwiązań, takich jak Tivoli czy OpenView. OpenNMS pozwala między innymi na logowanie zdarzeń z kilkunastu urządzeń, rozproszone monitorowanie sieci i zarządzanie wszelkiego rodzaju operacjami konserwacyjnymi. Informacje o konfiguracji OpenNMS znajdziesz na stronie www.howtoforge.com/opennms_network_management.
BigSister
Rozbudowany system zarządzania siecią, monitorujący pracę węzłów i raportujący awarie. Obsługuje SNMP, potrafi monitorować bazy danych Oracle, serwery DNS, serwery Radius i wiele innych protokołów. BigSister tworzy rozbudowane raporty, stara się być kompatybilny z wieloma innymi programami, co ważniejsze, obsługuje wtyczki i udostępniany jest w wersji zarówno do Windows jak i systemów *niksowych. BigSister to dojrzały NMS, zdecydowanie warty przetestowania. Możesz go pobrać ze strony www.bigsister.ch.
Nagios
Hasłem przewodnim Nagiosa jest “informowanie Cię o problemach w sieci, zanim zostaniesz o nich poinformowany przez użytkowników”. Program pracuje pod kontrolą Linuksa, nieustannie monitorując usługi działające na poszczególnych węzłach sieci. Administrator ma do dyspozycji całkiem elastyczny mechanizm wtyczek oraz świetne możliwości alarmowania o problemach (e-mail, SMS, komunikator internetowy). Dodatkowo, Nagios udostępnia większość zbieranych przez siebie danych w postaci strony internetowej, która może być dostępna z każdego miejsca w sieci. Program dostępny na stronie www.nagios.org.
The Dude
Działający pod kontrolą systemu Windows The Dude to prawdziwa perełka. Oprócz standardowych prac związanych z monitorowaniem i zarządzaniem urządzeniami sieciowymi, potrafi wykryć i rozrysować topologię sieci. Współpracuje z mapami. The Dude jest naprawdę prosty i przyjemny w użyciu, co nie zawsze jest regułą w systemach zarządzania siecią! Program do pobrania ze strony www.mikrotik.com/thedude.php.
Oprócz znanych na świecie zagranicznych systemów zarządzania siecią, warto bliżej przyjrzeć się rodzimej produkcji – systemowi David (www.david.lodz.pl), który od blisko siedmiu lat wspomaga pracę Centrum Komputerowego Politechniki Łódzkiej, zarządzając pracą sieci LODMAN i POL34.
Przyszłość SNMP
Wersja trzecia protokołu SNMP nie odniosła zbyt wielkiego sukcesu, nawet pomimo powszechnego zrozumienia i akceptacji dla wprowadzonych mechanizmów bezpieczeństwa. Wygląda na to, że prostota prawie dwudziestoletniej koncepcji SNMPv1 jest nie do pobicia i skutecznie wrosła już w umysły niezbyt skorych do zmian administratorów sieci.
Nie należy jednak zapominać, że każdy może kształtować przyszłość SNMP – jeśli nie w skali światowej, to chociaż na prywatnym podwórku… SNMP API (ang. Application Program Interface) powstało już prawie dla każdego języka. Z ważniejszych warto wymienić netsnmpj dla Javy (http://netsnmpj.sourceforge.net) i Net::SNMP dla Perla (http://search.cpan.org/dist/Net-SNMP).
Jakby tego było mało, do realizacji własnych pomysłów można posłużyć się gotowymi implementacjami SNMP, chociażby ze wspomnianego już pakietu net-snmp. W końcu jedną z najważniejszych cech dobrego administratora sieci jest zdolność powiększania swojego czasu wolnego poprzez udoskonalanie narzędzi sieciowych!
Alternatywy dla SNMP
Jak wielokrotnie podkreślaliśmy w tym artykule, SNMP jest podstawowym i najprostszym sposobem zbierania informacji o pracy sieci, zwłaszcza tych nieskomplikowanych. Jeśli na co dzień zmagasz się z siecią o dużym natężeniu ruchu, a interesują Cię głównie statystyki ilościowe dotyczące IP, warto byś zapoznał się z protokołem NetFlow (www.cisco.com/go/netflow). Jest to alternatywa dla SNMP, stworzona specjalnie na potrzeby rozbudowanych sieci komputerowych zbudowanych na urządzeniach Cisco.
