Zum Hauptinhalt springen

3. Elements Of Procedure

Die folgenden Abschnitte beschreiben die Verfahren, die von jedem der fünf Typen von SNMP-Anwendungen beim Erzeugen und Verarbeiten von SNMP-Nachrichten befolgt werden.

3.1. Command Generator-Anwendungen​

Eine Command Generator-Anwendung nutzt das SNMP-Message-Processing-Subsystem, um SNMP-Nachrichten an eine entfernte SNMP-Anwendung zu übergeben.

Der Command Generator muss in der Lage sein, die Transport-Domain und Transport-Adresse der entfernten Anwendung zu bestimmen. Die Methode, wie dies erreicht wird, ist implementierungsabhängig und außerhalb des Geltungsbereichs dieses Dokuments.

Der Command Generator muss in der Lage sein, die geeigneten SNMP-Nachrichtenparameter (Message Processing Model, Security Model, Security Level und Security Name) zu bestimmen, die bei der Kommunikation mit der entfernten Anwendung verwendet werden sollen. Die Methode, wie dies erreicht wird, ist implementierungsabhängig und außerhalb des Geltungsbereichs dieses Dokuments.

3.1.1. Erzeugen einer Befehlsanfrage​

Um eine SNMP-Befehlsanfrage zu senden, führt die Command Generator-Anwendung Folgendes aus:

  1. Verwendet ihre lokalen Konfigurationsinformationen, um Folgendes zu bestimmen:

    • Transport-Domain und Transport-Adresse
    • Message Processing Model
    • Security Model
    • Security Name
    • Security Level
    • Context Engine ID (contextEngineID)
    • Context Name (contextName)
    • Die entsprechende PDU (GetRequest, GetNextRequest, GetBulkRequest oder SetRequest)

  2. Ruft die send PDU-Primitive des Message-Processing-Subsystems auf und übergibt:

    • Transport-Domain und Transport-Adresse
    • Message Processing Model
    • Security Model
    • Security Name
    • Security Level
    • contextEngineID
    • contextName
    • PDU

  3. Das Message-Processing-Subsystem gibt eine Statusanzeige zurück. Falls ein Fehler zurückgegeben wird, sollte der Command Generator den Fehler angemessen behandeln.

3.1.2. Verarbeiten einer Antwort​

Wenn ein Command Generator eine Antwort empfängt:

  1. Das Message-Processing-Subsystem ruft die receive PDU-Primitive des Command Generators auf und übergibt:

    • Message Processing Model
    • Security Model
    • Security Name
    • Security Level
    • contextEngineID
    • contextName
    • PDU
    • Maximale Größe (maxSizeResponseScopedPDU)
    • Statusinformationen

  2. Der Command Generator überprüft, dass die Antwort mit einer ausstehenden Anfrage übereinstimmt (über request-id).

  3. Der Command Generator prüft den error-status in der Antwort. Falls das error-status-Feld ungleich Null ist, ist ein Fehler aufgetreten.

  4. Der Command Generator verarbeitet die variable-bindings-Liste in der Antwort.

3.1.3. Timeouts und Wiederholungen​

Falls innerhalb einer angemessenen Zeitspanne keine Antwort empfangen wird, kann der Command Generator die Anfrage erneut senden. Die Anzahl der Wiederholungen und Timeout-Werte werden durch lokale Konfiguration oder Richtlinien bestimmt.

Für zuverlässige Transportprotokolle (wie TCP) kann die Transportschicht selbst eine erneute Übertragung bereitstellen. In solchen Fällen können Wiederholungen auf Anwendungsebene unnötig oder unangemessen sein.

3.2. Command Responder-Anwendungen​

Eine Command Responder-Anwendung empfängt SNMP-Befehlsanfragen und erzeugt entsprechende Antworten.

3.2.1. Verarbeiten einer Anfrage​

Wenn ein Command Responder eine Anfrage empfängt:

  1. Das Message-Processing-Subsystem ruft die receive PDU-Primitive des Command Responders auf und übergibt:

    • Message Processing Model
    • Security Model
    • Security Name
    • Security Level
    • contextEngineID
    • contextName
    • PDU
    • Maximale Größe (maxSizeResponseScopedPDU)
    • Statusinformationen

  2. Der Command Responder überprüft, dass die contextEngineID die lokale SNMP-Engine identifiziert. Falls nicht, wird die Anfrage verworfen.

  3. Der Command Responder verwendet das Access-Control-Subsystem (wie VACM, definiert in RFC 3415), um zu bestimmen, ob der Security Name autorisiert ist, die angeforderte Operation durchzuführen.

  4. Der Command Responder verarbeitet die PDU:

    • GetRequest: Ruft Werte angeforderter MIB-Objekte ab
    • GetNextRequest: Ruft das nächste MIB-Objekt lexikografisch nach dem angeforderten Objektnamen ab
    • GetBulkRequest: Führt einen optimierten Multi-Variable-Abruf durch
    • SetRequest: Modifiziert die Werte angegebener MIB-Objekte

  5. Der Command Responder erstellt eine Antwort-PDU, die Folgendes enthält:

    • Die gleiche request-id wie die Anfrage
    • Error-status (noError oder ein entsprechender Fehlercode)
    • Error-index (falls ein Fehler aufgetreten ist, gibt an, welches variable-binding den Fehler verursacht hat)
    • Variable-bindings-Liste (für Get-Operationen enthält sie abgerufene Werte; für Set-Operationen enthält sie die gesetzten Variablen)

3.2.2. Erzeugen einer Antwort​

Der Command Responder erzeugt eine Antwort durch:

  1. Konstruktion einer Response-PDU mit dem entsprechenden error-status, error-index und variable-bindings-Liste.

  2. Aufruf der return response PDU-Primitive des Message-Processing-Subsystems und Übergabe von:

    • Message Processing Model (gleich wie Anfrage)
    • Security Model (gleich wie Anfrage)
    • Security Name (gleich wie Anfrage)
    • Security Level (gleich wie Anfrage)
    • contextEngineID (gleich wie Anfrage)
    • contextName (gleich wie Anfrage)
    • PDU (die Antwort-PDU)
    • Maximale Größe (die maxSizeResponseScopedPDU aus der Anfrage)
    • State Reference (aus der Anfragebearbeitung erhalten)

  3. Das Message-Processing-Subsystem übernimmt die Formatierung und Übertragung der Antwortnachricht.

3.2.3. Fehlerbehandlung​

Falls während der Verarbeitung der Anfrage ein Fehler auftritt, muss der Command Responder einen entsprechenden error-status in der Antwort-PDU setzen:

  • tooBig: Antwortnachricht ist zu groß, um innerhalb der maximalen Nachrichtengrößenbeschränkungen übertragen zu werden
  • noSuchName: Angefordertes Objekt existiert nicht (nur SNMPv1)
  • badValue: Der angegebene Wert ist für die angeforderte Operation ungeeignet (nur SNMPv1)
  • readOnly: Versuch, ein schreibgeschütztes Objekt zu modifizieren
  • genErr: Ein allgemeiner Fehler ist aufgetreten
  • noAccess: Zugriff verweigert (SNMPv2 und später)
  • wrongType: Die Variable hat den falschen Typ (SNMPv2 und später)
  • wrongLength: Der Wert hat die falsche Länge (SNMPv2 und später)
  • wrongEncoding: Der Wert hat die falsche Kodierung (SNMPv2 und später)
  • wrongValue: Der Wert ist inkorrekt (SNMPv2 und später)
  • noCreation: Erstellung ist nicht erlaubt (SNMPv2 und später)
  • inconsistentValue: Der Wert ist inkonsistent (SNMPv2 und später)
  • resourceUnavailable: Ressourcen sind nicht verfügbar (SNMPv2 und später)
  • commitFailed: Commit fehlgeschlagen (SNMPv2 und später)
  • undoFailed: Rückgängigmachen fehlgeschlagen (SNMPv2 und später)
  • authorizationError: Autorisierungsfehler (SNMPv2 und später)
  • notWritable: Das Objekt ist nicht beschreibbar (SNMPv2 und später)
  • inconsistentName: Der Name ist inkonsistent (SNMPv2 und später)

3.3. Notification Originator-Anwendungen​

Eine Notification Originator-Anwendung erzeugt SNMP-Benachrichtigungsnachrichten (Traps oder Inform-Requests).

3.3.1. Erzeugen einer Benachrichtigung​

Um eine SNMP-Benachrichtigung zu senden, führt der Notification Originator Folgendes aus:

  1. Bestimmt die Menge der Management Targets, die diese Benachrichtigung erhalten sollen. Dies wird typischerweise durch Konsultation der SNMP-TARGET-MIB und SNMP-NOTIFICATION-MIB durchgeführt.

  2. Für jedes ausgewählte Management Target:

    a. Bestimmt die Transport-Domain und Transport-Adresse

    b. Bestimmt die SNMP-Nachrichtenparameter:

    • Message Processing Model
    • Security Model
    • Security Name
    • Security Level

    c. Bestimmt den Benachrichtigungstyp (Trap oder Inform)

    d. Konstruiert die entsprechende PDU:

    • SNMPv2-Trap-PDU: Für unbestätigte Benachrichtigungen
    • InformRequest-PDU: Für bestätigte Benachrichtigungen

    e. Die PDU sollte Folgendes enthalten:

    • sysUpTime.0-Variable (Zeit seit Engine-Start)
    • snmpTrapOID.0-Variable (Objektidentifikator der Benachrichtigung)
    • Zusätzliche variable-bindings für die Benachrichtigung

    f. Ruft die send PDU-Primitive des Message-Processing-Subsystems auf

3.3.2. Verarbeiten einer Antwort auf einen Inform-Request​

Falls der Benachrichtigungstyp Inform (InformRequest-PDU) ist, muss der Notification Originator auf eine Antwort warten:

  1. Falls eine Antwort innerhalb der Timeout-Periode empfangen wird:

    • Überprüfen, dass die Antwort mit dem ausstehenden Inform-Request übereinstimmt (über request-id)
    • Prüfen des error-status
    • Bestätigen, dass die Benachrichtigung erfolgreich zugestellt wurde

  2. Falls innerhalb der Timeout-Periode keine Antwort empfangen wird:

    • Je nach konfigurierter Wiederholungsrichtlinie kann der Inform-Request erneut gesendet werden
    • Oder der Fehler wird lokal protokolliert und dieser Zustellversuch aufgegeben

  3. Für Traps (SNMPv2-Trap-PDU) wird keine Antwort erwartet, daher ist der Notification Originator sofort nach dem Senden fertig.

3.4. Notification Receiver-Anwendungen​

Eine Notification Receiver-Anwendung empfängt SNMP-Benachrichtigungsnachrichten.

3.4.1. Verarbeiten einer empfangenen Benachrichtigung​

Wenn ein Notification Receiver eine Benachrichtigung empfängt:

  1. Das Message-Processing-Subsystem ruft die receive PDU-Primitive des Notification Receivers auf und übergibt:

    • Message Processing Model
    • Security Model
    • Security Name
    • Security Level
    • contextEngineID
    • contextName
    • PDU
    • Maximale Größe
    • Statusinformationen

  2. Der Notification Receiver extrahiert die Benachrichtigungsinformationen:

    • sysUpTime.0 (Zeitstempel)
    • snmpTrapOID.0 (Benachrichtigungstyp)
    • Zusätzliche variable-bindings (Benachrichtigungsdaten)

  3. Der Notification Receiver verarbeitet die Benachrichtigung gemäß lokaler Richtlinie:

    • In eine Protokolldatei schreiben
    • Eine Warnung anzeigen
    • Eine automatisierte Reaktionsaktion auslösen
    • An andere Management-Systeme weiterleiten

3.4.2. Antworten auf einen Inform-Request​

Falls eine InformRequest-PDU empfangen wird, muss der Notification Receiver eine Antwort erzeugen:

  1. Eine Response-PDU konstruieren, die Folgendes enthält:

    • Die gleiche request-id wie die Anfrage
    • Error-status (typischerweise noError)
    • Error-index (typischerweise 0)
    • Variable-bindings-Liste (typischerweise die gleiche wie in der Anfrage)

  2. Die return response PDU-Primitive des Message-Processing-Subsystems aufrufen, um die Antwort zu senden.

Für SNMPv2-Trap-PDU wird keine Antwort erzeugt.

3.5. Proxy Forwarder-Anwendungen​

Eine Proxy Forwarder-Anwendung leitet SNMP-Nachrichten zwischen SNMP-Entitäten weiter. Proxy Forwarders können Protokollübersetzung, Sicherheitsübersetzung oder Management-Informations-View-Übersetzung durchführen.

Eine Proxy Forwarder-Anwendung führt zwei Arten der Weiterleitung durch:

  1. Request Forwarding: Weiterleitung von Befehlsanfragen und deren Antworten
  2. Notification Forwarding: Weiterleitung von Benachrichtigungsnachrichten

3.5.1. Request Forwarding​

Wenn ein Proxy Forwarder eine Befehlsanfrage empfängt:

  1. Das Message-Processing-Subsystem ruft die receive PDU-Primitive des Proxy Forwarders auf und übergibt die Anfrageparameter.

  2. Der Proxy Forwarder verwendet die SNMP-PROXY-MIB, um zu bestimmen, wie die Anfrage weitergeleitet werden soll:

    a. Konsultiert die snmpProxyTable unter Verwendung der empfangenen Parameter als Schlüssel:

    • contextEngineID
    • contextName
    • Transport-Domain und Transport-Adresse
    • PDU-Typ

    b. Falls ein passender Eintrag gefunden wird, extrahiert die Weiterleitungsparameter:

    • Ziel-Transport-Domain und Transport-Adresse
    • Ziel-Message-Processing-Model
    • Ziel-Security-Model
    • Ziel-Security-Name
    • Ziel-Security-Level
    • Ziel-contextEngineID
    • Ziel-contextName

  3. Der Proxy Forwarder muss möglicherweise die PDU modifizieren, um die Ziel-SNMP-Version zu berücksichtigen. Zum Beispiel:

    • SNMPv2 zu SNMPv1: Error-status-Codes konvertieren
    • SNMPv1 zu SNMPv2: Trap-PDU-Format konvertieren

  4. Der Proxy Forwarder ruft die send PDU-Primitive des Message-Processing-Subsystems auf, um die modifizierte Anfrage an das Ziel weiterzuleiten.

  5. Wenn eine Antwort vom Ziel empfangen wird:

    a. Muss möglicherweise die Antwort-PDU erneut modifizieren, um die SNMP-Version des ursprünglichen Anforderers zu berücksichtigen

    b. Ruft die return response PDU-Primitive des Message-Processing-Subsystems auf, um die Antwort zurück an den ursprünglichen Anforderer weiterzuleiten

3.5.2. Notification Forwarding​

Wenn ein Proxy Forwarder eine Benachrichtigung empfängt:

  1. Das Message-Processing-Subsystem ruft die receive PDU-Primitive des Proxy Forwarders auf und übergibt die Benachrichtigungsparameter.

  2. Der Proxy Forwarder verwendet die SNMP-PROXY-MIB, um zu bestimmen, wie die Benachrichtigung weitergeleitet werden soll:

    a. Konsultiert die snmpProxyTable unter Verwendung der empfangenen Parameter als Schlüssel

    b. Falls ein passender Eintrag gefunden wird, extrahiert die Weiterleitungsparameter

  3. Der Proxy Forwarder muss möglicherweise die Benachrichtigungs-PDU modifizieren:

    • SNMPv1-Trap zu SNMPv2-Trap: PDU-Format und variable-bindings konvertieren
    • SNMPv2-Trap zu SNMPv1-Trap: PDU-Format konvertieren

  4. Der Proxy Forwarder ruft die send PDU-Primitive des Message-Processing-Subsystems auf, um die Benachrichtigung an das Ziel weiterzuleiten.

  5. Falls die ursprüngliche Benachrichtigung eine InformRequest-PDU war und die weitergeleitete Benachrichtigung ebenfalls eine InformRequest-PDU ist:

    a. Auf eine Antwort vom Ziel warten

    b. Wenn die Antwort empfangen wird, die Antwort zurück an den ursprünglichen Notification Originator weiterleiten

3.5.3. Besondere Überlegungen für Proxy Forwarders​

Proxy Forwarders müssen mehrere Spezialfälle behandeln:

  1. PDU-Größenanpassung: Falls das Ziel eine kleinere maximale Nachrichtengröße als die ursprüngliche Anfrage unterstützt, muss der Proxy Forwarder möglicherweise einen tooBig-Fehler zurückgeben oder die Anfrage aufteilen.

  2. Kontextübersetzung: Der Proxy Forwarder muss möglicherweise zwischen verschiedenen contextEngineIDs und contextNames zuordnen.

  3. Zugriffskontrolle: Der Proxy Forwarder wendet seine eigenen Zugriffskontrollrichtlinien zusätzlich zu jeder Zugriffskontrolle beim Ziel-Command-Responder an.

  4. Fehler-Mapping: Bei der Übersetzung zwischen SNMP-Versionen müssen Fehlercodes möglicherweise zugeordnet werden. Zum Beispiel muss ein SNMPv2-noAccess-Fehler möglicherweise zu genErr in SNMPv1 zugeordnet werden.

  5. Timeouts und Wiederholungen: Der Proxy Forwarder muss möglicherweise seinen eigenen Timeout- und Wiederholungsmechanismus für weitergeleitete Anfragen implementieren, unabhängig vom Timeout des ursprünglichen Anforderers.

  6. Benachrichtigungsfilterung: Für die Benachrichtigungsweiterleitung kann der Proxy Forwarder Filterregeln anwenden, um bestimmte Arten von Benachrichtigungen selektiv weiterzuleiten.