4. PROTOCOL SPECIFICATION
RFC1157-SNMP DEFINITIONS ::= BEGIN
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., get, set, getnext
ANY -- implementation-specific;
-- e.g., BindingList for
-- bind request
}
-- PDUs
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- the individual PDUs and their syntax
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- sometimes ignored
ErrorStatus,
error-index -- sometimes ignored
ErrorIndex,
variable-bindings -- values are ignored
VarBindList
}
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object
-- generating
-- trap
OBJECT IDENTIFIER,
agent-addr -- address of object
-- generating trap
NetworkAddress,
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present
-- even if generic-trap
-- is not equal to 6
INTEGER,
time-stamp -- time elapsed between
-- agent start-up and
-- trap generation
TimeTicks,
variable-bindings -- "interesting" info
VarBindList
}
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
}
ErrorIndex ::=
INTEGER
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
END
4.1. Elements of Procedure
Die SNMP-Nachrichten werden an die wohlbekannte Port-Nummer (UDP-Port 161) auf dem Zielelement gesendet. Eine SNMP-Entität (entweder ein Agent oder ein Manager) empfängt Nachrichten an diesem Port. Management-Anfragen werden vom Agenten empfangen, und Management-Traps werden vom Manager empfangen. Die wohlbekannte Port-Nummer für Traps ist der UDP-Port 162.
Wenn eine Management-Station eine Anfrage an einen Agenten richtet, muss sie die Werte der „wohlbekannten" Felder in die entsprechenden Felder der Anfrage kopieren. Der Agent, der die Anfrage empfängt, prüft den Community-Namen in der Nachricht und kann optional einen Authentifizierungs-Trap senden, falls die Authentifizierung fehlschlägt.
Die als Agent agierende SNMP-Protokollentität muss am wohlbekannten Port Nachrichten mit einer maximal akzeptablen Länge von 484 Oktett bereit sein zu empfangen und sollte Nachrichten von mindestens 1024 Oktett bereit sein zu empfangen.
Die als Manager agierende SNMP-Protokollentität muss am wohlbekannten Port für Traps Nachrichten mit einer maximal akzeptablen Länge von 484 Oktett bereit sein zu empfangen und sollte Nachrichten von mindestens 1024 Oktett bereit sein zu empfangen.
4.1.1. The Request/Response Operations
Das Folgende beschreibt das Verfahren zur Erzeugung und Verarbeitung der Operationen get-request, get-next-request, get-response und set-request.
4.1.1.1. Generating a Retrieval Request
Bei der Erzeugung einer Abrufanfrage wählt die anfragende SNMP-Entität (typischerweise ein Manager) einen Wert für das Feld request-id. Dieser Wert ermöglicht es der anfragenden Protokollentität zusammen mit den Quell- und Ziel-Transportadressen, ihre eingehenden Antworten den ausstehenden Anfragen zuzuordnen. Die Felder error-status und error-index werden auf null gesetzt. Das Feld variable-bindings wird auf die Liste der Variablen gesetzt, deren Werte gewünscht werden.
4.1.1.2. Receiving a Retrieval Request
Beim Empfang einer Abrufanfrage ermittelt die empfangende SNMP-Entität (typischerweise ein Agent) die Größe der Antwort. Überschreitet die Größe der zu erzeugenden get-response-PDU die maximal akzeptable Länge für den Quell-Transport, so sendet die empfangende Entität eine get-response-PDU mit error-status tooBig, error-index null und dem Wertfeld aller gebundenen Variablen auf null gesetzt.
Andernfalls holt die empfangende Entität für jedes Objekt im Feld variable-bindings:
-
den Wert des benannten Objekts, falls der Name des Objekts einer tatsächlichen Instanz des Objekts entspricht und das Objekt zugreifbar ist; oder
-
das benannte Objekt nicht, falls der Name nicht einer tatsächlichen Instanz des Objekts entspricht; oder
-
das benannte Objekt existiert, der Zugriff darauf ist jedoch verboten.
Im ersten Fall werden Name und Wert des Objekts in das Feld variable-bindings der get-response-PDU aufgenommen. Im zweiten Fall wird der Name des Objekts zusammen mit einem Hinweis aufgenommen, dass das Objekt nicht existiert (d. h., das Wertfeld der Bindung wird auf null gesetzt, der Typ jedoch nicht). Im dritten Fall wird der Name des Objekts zusammen mit einem Hinweis aufgenommen, dass das benannte Objekt existiert, aber nicht zugreifbar ist. Die empfangende Entität setzt dann das Feld error-status der get-response-PDU auf noError und das Feld error-index auf null.
Entspricht ein im Feld variable-bindings benanntes Objekt keiner existierenden Instanz, so setzt die empfangende Entität das Feld error-status auf noSuchName und das Feld error-index auf den Index des fehlgeschlagenen Objekts in der Liste variable-bindings. Existiert ein im Feld variable-bindings benanntes Objekt, ist aber nicht zugreifbar, so setzt die empfangende Entität das Feld error-status auf readOnly und das Feld error-index auf den Index des fehlgeschlagenen Objekts. In beiden Fällen wird das Wertfeld aller Bindungen auf null gesetzt.
4.1.1.3. Generating a Set Request
Bei der Erzeugung eines set-request wählt die anfragende SNMP-Entität (typischerweise ein Manager) einen Wert für das Feld request-id. Die Felder error-status und error-index werden auf null gesetzt. Das Feld variable-bindings wird auf die Liste der Variablen gesetzt, deren Werte geändert werden sollen.
4.1.1.4. Receiving a Set Request
Beim Empfang eines set-request validiert die empfangende SNMP-Entität (typischerweise ein Agent) zunächst die Operation als Ganzes. Sie prüft, dass alle im Feld variable-bindings benannten Variablen existieren und zugreifbar sind und dass Typ und Länge jedes Werts mit der Definition des Objekts konsistent sind. Schlägt eine Prüfung fehl, so ändert der Agent die Werte keiner der Variablen und sendet eine get-response-PDU mit dem entsprechenden error-status (noSuchName oder badValue) und error-index auf den Index der fehlgeschlagenen Variablen gesetzt.
Gelingen alle Prüfungen, so führt der Agent die Set-Operation aus und ändert die Werte der benannten Variablen. Er sendet dann eine get-response-PDU mit error-status noError und error-index null und nimmt die neuen Werte in das Feld variable-bindings auf.
Tritt während der Set-Operation ein Fehler auf, so sendet der Agent eine get-response-PDU mit error-status genErr und error-index auf den Index der Variablen gesetzt, bei der der Fehler festgestellt wurde.
4.1.1.5. Receiving a Get Response
Wenn eine get-response von der anfragenden SNMP-Entität (typischerweise einem Manager) empfangen wird, ordnet diese die Nachricht mittels request-id und Quell-Transportadresse einer ausstehenden Anfrage zu. Sie verarbeitet dann das Feld variable-bindings gemäß den Feldern error-status und error-index. Ist error-status noError, so werden die Werte den entsprechenden lokalen Variablen zugewiesen. Andernfalls trifft der Manager Maßnahmen, die dem angezeigten Fehler angemessen sind.
4.1.2. The GetNextRequest-PDU
Die Semantik der get-next-request-PDU ähnelt der der get-request-PDU, mit der Ausnahme, dass die im Feld variable-bindings der Anfrage benannte Variable diejenige ist, deren Name lexikographisch auf die benannte Variable folgt (in der MIB-Sicht). Die get-next-request- und get-response-PDUs bieten ein Mittel, die MIB zu „durchwandern" (walk) und die Werte einer Folge von Variablen abzurufen, ohne ihre genauen Namen im Voraus zu kennen.
4.1.3. The Trap Operation
Traps sind asynchrone Benachrichtigungen, die ein Agent an einen Manager sendet. Der Agent erzeugt eine Trap-PDU, wenn ein bedeutendes Ereignis eintritt, wie etwa ein Kalt- oder Warmstart, das Ausfallen oder Aktivwerden einer Verbindung, ein Authentifizierungsfehler oder der Verlust eines EGP-Nachbarn. Die Trap-PDU enthält die Felder enterprise, agent-addr, generic-trap, specific-trap, time-stamp und variable-bindings. Da Traps unbestätigt sind, erwartet der Agent keine Antwort vom Manager.
Return: RFC 1157 Home