Home

 

4.5 Die SNMP Nachricht        

Alle Informationen, die das SNMP Protokoll verwenden und zwischen den verschiedenen Hosts in einem Netzwerk ausgetauscht werden, haben das Format von SNMP Nachrichten (SNMP Messages). In einem TCP/IP Netzwerk sind die SNMP Nachrichten stets in dem Payload eines UDP-Datagramms eingekapselt. Die komplette SNMP Nachricht ist immer BER verschlüsselt. Wenn Sie BER nicht fließend verstehen, ist es Ihnen vielleicht eine kleine Hilfe, die Nachricht in den Hex-Code umzuwandeln. In diesem Fall benötigen Sie dann die Hilfe eines Protokoll Analyser. Der Analyser stellt Ihnen die SNMP-Nachricht in Hex und die Informationen, die sie enthält, in einer für Menschen verständlichen Form dar.

Die Empfehlung vieler SNMP Profis ist :
Nutzen sie beides. Einen Protokoll-Analyser und die Fähigkeit, die jeder SNMP-Anwender haben sollte, nämlich BER zu lernen. Somit können Sie die Nachrichten auf doppelte Weise überprüfen. Bedenken Sie immer, daß ein Protokoll-Analyser auch nur von Menschen entwickelt wurde und daher auch Bugs enthalten kann.

Die SNMP-Nachricht, die folgend abgebildet wurde, besteht aus einer sehr simplen preamble, der ein Application Protocol Data Unit (APDU) oder auch SNMP-PDU genannt, folgt. Die preample beinhaltet Informationen, mit deren Hilfe die Gültigkeit der SNMP Nachricht überprüft wird (weiteres darüber später). Der PDU header beinhaltet Informationen speziell zur SNMP Nachricht. Das könnten   Informationen wie z.B.welche Operation ausgeführt werden soll usw. sein. Der PDU body (PDU Körper) beinhaltet die aktuellen Daten, die zur Ausführung eben dieser Operation notwendig sind.

Message Length SNMP Message Preamble
Message Version
Community String
PDU Header SNMP Protocol Data Unit
 

PDU Body

 

SNMP Nachricht (Grafik 10)

SNMP Message Preample

Die SNMP message preample enthält 3 Felder (jede SNMP Nachricht beinhaltet die gleiche preample).

                Message Length
                        Ein 16-Bit Integer, mit dessen Hilfe die absolute Länge der Nachricht in Oktetten angegeben wird. Von ihr
                        werden 2 Oktetten abgezogen, da die Größe dieses Feldes nicht mit eingerechnet wird.

                Message Version
                        Dieses Feld beinhaltet ein einzelnes Oktett, mit dessen Hilfe die Version des SNMP Protokolls
                        angegeben wird. Gültige Werte sind "0" für SNMPv1, "1" für SNMPv2 und so weiter.

                Community String
                        Dies ist die Sequenz von Oktett-Werten, mit deren Hilfe die Management Community des
                        Hosts angegeben wird, der die Nachricht empfangen soll. Dieses Feld variiert in seiner Länge, sollte aber
                        besser nicht länger als 128 Oktetten sein (was es normalerweise auch nicht der Fall ist)

 

Beachte

SNMP Management System müssen keine SNMP Nachrichten, die größer als 484 Bytes sind, unterstützen. Normalerweise sind sie jedoch so ausgelegt, daß sie solche übergroßen Nachrichten dennoch bearbeiten. Sie sollten jedoch bedenken, daß Agents, die auf sehr kleinen Systemen ausgeführt werden, solche Nachrichten nicht unterstützen können. Agents, die dagegen auf Arbeitsstationen mit genügend Speicher und Rechenpower ausgeführt werden, kommen selbst mit viel größeren Nachrichten zurecht.

 

 

SNMP Protocol Data Unit

Ein PDU ist ein unabhängiger Block von Informationen, der zwischen zwei oder mehr Einheiten, die ein Kommunikations- Protokoll (wie z.B. der Netzwerk Service in einem Protokoll Stack) verwenden, austauscht wird. Jedes Protokoll definiert einen oder mehrere PDUs, mit deren Hilfe Informationen ausgetauscht werden. Da wir die PDUs die von Ethernet, IP und UDP genutzt werden, schon besprochen haben, wenden wir uns nun den SNMP PDUs zu.

SNMPv1 definiert mit RFC 1157 fünf verschiedene PDUs :

GetRequest

GetNextRequest

SetRequest

GetResponse

Trap

Jede PDU ist eine "Schablone" die von einem SNMP Management System oder einem Agent mit Daten "angefüllt" und dann abgesendet wird. Der populärste Weg, die Datenstruktur einer PDU darzustellen, ist die Verwendung der ASN.1-Notation. Sie wird in RFC 1157 definiert und wird am meisten angewandt. Diese ASN.1 Illustration zeigt jedoch nur die PDU-Felder an, die speziell die Management-Informationen enthalten. Sie lässt die Low-Level Informationen, die für das Protokoll selbst wichtig sind, außen vor. Und da Sie bestimmt noch nicht so sehr mit ASN.1 vertraut sind, benutzte ich folgendes Blockdiagramm um die Innereien, SNMP Nachrichten und PDUs darzustellen :

 

Message Length SNMP Message Preamble Message Length
Message Version Message Version
Community String Community String
PDU Type PDU Header PDU Type
PDU Length
PDU Length
Enterprise MIB OID
Request ID
Agent IP Address
Standard Trap Type
Error Status
Specific Trap Type
Error Index
Time Stamp
PDU Body
Length of Variable Bindings Length of Variable Bindings
Length of First Binding Length of First Binding
OID of First Binding OID of First Binding
Type of First Binding Type of First Binding
Value of First Binding Value of First Binding
Length of Second Binding Length of Second Binding
OID of Second Binding OID of Second Binding
Type od Second Binding Type od Second Binding
Value of Second Binding Value of Second Binding
Additional Variable
Bindings
Additional Variable
Bindings
GetRequest
GetNextRequest
SetRequest
GetResponse
Art der SNMP Nachricht Trap

 

Blockdiagramm der Request und Trap Felder (Grafik 11)

 

PDU header

Bei den Request- und Response-Nachrichten ist der Header stets der gleiche. Der Trap-Header ist jedoch sehr unterschiedlich zu dem der anderen Messsages. Dies ergibt sich aus der speziellen Nutzung der Trap-Message. Wie Sie aus der Abbildung entnehmen können, sind die ersten beiden Felder der PDU identisch :

        PDU Type
               Zeigt auf den Typ, der von dieser Message dargestellten SNMP-Operation.
                Folgende Werte sind erlaubt und von RFC 1157 definiert :
                       
                        0     getRequest
                        1     getNextRequest
                        2     getResponse
                        3     setRequest
                        4     trap

        PDU Length
                Die Länge, der nach dem PDU length field folgenden SNMP-Nachricht. Dieser "Rest" der Nachricht
                wird in Oktetten angegeben.

Die folgenden Felder kommen nur in einer Trap-Nachricht vor.

        Enterprise MIB OID
                Die OID der management enterprise, welche die Trap-Nachricht definiert. Dieser Wert stellt sich
                als ein OBJECT IDENTIFIER Wert mit variabler Länge dar.

        Agent IP Adress
                Die Netzwerk Adresse des Agents, der die Nachricht erstellt hat. Dieses Feld beinhaltet die IP Adresse
                in Form eines OBJECT IDENTIFIERS.  Wenn der Agent sich in einem Netzwerk befindet, daß nicht
                mit IP sondern mit z.B. IPX arbeitet, stellt sich der Wert der Adresse mit Nullen dar (0.0.0.0).

        Standart Trap Type
                Identifiziert den Typ der Trap-Nachricht. Folgende Werte sind definiert :

                        0     coldStart
                        1    warmStart
                        2     linkDown
                        3     linkUp
                        4     authenticationFailure
                        5     egpNeighborLoss
                        6     enterpriseSpecific

        Specific Trap Type
                Zeigt auf die besondere Trap, die in einer besonderen Händler MIB definiert wird. Auf dieses Feld
                wird verwiesen, wenn der Wert des "Standart Trap Type"-Feldes 6 ist. In diesem Fall ist der Wert
                im "Specific Trap Type"-Feld größer Null, und zeigt mit ihrem Inhalt auf die besondere MIB,
                 die die Trap definiert. Ist der Wert im "Standart Trap Type"-Feld ungleich 6, so wird der Wert im
                "Specific Trap Type"-Feld auf Null gesetzt und nicht weiter beachtet.

        Time Stamp
                Ein positiver 32-Bit Wert, der die Anzahl der 1/100 Sekunden angibt, die seit dem (Neu)Start des
                SNMP-Agents und dem Senden dieser Trap-Nachricht vergangen sind. Dieses Feld wird mit dem Wert
                der sysUpTime-Variablen zum Zeitpunkt des Sendens der Trap initialisiert.

Diese folgenden Felder sind in den  PDUs aller SNMP Request- und Response-Nachricht definiert (also nicht in den PDUs der Trap)

        Request ID
               
Ein Handshake-Wert, mit dessen Hilfe eine Response-Nachricht mit einer Request-Message aufeinander
                abgestimmt werden. Dies ist vor allen dann sehr hilfreich, wenn eine Management-System mehrfach
                Request-Nachrichten zur selben Zeit sendet und die empfangenen Response-nachrichten den verschiedenen
                Request-Nachrichten wieder zuordnen muss (auf dieses Kapitel werden wir später noch genauer eingehen).

        Error Status
                Der Wert in diesem Feld informiert über den Erfolg oder den Fehlschlag der SNMP Operation. Werte ungleich
                Null weisen auf ein Fehlschlag hin. Folgend die möglichen Werte (definiert von RFC 1157), die in diesem Feld
                enthalten sein dürfen :

 

Wert Nachricht Beschreibung

0

noError Operation war erfolgreich. Keine Fehler

1

tooBig Die Nachricht ist zu groß, um versendet zu werden

2

noSuchName Diese spezielle OID wird nicht von dem Agent unterstützt, oder es liegt keine "next" OID bereit.

3

badValue Der Wert oder der Datentyp der gewählt wurde, ist nicht korrekt

4

readOnly Der Versuch, in eine Variable, die read-only deklariert ist, zu schreiben

5

genErr Ein nicht bekannter (beschreibbarer) Fehler ist beim lesen oder schreiben einer MIB Variablen aufgetreten.

       Error Index
               
  Dieser Index hat nur einen einzigen Eintrag. Der Wert gibt die Nummer der Variablen an, in der der Fehler
                 aufgetreten ist.  Hat der Eintrag den Wert "1", handelt es sich um die erste Variable. Bei "3" ist es die dritte
                 Variable usw. Ist der Wert  von Error Status ungleich "0", der Wert von Error Index jedoch  "0", so konnte
                der Fehler nicht lokalisiert, bzw. es handelt sich um einen unbekannten Fehler, der nicht zugeordnet werden konnte.
                Oft handelt es sich dann um einen  tooBig oder genErr-Fehler.

Request ID

Die meisten High-Level Kommunikations- Protokolle definieren ein header field. Es befinden sich Handshake Informationen, mit deren Hilfe Response-Nachrichten die passende Request-Nachricht finden. Bei dieser Information handelt es sich um ein Synchronisations - Wert oder eine "Beziehungsetikette" (correlation tag). Bei der SNMP Nachricht ist dieser Wert im "Request ID"-Feld der Request- und GetResponse-Nachricht, gespeichert.

Die Request ID wird von vielen SNMP-Autoren etwas "stiefmütterlich" behandelt. Dies kommt daher, da das "Request ID"-Feld keine wichtigen Management Daten speichert. Dennoch ist es ein wichtiger Teil des Handshake-Mechanismus. Der Agent nutzt dieses Feld nicht selbst, sondern kopiert dessen Wert in das "Request ID"-Feld der Response-Nachricht, die er dann an den anfragenden Node sendet.

Das Management System nutzt die Request ID um die Response-Nachricht der richtigen Request-Nachricht zuzuordnen.

Ein Beispiel :
Stellen Sie sich vor, daß ein Management System drei GetRequest-Nachrichten, mit den ID-Werten 123, 234 und 345, sendet. Beim Absenden der Anfragen wird ein Timer (für jede Anfrage) gestartet. Das System identifiziert die Antworten mit Hilfe derer ID und kann anhand der Zeitspanne die Verzögerung zwischen Senden und Empfangen feststellen.

Jede dieser Nachrichten werden von dem Agent, der sie empfangen hat, bearbeitet. Bevor er dann die Antwort an das Management System sendet, kopiert er die ID in die GetResponse-Nachricht. Danach wird sie abgesendet. Das Management System ordnet dann die Response-Nachricht dem richtigen Timer zu, speichert den Wert und löscht den Timer. Ist der Timer vor dem Empfangen der Nachricht abgelaufen, wird diese als verloren deklariert und eine erneute Anfrage wird gesendet. Wird eine festgelegte Anzahl von Anfragen nicht beantwortet, schließt das System daraus, daß der Agent nicht bereit ist, beendet daraufhin das Senden von Anfragen und meldet dies dem Netzbetreuer.

Die Request ID der Request-Nachricht wird auch zur Identifizierung des Prozesses, der sie erstellt hat genutzt.

Ein Beispiel :
Nachricht 123 wurde zum Registrieren aller betriebsbereiten Geräte, Nachricht 234 zum Erfragen der Fehlermeldungen und 345 zum Sammeln von Performance Daten, gesendet. Wie Sie sehen können, wurden diese Anfragen von verschiedenen Prozessen (auch threads genannt) erstellt. Mit Hilfe ihrer IDs können die Response-Nachrichten zu den richtigen threads geroutet und ausgewertet werden.

Dies alles kann nur dann geschehen, wenn das Management System die Request ID auslesen und zuordnen kann. Viele SNMP-APIs generieren automatisch eine ID und versehen diese mit einem read-only Status. Somit ist sichergestellt, daß diese nicht von Management Anwendungen verändert werden kann.

 

Variable bindings

Die variable bindings (oder kurz varbinds) sind die eigentlichen/wirklichen Daten-Payloads einer jeden SNMP Request- oder Response-Nachricht. Alle Management-Daten die eine SNMP-Nachricht transportiert, werden in der varbinds list gespeichert. Jede SNMP Nachricht, mit Ausnahme der Trap-Nachricht, beinhalten mindestens eine varbind. Die meisten SNMP-Nachrichten wären nutzlos, wenn sie keine Management-Daten transportieren würden.

Die varbinds erhielten ihren Namen, da sie eine OID (oder eine Identität) mit einem Wert binden.

Zur Erinnerung:
Mit der OID wird ein gemanagtes Objekt in einer MIB definiert.  Der Inhalt könnte ein ASN.1 scalar data type oder ein ASN.1 NULL (falls kein Wert gespeichert werden soll) sein. Wenn Daten gespeichert sind, muss der Datentyp in der "Bindung" übereinstimmen. Die Größe und die Anzahl der Bindungen, die jede PDU beinhaltet, sind variabel.

Es ist keine Feld in der PDU enthalten, welches die Anzahl der varbinds in einer PDU anzeigt. Varbinds werden mit "eins" beginnend aufgezählt. Die Anzahl der varbinds ist nicht festgelegt. Sie werden jedoch schnell von den Einschränkungen, seitens SNMP-Agents und dem Netzwerk, in Ihre Schranken verwiesen.

SNMP garantiert, daß die Reihenfolge der varbinds in einer GetResponse-Nachricht die selbe bleibt, wie die der vorher eingegangenen Request-Nachricht. In welcher Ordnung sie die varbinds in einer Request-Nachricht anordnen, hat keinerlei Bedeutung für den Agent.

 

SNMP Request-Nachrichten

Jede SNMP Operation wird durch das Senden einer SNMP Request-Nachricht an einen Agent eingeleitet. Die Request-Nachricht beinhaltet Informationen, mit deren Hilfe der Agent speziell geforderte Operationen ausführen kann. Es wurde jeweils eine Request-Nachricht pro SNMP Operation definiert. Obgleich alle Nachrichten das selbe "SNMP Nachrichten" -Format nutzten,  hat jede ihre besonderen Charaktere und Probleme.  Diese sind meist vom Verhalten der SNMP Operationen selbst abhängig.

GetRequest Nachricht

Die GetRequest-Nachricht wird für das anfordern von Daten eines gemanagten Objektes, welches von einem Agent verwaltet wird, genutzt. Mit jeder Nachricht kann der Wert einer oder mehrerer MIBs angefordert werden. Die Daten können sich in verschiedenen privaten MIBs befinden, müssen aber vom selben Agent unterstützt werden.

Wie wir schon wissen, beinhaltet jede GetRequest-Nachricht eine oder mehrere varbinds. Jede dieser varbinds spezifiziert eine einzige OID, deren Inhalt vom Management-System angefordert wurde. Da die GetRequest-Nachricht nur zur Anforderung der Daten verwendet wird, müssen die OIDs in jeder varbind, den instance identifier der Variablen, beinhalten (Sie erinnern sich ? Scalar, list oder table variable instances). Ist dies nicht der Fall, werden Sie eine noSuchName Fehlermeldung erhalten.

Das value field  einer jeder GetRequest-NAchricht wird nicht genutzt. Daher wird es mit einem ASN.1 NULL Wert initialisiert.

52 Size of Message 65
0 SNMP Version 0
public Community Name public
0 PDU Type 2
39 Size of PDU 52
2159 Request ID 2159
0 Error Status 0
0 Error Index 0
28 Size of All Variable Bindings 41
12 Size of First Varbind 23
1.3.6.1.2.1.1.2.0 OID of First Variable 1.3.6.1.2.1.1.2.0
NULL Type of First Variable 2
NULL Value of First Variable 1.3.6.1.4.1.311.1.1.3.2
12 Size of Second Varbind 14
1.3.6.1.2.1.7.4.0 OID of Second Variable 1.3.6.1.2.1.7.4.0
NULL Type of Second Variable 65
NULL Value of Second Variable 250
Additional Variable Bindings
GetRequest => <= GetResponse

GetRequest-Nachricht mit zugehöriger GetResponse-Nachricht (Grafik 12)

Die GetResponse-Nachricht enthält die Daten, die von der GetRequest-Nachricht angefordert wurden. Die Liste der varbinds wurde einfach aus der GetRequest in die GetResponse-Nachricht kopiert. Beachten Sie, daß das value field nun einen Wert besitzt. Hier ist nun der angeforderte Wert gespeichert. Nun noch eine Liste von Fehlern, die während dem ausführen einer GetRequest-Nachricht auftreten können :

        noSuchName
               
Eine OID, spezifiziert in der varbind list, wurde in den, vom Agent unterstützten, MIBs nicht gefunden (Kommt
                oft durch das auslassen bzw. falsche angeben des instance identifiers vor). Wenn sich die OID nicht in dem vom
                Agent unterstützten Namespace befindet, erhalten Sie ebenfalls diese Fehlermeldung.

        tooBig
                Die GetResponse-Nachricht ist zu groß, und kann nicht gesendet werden. Diesen Fehler kann nur ein Master-Agent
                erkennen. Ein Sub-Agent kann dieses Problem nicht erkennen und melden.

        genErr
                In manchen Fällen kann der Agent einen Wert nicht lesen

Denken Sie immer an die "Alles oder Nichts"-Regel von SNMPv1. Gibt es bei einem varbind Probleme, so wird alles im "Urzustand" gelassen, und die GetResponse-Nachricht ist eine exakte Kopie der GetRequest-Nachricht.

GetNextRequest-Nachricht

GetNextRequest, wird wie GetRequest, zum anfordern von Daten verwendet. Daher hat diese Nachricht das selbe Format wie die GetRequest-Nachricht. Die beiden Nachrichten unterscheiden sich aber durch die Art der Ausführung (GetNext operation).

GetNextRequest wird primär für das durchlaufen von Tabellen und das anfordern von speziell ausgewählten Werten (die natürlich von Tabellenmitgliedern stammen) verwendet. GetNext verlangt nicht wie Get, daß die instance der Variablen in deren OID angegeben wird. 

Wenn Sie eine GetNext-Operation mit der OID einer scalar variable (ohne Angabe ihres instance identifier) ausführen, bekommen Sie den korrekten Wert dieser Variablen geliefert.

Ein Beispiel :
Ausführung einer GetNext-Operation mit Verwendung dieser "varbind"- Daten :

Anfrage :
               OID     =    1.3.6.1.2.1.1.4
                Value     =    NULL
Antwort :
                OID     =    1.3.6.1.2.1.1.4.0
                Value     =    OCTET STRING  -  "Juergen Klein"

Wie Sie aus der OID erkennen können, handelt es sich um eine scalar variable und daher gibt es auch nur eine instance.
Wenn wir nun noch den instance identifier mit angeben, würde der Wert der nächsten Variablen ausgelesen :

Anfrage :
               OID     =    1.3.6.1.2.1.1.4.0
                Value     =    NULL
Antwort :
                OID     =    1.3.6.1.2.1.1.5.0
                Value     =    OCTET STRING  -  "Techniker - Schueler"

In der folgenden Abbildung ein GetNextRequest-Nachricht, in der zwei Variablen ausgelesen werden. In beiden Fällen wurde der instance identifier angegeben (Wie Sie wissen, wird somit die nächste Variable ausgelesen)

 

52 Size of Message 66
0 SNMP Version 0
public Community Name public
1 PDU Type 2
39 Size of PDU 53
112234 Request ID 112234
0 Error Status 0
0 Error Index 0
28 Size of All Variable Bindings 42
12 Size of First Varbind 15
1.3.6.1.2.1.1.2.0 OID of First Variable 1.3.6.1.2.1.1.3.0
NULL Type of First Variable 67
NULL Value of First Variable 1924065
12 Size of Second Varbind 23
1.3.6.1.2.1.7.4.0 OID of Second Variable 1.3.6.1.2.1.7.5.1.1.0.0.0.0.1025
NULL Type of Second Variable 64
NULL Value of Second Variable 0.0.0.0
Additional Variable Bindings
GetNextRequest => <= GetResponse

GetNextRequest-Nachricht und ihre GetResponse-Nachricht (Grafik 13)

Diese Tatsache ist die Grundlage dafür, daß Daten aus Tabellen herausgelesen und übertragen werden können, obwohl der instance identifier oder die row indexes nicht bekannt sind.  Wenn Sie zu den Supermenschen gehören, denen immer alle raw indexe einer Tabelle bekannt sind, würden Sie alleine mit der Get-Operation zurecht kommen. Da ich Ihnen dies aber nicht abnehme, müssen Sie wie alle Anderen auch die GetNext-Operation anwenden (Dafür wurde sie ja auch entwickelt).

Um das "durchlaufen" einer Tabelle zu starten, benötigen Sie folgende Angaben :

den Namen der Tabelle

ihren entry

die Namen der entry members, deren Wert sie auslesen wollen.   

Um alle Variablen in einer row mit dem GetNext-Befehl anzusprechen, führen sie eine GetNextRequest-Nachricht pro row  +1 aus
(3 rows = 4 x GetNextRequest-Nachrichten). Die varbinds, einer jeden GetNextRequest-Nachricht, spezifizieren die OID von jeder Variablen in der row. Die Werte die daraufhin geliefert werden, sind stets die der folgenden row.

Ein Beispiel :
Es handelt sich um eine Tabelle mit zwei columns (variables) und drei rows (instances)

                wiseTable, wiseEntry

                wiseIndex     wiseGuy
                1                   Klein
                2                   Juergen
                3                   Techniker

Der Durchlauf beginnt mit einem GetNextRequest der zwei varbinds enthält. Eine für jedes entry member. Die OIDs werden ohne instance identifier angeben. Dies bewirkt, daß die Werte in der ersten row ausgelesen werden. Es werden genau vier GetNext-Operationen benötigt, um alle Werte aus der Tabelle auszulesen.

Folgend habe ich die varbinds der GetNextRequest und GetResponse-Nachricht, die aus dem Durchlauf resultieren, aufgelistet. Um die Sache übersichtlicher zu machen, habe ich die Textform der OIDs gewählt. Die Nummern, mit deren Hilfe die Responses mit den Requests zusammenfinden, haben die gleiche Funktion wie die SNMP message Request ID-Werte.

        GetNextRequest 1
                OID     =    wiseTable.wiseEntry.wiseEntry
                Value     =    NULL
                OID     =    wiseTable.wiseEntry.wiseGuy
                Value     =    NULL

        GetResponse 1
                OID     =    wiseTable.wiseEntry.wiseEntry.1
                Value     =    1
                OID     =    wiseTable.wiseEntry.wiseGuy.1
                Value     =    "Klein"
       

        GetNextRequest 2
                OID     =    wiseTable.wiseEntry.wiseEntry.1
                Value     =    NULL
                OID     =    wiseTable.wiseEntry.wiseGuy.1
                Value     =    NULL

        GetResponse 2
                OID     =    wiseTable.wiseEntry.wiseEntry.2
                Value     =    2
                OID     =    wiseTable.wiseEntry.wiseGuy.2
                Value     =    "Juergen"

 

          GetNextRequest 3
                OID     =    wiseTable.wiseEntry.wiseEntry.2
                Value     =    NULL
                OID     =    wiseTable.wiseEntry.wiseGuy.2
                Value     =    NULL

        GetResponse 3
                OID     =    wiseTable.wiseEntry.wiseEntry.3
                Value     =    1
                OID     =    wiseTable.wiseEntry.wiseGuy.3
                Value     =    "Techniker"

 

        GetNextRequest 4
                OID     =    wiseTable.wiseEntry.wiseEntry.3
                Value     =    NULL
                OID     =    wiseTable.wiseEntry.wiseGuy.3
                Value     =    NULL

        GetResponse 4
                OID     =    wiseTable.wiseEntry.1
                Value     =    1
                OID     =    theNextMibVariable.0
                Value     ="1-700-899-3899"

Bei der ersten GetNextRequest wird die varbinds list mit einer varbind pro Mitglied und Spalte initialisiert. Es werden keine instance identifier angegeben, da wir eh nicht wissen, wie viele Instanzen in dieser Spalte enthalten sind. Die GetResponse-Nachricht beinhaltet den Namen, die instance identifier und die Werte der angefragten Variablen.

Die OIDs, die mit der Response-Nachricht übermittelt wurden, werden von der nächsten GetNextRequest übernommen. Wie Sie sicher bemerkt haben, übermittelt die GetResponse-Nachricht immer die OIDs (mit instance identifier) der nächsten Variablen und den Wert der aktuellen Variablen.

Das System erkennt das Ende einer Tabelle, wenn eine GetResponse-Nachricht eine OID übermittelt, die sich nicht mehr im Namespace der Tabelle befindet. Somit werden die Daten der letzten GetRespons-Nachricht auch nicht mehr ausgewertet - sie haben ja mit der Tabelle nichts zu tun.

Wenn die Tabelle am Ende der gemanagten Objekte ist, und sich daher keine Variablen mehr hinter ihr befinden, bekommen Sie eine noSuchName-Fehlermeldung. Dies ist eine ärgerliche Fehlermeldung, die ein guter MIB-Designer umgehen kann, wenn er am Ende einer MIB nur scalar variables schreibt.

Die nächste Grafik (Grafik 14) zeigt uns einen Lauf durch eine Tabelle mit 3 columns (Spalten) und jeweils 3 rows (Reihen). Für diesen Lauf werden 10 GetNext-Operationen benötigt (3 x 3 + 1 = 10).

grafik_14.jpg (19359 Byte)

Spaltenweiser Durchlauf durch eine Tabelle (Grafik 14)

Der Lauf beginnt bei dem ersten Mitglied der ersten column (Spalte) und wandert solange durch diese Tabelle, bis eine OID, die sich nicht mehr innerhalb dieser Tabelle befindet, überliefert wird. Hier wird Spalte (column) für Spalte abgearbeitet. Wie Sie sehen können, wird immer am Ende der Spalte zum Anfang der nächsten Spalte gesprungen. Gibt es nach der letzten Reihe keine neue Spalte mehr, erfolgt ein Sprung in die nächste MIB Variable. Damit ist dann der Durchlauf durch diese Tabelle abgeschlossen.

Die nächste Grafik (Grafik 15) zeigt uns den Durchlauf durch eine Tabelle, bei der eine Reihe nach der Anderen abgearbeitet wird:

grafik_15.jpg (20029 Byte)

Reihenweiser Durchlauf durch eine Tabelle (Grafik 15)

Wie Sie sehen können, wird hier zeitgleich auf alle drei Variablen der ersten row (Reihe) zugegriffen. Daher werden für diesen Durchlauf nur vier GetNext Operationen benötigt.

Wenn Sie jetzt meinen, Sie hätten Tabellen begriffen, muss ich Sie leider enttäuschen. Tabelle, wie in den vorhergegangenen Beispielen besprochen, stellen wirklich kein Problem dar. Wenn es da nur nicht die gefürchteten "sparse tables" geben würde.

Was sind "sparse tables"? Wie wir bereits besprochen haben, kann man die Tabellen wie  z.B. eine Excel-Tabelle betrachten. Fehlt bei einer solchen Excel -  Datei mal in Eintrag, ist das nicht weiters schlimm (normalerweise). Ganz anders verhält sich dies bei einer SNMP - Tabelle. Sie können also nie davon ausgehen, daß sich in jeder Reihe einer Spalte ein Eintrag befindet. Und wenn sich dann solche "holes" in der Tabelle befinden, spricht man von einer "sparse table".

Die GetNext-Operation hat mit diesen Löchern innerhalb einer Tabelle keine Probleme. Sie durchläuft die Tabelle mühelos. Problematisch wird die Sache, wenn das Management System die Löcher in der Tabelle nicht erkennt, und somit die OID in den varbinds der nächsten GetNextRequest-Nachricht nicht anpasst. Somit kann der Agent die Tabelle nicht mehr richtig durchlaufen. Die häufigste Ursache für solche "löchrigen" Tabellen, sind verschieden große Spalten. Wenn Sie eine solche Tabelle Reihenweise durchlaufen, und Ihnen das Vorhandensein von Löchern nicht bekannt ist, gehen Sie natürlich davon aus, daß die Daten die Sie mit einer jeden GetResponse geliefert bekommen, aus ein und derselben Reihe kommen. Wie Sie aus der Grafik 16 erkennen können, ist dies bei einer "sparse table" nicht der Fall. Hier können die Daten aus der vorhergehenden oder der folgenden Reihe stammen. Der Sprung in die nächste Reihe erfolgt bei der kürzeren Spalte schneller als bei den längeren. Auch dadurch werden die Daten durcheinander gebracht.

grafik_16.jpg (20181 Byte)

Reihenweiser Durchlauf durch eine "sparse table" (Grafik 16)

Nur durch das Prüfen der instance identifiers (Indexe der einzelnen Reihen), kann ein Management System Löcher in der Tabelle erkennen. Wenn alle gelieferten Daten den gleichen Index haben, sind sie aus der gleichen Reihe.

Um eine solche "sparse table" richtig zu durchlaufen, muss das System, wie oben schon erwähnt, die Löcher bemerken und die Variable solange erneut erfragen, bis der Index mit dem der anderen Variablen übereinstimmt. Solange es keine Übereinstimmung gibt, soll das System den Inhalt dieser Variablen ignorieren.

Die Fehlermeldungen die auf eine GetNextRequest-Nachricht folgen können, sind die Selben wie bei der GetRequest-Nachricht:

 

        noSuchName
               
Eine OID, spezifiziert in der varbind list, wurde in den, vom Agent unterstützten, MIBs nicht gefunden (Kommt
                oft durch das auslassen bzw. falsche angeben des instance identifiers vor). Wenn sich die OID nicht in dem vom
                Agent unterstützten Namespace befindet, erhalten Sie ebenfalls diese Fehlermeldung.

        tooBig
                Die GetResponse-Nachricht ist zu groß, und kann nicht gesendet werden. Diesen Fehler kann nur ein Master-Agent
                erkennen. Ein Sub-Agent kann dieses Problem nicht erkennen und melden.

        genErr
                In manchen Fällen kann der Agent einen Wert nicht lesen

SetRequest-Nachricht

Die Set-Operation stellt die einzige Möglichkeit für ein Management System dar, Daten, die von einem Agent verwaltet werden, zu verändern.

Um eine Set-Operation auszuführen, wird eine SetRequest-Nachricht, mit einer varbind pro MIB Variablen, kreiert. Jede varbind beinhaltet den instance identifier und den neuen Wert der Variablen. Das Management System sendet die SetRequest-Nachricht an den Agent. Dieser durchläuft die varbinds und speichert alle Werte in einem Zwischenspeicher. Wenn der Durchlauf keine Fehlermeldungen, wie z.B. noSuchName, badValue, readOnly, tooBig oder genErr, liefert, werden die neuen Werte in die Variablen geschrieben. Kommt jedoch auch nur eine Fehlermeldung vor, wird alles verworfen, die alten Werte bleiben erhalten und eine Fehlermeldung wird an das Management System gesendet.

Wenn die GetResponse-Nachricht keine Fehlermeldung entdeckt, wird der Wert des ErrorStatus-Feldes auf Null gesetzt. Kommt ein Fehler vor, klären die Werte der ErrorStatus- und ErrorIndex-Felder, um welche Fehler es sich handelt und welche varbind den Fehler verursacht hat.

Die Reihenfolge, in welcher die MIB-Variablen in den varbinds der SetRequest-Nachricht erscheinen, sollte keinen Einfluss darauf haben, wie sie von dem Agent verarbeitet werden.

Ein Auszug aus der RFC 1157 :

        "Each variable assignment specified by the SetRequest-PDU should be affected as if simultaneously
        set with respect to all other assignments specified in the same message."

Das bedeutet, daß alle Veränderungen, die in den MIB Variablen dieser einen SetRequest - Nachricht vorgenommen werden, von dem Agent zeitgleich vorgenommen werden. Er nimmt somit keine Rücksicht auf die Reihenfolge der Einträge- jeder ist gleichberechtigt. Mal angenommen, Sie wollen die beiden Variablen "Schranke ist offen J/N ?" und "Das Auto kann fahren" setzen, können Sie dies nicht in einer einzigen SetRequest-Nachricht tun. Diese beiden voneinander abhängigen Variablen müssen in zwei GetRequest-Nachrichten gesetzt werden. Nur so kann sichergestellt werden, daß die richtige Reihenfolge eingehalten wird.

Wenn Ihnen eine nach der Set-Operation folgenden GetResponse-Nachricht keine Fehlermeldungen anzeigt, könnte man davon ausgehen, daß alles klar gegangen ist. Das ist aber ein Irrtum!
SNMP ist nur ein Bestandteil der Mechanismen, die für das Lesen und Schreiben von Variablen angewandt werden. Das kein Fehler durch die GetResponse-Nachricht angezeigt wurde, bedeutet nur, daß der SNMP-Dienst des Agents die Daten an weitere Dienste übergeben konnte. Was danach mit den für SNMP unbekannten Diensten passiert, wird nicht überprüft. Es kann daher vorkommen, daß die neuen Werte nicht übernommen werden.

Idealerweise sollte der Agent keine GetResponse-Nachricht herausgeben, bis die Variablen für eine GetRequest-Nachricht zugänglich sind. Aber dann wäre der Agent wahrscheinlich die ganze Zeit im Zweifel, ob die Variable jetzt den richtigen Wert hat oder nicht. Und wenn der Agent dann auch noch auf einem schwachbrüstigen System installiert ist, daß immer nur eine Aufgabe auf einmal erledigen kann, ist diese Überprüfung von vorne herein unmöglich.

Dieses Problem wurde durch andere System- und Netzwerk-Protokolle gelöst. Sie liefern an das Management System eine "In Process" -Nachricht, die anzeigt, daß das System an der Request (Anfrage, Bitte) arbeitet. Diese InProcessResponse-Nachricht wird gesendet, wenn der Agent für diese Aufgabe mehr als 1 Sekunde benötigt. Ist diese Aufgabe dann erledigt, folgt eine richtige GetResponse-Nachricht.

Die Geschichte mit der InProcessResponse hört sich zwar toll an, bedeutet aber für den Agent eine weiter Hardware-Hürde. Werden z.B. 30 neue Werte durch eine Set-Operation an einen Agent übergeben, muss er sie alle auf ihre Richtigkeit überprüfen und gegebenenfalls laufend überwachen usw. bevor er eine GetResponse-Nachricht losenden kann. Und während all dem, muss er auch noch InProcess-Nachrichten an das System senden, damit dieses erkennt, daß er noch an der Aufgabe arbeitet. Die Unterstützung von InProcess-Nachrichten verletzt daher die SNMP-Regel, den Agent so wenig wie möglich zu belasten. Daher sollte man diese Methode nicht anwenden.

Da ein SNMP Management System eine erfolgreiche GetResponse-Nachricht nicht als Beweis für die korrekte Ausführung der Set-Operation nutzen kann, muss jede Set-Operation in vier Schritte unterteilt und ausgeführt werden:

  1. Das Management System erfragt den aktuellen Wert der Variablen mit einer Get-Operation.

  2. Es sendet die neuen Werte mit der Set-Operation.

  3. Es überprüft die neuen Werte mit Hilfe der GetResponse-Nachricht, die auf die Set-Operation folgt.

  4. Es startet eine neue Get-Operation, um die Variablen erneut auszulesen. Sind alle Variablen richtig, wird hier abgebrochen. Wenn nicht, wird eine bestimmte Anzahl von Get-Operationen ausgeführt. Ändert sich nichts, werden die Variablen erneut gesetzt.

Nun wird Ihnen dies alles sehr umständlich und unausgereift vorkommen. Bedenken Sie aber, daß der Agent als ein Low-Level Prozess auf dem Netzwerk-Gerät ausgeführt wird. Die Aufgaben des Agents sollen stets so einfach wie möglich gehalten werden. Treten Probleme auf, sollen diese von dem Netzwerk Management System und nicht von dem Agent gelöst werden.
Grafik 17_1 und 17_2  zeigt Ihnen zwei Möglichkeiten einer SetRequest-Transaktion:

wpe13.jpg (14603 Byte)

Eine "einfache" SetRequest Transaktion (Grafik 17_1)

wpe10.jpg (26611 Byte)

Eine "robuste" SetRequest-Transaktion (Grafik 17_2)

GetResponse Fehler

In dem Fall, daß Sie Probleme mit einer SNMP-Operation haben, liefern Ihnen die Werte von ErrorStatus und ErrorIndex wertvolle Information. Um den Fehler mit Hilfe dieser Informationen zu beseitigen, müssen Sie über detaillierte Kenntnisse verfügen.

RFC 1157 beschreibt eine Reihe von Regeln, mit deren Hilfe ein Agent entscheidet, ob eine ihm gestellte Aufgabe erfolgreich erledigt wurde. Die selben Regeln wenden Sie an, wenn Sie Ihre eigenen erweiterten Agents schreiben. Und Sie wenden diese Regeln ebenfalls an, wenn Sie eine GetResponse-Nachricht mit einer Fehlermeldung erhalten.

In der folgenden Tabelle stelle ich Fehlermeldungen dar, die Sie in Folge einer Get, GetNext oder Set-Operation erhalten können:

 

  Operation   mögliche Fehlermeldungen
  Get und GetNext   noSuchName
  tooBig
  genErr
  Set   badValue
  readOnly
  noSuchName
  tooBig (sehr selten)
  genErr

Beachten Sie immer, daß die Fehlermeldungen nur Fehler, die direkt mit dem SNMP-Protokoll zusammenhängen, anzeigen. Fehler die außerhalb des SNMP-Protokolls auf dem verwalteten Knoten vorkommen, werden nicht bemerkt und können somit auch nicht angezeigt werden. Diese Probleme müssen anhand der Daten in den Variablen der GetResponse- und Trap-PDUs erkannt werden.

Betrachten wir die SNMPv1 Fehlermeldungen im Detail:

tooBig error

Der tooBig error weißt darauf hin, daß eine resultierende GetResponse-Nachricht die erlaubte Größe überschreitet, und somit in diesem Zustand  => an einem Stück, nicht gesendet werden kann.

Wie schon besprochen, reduzieren manche Agents die erlaubte Größe von GetRespone- und Trap-PDUs auf z.B. 512 oder 1024 Oktetten, um damit Ihren beschränkten Speicher zu schonen.

Die Größendefinition basiert normalerweise immer auf dem Maximum Transfer Unit (MTU).  Der MTU ist der größte Frame (Rahmen), der am Stück in einem Netzwerk gesendet werden darf. Dessen Größe wird von der data link layer Schnittstelle (Schicht 2, OSI-Modell) bestimmt. Ist der Frame größer, wird er von dem IP-Dienst, der sich in der network layer (Schicht 3, OSI-Modell), in kleinere Frames zerstückelt und einzeln abgesendet. Beim Empfänger wird er wieder zusammengesetzt. Frames die nicht zerstückelt werden sollen bzw. können, müssen sich an das Limit halten.

In einem Ethernet-Netzwerk ist die MTU 1500 Oktetten lang. Nun sollte man meinen, daß dies genügen würde. Leider werden nur zu oft die Ansprüche  der IP-, UDP- und SNMP-Nachrichten sowie der PDU-Headers vergessen. Wenn Sie sich an die maximale Datengröße von 1400 Oktetten halten, dürften Sie in einem Ethernet-Netzwerk keine tooBig errors erhalten.

Achten Sie also auf die Menge der Variablen, die Sie in SNMP Request-Nachricht erfragen. Eine weitere Fehlerquelle ist die max. Größe der OCTET STRINGs. Falls Sie Größen-Probleme bekommen, unterteilen sie die Nachricht in mehrere kleine Nachrichten.

 

TIP

Zwei Möglichkeiten die Größe der MTU zu ermitteln:

Das Auslesen der 1.3.6.1.2.mib.interfaces.ifTable.ifEntry.ifMtu Variablen

Durch benutzen des Ping-Befehls in der Kommandozeile:
Sie rufen den Ping-Befehl auf, geben jedoch die Größe der Pakete vor und setzen den -f   Parameter, um des zerstückeln des frames zu verhindern. Starten Sie mit einer Größe von 1500 Oktetten und arbeiten Sie sich nach unten, bis keine Fehlermeldung mehr erfolgt.

ping -f -l  1500 <address>

 

noSuchName error

Der noSuchName error kommt vor, wenn sich eine in der varbind spezifizierte OID, nicht in dem vom Agent unterstützten MIB Namespace (Namenpool) befindet. Der Inhalt des ErrorIndex zeigt auf die varbind, in der sich die unbekannte OID befindet.

Hierzu muss ich wohl wenig sagen. Sie müssen eben immer darauf achten, daß die OIDs in Ihren varbinds auch im Namespace des Agents zu finden sind.

badValue error

Dieser Fehler wird Ihnen geliefert, wenn Sie in einer SetRequest-Nachricht den Wert der MIB-Variablen falsch definieren. Dabei kann es sich um den falschen Datentyp oder um einen zu großen (Größen-) Bereich handeln. Der ErrorIndex gibt an, welche varbind den falschen Wert beinhaltet.

Sie müssen stets darauf achten, daß der neu kreierte Wert die selben Spezifikationen besitzt, wie die der existierende Variable. Sie können eine Variable, die als INTEGER deklariert wurde, nicht mit einem OCTET STRING überschreiben. Ebenso müssen Sie die Größen-Bereiche beachten. Wie Sie wissen, kann man einer INTEGER oder OCTET STRING Variablen einen festen Bereich zuordnen. Nehmen wir an, eine OCTET STRING hätte den Bereich von 6-24 Oktetten. Wenn Sie diese Variable nun mit einem 32 Oktetten langen OCTET STRING, überschreiben wollen, bekommen Sie garantiert eine badValue error Meldung. 

Um dies zu verhindern, sollten Sie sich immer in der OBJEKT-TYPE Definition der Variablen über deren Datentyp und Datenbereich informieren.

readOnly error

Diese Meldung wird Ihnen geliefert, wenn Sie eine Variable mit einer SetRequest überschreiben wollen, diese jedoch  read-only Zugriffs Modus deklariert wurde.

Unglücklicherweise wurde in der Definition der SetRequest-Nachricht nach RFC 1157 nicht genau festgelegt, ob readOnly als Fehlermeldung zurückgeliefert werden muss. Deswegen kann es sein, daß Sie keine  readOnly error Fehlermeldung zurückgeliefert bekommen. Was passiert also, wenn Sie einem Agent eine SetRequest-Nachricht zukommen lassen, der Sie aber nicht bearbeitet, weil alle Variablen auf read-only gesetzt sind?
Werfen wir einen Blick zurück zu RFC 1157: Hier steht, daß alle Objekte, die für eine SetRequest-Nachricht nicht erreichbar sind, eine noSuchName error Fehlermeldung zurückliefern.
Sie müssen die Phrase: "nicht erreichbar" sowohl als: "read-only" wie auch als: "außerhalb des name spaces" interpretieren.

Um herauszufinden, welche der beiden Interpretationen zutrifft, muss eine Get-Operation ausgeführt werden. Wird der Wert der Variablen ausgelesen, ist sie schreibgeschützt. Konnte Sie nicht ausgelesen werden, befindet sie sich außerhalb des Namespaces des Agents.

genErr error

Die genErr error Fehlermeldung teilt Ihnen mit, daß ein Fehler aufgetreten ist, der keiner der anderen Fehlermeldungen zugeordnet werden konnte. Falls die fehlerhafte varbind erkannt wurde, kann man sie mit Hilfe des ErrorIndex-Feldes finden. Meistens konnte sie nicht erkannt werden und die genErr kommt mit einer "0" im ErrorIndex-Feld an. Wie schon besprochen, zeigt eine Null an, daß die fehlerhafte varbind nicht identifiziert wurde. Zahlen > 0 zeigen die Position der varbind an.

Um diesen Fehler möglichst schnell und ohne unnötigen Zeitaufwand zu beseitigen, setzen Sie hier einen Protokoll-Analyser ein. Durch überprüfen der Daten in den varbinds, sowohl in der Response- wie in der Request-Nachricht, ist der Fehler am schnellsten zu finden.

4.6 SNMPv1 Traps       

Traps sind unangeforderte Nachrichten, die von einem Agent an ein Management-System gesendet werden, sobald etwas unvorhergesehenes und für das Management-System interessantes geschieht. Traps kann man mit den aus der Hardware bekannten Interrupts vergleichen. Dann gibt es noch den "tollen" Vergleich mit dem vom Win95/98 bekannten "Blue Window". Auch er ist eine echte Trap-Nachricht. :-)

Der Term Trap (Falle) drückt genau das aus, was er ist - eine Falle, die darauf wartet zuzuschnappen. Sobald ein vorbestimmtes Ereignis eingetroffen ist, geniert der Agent eine message und sendet sie an eine bestimmte Netzwerk-Adresse, auch trap destination (Fallen-Bestimmungsort) genannt.

Hinter dieser Netzwerk-Adresse befindet sich ein hoffentlich empfangsbereites Management-System, daß die Nachricht entgegennimmt und in einer Liste abspeichert. Manche Systeme alarmieren durch akustische oder optische Signale, das Empfangen einer Trap-Nachricht.

Anhand der in den varbinds gespeicherten Daten, erkennt das Management-System, um welchen Vorfall es sich handelt. Jede dieser in der Nachricht enthaltenen MIBs muss von dem Agent, der die Nachricht erstellt hat, unterstützt werden.

Es gibt aber auch Trap-Nachrichten, die keine varbinds enthalten. Hier ist allein das Auftauchen der Trap die Nachricht. Wenn so eine Trap erscheint, sollte man sich etwas näher mit dem Agent beschäftigen. Erfolgt dies, hat die Trap-Nachricht ihre Aufgabe erledigt. Nicht immer werden viele Worte benötigt, um jemanden auf ein Vorkommnis aufmerksam zu machen. Siehe Blaulicht oder Kelle der Polizei ;-)

SNMPv1 Traps sind sehr einfach und ohne besondere Funktionen gehalten (was nicht nur Vorteile mit sich bringt). Egal was Sie über deren Aufbau denken => ihr Design steht fest und wird nicht verändert

 

TRAP-TYPE Makro

Das TRAP-TYPE Makro (beschrieben von RFC 1215) wird zur Definition von traps und der mit ihnen verbundenen MIBs, genutzt. Obgleich das TRAP-TYPE Makro dem OBJEKT-TYPE MAKRO sehr ähnelt, ist es keine MIB-Variable und hat keine OID. Anstatt dieser, weißt sich jede Trap durch die OID der MIB-Variablen aus, welche die Trap generiert hat. Zusätzlich erhält sie noch eine Bezeichnung in Form einer positiven Zahl. Diese wird in aufzählender Weise erweitert, falls es sich um mehrere Traps pro MIB handeln.

Hier ein Beispiel eines TRAP-TYPE Makro, welches ein beliebige (erfundene) Trap in einer private MIB (Hersteller MIB) definiert:

        cleverUnit OBJECT IDENTIFIER    : : =    {    enterprises 1999 1    }

        unitUnderWater     TRAP-TYPE
                ENTERPRISE cleverUnit
                VARIABLES     {    shelfId, slotIndex, unitId, unitIsUnderWaterState     }
                DESCRIPTION
                    "Diese trap teilt dem System mit, ob sich die gemanagten Geräte unter
                    Wasser befinden, oder ob das Wasser wieder abgeflossen ist ;-)
                    Die Variablen shelfId, slotIndex und untiId identifizieren das Gerät und seinen
                    Standort. Der Inhalt von unitIsUnderWaterState gibt an, ob Wasser vorhanden ist (1)
                    oder nicht (0)."
                : : = 1

Der Trap Identifier ist "unitUnderWater". Die Textbeschreibung erleichtert dem Administrator die Arbeit mit dieser Trap (Falls er sie nicht selbst geschrieben hat). Die OID der management enterprise, welch die Trap definiert, wird im ENTERPRISE-Abschnitt festgelegt. Im VARIABLES-Abschnitt werden die MIB-Variablen definiert. Deren OID und Werte werden im Falle eines Vorfalls in die varbinds der Trap kopiert. Die Variablen werden in der gleichen Reihenfolge wie sie gespeichert werden, spezifiziert. Falls die Trap keine MIB-Variablen enthält, wird der VARIABLES-Abschnitt einfach ausgelassen. Der DESCRIPTION-Abschnitt beschreibt wie besprochen die Funktion der Trap. Die folgende Zahl ist die aufzählende Nummer(nbezeichnung) der Trap-Nachricht.

Trap-PDU

Das Format der Trap-PDU (siehe Grafik 18) unterscheidet sich etwas von dem der Request- und Respone-PDUs. Body und die preamble sind bei den verschiedenen PDU identisch. Der Header hat aber ein paar zusätzliche Felder, die zur Unterstützung der Trap-Daten benötigt werden. Dafür fallen die ErrorStatus- und ErrorIndex-Felder in der Trap-PDU weg.

 

Message Length

SNMP Message Preamble

Message Version
Community String
PDU Type

PDU Header

PDU Length
Enterprise MIB OID
Agent IP Address
Standard Trap Type
Specific Trap Type
Time Stamp

PDU Body

Length of Variable Bindings
Length of First Binding
OID of First Binding
Type of First Binding
Value of First Binding
Length of Second Binding
OID of Second Binding
Type of Second Binding
Value of Second Binding
Additional Variable
Bindings

Trap PDU Format (Grafik 18)

Über die Identität einer Trap-Nachricht wird anhand der Informationen, die sich in den Enterprises-, Standart Trap Type- und Specific Trap Type-Feldern der Trap PDU befinden, entschieden. Falls es sich bei dem Inhalt des Standart Trap Type-Feldes um Wert von 0-5 handelt, ist es eine generic SNMP trap, welche von der MIB-II snmp group defniert wurde. Die OID im Enterprise-Feld, ist iso(1).org(3).dod(6).internet(1).mgmt(2).mib(1). snmp(11). Der Wert des Specific Trap Type-Feldes ist Null.

Ist der Wert im Standart Trap Type-Feld 6, so handelt es sich um eine Unternehmens (enterprise)-spezifische trap. Sie wird in einer privaten MIB erläutert, welche sich wiederum in dem von der SMI definierten  iso(1).org(3)dod(6).internet(1).private(4).enterprises(1) namespace befindet. Die in den Enterprise field gespeicherte OID zeigt genau an, welche management enterprise die Trap definiert. Die aufwärtszählende Nummernbezeichnung der Trap (siehe TRAP-TYPE Makro) wird im Specific Trap Type-Feld abgespeichert

Einige Traps werden zusätzlich mit Hilfe des Time Stamp-Feldes erkennt. Dies ist vor allem dann sehr wichtig, wenn die Trap zwei Zustände melden kann.

Ein Beispiel:

Nehmen wir mein vorhergehendes Beispiel "unitUnderWater". Diese Trap meldet sich bei Hochwasser wie bei abgeflossenem Wasser. Woher soll das Management System wissen, in welcher zeitlicher Reihenfolge die Traps generiert wurden?? Hier hilft die time stamp. Mit Ihr kann das System den Nachrichten die richtige Reihenfolge zuordnen und erkennen ob das Wasser noch da ist oder wieder abgeflossen ist.

RFC 1157 definiert 7 Traps die mit SNMPv1 Agents genutzt werden können. Sechs von diesen Traps werden als generic (~Standart) bezeichnet. Sie sollten von jedem Agent generiert werden können. Die siebte Trap wird als enterprise-specific (Unternehmens-Spezifisch) bezeichnet. Mit ihr werden die vom Gerät abhängigen traps generiert. Es können keine weiteren  generic traps generiert werden! Enterprise-specific traps können in beliebiger Anzahl erstellt werden. Und sie werden benötigt, glauben Sie mir.......;-)

 

SNMPv1 Generic Traps

Ein Agent ist nicht dazu verpflichtet, alle generic traps in sich zu implementieren. Einige generic traps wie z.B. coldStart und authenticationFailure sind in so gut wie jedem Agent zu finden, andere wie egpNeightborLoss nur vereinzelt.

coldStart traps

ColdStart traps zeigen an, daß dem gemanagten Gerät eine plötzliche, unerwartete Reinitialisierung (Kaltstart) widerfahren ist. Solch ein Kaltstart kann zur Folge haben, daß das Gerät nicht mehr 100%  gestartet ist oder Daten verloren gegangen sind.

Eine coldStart trap ist immer ein Zeichen dafür, daß das gemanagte Gerät wieder für SNMP requests empfangsbereit ist. Den nur ein korrekt gestarteter Agent kann eine Trap senden! Wenn der Wert der Time Stamp 0 oder nur eine kleine Differenz zur 0 beträgt, wurde der SNMP-Prozess gerade erst gestartet. In diesem Fall kann man davon ausgehen, daß es sich um die Zeitspanne handelt, seit der das System wieder hochgefahren ist. Dies ist aber nicht immer so! Auf diesen Wert können Sie sich nur dann verlassen, wenn das komplette System, nicht nur der SNMP-Prozess, neu gestartet wurde.

warmStart trap

Die warmStart trap ist ein Zeichen dafür, daß das Gerät neu initialisiert wurde, aber keine Daten und Einstellungen verlorengegangen sind. Es arbeitet wieder wie vor seiner Neuinitialisierung.

linkDown trap

Diese Trap zeigt an, daß einem Gerät ein link oder ein port verlorengegangen sind. Das könnte z.B eine Verbindung zu einem Rechner über eine Netzwerkkarte sein. Informationen über die betroffene Schnittstelle (z.B. Netzwerkkarte) wird in der ersten varbind der Trap PDU abgespeichert. Bei diesen Daten handelt es sich um den Namen und den Wert der ifIndex-Instanz (MIB-II interfaces group) der betroffenen Schnittstelle. Mit diesen Daten kann aber nicht die Ursache des Problems erkannt werden, sie zeigen nur auf die betroffene Schnittstelle.

Es gibt eine Menge von Netzwerk-Geräten, die mehrere ports (multiple communications links) besitzen. Fällt hier ein port aus, wird der "Verkehr" eben auf die anderen ports verlagert. Hier ist keine Katastrophe, wenn ein port ausfällt. Erst wenn mehrere linkes weggefallen sind, sollte sich der System-Administrator näheres mit diesem Gerät beschäftigen.

linkUp trap

Die linkUp trap zeigt an, daß sich ein Kommunikations-link oder -port betriebsbereit angemeldet hat. Wie bei der linkDown trap können Sie Informationen über die betroffene Schnittstelle aus der ersten varbind der Trap herauslesen. Diese Trap wird nur von Geräten mit multiple communications links (z.B Routers) unterstützt.

authenticationFailure trap

Dies Trap zeigt an, daß der Agent eine SNMP-Nachricht empfangen hat, mit ihr aber nichts anfangen kann. Dies kommt vor, wenn sich der Sender nicht in der selben Community wie der Empfänger befindet, bzw. er eine Netzwerkadresse besitzt, die nicht dazu berechtigt ist, an den Empfänger eine Nachricht zu senden.

Diese Trap besitzt leider keine Felder, in die Informationen über den Sender der SNMP-Nachricht gespeichert werden können. Dies ist ein schlechte Lösung, da es bestimmt nicht uninteressant wäre, etwas über den Falsch-Sender zu erfahren.

egpNeighborLoss trap

Diese Trap wird von einem Exterior Gatway Protocol (EGP) Router-Agent erzeugt, wenn sich ein in der neighbor table (egpNeighTable) eingetragener EGP peer router nicht mehr meldet. Um diesen Trap ausführen zu können, müssen alle betroffenen Geräte EGP installiert haben. Diese Trap wird nur in Netzen ausgeführt, die eine Menge von EGP-Geräten integriert haben. EGP ist ein IP router protocol welches von RFC 904 definiert wird.

 

Using Traps

Es sieht so aus, als ob Traps eine wunderbare Sache sind. Hat ein gemanagtes Gerät ein Problem, sendet es einfach ein paar Informationen an das Management-System. Darauf wird das Problem schon gelöst.

So sieht es in der Theorie aus. Aber in der Praxis erweisen sich Traps als recht problematisch. Wieder einmal ist UDP (das verbindungslose Protokoll) der Grund. Wie wir wissen, baut SNMP auf dieses Protokoll auf. Bei den Get-,GetNext- und Set-Funktionen stellt dies kein Problem dar. Hier folgt auf jede Request-Nachricht eine Response. Ist dies nicht der Fall, hakt SNMP nach einer bestimmten Zeit nach. Anders verhält es sich bei den Trap-Nachrichten. Hier wird keine Response-Nachricht erwartet. Der Agent weiß also nie, ob seine Nachricht auch erhört wurde.

Was hier benötigt wird ist Trap-Handshaking. Ist es sinnvoll oder wir nur ein unnötiger Overhead produziert?

Vergleichen wir zuerst einmal die Vor- und Nachteile von bestätigten und unbestätigten Traps:

Die Vorteile von unbestätigten Traps sind:

der Agent kann sich nach dem Absenden der Trap wieder voll seinen Aufgaben zuwenden

er muss nicht ins Netz "lauschen", ob den schon eine Antwort auf dem Weg ist

das erneute Senden, falls die Response nach einer bestimmten Zeit noch nicht angekommen ist, entfällt

somit kann es keine Duplikate im Netz geben

das Netz wird für die "wichtigen" Informationen freigehalten
       

Die Nachteile von unbestätigten traps sind:

der Agent weiß nicht, ob er erhört wurde

der Fehler wird nicht erkannt - also auch nicht behoben. Ein kompletter Absturz des Systems kann daraus folgen.

Ich denke, daß ich die Vorteile der bestätigten Traps  ich nicht aufzulisten brauche. Verdrehen Sie einfach die Vor- und Nachteile der unbestätigten Traps und Sie erhalten sie automatisch.

Sie sehen, ob Sie unbestätigte oder bestätigte Traps einsetzen, hängt vom ermessen des einzelnen Administrators ab. Ich denke, es ist am wichtigsten, daß jeder beide Möglichkeiten zur Auswahl hat, und somit frei entscheiden kann, welche er einsetzen möchte. Bei systemkritischen Vorkommnissen würde ich bestätigte Traps, bei den unkritischen unbestätigte Traps verwenden.

Hier geht es weiter zum Kapitel:

"Wie arbeite ich mit einem Protokoll-Analyser..?"

Leider verzögert sich der Seitenaufbau etwas, da Grafiken geladen werden müssen