Vorgänge und Probleme im Netz sind für die Administratoren immer schwieriger zu greifen. Schuld an dieser Entwicklung sind über Weitverkehrsstrecken hinweg expandierende Unternehmensnetze, in denen Daten und Anwendungen in einem erheblichen Umfang verteilt gehalten werden. Hinzu kommt der Trend zu komplexen Switch-Architekturen, mit denen die Verbindungen und Verkehrsbeziehungen innerhalb der lokalen Netzwerke für die Administratoren immer undurchsichtiger werden. Allein eine Entwikklung ist derzeit dabei, der wachsenden Komplexität entgegen zu steuern: die Vereinheitlichung des Unternehmensnetzes über das Internet-Protokoll (IP) und die zunehmende Etablierung einer durchgehenden Ethernet-Technik in den lokalen Netzwerken.
Deshalb waren leistungsfähige Werkzeuge noch nie so wichtig wie heu-te, um Abläufe im Unternehmensnetz abzusichern und effizient zu gestalten. Ein Ansatz dazu ist das Netzwerk- und Systemmanagement, das den Überwachungs- und Verwaltungshebel an den Komponenten selbst ansetzt, ein weiterer das Messen, Überwachen und Analysieren von Komponenten-Verbindungen. Auf dem Markt werden für die Aufgaben Messen, Überwachen und Analysieren der Anschlüsse tragbare oder fest installierte Netzwerkanalysatoren sowie RMON-Systeme angeboten. Spätestens seitdem der RMON2-Standard im zweiten Halbjahr 1997 verabschiedet wurde, geraten die teuren multiprotokollfähigen Netzwerkanalysatoren zusehends ins Abseits (siehe Kasten).
Für den Trend zu RMON gibt es weitere gute Gründe. Anders als portable Analysatoren, die immer am Ort des Geschehens oder Problems eingesetzt werden müssen, ist RMON ortsunabhängig im verteilten Netz anwendbar. Möglich wird dies aufgrund der RMON-MIB (Management Information Base) innerhalb der zentralen Management-Software (siehe Bild Seite 32). Sie beinhaltet die standardkonformen Variablen, mit denen den Probes an den Anschlüssen von LAN-Komponenten wie Hubs, Routern, Switch-Systemen und Servern das Sammeln spezifischer Daten aufgetragen wird. Die dort erfaßten Zahlenwerte werden dann zyklisch von der Management-Konsole abgefragt und für Auswertungen in einer zentralen Datenbank bereitgehalten. Per Reporting-Software kann dann das zentrale Management-Team Netzwerkstatistiken und Trendanalysen erstellen, Fehler im Netz verfolgen und Daten für die Abrechnung von Netzdienstleistungen zusammenstellen. Parallel können RMON-Variablen zur Definition von Schwellenwerten in einzelnen Probes genutzt werden, um beim Unter- beziehungsweise Überschreiten dieser Werte an der zentralen Managementstation einen Alarm auszu-lösen. Damit ist RMON auch ein ideales Frühwarnsystem Grundvoraussetzung für eine flächendekkende Erfassung von RMON-rele-vanten Informationen ist freilich ein TCP/IP-Netz. Der Trend zu RMON verstärkt sich dadurch, daß immer mehr Hersteller von Netzwerkkomponenten ihre Systeme ohne Zusatzkosten für den Anwender mit einem integrierten RMON-Probe ausrüsten. Damit schaffen sie sich potentielle Alleinstellungsmerkmale im hart umkämpften Netzwerkkomponenten-Markt. Somit läßt sich die RMON-Überwachung, zumindest theoretisch, von der Zentrale aus wirtschaftlich auf alle Segmente des Netzes ausdehnen.
Wer mehr an Funktionalität und Durchsatzengpässe im System von vornherein vermeiden will, sollte indes im Zusammenspiel mit der zentralen Management-Software auf externe RMON-Probes, ausgerüstet mit einem eigenen Prozessor und Speicher, setzen. Mit dieser Entscheidung löst sich der Anwender zudem, zumindest teilweise, aus der Klammer proprietärer Zusatzvariablen und -funktionen und somit einer markteinschränkenden Herstellerbindung. Die externen Probes haben zwar ihren Preis, aber an den richtigen Meßstellen im Unternehmensnetz eingesetzt, liegen die Kosten für die externen Probes immer noch weit unterhalb des Niveaus, auf das sich der Anwender mit dem Einsatz von portablen Netzwerkanalysatoren und erst recht von fest installierten Analyse-Servern einläßt.
Spätestens mit dem Einzug von Switch-Installationen im Unternehmen geraten die Netzwerkanalysatoren vollends aus der Mode. Sie sind in diesem Umfeld kaum mehr als ein Fehlersuchinstrument im akuten Problemfall. Heiko Rössel, Geschäftsführer von Röwaplan Ingenieurbüro und Beratung im schwäbischen Abtsgmünd, erklärt dies durch die Tatsache, daß Netzwerkanalysatoren hier jeweils nur an einem Switch-Anschluß messen können. Die RMON-Probes hingegen könnten für das Unternehmen wirtschaftlich für eine ständige Informationsrecherche gezielt an den Ort des Analysebedarfs plaziert und in definierten Intervallen von der zentralen Managementkonsole aus abgefragt werden.
Zudem läßt sich das RMON-System, das zwischen zentraler Management-Software und den entfernten Probes auf einer standardkonformen Kommunikation via SNMP (Simple Network Management Protocol) aufbaut, anders als der Netzwerkanalysator nahtlos in eine umfassende Netzwerk- und Systemmanagement-Architektur integrieren. SNMP als Kommunikationsprotokoll macht es auch möglich, via RMON-System nicht nur die Probes, sondern bei Bedarf auch die Basisstatistiken innerhalb von SNMP-Agenten auszulesen.
Doch trotz aller technischen und wirtschaftlichen Vorteile hat RMON auch Schwächen, die der Anwender für eine verläßliche Entscheidung kennen sollte. So kann der Anwender nur auf einen standardkonformen Einsatz von RMON innerhalb der LAN-Techniken Ethernet und Token-Ring zählen, sofern sich der Hersteller bei diesen Techniken an die Regeln hält. Hochgeschwindigkeitstechniken wie Gigabit-Ethernet und ATM harren hingegen einer künftigen Standardisierung durch die IETF (Internet Engineering Task Force), ebenso wie die WAN-Protokolle, inklusive X.25, HDLC, Frame-Relay und PPP (Point-to-Point Protocol). Diese verbindlichen Para- metervorgaben für ein normkonformes Sammeln von Informationen in den Probes bleiben einem RMON3-Standard vorbehalten, den Markt- kenner erst im Verlauf des Jahres 2000 sehen. Ein Wermutstropfen für den europäischen Markt ist auch die Tatsache, daß das WAN-Protokoll ISDN aufgrund der US-lastigen Sichtweise des IETF nicht zum Umfang des künftigen RMON3-Standards gehören wird, ebenso wie auch die LAN-Technik FDDI.
Im Switch-Umfeld ohne Alternative
Bis der Standard kommt, und wohl noch einige Zeit danach wird sich der Anwender bei den zur Normierung anstehenden LAN- und WAN-Protokollen mit proprietären Variablen zufrieden geben müssen, die in diesem Fall nicht in den RMON-MIBs, sondern in den herstellerspezifischen privaten MIBs stehen. Dieser Unterschied hat, über die Herstellerbindung hinaus für das Unternehmen zwei erhebliche Nachteile, wie Thomas Gebhardt, Berater beim Kommunikationsdienstleister Sornet in Bad Camberg, weiß:
"Private MIBs lassen sich nur schwierig und damit kostspielig in eine umfassende RMON- und damit Management-Architektur einbinden. Ein einheitlich hohes RMON-Leistungsniveau ist netzweit über alle Komponenten kaum möglich, weil proprietäre Variablen und Funktionen diesem generellen Anspruch entgegenstehen."
Proprietäre Lösungen im standardisierten Umfeld
"Es hilft nichts, die RMON-Funktionalität des Herstellers muß im einzelnen hinterfragt werden, um für den Einsatz auf Nummer sicher zu gehen", sensibilisiert Hans-Josef Wimmer, Leiter Technischer Support bei Netpart in Düsseldorf, die Anwender, die an den Einsatz von RMON denken. Für den RMON-Praktiker gilt dennoch: "Speziell die Einbeziehung von LAN-Techniken wie FDDI, ATM und Gigabit-Ethernet mit proprietären Meßmitteln ist immer noch besser als ihre Aussparung im Meßverbund."
Aber nicht nur im Bereich ausstehender Normen trifft der Anwender auf proprietäre RMON-Variablen und Funktionen. Er ist auch bei Ethernet und Token-Ring, speziell bei integrierten Probes der Komponentenhersteller, mit solchen herstellerbindenden Ansätzen konfrontiert, insbesondere bei RMON2. Als herstellerbindend erweist sich schon die Tatsache, daß mit diesem Standard nicht definiert wurde, welche Protokolle unterstützt werden müssen. Dr. Michael Rudolphi, Associate Partner bei Andersen Consulting in Sulzbach bei Frankfurt am Main, warnt dementsprechend: "Trotz dem seit 1997 verabschiedeten RMON2-Standards sollte der Anwender speziell bei integrierten RMON-Probes nicht von normkonformen Systemen ausgehen." Je mehr sich die RMON-Funktionalität von der Netzwerk- zur Anwendungsebene hin bewege, so der Berater, desto herstellerspezi-fischer seien letztlich solche Lösungen.
Daneben kann der Anwender nicht einmal gemäß RMON1 auf die Implementierung aller RMON-Gruppen mit den Variablen, neun für Ethernet (RFC 1271) und zehn für Token-Ring (RFC 1513), zählen. Besonders bei integrierten RMON-Probes der Komponentenhersteller werden oft wichtige Gruppen ausgespart. Wenig Klarheit verschafft in dieser Hinsicht die Behauptung der Hersteller, sie böten volle RMON-Unterstützung. Denn der Hersteller darf sein System bereits dann als voll RMON-fähig bezeichnen, wenn nur eine der mit dem RMON1-Standard vorgegebenen Gruppen komplett implementiert worden ist.
Ein weiterer Nachteil von RMON ist, daß die Dekodier- und Aufbereitungsintelligenz dieser Systeme auf Anwendungsschicht heute noch meist begrenzt ausfällt. Schuld daran ist die Diversität und Komplexität der aus den Datenrahmen auszulesenden Informationen, die von Ebene zu Ebene höhere Anforderungen an das RMON-System stellen. "Zwar werden hier die meisten gängigen Protokolle dekodiert", so Behrooz Moayeri, Prokurist und Leiter NetzewerkKonzipierung bei Comconsult in Aachen. "Aber für eine Analyse auf den höheren Schichten ist mehr als nur eine bloße Dekodierung erforderlich. Auch aussagekräftige Statistiken und Bezüge zwischen Protokollpaketen müssen im Sinne einer effizienten Analyse herstellbar sein."
Messen im Switch-Umfeld kaum mehr als Stückwerk
Zudem entpuppt sich die Datenrecherche der RMON2-Systeme auf den höheren Schichten beim genauen Hinsehen als Marketingaussage, wie Berater Gebhardt von Sornet herausstellt. "RMON-relevante Informationen der höheren Schichten werden nicht direkt auf diesen Ebenen ausgelesen, sondern nur mittelbar über den Port/Socket auf Schicht 4/5. Hier werden die Anwendungen wie E-Mail, FTP (File Transfer Protocol), Telnet und HTTP (Hypertext Transfer Protocol) dargestellt." Weder die Antwortzeiten einzelner Anwendungen können so standardkonform gemessen noch Fehler auf Aufwendungsebene aufgedeckt werden. Nur sogenannte RMON2-Plus-Systeme gehen teilweise bis in die Anwendungsströme. Dafür ist diese Plus-Funktionalität aber wiederum proprietär und bindet damit den Anwender an die Produkte dieses Herstellers. Für Gebhardt steht sowieso außer Frage: "Zur Anwendungsüberwachung wird sich künftig die ART- (Application Response Time-) MIB, integriert direkt in den Anwendungen, durchsetzen. "Diese ART-MIB könnte dann durch eine RMON-Probe als dezentrale Polling-Einheit abgefragt werden."
Darüber hinaus stoßen auch verteilt einsetzbare und von der Zentrale aus abfragbare RMON-Probes innerhalb sich ausbreitender Switch-Installationen schnell an ihre physikalischen Erhebungsgrenzen. Denn mit dem dedizierten Switch-Anschluß steht jeweils nur ein verkürztes Medium für die Informationsrecherche zur Verfügung. Das ist eine schmerzliche Einschränkung für den Anwender, denn hier, im Wust komplexer Verkehrsbeziehungen wäre eine Transparenz der Kommunikationsprozesse und -beziehungen besonders wichtig.
Auf die Funktionalität Switch-integrierter RMON-Probes könne das Unternehmen in dieser Situation nur bedingt zählen, unterstreicht Moayeri von Comconsult: "Diese Probes in den Switch-Systemen bieten standardkonforme Funktionen nur weniger RMON-Gruppen. Damit ist mit Blick auf eine Analyse lediglich eine rudimentäre Aufbereitung von Statistiken möglich." Daneben kann via RMON und SNMP auf die Basisstatistiken des im Switch integrierten SNMP-Agenten zugegriffen werden, sofern er über einen solchen Agenten verfügt. Aber auch über diese eher spartanischen Statistiken sind Switch-interne Verkehrsbeziehungen maximal bis auf IP-Ebene nachvollziehbar.
Moayeri empfiehlt vor diesem Hintergrund den Unternehmen, nur solche Switch-Systeme einzusetzen, die das Spiegeln von Anschlüssen erlauben, um an diesen Monitoring-Port externe RMON-Probes, inklusive RMON2-Funktionalität, anschließen zu können. So lassen sich die einzelnen Switch-Anschlüsse, beispielsweise für eine Fehlerrecherche, nacheinander der RMON-Messung unterziehen. Gleichzeitig wird mit dem Einsatz externer Probes der Switch von der RMON-Arbeit entbunden. So ausgewählt, sollten die RMON-Probes nur an strategisch wichtigen Anschlußpunkten plaziert werden, wie an bestimmten Server-Anschlüssen, an Uplinks zum Backbone und zwischen Router und Switch-Systemen. Andernfalls würde der Einsatz der Probes das Budget sprengen und die zentrale Managementkonsole mit nicht bewältigbaren Informationslasten überfluten.
MON in eigener Regie zu betreiben, heißt nicht, alles, von der Planung über die Installation und Customizing bis hin zur regelmäßigen Anpassung des RMON-Systems, selbst auszuführen. Wenn sich RMON für das Unternehmen auszahlen soll, gilt für Thomas Gebhardt von Sornet aus seinen praktischen Erfahrungen heraus folgender wirtschaftlicher Mix: "RMON-Implementierung inklusive Customizing durch den Dienstleister, Betrieb der RMON-Lösung durch den Anwender, die Pflege des RMON- Systems mit den notwendigen Anpassungen sowie neuen Definitionen und Statistiken wiederum durch den Dienstleister."
Tiefere Erkenntnisse zu seinen Switch-Umgebungen wird der Anwender jedoch auch mit diesem strategischen Ansatz nur bedingt erwarten können. Notwendig dazu wäre das Wissen über alle Protokollabläufe innerhalb der Switch-Systeme zu einem Zeitpunkt. Diese Erkenntnis wird einem SMON-(Switch MONitoring-) Standard vorbehalten bleiben, mit dem eine verbindliche Informationsrecherche direkt im Innern des Switch - am Bus oder an der Matrix - aufsetzbar sein wird. Eine Verfahrensweise, die beispielsweise Lucent Technologies mit den Lannet-Switch-Systemen in einer herstellerspezifischen Art verfechtet. Ein Normierungsentwurf für SMON wurde der IETF gerade vorgelegt. Bis SMON als verbindlicher Standard verabschiedet wird, sehen Marktkenner jedoch noch rund ein Jahr ins Land gehen. Dann wird es erfahrungsgemäß noch einige Zeit dauern, bis auch die Hersteller diesem Standard verbindlich folgen werden. (sf)