Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

06.02.1998 - 

System-Management/Chancen des neuen Standards

Mit RMON applikationsbezogenes Netz-Management realisieren

Bei nach wie vor steigenden Verfügbarkeitsanforderungen an den Netzwerkbetrieb ist eine konsequente Überwachung der Betriebszustände ein wesentliches Ziel zur Störfallreduzierung. RMON, Version 2, liefert eine Reihe von Möglichkeiten für proaktives Management.

RMON erweitert das Manager-Agenten-Modell von SNMP um eine Hierarchiestufe: Eine RMON-Manager-Applikation überwacht die Netzkomponenten nicht direkt, sondern steuert einen RMON-Agenten. Dieser beobachtet entsprechend seiner Konfiguration eine Reihe von Netzwerkkomponenten passiv und liefert die Resultate an den RMON-Manager.

Die RMON, Version 2, ist als Ergänzung für Version 1 gedacht. Dementsprechend wurde keine eigenständige Gruppennumerierung für die Variablen einfach weitergeführt (siehe Abb. 1). RMON, Version 2, umfaßt die RMON-Gruppen elf bis 20, wie nachfolgend beschrieben.

Protocol Directory (11) ist ein Verzeichnis, in dem für eine spezielle Implementierung die Liste der unterstützten Protokolle der Ebenen drei bis sieben eingetragen wird. Die Spezifikation unterscheidet dabei Netzwerkprotokolle (Ebene drei, "Network") und Applikationsprotokolle (im Unterschied zu OSI jedes Protokoll aus den Schichten vier bis sieben, "Application"). Protocol Distribution (12) definiert als Variablen zur Abfrage der Protokollverteilung die relative Paketzahl und Byte-Verteilung verschiedener Protokolle. Address Map (13) erstellt eine Mapping-Tabelle für Netzwerk- und zugehörige MAC-Adressen. Network Layer (14) definiert die Statistikabfrage für Ebene-drei-Kommunikation einzelner Protokolle, bezogen auf Netzwerkadressen (Hosts). Abgefragt werden Senden und Empfangen von Paketen und Bytes. Network Layer Matrix (15) legt fest, wie die Kommunikationsmatrix eines bestimmten Netzwerkprotokolls (beispielsweise IP oder IPX) erstellt wird. Application Layer und (16) und Application Layer Matrix (17) beschreiben analog zu Network Layer (14) und Network Layer Matrix (15) die Statistikabfrage für einzelne Hosts oder die Kommunikationsmatrix von Applikationsschichten (alle Schichten oberhalb der Netzwerkschicht) wie TCP, UDP, SUNRPC, FTP, Telnet, NFS, SMTP, BOOTP, HTTP, POP.

User History (18) ermöglicht die benutzerkonfigurierte Langzeitüberwachung von Parametern der RMONv1-Gruppen History (2) und Alarms (3). Probe Configuration (19) standardisiert Konfigurationsparameter von Probes wie Modem Control String, unterstützte RMON-Gruppen, Datum, Download-Server-Adresse und -Datei, serielle Schnittstelle, IP-Adresse sowie Trap-Destination-Einträge etc. Somit kann die Konfiguration von Probes selbst standardisiert werden. Conformance (20) beschreibt die Implementierungsanforderungen für die Bezeichnung RMON-konform: Gefordert (Mandatory) werden die Gruppen (11) bis (15), (18) und (19) für die sogenannte MIB-Konformität (Management Information Base). Application-Layer-Konformität erfordert zusätzlich die Gruppen (16) und (17).

Mit den beschriebenen Zielen und Funktionen stellt sich RMON in der Version 2 als Standard zur feinskalierten Überwachung und zum vorbeugenden Netzwerk-Management dar. Konfiguration und Tuning von Netzkomponenten ebenso wie Autodiscovery und Autotopology gehören jedoch nicht zum Fokus von RMON.

RMON-Manager sind als eigenständige Applikationen auf PC-Basis, als Teil von Element-Managern oder als Funktion von Plattformsystemen implementiert. RMON-Agenten können separate Probes sein oder Hard- und Softwaremodule in Netzkomponenten. Für den Outband-Zugriff wurde in RMON das Serial Line Internet Protocol (Slip) spezifiziert; teilweise unterstützen Probes jedoch auch das höherwertige PPP. Separate Probes bieten die umfangreichste Funktionalität, verursachen jedoch auch die höchsten Kosten, und ihr Einsatz ist nicht immer praktikabel. So etwa bei Netzwerken mit LAN-Switches als Collapsed Backbone, deren Ports alle dediziert gefahren werden (Anbindung von Etagen-Switches einerseits, dedizierte Anbindung von Servern andererseits). Sollen Traces gefahren werden, ist insbesondere CPU-Dimensionierung und Speicherausstattung einer Probe wichtig. Von den Software-Agenten in Netzkomponenten haben aktuell eindeutig die Hub-Systeme die höchste Funktionalität. LAN-Switches stellen meistens nur vier RMON-Version-1-Basisgruppen zur Verfügung (History, Statistics, Events, Alarms), mit denen sich nicht mehr als eine rudimentäre Überwachung erreichen läßt. Teilweise werden die Statistikdaten nur online zur Verfügung gestellt, lassen sich aber nicht oder nur in sehr geringem Umfang (etwa die letzten 20 Werte) im Switch abspeichern. In jedem Fall ist bei LAN-Switches zu überprüfen, ob die RMON-Werte je Port abfragbar sind und wie viele Ports sich parallel überwachen und im RMON-Manager darstellen lassen. 100 separate Fenster für 100 Switchports sind insbesondere in Störfallsituationen nicht akzeptabel. Leider ist die Darstellung der RMON-Daten aber vielfach auf genau diese Weise implementiert. RMON, Version 2, wird von LAN-Switches so gut wie gar nicht unterstützt. Das kommt aber mit den neuen Switch-Generationen (etwa "Corebuilder 9000" von 3Com).

Über die Adreß-Map kann der Administrator Doppelfehler, falsch vergebene IP-Adressen, Umzüge (bei DHCP) oder Re-Routing erkennen. Um die tatsächliche lastmäßige Bedeutung der Protokolle im Standortnetz zu belegen, wird die Protokollverteilung in Paketen und Bytes gemessen. Sie zeigt die relative Bedeutung eines einzelnen Protokolls und gibt Hinweise, ob in einem geswitchten Netz gegebenenfalls Routing erforderlich ist. Eine Übersicht über die Paket- und Byte-Anteile verschiedener Applikationen legt die Bedeutung eines Protokolls offen und macht deutlich, ob mehr Server-Bedarf besteht. Kombinierte Einzelüberwachung kritischer Stationen auf MAC- Netzwerk- und höheren Ebenen ist möglich. Sendeverhalten und Empfangsverhalten läßt sich überprüfen, zum Beispiel die IPX- und IP-Belastung eines bestimmten Servers. Auch die Zahl der Pakete und Bytes für verschiedene IP-Applikationen an einem Server wie DNS, FTP, HTTP, NFS, POP 3, TFTP können gemessen werden, um über eine sinnvolle Funktionsaufteilung auf mehrere Server zu entscheiden .

Ausblick: Tips zum RMON-Einsatz

- RMONv1 ist auf Werte der MAC-Ebene beschränkt und daher zur Basisüberwachung geeignet. Es sollte im Backbone und zumindest in jedem Netzsegment sowie für alle LAN-Switchports mit dedizierter Server-Anbindung installiert sein.

- RMONv2 sollte zur applikationsbezogenen Überwachung von Servern, Intranet- und Internet-Aktivitäten oder auch zur Analyse und Überwachung der Protokollverteilung (Accounting) bei Multiprotokollnetzen gefahren werden. Somit läßt sich der Einsatz von RMONv2 auf den Kernbereich eines Netzwerks beschränken, wo die wichtigsten Analysedaten zusammenlaufen (Backbone, Server-Farmen, RZ).

- Bei mittleren Anforderungen (Abfrage von Grundinformationen) können die RMON-Fähigkeiten von LAN-Switches genutzt werden. Auch für zentrale Server-Pools mit Switch-Ankopplung ist RMON-Funktionalität im LAN-Switch zur Überwachung der Server-Ports erforderlich. Hierfür muß die parallele Überwachung und Abfrage der RMON-Daten pro Port sichergestellt sein.

- Bei größeren Shared-LAN-Segmenten, für Backbones und wenn umfangreiche Traces oder Langzeitstatistiken gefahren werden sollen, sind separate Probes vielfach am besten geeignet.

- Generell ist von einer RMON-Nutzung auf Endgerät- oder Server-Adapterkarten eher abzuraten, da dies die CPU der Geräte zu stark belastet. Der Einsatz von RMON in Servern und Endgeräten ist höchstens für die Nutzung herstellereigener Erweiterungen sinnvoll.

- Um den RMON-Experten und Autor Steven Waldbusser zu zitieren: "Reines RMONv2 bringt wenig Nutzen." Ohne eine sinnvolle Abfrageauswahl der möglichen MIB-Variablen ist RMON nicht sinnvoll einsetzbar. Hierfür einige Hinweise:

- Statistiken über alle betriebenen Protokolle sind nur zur generellen Übersicht zu erstellen. Detailauswertungen sollten nur für produktionskritische Applikationen und Server-Systeme, nicht jedoch für Arbeitsplatzsysteme gefahren werden (letzteres birgt außerdem betriebsrechtliche Probleme).

- Erstellen Sie keine globalen Matrixauswertungen, sondern besser TopN beziehungsweise in speziellen Störfallsituationen (Fehler, schlechte Performance) entsprechend angepaßte Einzelanalysen.

- Bei der Erarbeitung eines Tool-Konzepts ist auf Automatisierungs- und Zusammenfassungsmöglichkeiten der Reportprodukte zu achten.

Fazit

RMON ist ein Überwachungs- und Analysestandard, der sich seit vier Jahren zunehmend etabliert und erkennbar in Richtung Applikationsmonitor und Accounting entwickelt wird. Erweiterungen für LAN-Switches und Hochgeschwindigkeits-Interfaces werden folgen. Allerdings ist nach wie vor keine RMON-Entwicklung für ATM erkennbar. Ist der Einsatz von RMONv2 zu empfehlen? Ja, aber hohe Effizienz ist nur mit einem Automatisierungs- und Überwachungskonzept gegeben, das die RMON-Abfragen gezielt und bewußt auf die unternehmensspezifisch relevanten Daten beschränkt.

Abkürzungen

BOOTP Bootstrap Protocol

DDP Datagram Delivery Protocol (Appletalk)

DHCP Dynamic Host Configuration Protocol

DNS Domain Name Service

IETF Internet Engineering Task Force

IPX Internetwork Packet Exchange

FTP File Transfer Protocol

HTTP Hypertext Transfer Protocol

NFS Network File System (Sun Microsystems)

NMS Netware Management System

POP Post Office Protocol

PPP Point-to-point Protocol

RPC Remote Procedure Call

SLIP Serial Line Interface Protocol

SMI Structure of Management Information

SMON Switch Monitoring

SMTP Simple Mail Transfer Protocol

SNMP Simple Network Management Protocol

SUNRPC Sun Microsystems RPC

TCP Transmission Control Protocol

Telnet Teletype Network

TFTP Trivial File Transfer Protocol

UDP User Datagram Protocol

RMON

Ein Standard setzt sich durch

November 1991: RFC 1271 als Basisstandard (Ethernet-MAC-Ebene)

September 1993: RFC 1513 integriert die Token Ring Wels (MAC-Ebene)

Februar 1995: RFC 1757 verbessert den Basisstandard durch wichtige Erweiterungen (RMON-Zugriffssteuerung)

Januar 1996: RFC 1905 zur Protokollspezifikation für SNMPv2

Januar 1997: RFC 2021 und 2074 definieren (auf der Basis von SMIv2, SNMPv2) Variablen zur Überwachung verschiedenster höherer Protokolle wie IP, TCP, FTP, NFS, IPX, RIP, SAP, IDP, Appletalk, (Status 12/97: Proposed Standard)

Januar 1998: Zwölf Monate nach der Ratifizierung von RMONv2 stehen erste Produkte zur Verfügung

Angeklickt

Mit der zweiten Version des Remote Monitorings (RMON) hat die IETF keinen Standard entworfen, der RMONv1 ablösen soll. Beide Normen ergänzen sich, wobei RMONv2 für das applikationsbezogene Netz-Management zuständig ist. Um das Verfahren effektiv zu nutzen, sollte der Anwender die Abfragemechanismen überlegt auswählen und auf wichtige Applikationen beschränken.

*Diplominformatikerin Petra Borowka ist Geschäftsführerin der UBN, eines Planungsbüros für herstellerunabhängige Studien, Beratung und Planung von Netzwerken in Aachen.