Wszystkie moduły MIB SNMP, które są zdefiniowane dla konkretnego urządzenia, składają się na bazę MIB tego urządzenia. Termin MIB jest często używany do określenia definicji pojedynczego modułu, jednak jest to niepoprawne z technicznego punktu widzenia. W rzeczywistości baza MIB jest połączeniem wszystkich modułów używanych w celu zarządzania określonym urządzeniem, niezależnie od tego czy urządzenie oznacza sprzęt, czy oprogramowanie. Dlatego bardziej precyzyjną nazwa dla każdego modułu zdefiniowanego przez producenta lub w dokumencie RFC jest moduł MIB SNMP.
Wszystkie moduły MIB są ostatecznie rozszerzeniami głównego modułu. Wszystkie moduły MIB od poszczególnych dostawców są rozszerzeniami obiektu zarządzanego urządzenia zdefiniowanego w dokumencie RFC1155-SMI. Dlatego wszystkie agenty protokołu SNMP muszą obsługiwać standard RFC1155, a wszystkie moduły MIB są rozszerzeniami RFC1155.
Aby istniała możliwość rozszerzenia bazy MIB protokołu SNMP, pokrewne elementy są ułożone w moduły, które tworzą strukturę hierarchii. Każdy moduł MIB jest zdefiniowany w następujący sposób:
ModuleName DEFINITIONS ::= BEGIN END
Znaczniki BEGIN i END w module pozwalają na zdefiniowanie kilku modułów w ramach jednego pliku tekstowego. Kompilatory MIB powinny być w stanie obsłużyć dowolną liczbę modułów zdefiniowanych w jednym pliku, ale nie powinny tego wymagać.
Istnieją konwencje dla każdego obiektu zdefiniowanego w module. Na przykład nazwa modułu musi zaczynać się wielką literą i może zawierać tylko litery, liczby, myślniki (-) lub znaki podkreślenia (_). Nazwa obiektu musi zaczynać się małą literą i może zawierać tylko litery, liczby, myślniki (-) lub znaki podkreślenia (_). Komentarz w bazie MIB reprezentują dwa następujące po sobie myślniki (--), a jakikolwiek tekst następujący po tym symbolu w każdym wierszu można zignorować.
Dzięki modułowej, łatwo rozszerzalnej budowie bazy MIB mogą oferować wsparcie dla wszelkich nowych funkcjonalności lub urządzeń przez dodanie dodatkowego modułu. Gdy moduł jest zapisany jako rozszerzenie innego modułu, zawiera on sekcję IMPORTS (importy), która znajduje się pod wierszem DEFINITIONS (definicje). Sekcja IMPORTS (importy) definiuje obiekty wymagane przez moduły położone wyżej w hierarchii MIB i moduły, w których są one zdefiniowane.
RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks FROM RFC1155-SMI;Błędy drukarskie są często popełniane podczas określania zaimportowanych nazw MIB. Na przykład jako nazwę modułu MIB można podać RFC1212, zamiast poprawnej nazwy RFC-1212. Jeśli błędy analizowania są podświetlone przez program MIB Manager, należy sprawdzić sekcję IMPORTS (importy), aby potwierdzić, że moduły MIB zostały poprawnie nazwane. Niektóre moduły również zawierają sekcję EXPORTS (eksporty), która także kończy się średnikiem. Ta sekcja informuje czytelnika o tym, że autor bazy MIB oczekuje, że inne moduły MIB będą używały takich samych obiektów. Dla naszych celów ta sekcja jest nieistotna i można ją zignorować.
Moduły MIB SNMP są zdefiniowane w formacie znanym jako ASN.13 (Abstract Syntax Notation 1). Protokół SNMP używa jednak tylko części formatu ASN.14. ASN.1 jest zdefiniowany w standardzie ITU-T X.208 oraz ISO 8824. Części ASN.1, które dotyczą SNMP, zostały zdefiniowane w dokumencie RFC1155. RFC1155 definiuje następujące poprawne typy danych SNMP:
Typ zdefiniowany to mechanizm użyty do nadania konkretnego formatu typom podstawowym lub strukturalnym. Autorzy MIB mogą zdefiniować dodatkowe typy za pomocą konstrukcji TEXTUAL-CONVENTION.
DisplayString ::= OCTET STRING (0..255)DisplayString ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. To summarize RFC 854, the NVT ASCII repertoire
specifies: - the use of character codes 0-127 (decimal) - the graphics characters
(32-126) are interpreted as US ASCII - NUL, LF, CR, BEL, BS, HT, VT and FF have the
special meanings specified in RFC 854 - the other 25 codes have no standard
interpretation - the sequence 'CR LF' means newline - the sequence 'CR NUL' means
carriage-return - an 'LF' not preceded by a 'CR' means moving to the same column on
the next line. - the sequence 'CR x' for any x other than LF or NUL is illegal.
(Note that this also means that a string may end with either 'CR LF' or 'CR NUL', but not with CR.) Any object defined using this syntax may not exceed 255 characters in length." SYNTAX OCTET STRING (SIZE (0..255))Częstym błędem popełnianym podczas pisania modułów MIB jest tworzenie nazw obiektów, które nie są unikalne. Uważa się, że instrukcja RFC1155 zaznacza, że tylko obiekty w ramach jednego modułu MIB muszą być unikalne. Jak wspomniano wcześniej, baza MIB jest kompletnym zestawem modułów, które po połączeniu są używane do zarządzania określonym urządzeniem. Dlatego wszystkie obiekty zdefiniowane w jakimkolwiek module MIB muszą mieć unikalne nazwy, nie tylko we własnym module, ale także w jakimkolwiek zaimportowanym module i modułach, które mogą być zaimportowane. Powszechnym mechanizmem zapewniającym unikalność nazw obiektów jest dodawanie na początku nazwy każdego modułu symbolu lub skróconej nazwy firmy.
Po zdefiniowaniu obiektów są one odwzorowywane w hierarchii liczbowej, która przypomina drzewo opinające. Za każdym razem, gdy obiekt jest definiowany, jest on definiowany jako liść obiektu nadrzędnego. Następujące trzy główne obiekty są zdefiniowane w drzewie bazy MIB SNMP:
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::=
{ internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER
::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT
IDENTIFIER ::= { private 1 }Te definicje wskazują nazwę obiektu, powiązane typy obiektów, nazwę elementu nadrzędnego każdego obiektu (lub uporządkowaną listę elementów nadrzędnych) i numer liścia tego elementu potomnego w stosunku do elementu lub elementów nadrzędnych. W postaci graficznej te elementy mają układ hierarchiczny.
Można poruszać się po widoku Drzewo MIB, rozwijając i zwijając węzły w drzewie MIB. Najwyższy poziom gałęzi drzewa MIB to nazwy modułów MIB, które zawierają inne elementy należące do tych modułów. Podczas dodawania dodatkowych modułów do bazy MIB, dodawane są także dodatkowe obiekty do drzewa MIB. Każdy obiekt może być wskazany przez odwołanie do jego nazwy lub identyfikatora obiektu (OID). Najbardziej dokładną metodą jest odwołanie do identyfikatora OID. Identyfikator OID zawiera numer obiektu oraz numer każdego z jego przodków aż do węzła głównego, konkatenowane za pomocą kropki (.) oddzielającej każdy numer. Numerem OID dla obiektu generującego pułapkę (węzła lub liścia) jest 1.3.6.1.4.1.
Wielu dostawców nie zapewnia uniwersalnej unikalności nazw swoich obiektów, dlatego możliwe jest, że dwóch dostawców ma obiekty o tej samej nazwie. Sprawia to, że korzystanie z nazw obiektów w celu identyfikowania obiektów jest niejednoznaczne.