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.
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). |
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 :
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