Vielerorts ist die Einstellung verbreitet, Netzwerk-Management sei eigentlich nur eine laestige Einschraenkung des offenen Informationsaustauschs. Erst wenn das Netz aufgrund unerklaerlicher Stoerungen wiederholt stillsteht, erkennen viele die Notwendigkeit, die Netzparameter staendig zu ueberwachen und notfalls fruehzeitig steuernd einzugreifen.

Netzadministratoren sehen zwar zunehmend den Bedarf nach entsprechenden Tools, aus Budgetgruenden werden aber oft im Zweifelsfall dringend benoetigte Anschaffungen dem eher langfristig und verhuetend wirkenden Management-Werkzeug vorgezogen. Wie bei allen Sicherheitsvorkehrungen wirkt auch hier der vorbeugende Effekt eher hinderlich, denn ausgebliebene Katastrophen lassen sich gegenueber der Geschaeftsfuehrung schlecht als Argument heranziehen.

Wenngleich vorrangig grosse Netze eines effektiven Netzwerk- Managements beduerfen, so sind doch auch kleine und mittelgrosse fuer zunaechst unerklaerliche Phaenomene anfaellig, die oft unterhalb der Anwendungsebene auftreten. Haeufig behelfen sich die Netzverantwortlichen dann mit dem Rebooten der Systeme oder isolieren sukzessive einzelne Systeme aus dem Netz, um den Stoerenfried zu lokalisieren. Schon bei zehn Knoten kann dieses Verfahren ein Netz nahezu einen Tag lang lahmlegen. Folge: Egal ob DOS oder Unix, Netware oder TCP/IP, Mini oder Mainframe - jeder, der mehr als zwei unabhaengige Rechner ueber ein Netz koppelt, benoetigt Werkzeuge, um die unsichtbaren Ablaeufe innerhalb des Netzwerkes zu ueberwachen und gegebenenfalls zu steuern.

Im Laufe der Jahre haben sich vor allem zu proprietaeren Netzen wie SNA oder Decnet Problemprofile herausgebildet, die solide Erfahrungswerte fuer ein Netzwerk-Management liefern. Vergleichbare Informationen gibt es zu OSI-Netzen mangels Masse bisher nicht zu verzeichnen. TCP/IP-Netze weisen dagegen den inhaerenten Nachteil auf, dass dank ihrer eigentlich wuenschenswerten Offenheit jeder Hersteller Komponenten erweitern, verbessern oder neu entwickeln kann. Schwierigkeiten zeigen sich dann nicht bei der Connectivity, also bei den Grundfunktionen, sondern oft erst im Detail oder unter aussergewoehnlichen Bedingungen bezueglich Last, Zeitverhalten oder Sicherheit. Gerade hier kann ein Management- System als uebergreifende Instanz helfen.

Im Rahmen der Normungsaktivitaeten auf dem Gebiet der Open Systems Interconnection hat man sich in den letzten Jahren verstaerkt mit der Ueberwachung und Steuerung von Rechnernetzen beschaeftigt. Begriffe wie CMIP, CMIS und MIB spielen hierbei eine wichtige Rolle. Parallel dazu stieg aufgrund des ungebrochenen Erfolgs der TCP/IP-Protokolle der Bedarf an Methoden zur Verwaltung der rasch wachsenden TCP/IP-Netze. Vor allem die Gateways, die Verbindungsstellen zwischen verschiedenen Netzen, erforderten wegen ihrer zentralen Bedeutung Ueberwachung und Steuerung. Daraus entstand Ende der 80er Jahre das Simple Network Management Protocol (SNMP).

SNMP bedient sich zur Identifikation und Ueberwachung von Netzwerkkomponenten der Management Information Base (MIB), einer als dekadischer Baum organisierten Struktur zur Darstellung beliebiger Netzwerkobjekte und -parameter. Gegenueber dem Common Management Information Protocol (CMIP) zeichnet es sich durch einfachere Implementation, weniger Speicher- und CPU-Bedarf sowie mit dem Internet durch eine vorhandene Testumgebung aus.

SNMP arbeitet nach dem Client-Server-Prinzip, bei dem die einzelnen Aufgaben eindeutig verteilt sind. Jeder Knoten in einem TCP/IP-Netzwerk verfuegt ueber einen SNMP-Agent. Dieser enthaelt die lokalen Netzwerkparameter gemaess MIB-Definition, zum Beispiel die IP-Adresse oder verschiedene Zaehler und Timer. Diese Daten haelt er laufend auf dem aktuellen Stand und stellt sie auf Abruf in entsprechenden Datenstrukturen bereit. Die Station fragt in bestimmten Intervallen die Parameter aller Agents ab (Pollingund uebergibt sie an die jeweiligen SNMP-Anwendungen zur Auswertung und Anzeige. Hierzu gehoeren grafische Darstellungen der Lastverteilung oder der zeitlichen Veraenderung verschiedener Parameter sowie Formulare und Editoren fuer die statischen Werte der einzelnen Netzwerkobjekte.

Die Netz-Management-Systeme der ersten Generation halten sich implementationstechnisch eng an das Prinzip von Agent und Station. Die Station ist einmal im Netz vorhanden und hat in der Art eines Netzwerk-Daemons alle Agents zu pollen und die Parameter einzusammeln. Anzeige und Basisauswertungen der Daten gehoeren zum Funktionsumfang der Station, wobei die Anzeige ueber entsprechende Window-Systeme erfolgt.

Der zentralistische Ansatz fuehrt in groesseren Netzen sehr schnell zu Mengenproblemen. Anzeige und Auswertung der Parameter von mehreren tausend Netzknoten erfordern eine entsprechend maechtige CPU mit gut ausgebauter Peripherie. Sollen fuer die lueckenlose Ueberwachung aller Knoten angemessene Polling-Intervalle eingehalten werden, so fuehrt dies ab einer bestimmten Netzgroesse zwangslaeufig zu Zeitengpaessen auf der Station. Weiterhin ist ein einzelner Netzoperator als Bediener der zentralen Station schnell durch die Menge der Daten und potentielle Probleme ueberfordert, ohne seinen Job sinnvoll mit einem zweiten Operator teilen zu koennen.

Diese Probleme koennen entweder durch Streckung der Polling- Intervalle oder durch weitere Kopien desselben Management-Systems umgangen werden. Im letzteren Fall arbeiten dann mehrere Ueberwachungssysteme unsynchronisiert auf Teilbereichen des Netzes, ohne die vorhandene maschinelle Redundanz effizient zu nutzen, von den Lizenzkosten ganz zu schweigen. Sollen kritische Knoten wie Bridges, Router oder Nodes mit Echtzeitaufgaben in besonders kurzen Intervallen abgefragt werden, so verschaerft sich das oben beschriebene Mengenproblem bis hin zu gravierend verminderten Reaktionszeiten.

Einige Anbieter, zum Beispiel Wollongong, haben diese Schwaechen bereits fruehzeitig erkannt und entsprechende Konsequenzen gezogen. Wollongong hat in seiner "Management Station" die Struktur aufgebrochen und die einzelnen Funktionen auf drei Ebenen verteilt. Die Agents selbst bleiben unveraendert. Die Station teilt sich bei dem verteilten Ansatz in sogenannte Network Management Daemonen und Benutzerprozesse auf. Der Daemon kann beliebig oft im Netz vertreten sein und entsprechend definierte Teilnetze ueberwachen, vorzugsweise Subnetze im Sinne des Internets. Die Benutzerprozesse, das heisst Anzeige und Auswertung, koennen ebenfalls mehrfach auftreten und auf einen oder mehrere Daemons zugreifen. Auf diese Weise sind verschiedene Operateure in der Lage, Teilnetze zu ueberwachen (siehe Abbildung 1).

Die verschiedenen Prozesse innerhalb des verteilten Systems stehen nicht beziehungslos nebeneinander, sondern kommunizieren ueber wohldefinierte Kommunikationspfade. Die Network Daemons sammeln die Daten der Agents per SNMP ueber eine UDP-Verbindung. Dieses Datagramm-Protokoll (Universal Datagram Protocolsetzt auf IP auf und erlaubt einen flexiblen Datenaustausch ohne den Overhead fester Verbindungen. Wegen der hohen Sampling-Rate wirken sich sporadische Datenverluste nicht gravierend aus.

Die Kommunikation zwischen dem Daemon und den Benutzerprozessen erfolgt ueber feste TCP- und SNMP-Verbindungen, da hier keine zeitkritischen Randbedingungen vorliegen. Der Daemon muss lediglich die bereits vorverarbeiteten Daten der Agents an die Anzeigestation zwecks Darstellung beziehungsweise Weiterverarbeitung weiterreichen. Im Gegensatz zur Agent-Abfrage koennten sich Verluste aufgrund eines Datagramm-Protokolls angesichts der Datenkomprimierung auf dieser Stufe allerdings fatal auswirken.

Kommunikation zwischen den Daemons

Den konzeptionell weitestgehenden Schritt vollzog Wollongong mit dem Kommunikationskonzept zwischen den Netzwerk-Daemonen. Wie bereits gesagt, koennen beliebig viele Daemons im Netz laufen und dabei disjunkte oder ueberlappende Bereiche ueberwachen. Diese Daemons kommunizieren untereinander ueber SNMP und TCP, das bedeutet, es existieren zwischen allen Daemons feste Kommunikationspfade. Dabei muss ein Daemon natuerlich nicht mit jedem anderen eine TCP-Verbindung aufbauen, sondern es koennen im Minimalfall Verbindungen jeweils zwischen zwei benachbarten Daemons konfiguriert werden, so dass jeder seine unmittelbare Umgebung kennt.

Die Daemons tauschen ueber diese Verbindung weitestgehend konfigurierbare Informationen aus, bis hin zu periodischen Uebertragungen aller Daten aus dem Nachbarnetz. Aufgrund der TCP- Verbindungen kann ein Daemon den Ausfall eines Nachbarn unmittelbar feststellen und unverzueglich entsprechende Reaktionen ausloesen. Dieser Ansatz bietet ein Hoechstmass an Flexibilitaet bei gleichzeitig groesstmoeglicher Ueberwachungsgarantie (siehe Abbildung 2).

Die Vernetzung der Daemons birgt natuerlich auch inhaerente Probleme in sich. So koennen Endlosschleifen entstehen, das heisst, bestimmte Nachrichten landen wieder bei dem urspruenglichen Daemon und werden von diesem wie Neuigkeiten weitergereicht, was schnell zu einer Ueberflutung des Netzes mit redundanten Daten fuehrt. Diese Gefahr kann durch einen speziellen Daemon zur "Loop Detection" gebannt werden, der bei Auftreten einer Schleife automatisch gestartet wird, sie beseitigt und eigenstaendig nach weiteren Schleifen fahndet.

Die Daemons sind im wesentlichen fuer die Erkennung von Netzknoten, Behandlung von Alarmen und Traps sowie fuer Fehler- und Statusnotierung innerhalb ihres Bereiches zustaendig. Ein Daemon selektiert Netzknoten anhand einer Liste von IP-Adressen (zum Beispiel /etc/hosts) und fragt sie ueber SNMP-Pakete ab. Antwortet ein Knoten nicht innerhalb eines konfigurierbaren Zeitrahmens auf SNMP-Ebene, so generiert der Daemon automatisch eine ICMP-Anfrage, um zumindest die Existenz eines Geraetes festzustellen. Wie bereits gesagt, melden sich SNMP-Agents nur bei Traps per Interrupt bei dem Daemon. Dazu gehoeren neben Kalt- und Warmstarts sowie "Link Up/down" noch Authentisierungsfehler sowie der Verlust des Nachbarn mit dem Extended Gateway Protocol. Dies zeigt, welchen hohen Stellenwert man den Gateways innerhalb eines Netzes einraeumt. Im Falle eines Traps oder anderer Ausnahmesituationen lassen sich grundsaetzlich folgende Aktionen in beliebigen Kombinationen ausloesen:

- Alarmmeldung an den Bediener,

- Notieren des Ereignisses in einer Datei,

- Aufruf eines Unix-Kommandos,

- Uebergabe der Information an eine Datenbank sowie

- Weiterreichen der Meldung an einen anderen Management-Daemon.

Ein besonderes Problem stellen Engpassknoten wie Gateways oder Bridges dar. Fallen sie aus, sind normalerweise auch die dahinterliegenden Netze und Knoten nicht mehr erreichbar, was zu einer Flut von Fehlermeldungen analog zu den Folgefehlern frueherer Compiler fuehren kann. Um diese unsinnige Meldungsflut zu vermeiden, kann der Netzwerk-Manager Prioritaeten vergeben, die bei entsprechender Einstellung die niederwertigen Scheinfehler solcher nachgeschalteten Netzknoten auszublenden gestatten.

In grossen Netzen erlaubt die verteilte Struktur die sinnvolle Aufteilung der Last auf verschiedene Systeme, das heisst, statt besonders leistungsfaehige und damit kostspielige Workstations fuer das Netzwerk-Management abzustellen, lassen sich hierfuer mehrere preiswerte Unix-PCs einsetzen, die auf die Subnetze oder die einzelnen Bereiche eines Netzes verteilt werden. Waechst das Netz, so uebernimmt ein zusaetzliches System einen Teil der Aufgaben, ohne die Gesamtstruktur zu tangieren oder eine Umkonfiguration der anderen Daemons zu erfordern. Das letzte Argument leitet bereits zum Sicherheitsaspekt ueber. Verteilte Management-Systeme lassen den Ausfall einer Management-Station nicht mehr zum Alptraum werden. Die benachbarten Daemons uebernehmen automatisch in Sekundenschnelle die Aufgaben der ausgefallenen Station und ermoeglichen so dem Netz-Manager, die Situation in Ruhe und ohne hektische Notmanoever zu bereinigen.

Die komplexen und vielschichtigen Informationen eines Netzes erfordern eine grafische Darstellung, die nur mit zeitgemaessen Windowing-Systemen moeglich ist. Wie fast alle namhaften Systeme stuetzt sich auch die Management Station von Wollongong hierbei auf "X Window", kurz X11 genannt, das sich als der Standard fuer Workstations durchgesetzt hat. Oberhalb X11 lassen sich Window- Manager wie Motif oder Open Look einsetzen, ohne dass dies die Funktionalitaet beeintraechtigt. Das Netz ist in Form einer Map mit vielfaeltigen Symbolen fuer Kabel, Workstations, Bridges, Router und andere Knotentypen sowie Zooms in Subnetze darstellbar.

Eine Auto-Discovery-Funktion erkennt alle Knoten selbstaendig und legt sie mit einstellbaren Standard-Icons in einem Clipboard ab, von wo sie der Netz-Manager per Maus an die gewuenschte Position verlagern kann. Die Toolbox bietet eine Reihe von Funktionen zur Anzeige, Bearbeitung und Auswertung von beliebigen (Sub-)Maps und stellt fuer den Benutzer den Kern der Benutzeroberflaeche dar. Mit ihr laesst sich die Praesentation komplexer Netze beliebig variieren und optimal konfigurieren.

Deutliche Fortschritte in den naechsten Jahren

Die Management Station notiert alle wichtigen Ereignisse in einer Datei. Bei grossen Netzen lassen sich solche Dateien jedoch nur noch schwer interpretieren. Hier bieten relationale Datenbanken weit bessere Auswertungsmoeglichkeiten. Aus diesem Grund stellt die Station von Wollongong im Konfigurations-Manager Schnittstellen zu Oracle, Ingres und Sybase zur Verfuegung. Damit kann selbst der Netzadministrator maechtige SQL-Programme fuer die Auswertung des Netzverhaltens schnell und elegant erstellen.

Fazit: Das Netz-Management von LANs befindet sich noch weitgehend im Anfangsstadium. Daher sind in den naechsten Jahren noch deutliche Fortschritte zu erwarten. Die dringendsten Aufgaben liegen im Bereich Sicherheit mit einer hieb- und stichfesten Implementation von Autorisierung und Authentisierung sowie in der Integration fremder Protokollsysteme wie Novell Netware oder Decnet. Es ist sogar anzunehmen, dass diese beiden Netzwerkkonzepte eher in vorhandene SNMP-Systeme aufgenommen werden als die OSI- Protokolle. Schliesslich sind sie schon jetzt haeufig installiert, waehrend OSI immer noch auf den Durchbruch beim Anwender wartet.

*Frank Raudszus ist bei der Danet GmbH, Beratung und Softwareentwicklung, in Darmstadt taetig.

Abb. 1: Verteilter Management-Ansatz der "Management Station"

Abb. 2: Kommunikation im verteilten Modell