Niniejszy temat zawiera opis typów obiektów zdefiniowanych w protokole SNMP w wersji v1 i v2.
Informacje o obiektach zawarte w poniższych sekcjach można odnaleźć, wybierając moduł w widoku Moduły MIB, a następnie wyszukując hasło ifIndex w polu Szukaj widoku Drzewo OID. Aby wyświetlić informacje o obiekcie oraz informacje o konwencji tekstowej w widoku Szczegóły, należy kliknąć obiekt ifIndex w hierarchii Drzewo OID.
Protokół SNMP w wersji v1 definiuje identyfikator obiektu (OBJECT IDENTIFIER), który jest podstawowym elementem budującym drzewo bazy MIB. Identyfikatory obiektów są analogiczne do nagłówków rozdziałów w książce - nie zawierają one rzeczywistych danych, lecz pozwalają zrozumieć, jakiego rodzaju dane są przekazywane przez ich elementy potomne.
Protokół SNMP w wersji v1 definiuje typ obiektu (OBJECT-TYPE), który jest używany jako kontener przechowujący informacje na temat zarządzanego urządzenia lub wartości mierzonej na urządzeniu.
Konwencja tekstowa (TEXTUAL-CONVENTION, TC) jest definicją typu obiektu, a nie rzeczywistym obiektem. W widoku Moduły MIB można wybrać opcję Konwencje tekstowe z listy Widok, aby wyświetlić przeanalizowane konwencje tekstowe w drzewie MIB. Należy wybrać nazwę konwencji tekstowej w drzewie MIB, aby wyświetlić jej definicję w widoku Szczegóły.
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "The BGP Established event is generated when the BGP FSM
enters the ESTABLISHED state." ::= 1 Sekcja ENTERPRISE definiuje obiekt, który jest elementem nadrzędnym pułapki. Jednak możliwe jest zdefiniowane obiektu drzewa MIB jako elementu potomnego numer 1 dla elementu nadrzędnego bgp. W rzeczywistości element bgpVersion jest zdefiniowany jako { bgp 1} w module RFC1269-MIB. Dlatego nie można dodać pułapki wersji v1 do drzewa MIB jako liścia, używając elementu ENTERPRISE jako elementu nadrzędnego.
Protokół SNMP w wersji v2 zmienia definicję TRAP-TYPE na NOTIFICATION-TYPE i określa, że ta nowa pułapka wersji v2 ma być definiowana tak jak inne obiekty MIB, z numerem elementu nadrzędnego i potomnego, co stanowi problem tylko dla pułapek wersji v1. Sekcja 4.1 dokumentu RFC1155 stanowi, że używanie liczby zero (0) jako numeru elementu potomnego jest niepoprawne i zarezerwowane do użytku w przyszłości. Protokół SNMP wersji v2 korzysta z liczby zero, pozwalając dostawcom na dodawanie pułapek wersji v1 do bazy MIB v2 przez dodanie zera do nazwy typu zarządzanego urządzenia, a następnie przez dodanie numeru pułapki po zerze. Dlatego w wersji v2 można definiować identyfikator obiektu z liczbą zero jako element potomny zarządzanego urządzenia, a następnie dodawać pułapki v1 jako elementy potomne tego zera.
Ta konwencja przyczyniła się do kolejnego błędu popełnianego przez autorów baz MIB. Sekcja 4 dokumentu RFC1155 stanowi, co następuje:
"Definicja typu obiektu składa się z pięciu pól: OBJECT (obiekt): ------- Nazwa tekstowa, określana jako OBJECT DESCRIPTOR (deskryptor obiektu), dla typu obiektu oraz odpowiadający mu OBJECT IDENTIFIER (identyfikator obiektu). Syntax (składnia): składnia abstrakcyjna dla typu obiektu. Musi to być zgodne ze składnią ASN.1 (zdefiniowaną poniżej). Definition (definicja): Opis tekstowy znaczenia typu obiektu. Przy implementacji powinno się upewnić, że obiekt jest zgodny z definicją, ponieważ baza MIB jest przeznaczona do użycia w środowisku wielu dostawców. Istotne jest to, aby obiekty miały spójne definicje we wszystkich komputerach. Access (dostęp): Jedna z opcji do wyboru: read-only (tylko do odczytu), read-write (do odczytu i zapisu), write-only (tylko do zapisu) lub not-accessible (niedostępny). Status: Jedna z opcji: mandatory (obowiązkowy), optional (opcjonalny) lub obsolete (przestarzały). Przyszłe notatki mogą również określić inne pola dla obiektów, które definiują."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs, adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute interval threshold reached." ::= { adslAtucTraps 0 1 } Obiekty przesyłane z pułapkami w wersji v1 lub powiadomieniami w wersji v2 są nazywane powiązaniami zmiennymi. Powiązania zmienne zawierają dodatkowe informacje na temat raportowanego zdarzenia. W pułapkach w wersji v1 powiązania zmienne są wyszczególnione w sekcji VARIABLES, a w powiadomieniach w wersji v2 w sekcji OBJECTS. Pełnią tę samą funkcję we wszystkich wersjach protokołu SNMP. Kolejność powiązań zmiennych na liście ma znaczenie, ponieważ pakiety PDU (pakiety SNMP) kodują powiązane wartości w kolejności ich występowania na liście bazy MIB.
Na przykład sekcja OBJECTS zawiera następujące trzy powiązania zmienne: ifIndex, ifAdminStatus oraz ifOperStatus. Zatem powiązanie zmienne ifIndex będzie kodowane jako pierwsze, ifAdminStatus jako drugie, a ifOperStatus jako trzecie. Po sprawdzeniu modułu IF-MIB okazuje się, że typ obiektu ifIndex jest zdefiniowany jako InterfaceIndex. Ponieważ nie jest to poprawny typ podstawowy ASN.1 dla protokołu SNMP, musi być konwencją tekstową. Po przeszukaniu konwencji tekstowych okazuje się, że InterfaceIndex w rzeczywistości odnosi się do typu Integer32 (32-bitowa liczba całkowita). Zatem po przesłaniu pakietu PDU do programu MIB Manager pierwsze powiązanie zmienne będzie liczbą całkowitą. Aby określić znaczenie liczby całkowitej, program MIB Manager musi się odnieść do modułu IF-MIB, wyszukać obiekt ifIndex i odczytać powiązane informacje o obiekcie. Drugie powiązanie zmienne to wyliczeniowy typ całkowitoliczbowy:
SYNTAX INTEGER { up(1), -- ready to pass packets down(2),
testing(3) -- in some test mode }Po odkodowaniu powiązania zmiennego z pakietu SNMP jego wartość będzie liczbą całkowitą, której wartość należy zinterpretować w oparciu o pozycje na liście. Jeśli program MIB Manager zostanie użyty do utworzenia pliku reguł, to utworzy tabelę wyszukiwania automatycznie łączącą wymienioną liczbę całkowitą z jej tekstowym odpowiednikiem. Trzecie powiązanie zmienne to również typ wyliczeniowy z identycznymi wartościami. Zatem jeśli powiązanie zmienne ifAdminStatus ma wartość 1 (up), a powiązanie zmienne ifOperStatus ma wartość 2 (down), to wiadomo dlaczego zdarzenie zostało wygenerowane i można podjąć próbę określenia przyczyny tego wyłączenia.
Powiązania zmienne w plikach reguł mają postać $1, $2, $3 itd.; każdy numer oznacza numer powiązania zmiennego. Program MIB Manager tworzy elementy w oparciu o elementy powiązań zmiennych i używa ich do ustawiania zmiennych w tabeli szczegółów. Na przykład elementy w tabeli szczegółów mogą mieć postać $ifIndex = $1, co będzie liczbą całkowitą, $ifAdminStatus = $2, co będzie wartością taką jak up (1), oraz $ifOperStatus = $3, co będzie wartością taką jak down (3). Wszelkie zmiany w ustawieniach obiektów są automatycznie odzwierciedlane w plikach reguł z użyciem konwencji określonych w bibliotece Netcool Knowledge Library (NCKL).
Tabele są odpowiednikiem wielowymiarowej macierzy z wierszami oraz kolumnami danych. Obiekt tabeli jest zdefiniowany jako typ SEQUENCE OF (lista) obiektu wpisu. Obiekt wpisu jest następnie definiowany jako SEQUENCE (struktura) obiektów typu OBJECT-TYPE. Czasami dostawca tworzy nietypowy system, na przykład router Cisco 10k. To urządzenie zawiera wewnętrzną tabelę warunków alarmowych i generuje pułapkę lub powiadomienie, gdy zachodzą zmiany w tabeli. Następnie należy wykonać żądanie SNMP GET (odczytu) na zawartości tabeli, aby określić bieżący status aktywnych alarmów dla urządzenia. To sprawia, że uzyskanie alarmów przez menedżera SNMP jest trudniejsze, ale nie niemożliwe, jeśli administrator ma odpowiednie narzędzia.
Oktet to jednostka danych składająca się z ośmiu bitów (powszechnie znanych jako bajt). OCTET STRING (łańcuch oktetów) to tablica bajtów lub ciąg bajtów. Termin OCTET STRING nie zakłada, że wszystkie bajty w ciągu są alfanumeryczne. Mogą one również być znakami binarnymi i mogą być używane jako maski bitowe.