"Der Anwender muß in der Lage sein, in einer spezifischen Protokollumgebung alle Protokollebenen zu erfassen und abzubilden - schon deshalb, weil sich die Vorgänge und Algorithmen in den seltensten Fällen auf wenige Protokollebenen beschränken", fordert Michael Schmidt, Geschäftsführer der Cornet Gesellschaft für Kommunikationsdienstleistungen mbH in Idstein. "Gerade die komplexeren unter ihnen - also die höheren Protokolle - sind diejenigen, die mit einer größeren Wahrscheinlichkeit schwer greifbare Auswirkungen auf das Netzwerk haben können."
Die bisherige Antwort der Hersteller: meist Teillösungen, die standardkonform nur die Überwachung und Verwaltung der Netzwerkkomponenten auf den unteren Ebenen abdecken. Der Grund dafür: Standards wie RMON (Remote Monitoring) und die SNMP-Standard-MIB (Management Information Base) reichen - bis auf wenige Ausnahmen - bisher mit ihrer Funktionalität nicht über die Ebene zwei beziehungsweise Ebene vier hinaus. Dort, wo die Hersteller Überwachungs- und Verwaltungsfunktionalität auf höheren Schichten abdecken, greifen sie sowohl bei RMON als auch beim klassischen SNMP-Management auf Extravariablen und -funktionen der herstellerspezifischen SNMP-Private-MIB zurück.
Die Folge für den Anwender: Solche Variablen und Funktionen sind meist nur auf die Komponenten der eigenen Systemwelt hin optimiert und werden auch weitgehend nur von diesen verstanden. Eine solche proprietäre Vorgehensweise fordert vom Anwender ihren Tribut, zumindest dann, wenn er sich bei der Produktauswahl nicht nur aus dem Portfolio eines Herstellers bedient.
Um Netzereignisse zentral an der Management-Konsole anzuzeigen, grafisch darzustellen und angemessen darauf zu reagieren, muß meist aufwendig programmiert werden. Und das macht die Integration unter Umständen um ein Vielfaches teurer als die Management-Komponenten selbst - ein Alptraum für den Netzwerkbetreiber.
Reicht in der Regel beim Sicherheits-, Konfigurations- und Abrechnungs-Management die Intelligenz der unteren drei Netzebenen noch aus, sorgt das Intelligenzdefizit speziell beim Performance- und Fehler-Management für erhebliche Überwachungs- und Verwaltungslücken. Denn hier sind Funktionalitäten über alle OSI-Schichten hinweg bis zur Anwendungsschicht gefordert. Das ist schmerzlich, da speziell mit Performance- und Fehler-Management die Weichen für wirtschaftliche und sichere Netzwerkabläufe im Unternehmen gestellt werden müßten.
Diese Lücke könnte sich mit der Verabschiedung des RMON-2-Standards zukünftig allmählich schließen. Das entsprechende Definitionspapier wird demnächst das Genehmigungsverfahren beim Standardisierungsgremium Inter-net Engineering Task Force (IETF) durchlaufen.
Jorge Encina, Projekt-Manager Netz-Management bei der Hewlett-Packard GmbH in Böblingen, sagt, wohin der Trend mit dem kommenden RMON-2-Standard geht: "RMON 2 wird es erlauben, auch Kommunikationsbeziehungen über Router hinweg zu identifizieren. Konkret wird es mit der neuen RMON-Version möglich sein, für alle Kommunikationsbeziehungen innerhalb eines Segments Statistiken auf Netzwerkebene zu erstellen - unabhängig davon, woher die Kommunikationsströme kommen oder wohin sie gehen oder mit welcher anderen Topologie dieses Segment kommuniziert. Mit RMON-2-basierenden Probes und Agents wird allen RMON-Gruppen die Netzebene bekanntgemacht und so Transparenz in die Ende-zu-Ende-Kommunikation über Protokolle wie IP, IPX, Decnet, Appletalk, Vines und OSI gebracht."
Selbst die Überwachung und die statistische Auswertungen auf Applikationsebene werden künftig mit dem RMON-2-Standard möglich sein. "RMON-Alarme, -Statistiken, -History und -Host-Conversation werden nützliche Werkzeuge sein, um auf der Anwendungsebene das Netzwerk zu überwachen und zu durchleuchten", so Encina weiter.
Doch diesem Anspruch an höherer Protokollintelligenz in den Systemen ist nicht einfach zu begegnen. "Die Vielfalt und Komplexität der aus den Datenrahmen auszulesenden Informationen stellen von Stufe zu Stufe höhere Anforderungen an das Management-Werkzeug", erläutert Michael Rudolphi, Associate Partner bei der Andersen Consulting GmbH in Eschborn. "Nicht von ungefähr sind für die Anwendungsebene Schicht sieben erst wenige proprietäre Überwachungs- und Verwaltungswerkzeuge verfügbar, so daß das Tracking der Anwendungen mit ihrem Netzverhalten noch eine offene Flanke des Netz-Managements ist."
Auch mit der verabschiedeten RMON-2-Norm wird es noch einige Zeit dauern, bis die Hersteller die neuen standardkonformen Variablen in die RMON-MIB ihrer Systeme implementiert haben, und noch länger, bis in aller Breite Protokolle der höheren Ebenen zum Standardrepertoire ihrer RMON-Systeme gehören werden.
Bis es soweit ist und RMON 2 allmählich die Protokolle höherer Ebenen erschließt, zählt für den Anwender, der auf die Sicherheit eines Standards setzen will, weiterhin die aktuelle RMON-1-Definition. Denn RMON-Variablen und -Funktionen, die über die Funktionalität der Ebene zwei hinausgehen, stehen bis dahin weiterhin in der herstellerspezifischen SNMP-Private-MIB, auch wenn die Anbieter sie durchweg bereits als RMON-2-Standard vermarkten.
"In dieser Situation gehen Produktanbieter mit proprietären Erweiterungen über den bestehenden RMON-Standard hinaus und rüsten ihr RMON-Werkzeug mit proprietären Variablen und Funktionen höherer Ebenen aus", beschreibt Rudolphi den aktuellen Herstelleransatz.
Wo sind die Grenzen des RMON-1-Standards?
"So werden neben TCP/IP oft bereits alle verbreiteten LAN-Protokolle abgedeckt und auch partiell die Funktionalitäten höherer Schichten bis hinauf zur Anwendungsebene erschlossen. So beziehen anbieterspezifische Architekturen wie das Enterprise-RMON-System von Frontier zusätzlich unter anderem virtuelle LANs, Fast Ethernet, FDDI und ATM in die Überwachung und Datenaufzeichnungen ein."
Für den Anwender indes zählt der aktuelle Stand der Normierung, und der heißt RMON 1, um die RMON-Funktionalität ohne zu großen Anpassungs- und Integrationsaufwand herstellerübergreifend einsetzen zu können. "Denn Standardisierung bedeutet einen hohen Grad an Investitionssicherung und Herstellerunabhängigkeit", so Cornet-Geschäftsführer Michael Schmidt.
Das ist noch nicht alles. "Letztlich geht es nicht nur um das geeignete Überwachungs- und das statistische Werkzeug fürs Netz, sondern vor allem um die Integration vieler anderer Management-Werkzeuge auf eine gemein- same Management-Plattform", so Schmidt weiter. "Denn wer wollte nicht, nachdem er Fehler oder ineffizient arbeitende Komponenten im Netz erkannt hat, beispielsweise über Geräte-Management regulierend von zentraler Stelle aus in das Netzgeschehen eingreifen?"
Deshalb ist es für den Anwender wichtig, die aktuellen Grenzen des bestehenden RMON-1-Standards zu kennen. Bisher sind lediglich RMON-Standards für Ethernet (neun Gruppen, RFC 1271) und Token Ring (elf Gruppen, RFC 1513) festgelegt. Es gibt zwar auch RMON-Lösungen für andere Techniken, beispielsweise FDDI und WAN-Verbindungen. Doch bewegen sich solche Lösungen aufgrund des fehlenden Standards ausschließlich auf proprietärem Terrain. Zudem wird dabei nur eine Teilfunktionalität erreicht.
Exakte Angaben sind unabdingbar
Das Beispiel FDDI macht es deutlich: Um Kenndaten auch im FDDI-Netz ermitteln und verarbeiten zu können, werden die RMON-Gruppendefinitionen aus der Ethernet- beziehungsweise Token-Ring-Welt übernommen und an die FDDI-Welt angepaßt. Freilich muß der Anwender dafür einen Nachteil in Kauf nehmen: So lassen sich weder die FDDI-spezifischen SMT-Daten (Station Management) noch die Inhalte, die in den FDDI-Paketen transportiert werden, erfassen und auswerten.
Last, but not least verlangt RMON gemäß dem aktuellen Standard ein TCP/IP-Netz als logische Netzwerkstruktur - ein logisches Netz, das zwar viele Unternehmen haben, aber längst nicht alle. Für Unsicherheit beim Anwender sorgt zudem die Tatsache, daß ein Hersteller seine Lösung bereits als RMON-System bezeichnen darf, wenn nur eine Gruppe von neun bei Ethernet und nur eine von elf bei Token Ring vollständig vertreten ist. Man sollte also beim Hersteller unbedingt auf exakte Angaben drängen.
Zudem lassen sich generell mit RMON-Systemen weder Lasten generieren noch Netzwerkabläufe simulieren, um Zusammenhänge zu testen. Auch stellt sich die Frage, ob das RMON-Konzept generell aufgeht, hohe Datenaufkommen der unterschiedlichen Netzebenen zentral zusammenzufassen, um sie hier zu verarbeiten und gegebenenfalls noch grafisch darzustellen. Denn die zyklische Abfrage der RMON-Agenten und RMON-Probes erzeugt auf den Netzverbindungen erhebliche Lasten, die auf Kosten des Nettodatendurchsatzes gehen.
Diese Frage wird sich in Zukunft um so deutlicher stellen, als die RMON-Überwachung und -Aufzeichnung mit Client-Server-Architekturen sowie komplexen Daten- und Programmbeziehungen sukzessive auf höhere Schichten ausgedehnt werden müssen, um Verarbeitungsabläufe insgesamt transparent zu machen und abzusichern. Denn mit jeder Netzebene, die zusätzlich mit RMON 2 einbezogen wird, wird auch die Datenlast auf den Netzverbindungen wachsen.
Nicht zu vergessen, daß RMON-Systeme weder mit RMON 1 noch mit RMON 2 Daten analysieren können, auch wenn die Hersteller dies immer wieder anklingen lassen. Die einzige Möglichkeit, Netzereignisse zu analysieren, besteht darin, zeitaufwendig in Statistiken zu recherchieren, um so vielleicht auf die Fehlerursache schließen zu können.
Insofern kann die Überlegung, die bestehenden Intelligenzlücken beim Performance- und Fehler-Management statt dessen mit der herstellerunabhängigen Netzanalyse zu schließen, durchaus lohnen, auch wenn Netzanalysatoren nicht den Vorteil einer integrierbaren SNMP-MIB zu bieten haben.
Kein Weg führt an der Netzwerkanalyse vorbeiDenn es steht außer Zweifel, daß die Möglichkeit leistungsfähiger Netzanalysatoren, Protokolle auf allen sieben Ebenen des Netzwerks nachzuvollziehen und dabei eine Vielzahl an LAN- und WAN-Techniken zu unterstützen, heute besser ausgeprägt ist als die selbst proprietärer RMON-Lösungen.
Besonders weit in der Funktionalität gehen Netzwerkanalyse-Systeme in Expertentechnik. Sie sind nicht nur in der Lage, Fehler, Kapazitätsengpässe und -vergeuder im Netz aufzudecken, sondern schließen zudem häufig automatisch auf die Fehlerursache und geben sogar Hinweise dazu, wie dem Netzproblem am besten begegnet wird.
"Ohne ein solches Werkzeug ist ein Fehler-Management äußerst schwierig", unterstreicht Dernbach von Arthur Andersen die Funktionsbreite von Netzwerk- analysatoren. "Wenn er fehlt, wird viel Zeit vergeudet, weil Mitarbeiter oft zu lange im dunkeln tappen und an der falschen Stelle nach den Problemen suchen." Besonders in komplexen Netzen mit verteilten Daten und Anwendungen führt laut Dernbach kein Weg an der Netzwerkanalyse vorbei.
Zudem stimmt die Verarbeitungsarchitektur der Netzwerkanalyse, wenn sie als Server-Lösung in den einzelnen Netzsegmenten eingesetzt wird. In diesem Fall werden die Daten nicht nur lokal erfaßt, sondern auch lokal verarbeitet.
Es werden also nur die reinen Ergebnisdaten über das Netz an die Zentrale übertragen - eine Verfahrensweise, die wenig Bandbreite braucht und besonders bei Weitverkehrsverbindungen Gebühren sparen hilft.
Daß ohne verteilte Analyse so manches Mal nichts mehr geht, macht Michael Rudolphi an einem Beispiel deutlich: "Stellt man sich einen global tätigen Bankkonzern mit Hauptsitz in Deutschland vor, wird für das US-Netz der Tochterbank bestimmt ein Netz-Manager vor Ort für sein Netzwerk verantwortlich sein. Denn wie sollte er Verantwortung tragen, wenn er keine Management-Konsole hätte, die den Status des US-Netzes umfassend darstellt. Umgekehrt wird sich der Netz-Manager, der für das internationale Netz zuständig ist, kaum für die Details des US-Netzes interessieren. Je nach Ausbreitung des Netzes wird die entsprechende Verantwortung immer mehr oder weniger stark geteilt sein müssen." Diese Dezentralisierung tut bei der verteilten Netzwerkanalyse nicht weh, eben weil die Auswertung - im Gegensatz zu RMON-Systemen - bereits lokal auf den Analyse-Servern stattfindet.
Zum Glück stellt sich die Frage RMON-System oder Netzwerkanalyse für den Anwender nicht. "RMON- und Netzwerkanalyse-Werkzeuge sind zwar auf den ersten Blick Konkurrenten im Markt", so Rudolphi. "Sie können sich jedoch nicht gegenseitig ersetzen, dafür aber wirkungsvoll ergänzen." Da hilft nur eins: entscheiden, wo die Netzwerkanalyse notwendig ist und wo statt dessen RMON-Werkzeuge zur Überwachung und Aufzeichnung des Verkehrs in den Segmenten ausreichen, um Verarbeitungs- sowie Kommunikationsprozesse insgesamt wirtschaftlicher zu gestalten und abzusichern.
Die Verteilung der Systeme wird je nach Sensibilität des Netzes in den einzelnen Unternehmen unterschiedlich ausfallen. Generell sollte man insbesondere im Backbone-Bereich und an der WAN-Schnittstelle auf eine profunde Netzwerkanalyse nicht verzichten. Unabdingbar ist diese darüber hinaus in besonders sensiblen Sektoren des Netzes, beispielsweise im Produktions- und produktionsnahen Bereich.
Als Faustregel gilt, zwei Drittel der Segmente mit RMON-Systemen und nur ein Drittel mit Netzwerkanalyse-Servern auszustatten, was rund viermal so teuer ist. Dann halten sich auch die Netz-Management-Kosten einigermaßen im Rahmen.
Zweifellos werden sich RMON-Systeme mit dem kommenden RMON-2-Standard nach und nach immer größere Netzbereiche erschließen. Denn auf eine lückenlose Überwachung und eine Transparenz über alle Netzebenen werden die Unternehmen mit jedem Schritt, den sie in die Client-Server-Welt machen, weniger verzichten können. Schon der günstige Preis dieser Technik wird ein Motor dieser Entwicklung sein. Was das Verarbeitungskonzept angeht - flächendeckende Erhebung sowie standardisiertes Kommunikationsverfahren (SNMP) und allgemein zugängliche Auswertungsbasis (RMON-MIB) -, wissen RMON-Systeme sowieso zu überzeugen. Damit lassen sich RMON-Systeme im Gegensatz zu Netzwerkanalysesystemen nahtlos in ein übergeordnetes Netz-Management integrieren. Fakten, die sich auch in den Marktzahlen von IDC widerspiegeln. Danach wurden 1995 mit RMON-Systemen weltweit 385 Millionen Dollar umgesetzt. Zur Jahrtausendwende sollen es laut IDC bereits 2,4 Milliarden Dollar sein.
Angeklickt
Vertrauen ist gut, Kontrolle ist besser. Nach diesem Motto handeln immer Netzadministratoren und haben deshalb ein starkes Interesse daran, ihre Netze auch in den höheren Protokollebenen genauer unter die Lupe zu nehmen. Bisher hieß es in diesem Punkt jedoch Fehlanzeige, weil die Standards RMON I (Remote Monitoring) und SNMP mit seiner Management Information Base (MIB) kaum über Ebene zwei hinausreichen. Abhilfe soll die Spezifikation RMON II schaffen, die in Kürze offiziell genehmigt wird. Dann werden Kommunikationsbeziehungen auch über Router hinweg zu identifizieren sein und können statistische Auswertungen auf Applikationsebene erfolgen.
*Hadi Stiel ist freier Journalist in Bad Camberg.