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).
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:
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.
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:
Das Management System erfragt den aktuellen Wert der Variablen mit einer Get-Operation.
Es sendet die neuen Werte mit der Set-Operation.
Es überprüft die neuen Werte mit Hilfe der GetResponse-Nachricht, die auf die Set-Operation folgt.
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:
Eine "einfache" SetRequest Transaktion (Grafik 17_1)
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:
|
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.
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