Home

 

4. Inside SNMP

Dieses Kapitel befasst sich mit den betrieblichen Merkmalen von SNMP sowie mit der logischen Struktur von Management-Informationen. Um die Probleme, die in einem Netzwerk auftreten können, schnell und sicher mit SNMP beseitigen zu können, müssen Sie SNMP fest im Griff haben.

Sie sollten wissen wie das Protokoll aufgebaut ist und wie es arbeitet. Ebenso sollte Ihnen die Struktur der gesammelten Daten bekannt sein. Wenn Sie dann noch wissen, wie die SNMP Nachrichten zusammengesetzt und interpretiert werden, haben Sie eine gute Grundlage.

4.1 Grundlagen

Ein Netzwerk node, der sich durch SNMP managen lässt, wird als "SNMP manageable" bezeichnet. Die Management-Daten (management data) sind eine Ansammlung von INTEGER, STRING und MIB-Adressvariablen, die wiederum die Daten enthalten, die für das managen des Nodes nötig sind. Diese Daten beinhalten Berechtigungen (für administrative und sicherheitsrelevante Zugriffe auf den Node), sowie Informationen über die Hard- und Software des Nodes und deren Konfiguration. Ebenso sind Daten enthalten, die über den vergangenen und gegenwärtigen Zustand des Nodes berichten. Diese Variablen werden oft als "managed objects" bezeichnet, in der SNMP Welt jedoch "MIB-Variablen" genannt.

MIB-Variablen enthalten die aktuellen Management-Daten, mit deren Hilfe man den Zustand des Nodes bestimmen kann. Mit deren Hilfe wird entschieden ob, und wenn ja, welche Maßnahmen ergriffen werden, um das Verhalten des Nodes zu verändern. SNMP definiert die Struktur der Management-Daten und stellt die Dienste, die von einem Management-System benötigt werden, um die Daten die in den MIB-Variablen gespeichert werden, zu verändern. Wenn ein Management-System einen Node managtet, nutzt es SNMP dazu, die Daten in den MIB-Variablen zu lesen und zu verändern.

Die gemanagten Objekte und Ihre Daten werden von einem Agent-Prozess, der auf dem Node ausgeführt wird, verwaltet. Der Agent ist der Türsteher der gemanagten Objekte und verrichtet die angeforderten Lese- und Schreibzugriffe des Management Systems. Der Agent ist daher verantwortlich für das Einfügen der SNMP-Protokolle in den Node.

Dieses einfache Konzept, das Lesen und Schreiben von in Variablen gespeicherten Daten, ist das Herz von SNMP.

Vier einfache Funktionen

SNMP definiert 4 Funktionen mit deren Hilfe MIB-Variablen verändert werden. Diese Funktionen werden Get, GetNext, Set und Trap genannt. Das man nur 4 Funktionen für das ausführen von allen Netzwerk-Management-Funktionen benötigt, bestätigt wieder einmal das "einfache" Konzept von SNMP.

Get Funktion

Die Get Funktion rettet den Inhalt einer speziellen "instance" eines gemanagten Objekts. Eine "instance" ist die physikalische Inkarnation einer in Speicher existierenden MIB-Variablen. Diese Variable kann einen Integer oder String Wert, bzw. die Adresse einer anderen Variablen, enthalten.

Die Get Funktion ist eine sehr einfacher Befehl. Nehmen Sie z.B. an das ein Agent drei Objekte mit folgenden Namen und Inhalten managtet :

Name Inhalt
erroredSeconds 17
mostSevereAlarm 24
shelfID "Cleversoft"

Wenn wir ein Get Funktion für erroredSeconds ausführen, wäre der Wert, welcher zurückgegeben wird, 17. Dieser aktuelle Wert wird dann in dem Objekt abgespeichert. Wir sagen dann dazu : "performed a get on erroredSeconds". Es wäre sicher sinnvoller, dies mit den Worten "Errettung oder holen und speichern des Wertes der Funktion erroredSeconds" zu umschreiben, aber warum sollen wir SNMP seiner eigenen Sprache berauben.

GetNext Funktion

Der nächst Befehl ist GetNext. Mit dieser Operation wird der nächste Wert gerettet und gespeichert (siehe Get Operation, nur der Sprung ist neu). Er bewirkt im Beispiel, daß der Inhalt von mostSevereAlarm gerettet und abgespeichert wird. Die Funktion dieses Befehls leuchtet im Moment vielleicht noch nicht so ein, da man wie in diesem Fall gut auf ihn verzichten könnte. In der Praxis ist er aber unverzichtbar. Vielen Daten, die aus Tabellen und MIB-Variablen zurückgegeben werden sollen, kann man keinen speziellen Namen zuweisen. Daher kann man sie nur mit dem GetNext-Befehl ansprechen.

Set Funktion

Der dritte Befehl ist Set. Die meisten gemanagten Objekt haben einen voreingestellten Wert, der beim Start des SNMP-Agents initialisiert wird. Wenn es sich bei diesem Objekt z.B. um die Taktfrequenz-Überwachung eines Prozessors handelt, wird diese immer wieder aktualisiert und abgespeichert. Um den Inhalt dieses Objektes, nach dem Start des Agents, auf einen bestimmten Wert setzen zu können, wendet man den Set-Befehl an.

Trap Funktion

Der vierte Befehl ist Trap. Diese Operation wird genutzt, um einem oder mehreren Management Systemen unaufgefordert mitzuteilen, daß eine speziell definierter Fall eingetreten ist. Auf diese Operation werde ich später detaillierter eingehen.

Die Nachricht ist das Management

SNMP ist ein Anfrage-und Antwort Protokoll. Ein Management System richtet eine Anfrage an einen Agent in Form von Get, NextGet, Set oder Trap Operationen. Der Agent reagiert auf diese Anfrage mit einer Antwort, deren Inhalt aussagt, ob die Anfrage erfolgreich beantwortet oder nicht bearbeitet werden konnte.

Sowohl der Agent wie das Management System, müssen ihre Anfragen und Antworten an eine spezielle Netzwerkadresse schicken. Für jede SNMP Anfrage, die von einem Management System gestellt wird, kommt eine Antwort, von jedem Agent, der sie empfangen hat zurück. Wenn eine Management System nun eine Anfrage an eine Broadcast-Adresse stellt, können eine Menge Antworten, die von den angesprochenen Agents gesendet wurden, empfangen werden. Eine Sache dürfte ebenfalls interessant sein : SNMPv1 Agents senden keine Management-Anfragen und SNMPv1 Management Systeme senden keine Management-Antworten.

Eine spezieller Typ von unaufgeforderten Antworten, die von einem Agent an ein Management System gesendet werden, ohne vorher eine Anfrage seitens des Management  Systems erfahren zu haben, werden Traps genannt. Eine Trap ist nichts anderes als ein Ereignisbericht, der aussagt, daß der Agent ein unvorhergesehenes Ereignis entdeckt hat.
Windows-Programmierer werden die verblüffende Ähnlichkeit zwischen dem Empfang und der Benachrichtigung einer Trap und der berühmt berüchtigten (schwer auf den Magen schlagenden) Windows-Mitteilung, daß ein schwerer Zugriffsfehler eingetreten ist, bemerken. Das Auftreten einer SNMP-Trap muss aber nichts mit dem Erkennen eines Fehlers zu tun haben.

 

Client Pull and Server Push

Die Transaktion (Abwicklung) von SNMP Anfragen und Antworten wird manchmal als das client pull model beschrieben. Dieses Modell sagt aus, daß der Management System Client die Daten die er vom Agent benötigt, "pulled" (holt).

Traps werden im server push model beschrieben, in welchem agents unaufgefordert Daten an ein Management System "pushed" (aufdrängen).

 

4.2 Die Sprachen von SNMP

SNMP ist ein sehr spezialisiertes Protokoll. Es wurde dafür entwickelt, Netzwerk Management Informationen, zwischen zwei oder mehr Einheiten in einem Netz, zu übertragen. Wir definierten Netzwerk Management Informationen als Daten, mit deren Hilfe Netzwerkgeräte kontrolliert, konfiguriert und überwacht werden können.

SNMP ist mehr als Protokoll den als Sprache anzusehen. Eine gute Interpretation von Protokoll ist folgende : eine Reihe von Regeln, die in Verhandlungen festgelegt wurden, und eingehalten werden müssen, damit der Austausch von Daten ohne Fehlinterpretationen erfolgen kann. Eine language (Sprache) ist ein entcodierender Mechanismus, der die Daten, die in einem Protokoll enthalten sind, in für uns verständliche Weise umsetzt. Das Protokoll sind dann die Regeln, mit deren Hilfe die Daten zwischen den verschiedenen Geräten transportiert werden.

Es gibt drei verschiedene Sprachen, mit deren Hilfe SNMP Management Informationen befördert :
Structure of Management Information (SMI)
spezifiziert das Format für zu verarbeitente Objekte, auf die über das SNMP-Protokoll zugegriffen werden soll
Abstract Syntax Notation One (ASN.1)
diese Sprache wird dazu genutzt, das Format von SNMP-Nachrichten und MIB Modulen, die eine eindeutige Datenbeschreibungsformat benutzen, zu definieren
Basic Encoding Rules (BER)
diese Sprache wird dazu genutzt, SNMP-Nachrichten in ein geeignetes Formt umzuwandeln, damit die Daten in einem Netz übertragen werden können.

Jede dieser Sprache unterstützt die anderen zwei, indem sie sich strikt an die jeweiligen Regeln halten, die seine Formate und Interpretationen beherrschen.

MIB Module sind sehr wichtig für SNMP. Ohne MIB gäbe es keine Informationen, um mit SNMP zu kommunizieren. Sie könnten genauso eine Sprache entwickeln, in der zwar Grammatik und Befehle vorhanden sind, jedoch keine Vokabeln um eine Aussage zu verbreiten.

SMI : Struktur von Management Informationen

MIB's sind sehr hochstrukturierte Darstellungen von Daten. Nochmals zur Wiederholung : die Regeln zur Definition von gemanagten Objekten und zum kreieren der Strukturen von SNMP MIB's, werden " die Struktur von Management Informationen", kurz SMI, genannt. Die SMI definiert die Regeln, um wiederum gemanagte Objekte in einem MIB zu definieren und die Struktur von MIB's für das Netzwerk Management zu spezifizieren.

SMIv1 wird in den RFCs 1155, 1212 und 1215 beschrieben und spezifiziert folgendes :
Die Anforderungen, an die MIB Module und deren definierten gemanagten Objekte, müssen mit Hilfe der CCITT X.208 ASN.1 data description language (" Daten Beschreibung's Sprache") beschrieben werden.
Eine Auflistung von Komponenten und Merkmalen der ASN.1 Sprache, mit deren Hilfe ein MIB Objekt beschrieben wird.
Die Definition von besonderen (neuen) ASN.1 Anwendungen, die speziell für SNMP MIB's angewendet werden.
Die Bestimmung, daß alle ASN.1 Konstruktionen, die veröffentlicht werden sollen, vorher mit CCITT X.209 BER entcodiert werden müssen.
Die Definition von der High-Level Struktur des Internet branch (Internet Zweig) (iso(1).org(3).dod(6).internet(1))  des MIB naming tree (MIB Namengegebene Baumstruktur).
Die Definition und Beschreibung eines SNMP gemanagten Objektes.

Die SMI befasst sich im wesentlichen mit der Organisation und Administration von gemanagten Objekten im Internet. Sie beschreibt eine "naming structure", auch "MIB naming tree" genannt. Mit dieser werden die gemanagten Objekt identifiziert und die Bereiche definiert, in welchen sich das gemanagte Objekt befindet. SMI beschreibt also nur das grundsätzliche Format, mit dessen Hilfe gemanagte Objekt definiert werden, selber kann es jedoch keine gemanagten Objekte definieren.

Wenn ein Netzwerk Gerät SNMP Management unterstützt, reicht es nicht aus, daß er nur das SNMP Protokoll unterstützt. Es muss nebenbei noch mindestens ein gemanagtes Objekt ausführen, welches im MIB tree definiert wurde. Die Objekte, die im wesentlichen von einer Einheit ausgeführt werden, sind Bestandteil der MIB view.

SMI sagt ebenso aus, daß jedes MIB-Modul, daß geschrieben wird, die Komponenten und Merkmale von ASN.1 benutzt um seine Struktur und seine Management Daten zu beschreiben. Stellen Sie daher sicher, daß die MIB-Module, mit denen Sie den Agent zu schreiben beginnen, auf jeden Fall ASN.1 Notationen  lesen können.

Abstract Syntax Notation One (ASN.1)

ASN.1 (A-S-N dot one ausgesprochen) ist eine Sprache, die von der ISO entwickelt wurde, Daten unabhängig ihrer Form, zu beschreiben. ASN.1 erlaubt allen Daten, sich in einer eindeutigen Textform, als Maske oder Schema darzustellen. Die Details, wie z.B die Maske realisiert und die Daten gespeichert werden, wird den Anforderungen des jeweiligen Systems überlassen.

Die vollständige Sprache wird in der CCITT x.208 beschrieben. SMI beschränkt SNMP jedoch auf einen kleinen Teil der ASN.1 Sprache, um damit die Management Daten zu beschreiben. Dieser Teil wird in vielen SNMP Büchern genau beschrieben. Ich möchte darauf jetzt nicht genauer eingehen, da dies den Rahmen dieser Dokumentation sprengen würde.

Nachdem Sie einen Blick auf den Syntax von ASN.1 geworfen haben, werden Sie sicher mit mir übereinstimmen, daß ASM.1 komplex und kompliziert ist. Behalten Sie immer in Erinnerung, daß ASM.1 dazu entwickelt wurde, jegliche Art von Daten in einer eindeutigen, Maschinenunabhängigen Form, darzustellen. Dadurch können die verschiedensten Systeme und Maschinen, die die Daten von ASM.1 dargestellt bekommen, deren Zusammenhang richtig interpretieren. Dies ist der abstrakte Teil von ASN.1.

Es ist die Allgemeingültigkeit und Flexibilität von ASN.1 die es zu einem wahren Universal-Werkzeug macht. Bedenken Sie jedoch immer, daß nur Daten von ASN.1 dargestellt werden können. Es werden keine Codes in Form von logischen Entscheidungen, Verzweigungen oder mathematischen Operationen unterstützt. Nur Daten-Strukturen, ob einfach oder komplex, werden unterstützt. Was auch immer mit den "rohen" MIB-Daten geschehen soll - es wird von den SNMP Einheiten entschieden und ausgeführt.

Syntax

ASN.1 hat wie jede andere Sprache auch eine Grammatik, ein Syntax und eine Reihe von stilistischen Konventionen. In diesem Kapitel werde ich kurz die Grundlagen von ASN.1 zusammenfassen. Später werden wir uns ausführlicher damit beschäftigen.

Um bei ASN.1 einen Datentyp zu definieren, wird folgender Syntax genutzt :

                <Datatype Name> : : = <Datatype Definition>

So können Sie z.B. einen Datentyp der "MostServereAlarm" genannt wird und auf dem ASN.1 Integer Typ basiert, definieren. Hier das Beispiel :

                MostSevereAlarm  : : = INTEGER

Nun können Sie anstelle des INTEGER "MostServereAlarm" benutzen, falls Sie in diesem Fall eine Variable erschaffen :

                circuitAlarms MostSevereAlarm : : = 3

Die Variable "circuitAlarms" ist somit von der gleichen Type wie "MostServereAlarm". Ihr wurde zusätzlich der Wert von 3 zugewiesen. Sie können dies natürlich genauso in C schreiben :

                typedef MostSevereAlarm int; MostSevereAlarm circuitAlarms = 3;

Nun fragen Sie sich sicher : Was ist dann so besonderes an ASN.1 ? Nun, um die Struktur und den Gehalt der Daten zu definieren, hat ASN.1 doch noch einiges mehr zu bieten als C.
Ein Beispiel : Sie können "MostSevereAlarm" einen eingeschränkten Wertbereich mit folgendem Syntax zuweisen :

                MostSevereAlarm : : = INTEGER (1..5)

"MostSevereAlarm" wurde somit definiert, daß er nur INTEGER mit einem Wert von 1 - 5 beinhalten darf. Sie können dies in C nicht mit sowenig Aufwand bewerkstelligen. Sie müssten hier einen Code entwickeln, der den Wert von "MostSevereAlarm" überprüft und dann entscheidet, ob er im gültigen Wertbereich liegt. ASN.1 dagegen definiert nur den gültigen Bereich der Variablen; den Rest muss der Agent, der den Zugriff zu der Variablen hat, ausführen (den Wert der Variablen überprüfen usw.).

Wir können zusätzlich jedem Wert der Variablen ein Label (Bezeichnung) zuweisen. Dies ist einer Aufzählung in Pascal oder C sehr ähnlich :

                MostSevereAlarm : : = INTEGER { critical(1), major (2), minor (3), warning (4), informational (5) }

Nun können wir mit dem "MostSevereAlarm" nicht nur Werte aus dem INTEGER-Bereich nutzen, sondern auch Textbezeichnungen :

                circuitAlarms MostSevereAlarm : : =3
                unitAlarms MostSevereAlarm : : = minor

Daten-Strukturen in Form von geordneten Listen werden mit dem SEQUENCE Schlüsselwort (Befehl) erstellt. Folgendes ist das Beispiel einer geordneten Liste :

                ErrorCounts : : = SEQUENCE      {
                    circuitId                             OCTECT STRING,
                    erroredSeconds                 INTEGER,
                    unavailableSeconds           INTEGER
                }

Wir können nun eine Liste, die auf dem "ErrorCounts" Datentyp basiert, erzeugen und Ihre Einträge folgendermaßen initialisieren :

                circuitPerformance : : = ErrorCounts  {
                " " ,                                  "Unassigned",
                erroredSeconds               0,
                unavailableSeconds         0
                }

 

Stilistische Konventionen

Es existieren eine Reihe von stilistischen Konventionen an die man sich bei der Erstellung von Labels für ASN.1 Werten, Makros, Identifizierern und Datentypen im SNMP halten muss. Alle Labels sind case-sensitive (Fallempfindlich) und sind stets in einer Sprache geschrieben, die von einem Menschen gelesen werden kann. Die folgenden Konventionen werden dazu genutzt, einheitliche Labels zu erzeugen :

 

Art des Labels Konvention Beispiel
ASN.1 Datentyp Das Initial ist großgeschrieben DisplayString
Datenwert (Inhalt) Das Initial ist kleingeschrieben true
Daten Identifizierer Das Initial ist kleingeschrieben sysDescr
ASN.1 Schlüsselwörter (Befehle) Alles großgeschrieben INTEGER
ASN.1 Makros Alles großgeschrieben OBJECT-TYPE
Modul Namen Initial großgeschrieben Clever-MIB

ASN.1 Schlüsselwörter, die gewöhnlich in SNMP MIBs genutzt werden, beinhalten folgendes :

                        BEGIN                     EXPORTS                     OBJECT
                        CHOICE                  IDENTIFIER                OCTET
                        DEFINED                IMPORTS                    OF
                        DEFINITIONS        INTEGER                     SEQUENCE
                        END                         NULL                             STRING

Kommentare

ASN.1 definiert Kommentare, die direkt in den ASN.1 Code eingebettet werden können. Diese Kommentare beinhalten leglich von Menschen lesbare Beschreibungen des Codes und werden von den Compilern ignoriert. Diese Kommentare werden immer nur auf einer Zeile erstellt. Ein Kommentar, der mehrere Zeilen beinhaltet, wird von ASN.1 nicht unterstützt.

Ein Kommentar wird von ASN.1 folgendermaßen definiert :
Er beginnt mit zwei aufeinanderfolgenden Bindestrichen
Er endet entweder wiederum mit zwei Bindestrichen - oder mit dem Ende der Zeile

Es folgen einige Beispiele von ASN.1 Kommentaren :

   -- Dies ist ein Kommentar --

    -- Dies ist ebenfalls ein Kommentar

    -- Dies ist ein Kommentar ---- Und dies ebenfalls

Es sieht so aus, als ob die Kommentare eine einfache Sache wären. Dennoch sind sie oft Fehlerquellen. Hier die zwei weitverbreitetsten Fehler :

                -- A local MIB definition
                myTimeStamp : : = OCTET STRING (SIZE(6))       -- 6-octet time stamp definition

Die erste Zeile ist ein einzelner Kommentar. Die zweite besteht aus einer ASN.1 Konstruktion und einem folgenden Kommentar. Diese zwei Zeilen würden fehlerfrei kompiliert. Jetzt verändern wir die Zeilen etwas :

                -- A local MIB definition
                -- myTimeStamp : : = OCTET STRING (SIZE(6))        -- 6-octet time stamp definition

Hier wurde versehentlich der doppelte Bindestrich durch ein verfrühtes RETURN in die nächste Zeile katapultiert und somit würde der Kommentar am Ende der Zeile nicht mehr als solcher angesehen --> eine Fehlermeldung beim Compilern wäre die Folge.

Die andere Fehlerquelle ist das optische hervorheben durch Bindestriche. Wenn die Anzahl der Bindestriche nicht ein vielfaches von 4 sind, tritt eine Fehlermeldung beim Compilern auf :

                -------- -- Gut. Zwei mögliche Bindestrichreihen

                ---- --- Nicht gut. Bei der zweiten Gruppe handelt es sich nicht um eine ungültige Bindestrichreihe

Also wenn mehr als 2 Bindestriche --> dann 4, 8, 12 usw.

 

The Basic Encoding Rules (BER)

Es besteht eine Verwandtschaft zwischen ASN.1 und BER, die auf dem gemeinsamen Quell- und Maschinen-Code basiert. ASN.1 ist eine Textbasierende, menschenverständliche Notation die in BER kompiliert wird. Bevor ein Netzwerkgerät eine SNMP Nachricht an ein anderes Gerät versenden kann, muss diese Nachricht in eine kleinere, binäre Darstellung umgewandelt werden. Das Resultat dieser "Umwandlung" ist BER.

Wenn diese Nachricht dann von dem anderen Gerät empfangen wurde, muss sie wieder in eine für das Gerät verständliche Form umgewandelt werden. Die Umwandlung in BER erfolgt also nur deswegen, daß die Nachricht im Netzwerk transportiert werden kann. Wenn Sie eine SNMP Datenaustausch mit einem Protokoll-Analyser beobachten, werden Sie feststellen, daß es sich bei jedem payload eines jeden UDP-Datagramms um eine BER-encodierte SNMP Nachricht handelt.

Da das Umwandeln von ASN.1 in BER und umgekehrt im Hintergrund von den SNMP Diensten ausgeführt wird, müssen wir auch nicht näher auf diesen Vorgang eingehen. Alleine das Wissen, daß es BER gibt, genügt, um Ihr Verständnis für SNMP zu vertiefen.

 

4.3 Gemanagte/verwaltete Objekte

Gemanagte Objekte werden immer im Zusammenhang mit einer MIB definiert. Dies erklärt sich selber, wenn man erkannt hat, daß eine MIB eine Kollektion von gemanagten Objekten ist. Deswegen nennt man sie auch MIB-Objekte, MIB-Einheiten oder MIB-Variablen. Wie ein Programmierer, sollten Sie eine MIB wie eine API, oder eine Reihe von globalen Variablen - die von einem Agent verwaltet werden - betrachten, die einem Management System den Zugriff auf Management Daten geben.

Jedes gemanagte Objekt wird in einem MIB Modul definiert, wobei man das OBJECT-TYPE Makro benutzt, daß von SMIv1 definiert wird. Ein ASN.1 Makro ist einer Klasse dadurch sehr ähnlich, indem es das Format und die Attribute des gemanagten Objekt beschreibt. Das Objekt kann Skalar (indem nur ein Fall/Ereignis darin vorkommt) oder Columnar (Säulenförmig, indem kein oder mehrere Fälle, Ereignisse darin vorkommen) sein.

Folgendes ist ein sysContact Objekt (definiert in MIB-II). Es handelt sich dabei um eine typische Definition einer Skalaren MIB Variablen.

                sysContact                     OBJECT-TYPE
                        SYNTAX                DisplayString         (SIZE    (0..255))
                        ACCESS                 read-write
                        STATUS                 mandatory
                        DESCRIPTION
                            "Hier wird festgehalten, wer die Person ist,
                              die für diesen gemanagten node Verantwortlich ist,
                              und wie man diese Person erreichen kann ( Email usw.)"
                        : : =    { system 4 }

Das "sysContact" Label ist der Name oder die Objekt-Beschreibung der Variablen. "OBJEKT-TYPE" ist das von SMIv1 definierte Makro. Die Attribute des Objektes werden von den nächsten 4 Zeilen beschrieben. (Diese Beschreibung wird von RFC 1155 definiert)

SYNTAX Die Syntax eines verwalteten Objekts definiert den Datentyp, der das Objekt beschreibt. Entsprechend dem Makro wird diese vom Datentyp ObjectSyntax genommen.

ACCESS beschreibt die aktuellen Zugriffsrechte des Objektes. Die verschiedenen Zugriffsrechte (read-only, read-write, write-only, not-accessible) werden von SMIv1 definiert.

STATUS beschreibt die Bedürfnisse und die Gültigkeit der Objekte. Folgende Einträge stehen zur Verfügung :

                Mandatory (Zwingend)
                   
Objekte die "zwingend" sind, müssen in einem Agent implementiert werden. Den Inhalt (Wert), den sie beinhalten, ist
                    freigegeben.

                Optional (Optional)
                   
Objekte die "optional" sind, können - müssen aber nicht - in einem Agent implementiert sein. 

                Deprecated (in etwa "missgebilligt")
                   
Objekte die "missgebilligt" sind, befinden sich in einer Vorstufe zum "veralteten" Zustand. Sie wurden bereits durch ein
                    neueres Objekt ersetzt, enthalten aber immer noch Daten, die vielleicht noch mal benötigt werden. Es handelt sich um eine
                    Vorruhestand.

                Obsolete (Veraltet)
                    Ein mit "veraltet" bezeichnetes Objekt wird nicht länger von MIB unterstützt und sollte nicht in einen Agent implementiert
                    werden. Es ist nicht notwendig, ein solches Objekt durch ein Aktuelles zu ersetzen, bevor man es als "veraltet" bezeichnet.

DESCRIPTION eine für Menschen lesbare Zeichenkette, die Auskunft über das Ziel/die Aufgabe des Objekts gibt, sowie erläutert, wie man mit dem Objekt umzugehen hat.

 

Gemanagte Objekte sind nicht notwendigerweise Objekt-Orientiert

Die Phrase "gemanagte Objekte" wird dazu genutzt, die Management Daten, die in einer MIB definiert wurden, zu beschreiben. Sie werden von einem Agent verwaltet und über SNMP wird auf sie zugegriffen. Der Term "Objekt" steht für folgendes : Eine Ansammlung von Daten, eine Reihe von zusammenhängenden Attributen und der Code, mit welchen mit den Daten gearbeitet werden kann. Die aktuell gemanagten Objekte, die von einem Agent unterstützt werden, beinhalten Daten und Attribute, haben aber selber keine Möglichkeit, etwas mit diesen Daten anzufangen. (Wenn dies der Fall wäre, könnte man sie als Objekt-Orientiert bezeichnen)  Dies ist so, weil alle mit SNMP gemanagten Objekte so betrieben werden, daß sie die Regeln von SNMP beachten. Diese Regeln werden vom SNMP-Protokoll festgelegt. Somit kann es sicherstellen, daß SNMP Plattform- und Geräteunabhängig ist und bleibt.

 

MIB-II gemanagte Objekte

RFC 1213 beinhaltet die Definition (Sie können Sie auch Quellcode nennen) von RFC1213-MIB (auch als MIB-II bekannt). MIB-I wird von RFC 1156 definiert und wurde von MIB-II abgelöst. Am MIB-Baum ist MIB-II wie folgend auszumachen :

iso(1).organization(3).dod(6).internet(1).mgmt(2).mib(1).

MIB-II beinhaltet 171 managebar Objekte, die in elf Funktionsgruppen organisiert sind. Für alle Netzwerkgeräte, die sich in einem TCP/IP Netzwerk befinden, ist es erforderlich, diese Gruppen zu implementieren, damit sie eine Grundlage an gemanagten Objekten  für Netzwerk Management Operationen haben.

Seit der Veröffentlichung von MIB-II im März 1991 wurden noch eine Reihe weiterer Funktionsgruppen in den mib(1) Zweig aufgenommen. So waren dies z.B. die Unterstützung von Nicht-Ethernet Schnittstellen (frame-relay, ATM, FDDI, SONET) und Nicht TCP/IP Transport Mechanismen (AppleTalk, X.500, IPX). Jede neue Gruppe wird als MIB Module beschrieben und als RFC veröffentlicht.

Es sind also eine Menge MIB Module veröffentlicht worden, die gemanagte Objekte definieren, die wiederum mit vielen verschiedenen Netzwerkgeräten und Schnittstellen, wie z.B. Routers, Bridges, Repeaters, RS-232 Schnittstellen, Modems, Drucker, Druckerschnittstellen und Unterbrechungsfreien Spannungsversorgungen, zusammenarbeiten.
Diese "privaten" MIB's sind im iso(1).organization(3).dod(6).internet(1).private(4).enterprises(1) Zweig des MIB-Baumes zu finden.
Viele der erweiterten Agents, die Sie schreiben, werden solche "privaten", gerätespezifischen MIB's unterstützen.

Da MIB-II eine breite Akzeptanz in der SNMP Gemeinde gefunden hat, werden wir uns bei den Beispielen in dieser Dokumentation an MIB-II Objekte halten. Diese werden Sie durch das ganze Dokument begleiten, damit Sie mit ihnen vertraut werden und Ihr Verständnis für SNMP vertiefen können.

Alle Knoten (Nodes), die SNMP-Management unterstützten, benötigen die Implementation der Systemgruppe von RFC1213-MIB. Die Management Informationen in der Systemgruppe identifizieren die Knoten zu einem Netzwerk Management System. Die Systemgruppe ist im Internet-Zweig (1.3.6.1.2.1.1.) des MIB-Baums zu finden.

Die sieben gemanagten Objekte dieser Gruppe sind folgend aufgelistet :

 

 

Objekt Identifizierer Objekt Beschreibung Zugriff MIB-I MIB-II
system.1 sysDescr read-only * *
system.2 sysObjectID read-only * *
system.3 sysUpTime read-only * *
system.4 sysContact read-write   *
system.5 sysName read-write   *
system.6 sysLocation read-write   *
system.7 sysServices read-only   *

Die Objekte haben folgende Bedeutung :

                sysDescr
                    Eine Beschreibung des Knotens (Nodes). Es wird die Version und der Namen der
                    Hardware, das Betriebssystem und die Netzwerksoftware beschrieben. Dieser String
                    wird oft an Management Stationen angezeigt, um einen speziellen Nodes zu identifizieren.
                    Dieser String ist bei Geräten, die vom gleichen Hersteller und von der gleichen Produktfamilie
                    abstammen, identisch.

                sysObjectID
                   
Die Registrations OID (Object Identifier - wird "oh-eye-dee" ausgesprochen). Jedes Netzwerkgerät,
                    daß mit einem privaten (Händler) MIB beschrieben wird, reserviert eine OID in ihrer MIB. Diese wird
                    dazu genutzt, daß das Gerät von dem Management System eindeutig identifiziert wird.

                sysUpTime
                    Der Zeitraum der vergangen ist, seitdem sich der SNMP-Prozess neu initialisiert hat. Da dieser
                    Prozess bei jedem Kalt- und Warmstart des Nodes ebenfalls durchgeführt wird, zählt man die Zeit,
                    die das Gerät selbst benötigt um sich zu initialisieren, nicht dazu. Der angegebene Zeitraum wird in
                    0.01 Sekunden angegeben. Dieser Zeitraum wird dann als eine Art "Zeitmarkierung/Zeitmarke"
                    (time stamp) jeder Trap-Nachricht, die der Agent versendet, beigefügt.
                    Diese time stamp kann dann von einem Management System dazu verwendet werden, die genaue
                    Ankunft der Trap zu bestimmen, und zu entscheiden, ob es sich bei der Nachricht um ein Duplikat handelt.
                    Man kann den Inhalt  von sysUpTime auch an ein anderes Objektes, wie z.B. lastConfigChanged übergeben.
                    Dies bietet sich daher an, da bei einer Änderung stets das Gerät neu initialisiert wird.
                    Des weiteren kann ein Management System, daß den Agent in einem bestimmten Intervall abfragt, erkennen
                    ob der Agent sich innerhalb der Abfrage-Intervalle neu initialisiert hat oder nicht.

                sysContact
                    Der Namen der Person, der Gruppe oder der Organisation die für die Wartung, Pflege usw. des Nodes
                    verantwortlich ist. Kontakt-Informationen wie eMail Adresse oder Telefonnummer können ebenfalls
                    beigefügt werden.

                sysName
                    Der Namen des Knotens. Das sind normalerweise der Host und Domain Name des Knotens oder eine
                    einfache "trockene" Beschreibung des Nodes wie z.B. "Internet Router".

                sysLocation
                    Eine Beschreibung, wo der Node sich befindet. Die Beschreibung sollte einfach aber deutlich sein.
                    Sie könnte z.B. "Telefon-Schrank, 3. Ebene" oder "Klein's Büro, Zimmernummer 0815" lauten.
                    In der Praxis kommen aber auch Beschreibungen wie "Hinter den Abwasserrohren im 3. Waschraum
                    der Werner-Siemens-Schule" vor.

                sysServices
                    Ein INTEGER Wert, dessen ersten 7 Bits anzeigen, welcher System Service (und welche Schicht im OSI-Modell)
                    von dem Node unterstützt wird. In der anschließenden Tabelle werden die verschiedenen Bereiche definiert.

 

Bit Field Funktionsweise OSI Schicht
0x01 Physical    1
0x02 Datalink/Subnetwork    2
0x04 Internet    3
0x08 End-to-end    4
0x10 End-to-end interface    5
0x20 Applications interface    6
0x40 Application    7

Nur 3 dieser 7 Objekte können mit SNMP verändert werden. Dies ist an der Access-Variablen "read-write" zu erkennen. Jedes Objekt das mit der Variablen "read-only" bezeichnet wurde, kann nicht verändert werden. Der Inhalt dieser Objekte wird beim erstellen des Agents gesetzt (sysDescr und sysObjectID)   bzw. beim initialisieren des Systems vom Agent selbst ermittelt und eingefügt (sysUpTime) oder ist fest im Agent integriert (sysServices).

Wir gehen nun noch ein bisschen genauer auf das Objekt sysObjectID ein. Der Inhalt dieses Objektes beinhaltet einen einmaligen Registrations-"Wert", mit dessen Hilfe das Management System das Netzwerkgerät mit Firmen, Produkt, Familien und Modellbezeichnungen identifizieren kann. Dies gestattet dem System, mehr Informationen für den Benutzer anzuzeigen, als nur "SNMP Gerät".

Jeder Registrations-"Wert" ist ein Objekt-Identifizierer und jedes Produkt hat seinen eigenen OID in seiner eigenen privaten Firmen MIB.

Folgend werde ich ein erfundenes Gerät mit seiner MIB auflisten :

--Clever's enterprise MIBs
ora                                 OBJECT IDENTIFIER    : : = {    enterprises 2040     }
                                                                                                                            -- 1.3.6.1.4.1.2040

--Product Group
products                        OBJECT IDENTIFIER    : : = {    ora 1    }                   -- 2040

--Product registration OID
registration                   OBJECT IDENTIFIER    : : = {    ora 3    }                   -- 2040.3

--Product MIBs
oraModem                     OBJECT IDENTIFIER    : : = {    products 1    }         -- 2040.1.1
oraPrinter                     OBJECT IDENTIFIER    : : = {    products 2    }         -- 2040.1.2
oraHub                          OBJECT IDENTIFIER    : : = {    products 3    }          -- 2040.1.3

--MIBs for individual Printer models
oraNeedle                     OBJECT IDENTIFIER    : : = {    oraPrinter 1    }         -- 2040.1.2.1
oraInc                           OBJECT IDENTIFIER    : : = (    oraPrinter 2    }         -- 2040.1.2.2
oraLaser                       OBJECT IDENTIFIER    : : = {    oraPrinter 3    }         -- 2040.1.2.3

-- Registration objects for sysObjectID
orareg-Modem            OBJECT IDENTIFIER    : : = {    registration 1    }         -- 2040.3.1
orareg-Printer            OBJECT IDENTIFIER    : : = {    registration 2    }         -- 2040.3.2
orareg-Hub                  OBJECT IDENTIFIER    : : = {    registration 3    }         -- 2040.3.3

--Registration objects for sysObjectID of all Printer models
orareg-Needle            OBJECT IDENTIFIER    : : = {    oraPrinter 1    }         -- 2040.3.2.1
orareg-Inc                   OBJECT IDENTIFIER    : : = {    oraPrinter 2    }         --2040.3.2.2
orareg-Laser               OBJECT IDENTIFIER    : : = {    oraPrinter 3    }         --2040.3.2.3


Diese MIB definiert die Bereiche der Produkt Familien : Modem, Drucker und Hubs. Jede MIB ist in dem Zweig 2040.1 des privaten Firmen MIB der Firma "Clever" untergebracht. Jede Produktfamilie hat eine gleichlautende Registrations-OID im 2040.3 Zweig. Die Drucker-Familie hat drei Modelle, welche unter der Drucker-MIB registriert wurden. Jeder dieser Drucker hat wiederum eine eigene MIB und eine eigene Registrations-OID.

Wenn Sie nun eine Anfrage an den Variablenwert von sysObjectID eines solchen Hub´s im Netz stellen, würden sie diese OID Information erhalten : 1.3.6.1.4.1.2040.3.3
Ein Management-System würde in seiner OID Datenbank nach diesem Wert suchen. Wenn es einen Treffer landet, können die erweiterten Informationen angezeigt werden. Natürlich müssen diese Informationen in seiner privaten Datenbank gespeichert sein.

Dies geschieht meist automatisch, wenn die MIB des Händlers auf das Management System geladen wird. Sie wird dann von dem Installations-Programm in die Datenbank eingetragen.

 

Beachte

Registrations OID's sind nur einfache Platzhalter, die dazu genutzt werden, eine einmalige Händler Identifizierung für jedes Produkt zu erschaffen. Sie sind nicht die eigentlichen Objekte die von einem SNMP-Agenten realisiert werden. Wenn Sie eine GET   Funktion mit einer Registrations-OID ausführen, werden Sie eine Fehlermeldung (genErr) erhalten.

 

 

SNMP Data Types

Es stehen zwar viele verschiedene Datentypen unter ASN.1 zur Verfügung, aber SMIv1 beschränkt SNMPv.1 MIBs auf die Nutzung der ASN.1 UNIVERSAL Typen. Daher basieren alle gemanagten (verwalteten) Objekte, definiert unter SNMPv1, auf folgendem 3 Typen :

INTEGER
                Damit können ganze Zahlen dargestellt werden. ASN.1 definiert keine speziellen Beschränkungen betreffend
                der Größe dieser Zahl, obgleich die meisten SNMP Anwendungen die Größe von INTEGER Zahlen
                mit 32 Bits und einem Bereich von -2147483648 bis 2147483648 angeben.

OCTET STRING
                Eine Sequenz von Oktetten *. Diese Sequenz können druckbare ASCII-Character oder beliebige binäre Daten sein

* Die Größe eines Oktetts ist systemunabhängig und hat immer eine Länge von 8 Bits. Die Größe eines Bytes ist systemabhängig und beinhaltet die Anzahl der Bits, die benötigt werden, um einen Character auf diesem System darzustellen.

OBJECT IDENTIFIER (OID)
                Speichert den Zweig (Lagebezeichnung) einer Variablen (gemanagtes Objekt) innerhalb einer MIB. Die
                 Lagebezeichnung ist ein Aufgebot von unsignierten16-Bit integers, subidentifiers genannt.
                OBJECT IDENTIFIER können mit den Zeigern in C, die die Adresse einer location im Speicher speichern,
                verglichen werden.

ASN.1 NULL ist kein echter Datentyp. Er fungiert als Platzhalter. Wenn man klarstellen möchte, daß die  MIB Variable einen uninteressanten Wert enthält, verwendet man NULL wie folgend :

Value : : = NULL

Es gibt 5 ASN.1 APPLICATION- (Anwendungs) Datentypen, die für die Verwendung in SNMP MIBs definiert wurden. Diese Typen werden von RFC 1155 und nicht von ASN.1 definiert :

                IpAdress     : : =
                [APPLICATION 0]
                IMPLICIT OCTET STRING (SIZE(4))

                Counter     : : =
                [APPLICATION 1]
                IMPLICIT INTEGER (0..4294967295)

                Gauge     : : =
                [APPLICATION 2]
                IMPLICIT INTEGER (0..4294967295)

                TimeTicks     : : =
                [APPLICATION 3]
                IMPLICIT INTEGER (0..4294967295)

                Opaque     : : =
                [APPLICATION 4]
                IMPLICIT OCTET STRING

Wie Sie aus deren Definitionen entnehmen können, sind alle diese 5 (APPLICATION) Typen aus INTEGER und OCTET STRING zusammengesetzt. Wie Sie sicher registriert haben, sind die Typen COUNTER, GAUGE und TIMETRICKS identisch definiert worden. Sie unterscheiden sich nur darin, wie die von ihnen gespeicherten Daten von dem Agent manipuliert bzw. von dem Management System ausgewertet werden. Das IMPLICIT ASN.1 Schlüsselwort wird dann benötigt, wenn ein Datentyp von einem Anderen abgeleitet wird.

IpAdress
                IpAdress
ist nur ein OCTECT STRING mit einer Größe von genau vier Oktetten (192.168.0.10).
                Von MIB Variablen dieser Art wird erwartet, daß sie eine 4-Byte Netzwerkadresse beinhalten.

Counter
                Counter ist eine positive 32-Bit Integer-Variable, die dazu genutzt wird, den Wert eines Zählers, der in
                einem festen Bereich von 0 bis 4294967295 aufwärts zählen kann, abzuspeichern. Wenn der Zähler
                seinen maximalen Wert erreicht hat, springt er wieder auf 0. Eine Counter-Variable funktioniert wie der
                Tageskilometerzähler in Ihrem Auto. Er kann zurückgesetzt werden, aber er ändert niemals seine
                Zählrichtung. Anders als Ihr Kilometerzähler, kann ein Counter jedoch zeitweise angehalten werden
                und auf einen bestimmten Wert gesetzt werden.

Gauge
                Gauge ist ebenfalls eine positive 32-Bit Integer-Variable. Jedoch kann mit ihr in einem variablen Bereich
                von 0 bis 4294967295 auf- und abwärts gezählt werden. Wenn der mini- bzw. maximal festgelegte
                Gauge-Wert erreicht wird, bleibt dieser stehen, und verändert sich erst wieder, wenn er
                den eingeschränkten Bereich wieder erreicht.
               
                Ein Beispiel :
                Sie haben einen Temperatur Sensor, der einen Bereich von - 40 bis 400 hat. Für Sie ist aber nur
                der Bereich von 20 - 40 interessant. Nachdem Sie die Grenzen gesetzt haben, verändert sich
                der Inhalt dieser Variablen nur innerhalb dieses Bereichs. Wird der Maximal- bzw. Minimal-Wert
                über- oder unterschritten, bleibt die Variable mit diesen Werten stehen.

TimeTicks
                TimeTicks ist eine positive 32-Bit Integer-Variable die einen Zeitintervall beinhaltet. Dieser Intervall
                beträgt 0.01 Sekunden. Wenn die TimeTicks-Variable als aufwärtszählender Counter verwendet wird
                setzt sie sich alle 497 Tage selbst auf 0 zurück.

Opaque
                Opaque ist ein Typ, der vornehmlich von SMI dazu benutzt wird, neue Daten zu kreieren.
                Bei diesen Daten, die in den Opaque Variablen gespeichert werden,  handelt es sich immer um
                BER-encodierte Werte, die nicht von SNMPv1 definiert wurden.

 

Textliche Konventionen

Eine textliche Konvention ist ASN.1-Subtyping, die die Rückdefinition eines existierenden ASN.1 Datentyps ermöglicht. Der zurückdefinierte Typ ist eigentlich kein echter neuer ASN.1 Datentyp, sondern eher eine eingeschränkte Version des existierenden Datentyps. Sie können so z.B einen neuen, Pseudo-Datentyp in C mit folgenden Zeilen erstellen :

                #define BOOL        int
                #define FALSE      0
                #define TRUE        !FALSE

Wir können dies genauso in ASN.1 bewerkstelligen, indem wir die textliche Konventionen benutzen :

                Bool     : : =    INTEGER     {   true(1), false (2)  }

In beiden Beispielen wurde eigentlich kein neuer Datentyp erstellt. Es wurde anstatt eines neuen Datentyps, ein  neuer Namen basierend auf dem existierenden Datentyps definiert. Dieser neue Name kann z.B. für die Erklärung von Variablen genutzt werden.

                Bool     JobIsComplete    : : =    false

RFC 1213 definiert zwei textliche Konventionen, die mit SNMPv1 benutzt werden dürfen. Die erste ist DisplayString, ein echter OCTET STRING mit einer Länge von 0 bis 255 Oktetten. Er beinhaltet nur die druckbaren ASCII- Zeichen (32 through 126), die von RFC 854 definiert werden. Die Andere, PhysAddress, ist ein OCTET STRING, der keine SIZE (Größen)-Klausel besitzt. Mit im werden Hardeware-Adressen, die sich auf dem Medien oder Physikalischen Level befinden, gespeichert.

Viele weiter textliche Konventionen haben, Dank der breiten Nutzung von SNMPv1 und der Entwicklung von SNMPv2, zu diesen beiden Konventionen gefunden. Die folgende Tabelle listet einige der Konventionen auf, die Ihnen in SNMPv1 MIBs begegnen können. Wenn Sie eine textliche Konvention in Ihrer eigenen MIBs erstellen, sollten Sie darauf aufpassen, daß sie nicht versehentlich mit mehreren Konventionen arbeiten.

 

Name Syntax Beschreibung
DateAndTime OCTET STRING(SIZE(8 | 11)) Datum und Zeit mit optionalen Zeit-Offset
DisplayString OCTET STRING(SIZE(0..255)) Druckbare ASCII-Zeichen
MacAddress OCTET STRING(SIZE(6)) IEEE 802 Hardware Adresse
PhysAddress OCTET STRING Hardware Adresse
TimeInterval INTEGER(0..2147483647) Zeit Intervall, gemessen in 0.01 Sekunden
TimeStamp TimeTicks SysUpTime Wert
TruthValue INEGER {  true(1),  fakse(2)  } Boolean
VariablePointer OBJECt IDENTIFIER MIB Variablen Identifizierer

 

Subtyping (Untertypen)

In den vorhergehenden Beispielen wurde deutlich, daß die meisten textlichen Konventionen eine eindeutige Beschränkung des Wertes, auf den sie verweisen, besitzen. Dies wird durch die Nutzung von ASN.1 subtyping weiter vollendet. Variablen beschränken ihren Wert in SNMPv1 durch die Nutzung von subtyping. *

 

* Achtung :

Nicht alle MIB Compiler bieten vollkommene "subtyping"-Unterstützung. Zum Beispiel der MIB-Compiler, MIBCC, von Microsoft unterstützt keine INTEGER und OCTET STRING Typen die als mehrere, feste subtypes wie INETGER(2|4|8|16) deklariert wurden.

Die nachfolgende Tabelle zeigt weitere Beispiele von INTEGER textl. Konventionen mit dem subtyping ihres Bereiches. Ein subtype kann einem Label als textl. Konvention oder direkt als SYNTAX Klausel  in einem OBJECT-TYPE Makro zugewiesen werden. Der Bereich eines INTEGERS wird in Dezimalen oder Hexadezimalen Werten angegeben.

 

Beispiel Beschreibung
INTEGER Bereich nicht festgelegt
INTEGER(-127..128) 8-Bit mit Vorzeichen
INTEGER(0..255) 8-Bit ohne Vorzeichen (nur pos.)
INEGER(1..10) Nur die Werte von 1-10
INTEGER(0|2|4|6|8) Nur die Werte 0,2,4,6 und 8
INTEGER(0..2|20) Von 0-2 und 20
INTEGER(-32768..32767) 16-Bit mit Vorzeichen
INTEGER(-32769..-1|1..32767) 16-Bit mit Vorzeichen ohne Null
INTEGER(0..'ffff'h) 16-Bit ohne Vorzeichen
INTEGER(0..'7fffffff'H) 32-Bit mit Vorzeichen
INTEGER(1) Nur 1

Aufzählende INTEGERs (Ganzzahlen) sind eine Form von ASN.1 subtyping, jedoch mit einem Text Label, welches auf einen beliebigen möglichen Wert verweisen kann. Der Wert eines aufzählenden INTEGERs kann von 1 - 2147483647 betragen (0 wäre zwar ein erlaubter Wert in ASN.1, jedoch nicht in SMIv1). Die Labels werden nur dazu genutzt, die aufzählenden Werte in ein MIB Modul zu übergeben. Die aktuellen Werte werden dann in der SNMP Nachricht selber gebraucht.

SMIv1 definiert, daß jedes Label eine Länge von 1-64 Characters hat und nur aus Buchstaben, Zahlen und Bindestrichen bestehen darf. Der erste Character muss kleingeschrieben, der letzt darf kein Bindestrich sein. Bindestriche dürfen nicht von einem weiteren Bindestrich gefolgt werden, da die folgenden Zeichen sonst als Kommentare betrachtet werden. Jedes Label muss innerhalb einer Aufzählung einmalig sein.

Das folgende Beispiel listet einige Beispiele von textl. Konventionen aufzählender INTEGERs auf. (Ich weis, daß das komisch klingt :-))). Diese Beispiele zeigen, wie mit Hilfe von aufzählende integers neue Labels erschaffen, bzw. sie direkt zu der SYNTAX Klausel in einem OBJECT-TYPE-Makro verwiesen, werden.

    Boolean    : : =    INTEGER     {  true(1)  ,  false(2)  }
        SYNTAX INTEGER    {   true(1)  ,  false(2)  }
    Alarm-level  : : =  INTEGER  {  critical(1)  ,   major(2)  ,  minor(3)  ,  warning (4)
                                                    informational(5)   }
    Day  : : =  INTEGER  {  sun(1)  ,  mon(2)   ,  tue(3)  ,  wed(4)  ,  thu(5)  ,  fri(6)   ,  sat(7)  }
    DayRange  : : = INTEGER   {  bps-96(9600)  ,   bps-192(19600)  ,  bps-384(38400)  ,  bps-567(56700)  }
        SYNTAX INTEGER    {   reset(1)    }
    MyInteger  : : =  INTEGER                 -- Bereich nicht angegeben

SMIv1 gestattet die Deklaration eines OCTET STRINGs ebenfalls durch die Nutzung von textliche Konventionen. Um den Bereich der OCTET STRINGs zu deklarieren, wird die SIZE Klausel verwendet. Die Größe des OCTET STRINGs wird in dezimaler oder hexadezimaler Schreibweise angegeben. Sie kann in einer festen oder variablen Größe festgelegt werden. Folgende Tabelle zeigt einige Beispiele :

 

Beispiel Beschreibung
SystemName  : : =  OCTET STRING Länge nicht angegeben
DisplayString  : : =  OCTETT STRING (SIZE (0..255)) 0-255 Oktetten
MacAddress  : : =  OCTET STRING (SIZE(6)) Genau 6 Oktetten
DateAndTime  : : = OCTET STRING (SIZE(8 | 11)) 8 oder 11 Oktetten
SYNTAX OCTET STRING (0..2 | 20) 0-2 oder 20 Oktetten
UnicodeChar  : : =  OCTET STRING (SIZE(2)) Genau 16-Bit
MyUnicodeString  : : = UnicodeChar  (SIZE(10..12)) Fehler!! Can't reSIZE
MyUnicodeString  : : = UnicodeChar So ist es richtig. Ein 2 Oktett String

Subtypes vom Opaque-Datentyp nutzen ebenfalls die SIZE Klausel. Ein Opaque ist nur ein OCTET STRING im Schafspelz - daher wird er auf dem gleichen Weg ge-"subtyped"

 

Beispiel Beschreibung
Opaque 0-65535 Oktetten
Opaque(SIZE(0..240)) 0-240 Oktetten
Opaque(SIZE(12)) genau 12 Oktetten
Opaque(SIZE(0 | 14 | 24)) 0, 14, oder 24 Oktetten
Opaque(SIZE(0 | 2..8 | 24..36)) 0, 2-8, oder 24-36 Oktetten
Opaque(SIZE(0..6)) 0-6 Oktetten
Opaque(SIZE( 1 | 2 | 3 | 4 | 5 | 6 )) 0-6 Oktetten

 

Das "subtyping" (siehe nächste Tabelle) von GAUGE-Typen ist das selbe wie von INTEGER-Typen. Jedoch verhält sich ein GAUGE-Type, mit eingeschränkten oder mehreren Wertebereichen, anders als ein INTEGER-Typ.

 

Beispiel Beschreibung
Gauge 0-4294967295
Gauge(0..110) 0-100
Gauge(40..400) 40-400
Gauge(20..100 | 110..120) 20-100 und 110-120
Gauge( 0 | 2 | 4 | 6 | 8 | 10) Nur 0, 2, 4, 6, 8, und 10
Gauge( 0 | 5..10) 0 oder 5-10
Gauge(12) Nur 12

 

Wie bereits besprochen, bleibt der Wert eines GAUGE stehen, wenn der durch das "subtyping" festgelegte Bereich, über- bzw. unterschritten wird. Wie man aus der Tabelle ersehen kann, kann man den Bereich entweder zusammenhängend oder fragmentiert definieren. Es werden aber immer nur Variablen abgespeichert, die im durch das "subtyping" festgelegten Bereich liegen.

4.4 Scalar und Columnar MIB Variablen (Nicht-tabellarische und tabellarische MIB Variablen)   

Das Vorkommen einer Variablen in einer MIB wird als "Instance" (Instanz) dieser Variablen bezeichnet. Eine scalar Variable hat nur eine instance in einer MIB. Columnar Variablen haben 0 oder mehrere instances und sind immer in Form einer eindimensionalen Liste oder einer zweidimensionalen Tabelle angeordnet.

Auf jede scalar Variable wird in ihrer OID und ihrem instance identifier eingegangen. Ein instance identifier ist eine positive INTEGER, ein OCTET STRING oder der Wert einer OBJECT IDENTIFIER und wird immer an das Ende einer OID angehängt. Dies könnte zum Beispiel so aussehen :

       <OBJECT IDENTIFIER>.<instance identifier>

Der instance identifier wird dazu genutzt, die spezielle instance einer MIB Variablen, eindeutig zu identifizieren. Eine scalar Variable wird durch das anhängen von ".0" an die OID gekennzeichnet.

Ein Beispiel :
Wenn Sie zum Beispiel ein GetRequest Operation auf ein gemanagtes Objekt, lokalisiert mit der OID 1.3.6.1.2.1.4.1, ausführen wollen, müssen Sie den instance-Wert des Objektes mit 1.3.6.1.2.1.4.1.0 spezifizieren. Wenn Sie dies vernachlässigen, kann der Agent das Objekt nicht zuordnen, und sie bekommen eine  noSuchName Fehlermeldung.

Columnar Objekte werden immer mit einer ".1" spezifiziert.

Lists und Tables

SMI definiert  zu den einfachen Datentypen zusätzlich strukturierte Datentypen. Diese werden in Form von geordneten Listen (Lists) und Tabellen (Tables) angegeben. Eine solche (eindimensionale Liste) besteht aus einer Sammlung von MIB Variablen, die eben in dieser Liste angeordnet sind. Die Liste muss aus einer oder mehreren Variablen bestehen, wobei die Variablen vom INTEGER, OCTET STRING, OBJECT IDENTIFIER oder anderen APPLICATION Datentypen sein müssen. Eine list ist einer struct in C sehr ähnlich.

Eine Tabelle ist eine zweidimensionale Sammlung von Listen, oder einfacher Ausgedrückt, eine Liste von geordneten Listen. Jede Liste (es können 0 oder mehrere sein) wird als eine "Row" bezeichnet. Alle rows in einer Tabelle sind vom selben Format. Eine table ist mit einem  array von structs in C zu vergleichen. 

In den meisten MIB-Definitionen werden Listen und Tabellen als Tabellenkalkulationen beschrieben und benutzt. So kann man mit ihnen z.B einen Report über die corrent alarms eines Knoten, eine Liste der Anmeldungen an einem Server oder eine Statistik über alle aktiven TCP connections, führen. Tabellen speichern und verwenden Daten wie z.B das Relational Database Model.

Mehr kreative Verwendung finden diese strukturierten Typen in Konstruktionen wie linked (verbundenen) Listen usw.

Durch die Nutzung von ASN.1 SEQUENZE Typen deklarieren Sie die list objects. Mit SEQUENZE werden die MIB Variablen, die die Liste beinhaltet, deklariert. Sie können sich eine SEQUENZ wie eine Aufzeichnung in einer Datenbank vorstellen, wobei, wie im folgenden Beispiel gezeigt, jede MIB Variable ein Bereich/ein Feld  in der Aufzeichnung ist.

                Employee   : : =  SEQUENZE  {
                    id                   INTEGER,
                    level               INTEGER,
                    fullName        DisplayString,
                    address          DisplayString
                }

Die Liste beginnt mit einem SEQUENZE identifier, welcher laut Konvention, mit einer großgeschriebenen Buchstaben beginnen muss. Jedes Mitglied in einer Liste deklariert sich durch die Nutzung eines member identifier und eines data typs (Datentyps). Der member identifier beginnt stets mit einem kleingeschriebenen Buchstaben. Jedes Mitglied ist eine unabhängig adressierbare columnar variable, die unbedingt durch die Nutzung eines OBJECT-TYPE Makro definiert werden muss. Listenmitglieder werden von einer Vielfalt von Namen beschrieben.

Das nächste Beispiel zeigt eine list, die zwei INTEGER Variablen beinhaltet :

                intList OBJECT-TYPE
                    SYNTAX         IntList
                    ACCESS         not-accessable
                    STATUS         mandatory
                    DESCRIPTION
                        "Eine Liste, die zwei INTEGER Werte beinhaltet."
                    : : =  {  myMib  1}

                IntList   : : =  SEQUENZE  {
                    intValue1         INTEGER,
                    intValue2         INTEGER
                }

                intValue1   OBJECT-TYPE
                    SYNTAX         INTEGER
                    ACCESS         read-write
                    STATUS         mandatory
                    DESCRIPTION
                        " Eine INTEGER Variable."
                    : : =  {  intList  1  }

                intValue2     OBJECT-TYPE
                    SYNTAX         INTEGER
                    ACCESS         read-write
                    STATUS         mandatory
                    DESCRIPTION
                        " Eine weitere INTEGER Variable."
                    : : =  {  intList  2}

Das intList Objekt ist die Definition der Liste. Durch seine Definition erklärt es sich selbst zu einem Objekt, das auf dem IntList-Typ basiert. Die ACCESS (Zugangs) Funktion wurde als not-accessable (nicht zugreifbar) deklariert, da strukturierte Typen keine scalar variables sind und daher nicht direkt auf sie zugegriffen werden kann. Die IntList SEQUENZE beinhaltet die Deklaration der Variablen, die in der Liste enthalten sind. Die IntValue1 und IntValue2 OBJECT-TYPE Makros sind die aktuellen Definitionen der scalar variables in der Liste.

Eine Listing, wie das obige, ordnet eine Ansammlung von scalar MIB variables in eine geordnete Liste.

Folgend stelle ich das Listing für intList in C vor :

                struct   {
                    long   intValue1;
                    long intValue2;
                }   intList;

Wenn wir intList nun grafisch darstellen, würden wir eine Tabelle mit nur einer row (Zeile/Reihe) sehen :

intValue1 intValue2

Tabellen werden aber zum speichern von mehr als einer Reihe (row) Daten benutzt. Um ein Tabellen Objekt (table object) zu deklarieren, benutzt man den ASN.1 SEQUENCE OF Typ. Mit SEQUENCE werden die einzelnen Objekte für eine einzelne Liste deklariert, mit SEQUENZE OF wird ein Objekt als Tabelle, eine Liste von Listen, deklariert. Wenn Sie bei einer Liste an einen eindimensionalen array denken, so ist eine Tabelle der array eines arrays.

Eine SEQUENCE kann nur für einer Tabelle genutzt werden. Wenn nun aber eine MIB mehrere identischeTabellen benötigt, braucht jede einzelne Tabelle eine eigene SEQUENZ, obgleich die Tabellen alle identisch sind. Diese Beschränkung gilt für alle Mitglieder diese Tabelle. Eine einzelne Variablen Definition kann nicht zwischen mehreren SEQUENZE Definitionen aufgesplitet werden. Jedes entry member (oder columnar variable), das in einer SEQUENZE deklariert wurde, benötigt seine eigene OBJECT-TYPE Definition. Tabellenmitglieder werden ebenfalls von einer Vielzahl von Namen beschrieben.

Jetzt modifizieren wir das vorhergehende Listing, um eine richtige Tabelle zu erstellen :

                intTable         OBJECT-TYPE
                    SYNTAX         SEQUENCE OF intTableEntry
                    ACCESS         not-accessable
                    STATUS         mandatory
                    DESCRIPTION
                        "Eine Tabelle von INERGER Werten."
                    : : =  {  myMib 1}

                intTableEntry OBJECT-TYPE
                    SYNTAX         IntList
                    ACCESS         not-accessable
                    STATUS         mandatory
                    DESCRIPTION
                        "Eintrag in die intTable Tabelle. Jeder Eintag beinhaltet
                        einen Index (intEntryId) sowie zwei INTEGER Werte."
                    INDEX
                        {   intEntryId  }
                    : : =  {  intTable 1  }

                intList   : : =  SEQUENCE  {
                    intEntryId         INTEGER,
                    intValue1          INTEGER,
                    intValue2          INTEGER
                }

                intEntryId OBJECT-TYPE
                    SYNTAX         INTEGER
                    ACCESS         read-only
                    STATUS         mandatory
                    DESCRIPTION
                        "Tabellen Eintrag Index Wert."
                    : : =  {  intTableEntry 1  }

                intValue1 OBJECT-TYPE
                    SYNTAX         INTEGER
                    ACCESS         read-write
                    STATUS         mandatory
                    DESCRIPTION
                        "Ein INTEGER Wert"
                    : : =  {   intTableEntry 2  }

                intValue2   OBJECT-TYPE
                    SYNTAX         INTEGER
                    ACCESS         read-write
                    STATUS         mandatory
                    DESCRIPTION
                        "Noch ein INTEGER Wert"
                    : : =  {  intTableEntry 3  }

Um intList in intTable zu konvertieren, müssen folgende Kriterien erfüllt werden :
Sie müssen eine Definition für das intTable Objekt hinzufügen
Eine INDEX Klausel in die SEQUENCE Definition einbeziehen
Eine Variable in die SEQUENCE Deklaration einbringen

Sie können anhand des SEQUENCE OF intTableEntry SYNTAX im intTable Objekt ersehen, daß es sich bei dieser Tabelle um eine Liste von intTableEntry Objekten handelt.

Da intTable keinen oder mehrere intTableEntry haben kann, muss mit Hilfe eines Index jede Zeile/Spalte der Tabelle adressiert werden. Daher sorgt man für eine Deklaration, aus der hervorgeht, daß eine oder mehrere der MIB Variablen in der intList als Index in der Tabelle genutzt werden. In der intTable z.B. deklariere ich den Index dazu, die INDEX Klausel im intTableEntry Objekt zu nutzen.

Folgend werde ich Ihnen eine mögliche Ansicht der resultierenden Tabelle anzeigen :

Row 1
Row 2
Row 3
Row 4
intEntryId = 1
intEntryId = 2
intEntryId = 4
intEntryId = 7
intValue1 = 10
intValue1 = 9
intValue1 = 10
intValue1 = 85
intValue2 = 34
intValue2 = 10
intValue2 = 22
intValue2 = 22

Wie Sie aus der Tabelle entnehmen können, beinhaltet sie 4 identische Kopien der intTableEntry Liste. Das kommt daher, da das Format jeder row identisch ist. Jedes Mitglied einer Tabelle ist eine unabhängige (augenblicklich betrachtete) "columnar" Variable, die zu einem bestimmten Zeitpunkt erfasste Daten abspeichert. Der Unterschied zu anderen MIB-Variablen ist, daß die Mitglieder einer Tabelle eben durch diese Tabelle oder durch SNMP Operationen bezeichnet und oder übersichtlicher dargestellt werden.

Jedes Mitglied der Tabelle wird darauf verwiesen, die Werte des oder der Tabellen Index(e) als instanc identifier zu nutzen. Wie ich schon vermerkt habe, besitzt eine scalar variable nur eine instanc (Instanz). Dies wird durch das anhängen von ".0" an die OID der Variablen gekennzeichnet. Die Variablen in der Tabelle können aber 0 oder mehrere instances besitzen. Um daher eine spezielle Variablen-Instanz (instanz) adressieren zu können, wird der Index der row an die OID angehängt.

Wenn wir z.B. auf  intValue2 in der row 3 verweisen wollen wird :

                                    intValue2.4

an die OID angehängt . Bei intEntryId  in der row 1 würde der "Anhängsel" :

                                    intEntry.1

lauten.

Die INDEX-Klausel in der SEQUENZE-Objekt Definition bestimmt, welche Mitglieder der Tabelle als Index anzusehen sind. Der Wert einer jeden Instanz eines jeden Mitgliedes (das als Index anzusehen ist) muss gegenüber seiner anderen Instanzen einmalig sein. Eine Tabelle mit identischen Index Werten kann nicht richtig ausgeführt werden.

In intTable sind die Index-Mitglieder vom INTEGER Datentyp, mit den Werten 1,2,4 und 7. Die Werte der Indexe müssen nicht sortiert oder fortlaufend sein.  Die einzigen Einschränkungen für den Wert der Indexe ist, daß sie einmalig und nicht mit der Ziffer "0" bezeichnet werden. Wenn man den Datentyp des Index von INTEGER auf OCTET STRING ändern würde, könnte man Bezeichnungen wie "Gert", Diether" oder "Martin" als Bezeichnung für die rows abspeichern. Damit wird wohl auch klar, warum die Reihenfolge bei Zahlen nicht wichtig ist.

Beachten Sie, daß Listen keine INDEX-Klausel benötigen, da sie immer nur einer Instanz einer Variablen beinhalten. Dies ist auch der Grund, warum die Mitglieder einer Liste immer die Bezeichnung ".1" an ihrer OID tragen.

Jeder Index, der in einer Tabelle definiert wird, erhöht die Anzahl der Dimensionen in ihr um 1. Ein allgemein bekanntes Beispiel einer Multi-Index Tabelle ist die tcpConnTable. Sie wird in der TCP Gruppe von MIB-II definiert. Diese Tabelle verweist auf vier Index-Werte, welche die Adressen und Ports der lokalen und entfernten Enden einer jeden TCP Verbindung darstellen. Der Syntax des Verweis lautet wie folgend :

                        tcpConnTable.<local IP addr>.<local port>.<remote IP addr>.<remote port>

Um auf die tcpConnState Variable einer speziellen Verbindung zu verweisen, benötigen Sie die IP Adressen und die Ports von eben dieser Verbindung. Hier ist der etwas ungewöhnlich anzusehende Verweis :

                       tcp.tcpConntable.tcpConnEntry.tcpConnState.199.35.10.47.139.199.35.12.25.1029

Achten Sie immer darauf, daß Sie es nicht versäumen, Tabellen-Indexe zu setzen. Sie müssen alle Indexe, die durch einen table entry definiert wurden, genau spezifizieren, um später mit ihnen auf eine Tabellen Variable verweisen zu könnnen.

An diesem Punkt angekommen, fragen Sie sich jetzt vielleicht, " Wo wird in der MIB eigendlich die Anzahl der rows festgelegt ?"  In unserem vorher vorgestellten Beispiel sieht es so aus, als ob ein subtyping festlegt, wie viel rows in der Tabelle enthalten sind. Wie dem auch sei, SMI definiert keine Konstruktion, mit der man die Anzahl der rows festzulegen hat. Wenn Sie RFC 1212 zu Rate ziehen, werden Sie ihr lediglich entnehmen, daß eine Tabelle 0 oder mehrere rows und jede row eine oder mehrere columnar scalar objects, enthalten darf. Dieser Effekt macht die Anzahl der rows in einer Tabelle zu jedem beliebigen Zeitpunkt "Ausführungs/Durchführungs-Abhängig".

Nun wundern Sie sich, wie Sie die Variablen in einer Tabelle den lesen oder verändern können, wenn Sie nichts über den Index-Wert der rows, der rows selbst bzw. die Mitglieder dieser row wissen. Die Magie, mit deren Sie dies bewerkstelligen können, nennt sich "GetNext Operation". (Auf sie gehen wir später ein)

Tabellen und Listen sind für voll und ganz für das Erzeugen von komplexen Datenstrukturen und deren Arrays geschaffen. Aber wie ist es mit dem Erzeugen von einfachen Arrays ?

Nach der Definition von ASN.1 wird SEQUENCE OF zum kreieren von Listen mit einem einzigen Datentyp verwendet. So benötigen wir für die Deklaration eines Arrays von INTEGER-Werten lediglich dieses einfache Listing :

                MyArray     : : =    SEQUENCE OF INTEGER
                MyArray   myArray    : : =    {    1, 1, 2, 5, 7, 9    }

                intArrayTable     OBJECT-TYPE
                        SYNTAX         MyArray
                        ACCESS          read-only
                        STATUS          mandatory
                        DESCRIPTION
                            "Ein Array von INTEGER-Werten"
                        : : = {    myMib 1    }

Dies funktioniert leider nur unter ASN.1 einwandfrei. Das subset von ASN.1, welcher für SNMP in SMI definiert wurde, erlaubt SEQUENCE OF nur die Spezifizierung des SEQUENZE-Typ. Um einen Array auf INTTEGER, OCTET STRING oder OBJECT IDENTIFIER zu definieren, müssen wir eine Tabelle definieren. In dieser Tabelle muss ein Mitglied zur Speicherung der INTEGER-Werte, sowie ein weiteres Mitglied zur Speicherung des Indexes vorhanden sein. Wenn Sie aus unserem Beispiel (intTable) das "intValue2"-Mitglied entfernen, besitzen Sie eine Tabelle, die Sie als Array auf einen INTEGER-Wert nutzen können.

Bevor Sie jetzt loslegen, und alle diese "cleveren" Dinge mit Listen und Tabellen ausprobieren, möchte ich Ihnen noch einige Einschränkungen von SMI vorstellen :
Aufzählende textliche Konventionen sind innerhalb einer SEQUENCE nicht gestattet. Beispiel :

        Employee    : : =     SEQUENCE    {
                id                 INTEGER,
                level            INTEGER    {     director(1),  manager(2),   grunt(3)    }

        }
Wenn Sie das Mitglied einer SEQUENCE deklarieren, wird das subtyping üblicherweise in der OBJECT-TYPE Definition jedes Mitgliedes ausgeführt. Niemals in der Mitglieds-Deklaration selbst. In der SEQUENCE Definition können textliche Konventionen ohne weiteres angewandt werden :

        IdType    : : =     INTEGER (0..6 )
        LevelType    : : =     INTEGER    {    director(1) ,   manager(2) ,  grunt(3)    }
        Employee    : : =     SEQUENCE    {
                id                 IdType,
                level            LevelType
        }
Sie können keine SEQUENCE in einer SEQUENCE "einnisten". Oder mit anderen Worten, dies können Sie nicht in einer SNMP MIB ausführen :

        Employee    : : =     SEQUENCE    {
                fullName         DisplayString,
                Address     : : =    SEQUENCE    {
                        street         DisplayString,
                        city            DisplayString
                        state          DisplayString
                        zipCode    DisplayString
                 }
        }
Ebenso dürfen Sie keine Tabelle in einer Tabelle "einnisten". Unter ASN.1 wäre das "einnisten" von SEQUENCE oder SEQUENCE erlaubt, wird aber, um die Komplexität von SNMP "kleinzuhalten", von SMI nicht gestattet.

Wenn Ihnen diese "Liste in Liste" bzw. "Tabelle in Tabelle" Verbote zu intolerant vorkommen, bedenken Sie, daß durch die Nutzung von gemeinsamen oder multiplen Index-Werten, mehrere Tabellen miteinander verbinden können.

Object Identifier (Objekt Bezeichner)

Jede Variable, die innerhalb einer MIB definiert wird, besitzt einen einmaligen Objekt Bezeichner (auch OID genannt). Eine OID ist die Stelle/der Platz eines gemanagten Objektes innerhalb des MIB Namensraum (namespace). Sie ist analog dazu die Adresse der Variablen im Speicher oder deren Pfadname im Dateiensystem. Die OID wird auch als die Identität des Objektes bzw. die Registration des Objektes bezeichnet.

OIDs werden in einer von Oben nach Unten hierarischen Struktur dargestellt. Diese Struktur ist mit dem File-System von MS-DOS, der Registry von Windows oder Unix zu vergleichen. Wenn man das ganze Filesystem "auseinandergefaltet" betrachtet, spricht man von einem "Directory Tree" (Verzeichnis Baum).

Der OID-Baum beginnt mit dem root und verzweigt sich dann abwärts in branches (Zweige,Äste). Jeder Punkt im OID-Baum wird als ein Node (Knoten) bezeichnet. Jeder Node beinhaltet einen oder mehrere branches oder endet mit einem leaf node (wörtlich übersetzt "Blatt-Knoten"). Nur diese sogenannten leaf nodes beinhalten Management Daten. Eine Ansammlung solcher OIDs wird als "MIB Namespace" oder als "Subtree" des gesamten OID-Baumes bezeichnet. Der gesamte OID-Baum (vom root aus abwärts betrachtet) wird als MIB naming tree bezeichnet. Die folgende Grafik zeigt einen solchen OID-Baum :

 

grafik_9.jpg (17329 Byte)

MIB naming tree (Grafik 9)

An der Spitze des MIB naming tree befindet sich root. Aus dem root verzweigen sich drei "Kinder", welche die OID ccitt(0), iso(1) und joint-iso-ccitt(2) tragen. Alle OIDs beginnen mit einer dieser drei branches. Root selbst trägt keine OID und ist daher nicht adressierbar.

Jeder Node wird durch eine Ziffernkombination, die aus einer positiven 32 Bit-Integer besteht, bezeichnet. Diese Bezeichnung wird subidentifier genannt. Alle OIDs werden (vom root aus beginnend) als Sequenz in "Dot-Schreibweise" (durch Punkt(e) getrennt) geschrieben :

                1.3.6.1.2.1.1.2

Jedem node kann ebenfalls eine für Menschen verständlicher Namen zugeordnet werden. Wenn es sich bei diesem Node um einen branch (Zweig)handelt, ist der Name eine textliche Konvention. Wenn es sich um ein leaf object handelt, ist es eine Objekt-Beschreibung. Subidentifiers können mit beiden Schreibweisen gemischt bezeichnet werden. Bei dem folgendem Beispiel handelt es sich um immer um das selbe MIB-Objekt :
               
                1.3.6.1.2.1.1.2
                1.3.6.1.2.1.1.sysObjectID
                iso.org.dod.internet.mgmt.mib-2.1.2
                iso.org.dod.internet.mgmt.mib-2.system.sysObjectID
                iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysObjectID(2)

Sie werden festgestellt haben, daß es gewisse Ähnlichkeiten zwischen den OIDs und den Notationen von MS-DOS, Unix oder der Registry von Windows gibt.

Das Internet Standart Netzwerk Management ist unter dem iso(1) branch definiert. Somit ist es äußerst praktisch, daß alle OIDs mit denen Sie es zu tun haben, mit 1.3.6.1. beginnen. Von SNMP aus gesehen, werden Sie immer mit dem mib(1.3.6.1.2.1) oder enterprise(1.3.6.1.4.1) arbeiten.

Eine Liste der aktuellen Enterprise-Mibs können Sie hier einsehen!!!!

Da wir uns nun genug mit den verschiedenen Typen von Datenstrukturen und Datenformaten beschäftigt haben, werden wir uns jetzt näher mit den Nachrichten, mit deren Hilfe Informationen zwischen SNMP Management Systemen und Agenten ausgetauscht werden, beschäftigen. Daher heißt das nächste Kapitel auch :

           Die SNMP Nachricht

Weiter