Zum Hauptinhalt springen

RFC 1157 - Einfaches Netzwerkverwaltungsprotokoll (SNMP)

Network Working Group Request for Comments: 1157 Obsolet: RFC 1098

Autoren: J. Case (SNMP Research) M. Fedor (Performance Systems International) M. Schoffstall (Performance Systems International) J. Davin (MIT Laboratory for Computer Science)

Datum: May 1990

Inhaltsverzeichnis​

1. Status dieses Dokuments​

Dieser RFC ist eine Neuveröffentlichung von RFC 1098, mit einem geänderten Abschnitt „Status dieses Memos“ sowie einigen kleineren typografischen Korrekturen. Dieses Memo definiert ein einfaches Protokoll, mit dem Verwaltungsinformationen für ein Netzwerkelement von logisch entfernten Benutzern überprüft oder geändert werden können. Insbesondere bieten diese Dokumente zusammen mit den begleitenden Memos, die die Struktur der Managementinformationen zusammen mit der Managementinformationsbasis beschreiben, eine einfache, praktikable Architektur und ein System für die Verwaltung von TCP/IP-basierten Internets und insbesondere des Internets.

Das Internet Activities Board empfiehlt, dass alle IP- und TCP-Implementierungen über das Netzwerk verwaltet werden können. Dies setzt die Implementierung des Internets MIB (RFC-1156) und mindestens eines der beiden empfohlenen Verwaltungsprotokolle SNMP (RFC-1157) oder CMOT (RFC-1095) voraus. Es ist zu beachten, dass SNMP derzeit ein vollständiger Internetstandard und CMOT ein Standardentwurf ist. Genauere Informationen zur Anwendbarkeit dieses Standards finden Sie auch in den RFCs zu Host- und Gateway-Anforderungen.

Aktuelle Informationen zum Zustand und Status der Standard-Internetprotokolle finden Sie in der neuesten Ausgabe des RFC „IAB Official Protocol Standards“.

Die Verbreitung dieses Memos ist unbegrenzt.

2. Einleitung​

Wie in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], berichtet, wurde eine zweigleisige Strategie für das Netzwerkmanagement von TCP/IP-basierten Internets verfolgt. Kurzfristig sollte das Simple Network Management Protocol (SNMP) zur Verwaltung von Knoten in der Internet-Community eingesetzt werden. Langfristig sollte der Einsatz des Netzwerkmanagement-Frameworks OSI untersucht werden. Zur Definition der Managementinformationen wurden zwei Dokumente erstellt: RFC 1065, das die Struktur der Managementinformationen (SMI) [2] definiert, und RFC 1066, das die Managementinformationsbasis (MIB) [3] definiert. Beide Dokumente wurden so konzipiert, dass sie mit den Netzwerkmanagement-Frameworks SNMP und OSI kompatibel sind.

Diese Strategie war kurzfristig recht erfolgreich: Innerhalb weniger Monate wurde die internetbasierte Netzwerkmanagementtechnologie sowohl von der Forschung als auch von der Wirtschaft eingesetzt. Dadurch wurden Teile der Internet-Community rechtzeitig netzwerkfähig.

Wie in RFC 1109, Bericht der Second Ad Hoc Network Management Review Group [4], berichtet, waren die Anforderungen der Netzwerkmanagement-Frameworks SNMP und OSI unterschiedlicher als erwartet. Daher wurde die Anforderung der Kompatibilität zwischen SMI/MIB und beiden Frameworks ausgesetzt. Diese Aktion ermöglichte es dem operativen Netzwerkmanagement-Framework SNMP, auf neue betriebliche Anforderungen in der Internet-Community zu reagieren, indem es Dokumente erstellte, die neue MIB-Elemente definieren.

Das IAB hat SNMP, SMI und das erste Internet MIB als vollständige „Standardprotokolle“ mit dem Status „Empfohlen“ eingestuft. Mit dieser Maßnahme empfiehlt das IAB, dass alle Implementierungen von IP und

Daher besteht das aktuelle Netzwerkverwaltungs-Framework für TCP/IP-basierte Internets aus: Struktur und Identifizierung von Managementinformationen für Management Information Base für die Netzwerkverwaltung von TCP/IP-basierten Internets, die die verwalteten Objekte beschreibt, die im MIB enthalten sind, wie in RFC 1156 [6] dargelegt; und das Simple Network Management Protocol, das das zur Verwaltung dieser Objekte verwendete Protokoll definiert, wie in diesem Memo dargelegt.

Wie in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], berichtet, hat das Internet Activities Board die Internet Engineering Task Force (IETF) angewiesen, zwei neue Arbeitsgruppen im Bereich Netzwerkmanagement einzurichten. Eine Gruppe wurde mit der weiteren Spezifikation und Definition der Elemente beauftragt, die in die Management Information Base (MIB) aufgenommen werden sollen. Der andere wurde damit beauftragt, die Änderungen am Simple Network Management Protocol (SNMP) zu definieren, um den kurzfristigen Anforderungen der Netzwerkanbieter und Betriebsgemeinschaften gerecht zu werden und sich an den Ergebnissen der MIB-Arbeitsgruppe auszurichten.

Die Arbeitsgruppe Ein zweites Memo [3] definiert die Liste der verwalteten Objekte.

Die Ausgabe der Arbeitsgruppe „SNMP-Erweiterungen“ ist dieses Memo, das Änderungen an der ursprünglichen SNMP-Definition [7] enthält, die erforderlich sind, um eine Übereinstimmung mit der Ausgabe der Arbeitsgruppe MIB zu erreichen. Die Änderungen sollten minimal sein, um der Anweisung des IAB zu entsprechen, dass die Arbeitsgruppen „äußerst sensibel auf die Notwendigkeit achten müssen, den SNMP einfach zu halten“. Obwohl den Änderungen am SNMP, die sich in diesem Memo widerspiegeln, große Sorgfalt und Diskussionen gewidmet wurden, ist das resultierende Protokoll nicht abwärtskompatibel mit seinem Vorgänger, dem Simple Gateway Monitoring Protocol (SGMP) [8]. Obwohl die Syntax des Protokolls geändert wurde, bleiben die ursprüngliche Philosophie, Designentscheidungen und Architektur erhalten. Um Verwirrung zu vermeiden, wurden neue UDP-Ports für die Verwendung durch das in diesem Memo beschriebene Protokoll zugewiesen.

3. Die SNMP-Architektur​

Im SNMP-Architekturmodell ist eine Sammlung von Netzwerkverwaltungsstationen und Netzwerkelementen implizit enthalten. Netzwerkmanagementstationen führen Verwaltungsanwendungen aus, die Netzwerkelemente überwachen und steuern. Netzwerkelemente sind Geräte wie Hosts, Gateways, Terminalserver und dergleichen, die über Managementagenten verfügen, die für die Ausführung der von den Netzwerkmanagementstationen angeforderten Netzwerkmanagementfunktionen verantwortlich sind. Das Simple Network Management Protocol (SNMP) wird zur Kommunikation von Verwaltungsinformationen zwischen den Netzwerkmanagementstationen und den Agenten in den Netzwerkelementen verwendet.

3.1. Ziele der Architektur​

Der SNMP minimiert explizit die Anzahl und Komplexität der Verwaltungsfunktionen, die vom Managementagenten selbst realisiert werden. Dieses Ziel ist in mindestens viererlei Hinsicht attraktiv:

  1. Die Entwicklungskosten für die Management-Agent-Software, die zur Unterstützung des Protokolls erforderlich ist, werden entsprechend reduziert.

  2. Der Grad der fernunterstützten Verwaltungsfunktion wird entsprechend erhöht, wodurch die volle Nutzung der Internetressourcen für die Verwaltungsaufgabe ermöglicht wird.

  3. Der Grad der fernunterstützten Managementfunktion wird dadurch erhöht, wodurch die Form und Komplexität der Managementtools möglichst wenig eingeschränkt werden.

  4. Vereinfachte Sätze von Verwaltungsfunktionen sind für Entwickler von Netzwerkverwaltungstools leicht zu verstehen und zu verwenden.

Ein zweites Ziel des Protokolls besteht darin, dass das funktionale Paradigma für die Überwachung und Steuerung ausreichend erweiterbar ist, um zusätzliche, möglicherweise unerwartete Aspekte des Netzwerkbetriebs und -managements zu berücksichtigen.

Ein drittes Ziel besteht darin, dass die Architektur so weit wie möglich unabhängig von der Architektur und den Mechanismen bestimmter Hosts oder bestimmter Gateways ist.

3.2. Elemente der Architektur​

Die SNMP-Architektur formuliert eine Lösung für das Netzwerkverwaltungsproblem im Hinblick auf:

  1. der Umfang der durch das Protokoll übermittelten Verwaltungsinformationen,

  2. die Darstellung der durch das Protokoll übermittelten Verwaltungsinformationen,

  3. Operationen an Verwaltungsinformationen, die vom Protokoll unterstützt werden,

  4. die Form und Bedeutung des Austauschs zwischen Verwaltungseinheiten,

  5. die Definition der Verwaltungsbeziehungen zwischen Verwaltungseinheiten und

  6. Form und Bedeutung von Verweisen auf Managementinformationen.

3.2.1. Umfang der Verwaltungsinformationen​

Der Umfang der durch den Betrieb des SNMP übermittelten Verwaltungsinformationen entspricht genau dem, der durch Instanzen aller nicht aggregierten Objekttypen repräsentiert wird, die entweder im Internet-Standard MIB definiert oder an anderer Stelle gemäß den im Internet-Standard SMI [5] dargelegten Konventionen definiert sind.

Die Unterstützung aggregierter Objekttypen im MIB ist für die Konformität mit dem SMI weder erforderlich noch wird sie vom SNMP realisiert.

3.2.2. Darstellung der Verwaltungsinformationen​

Verwaltungsinformationen, die durch den Betrieb des SNMP übermittelt werden, werden gemäß der Teilmenge der ASN.1-Sprache [9] dargestellt, die für die Definition von Nicht-Aggregattypen im SMI angegeben ist.

Der SGMP übernahm die Konvention, eine wohldefinierte Teilmenge der Sprache ASN.1 zu verwenden [9]. Der SNMP setzt diese Tradition fort und erweitert ihn, indem er eine etwas komplexere Teilmenge des ASN.1 zur Beschreibung verwalteter Objekte und zur Beschreibung der Protokolldateneinheiten verwendet, die zur Verwaltung dieser Objekte verwendet werden. Darüber hinaus führte der Wunsch, den Übergang zu OSI-basierten Netzwerkverwaltungsprotokollen zu erleichtern, zur Definition einer Internet-Standardstruktur von Verwaltungsinformationen (SMI) [5] und einer Verwaltungsinformationsbasis (MIB) [6] in der Sprache ASN.1. Die Verwendung der Sprache ASN.1 wurde teilweise durch die erfolgreiche Verwendung von ASN.1 in früheren Bemühungen, insbesondere SGMP, gefördert. Die im SMI enthaltenen Einschränkungen bei der Verwendung von Der Einfachheit halber verwendet SNMP nur eine Teilmenge der grundlegenden Kodierungsregeln von ASN.1 [10]. Alle Kodierungen verwenden nämlich die Form mit definierter Länge. Darüber hinaus werden, wann immer zulässig, Nicht-Konstruktor-Kodierungen anstelle von Konstruktor-Kodierungen verwendet. Diese Einschränkung gilt für alle Aspekte der ASN.1-Codierung, sowohl für die Protokolldateneinheiten der obersten Ebene als auch für die darin enthaltenen Datenobjekte.

3.2.3. Unterstützte Operationen auf Verwaltungsinformationen​

Der SNMP modelliert alle Managementagentenfunktionen als Änderungen oder Inspektionen von Variablen. Somit interagiert eine Protokolleinheit auf einem logisch entfernten Host (möglicherweise das Netzwerkelement selbst) mit dem auf dem Netzwerkelement residenten Managementagenten, um Variablen abzurufen (abrufen) oder zu ändern (setzen). Diese Strategie hat mindestens zwei positive Konsequenzen:

  1. Dadurch wird die Anzahl der vom Managementagenten realisierten wesentlichen Verwaltungsfunktionen auf zwei begrenzt: eine Operation zum Zuweisen eines Werts zu einer bestimmten Konfiguration oder einem anderen Parameter und eine weitere zum Abrufen eines solchen Werts.

  2. Ein zweiter Effekt dieser Entscheidung besteht darin, die Einführung einer Unterstützung für zwingende Verwaltungsbefehle in die Protokolldefinition zu vermeiden: Die Anzahl solcher Befehle nimmt in der Praxis ständig zu und die Semantik solcher Befehle ist im Allgemeinen willkürlich komplex.

Die im SNMP implizierte Strategie besteht darin, dass die Überwachung des Netzwerkstatus auf jeder signifikanten Detailebene hauptsächlich durch Abfrage geeigneter Informationen seitens der Überwachungszentrale(n) erfolgt. Eine begrenzte Anzahl unerwünschter Nachrichten (Traps) bestimmt den Zeitpunkt und die Ausrichtung der Umfrage. Die Begrenzung der Anzahl unerwünschter Nachrichten steht im Einklang mit dem Ziel der Einfachheit und Minimierung des durch die Netzwerkverwaltungsfunktion erzeugten Datenverkehrsvolumens.

Der Ausschluss imperativer Befehle aus dem Satz explizit unterstützter Verwaltungsfunktionen wird wahrscheinlich keine wünschenswerte Operation des Managementagenten ausschließen. Derzeit handelt es sich bei den meisten Befehlen um Anfragen, entweder um den Wert eines Parameters festzulegen oder einen solchen Wert abzurufen, und die Funktion der wenigen derzeit unterstützten zwingenden Befehle kann durch dieses Verwaltungsmodell problemlos in einem asynchronen Modus untergebracht werden. In diesem Schema könnte ein zwingender Befehl als Einstellung eines Parameterwerts realisiert werden, der anschließend die gewünschte Aktion auslöst. Anstatt beispielsweise einen „Neustartbefehl“ zu implementieren, könnte diese Aktion durch einfaches Festlegen eines Parameters aufgerufen werden, der die Anzahl der Sekunden bis zum Systemneustart angibt.

3.2.4. Form und Bedeutung des Protokollaustauschs​

Die Kommunikation von Verwaltungsinformationen zwischen Verwaltungseinheiten wird im SNMP durch den Austausch von Protokollnachrichten realisiert. Die Form und Bedeutung dieser Nachrichten wird unten in Abschnitt 4 definiert.

Im Einklang mit dem Ziel, die Komplexität des Managementagenten zu minimieren, erfordert der Austausch von SNMP-Nachrichten nur einen unzuverlässigen Datagrammdienst, und jede Nachricht wird vollständig und unabhängig durch ein einziges Transportdatagramm dargestellt. Während dieses Dokument den Austausch von Nachrichten über das UDP-Protokoll [11] spezifiziert, sind die Mechanismen des SNMP grundsätzlich für den Einsatz mit einer Vielzahl von Transportdiensten geeignet.

3.2.5. Definition administrativer Beziehungen​

Die SNMP-Architektur lässt eine Vielzahl von Verwaltungsbeziehungen zwischen Entitäten zu, die am Protokoll teilnehmen. Die Entitäten auf Verwaltungsstationen und Netzwerkelementen, die über SNMP miteinander kommunizieren, werden als SNMP-Anwendungsentitäten bezeichnet. Die Peer-Prozesse, die SNMP implementieren und somit die SNMP-Anwendungsentitäten unterstützen, werden als Protokollentitäten bezeichnet.

Eine Paarung eines SNMP-Agenten mit einem beliebigen Satz von SNMP-Anwendungsentitäten wird als SNMP-Community bezeichnet. Jede SNMP-Community wird durch eine Folge von Oktetten benannt, die als Community-Name für diese Community bezeichnet wird.

Eine SNMP-Nachricht, die von einer SNMP-Anwendungseinheit stammt, die tatsächlich zur SNMP-Community gehört, die durch die Community-Komponente dieser Nachricht benannt wird, wird als authentische SNMP-Nachricht bezeichnet. Der Satz von Regeln, anhand derer eine SNMP-Nachricht als authentische SNMP-Nachricht für eine bestimmte SNMP-Community identifiziert wird, wird als Authentifizierungsschema bezeichnet. Eine Implementierung einer Funktion, die authentische SNMP-Nachrichten anhand eines oder mehrerer Authentifizierungsschemata identifiziert, wird als Authentifizierungsdienst bezeichnet.

Eine effektive Verwaltung administrativer Beziehungen zwischen SNMP-Anwendungseinheiten erfordert eindeutig Authentifizierungsdienste, die (durch den Einsatz von Verschlüsselung oder anderen Techniken) in der Lage sind, authentische SNMP-Nachrichten mit einem hohen Maß an Sicherheit zu identifizieren. Einige SNMP-Implementierungen möchten möglicherweise nur einen trivialen Authentifizierungsdienst unterstützen, der alle SNMP-Nachrichten als authentische SNMP-Nachrichten identifiziert.

Für jedes Netzwerkelement wird eine Teilmenge der Objekte im MIB, die zu diesem Element gehören, als SNMP MIB-Ansicht bezeichnet. Beachten Sie, dass die Namen der in einer SNMP MIB-Ansicht dargestellten Objekttypen nicht zu einem einzelnen Unterbaum des Objekttyp-Namensraums gehören müssen.

Ein Element der Menge { READ-ONLY, READ-WRITE } wird als SNMP-Zugriffsmodus bezeichnet.

Eine Paarung eines SNMP-Zugriffsmodus mit einer SNMP-MIB-Ansicht wird als SNMP-Community-Profil bezeichnet. Ein SNMP-Community-Profil repräsentiert bestimmte Zugriffsrechte auf Variablen in einer bestimmten MIB-Ansicht. Für jede Variable in der MIB-Ansicht in einem bestimmten SNMP-Community-Profil wird der Zugriff auf diese Variable durch das Profil gemäß den folgenden Konventionen dargestellt:

  1. Wenn die Variable im MIB mit „Zugriff:“ von „none“ definiert ist, ist sie als Operand für keinen Operator verfügbar.

  2. Wenn die Variable im MIB mit „Zugriff:“ von „Lesen/Schreiben“ oder „Nur Schreiben“ definiert ist und der Zugriffsmodus des angegebenen Profils READ-WRITE ist, steht diese Variable als Operand für die Get-, Set- und Trap-Operationen zur Verfügung;

  3. andernfalls steht die Variable als Operand für die Get- und Trap-Operationen zur Verfügung.

  4. In den Fällen, in denen eine „schreibgeschützte“ Variable ein Operand ist, der für Get- oder Trap-Operationen verwendet wird, ist der für die Variable angegebene Wert implementierungsspezifisch.

Eine Paarung einer SNMP-Community mit einem SNMP-Community-Profil wird als SNMP-Zugriffsrichtlinie bezeichnet. Eine Zugriffsrichtlinie stellt ein bestimmtes Community-Profil dar, das der SNMP-Agent einer bestimmten SNMP-Community anderen Mitgliedern dieser Community zur Verfügung stellt. Alle Verwaltungsbeziehungen zwischen SNMP-Anwendungseinheiten werden architektonisch in Bezug auf SNMP-Zugriffsrichtlinien definiert.

Wenn für jede SNMP-Zugriffsrichtlinie das Netzwerkelement, auf dem sich der SNMP-Agent für die angegebene SNMP-Community befindet, nicht das ist, zu dem sich die MIB-Ansicht für das angegebene Profil bezieht, wird diese Richtlinie als SNMP-Proxy-Zugriffsrichtlinie bezeichnet. Der einer Proxy-Zugriffsrichtlinie zugeordnete SNMP-Agent wird als SNMP-Proxy-Agent bezeichnet. Während eine nachlässige Definition von Proxy-Zugriffsrichtlinien zu Verwaltungsschleifen führen kann, ist eine umsichtige Definition von Proxy-Richtlinien in mindestens zweierlei Hinsicht nützlich:

  1. Es ermöglicht die Überwachung und Steuerung von Netzwerkelementen, die ansonsten nicht über das Managementprotokoll und das Transportprotokoll ansprechbar sind. Das heißt, ein Proxy-Agent kann eine Protokollkonvertierungsfunktion bereitstellen, die es einer Verwaltungsstation ermöglicht, ein konsistentes Verwaltungsrahmenwerk auf alle Netzwerkelemente anzuwenden, einschließlich Geräten wie Modems, Multiplexern und anderen Geräten, die unterschiedliche Verwaltungsrahmenwerke unterstützen.

  2. Es schützt möglicherweise Netzwerkelemente vor aufwändigen Zugriffskontrollrichtlinien. Beispielsweise kann ein Proxy-Agent eine ausgefeilte Zugriffskontrolle implementieren, wodurch verschiedene Teilmengen von Variablen innerhalb des MIB verschiedenen Verwaltungsstationen zugänglich gemacht werden, ohne die Komplexität des Netzwerkelements zu erhöhen.

Abbildung 1 veranschaulicht beispielhaft die Beziehung zwischen Managementstationen, Proxy-Agenten und Managementagenten. In diesem Beispiel soll der Proxy-Agent ein normales Internet Network Operations Center (INOC) einer Verwaltungsdomäne sein, das eine Standardverwaltungsbeziehung mit einer Reihe von Managementagenten unterhält.

   +------------------+       +----------------+      +----------------+
   |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
   |                  |       |                |      |                |
   |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
   |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
   |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
   |                  |       |                |      |                |
   +------------------+       +----------------+      +----------------+
          /|\                      /|\                     /|\
           |                        |                       |
           |                        |                       |
           |                       \|/                      |
           |               +-----------------+              |
           +-------------->| Region #3 INOC  |<-------------+
                           |                 |
                           |Domain=Region #3 |
                           |CPU=super-mini-2 |
                           |PCommunity=pub,  |
                           |         slate   |
                           |DCommunity=secret|
           +-------------->|                 |<-------------+
           |               +-----------------+              |
           |                       /|\                      |
           |                        |                       |
           |                        |                       |
          \|/                      \|/                     \|/
   +-----------------+     +-----------------+       +-----------------+
   |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
   |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
   |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
   +-----------------+     +-----------------+       +-----------------+

Domäne: die Verwaltungsdomäne des Elements. PCommunity: der Name einer Community, die einen Proxy-Agenten verwendet. DCommunity: der Name einer direkten Community

Abbildung 1 Beispiel einer Netzwerkverwaltungskonfiguration

3.2.6. Form und Bedeutung von Verweisen auf verwaltete Objekte​

Der SMI erfordert, dass die Definition einer konformen Verwaltungsprotokolladresse:

  1. die Auflösung mehrdeutiger MIB-Referenzen,

  2. die Auflösung von MIB-Referenzen bei Vorhandensein mehrerer MIB-Versionen und

  3. die Identifizierung bestimmter Instanzen von Objekttypen, die im MIB definiert sind.

3.2.6.1. Auflösung mehrdeutiger MIB-Verweise​

Da der Umfang jeder SNMP-Operation konzeptionell auf Objekte beschränkt ist, die für ein einzelnes Netzwerkelement relevant sind, und da alle SNMP-Referenzen auf MIB-Objekte (implizit oder explizit) durch eindeutige Variablennamen erfolgen, besteht keine Möglichkeit, dass eine SNMP-Referenz auf einen in MIB definierten Objekttyp in mehrere Instanzen dieses Typs aufgelöst werden könnte.

3.2.6.2. Auflösung von Verweisen zwischen MIB-Versionen​

Die Objektinstanz, auf die sich eine SNMP-Operation bezieht, ist genau die, die als Teil der Operationsanforderung angegeben wurde, oder (im Fall einer Get-Next-Operation) ihr unmittelbarer Nachfolger im gesamten MIB. Insbesondere wird ein Verweis auf ein Objekt als Teil einer Version des Internet-Standards MIB nicht in ein Objekt aufgelöst, das nicht Teil dieser Version des Internet-Standards

3.2.6.3. Identifizierung von Objektinstanzen​

Die Namen für alle Objekttypen im MIB werden explizit entweder im Internet-Standard MIB oder in anderen Dokumenten definiert, die den Namenskonventionen des SMI entsprechen. Der SMI erfordert, dass konforme Verwaltungsprotokolle Mechanismen zur Identifizierung einzelner Instanzen dieser Objekttypen für ein bestimmtes Netzwerkelement definieren.

Jede Instanz eines in MIB definierten Objekttyps wird in SNMP-Operationen durch einen eindeutigen Namen identifiziert, der als „Variablenname“ bezeichnet wird. Im Allgemeinen ist der Name einer SNMP-Variable ein OBJECT IDENTIFIER der Form x.y, wobei x der Name eines im MIB definierten nicht aggregierten Objekttyps ist und y ein OBJECT IDENTIFIER-Fragment ist, das auf eine für den benannten Objekttyp spezifische Weise die gewünschte Instanz identifiziert.

Diese Benennungsstrategie ermöglicht die volle Ausnutzung der Semantik des GetNextRequest-PDU (siehe Abschnitt 4), da sie Namen für verwandte Variablen so zuweist, dass sie in der lexikografischen Reihenfolge aller im MIB bekannten Variablennamen zusammenhängend sind.

Die typspezifische Benennung von Objektinstanzen wird im Folgenden für eine Reihe von Klassen von Objekttypen definiert. Instanzen eines Objekttyps, auf die keine der folgenden Namenskonventionen anwendbar ist, werden durch OBJEKT-IDENTIFIER der Form x.0 benannt, wobei x der Name des Objekttyps in der MIB-Definition ist.

Angenommen, man möchte eine Instanz der Variablen sysDescr identifizieren. Die Objektklasse für sysDescr lautet:

             iso org dod internet mgmt mib system sysDescr
              1   3   6     1      2    1    1       1

Daher wäre der Objekttyp x 1.3.6.1.2.1.1.1, an den ein Instanz-Unterbezeichner von 0 angehängt wird. Das heißt, 1.3.6.1.2.1.1.1.0 identifiziert die einzige Instanz von sysDescr.

3.2.6.3.1. Namen der ifTable-Objekttypen​

Der Name einer Subnetzschnittstelle, s, ist der OBJECT IDENTIFIER-Wert der Form i, wobei i den Wert der Instanz des ifIndex-Objekttyps hat, der s zugeordnet ist.

Für jeden Objekttyp t, für den der definierte Name n das Präfix ifEntry hat, wird eine Instanz i von t durch ein OBJECT IDENTIFIER der Form n.s benannt, wobei s der Name der Subnetzschnittstelle ist, über die i Informationen darstellt.

Angenommen, man möchte die Instanz der Variablen ifType identifizieren, die der Schnittstelle 2 zugeordnet ist. Dementsprechend würde ifType.2 die gewünschte Instanz identifizieren.

3.2.6.3.2. Namen der atTable-Objekttypen​

Der Name einer im AT-Cache gespeicherten Netzwerkadresse x ist ein OBJECT IDENTIFIER der Form 1.a.b.c.d, wobei a.b.c.d der Wert (in der bekannten „Punkt“-Notation) des atNetAddress-Objekttyps ist, der x zugeordnet ist.

Der Name einer Adressübersetzungsäquivalenz e ist ein OBJECT IDENTIFIER-Wert der Form s.w, sodass s der Wert der Instanz des Objekttyps atIndex ist, der mit e verknüpft ist, und dass w der Name der im AT-Cache gespeicherten Netzwerkadresse ist, die mit e verknüpft ist. Für jeden Objekttyp t, für den der definierte Name n das Präfix atEntry hat, wird eine Instanz i von t durch ein OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name der Adressübersetzungsäquivalenz ist, über die i Informationen darstellt.

Angenommen, man möchte die physische Adresse eines Eintrags in der Adressübersetzungstabelle (ARP-Cache) finden, der mit einer IP-Adresse von 89.1.1.42 und Schnittstelle 3 verknüpft ist. Dementsprechend würde atPhysAddress.3.1.89.1.1.42 die gewünschte Instanz identifizieren.

3.2.6.3.3. Namen der ipAddrTable-Objekttypen​

Der Name eines IP-adressierbaren Netzwerkelements, x, ist der OBJECT IDENTIFIER der Form a.b.c.d, sodass a.b.c.d der Wert (in der bekannten „Punkt“-Notation) dieser Instanz des ipAdEntAddr-Objekttyps ist, der x zugeordnet ist.

Für jeden Objekttyp t, für den der definierte Name n das Präfix ipAddrEntry hat, wird eine Instanz i von t durch ein OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name des IP-adressierbaren Netzwerkelements ist, über das i Informationen darstellt.

Angenommen, man möchte die Netzwerkmaske eines Eintrags in der IP-Schnittstellentabelle finden, der mit der IP-Adresse 89.1.1.42 verknüpft ist. Dementsprechend würde ipAdEntNetMask.89.1.1.42 die gewünschte Instanz identifizieren.

3.2.6.3.4. Namen der ipRoutingTable-Objekttypen​

Der Name einer IP-Route, x, ist der OBJECT IDENTIFIER der Form a.b.c.d, sodass a.b.c.d der Wert (in der bekannten „Punkt“-Notation) dieser Instanz des ipRouteDest-Objekttyps ist, der x zugeordnet ist.

Für jeden Objekttyp t, für den der definierte Name n das Präfix ipRoutingEntry hat, wird eine Instanz i von t durch ein OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name der IP-Route ist, über die i Informationen darstellt.

Angenommen, man möchte den nächsten Hop eines Eintrags in der Routing-Tabelle IP finden, der dem Ziel 89.1.1.42 zugeordnet ist. Dementsprechend würde ipRouteNextHop.89.1.1.42 die gewünschte Instanz identifizieren.

3.2.6.3.5. Namen der tcpConnTable-Objekttypen​

Der Name einer TCP-Verbindung, x, ist OBJECT IDENTIFIER der Form a.b.c.d.e.f.g.h.i.j, sodass a.b.c.d der Wert (in der bekannten „Punkt“-Notation) dieser Instanz des tcpConnLocalAddress-Objekttyps ist, der mit x verknüpft ist, und dass f.g.h.i der Wert (in der bekannten „Punkt“-Notation) dieser Instanz ist des Objekttyps tcpConnRemoteAddress, der mit x verknüpft ist, und so, dass e der Wert dieser Instanz des Objekttyps

Für jeden Objekttyp t, für den der definierte Name n das Präfix tcpConnEntry hat, wird eine Instanz i von t durch ein OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name der TCP-Verbindung ist, über die i Informationen darstellt.

Angenommen, man möchte den Status einer TCP-Verbindung zwischen der lokalen Adresse von 89.1.1.42 auf TCP-Port 21 und der Remote-Adresse von

3.2.6.3.6. Namen der egpNeighTable-Objekttypen​

Der Name eines EGP-Nachbarn, x, ist der OBJECT IDENTIFIER der Form a.b.c.d, sodass a.b.c.d der Wert (in der bekannten „Punkt“-Notation) dieser Instanz des egpNeighAddr-Objekttyps ist, der x zugeordnet ist.

Für jeden Objekttyp t, für den der definierte Name n das Präfix egpNeighEntry hat, wird eine Instanz i von t durch ein OBJECT IDENTIFIER der Form n.y benannt, wobei y der Name des EGP-Nachbarn ist, über den i Informationen darstellt.

Angenommen, man möchte den Nachbarstatus für die IP-Adresse von 89.1.1.42 ermitteln. Dementsprechend würde egpNeighState.89.1.1.42 die gewünschte Instanz identifizieren.

4. Protokollspezifikation​

Das Netzwerkverwaltungsprotokoll ist ein Anwendungsprotokoll, mit dem die Variablen des MIB eines Agenten überprüft oder geändert werden können.

Die Kommunikation zwischen Protokolleinheiten erfolgt durch den Austausch von Nachrichten, die jeweils vollständig und unabhängig in einem einzelnen UDP-Datagramm unter Verwendung der grundlegenden Codierungsregeln von ASN.1 (wie in Abschnitt 3.2.2 erläutert) dargestellt werden. Eine Nachricht besteht aus einer Versionskennung, einem SNMP-Community-Namen und einer Protokolldateneinheit (PDU). Eine Protokolleinheit empfängt Nachrichten am UDP-Port 161 auf dem Host, mit dem sie verknüpft ist, für alle Nachrichten mit Ausnahme derjenigen, die Traps melden (d. h. alle Nachrichten mit Ausnahme derjenigen, die Trap-PDU enthalten). Nachrichten, die Traps melden, sollten zur weiteren Verarbeitung am UDP-Port 162 empfangen werden. Eine Implementierung dieses Protokolls muss keine Nachrichten akzeptieren, deren Länge 484 Oktette überschreitet. Es wird jedoch empfohlen, dass Implementierungen nach Möglichkeit größere Datagramme unterstützen.

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. Verfahrenselemente​

In diesem Abschnitt werden die Aktionen einer Protokollentität beschrieben, die den SNMP implementiert. Beachten Sie jedoch, dass es nicht dazu gedacht ist, die interne Architektur einer konformen Implementierung einzuschränken.

Im folgenden Text wird der Begriff Transportadresse verwendet. Im Fall des UDP besteht eine Transportadresse aus einer IP-Adresse und einem UDP-Port. Zur Unterstützung des SNMP können andere Transportdienste genutzt werden. In diesen Fällen sollte die Definition einer Transportadresse entsprechend erfolgen.

Die Aktionen der obersten Ebene einer Protokollentität, die eine Nachricht generiert, sind wie folgt:

  1. Zunächst wird die entsprechende PDU, z. B. GetRequest-PDU, als ASN.1-Objekt erstellt.

  2. Anschließend übergibt es dieses ASN.1-Objekt zusammen mit einem Community-Namen, seiner Quelltransportadresse und der Zieltransportadresse an den Dienst, der das gewünschte Authentifizierungsschema implementiert. Dieser Authentifizierungsdienst gibt ein weiteres ASN.1-Objekt zurück.

  3. Die Protokollentität erstellt dann ein ASN.1-Nachrichtenobjekt unter Verwendung des Community-Namens und des resultierenden ASN.1-Objekts.

  4. Dieses neue ASN.1-Objekt wird dann unter Verwendung der grundlegenden Codierungsregeln von ASN.1 serialisiert und dann mithilfe eines Transportdienstes an die Peer-Protokollentität gesendet.

In ähnlicher Weise lauten die Aktionen der obersten Ebene einer Protokollentität, die eine Nachricht empfängt, wie folgt:

  1. Es führt eine rudimentäre Analyse des eingehenden Datagramms durch, um ein ASN.1-Objekt zu erstellen, das einem ASN.1-Nachrichtenobjekt entspricht. Wenn die Analyse fehlschlägt, wird das Datagramm verworfen und es werden keine weiteren Aktionen ausgeführt.

  2. Anschließend wird die Versionsnummer der SNMP-Nachricht überprüft. Bei einer Nichtübereinstimmung wird das Datagramm verworfen und es werden keine weiteren Aktionen ausgeführt.

  3. Die Protokollentität übergibt dann den Community-Namen und die Benutzerdaten, die im ASN.1-Nachrichtenobjekt gefunden werden, zusammen mit den Quell- und Zieltransportadressen 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 notiert die Protokolleinheit diesen Fehler, generiert (möglicherweise) eine Falle, verwirft das Datagramm und führt keine weiteren Aktionen aus.

  4. 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 erstellen, das einem ASN.1-PDUs-Objekt entspricht. Wenn die Analyse fehlschlägt, wird das Datagramm verworfen und es werden keine weiteren Aktionen ausgeführt. Andernfalls wird unter Verwendung der genannten SNMP-Community das entsprechende Profil ausgewählt und die PDU entsprechend verarbeitet. Wenn als Ergebnis dieser Verarbeitung eine Nachricht zurückgegeben wird, muss die Quelltransportadresse, von der die Antwortnachricht gesendet wird, mit der Zieltransportadresse identisch sein, an die die ursprüngliche Anforderungsnachricht gesendet wurde.

4.1.1. Gemeinsame Strukturen​

Bevor die sechs PDU-Typen des Protokolls vorgestellt 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 zur Unterscheidung ausstehender Anfragen verwendet. Mithilfe der RequestID kann eine SNMP-Anwendungsentität eingehende Antworten mit ausstehenden Anforderungen korrelieren. In Fällen, in denen ein unzuverlässiger Datagrammdienst verwendet wird, bietet die RequestID auch eine einfache Möglichkeit, vom Netzwerk duplizierte Nachrichten zu identifizieren.

Eine Instanz von ErrorStatus ungleich Null wird verwendet, um anzuzeigen, dass während der Verarbeitung einer Anforderung eine Ausnahme aufgetreten ist. In diesen Fällen kann ErrorIndex zusätzliche Informationen bereitstellen, indem er angibt, welche Variable in einer Liste die Ausnahme verursacht hat.

Der Begriff Variable bezieht sich auf eine Instanz eines verwalteten Objekts. Eine Variablenbindung oder VarBind bezieht sich auf die Paarung des Namens einer Variablen mit dem Wert der Variablen. Eine VarBindList ist eine einfache Liste von Variablennamen und entsprechenden Werten. Einige PDUs befassen sich nur mit dem Namen einer Variablen und nicht mit ihrem Wert (z. B. 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. GetRequest-PDU​

Die Form des GetRequest-PDU ist:

                  GetRequest-PDU ::=
                      [0]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,

                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

Der GetRequest-PDU wird von einer Protokollentität nur auf Anfrage ihrer SNMP-Anwendungsentität generiert.

Nach Erhalt des GetRequest-PDU antwortet die empfangende Protokolleinheit gemäß einer anwendbaren Regel in der folgenden Liste:

  1. Wenn der Name eines im Feld variable-bindings genannten Objekts nicht genau mit dem Namen eines Objekts übereinstimmt, das in der betreffenden MIB-Ansicht für get-Operationen verfügbar ist, sendet die empfangende Entität dem Absender der empfangenen Nachricht eine GetResponse-PDU gleicher Form. Dabei hat das Feld error-status den Wert noSuchName, und das Feld error-index enthält den Index der betreffenden Objektnamenkomponente in der empfangenen Nachricht.

  2. Wenn ein im Feld variable-bindings genanntes Objekt ein Aggregattyp (wie in der SMI definiert) ist, sendet die empfangende Entität dem Absender der empfangenen Nachricht eine GetResponse-PDU gleicher Form. Dabei hat das Feld error-status den Wert noSuchName, und das Feld error-index enthält den Index der betreffenden Objektnamenkomponente in der empfangenen Nachricht.

  3. Wenn die Größe des wie unten beschrieben generierten GetResponse-PDU eine lokale Beschränkung überschreiten würde, sendet die empfangende Entität an den Absender der empfangenen Nachricht den GetResponse-PDU identischer Form, mit der Ausnahme, dass der Wert des Felds error-status tooBig ist und der Wert des Felds error-index Null ist.

  4. Wenn der Wert eines im Feld variable-bindings genannten Objekts aus Gründen, die von keiner der vorstehenden Regeln erfasst werden, nicht abgerufen werden kann, sendet die empfangende Entität dem Absender der empfangenen Nachricht eine GetResponse-PDU gleicher Form. Dabei hat das Feld error-status den Wert genErr, und das Feld error-index enthält den Index der betreffenden Objektnamenkomponente in der empfangenen Nachricht.

Wenn keine der vorstehenden Regeln zutrifft, sendet die empfangende Protokollentität dem Absender der empfangenen Nachricht eine GetResponse-PDU, deren entsprechende Komponente für jedes im Feld variable-bindings der empfangenen Nachricht genannte Objekt den Namen und den Wert dieser Variablen enthält. Das Feld error-status der GetResponse-PDU hat den Wert noError, das Feld error-index den Wert Null. Das Feld request-id der GetResponse-PDU hat denselben Wert wie in der empfangenen Nachricht.

4.1.3. GetNextRequest-PDU​

Die Form des GetNextRequest-PDU ist bis auf die Angabe des PDU-Typs identisch mit der des GetRequest-PDU. In der Sprache ASN.1:

                  GetNextRequest-PDU ::=
                      [1]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,
                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

Der GetNextRequest-PDU wird von einer Protokollentität nur auf Anfrage ihrer SNMP-Anwendungsentität generiert.

Nach Erhalt des GetNextRequest-PDU antwortet die empfangende Protokolleinheit gemäß einer anwendbaren Regel in der folgenden Liste:

  1. Wenn ein Objektname im Feld variable-bindings lexikografisch nicht vor dem Namen eines Objekts liegt, das in der betreffenden MIB-Ansicht für get-Operationen verfügbar ist, sendet die empfangende Entität dem Absender der empfangenen Nachricht eine GetResponse-PDU gleicher Form. Dabei hat das Feld error-status den Wert noSuchName, und das Feld error-index enthält den Index der betreffenden Objektnamenkomponente in der empfangenen Nachricht.

  2. Wenn die Größe des wie unten beschrieben generierten GetResponse-PDU eine lokale Beschränkung überschreiten würde, sendet die empfangende Entität an den Absender der empfangenen Nachricht den GetResponse-PDU identischer Form, mit der Ausnahme, dass der Wert des Felds error-status tooBig ist und der Wert des Felds error-index Null ist.

  3. Wenn der Wert des lexikografischen Nachfolgers eines im Feld variable-bindings genannten Objekts aus Gründen, die von keiner der vorstehenden Regeln erfasst werden, nicht abgerufen werden kann, sendet die empfangende Entität dem Absender der empfangenen Nachricht eine GetResponse-PDU gleicher Form. Dabei hat das Feld error-status den Wert genErr, und das Feld error-index enthält den Index der betreffenden Objektnamenkomponente in der empfangenen Nachricht.

Wenn keine der vorstehenden Regeln zutrifft, sendet die empfangende Protokollentität dem Absender der empfangenen Nachricht eine GetResponse-PDU. Für jeden Namen im Feld variable-bindings der empfangenen Nachricht enthält die entsprechende Komponente der GetResponse-PDU den Namen und den Wert desjenigen Objekts, dessen Name in der lexikografischen Ordnung aller für get-Operationen in der betreffenden MIB-Ansicht verfügbaren Objekte unmittelbar auf den Wert des name-Felds der gegebenen Komponente folgt. Das Feld error-status der GetResponse-PDU hat den Wert noError, das Feld errorindex den Wert Null. Das Feld request-id der GetResponse-PDU hat denselben Wert wie in der empfangenen Nachricht.

4.1.3.1. Beispiel einer Tabellendurchquerung​

Eine wichtige Verwendung des GetNextRequest-PDU ist das Durchlaufen konzeptioneller Informationstabellen innerhalb des MIB. Die Semantik dieser Art von SNMP-Nachricht ermöglicht zusammen mit den protokollspezifischen Mechanismen zur Identifizierung einzelner Instanzen von Objekttypen im MIB den Zugriff auf verwandte Objekte im MIB, als ob diese tabellarisch organisiert wären.

Durch den unten skizzierten SNMP-Austausch könnte eine SNMP-Anwendungseinheit die Zieladresse und das Next-Hop-Gateway für jeden Eintrag in der Routing-Tabelle eines bestimmten Netzwerkelements extrahieren. Angenommen, diese Routing-Tabelle enthält 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 Managementstation sendet an den SNMP-Agenten ein GetNextRequest-PDU, das die angegebenen OBJECT IDENTIFIER-Werte als angeforderte Variablennamen enthält:

   GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )

Der SNMP-Agent antwortet mit einem 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 Managementstation 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 Managementstation 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 Managementstation 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 die Objekte zurück, die in der lexikografischen Reihenfolge der bekannten Objektnamen an nächster Stelle stehen. Diese Antwort signalisiert der Managementstation das Ende der Routing-Tabelle.

4.1.4. GetResponse-PDU​

Die Form des GetResponse-PDU ist bis auf die Angabe des PDU-Typs identisch mit der des GetRequest-PDU. In der Sprache ASN.1:

                  GetResponse-PDU ::=
                      [2]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,
                              error-status
                                  ErrorStatus,

                              error-index
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

Der GetResponse-PDU wird von einer Protokolleinheit nur beim Empfang des GetRequest-PDU, GetNextRequest-PDU oder SetRequest-PDU generiert, wie an anderer Stelle in diesem Dokument beschrieben.

Nach Erhalt des GetResponse-PDU präsentiert die empfangende Protokolleinheit ihren Inhalt ihrer SNMP-Anwendungseinheit.

4.1.5. SetRequest-PDU​

Die Form des SetRequest-PDU ist bis auf die Angabe des PDU-Typs identisch mit der des GetRequest-PDU. In der Sprache ASN.1:

                  SetRequest-PDU ::=
                      [3]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,

                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

Der SetRequest-PDU wird von einer Protokollentität nur auf Anfrage ihrer SNMP-Anwendungsentität generiert.

Nach Erhalt des SetRequest-PDU antwortet die empfangende Entität gemäß den geltenden Regeln in der folgenden Liste:

  1. Wenn ein im Feld variable-bindings genanntes Objekt in der betreffenden MIB-Ansicht nicht für set-Operationen verfügbar ist, sendet die empfangende Entität dem Absender der empfangenen Nachricht eine GetResponse-PDU gleicher Form. Dabei hat das Feld error-status den Wert noSuchName, und das Feld error-index enthält den Index der betreffenden Objektnamenkomponente in der empfangenen Nachricht.

  2. Wenn bei einem im Feld variable-bindings genannten Objekt der Inhalt des value-Felds gemäß ASN.1 nicht den für die Variable erforderlichen Typ, die erforderliche Länge und den erforderlichen Wert aufweist, sendet die empfangende Entität dem Absender der empfangenen Nachricht eine GetResponse-PDU gleicher Form. Dabei hat das Feld error-status den Wert badValue, und das Feld error-index enthält den Index des betreffenden Objektnamens in der empfangenen Nachricht.

  3. Wenn die Größe der wie unten beschrieben generierten Nachricht vom Typ „Get Response“ eine lokale Beschränkung überschreiten würde, sendet die empfangende Entität an den Absender der empfangenen Nachricht den GetResponse-PDU identischer Form, mit der Ausnahme, dass der Wert des Felds error-status tooBig ist und der Wert des Felds error-index Null ist.

  4. Wenn der Wert eines im Feld variable-bindings genannten Objekts aus Gründen, die von keiner der vorstehenden Regeln erfasst werden, nicht geändert werden kann, sendet die empfangende Entität dem Absender der empfangenen Nachricht eine GetResponse-PDU gleicher Form. Dabei hat das Feld error-status den Wert genErr, und das Feld error-index enthält den Index der betreffenden Objektnamenkomponente in der empfangenen Nachricht.

Wenn keine der oben genannten Regeln zutrifft, wird für jedes im Feld variable-bindings der empfangenen Nachricht genannte Objekt der Variable der entsprechende Wert zugewiesen. Jede durch SetRequest-PDU angegebene Variablenzuweisung sollte so erfolgen, als ob sie gleichzeitig in Bezug auf alle anderen in derselben Nachricht angegebenen Zuweisungen festgelegt wäre.

Die empfangende Entität sendet dann an den Absender der empfangenen Nachricht den GetResponse-PDU identischer Form, mit der Ausnahme, dass der Wert des Felds error-status der generierten Nachricht noError ist und der Wert des Felds error-index Null ist.

4.1.6. Trap-PDU​

Die Form des 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
             }

Der Trap-PDU wird von einer Protokollentität nur auf Anfrage der SNMP-Anwendungsentität generiert. Die Art und Weise, wie eine SNMP-Anwendungsentität die Zieladressen der SNMP-Anwendungsentitäten auswählt, ist implementierungsspezifisch.

Nach Erhalt des Trap-PDU präsentiert die empfangende Protokolleinheit ihren Inhalt ihrer SNMP-Anwendungseinheit. Die Bedeutung der variable-bindings-Komponente des Trap-PDU ist implementierungsspezifisch.

Interpretationen des Werts des Felds generic-trap sind:

4.1.6.1. coldStart-Trap​

Ein coldStart(0)-Trap bedeutet, dass sich die sendende Protokolleinheit selbst neu initialisiert, sodass die Konfiguration des Agenten oder die Implementierung der Protokolleinheit geändert werden kann.

4.1.6.2. warmStart-Trap​

Ein warmStart(1)-Trap bedeutet, dass sich die sendende Protokolleinheit selbst neu initialisiert, sodass weder die Agentenkonfiguration noch die Implementierung der Protokolleinheit geändert werden.

4.1.6.3. linkDown-Trap​

Ein linkDown(2)-Trap bedeutet, dass die sendende Protokolleinheit einen Fehler in einer der in der Agentenkonfiguration dargestellten Kommunikationsverbindungen erkennt.

Der Trap-PDU vom Typ linkDown enthält als erstes Element seines variable-bindings den Namen und Wert der ifIndex-Instanz für die betroffene Schnittstelle.

4.1.6.4. linkUp-Trap​

Ein linkUp(3)-Trap bedeutet, dass die sendende Protokolleinheit erkennt, dass eine der in der Agentenkonfiguration dargestellten Kommunikationsverbindungen aufgebaut wurde.

Der Trap-PDU vom Typ linkUp enthält als erstes Element seines variable-bindings den Namen und Wert der ifIndex-Instanz für die betroffene Schnittstelle.

4.1.6.5. authenticationFailure-Trap​

Ein authenticationFailure(4)-Trap bedeutet, dass die sendende Protokolleinheit der Adressat einer Protokollnachricht ist, die nicht ordnungsgemäß authentifiziert ist. Während Implementierungen des SNMP in der Lage sein müssen, diese Falle zu erzeugen, müssen sie auch in der Lage sein, die Emission solcher Fallen über einen umsetzungsspezifischen Mechanismus zu unterdrücken.

4.1.6.6. egpNeighborLoss-Trap​

Eine egpNeighborLoss(5)-Trap bedeutet, dass ein EGP-Nachbar, für den die sendende Protokollentität ein EGP-Peer war, herabgestuft wurde und die Peer-Beziehung nicht mehr besteht.

Der Trap-PDU vom Typ egpNeighborLoss enthält als erstes Element seines variable-bindings den Namen und Wert der egpNeighAddr-Instanz für den betroffenen Nachbarn.

4.1.6.7. enterpriseSpecific-Trap​

Ein enterpriseSpecific(6)-Trap bedeutet, dass die sendende Protokolleinheit erkennt, dass ein unternehmensspezifisches Ereignis aufgetreten ist. Das Feld specific-trap identifiziert den jeweiligen aufgetretenen Trap.

5. Definitionen​

     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
                          }
          -- PDUs

          GetRequest-PDU ::=
              [0]
                  IMPLICIT PDU

          GetNextRequest-PDU ::=
              [1]
                  IMPLICIT PDU

          GetResponse-PDU ::=
              [2]
                  IMPLICIT PDU

          SetRequest-PDU ::=
              [3]
                  IMPLICIT PDU

          PDU ::=
                  SEQUENCE {
                     request-id
                          INTEGER,

                      error-status      -- sometimes ignored
                          INTEGER {
                              noError(0),
                              tooBig(1),
                              noSuchName(2),
                              badValue(3),
                              readOnly(4),
                              genErr(5)
                          },

                      error-index       -- sometimes ignored
                         INTEGER,

                      variable-bindings -- values are sometimes ignored
                          VarBindList
                  }

          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
                  }

          -- variable bindings

          VarBind ::=
                  SEQUENCE {
                      name
                          ObjectName,

                      value
                          ObjectSyntax
                  }

         VarBindList ::=
                  SEQUENCE OF
                     VarBind

         END

6. Danksagungen​

Dieses Memo wurde von der IETF-Arbeitsgruppe SNMP-Erweiterungen beeinflusst:

      Karl Auerbach, Epilogue Technology
      K. Ramesh Babu, Excelan
      Amatzia Ben-Artzi, 3Com/Bridge
      Lawrence Besaw, Hewlett-Packard
      Jeffrey D. Case, University of Tennessee at Knoxville
      Anthony Chung, Sytek
      James Davidson, The Wollongong Group
      James R. Davin, MIT Laboratory for Computer Science
      Mark S. Fedor, NYSERNet
      Phill Gross, The MITRE Corporation
      Satish Joshi, ACC
      Dan Lynch, Advanced Computing Environments
      Keith McCloghrie, The Wollongong Group
      Marshall T. Rose, The Wollongong Group (chair)
      Greg Satz, cisco
      Martin Lee Schoffstall, Rensselaer Polytechnic Institute
      Wengyik Yeong, NYSERNet

7. Referenzen​

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.

[3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.

[6] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.

[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.

[9] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[10] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

[11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, November 1980.

8. Sicherheitsüberlegungen​

Sicherheitsfragen werden in diesem Memo nicht behandelt.

9. Adressen der Autoren​

Jeffrey D. Case SNMP Research P.O. Box 8593 Knoxville, TN 37996-4800

Telefon: (615) 573-1434

Email: [email protected]

Mark Fedor Performance Systems International Rensselaer Technology Park 125 Jordan Road Troy, NY 12180

Telefon: (518) 283-8860

Email: [email protected]

Martin Lee Schoffstall Performance Systems International Rensselaer Technology Park 165 Jordan Road Troy, NY 12180

Telefon: (518) 283-8860

Email: [email protected] James R. Davin MIT Laboratory for Computer Science, NE43-507 545 Technology Square Cambridge, MA 02139

Telefon: (617) 253-6020

Email: [email protected]

Letztes Update am