Die Netzwerkanalyse wird haeufig fehlinterpretiert. Manche verstehen darunter einfache Diagnosegeraete und Kabeltester, andere die Decodierung von Protokollen, wieder andere sprechen ihr Qualitaeten des Netzwerk-Managements zu. Frank Koelmel* gibt einen Ueberblick ueber aktuelle Moeglichkeiten und stellt das Konzept der Blackboard-Systeme vor.

Kaum ein anderer Bereich hat mit solcher Vehemenz die stuermische Netzwerkentwicklung nachvollzogen, ist mit den neuen, hoeheren Anforderungen gereift wie die Netzwerkanalyse - oft schneller, als der potentielle Anwender die Technologie nachvollziehen konnte. In der Zeit, in der vormals eingefuehrte Techniken sukzessive durch andere, wesentlich wirkungsvollere Grundtechniken abgeloest wurden, sind die Entwickler von Netzwerkanalysesystemen stets am Ball geblieben und haben ihren Loesungen immer neue Faehigkeiten verliehen.

Aufspueren von Fehlern auf untersten Ebenen

Mit dem Kabeltester, der noch heute zum unverzichtbaren Werkzeug bei der Installation von Datennetzen zaehlt, hat es begonnen. Mit ihm laesst sich die physikalische Unversehrtheit von Kabelstraengen pruefen. Dass der Fokus der Systemverantwortlichen vor zehn Jahren auf der Datenleitung lag, ist verstaendlich: Die verwendeten Netzwerkprotokolle waren alles andere als komplex und das Datenaufkommen verschwindend gering.

Der Netzwerkanalyse die Ebene-2-Protokollintelligenz zu verleihen und sie als leistungsfaehiges Ueberwachungs- und Statistikwerkzeug zu nutzen war der naechste Entwicklungsschritt. Mit dieser zusaetzlichen Systemintelligenz gewappnet, konnten vor allem die Paketzahl und -groesse sowie der Anteil einzelner Protokolle an den Kommunikationsprozessen genau betrachtet werden. So erschloss sich der Anwender beispielsweise die Moeglichkeit, Trends beim Datenaufkommen fruehzeitig zu erkennen und gegebenenfalls schnell mit einer Erweiterung oder Segmentierung des Netzwerks zu reagieren. Aber auch Kommunikationsprobleme liessen sich mit der neuen Ebene-2-Protokollintelligenz aufspueren. Folgendes Beispiel soll dies verdeutlichen:

Einzelne Benutzer staunten nicht schlecht, als sie kurz nach der Anmeldung beim SNA-Gateway keinen Zugang mehr zum IBM-Host erhielten. Was war passiert? Mit den 16 Sitzungen, die das SNA- Gateway gleichzeitig zulaesst, waren die Benutzer bislang noch gut bedient. Mit der starken Expansion des Netzes reichte die Sitzungskapazitaet fuer alle jedoch bald nicht mehr aus, und das SNA-Gateway nahm eine Station nach drei Minuten Inaktivitaet einfach vom Netz. Mit der Ebene-2-Statistik brachte die Netzwerkanalyse das Problem an den Tag: Vier Stationen belegten mit ihren Paketen den Grossteil der Verbindungskapazitaet zum und vom Host. Um den Rest mussten die anderen Stationen konkurrieren, wobei sich einigen in der Dreiminutenspanne gar keine Chance mehr bot, Verbindung zum Host aufzunehmen.

Bei der LAN-Technik Token Ring waren im Gegensatz zum Bus- orientierten Ethernet auf der Netzwerkebene zwei, genauer besehen auf der MAC-Teilebene (Medium Access Control), einige Ueberwachungsmechanismen implementiert worden, in die man sich nun mittels Tracetools wirkungsvoll einklinken konnte. Die softwarebasierte Netzwerkanalyse war geboren.

Fortan konnten die eingelesenen MAC-Rahmen nicht nur hinsichtlich ihrer Anzahl und Groesse ermittelt, sondern darueber hinaus dekodiert werden, und die Daten liessen sich in praegnanter Form darstellen.

Daraus entwickelten sich Protokollanalysesysteme fuer alle Topologien in unterschiedlichen Leistungsklassen. Auch die Protokollintelligenz wurde sukzessive erweitert und erstreckt sich bei einzelnen Anbietern wie Network General Corporation bereits auf alle sieben Ebenen des Netzwerks.

Nur dekodiert statt analysiert

Eine klare Zuordnung der Funktionalitaet war mit dem Begriff Netzwerkanalyse freilich immer noch nicht geschaffen worden - was nicht unbedingt zur Klarheit fuer den potentiellen Anwender beitrug. Protokolle lassen sich von Haus aus nur dekodieren, das heisst, der Inhalt der Datenrahmen kann in gut lesbarer Form am Bildschirm dargestellt werden, um so beispielsweise Falschbesetzungen und Bit-Drehern auf die Spur zu kommen. Die Analyse im Sinne der Bewertung von Datenstroemen, um daraus vielleicht direkt auf Verbindungs- und Sitzungsfehler zu schliessen, war mit diesen Systemen nicht moeglich. Die Auswertung musste Ende der 80er Jahre immer noch in zeitaufwendigen Prozeduren erfolgen. Wie dies in der Regel aussah und in vielen Faellen auch heute noch aussieht, skizziert folgendes Beispiel: Vom Problem im Netz erfuhr man nicht per System, sondern in der Regel per Telefonat, in dem ein betroffener Mitarbeiter das Kommunikationsproblem haeufig undeutlich und zudem ungehalten umriss. Also machte sich der Administrator mit seinem Netzwerkanalysesystem auf den Weg, um das Problem vor Ort zu loesen, in der Hoffung, dass sich der Fehler wiederholen wuerde, damit er ihm ueberhaupt auf die Spur kommen koennte. Ein schwieriges Unterfangen: In einem Ethernet-Segment mit einer Last von zehn Prozent werden an einem Tag ueber 10000000000 (in Worten: zehn Milliarden) Byte transportiert. Waehrend der Netzwerk-Manager die Fehlersituation nachzustellen versucht, schneidet sein Analysesystem gerade einmal 10 Megabyte an Daten mit - eine winzig kleine Probe selbst im Vergleich zum stuendlichen Datenaufkommen.

Doch nicht nur das Missverhaeltnis zwischen Datenaufkommen und Minimalprobe machte ihm zu schaffen. Zudem geriet der Spezialist in den Teufelskreis der Netzwerkanalyse: Wohl werden die Daten aller sieben Ebenen des OSI-Referenzmodells wunderbar am Bildschirm dargestellt, und wenn er will, kann er unter einer Vielzahl von Filtern waehlen, um bestimmte Problemkreise zu fokussieren. Doch hier beisst sich der Hund in den Schwanz: Um einen Filter gezielt auswaehlen zu koennen, muesste der Administrator das Problem bereits eingrenzen koennen, zumindest aber eine Ahnung vom Problemkreis haben. So jedoch gleicht das Aufspueren des Fehlers eher der Suche nach der beruehmten Stecknadel im Heuhaufen. Es koennen Stunden, manchmal sogar Tage vergehen, bis er der Sache endlich auf den Grund kommt.

Kommunikationsfluss zaeh im Leitungssystem

Besonders aergerlich ist das Ganze, wenn sich das Problem dann - wie meist - als aeusserst simpel entpuppt - wie im Fall eines mittelstaendischen Speditionsunternehmens:

Der Novell-Server war hier seit der Installation sechs Monate zuvor vollkommen problemlos gelaufen. Bis auf einmal der Kommunikationsfluss nur noch zaeh durch das Leitungssystem des Netzwerks lief. Der Durchsatz verschlechterte sich derart, dass die Frachten fuer die einzelnen Touren eines Tages nicht mehr rechtzeitig zusammengestellt werden konnten. Der Grund war banal: Irgend jemand hatte die Turbotaste am Server gedrueckt, der fortan einen forscheren Arbeitstakt vorlegte. Zu schnell fuer die alten PC/AT-Systeme, die nicht so flink wie der Server von Senden auf Empfangen umschalten koennen. Mit dem Wechsel auf die langsamere Server-Taktrate von 33 Megahertz war das Problem behoben. So banal der Grund auch war, fuer die Spedition zog dieser kleine Fauxpas immense Kosten nach sich. Zwei Tage lang konnten keine Auftraege mehr zusammengestellt werden, was ein Auftragsvolumen von ueber 75 000 Mark ausmachte.

Ein Einzelfall? Sicher nicht. Zudem werden die Netzwerke immer komplexer, was das Aufspueren von Fehlern zunehmend schwieriger gestaltet. Einen Ausfall von Kommunikationsverbindungen oder gar des gesamten Netzwerks koennen sich hingegen die wenigsten Unternehmen leisten, weil die Abhaengigkeit vom Netzwerk permanent groesser wird. Zu sehr ist dieses in alle Firmenbereiche vorgedrungen und hat dabei auch hochsensible Bereiche wie die Produktion und Disposition erreicht.

Fuer den Netzwerkadministrator wird die Situation doppelt brenzlig. Nicht nur, dass es fuer ihn immer schwieriger wird, den Fehler zu orten. Ihm bleibt dazu auch noch weniger Zeit. Erschwerend kommt hinzu, dass das Unternehmen seine Systeme in der Regel aus vielen Quellen bezieht - angefangen vom Verkabler und Netzwerkintegrator bis hin zum PC-Lieferanten und Softwarehaus -, was im Fehlerfall nicht unbedingt zu klareren Verhaeltnissen beitraegt. Im Falle eines Falles wird jeder Anbieter tendenziell auf die Komponente eines anderen Herstellers verweisen. In dieser Situation geraet der Netzwerkadministrator zusehends unter Beweisdruck.

Die Industrie hat auf die erhoehten Anforderungen reagiert und bietet mittlerweile Netzwerkanalysesysteme einer neuen Generation. An dieser Stelle allerdings gabelt sich der Weg.

Zu nennen waeren hier zwei Entwicklungsrichtungen: Es gibt Systeme, die auf Messungen ausgelegt sind, und solche, die zur Analyse von Produktionsnetzen dienen. Mit einem auf Messungen fokussierten System lassen sich Pakete auch im Bandbreitengrenzbereich exakt erfassen. Diese Systeme haben eine sehr aufwendige Hardwarestruktur und erlauben es meist, an mehreren Schnittstellen parallel zu messen - ein interessanter Leistungsvorzug, um Netzwerkkomponenten beispielsweise hinsichtlich des Durchsatzes und der Latenzzeit (Paketverweildauer im System) auszutesten.

Messen oder in Echtzeit analysieren?

Die Messgeraete sind mittlerweile sehr komfortabel. So kann man beispielsweise auf eine Vielzahl von Testroutinen zurueckgreifen oder Testszenarien bequem selbst entwickeln. Die Programmierung erfolgt meist in C- oder Pascal-aehnlichen Sprachen. Viele Standardtests wurden mittlerweile im Rahmen der IETF (Internet Engineering Task Force) entwickelt, beispielsweise Benchmark-Tests fuer Bruecken und Router. Federfuehrend ist hier Scott Bradner von der Harvard-Universitaet, der regelmaessig und unabhaengig die Leistungsfaehigkeit von Router-Systemen sowie anderen Netzwerkkomponenten prueft. Die Resultate werden weltweit publiziert und via Internet zur Verfuegung gestellt.

Ueber alle sieben Ebenen hinweg automatisch

Fuer seine Tests im Ethernet- und Ethernet/FDDI-Bereich nutzt Bradner das Testsystem Power-Bits von Alantec. Dieses ermoeglicht es ihm, bis zu sechs Ethernet-Datenstroeme gleichzeitig zu messen.

Testbeispiel: Beim Test eines Routers oder einer Bruecke werden Daten zu der Komponente geschickt und auf der "anderen" Seite wieder vom Testsystem gelesen. Anschliessend wird statistisch ermittelt, ob alle gesendeten Pakete auch weitergeschickt wurden (interessant unter Vollast). Eine weitere Frage ist es, wie lange die Verarbeitung eines Pakets dauert - wichtig besonders fuer zeitkritische Applikationen. Will man zu aussagefaehigen Testwerten gelangen, reichen Zwei-Port-Messsysteme nicht aus. Es muessen dann wesentlich mehr als nur zwei Datenstroeme parallel gemessen werden. Nur so kann das Testsystem wirklich ausgelastet werden. Mit dem Power-Bits-Tester von Alantec lassen sich zwei, vier oder sechs Datenstroeme parallel messen - in der Maximalkonfiguration also zwoelf Anschluesse. Zusaetzlich kann noch ein FDDI-Strom in die Messungen einbezogen werden. Da solch ein Testszenario fuer die heutigen High-end-Systeme dennoch nicht ausreicht, wird man mit dem naechsten Software-Release mehrere Power-Bits-Systeme parallel synchronisieren und einsetzen koennen. Dann sind auch grosse Backbone-Loesungen austestbar. Der Testaufbau kann dann aussehen wie in Abbildung 1.

Der Experte im System denkt mit

Mit auf die Analyse von Produktionsnetzen ausgerichteten Systemen ist es moeglich, den gesamten Netzwerkverkehr ueber alle sieben Ebenen des Netzwerks hinweg automatisch und in Echtzeit auszuwerten. Diese Loesungen sind vorrangig in Software realisiert. Doch Vorsicht - nicht jedes Expertensystem analysiert in Echtzeit. Die Abfolge innerhalb eines normalen Expertensystems macht dies deutlich. In einer internen Datenbank werden Fakten mit Ableitungsregeln kombiniert gespeichert, die beide zusammen spezifische Wissensstaende ausmachen. Ein Programm als sogenannte Inferenzmaschine (Denken) versucht die eingehenden Behauptungen aus den vorhandenen Regeln und Fakten abzuleiten. Dabei koennen auch Aktionen ausgeloest werden. Laesst sich die Behauptung nicht ableiten, muss die Maschine passen und kann nur eine lapidare Meldung wie "failed" oder "no" ausgeben.

Diese Verfahrensweise birgt einen wesentlichen Nachteil fuer die automatisierte Netzwerkanalyse. Bei jedem Durchlauf der Inferenzmaschine muessen meist alle Fakten und Regeln in der Datenbank betrachtet werden. Damit geht viel Zeit fuer die Reaktion auf Fehlervorkommnisse im Netzwerk verloren. Diese Systeme eignen sich also nicht fuer die Netzwerkanalyse in Echtzeit. Anders die sogenannten Blackboard-Systeme. Ein derartiges System (zum Beispiel Expert-Sniffer) besteht aus mehreren semiparallel ablaufenden Prozessen. Ein ankommendes Datenpaket wird zuerst vom Dekodierprozess in eine einheitliche, protokollunabhaengige Struktur uebersetzt und in einem zentralen Speicher abgelegt, der allen Prozessen zur Verfuegung steht. Daneben gibt es weitere Prozesse, die Wissensquellen des Systems. Jede ist auf einen bestimmten Problembereich spezialisiert, zum Beispiel Antwortzeiten, Sequenzfehler, doppelt vergebene Adressen. Jeder dieser Prozesse liest nur den fuer seine Auswertungen relevanten Teil des Paketrahmens ein, wertet ihn aus und vergleicht die Daten mit dem selbsterlernten Echtzeitdatenbild des Netzwerks in der internen Datenbank. Stimmen die Daten mit dem "Weltbild" ueberein, dann entstehen in dieser Datenbank neue Objekte oder vorhandene werden aktualisiert. Stehen die Daten hingegen im Widerspruch zum "Weltbild" - beispielsweise wenn die einer IP-Adresse zugeordnete MAC-Adresse nicht mit dem Eintrag in der Datenbank uebereinstimmt - hat das System den Fehler gefunden und kann die Information an der Konsole ausgeben. Da alle Wissensquellen parallel nur die fuer sie relevanten Auswertungen treffen, entsteht kein Zeitverzug, und die Netzwerkanalyse kann in Echtzeit durchgefuehrt werden. Wieviel effektiver eine automatisierte Netzwerkanalyse gegenueber der herkoemmlichen Analyse greift, macht folgendes Beispiel deutlich.

Bei einer regionalen Zeitung werden an jedem Morgen die Anzeigen und Lokalteile fix und fertig gesetzt von den Lokalredaktionen zur Zentrale uebertragen. Dazu wird nacheinander eine Verbindung zu jeder Aussenredaktion aufgebaut. Bei einer durchschnittlichen Entfernung von 50 Kilometern werden taeglich zirka zwei Stunden lang Daten transferiert, was jeweils die Zeitung rund 1200 Mark kostet, im Monat also 32400 Mark. Nachdem man zwischen Router und Terminaladapter ein derartiges Testsystem angeschlossen hatte, um den Datenverkehr zu ueberwachen, staunte man nicht schlecht: Im Durchschnitt wurde jedes Paket zweimal uebertragen! Warum? Wie das Analysesystem offenbarte, lag die Ursache darin, dass Puffer falsch konfiguriert worden waren. Nach der Korrektur der Fehler reduzierte sich die notwendige Verbindungszeit auf die Haelfte. Damit werden jetzt taeglich 600 Mark Leitungskosten gespart. Nur durch die Aufdeckung dieses Fehlerfalls hatte sich der Server bereits nach rund neun Wochen amortisiert.

Blackboard-Systeme gehen so weit, dass sie das Problem klassifizieren und damit die Fehlerursache aufdecken; sie werden an der Konsole sortiert nach ihrer Wahrscheinlichkeit ausgegeben - die wahrscheinlichste zuerst. Diese Vorgehensweise erspart dem Administrator lange Recherchen.

Aber nicht nur im Netzwerkproblemfall sind derartige Systeme einsetzbar. Da alle Aktivitaeten im Netzwerk permanent mit dem Netzwerkbild der Datenbank verglichen werden, kann auf kleinste Abweichungen beziehungsweise heraufziehende Probleme fruehzeitig reagiert werden.

Wo sollte nun die Netzwerkanalyse zum Einsatz kommen? Jedes Segment mit einem Analyse-Server auszustatten duerfte schon aus Kostengruenden kaum praktikabel sein. So stellt sich also die Frage, wo ein Netzwerkausfall eher in Kauf genommen werden koennte und wo nicht. Es empfiehlt sich dementsprechend, derartige Server nur in kritischen Segmenten zu installieren (Backbone, WAN- Anbindungen, Produktionsbereiche) - sie machen in der Regel nur ein Drittel des Unternehmensnetzes aus. Doch hier hat sich die Investition in die Netzwerkanalyse in der Regel schnell amortisiert. Verteilte Netzwerk-Analysesysteme arbeiten dabei voellig autonom, um bei der Kommunikation mit der Konsole keine Blindlast im Netzwerk zu erzeugen. Nur im Fehlerfall werden entsprechende SNMP-Traps an die Konsolen versendet.

Aehnlich Telnet - nur komprimierter

Wuenscht der Administrator genauere Informationen zum Problem, wird von der zentralen Konsole eine Verbindung aehnlich Telnet - nur komprimierter - zu den dezentralen Analyse-Servern aufgebaut. Um auf Nummer Sicher zu gehen, sollte diese Verbindung nicht nur ueber das Netz, sondern auch ueber serielle Leitungen schaltbar sein. Dafuer koennen 9600 Baud voellig ausreichen. Die serielle Verbindung oeffnet dem Unternehmen zudem das Tor zum Outsourcing. So laesst sich die Netzwerkanalyse an einen Dienstleister delegieren, der in diesem Fall die Server in den kritischen Segmenten stellt und die Ereignisse des Kundennetzwerks fernueberwacht.

Doch was passiert mit den nicht so kritischen Segmenten, in denen sich das Unternehmen dennoch keinen Kommunikationsausfall leisten kann? Zwei verschiedene Ansaetze sind moeglich. Entweder man verwendet Switch-Systeme (hier: Segmentumschalter), die dem Netzwerkanalyse-Server nachgeschaltet sind, oder man setzt auf RMON Probes.

Im ersten Fall bedient der Switch (zum Beispiel von Datacom Systems Inc.) ein kritisches und sieben unkritische Segmente. Der Netzwerk-Manager kann sich damit im Bedarfsfall ueber die Software des Netzwerkanalysesystems in das betreffende Segment einschalten. Fuer die Zeit der Fehlersuche bleibt das kritische Segment jedoch unbeobachtet. Um das zu vermeiden, empfiehlt es sich, den acht Segmenten neben dem Segmentumschalter einen eigenen Netzwerkanalyse-Server zuzuordnen.

Im zweiten Fall kommen verteilte Monitoring-Systeme (RMON) zum Einsatz, insbesondere wenn differenziertere Informationen zu Netzwerkereignissen, beispielsweise Trendanalysen, erstellt werden sollen. Wirklich neu daran sind nicht die Inhalte, sprich: Funktionen, denn die gibt es bereits seit Jahren.

Abfragen zentral ueber die Konsole

Neu ist, dass diese Funktionen mit der Remote Monitoring Management Information Base allgemein verbindlich standardisiert wurden. Somit koennen jetzt von einer zentralen Management-Station aus bei den angeschlossenen Agents und Probes Statistiken in Auftrag gegeben werden, die dann ihrerseits die ermittelten Daten ueber die zentrale Management-Datenbank bereitstellen. Auswertung und zyklische Abfragen erfolgen anders als bei den verteilten Netzwerkanalysesystemen zentral durch die Konsole. Sie uebernimmt zudem die statistische Aufbereitung der Daten ebenso wie die grafische Darstellung. Damit erzeugen diese Systeme zusaetzlichen Netzwerkverkehr bei der Abfrage der Werte via SNMP. Eine Datenlast, die sich zur Konsole hin schnell kumuliert und dem normalen Netzverkehr viel Bandbreite raubt.

Alarme werden aehnlich wie bei Netzwerkanalysesystemen via SNMP- Traps verschickt und beziehen sich vornehmlich auf die MAC-Ebene und den IP-Bereich. Derzeit werden zwei RMON-RFC (Request For Connect) unterstuetzt, fuer Ethernet (neun Gruppen, Nr. 1271) und Token Ring (zehn Gruppen, Nr. 1531). In den einzelnen Gruppen sind entweder spezielle Statistiken, bezogen auf Segment, Host oder Kommunikation, beschrieben oder Parameter wie Schwellenwerte fuer die Alarmsteuerung hinterlegt. Ein Anbieter darf sein System bereits dann RMON-System nennen, wenn eine der vielen Gruppen vollstaendig implementiert ist. Also gilt es besonders darauf zu achten, dass alle Gruppen zum Vorrat des RMON-Systems gehoeren - wie im Falle des Foundation Manager/ Cornerstone Agent von Network General.

Ein Alptraum jedes Netzwerkverantwortlichen: Er entscheidet sich fuer die nach seiner Meinung geeigneten Netzwerkkomponenten, LAN- Infrastrukturen und WAN-Techniken - und konzeptioniert sein Netzwerk am Bedarf vorbei. Auch in dieser Hinsicht wird es bald Loesungen geben, dem Administrator ein grosses Stueck Planungsunsicherheit zu nehmen. So soll demnaechst eine Software auf den Markt kommen, die es erlaubt, Netzwerkablaeufe exakt zu simulieren, um so zum richtigen Netzwerkaufbau zu finden. Dazu kann der Netzverantwortliche das Netzwerk seiner Wahl unter einer komfortablen Windows-Oberflaeche flexibel gestalten oder das vorhandene am Monitor nachbilden (vgl. Abbildung 2), um potentiellen Schwachstellen schnell auf die Spur zu kommen.

Fuer alle wichtigen Komponenten des Netzes stehen Ikos zur Verfuegung, so fuer unterschiedliche LAN-Techniken (Ethernet, Token Ring, Fast Ethernet, FDDI), fuer Server, Hub-Systeme, Weitverkehrsverbindungen und verschiedene Internet-Systeme wie Bruecken, Router und Switch-Systeme. Sie alle koennen per Mausklick positioniert werden. Auf diese Weise lassen sich schnell alternative Netzwerkdesigns erstellen.

Richtige Positionierung im Serversystem

Einmal konzeptioniert, ist es mittels vorgeschaltetem Sniffer- Analysesystem moeglich, unterschiedliche Verkehrsarten (TCP/ IP, Novell IPX, Banyan Vines, XNS) und verschiedene Verkehrslasten zu generieren, um das Netzwerk realitaetsnah auf die Probe zu stellen. Rechnerkapazitaeten werden im geplanten Umfeld ebenso simuliert und analysiert wie Verkabelungsstrukturen, Verkehrsaufkommen im lokalen Netzwerk und an den Fernverbindungen sowie Fehlerereignisse und Durchsatzverhalten an Internet-Systemen. Zusaetzlich lassen sich vor dem Einsatz neue Anwendungen im simulierten Netzbetrieb austesten und, falls erforderlich, auf ihre Client-Server-Tauglichkeit hin ueberpruefen. Besonders nah an der Realitaet koennen Netzwerkerweiterungen konzipiert werden, weil in diesem Fall das Analysesystem praxiserprobte Daten aus dem bestehenden Netzwerk fuer Simulationslaeufe zur Verfuegung stellt.

So findet der Netzwerkverantwortliche ohne grosses Investitionsrisiko und teure Beratungshonorare durch Ausprobieren unterschiedlicher Netzwerkkomponenten und -topologien zur geeigneten Infrastruktur und einer massgerechten Segmentierung des lokalen Netzwerks, zur richtigen Positionierung von Server- Systemen, zu leistungsfaehigen Programmen und zu bedarfsorientierten Weitverkehrsverbindungen - noch bevor ein einziges System installiert worden ist.

Immense Nachteile in Kauf genommen

An einer wirkungsvollen Netzwerkanalyse fuehrt in den Unternehmen kein Weg mehr vorbei. Leistungsfaehiges Simulationswerkzeug wird zudem dazu beitragen, dass Fehlinvestitionen in Hard- und Software weitgehend ausgeschlossen sind. Die Werkzeuge, um mehr Kommunika-

tionssicherheit im Netz zu etablieren, sind auf jeden Fall vorhanden. Was noch fehlt, ist vielerorts die Sensibilitaet fuer Netzwerkprobleme - und davon gibt es genug, auch wenn man in den Abteilungen Kommunikation oder Netzwerk nicht gern davon spricht. So erreicht die Botschaft nur selten die Unternehmensfuehrung - mit der Konsequenz, dass immense Nachteile stillschweigend in Kauf genommen werden.

Die Netzwerkprobleme jedoch werden sich in stetig expandierenden Netzen mit immer komplexeren Kommunikationsbeziehungen und schnelleren Topologien noch haeufen - und tendenziell auch staerker den Kommunikationsnerv des Unternehmens treffen. Es sei denn, die Netzwerkanalyse und -simulation hilft, Probleme schnell zu beheben oder - noch besser - gar nicht erst aufkommen zu lassen.

* Frank Koelmel ist Produkt-Manager Netzwerkanalyse/Netzwerk- Management bei der Telemation Gesellschaft fuer Datenuebertragung mbH in Oberursel.