4. Protokollspezifikation
Das Netzwerkmanagement-Protokoll ist ein Anwendungsprotokoll, mit dem die Variablen der MIB eines Agenten geprüft oder geändert werden können.
Die Kommunikation zwischen Protokollentitäten erfolgt durch den Austausch von Nachrichten, von denen jede vollständig und unabhängig innerhalb eines einzelnen UDP-Datagramms unter Verwendung der Basic Encoding Rules von ASN.1 dargestellt wird (wie in Abschnitt 3.2.2 erörtert). Eine Nachricht besteht aus einer Versionskennung, einem SNMP-Community-Namen und einer Protokolldateneinheit (PDU). Eine Protokollentität empfängt Nachrichten am UDP-Port 161 auf dem Host, mit dem sie verbunden ist, für alle Nachrichten außer denen, die Traps melden (d. h. alle Nachrichten außer denen, die die Trap-PDU enthalten). Nachrichten, die Traps melden, sollten am UDP-Port 162 zum weiteren Verarbeiten empfangen werden. Eine Implementierung dieses Protokolls muss keine Nachrichten annehmen, deren Länge 484 Oktett überschreitet. Es wird jedoch empfohlen, dass Implementierungen größere Datagramme unterstützen, wann immer dies machbar ist.
Es ist zwingend erforderlich, dass alle Implementierungen des SNMP die fünf PDUs unterstützen: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU und Trap-PDU.
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
-- protocol data units
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 commonly used
-- data types will be defined later
END
4.1. Elemente des Verfahrens
Dieser Abschnitt beschreibt die Aktionen einer Protokollentität, die das SNMP implementiert. Beachten Sie jedoch, dass damit nicht die interne Architektur einer konformen Implementierung eingeschränkt werden soll.
Im folgenden Text wird der Begriff Transportadresse verwendet. Im Fall von UDP besteht eine Transportadresse aus einer IP-Adresse zusammen mit einem UDP-Port. Andere Transportdienste können zur Unterstützung des SNMP verwendet werden. In diesen Fällen sollte die Definition einer Transportadresse entsprechend erfolgen.
Die Aktionen auf oberster Ebene einer Protokollentität, die eine Nachricht erzeugt, sind wie folgt:
-
Sie konstruiert zunächst die geeignete PDU, z. B. die GetRequest-PDU, als ASN.1-Objekt.
-
Dann übergibt sie dieses ASN.1-Objekt zusammen mit einem Community-Namen, ihrer Quell-Transportadresse und der Ziel-Transportadresse an den Dienst, der das gewünschte Authentifizierungsschema implementiert. Dieser Authentifizierungsdienst gibt ein weiteres ASN.1-Objekt zurück.
-
Die Protokollentität konstruiert dann ein ASN.1-Message-Objekt unter Verwendung des Community-Namens und des resultierenden ASN.1-Objekts.
-
Dieses neue ASN.1-Objekt wird dann unter Verwendung der Basic Encoding Rules von ASN.1 serialisiert und anschließend mithilfe eines Transportdienstes an die Peer-Protokollentität gesendet.
Ebenso sind die Aktionen auf oberster Ebene einer Protokollentität, die eine Nachricht empfängt, wie folgt:
-
Sie führt eine rudimentäre Analyse des eingehenden Datagramms durch, um ein ASN.1-Objekt zu bilden, das einem ASN.1-Message-Objekt entspricht. Schlägt die Analyse fehl, verwirft sie das Datagramm und führt keine weiteren Aktionen aus.
-
Sie prüft dann die Versionsnummer der SNMP-Nachricht. Bei einer Nichtübereinstimmung verwirft sie das Datagramm und führt keine weiteren Aktionen aus.
-
Die Protokollentität übergibt dann den Community-Namen und die im ASN.1-Message-Objekt gefundenen Benutzerdaten zusammen mit den Quell- und Ziel-Transportadressen des Datagramms an den Dienst, der das gewünschte Authentifizierungsschema implementiert. Diese Entität gibt ein weiteres ASN.1-Objekt zurück oder signalisiert einen Authentifizierungsfehler. Im letzteren Fall vermerkt die Protokollentität diesen Fehler, erzeugt (möglicherweise) einen Trap und verwirft das Datagramm und führt keine weiteren Aktionen aus.
-
Die Protokollentität führt dann eine rudimentäre Analyse des vom Authentifizierungsdienst zurückgegebenen ASN.1-Objekts durch, um ein ASN.1-Objekt zu bilden, das einem ASN.1-PDUs-Objekt entspricht. Schlägt die Analyse fehl, verwirft sie das Datagramm und führt keine weiteren Aktionen aus. Andernfalls wird unter Verwendung der benannten SNMP-Community das geeignete Profil ausgewählt und die PDU entsprechend verarbeitet. Wird infolge dieser Verarbeitung eine Nachricht zurückgegeben, so muss die Quell-Transportadresse, von der die Antwortnachricht gesendet wird, identisch mit der Ziel-Transportadresse sein, an die die ursprüngliche Anforderungsnachricht gesendet wurde.
4.1.1. Gemeinsame Konstrukte
Bevor die sechs PDU-Typen des Protokolls eingeführt werden, ist es angebracht, einige der häufig verwendeten ASN.1-Konstrukte zu betrachten:
-- request/response information
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
ErrorIndex ::=
INTEGER
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
RequestIDs werden verwendet, um ausstehende Anforderungen voneinander zu unterscheiden. Mithilfe der RequestID kann eine SNMP-Anwendungsentität eingehende Antworten ausstehenden Anforderungen zuordnen. In Fällen, in denen ein unzuverlässiger Datagramm-Dienst verwendet wird, bietet die RequestID zudem ein einfaches Mittel, um vom Netzwerk duplizierte Nachrichten zu erkennen.
Eine ErrorStatus-Instanz ungleich null zeigt an, dass bei der Verarbeitung einer Anforderung eine Ausnahme aufgetreten ist. In diesen Fällen kann ErrorIndex zusätzliche Informationen liefern, indem angegeben wird, welche Variable in einer Liste die Ausnahme verursacht hat.
Der Begriff Variable bezeichnet eine Instanz eines verwalteten Objekts. Eine Variablenbindung, oder VarBind, bezeichnet die Paarung des Namens einer Variablen mit dem Wert der Variablen. Eine VarBindList ist eine einfache Liste von Variablennamen und zugehörigen Werten. Einige PDUs betreffen nur den Namen einer Variablen und nicht ihren Wert (z. B. die GetRequest-PDU). In diesem Fall wird der Wertteil der Bindung von der Protokollentität ignoriert. Der Wertteil muss jedoch weiterhin eine gültige ASN.1-Syntax und -Kodierung aufweisen. Es wird empfohlen, für den Wertteil solcher Bindungen den ASN.1-Wert NULL zu verwenden.
4.1.2. Die GetRequest-PDU
Die Form der GetRequest-PDU ist:
The form of the GetRequest-PDU is:
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
Die GetRequest-PDU wird von einer Protokollentität nur auf Anforderung ihrer SNMP-Anwendungsentität erzeugt.
Beim Empfang der GetRequest-PDU antwortet die empfangende Protokollentität gemäß jeder anwendbaren Regel in der folgenden Liste:
-
Wenn für irgendein im Feld variable-bindings benanntes Objekt der Name des Objekts nicht genau mit dem Namen irgendeines für get-Operationen in der relevanten MIB-Sicht verfügbaren Objekts übereinstimmt, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status noSuchName ist und der Wert des Felds error-index der Index dieser Objektnamenskomponente in der empfangenen Nachricht ist.
-
Wenn für irgendein im Feld variable-bindings benanntes Objekt das Objekt ein aggregierender Typ ist (wie in der SMI definiert), sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status noSuchName ist und der Wert des Felds error-index der Index dieser Objektnamenskomponente in der empfangenen Nachricht ist.
-
Wenn die Größe der wie unten beschrieben erzeugten GetResponse-PDU eine lokale Beschränkung überschreiten würde, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status tooBig ist und der Wert des Felds error-index null ist.
-
Wenn für irgendein im Feld variable-bindings benanntes Objekt der Wert des Objekts aus Gründen, die von keiner der vorstehenden Regeln erfasst werden, nicht abgerufen werden kann, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status genErr ist und der Wert des Felds error-index der Index dieser Objektnamenskomponente in der empfangenen Nachricht ist.
Wenn keine der vorstehenden Regeln zutrifft, sendet die empfangende Protokollentität an den Urheber der empfangenen Nachricht die GetResponse-PDU derart, dass für jedes im Feld variable-bindings der empfangenen Nachricht benannte Objekt die entsprechende Komponente der GetResponse-PDU den Namen und den Wert dieser Variablen darstellt. Der Wert des Felds error-status der GetResponse-PDU ist noError und der Wert des Felds error-index ist null. Der Wert des Felds request-id der GetResponse-PDU ist der der empfangenen Nachricht.
4.1.3. Die GetNextRequest-PDU
Die Form der GetNextRequest-PDU ist identisch mit der der GetRequest-PDU, abgesehen von der Angabe des PDU-Typs. In der ASN.1-Sprache:
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
Die GetNextRequest-PDU wird von einer Protokollentität nur auf Anforderung ihrer SNMP-Anwendungsentität erzeugt.
Beim Empfang der GetNextRequest-PDU antwortet die empfangende Protokollentität gemäß jeder anwendbaren Regel in der folgenden Liste:
-
Wenn für irgendeinen Objektnamen im Feld variable-bindings dieser Name lexikographisch nicht vor dem Namen irgendeines für get-Operationen in der relevanten MIB-Sicht verfügbaren Objekts steht, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status noSuchName ist und der Wert des Felds error-index der Index dieser Objektnamenskomponente in der empfangenen Nachricht ist.
-
Wenn die Größe der wie unten beschrieben erzeugten GetResponse-PDU eine lokale Beschränkung überschreiten würde, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status tooBig ist und der Wert des Felds error-index null ist.
-
Wenn für irgendein im Feld variable-bindings benanntes Objekt der Wert des lexikographischen Nachfolgers des benannten Objekts aus Gründen, die von keiner der vorstehenden Regeln erfasst werden, nicht abgerufen werden kann, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status genErr ist und der Wert des Felds error-index der Index dieser Objektnamenskomponente in der empfangenen Nachricht ist.
Wenn keine der vorstehenden Regeln zutrifft, sendet die empfangende Protokollentität an den Urheber der empfangenen Nachricht die GetResponse-PDU derart, dass für jeden Namen im Feld variable-bindings der empfangenen Nachricht die entsprechende Komponente der GetResponse-PDU den Namen und den Wert jenes Objekts darstellt, dessen Name in der lexikographischen Ordnung der Namen aller für get-Operationen in der relevanten MIB-Sicht verfügbaren Objekte zusammen mit dem Wert des Namensfelds der gegebenen Komponente der unmittelbare Nachfolger dieses Werts ist. Der Wert des Felds error-status der GetResponse-PDU ist noError und der Wert des Felds error-index ist null. Der Wert des Felds request-id der GetResponse-PDU ist der der empfangenen Nachricht.
4.1.3.1. Beispiel für das Durchlaufen einer Tabelle
Eine wichtige Verwendung der GetNextRequest-PDU ist das Durchlaufen konzeptueller Informationstabellen innerhalb der MIB. Die Semantik dieser Art von SNMP-Nachricht bietet zusammen mit den protokollspezifischen Mechanismen zur Identifikation einzelner Instanzen von Objekttypen in der MIB Zugriff auf verwandte Objekte in der MIB, als hätten sie eine tabellarische Organisation.
Durch den unten skizzierten SNMP-Austausch könnte eine SNMP-Anwendungsentität die Zieladresse und das Next-Hop-Gateway für jeden Eintrag in der Routing-Tabelle eines bestimmten Netzwerkelements extrahieren. Angenommen, diese Routing-Tabelle hat drei Einträge:
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
Die Management-Station sendet an den SNMP-Agenten eine GetNextRequest-PDU, die die angegebenen OBJECT IDENTIFIER-Werte als die angeforderten Variablennamen enthält:
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
Der SNMP-Agent antwortet mit einer GetResponse-PDU:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
Die Management-Station fährt fort mit:
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
Der SNMP-Agent antwortet:
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
Die Management-Station fährt fort mit:
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
Der SNMP-Agent antwortet:
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
Die Management-Station fährt fort mit:
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
Da keine weiteren Einträge in der Tabelle vorhanden sind, gibt der SNMP-Agent jene Objekte zurück, die in der lexikographischen Ordnung der bekannten Objektnamen als nächste folgen. Diese Antwort signalisiert der Management-Station das Ende der Routing-Tabelle.
4.1.4. Die GetResponse-PDU
Die Form der GetResponse-PDU ist identisch mit der der GetRequest-PDU, abgesehen von der Angabe des PDU-Typs. In der ASN.1-Sprache:
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
Die GetResponse-PDU wird von einer Protokollentität nur beim Empfang der GetRequest-PDU, GetNextRequest-PDU oder SetRequest-PDU erzeugt, wie an anderer Stelle in diesem Dokument beschrieben.
Beim Empfang der GetResponse-PDU präsentiert die empfangende Protokollentität ihren Inhalt ihrer SNMP-Anwendungsentität.
4.1.5. Die SetRequest-PDU
Die Form der SetRequest-PDU ist identisch mit der der GetRequest-PDU, abgesehen von der Angabe des PDU-Typs. In der ASN.1-Sprache:
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
Die SetRequest-PDU wird von einer Protokollentität nur auf Anforderung ihrer SNMP-Anwendungsentität erzeugt.
Beim Empfang der SetRequest-PDU antwortet die empfangende Entität gemäß jeder anwendbaren Regel in der folgenden Liste:
-
Wenn für irgendein im Feld variable-bindings benanntes Objekt das Objekt nicht für set-Operationen in der relevanten MIB-Sicht verfügbar ist, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status noSuchName ist und der Wert des Felds error-index der Index dieser Objektnamenskomponente in der empfangenen Nachricht ist.
-
Wenn für irgendein im Feld variable-bindings benanntes Objekt der Inhalt des Wertfelds gemäß der ASN.1-Sprache keinen Typ, keine Länge und keinen Wert aufweist, die mit dem für die Variable erforderlichen konsistent sind, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status badValue ist und der Wert des Felds error-index der Index dieses Objektnamens in der empfangenen Nachricht ist.
-
Wenn die Größe der wie unten beschrieben erzeugten Nachricht vom Get-Response-Typ eine lokale Beschränkung überschreiten würde, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status tooBig ist und der Wert des Felds error-index null ist.
-
Wenn für irgendein im Feld variable-bindings benanntes Objekt der Wert des benannten Objekts aus Gründen, die von keiner der vorstehenden Regeln erfasst werden, nicht geändert werden kann, sendet die empfangende Entität an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status genErr ist und der Wert des Felds error-index der Index dieser Objektnamenskomponente in der empfangenen Nachricht ist.
Wenn keine der vorstehenden Regeln zutrifft, wird für jedes im Feld variable-bindings der empfangenen Nachricht benannte Objekt der entsprechende Wert der Variablen zugewiesen. Jede durch die SetRequest-PDU angegebene Variablenzuweisung sollte so ausgeführt werden, als würde sie in Bezug auf alle anderen in derselben Nachricht angegebenen Zuweisungen gleichzeitig gesetzt.
Die empfangende Entität sendet dann an den Urheber der empfangenen Nachricht die GetResponse-PDU in identischer Form, außer dass der Wert des Felds error-status der erzeugten Nachricht noError ist und der Wert des Felds error-index null ist.
4.1.6. Die Trap-PDU
Die Form der Trap-PDU ist:
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
agent-addr -- address of object generating
NetworkAddress, -- trap
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
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the network
-- entity and the generation of the
trap
variable-bindings -- "interesting" information
VarBindList
}
Die Trap-PDU wird von einer Protokollentität nur auf Anforderung der SNMP-Anwendungsentität erzeugt. Die Art und Weise, wie eine SNMP-Anwendungsentität die Zieladressen der SNMP-Anwendungsentitäten auswählt, ist implementierungsspezifisch.
Beim Empfang der Trap-PDU präsentiert die empfangende Protokollentität ihren Inhalt ihrer SNMP-Anwendungsentität.
Die Bedeutung der Komponente variable-bindings der Trap-PDU ist implementierungsspezifisch.
Interpretationen des Werts des Felds generic-trap sind:
4.1.6.1. Der coldStart-Trap
Ein coldStart(0)-Trap bedeutet, dass die sendende Protokollentität sich selbst neu initialisiert, sodass die Konfiguration des Agenten oder die Implementierung der Protokollentität geändert werden kann.
4.1.6.2. Der warmStart-Trap
Ein warmStart(1)-Trap bedeutet, dass die sendende Protokollentität sich selbst neu initialisiert, sodass weder die Konfiguration des Agenten noch die Implementierung der Protokollentität geändert wird.
4.1.6.3. Der linkDown-Trap
Ein linkDown(2)-Trap bedeutet, dass die sendende Protokollentität einen Ausfall in einer der in der Konfiguration des Agenten dargestellten Kommunikationsverbindungen erkennt.
Die Trap-PDU vom Typ linkDown enthält als erstes Element ihrer variable-bindings den Namen und den Wert der ifIndex-Instanz für die betroffene Schnittstelle.
4.1.6.4. Der linkUp-Trap
Ein linkUp(3)-Trap bedeutet, dass die sendende Protokollentität erkennt, dass eine der in der Konfiguration des Agenten dargestellten Kommunikationsverbindungen aktiv geworden ist.
Die Trap-PDU vom Typ linkUp enthält als erstes Element ihrer variable-bindings den Namen und den Wert der ifIndex-Instanz für die betroffene Schnittstelle.
4.1.6.5. Der authenticationFailure-Trap
Ein authenticationFailure(4)-Trap bedeutet, dass die sendende Protokollentität der Adressat einer Protokollnachricht ist, die nicht ordnungsgemäß authentifiziert ist. Implementierungen des SNMP müssen in der Lage sein, diesen Trap zu erzeugen, sie müssen jedoch auch in der Lage sein, die Ausgabe solcher Traps über einen implementierungsspezifischen Mechanismus zu unterdrücken.
4.1.6.6. Der egpNeighborLoss-Trap
Ein egpNeighborLoss(5)-Trap bedeutet, dass ein EGP-Nachbar, für den die sendende Protokollentität ein EGP-Peer war, als ausgefallen markiert wurde und die Peer-Beziehung nicht mehr besteht.
Die Trap-PDU vom Typ egpNeighborLoss enthält als erstes Element ihrer variable-bindings den Namen und den Wert der egpNeighAddr-Instanz für den betroffenen Nachbarn.
4.1.6.7. Der enterpriseSpecific-Trap
Ein enterpriseSpecific(6)-Trap bedeutet, dass die sendende Protokollentität erkennt, dass ein unternehmensspezifisches Ereignis eingetreten ist. Das Feld specific-trap identifiziert den jeweiligen aufgetretenen Trap.