Probes nach Maß

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."