SNMP - Informatik 4

Rheinisch-Westfälische Technische Hochschule Aachen
Lehrstuhl für Informatik IV
Prof. Dr. rer. nat. Otto Spaniol
SNMP
Seminar: Internetprotokolle für die
Multimediakommunikation
WS 2002/03
Martin Krebs
Matrikelnummer: 232852
Betreuung:
Karl-Heinz Krempels
Lehrstuhl für Informatik IV, RWTH Aachen
Inhaltsverzeichnis
1
2
3
SNMP-Einführung
4
1.1
Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Geschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Ziele von SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Das Modell
5
2.1
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Management-Station (Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3
Proxy-Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.4
Das RFC-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
ASN.1 (Abstract Syntax Notation One)
7
3.1
Die Grundidee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2
Primitive Datentypen (simple types) . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.3
Subtypen (subtypes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.4
Zusammengesezte Typen (constructed types) . . . . . . . . . . . . . . . . . . . . .
8
3.5
Neue Typen (tagged types) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.6
Object Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.7
Transfersyntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
4
SMI (Structure of Mangement Information)
11
5
MIB - Management Information Base
12
5.1
System-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.2
Interfaces-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.3
AT (Adresstranslation)- Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.4
IP-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.5
ICMP-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
5.6
TCP-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2
6
7
8
5.7
UDP-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
5.8
EGP-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
5.9
Transmission-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
5.10 SNMP-Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Standard MIBs
15
6.1
RMON-MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
6.2
RMON2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
6.3
Andere MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
Das SNMP-Protokoll
16
7.1
Transportprotokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
7.2
Communities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
7.3
SNMP-Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
7.4
Aufbau der SNMP-Pakete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
7.4.1
PDU der Befehle Get, Get-next und Set . . . . . . . . . . . . . . . . . . . .
18
7.4.2
PDU von Traps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
SNMPv2
19
8.1
Einsatz weiterer Transportprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . .
20
8.2
Erweiterungen der SMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
8.2.1
Neue Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
SNMPv2 Versionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.3.1
SNMPv2c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.3.2
SNMPv2u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.3.3
SNMPv2* . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
8.3
9
SNMPv3
21
10 SNMP am Beispiel
22
10.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
24
1
SNMP-Einführung
1.1 Einleitung
Netzwerke sind in der Regel recht komplex und heterogen. Sie bestehen aus Komponenten wie Router, Switches oder Drucker. Mit wachsender Anzahl und steigender Komplexität der Geräte wächst
auch der administrative Aufwand, und damit die TCO (Total Cost of Ownership). Bei schlecht strukturierten und dokumentierten Netzwerken kann die Fehlersuche oft sehr viel Zeit verursachen. Jede
Ausfallzeit, etwa eines E-Commerce Webservers bedeutet für ein Unternehmen nicht kalkulierbare
Verluste, je nach Größe des Unternehmens sogar im sechsstelligen Bereich. Abhilfe schaffen intelligente Managementkonzepte, die Verwaltung und Fehlersuche wesentlich vereinfachen und beschleunigen. Die Grundlage für alle Konzepte bildet das SNMP (Simple Network Mangement Protokoll).
Die Anforderungen an ein Mangementprotokoll sind relativ hoch. Es darf nicht zu komplex sein,
und sollte ein Netzwerk nicht noch zusätzlich mit hohem Datenaustausch belasten. Für Hersteller
ist der Implementierungsaufwand für ein Endgerät oft entscheidend. Ein grundlegender Ansatzpunkt
stellt die Sicherheit bzw. ein Sicherheitskonzept eines Protokolls dar. Mit Hilfe des Protokolls muß
es möglich sein nicht nur zu überwachen, sondern auch zu steuern: Fällt ein Port auf einem Switch,
aus wird der Administrator durch eine Warnmeldung benachrichtigt. Dieser entscheidet dann, was zu
tun ist. Er könnte einen Techniker vor Ort schicken oder einfach eine Reserveroute aufschalten. Das
Protokoll muß einem Standard unterliegen, wie etwa den RFC(Request for Comments). Damit ein
Protokoll auch erfolgreich wird, sollten es viele Hersteller in ihren Geräten unterstützen. Alle diese
Ansprüche erfüllt SNMP.
1.2 Geschichte
SNMP hat seinen Ursprung im nordamerikanischen Forschungsnetz ARPANET dem Vorgänger des
Internet. Anfangs war das Netzwerk mit seinen Komponenten überschaubar. Funktionierte etwas
nicht, konnte man den verantwortlichen Router problemlos etwa mit einem Ping ausfindig machen.
In den 80er Jahren begann das Netz explosionsartig zu wachsen, in jedem Jahr verdoppelte sich die
Anzahl der angeschlossenen Netzknoten mit den angeschlossenen Subnetzen. Dadurch wurde die eingesetzte Hardware-Landschaft immer unüberschaubarer und heterogener. Im März 1987 begann eine
kleine Gruppe von Netzgurus mit der Entwicklung von Management-Protokollen. Sie verfolgten dabei mehrere verschiedene Ansätze. Darunter war das Simple Gateway Monitoring Protocol (SGMP).
Der Name wurde deshalb gewählt, da das Management von Verbindungsknoten zwischen den Subnetzen mit den jeweiligen Gateways eines der Hauptprobleme darstellte. Zwei weitere Ansätze setzten
sich nicht durch, das eine verließ nie den Entwicklungsstatus in den Labors und man gab es zu Gunsten von SGMP auf. Ein weiterer Ansatz CMOT konnte mit SGMP nicht konkurrieren. Im August
1988 wurden RFC 1065 Structurs of Management Information, RFC 1066 Management Information
und RFC 1067 Simple Network Management Protocoll zum draft standard“ erklärt. Im April 1989
”
bekam SNMP, wie es jetzt hieß, den Standard recomended“, wodurch es faktisch zur Norm für die
”
4
Verwaltung von TCP/IP basierten Netzwerken wurde. Aufgrund der einfachen Realisierung des Protokolls, sowie der geringen Anforderungen an die Hardware fand SNMP schnelle Verbreitung. Es
zeigten sich aber bald Schwächen, insbesondere im Bereich Sicherheit. Zur Lösung des Problems erschienen im Juli 1992 eine Reihe von RFCs, allgemein unter dem Namen Secure SNMP bekannt, als
Proposed Standard. Zur gleichen Zeit wurde eine Erweiterung von SNMP vorgeschlagen, das Simple Management Protocol (SMP). Aus beiden Ansätzen entstand dann die offizielle zweite Version
von SNMP: SNMPv2. Im März 1993 erlangte SNMPv2 den Proposed Internet Standard. Das Sicherheitskonzept von SNMPv2 wurde aber allgemein als zu komplex empfunden, so dass im Jahr 1996
überarbeitete RFCs zu SNMPv2 erschienen und man das Sicherheitskonzept von SNMPv2 durch
das alte aus SNMPv1 bekannte und unsichere Community-basierende Konzept ablöste. Die neue“
”
Version erhielt den Namen SNMPv2c. Um das Sicherheitsproblem zu lösen, entwickelten sich zwei
konkurrierende Ansätze, SNMPv2u und SNMPv2*. Da es aber keinen einheitlichen Standard mehr
gab, begann 1997 die Arbeitsgruppe SNMPv3 mit der Arbeit. Im Januar 1998 wurde SNMPv3 zum
Proposed Internet Standard, im März 1999 zum Draft Internet Standard erklärt.
1.3 Ziele von SNMP
SNMP liegt folgenden Zielen zu Grunde:
leicht und günstig zu implementieren mit möglichst geringem zusätzlichen Hardwareaufwand
plattformunabhängig
keine zu große Netzbelastung verursachen
offene Architektur für zukünftige Erweiterungen (Abwärtskompatibilität)
2
Das Modell
SNMP basiert auf dem Manager-Agent-Modell, wie es auch im OSI-Modell für Netzwerkmanagement verwendet wird. Die vier Kernkomponenten sind:
Verwalteter Knoten mit Managementagent
Managementstation
Management Information Base (MIB)
Managementprotokoll
5
Bild 2.1: Manager-Agent-Modell
2.1 Agent
Die verwalteten Knoten können beliebige Endgeräte sein, die über einen Netzwerkanschluss verfügen,
wie Router, Swichtes, oder Drucker. Es kann aber auch eine spezielle Anwendung sein wie das Betriebssystem eines PCs oder ein Proxyserver-Programm. Theoretisch ist es auch möglich, einen Toaster oder eine Kaffeemaschine mit SNMP zu verwalten, was dem Leitgedanken von SNMP keinesfalls
widerspricht. Damit das entsprechende Gerät verwaltet werden kann, muss es einen SNMP-Agenten
ausführen können, der die Kommunikation mit der Außenwelt abwickelt. Jeder Agent besitzt eine
lokale Datenbank mit Variablen (MIB - Management Information Base), die den Zustand oder Ereignisse beschreiben. Durch Setzen von Variablen ist es möglich, den Zustand des Knotens zu verändern.
Die Objekte sind nicht generisch, d.h. sie sind nicht erzeugbar, sondern sie sind vorhanden oder eben
nicht. Sie besitzen auch keine Methoden, sondern nur einen Wert der gelesen (GET) oder geschrieben
(SET) werden kann.
2.2 Management-Station (Manager)
Das eigentliche Netzwerk-Management wird auf der Management-Station ausgeführt. Die Station
ist ein beliebiger Rechner, auf der ein spezielles Management-Programm läuft, das mit den einzelnen verwalteten Knoten kommuniziert. Die Hauptaufgabe von SNMP besteht aus geplanter Anfrage/Antwort-Kommunikation, die von der Management-Station ausgelöst werden kann. Die zweite Möglichkeit ist, dass der Agent selbständig eine Nachricht an die NMS (Network Management Station) sendet, ausgelöst etwa durch ein unvorhergesehenes Ereignis, z.B. einen ausgefallenen Port an einem
Switch. Diese Form der Nachricht wird als Trap bezeichnet. Mit Hilfe der Management Software
ist es möglich, bestimmte Anfragen an Agenten zu automatisieren. Die Station fragt dann in einem
bestimmten Zeitintervall Variablen ab, was als Polling bezeichnet wird. Geschieht dieses Polling in
einem zu großen Umfang, belastet es ein bestehendes Netz noch zusätzlich, was dem Grundgedanken
von SNMP widerspricht: möglichst klein und einfach zu sein.
6
2.3 Proxy-Agent
Nicht alle Netzknoten, insbesondere ältere, verfügen über einen Agenten und sind damit per SNMP
managebar. Um diese Geräte aber dennoch in ein Management-Konzept mit einzubinden, definiert
SNMP sog. Proxy-Agenten. Der Proxy-Agent wird zwischen Management-Station und dem zu verwaltenden Gerät geschaltet. Die Kommunikation zwischen NMS erfolgt in gewohnter Weise über
SNMP. Das Gerät kommuniziert dann mit dem Proxy-Agenten in einer ihm verständlichen Sprache.
Danach sendet der Proxy-Agent die Antwort wieder als SNMP-Nachricht zurück an die NMS.
2.4 Das RFC-Framework
Das SNMP-Framework basiert auf einer Vielzahl von Dokumenten und Spezifikationen und wird
ständig erweitert. Die wichtigsten Dokumente von SNMP sind:
RFC1155/1212 Structure of Management Information (SMI)
RFC1213 Management Information Base II(MIB-II)
RFC1157 SNMP Simple Network Management Protokoll
3
ASN.1 (Abstract Syntax Notation One)
3.1 Die Grundidee
ASN.1 ist die formale Beschreibungssprache von Objekten, die von Agenten verwaltet werden und
von einer NMS gelesen bzw. geschrieben werden können. Die Kommunikation zwischen Agent und
NMS verschiedener Hersteller ist nur über einen einheitlichen Standard in der Kommunikation als
auch in einer genormten Beschreibungssprache gewährleistet. Die formale Beschreibung von Objekten wird als abstract syntax, der serialisierte Datenstrom als transfer syntax und die spezielle Darstellung auf dem Rechner wird als local syntax bezeichnet. SNMP benutzt die ASN.1 des OSI-Standards
nach ISO-Norm 8824 für die Transfer Syntax und ISO-Norm 8825 für die Basic Encoding Rules. Die
Kodierung unterteilt sich in zwei genormte Module, eines zur Kodierung und eines zur Dekodierung.
Diese beiden Vorgänge werden in der zuvor genannten Norm durch entsprechende Regeln abgedeckt.
ASN.1 ist eine primitive Datendeklarationssprache die von SNMP in einer reduzierten Version benutzt
wird, und sich darüber hinaus einiger Besonderheiten bedient. ASN.1 definiert primitive Objekte, die
dann zu komplexen Objekten zusammengefasst werden. Vorhandene Standarddatentypen werden in
Großbuchstaben geschrieben (z.B. INTEGER) . Benutzerdefinierte Datentypen besitzen einen großen
Anfangsbuchstaben. Variablen können Groß-,Kleinbuchstaben, Ziffern oder Bindestriche enthalten,
beginnen aber klein (z.B. counter). Kommentare werden von zwei Bindestrichen jeweils am Anfang
und Ende eingeschlossen. Es existieren vier Arten von Typen: simple types, constructed types, tagged
types, subtypes.
7
3.2 Primitive Datentypen (simple types)
Es folgen zulässige Datentypen nach ASN.1. Weitere Datentypen wie BIT STRING,BOOLEAN oder
REAL sind zwar in ASN.1 definiert, werden aber von SNMP nicht benutzt.
Primitivtyp
INTEGER
OCTET STRING
NULL
OBJECT IDENTIFIER
Bedeutung
Ganzzahl
Zeichenkette zwischen 0 und 255 Byte
Platzhalter
Objektbezeichner
Allgemeine Deklaration:
NameOfType::=TYPE
Beispiel 1:
Deklaration der Variablen DisplayString als Zeichenkette
DisplayString ::= OCTETSTRING
3.3 Subtypen (subtypes)
Variablen von Subtypen können nur bestimmte Werte annehmen, oder sind auf einen bestimmten
Bereich beschränkt.
Beispiel 2:
Die Variable Status kann nur die drei Zustände up, down oder unknown annehmen. Packetsize ist eine
Ganzzahl zwischen 0 und 1023.
Status ::= INTEGER up(1), down(2), unknown(3)
Packetsize ::= INTEGER (0..1023)
3.4 Zusammengesezte Typen (constructed types)
ASN.1 definiert mehrere constructed types, in SNMP werden aber nur SEQUENCE, SEQUENCE
OF und CHOICE verwendet. Mit Hilfe von SEQUENCE kann man z.B. Tabelleneinträge definieren.
Alle Beispiele aus [1].
Beispiel 3:
TableEntry ::= SEQUENCE
tableIndex INTEGER
tableAdress OCTETSTRING
tableOwner OBJECTIDENTIFIER
8
SEQUENCE OF konstruiert eine geordnete Liste mit Elementen vom gleichen Typ, was einem Array
in einer höheren Programmiersprache wie C entsprechen würde.
Beispiel 4:
Hier ist Table eine Tabelle mit Einträgen vom Typ TableEntry.
Table ::= SEQUENCE OF TableEntry
CHOICE ist ein Variantentyp.
Beispiel 5:
NumberRepr stellt drei verschiedene Möglichkeiten zur Auswahl eine Zahl darzustellen. Entweder
als Ganzzahl, bcd-Zahl oder im Hex-ASCII Format.
NumberRepr ::=CHOICE
integerRepr INTEGER
bcdRepr OCTET STRING
hexRepr OCTET STRING
3.5 Neue Typen (tagged types)
Neue Typen lassen sich durch tagging, ähnlich in C, der alten Typen erzeugen. Dazu stehen vier
Kategorien zur Auswahl: universell, anwendungsweit, kontextspezifisch und privat. Ein tagged typ
besteht aus einer Beschriftung und einer Ganzzahl zur Identifizierung des Tags.
Bespiel 6:
Es werden zwei Typen durch 32-Bit Ganzzahlen implementiert, sind aber unterschiedlich in der Umsetzung. Der erste kann nach erreichen des Höchstwertes wieder am Anfang beginnen, der zweite
läuft nur bis zum Höchstwert und muss manuell zurückgesetzt werden.
Counter32 ::= [application1] INTEGER (0.. 4294967295)
Gauge32 ::= [application2] INTEGER (0.. 4294967295)
3.6 Object Identifier
Um jedes Objekt eindeutig zu identifizieren existieren Object Identifier, die das Objekt an der zugewiesenen Stelle im Standardbaum einordnen. Die Wurzel des Baumes ist leer, und besitzt weder
Beschreibung noch Nummer. Auf der obersten Ebene befinden sich die drei wichtigsten Standardisierungsorgane, ccitt (jetzt ITU), iso und joint-iso-citt, eine Kombination aus beiden. Jede Kante hat
9
eine Beschriftung und eine Nummer. Damit kann jedes Objekt in diesem Standard als Object Identifier dargestellt werden. Es existieren drei Darstellungsarten, nur Beschreibung, nur Nummern oder
Mischform. Die Objekt Identifier
iso identified-organisation (3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) ,
1361211
oder iso 3 dod(6) 1 2 1 system(1)
beschreiben das gleiche Objekt,nämlich sysDescr.0 .
3.7 Transfersyntax
Die Transfersyntax definiert, wie Werte von ASN.1-Typen eindeutig in eine Bytefolge zur Übertragung kodiert und dekodiert werden. Die von ASN.1 benutzte Transfersyntax ist BER (Basic Encoding
Rules). ASN.1 hat keine weitere über SNMP hinausgehende Transfersyntax. Die Regeln sind rekursiv aufgebaut, so dass das Kodieren eines strukturierten Objektes nur die Verkettung der Kodierungen
der Komponentenobjekte ist. Der Vorteil hierbei ist, dass alle Objektkodierungen auf Primitivobjekte
reduziert werden. Die Kodierung dieser Objekte geschieht dann durch BER. Jede Variable wird durch
drei Größen kodiert:
Bezeichner (tag)
Länge des Datenfeldes in Byte (length)
Datenfeld (value)
Die Kodierung wird auch als TLV-Kodierung bezeichnet.
Tag
Tag ist die Typenkennung und besteht aus simple types oder constructed types. Die vier Tag-Klassen
sind wie folgt codiert und belegen Bit 7 und 8.
Ein Tag wird wie folgt kodiert:
Tag-Klasse
87
primitive/constructed type
6
Typenkennung
54321
Die Tag-Klasse kann folgende Werte annehmen:
Tag-Klasse
Bit 8 Bit 7
universal
0
0
application
0
1
context-specific
1
0
private
1
1
Das Feld primitive/constructed Type kann die Werte 0 und 1 annehmen.
Length
Das Feld lenght besteht aus 127 Bit, wobei Bit 127 reserviert ist.
10
Value
Im Datenfeld wird der Wert einer Variablen kodiert. Es ist entweder leer oder enthält beliebig viele
Bytes.
4
SMI (Structure of Mangement Information)
SMI bedeutet wörtlich übersetzt Struktur und Identifizierung von Managementinformationen und definiert ein allgemeines Rahmenwerk mit dem Managed Objekts (MO) in einer Management Information Base (MIB) formal nach ASN.1 beschrieben werden können. SMI ist eine Teilmenge von ASN.1
um SNMP Datenstrukturen zu erzeugen. Um Einfachheit zu gewährleisten beschränkt man sich auf
einfache Datentypen bzw. (2-dim.) Tabellen. Der Standardbaum ist der gleiche wie in ASN.1, mit
der Ausnahme, dass identified-organisation hier org heißt. Die Objektklassen werden definiert über
Namen, ihrer Syntax und die zugehörige Kodierung. Der Name des Objekts ist wie in ASN.1, nur
dass hier eine Kurzform wie (mgmt 1) möglich ist. SNMP Variablen werden als Objekte definiert,
zusammenhängende Objekte werden in Gruppen zusammengefasst, wie z.b. TCP-Gruppe, und Gruppen werden wiederum in Module gepackt. Eine SNMP-Variable beginnt mit dem Aufruf des Makros
MODULE-IDENTITY, das den Namen und die Adresse des Implementers, die Revisionsgeschichte
und andere Informationen liefert. Es folgt OBJECT-IDENTITY, das den Namen im Standardbaum
liefert. Darauf wird das Makro OBJECT-TYPE aufgerufen, das die zu verwaltenden Variablen und
deren Merkmale benennt. Dieses hat vier zwingende und vier weiter optionale Parameter:
Syntax, der Datentyp der Variablen
Max-Access, der Zugriff auf die Variable, Lesen-Schreiben oder Nur-Lesen
Status, Status bei der aktuellen SNMP-Entwicklung z.B. current für aktuell gültig
Description, eine Beschreibung was die Variable leistet (optional)
::=experimenatal 20 stellt die Variable in den Baum
Beispiel der Variable lostPackets als Deklaration OBJECT TYPE (aus [2]).
LostPackets OBJECT TYPE
SYNTAX Counter -- Benutze 32-Bit-Zähler
MAX-ACCESS read-only -- Variable ist schreibgeschützt
STATUS current -- Variable ist aktuell
DESCRIPTION ’Anzahl der verlorenen Pakete seit dem letzten Booten’
::=experimental 20
SMI definiert drei Datentypengruppen, wie auch schon aus ASN.1, Primtive Types, Constructor Types und Defined Types. Defined Types sind in ASN.1 von Basistypen abgeleitete Datentypen. Die
folgende Tabelle zeigt sechs Defined Types (SNMPv1).
11
Defined Type
NetworkAddress
IpAdress
Counter
Gauge
TimeTicks
Opaque
5
Bedeutung
Netzwerkadresse (IP-Adresse)
4-Byte-Internetadresse
32-Bit-Zähler,beginnt wieder bei 0
32-Bit-Pegelanzeige, kein Wechsel auf 0
Anzahl von 1/100 sec-Einheiten (32-Bit)
für private Datentypen,die auf OCTET STRING abgebildet werden
MIB - Management Information Base
Die von SNMP verwalteten Objekte werden in der MIB verwaltet. MIB bezeichnet keine reale Datenbank, sondern ein Datenmodell, das die per SNMP verwalteten Managed Nodes in einer abstrahierten
und speziellen Sicht beschreibt. Definiert wird die aktuelle Version der MIB, die MIB-II in RFC
1213, die im wesentlichen aus 175 Makroaufrufen und Kommentaren besteht. Dabei werden Objekte
in Gruppen eingeteilt. Unter dem Teilbaum mib-2 existieren derzeit 10 Gruppen, die jeweils wieder
eigene Teilbäume bilden, in denen sich insgesamt 175 Objekte befinden. Die Object Identifier aller
Objekte dort beginnen mit mgmt 1 oder eben 1.3.6.1.2.1. Alle Gruppen, außer egp müssen implementiert werden.
Bild 5.1: MIB-Baum
12
Die MIB-II besteht aus folgenden Gruppen:
mib-2 1 system
mib-2 2 interfaces
mib-2 3 at
mib-2 4 ip
mib-2 5 icmp
mib-2 6 tcp
mib-2 7 udp
mib-2 8 egp
mib-2 10 transmission
mib-2 11 snmp
5.1 System-Group
Die Gruppe System enthält 7 Objekte, die aus Informationen zum Managed Node bestehen.
system 1
system 2
system 3
system 4
system 5
system 6
system 7
sysDescr
sysObjectID
sysUPTime
sysContact
sysName
sysLocation
sysServices
Beschreibung der Hardware- und Systemsoftware-Konfiguration
Objekt Identifier des Herstellers des Managed Nodes
Zeit seit dem letzten Restart des Agent in TimeTicks (1/100 sec)
Administrator des Managed Nodes
Names des Managed Nodes, meist DNS-Name
Beschreibung des Standortes des Managed Nodes
implementierte Kommunikationsschichten des Managed Node
5.2 Interfaces-Group
Diese Gruppe enthält Informationen und Tabellen über die vorhandenen Netzwerk-Interfaces des
Gerätes, wie Übertragungsgeschwindigkeit (ifSpeed), Zustand (ifOperStatus) oder Länge der Warteschlange in Paketen.
5.3 AT (Adresstranslation)- Group
Die AT-Gruppe besteht aus Informationen über Umsetzung von Ethernet in IP-Adressen. Sie ist allerding als ’deprecated’ gekennzeichnet und wird in einer nächsten Version nicht mehr vorhanden
sein.
5.4 IP-Group
Unter der IP-Gruppe finden sich u.a. Zähler über Anzahl der empfangenen IP-Datagramme oder eine
IP-Tabelle mit dem des Managed Nodes zugewiesenen IP-Adressen. Besonders bei Routern ist die
13
Tabelle ipRouteTable mit allen bekannten Routen interessant.
5.5 ICMP-Group
IP-Fehlermeldungen, gesendete und empfangene ICMP-Fehlermeldungen enthält diese Gruppe.
5.6 TCP-Group
Hier befinden sich Informationen über gesendete und empfangene TCP-Pakete, oder die tcpConnTable mit aktuellen TCP-Verbindungen.
5.7 UDP-Group
Die UDP-Gruppe enthält 4 Statistikzähler, und u.a. die Tabelle udpTable, die aktuelle UDP-Empfänger
beschreibt.
5.8 EGP-Group
In der EGP-Gruppe befinden sich Objekte des Exterior Gateway Protocols, ein Protokoll zum Austausch von Erreichbarkeitsinformationen. Das EGP wurde inzwischen aber durch das BGP (Border
Gateway Protocol) abgelöst.
5.9 Transmission-Group
Die Transmission-Gruppe ist ein Platzhalter für medienspezifische MIBs, etwa der Ether-Like MIB
oder der Token-Ring MIB (RFC 1231 IEEE 802.5).
5.10 SNMP-Group
In der SNMP-Gruppe sind 29 Zähler untergebracht zu gesendeten und empfangenen SNMP-Nachrichten
oder Fehlermeldungen wie snmpInNosuchName snmp 9 oder der GetNext-Zähler snmpInGetNexts
snmp 16.
14
6
Standard MIBs
6.1 RMON-MIB
Außer der MIB-I / MIB-II existieren noch weiter MIBs, wie schon erwähnt die Ether-Like MIB. Viele
Hersteller wie HP oder Cisco statten ihre Produkte mit eigenen MIBs aus, wie z.B. die Drucker-MIB
von HP. Von besonderer Bedeutung ist allerdings die RMON (Remote Monitoring) MIB. Sie erweitert SNMP beachtlich um weitere Management und Überwachungsfunktionen, die den Datenverkehr
protokollieren aber keine Informationen über spezielle Netzkomponenten liefern. RMON erweitert
SNMP um Protokollfunktionen für LANs, da SNMP ursprünglich für WANs entwickelt wurde mit
Schwerpunkt Gateways,Router und allgemeine Informationen. Mit Hilfe der RMON-MIB steigt die
Funktionalität für Geräte auf OSI-Layer 2, etwa Switches, Repeater oder Bridges. Die RMON-MIB
wird häufig von einem Monotoring-Tool, wie das komerzielle HP OpenView. Die Monitoring Software auf der Network Management Station ist eine Komplettlösung, die ganze Netzwerke verwaltet
und überwacht. Dazu zählt:
Identifikation der am LAN angeschlossenen Stationen
Ermittlung der Netzbelastung und graphische Darstellung
Verkehrsaufkommen
Beobachten der Verfügbarkeit (host up/down?)
Ermittlung und Darstellung anderer Protokolle wie IPX, NetBios
Datenaufkommen mit Liste der zehn aktivsten Sender (Top Ten Talkers)
RMON ist eine Gruppe innerhalb des MIB-II Teilbaums und bildet selbst wieder einen Teilbaum mit
zehn Gruppen,ursprünglich waren es nur neun, Token Ring kam später dazu. Der eindeutige OBJECTIDENTIFIER für RMON lautet mib2 16. Die Implementierung ist optional, die SMI schreibt nur
vor, dass jede implementierte Gruppe auch vollständig sein muss. Die RMON-MIB besteht aus folgenden Gruppen
rmon 1
rmon 2
rmon 3
rmon 4
rmon 5
rmon 6
rmon 7
rmon 8
rmon 9
rmon 10
statistics
history
alarm
hosts
hostTopN
matrix
filter
capture
event
tokenRing
enthält Statistik-Werte über den Paketverkehr
dient zur Erfassung periodischer Messwerte
Variablen, die bei Schwellenwertüberschreitung ein Alarmereignis senden
enthält Quell- und Ziel-MAC-Adressen
enthält z.B Top Ten Talkers
Datenverkehrsaufkommen zwischen je zwei MAC-Adressen als Paketzähler
Filteraudrücke, nach den Pakete im LAN ausgewählt werden können
mit Hilfe der Filter-Gruppe lassen sich Trace-Anwendungen realisieren
enthält eine Protokolltabelle und eine Ereignistabelle
stellt Informationen zu Token Ring zur Verfügung
15
6.2 RMON2
RMON2 ist eine Weiterentwicklung von RMON. Mit RMON2 ist es nun möglich, Geräte auf Layer
3 und darüberhinaus zu verwalten, wobei RMON ja nur auf Layer 2 beschränkt ist. Es lässt sich
nun E-Mail Verkehr, WWW-Zugriff oder der Router direkt überwachen. Dies ermöglicht, z.B. nach
der Installation von neuen Anwendungen festzustellen, warum das Netzwerk plötzlich so langsam
geworden ist, oder es lässt sich herausfinden, welcher Datenverkehr durch privates Surfen der User in
einem Unternehmen verursacht wird. RMON2 stellt dazu 10 weitere Gruppen zur Verfügung:
rmon 11 protocolDir
rmon 12 protocolDist
rmon 13 adressMap
rmon 14 n1Host
rmon 15 n1Matrix
rmon 16 a1Host
rmon 17 a1Matrix
rmon 18 userHistory
rmon 19 probeConfig
rmon 20 rmonConformance
6.3 Andere MIBs
Es existieren fast schon unzählig viele MIBs, vor allem herstellerspezifische. An dieser Stelle seien
noch einige wichtige Standard-MIBs gennant.
RIP Version 2 (RFC 1389), MIB für das Routing Information Protocol (RIP)
Ethernet MIB (RFC 1398), enthält u.a statisic group und collision statistic group
UPS Management MIB (RFC 1628), MIB für unterbrechungsfreie Stromversorgung (USV)
ATM Management MIB (RFC 1695), MIB für ATM mit Verkehrsmanagement
Token Ring MIB (RFC 1231)
7
Das SNMP-Protokoll
7.1 Transportprotokoll
Die Kommunikation zwischen Managementstation und Agenten erfolgt durch den Austausch von
Protokollnachrichten. SNMP verwendet das verbindungs- und quittungslose User Datagramm Protocol (UDP). Auf der NMS wird dazu in der Regel Port 161 zum Senden und Empfangen von SET und
GET benutzt. Port 162 wartet auf ankommende Traps eines Agenten. RFC 1157 weist aber darauf hin,
16
dass auch andere Transportprotokolle benutzt werden können. Das Datagramm Protokoll entspricht
aber am ehesten dem Leitgedanken von SNMP, da es im Gegensatz zu TCP keinen zu großen Overhead besitzt, und ein bestehendes Netz nicht noch zusätzlich belastet. Ein Nachteil ist allerdings, dass
Kommandos schlichtweg verloren gehen können, ohne dass es weiter auffällt, da der Kommunikationspartner den Empfang nicht quittieren muss.
7.2 Communities
Die Einheit einer Anwendung auf einer Management Station und einem Agenten auf einem verwalteten Gerät wird als Application Entities bezeichnet. Beide benutzen zur Abwicklung des SNMPProtokolls jeweils eine SNMP-Protocol Entity. Application Entities werden zu Gruppen, sogenannten
SNMP Communities, zusammengefasst. Sie erhalten einen eindeutigen Namen, den Community Name oder auch als Community String bezeichnet. Es können nur solche Application Entities miteinander kommunizieren, die in der gleichen Community sind. Man unterscheidet in Public und Private
Community String. Der Public String berechtigt nur zum Lesen von Objektvariablen, der Private
String erlaubt sowohl Lesen als auch Schreiben.
7.3 SNMP-Nachrichten
In der Regel sendet eine Management Station eine Anfrage an einen Agenten, der darauf mit der
gewünschten Information, einer Bestätigung des Änderungswunsches oder mit einer Fehlermeldung
antwortet. Eine Fehlermeldung könnte sein, dass die angeforderte Variable nicht existiert, dann würde
die Fehlermeldung lauten noSuchName“. Die Daten werden bei der Kommunikation,wie bereits
”
erwähnt, per ASN.1 Transfersyntax übertragen. Das eigentliche Protokoll von SNMP wird in RFC
1448 definiert. SNMP kennt 7 Nachrichtentypen, davon werden 6 vom Initiator gesendet, die siebte
ist die Antwort. Die möglichen Nachrichten sind:
Get
Get-next
Set
Inform
Trap
get-response
fordert den Wert einer oder mehreren Variablen an
fordert die nächste Variable nach der aktuellen an
setzt eine Variable auf einen neuen Wert
Manager/Manager Nachricht mit einer Beschreibung der aktuellen MIB
Spontanmeldung eines Ereignisses vom Agenten an den Manager
Anwort auf einen Befehl
Eine mögliche Kommunikation zwische Manager und Agent könnte so aussehen:
Beispiel 1:
Der Manager sendet get(sysDescr.0)
Der Agent antwortet get-response(sysDescr.0=’Elsa Lancom Wireless L11’)
Beispiel 2:
Die Anfrage get-next(sysDescr.0)
17
liefert get-response(sysObjectID.0=’1.3.6.1.4.x.y’), da in der MIB-II auf 1.3.6.1.2.1.1.1
(sysDescr) der OBJECT IDENTIFIER 1.3.6.1.2.1.1.2 (sysObjectID) folgt.
7.4 Aufbau der SNMP-Pakete
SNMP Version Community Name
Abbildung 7.1: SNMP Paket
PDU
Jede SNMP-Nachricht enthält eine SNMP-Versionsnummer, einen Community Namen und einen Datenteil mit der Bezeichnung Protocol Data Unit (PDU). Der Datenteil wird nach ASN.1/BER kodiert,
der Community String wir allerdings im Klartext übertragen, was ein erhebliches Sicherheitsrisiko
darstellt, und das der Hauptkritikpunkt an den ersten SNMP-Versionen ist. Insgesamt werden für die
SNMP Operationen nur zwei PDUs definiert. Eine PDU für die get, get-next und set, die zweite PDU
für trap Operationen.
7.4.1 PDU der Befehle Get, Get-next und Set
PDU-Typ request-id error-status error-index
Abbildung 7.2: Struktur einer SNMP-PDU
PDU-Typ
variable-bindings
: Kennung für den PDU-Typ (z.B. 0 für GetRequest)
request-id : Kennung, über die get-,get-next- und set-Operationen den jeweiligen Anworten zugeordnet werden können, auch eine Möglichkeit, verlorene oder gedoppelte Responses zu erkennen
error-status: Status der Ausführung der Operationen, kann folgende Werte annehmen:
NoError (0)
tooBig (1)
noSuchName (2)
badValue (3)
read-Only (4)
genErr(5)
erfolgreich
Ergebnis passt nicht in einzelne Nachricht
Objekt ist unbekannt
unzulässiger Wert bei Set-Operation
Variable ist schreibgeschützt
alles andere
error-index
: Index der Variablen in variable-bindings, die den im error-status gemeldeten Fehler
verursacht hat; wird nur bei noSuchName, bad Value und read-only angegeben, sonst NULL.
variable-bindings : Liste der betroffenen Objektvariablen
Bei GetRequest-, GetNextREquest- und SetRequest-PDUs sind die Werte für error-status und errorindex immer 0.
18
7.4.2 PDU von Traps
Traps sind spontane Ereignismeldungen, die ein Agent selbständig an eine Managementstation sendet.
Trap-PDUs haben dabei folgende Struktur:
PDU-Typ Geräte-Herst. Agent-Adresse
Abbildung 7.3: Struktur einer Trap-PDU
generic-trap
specific-trap
time-stamp
variable-bindings
PDU-Typ
: Kennung für den PDU-Typ, in diesem Fall nur der Wet 4 für Trap
enterprise
: Kennung des Gerätes, Wert der MIB-Variablen sysObjectID auf dem Managed Node
agent-addr : Netzwerkadresse des sendenden Managed Node
generic-trap : Ereignis, das den Trap auslöst, dass kann sein:
Typ
coldstart (0)
warmstart (1)
linkDown (2)
linkUp (3)
authenticationFailure (4)
egpNeighborLoss (5)
enterpriseSpecific (6)
Bedeutung
der Agent startet neu, Objekte in seiner MIB-View können sich ändern
der Agent re-initialisiert sich, Werte der Objekte ändern sich nicht
eine angeschlossene Schnittstelle ist vom up in den down Zustand gewechselt
wie linkDown, aber Schnittstelle von down nach up
Versuch des Zugriffs mit einer falschen Community
ein EGP-Nachbar (Gateway) ist in den down Zustand gewechselt
ein anderes herstellerspezifisches Ereignis ist eingetreten
specific-trap
: bezeichnet den enterpriseSpecific-Trap, ansonsten 0
time-stamp
: Wert des Objektes sysUpTime zum Zeitpunkt des Ereignisses
variable-bindings : Liste der betroffenen Objektvariablen
8
SNMPv2
SNMPv2 ist eine kontinuierliche Weiterentwicklung des ursprünglichen SNMP Protokolls. Die gemachten Verbesserungsvorschläge für die neue Version ergaben sich aus den Situationen, die mit dem
praktischen Einsatz von SNMP verbunden waren. Der Hauptschwerpunkt ist die Einführung eines
neuen Sicherheitsmodells. Aber auch in anderen Bereichen wurde SNMP deutlich erweitert, dabei
sollte es aber keinesfalls gegen den Grundgedanken eines simple“ Protokolls verstoßen. SNMPv1
”
benutzt in seinem Kommunikationsmodell bei der Beziehung zwischen Agenten und Managementstationen das Community-Modell. In SNMPv2 wurde es deutlich durch die Einführung von SNMPv2”
Party“ und SNMPv2-context“ erweitert. Aufgrund seiner Komplexität setzte sich dieses Sicherheits”
konzept im Internet aber nicht durch. Deshalb wurden nach Überarbeitung des SNMPv2-Standards
RFC 1901-1908 komplett für nichtig erklärt und verworfen. Stattdessen verwendete man wieder das
aus SNMPv1 bekannte Community-Modell. Dieses Vorgehen war aber keine Lösung des eigentlichen
Problems, und deshalb entstanden zwei weitere konkurrierende Ansätze des Sicherheitsmodells.
19
Die wichtigsten Neuerungen im Überblick sind:
Kommunikationsmodell für SNMP Protocol Entities
Sicherheitskonzept
Kommunikation zwischen Managementstation
Erweiterung des Agent-Konzeptes
Einführung einer MIB für Protocol Entities
Übertragung größerer Daten in einer PDU
Abfrage einer ganzen Tabelle mit nur einem Befehl (Get-Bulk)
Erweiterte Fehlersignalisierungen und Traps
Erweiterung der Structure of Management Information (SMI)
Verwendung anderer Transportprotokolle
8.1 Einsatz weiterer Transportprotokolle
SNMPv1 wurde für die Verwaltung von TCP/IP basierten Netzwerken entwickelt. Damit ist SNMP
fest mit dem TCP/IP Protokoll-Stack verbunden, und ein Einsatz anderer Transportprotokolle wie
IPX oder OSI ist damit nicht möglich. Um aber die Verbreitung von SNMP weiter voranzutreiben
und auch die Verwaltung von Netzwerken, die auf anderen Protokollen basieren zu ermöglichen,
wurden einige Änderungen vorgenommen. Das Objekt IPAdresse besteht aus einer 32-Bit Internetadresse, für eine OSI-Adresse ist dieses Objekt aber nicht nutzbar. Die Lösung war die Schaffung
eines neuen Adresstyps, der bis zu 21 Oktette aufnehmen kann. Das neue Objekt wird als NSAPAdresse bezeichnet. Damit besteht die Nutzung einer beliebigen OSI-Adresse, aber auch der Einsatz
von IPv6-Adressen, die aus einer 128-Bit-Adresse bestehen, ist möglich. Damit ist SNMP für den
nächsten großen Entwicklungsschritt des Internets auf IPv6 gerüstet. Neben dem empfohlenen User
Datagramm Protocol (UDP) werden folgene Transportprotokolle vorgeschlagen (RFC 1149 - Transport Mappings for SNMPv2):
Novell Internetwork Packet Exchange (IPX)
OSI Connectionless-Mode Network Service CLNS
AppleTalk DDP
8.2 Erweiterungen der SMI
8.2.1 Neue Datentypen
Es werden zwei neue Datentypen definiert.
Counter64 ::= [application6] IMPLICIT INTEGER (0..18446744073709551615)
Unsigned32 :: = [application2] IMPLICIT INTEGER (0..4294967295)
20
Der Einsatz des Datentyps BITSTRING ist nun wie in ASN.1 auch in SNMP möglich. Der Datentyp
Unsigned32 ist nur eine anderer Name für den Gauge Datentyp, hat sonst keinen Unterschied. Außerdem wurden die Bezeichnungen von Gauge und Counter in Gauge32 und Counter32 geändert, und es
existiert ein neuer Datentyp NSAP (für NSAPAdresse).
8.3 SNMPv2 Versionen
8.3.1 SNMPv2c
SNMPv2c ist das Community Based SNMP, das das Sicherheitsmodell aus SNMPv1 übernommen
hat. Es ist der kleinste gemeinsame Nenner und einfach in der Praxis umzusetzen. Da es aber das
nicht mehr zeitgemäße Sicherheitskonzept beinhaltet, gingen die Arbeiten weiter, die zu zwei konkurrierenden Ansätzen führten.
8.3.2 SNMPv2u
SNMPv2u ähnelt der ursprünglichen Spezifikation von SNMPv2. Statt Parties enthält es aber ein
User/Agent-Konzept, daher trägt das Sicherheitsmodell in dieser Version den Namen User-BasedSecurity-Modell (USEC-Modell). Die Authentifikation erfolgt mit Benutzername und Passwort. Zu
jedem Benutzer ist ein Schlüssel generierbar, mit dessen Hilfe die übertragenen Daten verschlüsselt
werden können.
8.3.3 SNMPv2*
SNMPv2* (v2 star) implementiert den zweiten Ansatz zur Beseitigung des Sicherheitsproblems. Es
basiert bis 80 Prozent auf den ursprünglichen Dokumenten von SNMPv2. Zusätzlich implementiert es
weitere Funktionen auf der Managementstation, wie z.B. mögliche Fernkonfiguration von Agenten,
um eine MIB auf dem Agenten zu ändern.
9
SNMPv3
Nach der Spaltung und Scheitern der SNMPv2 Arbeitsgruppe wurde die SNMPv3 Arbeitsgruppe
gegründet und mit der Ausarbeitung eines einheitlichen Standards beauftragt, als Nachfolger zu
SNMPv1/2. Es wurden folgende Ziele zuvor klar definiert:
Es soll so viel wie möglich aus den beiden konkurrierenden Versionen SNMPv2u und SNMPv2*
übernommen werden
Das neue Sicherheitskonzept soll es ermöglichen, die set-Operation über das Internet auszuführen
21
SNMPv3 soll eine flexible Architektur bekommen, die es erlaubt, alternative Modelle zu integrieren
SNMPv3 soll so einfach wie möglich gehalten werden
Im Januar 1998 wurden folgende Dokumente der SNMPv3 Arbeitsgruppe als Proposed Internet Standard veröffentlicht:
RFC 2271 An Architekture for Describing SNMP Management Frameworks
RFC 2272 Message Processing and Dispatching for the SNMP Protocol
RFC 2273 SNMPv3 Applications
RFC 2274 User-based Security Model (USM) for version 3 of the SNMP Protocol
RFC 2275 View-based Access Control Model (VACM) for the SNMP Protocol
10 SNMP am Beispiel
Das folgende Beispiel zeigt eine Toaster-MIB. Der Toaster bildet einen Teilbaum unter enterprise und
besitzt den OBJECT IDENTIFIER
iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).epilogue(12).toaster(2) . Der Teilbaum toaster enthält folgende Objekte:
(1) toasterManufacturer
(2) toasterModelNumber
(3) toasterControl
(4) toasterDoneness
(5) toasterToastType
enthält den Namen des Herstellers
enthält den Namen der Modell-Bezeichnung
steuert den Zustand des Toasters
steuert die Bräunungsstufe eines Toastes
steuert den Brottyp des Toasts
TOASTER-MIB DEFINITIONS ::= BEGIN
--- Microsoft copied from SNMP mailing list and made no changes.
-IMPORTS
enterprises
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC-1212
DisplayString
FROM RFC1213-MIB;
epilogue OBJECT IDENTIFIER ::= enterprises 12 toaster OBJECT IDENTIFIER ::= epilogue 2 -- toaster MIB
22
toasterManufacturer OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
‘The name of the toaster’s manufacturer. For instance,
Sunbeam.’
::= toaster 1 toasterModelNumber OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The name of the toaster’s model. For instance,
Radiant Automatic.’
::= toaster 2 toasterControl OBJECT-TYPE
SYNTAX INTEGER up(1),
down(2)
ACCESS read-write
STATUS mandatory
DESCRIPTION
‘This variable controls the current state of the
toaster. To begin toasting, set it to down(2). To
abort toasting (perhaps in the event of an
emergency), set it to up(2).’
::= toaster 3 toasterDoneness OBJECT-TYPE
SYNTAX INTEGER (1..10)
ACCESS read-write
STATUS mandatory
DESCRIPTION
‘This variable controls how well done ensuing toast
should be on a scale of 1 to 10. Toast made at 10
is generally considered unfit for human consumption;
toast made at 1 is lightly warmed.’
::= toaster 4 23
toasterToastType OBJECT-TYPE
SYNTAX INTEGER white-bread(1),
wheat-bread(2),
wonder-bread(3),
frozen-waffle(4),
frozen-bagel(5),
hash-brown(6),
other(7)
ACCESS read-write
STATUS mandatory
DESCRIPTION
‘This variable informs the toaster of the type of
material being toasted. The toaster uses this
information combined with toasterToastDoneness to
compute how long the material must be toasted for
to achieve the desired doneness.’
::= toaster 5 END
10.1 Zusammenfassung
Neben dem obigen Beispiel einer Toaster-MIB existieren komplette Managementlösungen für Netzwerke. Fast alle Hersteller bieten für ihre Netzwerkkomponenten Unterstützung für SNMP an, womit
einem flächendeckendem Einsatz im Netzwerk nichts mehr im Wege steht.
Nach wie vor existieren jedoch Sicherheitsprobleme, vor allem hat sich SNMPv2 mit seinen Sicherheitskonzepten nicht durchsetzen konnte. Dies dürfte den Einsatz in WANs mit hohen Sicherheitsansprüchen weitgehend verhindern. Mit SNMPv3 steht aber Besserung in Aussicht. Allerdings sind
konkrete Implementierungen seitens der Hersteller noch kaum oder fast gar nicht verfügbar. Dies
wird sicher aber im Laufe der Zeit höchstwahrscheinlich ändern. Auch auf weitere Entwicklungen
des SNMP-Standards darf man gespannt sein.
24
Literatur
[1] SNMP: Konzepte-Verfahren-Plattformen , Rainer Janssen, Wolfgang Schott, DATACOMVERLAG, Bergheim, 1993
[2] Computernetzwerke, Andrew S. Tanenbaum, Prentice Hall, 1998
[3] Managing Switched Local Area Networks - A practical Guide, Darryl P. Black, AddisonWesley, 1998
[4] TCP/IP Netzwerkadministration, Craig Hunt, O’Reilly, 1998
[5] RFC 1157 Simple Network Mangement Protokoll (SNMP)
[6] RFC 1212 Concise MIB Definitions
[7] RFC 1213 Mangement Information Base for network mangement of TCP/IP-based internets:
MIB-II
[8] RFC 1215 Convention for defining traps for use with SNMP
[9] RFC 1271 Remote network monitoring Management Information Base : RMON-MIB
[10] RFC 2271 An Architekture for Describing SNMP Management Frameworks
[11] RFC 2272 Message Processing and Dispatching for the SNMP Protocol
[12] RFC 2273 SNMPv3 Applications
[13] RFC 2274 User-based Security Model (USM) for version 3 of the SNMP Protocol
[14] RFC 2275 View-based Access Control Model (VACM) for the SNMP Protocol
25