Die unterschiedliche Komplexität der Netze stellt immer höhere Anforderungen an das Netzwerk-Management. Das Management zentral orientierter, relativ homogener Terminalnetze basiert heute auf weiterentwickelten Konzepten und Produkten. Für die Zukunft stoßen diese jedoch wegen der zunehmenden Heterogenität der Systeme an ihre Grenzen. Der dritte Beitrag einer Serie von Franz-Joachim Kauffels beschäftigt sich im Detail mit dem "erfolgreichen" Simple Network Management Protokoll und TCP/IP.
Das Simple Network Management Protocol (SNMP), entstammt der TCP/IP-Protokollfamilie. Ursprünglich als einfache und schnelle Möglichkeit zur elementaren Leistungs- und Fehlerüberwachung bei Internetze konzipiert, hat es im letzten halben Jahr durch entsprechende Commitments großer Hersteller wie IBM, DEC oder Sun und eine Reihe von praktikablen, window-orientierten Netz- Management-Produkten Aufschwung genommen.
SNMP hat das Ziel, Netz-Managern einen zentralen Punkt zur Beobachtung, Kontrolle und Verwaltung ihrer Installationen zu geben. Es ist dabei zunächst völlig unabhängig von herstellergebundenen Konzepten. Auf SNMP basierende Produkte ermöglichen die Pflege komplexen Internetze und die Rekonfiguration eines weiten Spektrums von Geräten im Netz vom Router bis zur Workstation in Abhängigkeit von aktuellen Bedürfnissen. Diese Produkte, die von einer großen Anzahl von Herstellern angekündigt und teilweise schon ausgeliefert wurden, beruhen auf leistungsfähigen Workstations mit grafischem Benutzer-Interface. Der Netz-Manager kann dadurch das Netz kontrollieren und Schwachstellen ausfindig machen, im Idealfall bevor es zu Fehlern kommt. Wesentlich ist auch, daß nur noch eine zentrale Workstation benutzt werden muß und nicht weithin verstreute Gerätschaften.
SNMP ist für den Einsatz im Rahmen der verteilten Datenverarbeitung mit PCs, Workstations, Minis und Großrechnern in der kommerziellen Büroumgebung und Verwaltung gedacht. In den Staaten setzt es sich erheblich gegenüber herstellerabhängigen Programmen zur Verwaltung einzelner LANs, Bridges, Router oder Server durch.
Das Verhältnis zwischen SNMP und CMIP, dem Informationsprotokoll im Rahmen von OSI/OSI, läßt sich grob bestimmen in der Analogie des Verhältnisses zwischen TCP/IP und ISO/OSI: eigentlich möchte man Kommunikation zwischen heterogenen Einrichtungen auf Basis von OSI-Standards, installiert aber zunächst TCP/IP, weil es kompakter, einfacher, billiger und in höherem Maße verfügbar ist, ohne auf unmittelbar benötigte Leistungsmerkmale zu verzichten.
Gleichermaßen ist das Verhältnis zwischen SNMP und Netview zu sehen: Netview ist ein Instrument zum Netzwerk-Management in im wesentlichen geschlossenen SNA-Umgebungen. SNMP steuert offene TCP/IP Internets. Offensichtlich gibt es Berührungspunkte zwischen SNMP- und Netview-"Domänen". Wesentlich ist also, daß beide Management-Systeme wichtige Informationen voneinander erhalten um die Isolation da zu überbrücken, wo es zweckmäßig ist.
Das SNMP-Protokoll selbst ist nur ein Aspekt einer kompletten Management-Struktur, deren andere Teile die Management-Informations-Basis (MIB) und die Structure of Management Information, die SMI-Spezifikationen bilden. Die MIB ist eine Ansammlung von Objekten, die Geräte im Netz und deren interne Komponenten abstrakt repräsentieren. SMI enthält eine Menge von Regeln zur Definition der Charakteristika von Netzwerk-Objekten und ein Regelwerk, wie Management-Protokolle Informationen über diese Objekte beschaffen.
Die Netzwerk Management-Station NMS ist eine zentrale Komponente, üblicherweise eine Workstation, die dem Administrator einen Überblick über den Zustand des Netzes verschafft und ihm Möglichkeiten zum Eingriff gibt. In den einzelnen Netz-Geräten residieren sogenannte AGENTs, kleine Programme für die Ausführung der wichtigsten Management-Funktionen, wie zum Beispiel die Aufnahme von Zustandswerten vor Ort.
SNMP koordiniert Arbeit zwischen NMS und AGENTs
SNMP ist im engeren Sinne das Protokoll zur Zusammenarbeit zwischen AGENTs und NMS. Alle SNMP-Systeme benutzen dabei sowohl das verbindungslose UDP-Protokoll als auch das verbindungsorientierte TCP für den Nachrichtenaustausch. Die Management-Software in der NMS überwacht und kontrolliert Geräte durch Abfrage von Werten, die die AGENTs zusammenstellen. Die wichtigste Aufgabe eines AGENT-Programmes ist das Bereithalten von Informationen über die Objekte, die den kritischen Teilen und Aktionen des vom AGENT betreuten Gerätes entsprechen, wie zum Beispiel den Zustand einer Token-Ring-Karte oder die Anzahl von Kollisionen im Ethernet über eine gewisse Zeitspanne. Die AGENTs speichern diese Informationen und geben sie auf Anfrage an ein Management-Programm ab. Unaufgeforderte Meldungen werden von den AGENTs nur im Rahmen kritischer Bedingungen, außergewöhnlicher Fehler und Stromversorgungsausfällen erzeugt.
Die SMI-Spezifikationen sind Regeln darüber, wie Netzwerk-Variablen oder Objekte für die Benutzung durch das Netzwerk-Management-Protokoll definiert sein müssen, wie das Protokoll auf die Objekte zugreift und wie Objekte in die MIB eingebracht werden. Zur Beschreibung der Datenformate für Objekte, die einem "Objekt-Informations-Modell" entsprechen, wird die OSI Beschreibungssprache ASN.1 verwandt.
Um zukünftige Erweiterungen neben bestehenden Objekten und Funktionen zu ermöglichen, gibt es in der SMI vier Objektklassen: Verzeichnis-, Management-, experimentelle sowie private Objekte.
Die SNMP-MIB ist eine datenbankähnliche Ansammlung von Objekten in den AGENTs, die von der Management-Workstation aus beobachtet und kontrolliert werden können. Die MIB ist also verteilt. Diese Objekte sind meist statistischer Natur: Zähler für gesendete Pakete, benutzte Verbindungen, Versuche des Verbindungsaufbaus, Anzahl fehlerhafter Pakete, Anzahl von Kollisionen in einem LAN-Segment.
Die MIB definiert 126 Objektgruppen, die zum Teil permanent oder temporär obligatorisch sind. Die Objekte selbst werden hierarchisch organisiert, die gleiche numerische Identifikation darf natürlich nicht an mehrere Objekte vergeben werden. Die individuellen Objekte selbst stellen die unterste Hierarchiestufe dar. Die höchste Stufe sind Tafeln, die aus Einträgen zusammengesetzt sind.
SNMP überwacht das Netz durch Anpollen der Geräte
In einer SNMP-Implementierung arbeitet der NMS Manager Code auf einer Management-Konsole. Von dem zentralen Punkt der Workstation aus vollziehen die Netz-Manager ihre Beobachtungs-, Überwachungs-, Steuerungs- und Installationsfunktionen.
Die Beobachtung des Netzes geschieht bei SNMP durch Anpollen der Geräte, wobei kontinuierlich aus den AGENTs Informationen geholt und in der NSD-Datenbank zu Korrelations- und Planungszwecken gesammelt werden. Der Netzadministrator kann die Polling-Rate bestimmen. Die AGENTs antworten auf die Polling-Anfragen und verbrauchen dabei auch unmittelbar ihre gesammelten Daten, so daß der durch sie in den Geräten belegte Speicherplatz gering bleibt.
OSI-Protokoll läßt Platz für die TRAP-Definition
Wenn ein Gerät nicht mehr funktioniert und nicht mehr erreichbar ist, tritt eine Alarmbedingung oder "trap" auf. Es gibt fünf wichtige Ereignisse, die zu einer Trap führen: Ausfall einer Verbindung, Neustart einer Verbindung, Initialisierung eines AGENTs, Neustart eines AGENTs und Fehler bei der Authentifikation, wenn ein unberechtigter Benutzer ohne entsprechende Authorisierung versucht, Zugang zu einem AGENT zu bekommen. SNMP erlaubt den Herstellern, weitere Trap-Bedingungen zu definieren. Dies könnten Ereignisse im Rahmen der Benutzung von X.25, Decnet oder 802.1-Protokollen sein.
Das Polling mit Traps ist die Methode von SNMP, Fehlerquellen zu isolieren. Die Methode ist sehr effektiv und schnell. Die Daten, die im Rahmen des Polling gesammelt werden oder die Reaktion auf bestimmte Ereignisse können Netz-Manager dazu anregen, bestimmte Parameter im Netz zu verändern. Parameteränderungen werden prinzipiell auf der Basis des SET-Kommandos ausgeführt, die es in Analogie zu den GET-Kommandos ermöglichen, Variablen in den Tabellen zu setzen. Wird zum Beispiel eine Adreßduplizierung als Fehlerquelle beim Routing ausgemacht, so muß diese Fehlerquelle durch Angabe einer oder mehrerer neuer Adressen beseitigt werden.
Die gesammelten Daten sind ferner dazu verwendbar, langfristige Planungsaufgaben zu unterstützen. Hier können die Hersteller ihren Kunden weitergehende Planungshilfen an die Hand geben, die derartige Daten mitverwenden. Letztlich sind auch KI-Programme denkbar, die sich auf Basis der NSD-Daten, bereits gemachter "Erfahrungen" und Regeln merken und dem Netz-Manager Vorschläge unterbreiten. Dies wird besonders bei größeren Netzen von Interesse sein.
Typischerweise erstellt ein Anbieter zunächst SNMP-AGENT-Software für seine Produkte und entwickelt später ein NMS-Produkt. Viele Hersteller wählen die ersten funktionsfähigen AGENT-SW-Codes von MIT, Carnegie Mellon oder Net-Labs als Basis. Manche OEM-Produkte wurden für spezielle Umgebungen, wie zum Beispiel Unix, gemacht. Andere, wie das SNMP Release 2 von Epilogue oder das XNetmon von SNMP Research wurden portiert und können in unterschiedlichsten Umgebungen, wie SUN-OS, DEC VAX VMS, IBM AIX, das oder XENIX laufen. Sie sind meistens in C geschrieben. Diese Produkte werden oft durch eine Reihe von Utilities angereichert, wie zum Beispiel einen MIB-Compiler, der aus herstellerspezifischen Daten SNMP-MIB-Daten erzeugt. Dadurch können zeitraubende und fehlerträchtige Handkonversionen entfallen.
Die Basisfunktionen von SNMP können auf vielfältige Weise für den Benutzer veredelt werden. Einfache Systeme bieten nur die Netzbeobachtung und die Isolation von Fehlern. Komplexere Implementierungen ermöglichen darüber hinaus Leistungs- und Konfigurations-Management. Analoges gilt für die Benutzeroberflächen: Einfache Oberflächen können zeichenbasiert sein, komfortable Oberflächen arbeiten mit Fenstertechnik und farbigen Darstellungen des Netzes, die in Stufen gezoomt werden können. Alarme und Problemstellen werden optisch hervorgehoben.
Wie stehen nun große DV-Hersteller, die in vielen Fällen schon ein anderes Netz-Management-Konzept für die eigene, relativ homogene Welt haben, zu SNMP ? Die Antwort auf diese Frage ist sicherlich der entscheidende Schlüssel zu Erfolg oder Mißerfolg dieser Protokollgruppe.
IBM, DEC, HP und Sun haben angekündigt, sowohl SNMP als auch OSI CMIP in ihren Netz-Management-Systemen zu unterstützen. Alle vier haben eigene Systeme, die in ihren Fähigkeiten wesentlich mächtiger als SNMP sind. jeder Hersteller sieh jedoch die Notwendigkeit ein, Standards zu unterstützen, die es den Kunden erlauben, einen weiten Bereich von Geräten unterschiedlicher Hersteller zu benutzen und zu steuern.
IBM hat für OS/2 Extended Edition 1.2 TCP/IP komplett mit einem SNMP AGENT angekündigt. Diese Implementierung erlaubt die Kommunikation von OS/2-Servern mit einem SNMP NMS. Der Netzwerk Manager bekommt von der AGENT MIB Informationen wie eine Fehlerstatistik oder Paketzähler. In naher Zukunft wird IBM das Hostbasierte Netview-Management-System um die Fähigkeit erweitern, TCP/IP SNMP und OSICMIP-Knoten zu kontrollieren. Dies ist auch als Reaktion auf die schwächliche Akzeptanz von Netview/PC zu verstehen. Die AGENT-Software enthält keine IBM-spezifischen MIB-Erweiterungen. Sie unterstützt die SNMP GET-Funktion, die es so einem OS/2-Client erlaubt, andere SNMP-AGENTs nach ihren MIB-Daten zu fragen. IBM unterstützt jedoch nicht die SET-Funktion. 3Com und Novell haben beide angekündigt, ihren Servern und Internetz-Einheiten (Gateways, Bridges) SNMP-AGENT-Fähigkeiten zu verleihen, wollen die SNMP-Fähigkeit aber nicht auf die Workstations bringen. Banyan zögert noch.
Fazit: SNMP hat gezeigt, wie schnell es von der Definition eines Standards bis zur Realisierung gehen kann, wenn alle an einem Strang ziehen. So ist auch Aufstieg und Fall von OSI-Standards abhängig vom Umfeld und dem Willen der Hersteller. Diese können sich jedoch OSI nicht länger verschließen. Es wird wie bei funktionalen Standards auch zu einer friedlichen Koexistenz herstellergebundener und offener Konzepte kommen, denn die Steuerung eines Terminalnetzes mit OSI ist genauso unzweckmäßig wie die Steuerung einer offenen, heterogenen verteilten Systemumgebung mit Netview.