AGENT SNMP DLA URZĄDZENIA NetmasterLE

Transkrypt

1 Janusz Kleban Instytut Elektroniki i Telekomunikacji Politechnika Poznańska Maciej Obarski mobarski@gmail.com Activis Polska sp z o.o Poznańskie Warsztaty Telekomunikacyjne Poznańskie Warsztaty Telekomunikacyjne Poznań 8-9 grudnia 2005 AGENT SNMP DLA URZĄDZENIA NetmasterLE Streszczenie: W pracy przedstawiono proces tworzenia oraz wdrażania agenta SNMP dla urządzenia NetmasterLE, zaprojektowanego przez firmę Activis Polska. Zamieszczono wiele uwag praktycznych wynikających z doświadczeń zdobytych podczas uruchamiania i wdrażania agenta SNMP. Zwrócono również uwagę na ograniczenia w tworzeniu oprogramowania dla środowiska systemu wbudowanego. Przygotowane oprogramowanie współpracuje z komercyjnie dostępnymi systemami do zarządzania sieciami np. HP Open View. 1. WSTĘP Wzrost złożoności sieci telekomunikacyjnych i komputerowych już od dawna implikuje konieczność wprowadzenia systemów zarządzania, umożliwiających zdalny nadzór nad pracą sieci, skracających czas reakcji na awarie, a także ułatwiających oferowanie nowych usług. Konieczna staje się automatyzacja procesu zarządzania siecią i usługami oraz integracja systemów zarządzania np. dostarczanych razem ze sprzętem. Automatyzacja procesu zarządzania nie jest możliwa bez przyjęcia ogólnoświatowych standardów opracowywanych w ramach ISO i ITU-T. W niniejszym artykule skupimy się na zarządzaniu sieciami opartymi na grupie protokołów TCP/IP, stąd problemy związane z zarządzaniem sieciami telekomunikacyjnymi zostaną pominięte. Na potrzeby zarządzania urządzenia sieciowe dzieli się na: obiekty zarządzane, wyposażone w oprogramowanie zwane agentami systemu zarządzania, oraz obiekty zarządzające, wyposażone w oprogramowanie nazywane stacjami zarządzania siecią NMS (ang. Network Management Station). Architektura systemu zarządzania oparta na takim modelu nosi nazwę architektury zarządca agent. Aby agent mógł wymieniać informacje z zarządcą, obie jednostki muszą porozumiewać się używając identycznego schematu komunikacji zwanego protokołem. Najbardziej rozpowszechnionym protokołem zarządzania sieciami jest SNMP (ang. Simple Network Management Protocol) [1, 2]. Protokół ten definiuje komunikaty, które agent wymienia z zarządcą oraz metodę, za pomocą której obie strony wskazują, o który zasób chodzi. W protokole SNMP zarządca i agent przeprowadzają operacje na reprezentacji zarządzanych zasobów zgromadzonych w bazie MIB (ang. Management Information Base) [3]. Baza MIB opisywana jest najczęściej za pomocą notacji ASN.1, która określa budowę bazy w sposób abstrakcyjny, niezależny od implementacji i wewnętrznej reprezentacji danych. Notacja ASN.1 jest stosowana także do określania komunikatów wymienianych w ramach protokołu SNMP. W przeciwieństwie do opisu bazy MIB, definiowanie wymienianych komunikatów wymaga oprócz abstrakcyjnego opisu danych określenia sposobu kodowania i dekodowania informacji. Protokół SNMP posługuje się w tym celu kodowaniem BER (ang. Basic Encoding Rules) [4], które jest zbiorem reguł zamiany obiektów z notacji ASN.1 na postać binarną. Często zarządza się urządzeniami, które mają bardzo ograniczone zasoby sprzętowe np. szybkość procesora i pojemność pamięci nie są wystarczające do uruchomienia systemu operacyjnego ogólnego przeznaczenia. Posiadają one system operacyjny spełniający tylko podstawowe funkcje, takie jak przełączanie procesora pomiędzy wykonywaniem kilku programów i zapewnienie komunikacji pomiędzy procesami. Systemy takie, w połączeniu z oprogramowaniem realizującym wszystkie funkcje urządzenia, nazywa się systemami wbudowanymi (ang. embedded systems). Tworzenie oprogramowania dla systemów wbudowanych jest zwykle większym wyzwaniem niż tworzenie oprogramowania dla komputerów klasy PC. Systemy te projektuje się tak, aby zminimalizować koszt sprzętu, na którym będą działać. Często nie mają one dostępu do napędu dyskowego, systemu plików i jakiegokolwiek interfejsu użytkownika. Urządzenia z systemami wbudowanymi zazwyczaj muszą pracować bez przerwy przez wiele lat. Aby było to możliwe, system taki musi nadzorować poprawność wykonywania wielu czynności i jeśli jest to konieczne, wymusić zerowanie i ponowny start oprogramowania. Kolejnym utrudnieniem jest częsty brak zgodności systemu wbudowanego ze standardem POSIX (ang. Portable Operating System Interface) co bardzo komplikuje wykorzystanie powszechnie dostępnych bibliotek z otwartym kodem źródłowym. W dalszej części artykułu przedstawiono główne problemy dotyczące tworzenia i implementacji agenta SNMP i bazy MIB dla urządzenia NetmasterLE firmy Activis Polska sp. z o.o. 2. PROTOKÓŁ SNMP Protokół SNMPv1 jest protokołem bezstanowym, w którym zarządca wykonuje operacje na bazie MIB PWT POZNAŃ 8-9 GRUDNIA /5

2 agenta otrzymując informacje zwrotne. Zarządca posługując się trzema rodzajami komunikatów: Get, Get-Next i Set. Komunikat Get pobiera z bazy MIB adresy oraz wartości wskazane przez zarządce. Komunikat Get-Next powoduje pobranie z bazy MIB adresów oraz wartości obiektów następnych w stosunku do tych, które zostały podane przez zarządce. Komunikat Set na podstawie informacji o adresach i wartościach podanych przez zarządcę zmienia wartości obiektów w bazie MIB. Odpowiedź na komunikaty zarządcy agent SNMPv1 przesyła w komunikatach Get- Response. Agent może poinformować zarządcę o zdarzeniu wysyłając wiadomość Trap. Ramka SNMP zbudowana jest z wartości zakodowanych zgodnie z regułami BER. Pola komunikatu są ułożone w następującej kolejności: numer wersji protokołu SNMP, nazwa grupy zarządcy (ang. community), typ wiadomości SNMP, identyfikator żądania, status błędu, pozycja błędu, zapytanie. Powyższa kolejność nie dotyczy komunikatów Trap, które ze względu na swój charakter (komunikaty wysyłane z inicjatywy agenta) muszą zawierać inne informacje. Komunikat Trap zawiera następujące pola: numer wersji protokołu SNMP, nazwa grupy, identyfikator urządzenia w gałęzi enterprise, adres sieciowy, ogólny numer wiadomości Trap, szczegółowy numer wiadomości Trap, znacznik czasowy, sekwencja pomocnych zmiennych i wartości. Ramka protokołu SNMPv1 opisana jest według notacji ASN.1 w dokumencie RFC-1157 [2]. 3. URZĄDZENIE NETMASTER NetmasterLE jest multiplekserem dostępowym wyposażonym w dwa interfejsy E1 oraz jeden interfejs Ethernet 10/100. Typowym zastosowaniem tego urządzenia jest przesyłanie ramek Ethernet'u poprzez trakty E1 oraz komutacja szczelin traktów E1. Urządzenie to posiada wbudowany system czasu rzeczywistego realizujący architekturę mikrokernela, w której procesy komunikują się wymieniając komunikaty w pamięci współdzielonej. System ten bardzo sprawnie wykorzystuje dostępne zasoby sprzętowe jednak posiada szereg ograniczeń, które utrudniają proces wytwarzania oprogramowania: Brak dynamicznego zarządzania pamięcią. Brak funkcji realizujących dynamiczną alokację pamięci oraz dynamiczną dealokację. Utrudnia to nieco projektowanie systemu ze względu na konieczność alokowania zasobów zanim będą one potrzebne. Brak standardowego wyjścia. Nie ma prostej metody przekazywania informacji zwrotnych, co utrudnia proces testowania. Długi proces kompilacji i uruchomienia. Kompilacja i przeniesienie oprogramowania na urządzenie trwa około pięciu minut. Tak długi cykl uruchomieniowy utrudnia strategię bardzo częstego testowania. Trudna separacja programu od otoczenia. Program agenta SNMP jest jednym z blisko czterdziestu procesów tworzących oprogramowanie urządzenia. Oznacza to utrudnioną analizę w przypadku wykrycia błędu, gdyż nie można wykluczyć, iż źródłem błędu jest inny proces. Brak zgodności ze standardem POSIX. W projekcie nie można było zastosować bibliotek oprogramowania z otwartym kodem źródłowym, gdyż większość z nich wymaga systemu kompatybilnego z tym standardem. 4. MODEL AGENTA SNMP Model agenta SNMP przedstawiono opisując jego funkcje w architekturze trójwarstwowej, w której wyróżniono następujące warstwy: danych, sterowania i prezentacji. Reprezentacja ta jest najczęściej używana do modelowania aplikacji sieciowych, w których klientem jest przeglądarka internetowa, jednak elastyczność tego modelu sprawia, że doskonale nadaje się on do przedstawiania agentów systemów zarządzania. Warstwa prezentacji Zadaniem warstwy prezentacji jest tłumaczenie danych z postaci transportowej na łatwiejszą do przetwarzania reprezentację wewnętrzną, oraz z reprezentacji wewnętrznej na postać transportową. Funkcję tę w oprogramowaniu agenta SNMP pełni moduł kodera i dekodera BER. Po otrzymaniu na wejściu zawartości datagramu odebranego przez port 161 dekoder przystępuje do sekwencyjnego odczytywania danych i dopasowywania ich do wzorców określających postać komunikatu SNMP. Jeśli komunikat zostanie pomyślnie zdekodowany to zostają wywołane odpowiednie procedury warstwy sterowania. W przeciwnym razie operacja dekodowania zostanie przerwana, a dekoder powraca do stanu oczekiwania na zgłoszenia nie wysyłając żadnej odpowiedzi (zgodnie z zaleceniem RFC). Koder BER na wejściu otrzymuje wartość (w reprezentacji wewnętrznej) oraz typ, według którego wartość ta ma zostać zakodowana. Przestrzegając reguł BER koder zapisuje postać transportową wartości jako ciąg oktetów dopisywanych do końca strumienia wyjściowego. Podczas wykonywania tej operacji uaktualniany jest wskaźnik bieżącej pozycji w strumieniu wyjściowym. Warstwa sterowania Zadaniem warstwy sterowania jest pośredniczenie pomiędzy warstwą danych, a warstwą prezentacji w celu nadzorowania procesu komunikacji pomiędzy agentem a zarządcą. Zadania warstwy sterowania podczas odbierania wiadomości od zarządcy są następujące: sprawdzanie poprawności identyfikatorów obiektów, sprawdzanie uprawnień, tłumaczenie identyfikatorów obiektów (OID) na adresy węzłów drzewa MIB, wyszukiwanie węzłów "następnych", przeprowadzanie operacji pobierania / ustawiania wartości z warstwy danych, sterowanie warstwą prezentacji podczas budowania odpowiedzi. Zadania warstwy sterowania podczas odbierania wiadomości od systemu: decydowanie czy wiadomość należy wysłać, PWT POZNAŃ 8-9 GRUDNIA /5

3 określenie adresu zarządcy, sterowanie warstwą prezentacji podczas budowania wiadomości. Warstwa danych Zadaniem warstwy danych jest dostarczanie informacji warstwie sterowania oraz zapamiętywanie danych przysłanych przez tę warstwę. W oprogramowaniu agenta SNMP warstwa ta nie jest typową bazą danych, gdyż większość rekordów nie jest przechowywana w pamięci. Gdy warstwa danych ma dostarczyć warstwie sterowania informacje dotyczące stanu urządzenia, wywoływana jest funkcja systemowa, która analizuje stan urządzenia i zwraca niezbędne informacje. Informacje te są tłumaczone do postaci przewidzianej w opisie bazy MIB i następnie przekazywane do warstwy sterowania. 5. STRUKTURA BAZY MIB DLA NetmasterLE Baza MIB urządzenia NetmasterLE, składa się z wybranych, typowych gałęzi drzewa MIB realizujących podstawowe funkcje umożliwiające zarządzanie urządzeniem oraz z gałęzi ActivisLE, która realizuje funkcje zarządzania specyficzne dla tego urządzenia. Gałęzie wymagane do poprawnej pracy z najbardziej popularnymi platformami NMS są następujące [3]: System - w gałęzi tej są przechowywane obiekty z podstawowymi informacjami dotyczącymi urządzenia. Implementacja tych obiektów polega na utworzeniu zmiennych przechowujących nadane wartości i zwracających je na żądanie. Implementacja obiektu systime powinna odwoływać się do funkcji systemu operacyjnego. Interfaces - gałąź zawiera informacje dotyczące interfejsów komunikacyjnych. Każdy interfejs sieciowy urządzenia musi posiadać swój odpowiednik w bazie MIB, aby umożliwić zarządcy nadzorowanie wszystkich możliwych dróg komunikacji. At (Adress Translation) - gałąź zawiera informacje dotyczące adresów fizycznych interfejsów sieciowych, których znajomość jest niezbędna do diagnozowania problemów z niższymi warstwami sieci. IfMib - obiekt IfMib zawiera informacje dodatkowe o interfejsach sieciowych. Znaczną część tej gałęzi stanowią liczniki 64-bitowe, które zostały wprowadzone, aby zmniejszyć częstotliwość przekroczenia zakresu liczników interfejsów o dużej szybkości. Ze względu na ograniczone możliwości systemów wbudowanych, liczniki te mają zakres 32- bitowy. Powodowane jest to koniecznością unikania arytmetyki 64-bitowej w kodzie stosu IP, jeśli platforma sprzętowa nie potrafi wydajnie realizować takiej operacji. Gałąź ta musi jednak znajdować się w bazie MIB, gdyż część dostępnego na rynku oprogramowania zarządzania sieciami łączy pytania dotyczące gałęzi If z pytaniami dotyczącymi gałęzi IfMib [5]. W systemie zostały również zaimplementowane trzy gałęzie drzewa SNMP choć nie są one niezbędne do prawidłowej pracy systemu: SNMP - gałąź gromadzi obiekty reprezentujące stan oprogramowania agenta SNMP. Choć jej zastosowanie może wydawać się ograniczone to jednak stanowi bardzo silne narzędzie w diagnozowaniu problemów komunikacji z agentem, oraz współpracy agenta z oprogramowaniem zarządzającym. Wszystkie obiekty gałęzi SNMP realizowane są jako funkcje zwracające stan liczników wewnętrznych oprogramowania agenta. Transmission - gałąź zawiera szczegółowe informacje dotyczące parametrów transmisyjnych. Obiekty w tej gałęzi podzielone są na grupy odpowiadające różnym rodzajom interfejsów. Realizacja funkcji tych obiektów polega na pobraniu odpowiedniej informacji za pomocą funkcji modułu utrzymania. ActivisLE - obiekt ActivisLE i wszystkie obiekty podrzędne zostały zaprojektowane tak, aby udostępnić za pomocą protokołu SNMP określone informacje dla systemu zarządzania urządzeniem NetmasterLE. Obiekt ActivisLE znajduje się w gałęzi Enterprise.Activis i składa się z następujących obiektów potomnych: - alcurtable - tabela zawierająca informacje dotyczące aktywnych alarmów; - alcurentry - pojedynczy wpis odnoszący się do jednego aktywnego alarmu; - alcurtime - czas zgłoszenia alarmu wyrażony w wartości systime, gdy zdarzenie to miało miejsce; - alcurnumber - numer zgłoszonego alarmu; - alcuriftype - typ interfejsu związanego z alarmem; - alcurdevice - numer urządzenia związanego z alarmem (dotyczy urządzeń o budowie modułowej); - alcurcard - numer karty związanej z alarmem (dotyczy urządzeń o budowie modułowej); - alhistable - tabela zawierająca informacje związane z historią zarejestrowanych informacji alarmowych; tabela ta zawiera informacje zarówno o włączeniu, jak i o wyłączeniu alarmów; - alhisentry - pojedynczy wpis w tabeli historii alarmów odnoszący się do jednego zgłoszenia związanego z komunikatami alarmowymi; - alhisindex - numer porządkowy komunikatu alarmowego; - alhistime - czas zgłoszenia alarmu wyrażony w wartości systime, gdy zdarzenie to miało miejsce; - alhisnumber - numer zgłoszonego alarmu; - alhisiftype - typ interfejsu związanego z alarmem; alhisdevice - numer urządzenia związanego z alarmem (dotyczy urządzeń o budowie modułowej); alhiscard - numer karty związanej z alarmem (dotyczy urządzeń o budowie modułowej); PWT POZNAŃ 8-9 GRUDNIA /5

4 alhisstate - zgłoszony stan alarmu. 6. IMPLEMENTACJA BAZY MIB Oprogramowanie, którego celem jest realizowanie funkcji zarządzania poprzez protokół SNMPv1 musi posiadać przynajmniej dwa moduły: moduł agenta oraz moduł bazy MIB. Podział taki wynika z założeń protokołu, które definiują SNMP jako protokół dostępu do bazy MIB, która może istnieć niezależnie od oprogramowania agenta. Obiekt MIB jest najważniejszą strukturą danych występującą w oprogramowaniu agenta SNMP. Zadaniem tej struktury jest reprezentowanie zarządzanego zasobu, lub grupy zasobów tak, aby zmiana obiektu bazy znalazła odzwierciedlenie w zarządzanym obiekcie i na odwrót. Obiekty tej struktury muszą tworzyć drzewo, będące odwzorowaniem opisanego drzewa MIB urządzenia. Do poprawnej pracy systemu oprócz deklaracji węzłów MIB potrzeba również funkcji działających na tych obiektach, które będą stanowiły interfejs pomiędzy warstwą danych a warstwą sterowania. Interfejs ten musi umożliwiać wykonanie następujących operacji na zbiorze węzłów drzewa MIB: zlokalizowanie obiektu podrzędnego, zlokalizowanie obiektu następnego w stosunku do podanego, zlokalizowanie obiektu na podstawie podanego adresu domenowego, sprawdzenie poprawności rozkazu względem podanego obiektu. Proces tworzenia oprogramowania związanego z bazą MIB składa się z kilku faz. Na początku należy stworzyć kompletny opis bazy MIB urządzenia w notacji ASN.1 zgodnie z odpowiednim zaleceniem RFC. Opis ten poddawany jest translacji, która zamienia notację ASN.1 na definicje obiektów i definicje funkcji w języku C. Część powstałych w ten sposób definicji funkcji jest pusta i wymaga uzupełniania tak, aby funkcje obiektów bazy MIB odpowiadały funkcjom zarządzanych obiektów. Innymi słowy: należy zapewnić prawidłową reakcję zarządzanego obiektu na zmianę jego reprezentacji w bazie MIB, oraz odwrotnie: prawidłową reakcję reprezentacji obiektu na zmianę w zarządzanym obiekcie. Po dodaniu tych funkcji można już połączyć definicje bazy MIB w języku C z kodem agenta SNMP. Najtrudniejszą z wyżej wymienionych faz jest faza tłumaczenia notacji ASN.1 do C, która przebiega w czterech etapach: analizy leksykalnej, analizy gramatycznej i tworzenia drzewa obiektów, przeliczenia drzewa obiektów oraz tworzenia kodu na podstawie drzewa obiektów. Podczas analizy leksykalnej sprawdzana jest poprawność budowy pojedynczych "słów" (ang. Token) języka ASN.1, a podczas analizy gramatycznej poprawność całych "zdań". Jeśli opis MIB jest prawidłowy to tworzone są obiekty języka Ruby [6] reprezentujące obiekty drzewa MIB. Po utworzeniu całego drzewa obiektów niezbędne jest przeliczenie wartości pól związanych z hierarchią drzewa MIB. Przeliczanie to odbywa się zgodnie z algorytmem przeszukiwania w głąb DFS (ang. Depth First Search), zgodnie z którym kolejność przeliczania wynika z rekurencyjnego wywoływania procedury na wszystkich obiektach potomnych. Na podstawie drzewa obiektów tworzony jest kod deklarujący zmienne, incjalizujący wartości struktur oraz, jeśli jest to potrzebne, generujący deklaracje funkcji związanych z obiektem. Ze względu na limitowane zasoby systemów wbudowanych baza MIB agenta powinna posiadać możliwie najmniej węzłów. Większość zdefiniowanych węzłów nie jest niezbędna do prawidłowej współpracy agenta z zarządcą, jednak istnieją takie, które muszą być obecne w bazie MIB, aby oprogramowanie NMS mogło skutecznie zarządzać urządzeniem. Główną przyczyną takiego stanu rzeczy jest zastosowane w SNMPv1 podejście wszystko albo nic. W praktyce oznacza to, iż baza MIB agenta musi zawierać wszystkie obiekty, które NMS może wymienić w typowych komunikatach. Jeśli baza MIB agenta nie zawiera choćby jednego obiektu, o którym mowa w przychodzącym komunikacie, to wiadomość zostanie zwrócona z informacją o błędzie. Część oprogramowania NMS rozumie ten aspekt protokołu SNMPv1 i po otrzymaniu komunikatu informującym o braku obiektu w bazie MIB ponowi wysłanie żądania dzieląc je na mniejsze części, aby zwiększyć prawdopodobieństwo uzyskania odpowiedzi. Niektóre programy zarządzające siecią nie uwzględniają tej różnicy pomiędzy protokołami SNMPv1 i SNMPv2, przez co pewne gałęzie drzewa MIB mogą nie być dla nich widoczne. 7. IMPLEMENTACJA AGENTA Proces tworzenia agenta uwzględniał powstanie fragmentów systemu w następującej kolejności: dekoder BER, koder BER, dekoder wiadomości SNMPv1, koder wiadomości SNMPv1, procedura głównej pętli oprogramowania agenta, struktura reprezentująca obiekt drzewa MIB, procedury sprawdzania poprawności wiadomości, funkcje działające na strukturze reprezentującej obiekt drzewa MIB (z pominięciem funkcji Get-Next ), analizator leksykalny ASN.1, analizator gramatyczny ASN.1, moduł tworzący drzewo obiektów języka Ruby na podstawie ASN.1, generator kodu C, procedury obiektów MIB niezależnych od platformy sprzętowej, realizacja funkcji Get-Next, zależne od platformy sprzętowej procedury obiektów ze standardowych gałęzi drzewa MIB, moduł komunikacji za pośrednictwem UDP, opis bazy MIB urządzenia w notacji ASN.1 (z pominięciem wiadomości Trap ), procedury obiektów drzewa MIB specyficzne dla urządzenia NetmasterLE, moduł wysyłania wiadomości Trap, opis wiadomości Trap specyficznych dla urządzenia NetmasterLE oraz interfejs programowy do wysyłania wiadomości Trap. Już we wczesnym etapie realizacji projektu powstała potrzeba testowania kodu, stąd została stworzona biblioteka języka C zawierająca funkcje wspomagające proces automatycznego testowania. Biblioteka ta została następnie zastosowana do wykrywania usterek w oprogramowaniu na długo przed ostatecznym scaleniem systemu. Dla najważniejszych PWT POZNAŃ 8-9 GRUDNIA /5

5 fragmentów systemu powstał zestaw testów, dzięki któremu możliwe stało się bardzo szybkie wykrywanie błędów powstałych podczas scalania modułów i nanoszenia poprawek. Największym problemem podczas tworzenia systemu było znalezienie algorytmu przeglądania drzewa MIB, który zapewniałby efektywną współpracę z istniejącym już modułem oprogramowania odpowiedzialnym za nadzór urządzenia. Istotą problemu była różnica w sposobie adresowania tabel z danymi i dostępu do nich. W bazie MIB wiersze tabeli mogą znajdować się pod dowolnym adresem i istnieje możliwość adresowania kolumn. Moduł zarządzania przewidywał tylko adresowanie indeksem całkowitym i wymagał pobierania całych wierszy, bez możliwości wyboru kolumny. Rozwiązanie problemu wymagało stworzenia pamięci podręcznej odpowiedzi modułu zarządzania, dzięki czemu adresowanie kolumn stało się efektywne i nie wymagało wielokrotnych zapytań skierowanych do modułu zarządzania. Problem dynamicznego adresowania rozwiązano stosując pobieranie par rekordów, tak aby zawsze można było sprawdzić dane z następnego wiersza. Aby powstałe oprogramowanie mogło zostać dołączone do zbioru programów urządzenia NetmasterLE musiało przejść przez szereg testów. Aby ograniczyć utrudnienia związane z testowaniem, program agenta SNMP został zaprojektowany i wykonany w ten sposób, aby mógł zostać uruchomiony w środowisku systemu Linux. Możliwość uruchomienia agenta na bardziej przyjaznej platformie sprawiła, iż testowanie przebiegało sprawnie i szybko, co umożliwiło zastosowanie strategii bardzo częstego testowania. Testy zostały podzielone na dwie kategorie: testy niezawodności, których zadaniem było znalezienie jak największej liczby usterek powodujących nieprawidłową pracę systemu, testy kompatybilności, których zadaniem było znalezienie błędów podczas współpracy z oprogramowaniem zarządców. Testy niezawodności polegały na sprawdzaniu pracy systemu pod dużym obciążeniem i monitorowaniu stopnia wykorzystania zasobów oraz wykrywaniu błędnych zachowań. Testy kompatybilności polegały na wydawaniu agentowi rozkazów za pomocą wielu różnych wersji oprogramowania zarządzającego, notowaniu ewentualnych błędów i nanoszeniu poprawek. W ramach testów kompatybilności sprawdzono pracę agenta z następującym oprogramowaniem: NetInspector firmy MG-SOFT, Monitor One firmy FineConnection, OpenView firmy Hewlett-Packard, SNMP Trap Watcher firmy BTT, Net- SNMP (program z otwartym kodem źródłowym), Scotty (program z otwartym kodem źródłowym), Getif (darmowy program z zamkniętym kodem źródłowym). Sprawdzone zostały następujące aspekty współpracy: proces kompilacji opisu bazy MIB, kodowanie i dekodowanie wiadomości, adresowanie obiektów drzewa MIB, przeglądanie drzewa MIB, obsługę wiadomości Trap, obsługę błędów, wydajność. Mimo przestrzegania zaleceń RFC wystąpiły kłopoty we współpracy z oprogramowaniem HP: OpenView. Po wnikliwej analizie okazało się, że problem wynika z odwoływania się do obiektów bazy MIB, które nie są wspomniane w podstawowej definicji bazy MIB, co w połączeniu z regułą wszystko albo nic protokołu SNMPv1 prowadziło do odrzucania większości wiadomości. Niezbędne poprawki zostały wprowadzone do implementacji bazy MIB, dzięki czemu oprogramowanie agenta prawidłowo współpracuje z programem HP: OpenView. Proces testowania zakończył się, gdy uzyskano wystarczającą pewność, że agent poprawnie współpracuje z istniejącym oprogramowaniem zarządzania i, że jego działanie nie stanowi zagrożenia dla poprawnej pracy urządzenia NetmasterLE. 8. UWAGI KOŃCOWE Zaproponowana architektura agenta SNMP okazała się bardzo elastyczna - zaimplementowany system działa na dwóch, bardzo różnych platformach: systemie Linux (system operacyjny ogólnego przeznaczenia), oraz systemie BOSS (wbudowany system czasu rzeczywistego). Początkowo baza MIB obejmowała tylko jedno urządzenie (multiplekser dostępowy NetmasterLE), jednak z czasem została rozbudowana o dwa kolejne, przy minimalnym nakładzie kosztów związanych z modyfikacją kodu. System został zaprojektowany i zaimplementowany z myślą o niezawodnej pracy dzięki czemu po około roku od wdrożenia zgłoszono tylko dwa błędy, które zostały poprawione w bardzo krótkim czasie. Możliwe drogi rozwoju powstałego oprogramowania to: dodatnie do agenta możliwości obsługi komunikatów drugiej wersji protokołu SNMP, w której położono nacisk na wydajność oraz wprowadzono agentów pośredniczących (ang. proxy agent), dodanie do agenta możliwości obsługi komunikatów trzeciej wersji protokołu SNMP, w której położono nacisk na bezpieczeństwo. SPIS LITERATURY [1] W. Stallings: Protokoły SNMP i RMON Vademecum Profesjonalisty, Helion, Lipiec [2] IETF: RFC A Simple Network Management Protocol (SNMP). [3] IETF: RFC Management Information Base for Network Management of TCP/IP-based internets: MIB-II. [4] ITU-T / ISO: X.690 / Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding. [5] IETF: RFC Evolution of the Interfaces Group of MIB-II. [6] D. Thomas, C. Fowler, A. Hunt: Programming Ruby, Pragmatic Bookshelf, PWT POZNAŃ 8-9 GRUDNIA /5