46 Simple Network Management Protocol (SNMP)

Transkript

1 KAPITEL 46 Simple Network Management Protocol (SNMP) 46 Simple Network Management Protocol (SNMP) 46.1 Hintergrund Beim Simple Network Management Protocol (SNMP) handelt es sich um ein Protokoll für die Anwendungsschicht, das den Austausch von Verwaltungsinformationen zwischen Netzwerk-Geräten erleichtert. Es ist ein Bestandteil der Protokollsammlung Transmission Control Protocol/Internet Protocol (TCP/IP). SNMP gestattet es Netzwerk-Administratoren, die Netzwerk-Performance zu verwalten, Netzwerk-Probleme aufzuspüren und zu lösen und das Wachstum des Netzwerks zu planen. Es gibt zwei Versionen von SNMP: SNMP Version 1 (SNMPv1) und SNMP Version 2 (SNMPv2). Beide Versionen verfügen über einige gemeinsame Eigenschaften, SNMPv2 bietet allerdings auch einige Erweiterungen wie beispielsweise zusätzliche Protokolloperationen. Die Standardisierung einer weiteren Version von SNMP SNMP Version 3 (SNMPv3) ist anhängig. Dieses Kapitel beschreibt die Protokolloperationen von SNMPv1 und SNMPv2. Im Bild 46.1 ist ein einfaches mit SNMP verwaltetes Netzwerk dargestellt.

2 570 Handbuch Netzwerk-Technologien Bild 46.1: SNMP ermöglicht den Austausch von Netzwerk- Informationen zwischen Geräten 46.2 SNMP Grundlegende Komponenten Ein mit SNMP verwaltetes Netzwerk setzt sich aus drei wesentlichen Komponenten zusammen: verwaltete Geräte, Agenten und Netzwerk-Verwaltungssysteme (Network Management Systems = NMSs). Bei einem verwalteten Gerät handelt es sich um einen Netzwerk-Knoten, der über einen SNMP-Agenten verfügt und der sich in einem verwalteten Netzwerk befindet. Verwaltete Geräte sammeln und speichern Verwaltungsinformationen und stellen diese Informationen mittels SNMP den NMSs zur Verfügung. Bei verwalteten Geräten, die manchmal auch als Netzwerk-Elemente bezeichnet werden, kann es sich um Router und Zugriffsserver, Switches und Bridges, Hubs, Hostcomputer oder Drucker handeln. Bei einem Agenten handelt es sich um ein netzwerkverwaltendes Software-Modul, das sich auf einem verwalteten Gerät befindet. Ein Agent verfügt über lokales Wissen von Verwaltungsinformationen und übersetzt diese Informationen in eine Form, die zu SNMP kompatibel ist. Ein NMS führt Anwendungen aus, die verwaltete Geräte überwachen und steuern. NMSs stellen den Großteil der für die Netzwerk-Verwaltung erforderlichen Bearbeitungs- und Speicherressourcen bereit. In jedem verwalteten Netzwerk müssen ein oder mehrere NMSs vorhanden sein. Im Bild 46.2 sind die Beziehungen zwischen diesen drei Komponenten dargestellt.

3 Kapitel 46 Simple Network Management Protocol (SNMP) 571 NMS Bild 46.2: Ein per SNMP verwaltetes Netzwerk setzt sich aus verwalteten Geräten, Agenten und NMSs zusammen Agent Agent Agent Verwaltungseinheit Verwaltungsdatenbank Verwaltungsdatenbank Verwaltungsdatenbank verwaltete Geräte 46.3 SNMP Grundlegende Befehle Verwaltete Geräte werden mittels folgender vier grundlegenden Befehle von SNMP überwacht und gesteuert: Read, Write, Trap und Traversal-Operationen. Der Befehl Read wird von einem NMS verwendet, um verwaltete Geräte zu überwachen. Das NMS untersucht verschiedene Variablen, die von verwalteten Geräten vorgehalten werden. Der Befehl Write wird von einem NMS verwendet, um verwaltete Geräte zu steuern. Das NMS ändert die Werte von in verwalteten Geräten gespeicherten Variablen. Der Befehl Trap wird von verwalteten Geräten verwendet, um dem NMS asynchron Ereignisse mitzuteilen. Beim Auftreten bestimmter Arten von Ereignissen schickt ein verwaltetes Gerät einen Trap an das NMS. Traversal-Operationen werden vom NMS verwendet, um zu ermitteln, welche Variablen ein verwaltetes Gerät unterstützt und um der Reihe nach Informationen in Variablentabellen wie beispielsweise einer Routing-Tabelle zu sammeln.

4 572 Handbuch Netzwerk-Technologien 46.4 SNMP Management Information Base (MIB) Eine Management Information Base (MIB) ist eine Sammlung von hierarchisch organisierten Informationen. Auf MIBs wird mittels eines Protokolls zur Netzwerk-Verwaltung wie beispielsweise SNMP zugegriffen. Sie setzen sich aus verwalteten Objekten zusammen und werden durch Objekt-IDs identifiziert. Ein verwaltetes Objekt (manchmal auch als MIB-Objekt, Objekt oder MIB bezeichnet) stellt eine von einer beliebigen Anzahl von Eigenschaften eines verwalteten Geräts dar. Verwaltete Objekte bestehen aus einer oder mehreren Objektinstanzen, bei denen es sich im wesentlichen um Variablen handelt. Es gibt zwei Arten verwalteter Objekte: skalare und tabellarische. Skalare Objekte definieren eine einzige Objektinstanz. Tabellarische Objekte definieren mehrere zusammengehörige Objektinstanzen, die in MIB-Tabellen zusammen gruppiert sind. Ein Beispiel für ein verwaltetes Objekt ist atinput, bei dem es sich um ein skalares Objekt handelt, das als einzige Objektinstanz den ganzzahligen Wert enthält, der die Gesamtzahl der an einer Router-Schnittstelle eingegebenen AppleTalk-Pakete angibt. Eine Objekt-ID weist ein verwaltetes Objekt in der MIB-Hierarchie eindeutig aus. Die MIB-Hierarchie kann als ein Baum mit namenloser Wurzel betrachtet werden, dessen Ebenen von unterschiedlichen Organisationen zugewiesen werden. Im Bild 46.3 ist der MIB-Baum dargestellt. Die Objekt-IDs der obersten MIB-Ebene gehören zu unterschiedlichen Standardisierungsorganisationen, wohingegen die Objekt-IDs der untergeordneten Ebenen von angeschlossenen Organisationen belegt werden. Anbieter können eigene Zweige definieren, die verwaltete Objekte für ihre eigenen Produkte enthalten. MIBs, die nicht standardisiert wurden, befinden sich üblicherweise im Zweig experimental.

5 Kapitel 46 Simple Network Management Protocol (SNMP) 573 standard (0) ccitt (0) registrationauthority (1) iso (1) iso-ccitt (2) memberbody (2) internet (1) dod (6) identifiedorganization (3) Bild 46.3: Der MIB- Baum stellt die verschiedenen Hierarchien dar, die von unterschiedlichen Organisationen zugewiesen wurden directory (1) mgmt (2) experimental (3) private (4) security (5) snmpv2 (6) mib-2 (1) enterprise (1) cisco (9) temporary variables (3) DECnet (1) XNS (2) Apple Talk (3) atinput (1) atlocal (2) atbcastin (3) atforward (4) Novell (3) VINES (4) Chassis (5) Das verwaltete Objekt atinput kann entweder durch die Objektbezeichnung iso.identified-organization.dod.internet. private. enterprise.cisco.temporary variables.appletalk.atinput oder durch den entsprechenden Objektdeskriptor eindeutig identifiziert werden SNMP und Datendarstellung SNMP muß Inkompatibilitäten zwischen verwalteten Geräten erklären und diese ausgleichen. Verschiedene Computer verwenden verschiedene Techniken zur Datendarstellung, wodurch es zu Zugeständnissen für die Fähigkeit von SNMP zum Informationsaustausch zwischen verwalteten Geräten kommen kann. SNMP setzt eine Teilmenge der Abstract Syntax Notation One (ASN.1) ein, um sich auf die Kommunikation zwischen unterschiedlichen Systemen einzustellen.

6 574 Handbuch Netzwerk-Technologien 46.6 SNMP Version 1 (SNMPv1) SNMP Version 1 (SNMPv1) ist die erste Implementierung des Protokolls SNMP. Es ist im Request For Comments (RFC) 1157 beschrieben und funktioniert innerhalb der Spezifikationen für die Structure of Management Information (SMI). SNMPv1 arbeitet mit Protokollen wie beispielsweise dem User Datagram Protocol (UDP), Internet Protocol (IP), OSI Conectionless Network Service (CLNS), AppleTalk Datagram Delivery Protocol (DDP) und Novell Internet Paket Exchange (IPX). SNMPv1 wird häufig eingesetzt und stellt das Standardprotokoll für die Netzwerk-Verwaltung im Internet dar SNMPv1 und Structure of Management Information (SMI) Die Structure of Management Information (SMI) definiert die Regeln für das Beschreiben von Verwaltungsinformationen mittels der Abstract Syntax Notation One (ASN.1). Die SMI von SNMPv1 ist in dem RFC 1155 definiert. Sie sorgt für drei Schlüsselspezifikationen: ASN.1-Datentypen, SMI-spezifische Datentypen und MIB-Tabellen von SNMP. SNMPv1 und ASN.1-Datentypen Die SMI von SNMPv1 gibt an, daß mit allen verwalteten Objekten eine bestimmte Teilmenge von ASN.1-Datentypen verbunden ist. Drei ASN.1-Datentypen werden benötigt: Name, Syntax und Encoding. Der Name dient als Objekt-ID. Die Syntax definiert den Datentyp des Objekts (beispielsweise Ganzzahl oder Zeichenkette). Die SMI setzt eine Teilmenge für ASN.1-Syntaxdefinitionen ein. Die Encoding-Daten beschreiben, auf welche Weise mit einem verwalteten Objekt verbundene Informationen für die Übertragung über das Netzwerk als eine Reihe von Dateneinträgen formatiert werden. SNMPv1 und SMI-spezifische Datentypen Die SMI von SNMPv1 beschreibt den Einsatz einiger SMIspezifischer Datentypen, die in zwei Kategorien eingeteilt werden: einfache Datentypen und anwendungsweite Datentypen.

7 Kapitel 46 Simple Network Management Protocol (SNMP) 575 Es werden drei einfache Datentypen in der SMI von SNMPv1 definiert, die alle eindeutige Werte darstellen: Integers, Octet Strings und Object-IDs. Bei den Integern handelt es sich um vorzeichenbehaftete Ganzzahlen im Bereich von bis Bei den Octet Strings handelt es sich um sortierte Abfolgen von null bis Oktetten. Object-IDs stammen aus der Menge sämtlicher entsprechend den ASN.1-Regeln erteilter Objekt-IDs. In der SMI von SNMPv1 gibt es sieben anwendungsweite Datentypen: Network Addresses, Counter, Gauges, Time Ticks, Opaques, Integers und Unsigned Integers. Netzwerk-Adressen stehen für eine Adresse einer bestimmten Protokollfamilie. SNMPv1 unterstützt nur 32-Bit-IP-Adressen. Counter sind positive Ganzzahlen, die erhöht werden, bis sie einen Maximalwert erreichen und dann wieder bei Null beginnen. In SNMPv1 sind 32 Bit für die Zählergröße vorgesehen. Gauges sind positive Ganzzahlen, die erhöht oder verringert werden können, aber den erreichten Maximalwert beibehalten. Ein Time Tick steht für die Hundertstelsekunden nach irgendeinem Ereignis. Ein Opaque steht für eine beliebige Kodierung, die für die Übergabe beliebiger Informationszeichenketten verwendet wird, die nicht der von der SMI benutzten genauen Datentypisierung entsprechen. Ein Integer stellt Informationen mit vorzeichenbehafteten ganzzahligen Werten dar. Dieser Datentyp definiert den Datentyp Integer neu, der unter ASN.1 über eine beliebige, unter SMI aber über eine begrenzte Genauigkeit verfügt. Ein Unsigned Integer stellt Informationen mit vorzeichenlosen ganzzahligen Werten dar und ist nützlich, wenn Werte immer positiv ausfallen. Dieser Datentyp definiert den Datentyp Integer neu, der unter ASN.1 über eine beliebige, unter SMI aber über eine begrenzte Genauigkeit verfügt. SNMP MIB-Tabellen Die SMI von SNMPv1 definiert hochgradig strukturierte Tabellen, die für die Gruppierung der Instanzen eines tabellarischen Objekts (also ein mehrere Variablen enthaltendes Objekt) eingesetzt werden. Tabellen setzen sich aus keiner oder mehreren Zeilen zusammen, die in einer Weise indiziert sind, die es SNMP gestattet, eine ganze Zeile mit einem einzigen Get-, GetNext- oder Set-Befehl zu ermitteln oder zu ändern.

8 576 Handbuch Netzwerk-Technologien SNMPv1 Protokolloperationen Bei SNMP handelt es sich um ein einfaches Request-Response- Protokoll. Das Netzwerk-Managementsystem (NMS) löst ein Request aus, und verwaltete Geräte liefern Responses zurück. Solches Verhalten wird durch den Einsatz einer der folgenden vier Protokolloperationen realisiert: Get, GetNext, Set und Trap. Die Get-Operation wird vom NMS verwendet, um den Wert eines oder mehrerer Objektinstanzen von einem Agenten zu erhalten. Kann der auf die Get-Operation reagierende Agent nicht für alle Objektinstanzen einer Auflistung Werte liefern, so stellt er gar keine Werte zur Verfügung. Die Get- Next-Operation wird vom NMS verwendet, um den Wert von der nächsten Objektinstanz in einer Tabelle oder Auflistung eines Agenten zu erhalten. Die Set-Operation wird vom NMS verwendet, um die Werte von Objektinstanzen in einem Agenten zu setzen. Die Trap-Operation wird von Agenten verwendet, um dem NMS asynchron wichtige Ereignisse mitzuteilen SNMP Version 2 (SNMPv2) SNMP Version 2 (SNMPv2) ist eine Weiterentwicklung der ersten Version, SNMPv1. Ursprünglich wurde SNMPv2 im Jahre 1993 als eine Reihe von Vorschlägen für Internet-Standards veröffentlicht; derzeit handelt es sich dabei um einen Standard in der Entwurfsphase. Wie bereits SNMPv1, funktioniert SNMPv2 innerhalb der Spezifikationen für die Structure of Management Information (SMI). Theoretisch bringt SNMPv2 einige Verbesserungen gegenüber SNMPv1 mit sich, zu denen beispielsweise zusätzliche Protokolloperationen gehören SNMPv2 und Structure of Management Information (SMI) Die Structure of Management Information (SMI) definiert die Regeln für das Beschreiben von Verwaltungsinformationen mittels der Abstract Syntax Notation One (ASN.1). Die SMI von SNMPv2 ist in der RFC 1902 definiert und bringt einige Ergänzungen und Erweiterungen für SMI-spezifische Datentypen mit; unter anderem für Bit Strings, Network

9 Kapitel 46 Simple Network Management Protocol (SNMP) 577 Addresses und Counter. Bit Strings sind nur in SNMPv2 definiert und umfassen keine oder mehrere bezeichnete Bits, die einen Wert angeben. Netzwerk-Adressen stehen für eine Adresse einer bestimmten Protokollfamilie. SNMPv1 unterstützt nur 32-Bit-IP-Adressen, während SNMPv2 auch andere Arten von Adressen unterstützt. Counter sind positive Ganzzahlen, die erhöht werden, bis sie einen Maximalwert erreichen, und dann wieder bei Null beginnen. In SNMPv1 sind 32 Bit für die Zählergröße vorgesehen. In SNMPv2 sind Zähler mit 32 und 64 Bit definiert. SMI-Informationsmodule Weiterhin beschreibt die SMI von SNMPv2 Informationsmodule, die eine Gruppe zusammengehöriger Definitionen angeben. Es gibt drei Arten von SMI-Informationsmodulen: MIB- Module, Compliance-Statements und Capability-Statements. MIB-Module enthalten Definitionen von sich aufeinander beziehenden verwalteten Objekten. Compliance-Statements stellen eine systematische Methode zum Beschreiben einer Gruppe von verwalteten Objekten dar, die implementiert sein müssen, um einen Standard zu erfüllen. Capability-Statements werden eingesetzt, um den genauen Grad an Unterstützung anzuzeigen, den ein Agent hinsichtlich einer MIB-Gruppe fordert. Ein NMS kann sein Verhalten gegenüber Agenten entsprechend der mit jedem Agenten verbundenen Compliance-Statements anpassen. SNMPv2 Protokolloperationen Die in SNMPv1 verwendeten Operationen Get, GetNext und Set stimmen mit den in SNMPv2 verwendeten überein. Allerdings ergänzt und erweitert SNMPv2 einige Protokolloperationen. Beispielsweise erfüllt die SNMPv2-Operation Trap die gleiche Funktion wie in SNMPv1. Sie greift allerdings auf ein anderes Nachrichtenformat zurück und soll das Trap von SNMPv1 ersetzen. SNMPv2 definiert weiterhin zwei neue Protokolloperationen: GetBulk und Inform. Die Operation GetBulk wird vom NMS verwendet, um umfangreiche Datenblöcke wie beispielsweise mehrere Zeilen einer Tabelle rationell zu erhalten. GetBulk füllt eine Response-Nachricht mit so vielen der angeforderten

10 578 Handbuch Netzwerk-Technologien Daten wie möglich. Die Operation Inform gestattet es einem NMS, Trap-Informationen an ein anderes NMS zu senden und eine Antwort zu erhalten. Wenn der auf GetBulk-Operationen reagierende Agent unter SNMPv2 nicht für alle Variablen einer Auflistung Werte liefern kann, stellt er Teilergebnisse zur Verfügung SNMP Verwaltung Bei SNMP handelt es sich um ein Protokoll für die verteilte Verwaltung. Ein System kann entweder ausschließlich als NMS oder Agent fungieren oder aber beide Funktionen übernehmen. Wenn eine System sowohl als NMS als auch als Agent fungiert, kann ein anderes NMS verlangen, daß das System verwaltete Geräte anfordert und eine Zusammenfassung der angeeigneten Informationen zur Verfügung stellt oder daß es lokal gespeicherte Verwaltungsinformationen mitteilt SNMP Sicherheit SNMP mangelt es an jeglicher Fähigkeit zur Authentifizierung, was zu einer Anfälligkeit für eine Vielzahl von Sicherheitsbedrohungen führt. Zu diesen zählen die Täuschung, die Veränderung von Informationen, die Veränderung der Abfolge und des Timings von Nachrichten sowie die Preisgabe von Informationen. Eine Täuschung liegt vor, wenn eine unautorisierte Einheit mit der mutmaßlichen Identität einer autorisierten Verwaltungseinheit Verwaltungsoperationen durchzuführen versucht. Die Veränderung von Informationen bezieht sich auf eine unautorisierte Einheit, die eine von einer autorisierten Einheit generierte Nachricht zu verändern versucht, so daß die Nachricht zu einer nicht autorisierten Verwaltungsoperation für das Accounting oder die Konfiguration führt. Zu einer Veränderung der Abfolge und des Timings von Nachrichten kommt es, wenn eine unautorisierte Einheit eine von einer autorisierten Einheit generierte Nachricht erneut abruft, verzögert oder kopiert und später wiedergibt. Zu einer Preisgabe von Informationen kommt es, wenn eine unautorisierte Einheit in verwalteten Objekten gespeicherte Werte herauszieht oder durch die Überwachung des Datenaustauschs zwischen Managern und Agenten von meldepflichtigen Ereignissen er-

11 Kapitel 46 Simple Network Management Protocol (SNMP) 579 fährt. Da SNMP keine Authentifizierung implementiert, realisieren viele Anbieter die Set-Operation nicht und reduzieren SNMP damit auf ein reines Überwachungsmedium SNMP Zusammenarbeit In der gegenwärtigen Spezifikation ist SNMPv1 in zwei Schlüsselbereichen nicht kompatibel zu SNMPv2: Nachrichtenformate und Protokolloperationen. SNMPv2-Nachrichten verwenden im Vergleich zu SNMPv1 andere Formate für den Header und die Protokolldateneinheiten (Protocol Data Units = PDUs). Außerdem verwendet SNMPv2 zwei Protokolloperationen, die in SNMPv1 nicht beschrieben sind. Darüber hinaus definiert die RFC 1908 zwei mögliche Strategien zur Koexistenz von SNMPv1/v2: Proxy-Agenten und»zweisprachige«netzwerk-verwaltungssysteme Proxy-Agenten Ein SNMPv2-Agent kann folgendermaßen als Proxy-Agent für verwaltete Geräte von SNMPv1 agieren: Ein NMS von SNMPv2 ruft einen für einen SNMPv1- Agenten gedachten Befehl auf. Das NMS schickt die SNMP-Nachricht an den SNMPv2- Proxy-Agenten. Der Proxy-Agent leitet Get-, GetNext- und Set-Nachrichten unverändert an den SNMPv1-Agenten weiter. GetBulk-Nachrichten werden vom Proxy-Agenten in Get- Next-Nachrichten umgewandelt unddannanden SNMPv1- Agenten weitergeleitet. Der Proxy-Agent bildet Trap-Nachrichten unter SNMPv1 auf Trap-Nachrichten unter SNMPv2 ab und leitet diese an das NMS weiter »Zweisprachige«Netzwerk-Verwaltungssysteme»Zweisprachige«Netzwerk-Verwaltungssysteme (NMS) unter SNMPv2 unterstützen sowohl SNMPv1 als auch SNMPv2. Um diese doppelte Verwaltungsumgebung zu unterstützen,

12 580 Handbuch Netzwerk-Technologien muß eine Verwaltungsanwendung im»zweisprachigen«nms eine Verbindung zu einem Agenten aufbauen. Daraufhin untersucht das NMS in einer lokalen Datenbank gespeicherte Informationen, um festzustellen, ob der Agent SNMPv1 oder SNMPv2 unterstützt. Entsprechend der Information in der Datenbank kommuniziert das NMS unter Verwendung der geeigneten Version von SNMP mit dem Agenten SNMP-Referenz: SNMPv1 Nachrichtenformate Nachrichten unter SNMPv1 enthalten zwei Teile: einen Nachrichten-Header und eine Protocol Data Unit (PDU). Im Bild 46.4 ist das grundlegende Format einer Nachricht unter SNMPv1 dargestellt. Bild 46.4: Eine Nachricht unter SNMPv1 setzt sich aus einem Header und einer PDU zusammen Nachrichten- Header PDU SNMPv1 Nachrichten-Header Nachrichten-Header unter SNMPv1 enthalten zwei Felder: Versionsnummer und Gemeinschaftsname. Im folgenden werden diese Felder kurz beschrieben: Versionsnummer Gibt die Version des verwendeten SNMP an. Gemeinschaftsname Definiert eine Zugriffsumgebung für eine Gruppe von NMSs. Von NMSs innerhalb der Gemeinschaft sagt man, daß sie sich in derselben Verwaltungsdomain befinden. Gemeinschaftsnamen dienen als eine dürftige Form der Authentifizierung, da Geräte, die den richtigen Gemeinschaftsnamen nicht kennen, von SNMP-Operationen ausgeschlossen sind SNMPv1 Protokolldateneinheit (PDU) Protokolldateneinheiten (Protocol Data Units = PDUs) unter SNMPv1 enthalten einen bestimmten Befehl (Get, Set usw.)

13 Kapitel 46 Simple Network Management Protocol (SNMP) 581 und Operanden, welche die in der Transaktion einbezogenen Objektinstanzen angeben. Die PDU-Felder sind unter SNMPv1 wie von ASN.1 vorgeschrieben von variabler Länge. Im Bild 46.5 sind die Felder für die Transaktionen Get, GetNext, Response und Set PDUs unter SNMPv1 dargestellt. PDU- Typ Fehlerstatus Request- ID Fehlerindex Objekt 1 Wert 1 Objekt 2 Wert 2 variable Bindungen Objekt x Wert x Im folgenden werden die im Bild 46.5 dargestellten Felder kurz beschrieben: PDU-Typ Gibt den Typ der übertragenen PDU an. Request-ID Verbindet SNMP-Requests mit Responses. Fehlerstatus Gibt einen von mehreren Fehlern und Fehlertypen an. Nur die Response-Operation setzt dieses Feld. Andere Operationen belegen dieses Feld mit dem Wert 0. Fehlerindex Verbindet einen Fehler mit einer bestimmten Objektinstanz. Nur die Response-Operation setzt dieses Feld. Andere Operationen belegen dieses Feld mit dem Wert 0. Variable Bindungen Dient als Datenfeld der PDU unter SNMPv1. Jede Variablenbindung verknüpft eine bestimmte Objektinstanz mit dessen aktuellem Wert (mit Ausnahme von Get- und GetNext-Requests, für die der Wert ignoriert wird). Bild 46.5: Get, GetNext, Response und Set PDUs enthalten unter SNMPv1 dieselben Felder Format von Trap PDU Im Bild 46.6 sind die Felder von Trap PDU unter SNMPv1 dargestellt. Enterprise Agent- Adresse Gererischer Trapcode Spezifischer Trapcode Zeitprotokollierung Objekt 1 Wert 1 Objekt 2 Wert 2 variable Bindungen Objekt x Wert x Bild 46.6: Trap PDU setzt sich unter SNMPv1 aus acht Feldern zusammen

14 582 Handbuch Netzwerk-Technologien Im folgenden werden die im Bild 46.6 dargestellten Felder kurz beschrieben: Enterprise Gibt die Art des verwalteten Objekts an, das den Trap generiert hat. Agent-Adresse Stellt die Adresse des verwalteten Objekts bereit, das den Trap generiert hat. Generischer Traptyp Gibt einen von mehreren generischen Traptypen an. Spezifischer Trapcode Gibt einen von mehreren spezifischen Trapcodes an. Zeitprotokollierung Stellt die seit der letzten Initialisierung des Netzwerks bis zum Erzeugen des Traps verstrichene Zeit bereit. Variable Bindungen Dient als Datenfeld der Trap PDU unter SNMPv1. Jede Variablenbindung verknüpft eine bestimmte Objektinstanz mit dessen aktuellem Wert SNMP-Referenz: SNMPv2 Nachrichtenformate Nachrichten unter SNMPv1 setzen sich aus einem Header und einer PDU zusammen. Im Bild 46.7 ist das grundlegende Format einer Nachricht unter SNMPv2 dargestellt. Bild 46.7: Nachrichten unter SNMPv2 setzen sich ebenfalls aus einem Header und einer PDU zusammen Nachrichten- Header PDU SNMPv2 Nachrichten-Header Nachrichten-Header unter SNMPv2 enthalten zwei Felder: Versionsnummer und Gemeinschaftsname. Im folgenden werden diese Felder kurz beschrieben: Versionsnummer Gibt die Version des verwendeten SNMP an.

15 Kapitel 46 Simple Network Management Protocol (SNMP) 583 Gemeinschaftsname Definiert eine Zugriffsumgebung für eine Gruppe von NMSs. Von NMSs innerhalb der Gemeinschaft sagt man, daß sie sich in derselben Verwaltungsdomain befinden. Gemeinschaftsnamen dienen als eine dürftige Form der Authentifizierung, da Geräte, die den richtigen Gemeinschaftsnamen nicht kennen, von SNMP-Operationen ausgeschlossen sind SNMPv2 Protokolldateneinheit (PDU) SNMPv2 beschreibt zwei PDU-Formate, die von den SNMP- Protokolloperationen abhängen. Die Felder von PDU unter SNMPv2 verfügen wie von der ASN.1 vorgeschrieben über eine variable Länge. Im Bild 46.8 sind die Felder von Get, GetNext, Inform, Response, Set und Trap PDUs unter SNMPv2 dargestellt. PDU- Typ Fehlerstatus Request- ID Fehlerindex Objekt 1 Wert 1 Objekt 2 Wert 2 variable Bindungen Objekt x Wert x Im folgenden werden die im Bild 46.8 dargestellten Felder kurz beschrieben: PDU-Typ Gibt den Typ der übertragenen PDU an (Get, GetNext, Inform, Response, Set oder Trap). Request-ID Verbindet SNMP-Requests mit Responses. Fehlerstatus Gibt einen von mehreren Fehlern und Fehlertypen an. Nur die Response-Operation setzt dieses Feld. Andere Operationen belegen dieses Feld mit dem Wert 0. Fehlerindex Verbindet einen Fehler mit einer bestimmten Objektinstanz. Nur die Response-Operation setzt dieses Feld. Andere Operationen belegen dieses Feld mit dem Wert 0. Variable Bindungen Dient als Datenfeld der PDU unter SNMPv2. Jede Variablenbindung verknüpft eine bestimmte Objektinstanz mit dessen aktuellem Wert (mit Ausnahme von Get- und GetNext-Requests, für die der Wert ignoriert wird). Bild 46.8: Get, GetNext, Inform, Response, Set und Trap PDUs enthalten unter SNMPv2 dieselben Felder

16 584 Handbuch Netzwerk-Technologien Format von GetBulk PDU Im Bild 46.9 sind die Felder von GetBulk PDU unter SNMPv2 dargestellt. Bild 46.9: GetBulk PDU setzt sich unter SNMPv2 aus sieben Feldern zusammen PDU- Typ Request- ID keine Wiederholung Max. Wiederholung Objekt 1 Wert 1 Objekt 2 Wert 2 variable Bindungen Objekt x Wert x Im folgenden werden die im Bild 46.9 dargestellten Felder kurz beschrieben: PDU-Typ Weist die PDU als eine GetBulk-Operation aus. Request-ID Verbindet SNMP-Requests mit Responses. Keine Wiederholung Gibt die Anzahl von Objektinstanzen im Feld Variable Bindungen an, die von Beginn des Request an nur einmal erhalten werden sollen. Dieses Feld wird verwendet, wenn es sich bei einigen der Instanzen um skalare Objekte mit nur einer Variable handelt. Max. Wiederholung Definiert, wie oft andere als die durch das Feld Keine Wiederholung angegebenen Variablen maximal erhalten werden sollen. Variable Bindungen Dient als Datenfeld der PDU unter SNMPv2. Jede Variablenbindung verknüpft eine bestimmte Objektinstanz mit dessen aktuellem Wert (mit Ausnahme von Get- und GetNext-Requests, für die der Wert ignoriert wird).