Mit zunehmender Dezentralisierung der IT-Infrastruktur und der Komplexität der Applikationen ist eine Entwicklung eingetreten, der auch Überwachungs-, Analyse- und Statistikwerkzeuge folgen müssen, denn sie sollen Kommunikations- und Verarbeitungsprozesse und damit Geschäftsabläufe im Netz sichern. Insbesondere Netzwerkanalyse- und Remote-Monitoring-(RMON-)Systeme konkurrieren um diese Aufgaben, wobei sogenannte RMON-2-Systeme mit zusätzlicher Ebenenintelligenz und Analysefähigkeiten künftig in die Domäne der Lösungen zur Netzwerkanalyse einbrechen könnten.
Doch bevor sich der Anwender mit dem Angebot an RMON-Systemen und gegebenenfalls Netzwerkanalysatoren auseinandersetzt, sollte er sich über den tatsächlichen Bedarf an Überwachung, Analyse und statistischen Auswertungen im Unternehmensnetz bewußt werden. Michael Schmidt, Geschäftsführer der Cornet Gesellschaft für Kommunikations-Dienstleistungen mbH in Idstein, zweifelt nicht daran, daß der Bedarf an Zusatzwerkzeugen in aktuellen Netzen nicht so hoch ist, wie viele Hersteller und Anbieter es ihren potentiellen Kunden gern glauben machen wollen: "Zwar sollten Verkehrszahlen in allen Teilen des Netzes regelmäßig geprüft werden, aber dazu muß der Administrator nicht zwangsläufig auf RMON-Systeme oder Netzwerkanalysatoren zurückgreifen."
Die meisten Kopplungssysteme stellen dem Administrator standardmäßig ein Mindestmaß an Informationen zur Verfügung. Dazu gehören etwa kritische Daten zur Auslastung und zusammengefaßte Fehlerraten. Diese Informationen reichen meist zu einer grundsätzlichen Beurteilung aus. Erst wenn bei diesen ständig mitlaufenden Routinestatistiken Unregelmäßigkeiten oder stark zunehmende Lastveränderungen erkannt werden, seien weiterführende Analysen notwendig, so Schmidt. Ähnlich bewertet er den Analyse- und Statistikbedarf im Kern-Netzbereich, wobei Standardroutinen hier häufiger durchgeführt werden sollten.
Anders sieht er dagegen die Ausgangssituation in Netzen, die für das Unternehmen kritisch sind, in denen oft Designveränderungen stattfinden, Mitarbeiter häufig umziehen oder Release-Wechsel vorgenommen werden.
"Hier sollte beispielsweise halbjährlich oder jährlich eine Netzüberprüfung erfolgen. Diese Audits müssen auch eine Analyse etwa der verwendeten Protokolle, der Netzlasten und der Routing-Algorithmen einbeziehen", lautet die Einschätzung des Cornet-Managers.
Analyse- und Statistikbedarf konstatiert Martin Domian, Consultant bei der Eutelis Consult Beratungsgesellschaft für Telekommunikation und Mehrwertdienste mbH in Ratingen, auch an der Weitverkehrs-Schnittstelle: "Die zunehmende Abhängigkeit vieler Geschäftsprozesse von Weitverkehrsverbindungen erfordert Werkzeuge an dieser Schnittstelle, um Licht ins Dunkel der Kommunikationsbeziehungen zu bringen." Zu den anfallenden Maßnahmen zählt er etwa Verkehrsanalysen, um die Auslastung insgesamt und gesondert nach Protokollen nachzuvollziehen. Die Ergebnisse können dann zu einer sichereren und wirtschaftlicheren Nutzung der teuren Weitverkehrsverbindung beitragen. Domian empfiehlt sogar, den Kommunikationsverkehr an den Weitverkehrs-Schnittstellen permanent zu registrieren und zu analysieren, um so unter anderem unerlaubte Zugriffe auf das lokale Netz aufzudecken.
Also längst nicht in allen Netzbereichen, sondern nur dort, wo die Sensibilität des Netzes es erfordert, muß sich der Anwender Gedanken über den Einsatz von Überwachungs-, Analyse- und Statistikwerkzeugen machen. Hier hat er die Qual der Wahl. Er kann den RMON-Systemofferten der Hersteller und Anbieter folgen oder auf die Funktionalität des klassischen Netzwerkanalysators zurückgreifen.
Vor allem seit Hersteller und Anbieter mit RMON-2-Produkten locken, beginnen sich die Grenzen zwischen RMON- und klassischen Netzwerkanalysatoren zu verwischen. Warten doch diese RMON-Systeme zunehmend mit statistischen Möglichkeiten und Überwachungsfunktionen auf höheren Netzebenen auf. Außerdem integrieren sie sogar einige Analysefähigkeiten. "Neben TCP/IP werden oft alle verbreiteten LAN-Protokolle abgedeckt", gibt Michael Rudolphi, Associate Partner bei der Andersen Consulting GmbH in Sulzbach bei Frankfurt, den Entwicklungstrend bei RMON wieder. "Anbieterspezifische Architekturen beziehen darüber hinaus neben Ethernet und Token Ring auch Fast Ethernet, FDDI und ATM in die Überwachung, statistischen Auswertungen und Analysen ein."
Rudolphi geht davon aus, daß RMON-Systeme so allmählich die Intelligenz von Netzwerkanalysatoren erreichen werden. "Allmählich", wie er betont, "denn die Diversität und Komplexität der aus den Datenrahmen auszulesenden Informationen stellen von Stufe zu Stufe höhere Anforderungen an das RMON-Werkzeug." Nicht von ungefähr seien für die Anwendungsebene (Schicht 7 des OSI-Modells) selbst bei den proprietären RMON-Lösungen erst wenige Werkzeuge verfügbar.
Damit spricht er indirekt ein wesentliches Manko der RMON-2-Systeme an: Sie tragen bis heute einen herstellerspezifischen Systemstempel, weil ein RMON-2-Standard trotz mehrfacher Ankündigung (die erste erfolgte bereits Ende 1995) bis heute nicht verabschiedet wurde. Derzeit wird der Sommer dieses Jahres als möglicher Verabschiedungstermin anvisiert. Bis für den Anwender letztendlich verläßliche Entwicklungsnormen vorliegen, können die Anbieter ihren Kunden jedoch nur mit proprietären RMON-Variablen aus der Private Management Information Base (MIB) des Simple Network Management Protocol (SNMP) dienen, wo jeder Hersteller seine eigene spezifische RMON-MIB kreieren kann. Hier ist er an keinerlei Vorgaben gebunden. Eine Ausgangssituation, die ein Zusammenspiel zwischen RMON-Console-Software und RMON-Agenten unterschiedlicher Anbieter schwierig macht und zudem eine Integration dieser Systeme unter eine Management-Plattform beträchtlich erschwert.
In dieser Situation rät Behrooz Moayeri, Leiter Netzwerkkonzipierung bei der Comconsult Beratung und Planung GmbH in Aachen, den Unternehmen, abzuwarten: "Bereits die Erfahrungen mit dem aktuellen RMON-1-Standard haben gezeigt, wie lang der Weg sein kann, bis die Hersteller endlich zu einem allgemeinverbindlichen Standard finden. Selbst wenn der RMON-2-Standard nach vielfachen Ankündigungen Mitte dieses Jahres wirklich verabschiedet werden sollte, wird es bestimmt noch Monate, wenn nicht Jahre dauern, bis die Hersteller mit einer standardkonformen Implementierung von RMON-2-Systemen folgen werden." Moayeri empfiehlt seinen Kunden daher, grundsätzlich auf standardbasierte Lösungen zu setzen und proprietäre Produkte zu meiden. Letztere machen Anwender meist vom Hersteller abhängig. In die gleiche Kerbe schlägt Cornet-Manager Schmidt. Auch er rät den Anwendern, den standardkonformen Weg nicht zu verlassen. "Standards bedeuten einen hohen Grad an Investitionssicherheit und Herstellerunabhängigkeit. Wichtig ist nicht nur, ein geeignetes Überwachungs- und Analysewerkzeug zu finden, sondern vor allem auch die Integration der Lösungen mit anderen Managementwerkzeugen unter eine gemeinsame Management-Plattform."
Für Moayeri steht außer Zweifel, daß trotz intensiver Avancen der Hersteller Netzwerkanalysatoren immer noch die weitaus besseren Fehlersuchfunktionen als proprietäre RMON-2-Lösungen aufweisen. "Die Protokolldecodierungs-Mechanismen auf den höheren Netzschichten sind bei Analysatoren umfangreicher und einfacher in der Bedienung", lautet sein Urteil. Er ist sich deshalb sicher, daß RMON-2-Systeme in ihrer Leistungsfähigkeit auch nach der Verabschiedung des Standards bis auf weiteres nicht an die Decodierintelligenz herstellerunabhängiger Netzwerkanalysatoren heranreichen werden. Für die Zukunft zeichnet er daher folgendes Szenario: "Die RMON-Lösung eignet sich für die schnelle Reaktion und die erste Fehlereingrenzung. Den portablen Analysator mit seinen mächtigen Decodierfunktionen sollte man für den Fall hinzuziehen, wenn die erste Phase nicht zum Erfolg führt und sich die Fehlersituation als kompliziert herausstellt."
Ob proprietäre RMON-2-Lösung oder herstellerunabhängiger Netzwerkanalysator: Spätestens bei Switch-Installationen stoßen beide Werkzeuge auf ihre Grenzen. Hier stellt sich prinzipiell die Frage: Wo im Netz messen? Einen gemeinsamen Backbone, an dem sich alle Daten aufgreifen lassen, gibt es in diesem Fall nicht. Potentielle Fehler müssen statt dessen an den Anschlußpunkten der Server-Systeme nachvollzogen werden. "In dieser Situation hat der Netz-Manager nur die Möglichkeit, an ausgewählten Switchports den Verkehr nachzuvollziehen und zu analysieren", schildet Wolfgang Brinkmann, Geschäftsführer der WBN Netzwerkdienste im schwäbischen Pfullingen und Kenner der RMON- und Analysetechnik, die Schwierigkeiten. "Er läuft damit nur Gefahr, jeweils an den falschen Anschlüssen zu messen - besonders im Problemfall eine unglückliche Situation."
Damit werden auch die Ereignisse innerhalb virtueller LANs bis auf weiteres für den Anwender weitgehend im dunkeln bleiben. Erste herstellerspezifische Switch-Monitoring-(SMON-)Lösungen weisen in die richtige Richtung, da sie im Innern des Switch-Systems - am Bus oder an der Matrix - messen. Auf standardisierte Lösungen in diesem Umfeld werden die Unternehmen trotz allem noch lange warten müssen. Denn Switch-Installationen und virtuelle LANs werden im fernen RMON-3-Standard behandelt werden.
Angeklickt
Heutige RMON-Systeme warten mit immer ausgefeilteren Auswertungsmechanismen auf. Ursprünglich nur für das Sammeln von Daten konzipiert, tasten sie sich aufgrund ihrer statistischen Möglichkeiten und Überwachungsfunktionen in die Domäne der klassischen Netzwerkanalysatoren vor. Weil die aktuelle RMON-Version jedoch keine Zugriffsmöglichkeiten auf höhere OSI-Schichten hat, werden die Analysatoren eine wichtige Komponente bei der Überwachung des Netzes bleiben. Daran wird auch der RMON-2-Standard auf absehbarer Zeit nichts ändern.
Analysatoren
Obwohl RMON-Systeme mit dem kommenden RMON-2-Standard sukzessive an Ebenenintelligenz zulegen werden, sind portable Netzwerkanalysatoren bis auf weiteres nicht zu ersetzen. Denn sie verfügen über die ausgeprägtere Decodierintelligenz bis hinauf zu Protokollen auf Anwenderschicht. Auf über 200 Protokolle bringen es bereits die leistungsfähigsten Analysatoren im Markt. Ergänzt um Expertenfunktionalität, können einige von ihnen sogar bei vielen Netzproblemen automatisch vom Fehler auf mögliche Ursachen schließen und damit wirklich analysieren. Zudem warten Netzwerkanalysatoren im Vergleich zu RMON-Lösungen in der Regel mit der komfortableren und besser bedienbaren Oberfläche auf.
Auch Statistikfunktionalitäten haben Netzwerkanalysatoren zu bieten, die in ihrer Funktionalität aber nicht an die der RMON-Systeme heranreichen. Bleibt ein erhebliches Handikap: Leistungsfähige Netzwerkanalysatoren, die Protokolle auf allen sieben Netzebenen decodieren, sind teuer. Sie kosten zwischen 10000 Mark (Ethernet oder Token Ring) und 60000 Mark (ATM). Für einen Analysator mit FDDI-Schnittstelle muß der Anwender rund 30000 Mark ausgeben. Die Preise verstehen sich ohne Laptop.
Die RMON-Architektur
RMON-Systeme können schnell zu Durchsatzproblemen auf den Verbindungswegen zwischen den RMON-Agenten in den Netzkomponenten und der Konsole führen, weil in der Regel alle gesammelten Daten zur Konsole geschickt und erst dort in der RMON-MIB über die entsprechenden Gruppen ausgewertet werden. Mit RMON-2-Lösungen, die Protokolle und Ereignisse bis auf Ebene 7 registrieren werden, wird diese Netzlast noch immens wachsen. RMON-Agenten mit eigenem Prozessor, die eine Vorverarbeitung übernehmen und zudem die Daten vor dem Transfer komprimieren, werden diese Last nur teilweise verringern können. Sie sollten daher nur dort eingesetzt werden, wo sie notwendig sind. Zudem sollten die Erfassungsintervalle so groß wie möglich eingestellt werden.
Beim Verarbeitungskonzept sollte auf eine zentralistische Architektur zwischen Konsole und Agenten, eine flächendeckende Erhebung, ein standardisiertes Kommunikationsverfahren (SNMP) und eine allgemein zugängliche Auswertungsbasis geachtet werden. Eine derartige Struktur zahlt sich besonders in weit verteilten Netzen schnell aus. Denn Support vor Ort wird immer weniger durch das eigene Unternehmen geleistet werden können, und auch Serviceunternehmen sind nicht omnipräsent.
Der aktuelle RMON-Standard
Die derzeit vorliegende RMON-Spezifikation gewährleistet lediglich, daß Daten bis zur Zugangsschicht (Ebene 2) gesammelt und statistisch ausgewertet werden. Zudem lassen sich die in den Agenten erfaßten Informationen dazu nutzen, beim Über- beziehungsweise Unterschreiten definierter Schwellenwerte einen Alarm auszulösen. Auch bestimmte (Fehler-)Ereignisse lassen sich über ein Zählerfeld aufsummieren und ebenso Zugriffe von außen im Logbuch aufzeichnen. Zur Analyse sind RMON-Systeme jedoch nicht befähigt. Sie obliegt dem Administrator, der dazu in der Regel viele komplexe Tabellen sichten muß. Der standardkonforme Einsatz des RMON-Systems stößt zudem in LANs an seine Grenzen. Bisher wurde RMON nur für Ethernet und Token Ring definiert. Außerdem ist es allenfalls möglich, die Ethernet- oder Token-Ring-Gruppen beispielsweise für den Einsatz von RMON im FDDI-Umfeld zu nutzen - dabei gehen jedoch wesentliche Funktionen verloren. Ferner verlangt RMON ein TCP/IP-Netz als logische Netzwerkstruktur, die nicht überall implementiert ist.
*Rene Urs ist freier Journalist in Frankfurt am Main