Alle SNMP-MIB-Module, die für die Verwendung durch ein bestimmtes Gerät definiert werden, bilden die MIB für dieses Gerät. Mit dem Begriff MIB wird häufig eine einzelne Moduldefinition beschrieben. Dies ist allerdings technisch falsch. Tatsächlich ist die MIB die Kombination aus allen Modulen, die für die Verwaltung eines bestimmten Geräts verwendet werden. Dabei spielt es keine Rolle, ob sich das Gerät auf Hardware oder auf Software bezieht. Daher ist der genauere Name für jedes Modul, das von einem Lieferanten oder in einer RFC definiert wird, SNMP-MIB-Modul.
Alle MIB-Module sind letztendlich Erweiterungen des Stammmoduls. Alle freigegebenen MIB-Module von einzelnen Lieferanten sind Erweiterungen des Unternehmensobjekts, das in RFC1155-SMI definiert wird. Daher müssen alle SNMP-Agenten RFC1155 unterstützen und alle MIB-Module sind Erweiterungen von RFC1155.
Damit die Management Information Base (MIB) von SNMP erweitert werden kann, werden zusammengehörige Elemente in MIB-Modulen angeordnet, die eine strukturierte Hierarchie bilden. Jedes MIB-Modul wird innerhalb des folgenden Konstrukts definiert:
modulname DEFINITIONS ::= BEGIN END
Die Tags BEGIN und END im Modul ermöglichen die Definition mehrerer Module innerhalb einer einzigen Textdatei. MIB-Compiler sollten dazu in der Lage sein, eine beliebige Anzahl Module zu bearbeiten, die in einer einzigen Datei definiert sind. Dies sollte aber keine Voraussetzung sein.
Für jedes definierte Objekt innerhalb des Moduls gibt es Konventionen. Ein Modulname muss beispielsweise mit einem Buchstaben in Großschreibung beginnen und darf lediglich Buchstaben, Ziffern, Bindestriche (-) und Unterstreichungszeichen (_) enthalten. Ein Objektname muss mit einem Buchstaben in Kleinschreibung beginnen und darf lediglich Buchstaben, Ziffern, Bindestriche und Unterstreichungszeichen enthalten. Die beiden aufeinanderfolgenden Bindestriche (--) stellen in MIB-Modulen einen Kommentar dar und alle Textinformationen nach diesem Symbol in einer Zeile können ignoriert werden.
Aufgrund des modularen Aufbaus können MIBs auf einfache Weise erweitert werden und können jegliche neue Funktionalität oder jedes neue Gerät unterstützen, indem ein weiteres Modul hinzugefügt wird. Wenn ein Modul als Erweiterung eines anderen Moduls geschrieben wird, enthält es den Abschnitt IMPORTS, der unterhalb der Zeile DEFINITIONS zu finden ist. Im Abschnitt IMPORTS werden die Objekte, die für Module höher in der MIB-Hierarchie erforderlich sind, sowie die Module definiert, in denen die Objekte definiert werden.
RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks FROM RFC1155-SMI;Beim Angeben importierter MIB-Namen kommt es häufig zu einem Schreibfehler. So könnte z. B. RFC1212 als MIB-Modul anstatt des richtigen Namens RFC-1212 referenziert werden. Wenn von MIB Manager Parsingfehler hervorgehoben werden, muss der Inhalt des Abschnitts IMPORTS geprüft werden, um sicherzustellen, dass die MIB-Module ordnungsgemäß benannt sind. Einige MIB-Module enthalten auch den Abschnitt EXPORTS, der ebenfalls mit einem Semikolon endet. In diesem Abschnitt wird der Leser darüber informiert, dass vom MIB-Verfasser vorgesehen ist, dass andere MIB-Module dieselben angegebenen Objekte verwenden. Für die Zwecke im vorliegenden Text ist dieser Abschnitt irrelevant und kann ignoriert werden.
SNMP-MIB-Module werden in einem Format namens ASN.13 (Abstract Syntax Notation 1) definiert, für SNMP wird jedoch nur ein Teil von ASN.14 verwendet. ASN.1 wird in ITU-T X.208 und in ISO 8824 definiert. Die Teile von ASN.1, die für SNMP gelten, werden in RFC1155 definiert. In RFC1155 werden die folgenden gültigen SNMP-Datentypen definiert:
Ein definierter Typ ist der Mechanismus, über den ein bestimmtes Format für einen primitiven Typ oder einen Konstruktortyp angegeben wird. MIB-Verfasser können über das Konstrukt TEXTUAL-CONVENTION weitere Typen definieren.
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))Ein häufiger Fehler beim Schreiben von MIB-Modulen ist die Erstellung eines Objektnamens, der nicht eindeutig ist. Es wird behauptet, dass die Anweisung RFC1155 bedeutet, dass nur Objekte in einem einzelnen MIB-Modul eindeutig sein müssen. Wie zuvor erläutert, ist die MIB der vollständige Satz der Module, die in Kombination für die Verwaltung eines bestimmten Geräts verwendet werden. Daher müssen alle Objekte, die in einem beliebigen MIB-Modul definiert sind, eindeutig sein, nicht nur im eigenen Modul, sondern auch in allen anderen Objektnamen beliebiger importierter Module sowie in allen Modulen, die u. U. von diesen Modulen importiert werden. Ein häufiger Mechanismus, mit dem die Eindeutigkeit von Objektnamen sichergestellt wird, besteht darin, allen Modulnamen das Tickersymbol der jeweiligen Firma oder den abgekürzten Firmennamen voranzustellen.
Wenn Objekte definiert werden, werden sie einer numerischen Hierarchie zugeordnet, die einem Spanning Tree ähnelt. Immer dann, wenn ein Objekt definiert wird, wird es als Blatt eines übergeordneten Objekts definiert. In der SNMP-MIB-Baumstruktur sind die folgenden drei Stammobjekte definiert:
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 }Diese Definitionen geben den Objektnamen, die zugeordneten Objekttypen, den Namen des übergeordneten Objekts der einzelnen Objekte (oder eine sortierte Liste mit übergeordneten Objekten) sowie die Blattnummer dieses untergeordneten Objekts für das betreffende übergeordnete Objekt (bzw. die übergeordneten Objekte) an. Grafisch weisen diese Elemente eine hierarchische Form auf.
Sie können durch die Sicht MIB-Baumstruktur navigieren, indem Sie Knoten innerhalb der MIB-Baumstruktur ein- und ausblenden. Die Verzweigungen der höchsten Stufe in der MIB-Baumstruktur enthalten die Namen der MIB-Module. In jeder MIB-Modulverzweigung sind die anderen Elemente angeordnet, aus denen sich die MIB zusammensetzt. Wenn der MIB weitere Module hinzugefügt werden, werden der MIB-Baumstruktur weitere Objekte hinzugefügt. Auf jedes Objekt kann über seinen Objektnamen oder über seine Objekt-ID (OID) verwiesen werden. Die präziseste Methode ist der Verweis mittels OID. Die OID ist als die Nummer des Objekts mit jeder der Nummern der zugehörigen Vorfahren bis hin zum Stammknoten definiert, wobei diese Nummern hintereinander gestellt und jeweils durch einen Punkt (.) voneinander getrennt werden. Die OID für das Unternehmensobjekt (Knoten oder Blatt) ist 1.3.6.1.4.1.
Viele Lieferanten stellen nicht sicher, dass ihre Objektnamen universell eindeutig sind. Daher ist es möglich, dass zwei Lieferanten ein Objekt mit demselben Namen verwenden. Deshalb ist die Verwendung des Objektnamens für die Kennzeichnung eines Objekts etwas mehrdeutig.