Neben den von den Herstellern gelieferten Applikationen hat der Netzadministrator die Moeglichkeit, selbst Management-Anwendungen zu erstellen, die an die Management-Station gekoppelt werden. Abbildung 1 zeigt am Beispiel von Transview-SNMP die Schnittstellen, an denen es moeglich ist, das Management-Produkt zu modifizieren und den jeweiligen Beduerfnissen anzupassen. Fuer die Erstellung eigener Applikationen ist jedoch ein gutes Verstaendnis der Hardware und des Protokolls erforderlich. Immerhin sind die grafische Oberflaeche zu bedienen, die geraetespezifischen Aufgaben zu bearbeiten, die Geraetezugriffe mit SNMP zu behandeln sowie die Integration in das Management-Produkt vorzunehmen.
Aus diesem Taetigkeitsprofil entwickelte sich eine Art Spezialisierung, in dem in Zusammenarbeit zwischen den Hardware- herstellern und den Anbietern von Management-Loesungen komfortable Anwendungen zur Konfiguration und Bedienung von Netzkomponenten entstanden. So existieren mittlerweile spezielle Applikationen zum Inventory- oder zum Kabel-Management beziehungsweise zur Fehlerverfolgung (trouble ticketing). Da es noch keine standardisierten APIs gibt und weil letztlich SNMP so "einfach" ist, benutzen diese Anwendungen haeufig ihren eigenen ProtokollStack und sind nur lose an die Management-Station gekoppelt. Als Implementierungsaufwand bleibt dann nur die Portierung auf die eigene Unix-Version, die Anpassung an das eigene Datenbanksystem und die Koppelung an die Management- Station.
SNMP-Agenten liefern der Management-Station die gewuenschten Informationen beziehungsweise fuehren das lokale Setzen von Variablen durch. Dedizierte Netzelemente wie Repeater, Bridges oder Hubs werden meist mit integrierten SNMP-Agenten ausgeliefert, welche die ihnen entsprechende(n) MIB(s) unterstuetzen. Die Flexibilitaet bei der Normung, die durch die Unabhaengigkeit der MIB-Definitionen vom eigentlichen SNMP-Protokoll gegeben ist, wird von den Host-eigenen SNMP-Agenten auch gefordert. Daraus leiten sich im wesentlichen wiederum zwei Bedingungen ab, die im folgenden begruendet und genauer diskutiert werden sollen.
Ein Grossrechner hat im allgemeinen nur eine IP-Adresse. Deshalb darf auf einem Host auch nur ein SNMP-Agent implementiert sein. Aus dieser Praemisse ergibt sich bereits die erste Forderung: Existieren mehrere MIB-Implementierungen auf dem Host, dann muss dieser wie ein Multiplexer funktionieren, also die SNMP-Requests von der Management-Station empfangen und entsprechende Auftraege an die MIB-Implementierungen verteilen. Die Antworten, die er dann von diesen MIB-Implementierungen bekommt, fasst er zu einer SNMP- Response-Nachricht zusammen und schickt sie an die Management- Station zurueck.
Aus technischer Sicht gibt es bei der Implementierung unter Unix zwei Moeglichkeiten fuer ein solches Multiplexing. Die erste Moeglichkeit besteht darin, dass die MIB-Implementierungen eigene Prozesse darstellen, die Zugriff auf die Daten haben, die in den SNMP-Variablen modelliert sind. Der SNMP-Agent muss in diesem Fall ueber Protokolle mit diesen MIB-Implementierungen kommunizieren.
Befinden sich jedoch SNMP/SMI-Implementierung (SNMP Core Agent) und die MIB-Implementierungen auf dem gleichen Host, ist die Verwendung eines geeigneten APIs (Application Programming Interface) vorzuziehen. Die MIB-Implementierung besteht dann aus einer Reihe von Prozeduren, die dynamisch mit dem SNMP-Agent verbunden werden koennen. In der Regel werden sich zwar die Daten, die durch die SNMP-Variablen modelliert werden, ausserhalb des mit dem SNMP-Agenten verbundenen Prozesses befinden, so dass auf sie ebenfalls ueber Interprozess-Kommunikation (Shared Memory, Files, Pipes) zugegriffen werden muss.
Dies muss aber nicht bei jedem empfangenen SNMP-Request geschehen. Die MIB-Implementierung kann beispielsweise eine komplette Tabelle in einen Cache lesen und entscheiden, wie lange sie den Inhalt dieses Caches verwendet. Dadurch koennen die Antwortzeiten des SNMP-Agenten wesentlich verbessert werden.
Die zweite der erwaehnten Bedingungen besteht darin, dass die MIB- Implementierung entkoppelt vom SNMP-Core-Agent zu entwickeln sein muss. Der SNMP-Agent kann lediglich als Bestandteil des Protokoll- Stacks betrachtet werden, waehrend MIB-Implementierungen eine sehr enge Bindung zu der Software haben, die ueberwacht und gesteuert werden soll. Deshalb werden MIB-Implementierungen auch zusammen mit dieser Software entwickelt und ausgeliefert. Abbildung 2 zeigt, wie diese Anforderungen beim SNMP-Agenten 2.0 in Sinix erfuellt sind.
Der SNMP-Core-Agent und die MIB-II-Implementierung sind Bestandteil des Sinix-Systems und laufen auf diesem. Die MIB-II- Implementierung greift auf einige Daten des Sinix-Kernels zu, da diese in den MIB-II-Objekttypen modelliert sind.
In dem dargestellten Beispiel wird zu einem spaeteren Zeitpunkt Software installiert, die via SNMP ueberwacht und gesteuert werden soll. In System V.4 ist ein Package die kleinste installierbare Einheit.
Das zu installierende Package enthaelt neben dem Binaercode und den Daten auch eine entsprechende MIB-Implementierung, die auf diese Daten zugreift.
Die MIB-II ist die Standard-MIB fuer den Einstieg in das Management heterogener Netze mit SNMP. Das Management spezieller Komponenten wird unterstuetzt durch besondere MIBs wie etwa die Hub-MIB, Bridge-MIB etc. MIBs koennen darueber hinaus aber auch fuer beliebige Zwecke definiert werden. Das heisst, Hersteller und Anwender sind in der Lage, im Namensraum unter ihrem eigenen Knoten ihre eigenen Objekte zu definieren. Bis Ende 1992 sind auf diese Weise etwa 23 000 solcher Objekttypen fuer SNMP definiert worden.
Mit geeigneten MIB-Definitionen kann SNMP daher sowohl zum Management von heterogenen Netzen als auch zum System-Management sowie der Administration von Applikationen eingesetzt werden. Ein wesentlicher Vorteil besteht dabei darin, dass fuer das Management mit privaten MIBs die gleichen Mechanismen und generischen Werkzeuge eingesetzt werden koennen wie bei der Verwendung genormter MIBs. Anders formuliert: Dem Benutzer an der Management- Station steht fuer das Netz-, System- und Applikations-Management die gleiche einheitliche Benutzeroberflaeche zur Verfuegung. Darueber hinaus koennen auf der Agenten-Seite die Implementierungen privater MIBs getrennt vom SNMP-Agenten entwickelt werden.
Es gibt bereits Aktivitaeten, beispielsweise in der Host-MIB- Working-Group, genormte MIBs fuer das System-Management zu entwickeln. Deshalb wird zukuenftig auch das Management heterogener Systeme mit Hilfe von SNMP moeglich sein. Im vergangenen Jahr wurde auch damit begonnen, SNMP in Richtung SNMPv2 weiterzuentwickeln, wobei man von zahlreichen Erfahrungen aus dem praktischen Einsatz von SNMP zehrt. SNMPv2 unterscheidet sich grundsaetzlich von der bisherigen SNMP-Version, gleichzeitig wurde aber darauf geachtet, dass der Uebergang zum neuen, maechtigeren Release moeglichst einfach ist.
Die zusaetzlichen Features von SNMPv2 seien an dieser Stelle nur kurz angedeutet: umfangreiche, optionale Sicherheitsmechanismen, Locking fuer Remote Configuration, effiziente Uebertragung von vielen Variablen (Getbulk command), zusaetzliche Datentypen, differenzierte Fehlercodes sowie Manager-Manager-Kommunikation (Inform command). Die endgueltige Spezifikation von SNMPv2 ist zwar noch nicht abgeschlossen, unabhaengig davon ist jedoch vorgesehen, fuer Transview-SNMP auch einen SNMPv2-Anschluss zu entwickeln, sobald die stabile Spezifikation verfuegbar ist.
In der Uebergangszeit beide Protokolle verwenden
In der Uebergangszeit werden beide Protokolle, SNMPv2 und SNMP, in heterogenen Netzen verwendet werden muessen. Loesungsmoeglichkeiten werden derzeit vor allem in Form von zweisprachigen Management- Stationen, die SNMP-Agenten ueber SNMP beziehungsweise SNMPv2- Agenten ueber SNMPv2 ansprechen, erprobt oder in Form von Proxy- Agents, die SNMP in SNMPv2 umsetzen und umgekehrt. Von einem Einsatz sogenannter Doppelagenten, die beide Protokolle implementiert haben, wird allgemein abgeraten, weil diese Loesung gegen den Grundsatz verstossen wuerde, moeglichst wenig Overhead auf dem ueberwachten Geraet zu erzeugen.
Es bleibt ferner abzuwarten, wie schnell sich SNMPv2 im praktischen Einsatz durchsetzen und bewaehren wird, denn die erweiterte Funktionalitaet - insbesondere die Sicherheitsmechanismen - ist unweigerlich auch mit mehr Komplexitaet und einem groesseren Overhead verbunden. Eines ist jedoch absolut sicher: Die MIB-Definitionen sind kompatibel mit dem neuen SNMPv2-Protokoll. Hier zeigt sich nicht zum ersten Mal der Vorteil einer sauberen Trennung zwischen dem Management- Protokoll und der Definition der Management-Information. Bereits vorhandene MIBs sind daher auch bei einem spaeteren Management mit SNMPv2 unveraendert einsetzbar, was bedeutet, dass die Investitionen in MIB-Implementierungen und Management-Applikationen geschuetzt sind.
*Reinhard Hoepfner und Guenther Kroenert sind Mitarbeiter der Abteilung Systemtechnische Entwicklung Open Systems bei der Siemens-Nixdorf Informationssysteme AG, Muenchen.
Abbildung 1: Transview-SNMP-Architektur. Quelle: SNI
Abbildung 2: Der SNMP-Core-Agent und die MIB-II-Implementierung sind Bestandteile des Sinix-Systems. Quelle: SNI