Zur Implementierung einer bedarfsorientierten, verteilten Monitoring-Funktionalitaet in LANs und LAN-WAN-Verbundnetzen hat sich seit Ende 1992 der SNMP-Standard Remote Monitoring (RMON) zunehmend etabliert. Petra Borowka* beschreibt in ihrem Beitrag nicht nur Standardumfang, Funktionalitaet und Ziele von RMON, sondern skizziert darueber hinaus auch Moeglichkeiten und Grenzen der SNMP-Norm anhand von Architekturen, zentralen Anforderungen und Einsatzszenarien.

Der Bedarf nach RMON entstand aus dem Anwenderwunsch, schon lange verfuegbare Monitoring-Funktionen proprietaerer LAN-Analysatoren wie dem Sniffer von Data General, Network Advisor von Hewlett-Packard, Lanalyzer von Novell, K1102 von Siemens etc. als Standardfunktionalitaet in die SNMP-Netz-Management-Familie zu integrieren.

Verantwortlich fuer RMON zeichnet die IETF RMON Working Group. Ihr gehoeren fuehrende Hersteller aus dem LAN-Analyse-Umfeld wie Lexcel, Novell, Hewlett-Packard, Frontier Software, Spider Systems etc. an, die ihre Entwicklungsaktivitaeten zur Schaffung eines standardisierten Monitorings und Fehler-Managements auf Data-Link- Ebene gebuendelt haben. Die Vorteile, die aus der Zusammenarbeit dieser Hersteller resultieren, sind:

- Verringerung des Investitionsrisikos in SNMP durch Vergroesserung der Marktrelevanz dieser Management-Philosophie,

- Reduzierung der Entwicklungskosten fuer den einzelnen Hersteller sowie

- kuerzere Entwicklungszyklen bis zur Produktreife.

Trotzdem haben alle Hersteller von RMON-Produkten dem Standardumfang Erweiterungsmerkmale zugefuegt, um sich nach Schaffung der Grundlagen wiederum vom Mitbewerb abzusetzen.

Die Entwicklung von RMON (RFC 1271, 1513) verfolgte mehrere Ziele. Einige SNMP-Schwaechen wie zum Beispiel der Polling-Overhead, die reduzierte Standard-MIB (Management Information Base) sowie viele inkompatible Private-MIBs sollten durch RMON nivelliert werden. Zukuenftig sind als Erweiterungen in RMONv2 die Nutzung von SNMPv2 sowie MIB-Variablen fuer Funktionen der Netzwerk- und Transportebene angedacht.

Im folgenden werden die Ziele einzeln jeweils kurz erlaeutert:

Reduziertes Polling: Durch den Einsatz separater Monitore in kritischen Netzsegmenten wird das Polling durch passives Mithoeren ersetzt und im wesentlichen auf das zu kontrollierende Segment eingeschraenkt. Ein einzelnes zentrales Netz-Management-System (NMS) pollt dagegen je nach Implementierung ueber Unicasts alle Segmente, wobei alle Transitsegmente zwischen NMS und gepollter Station sowohl durch den Poll-Request als auch die gesendeten Antworten mitbelastet werden.

Erweiterung der Standard-MIB: Die Urheber von SNMP haben in erster Linie die Netzwerk- und Transportebene des ISO-OSI-Referenzmodells beruecksichtigt. Variablen der physikalischen und Data-Link-Ebene fehlen jedoch.

Minimierung der Private-MIBs: Fuer Hersteller von Management- Plattformen war es zu aufwendig, Applikationen fuer Private-MIBs von Analysatorherstellern zu entwickeln. Eine Reihe dieser Plattformen kann nur den Wert einer MIB-Variablen anzeigen - von einer benutzerfreundlichen Anwendung also keine Spur. Die Schaffung einer Standard-MIB fuer Monitoring-Zwecke setzte diese Produzenten jedoch unter Druck, Maus-bedienbare Anwendungen mit grafischer Variablendarstellung zu implementieren, die auf unterschiedliche, RMON-konforme, verteilte Monitore zugreifen koennen.

Offline-Betrieb: Wenn die Management-Station selbst aufgrund von System- oder Netzausfall nicht aktiv ist, kann in remoten Netzsegmenten dennoch eine kontinuierliche Ueberwachung erfolgen. Nach Aktivierung des NMS sind die zwischenzeitlich aufgezeichneten Statistiken und Events abrufbar.

Vorbeugende Diagnose: Performance-Engpaesse koennen durch geeignete Schwellwertueberwachung fruehzeitig erkannt und zur Abhilfe Tuning- Massnahmen (Strukturierung, Erweiterung) eingeleitet werden, bevor die Benutzer ernsthafte Funktionseinbussen bemerken.

Fehlererkennung: Durch kontinuierliches Monitoring lassen sich Fehlersituationen aufzeichnen und automatisch als Ereignismeldungen (Traps) an ein NMS senden.

Aktueller RMON-Standard ist nur fuer Ethernet gueltig

RMON gliedert sich in insgesamt neun Variablengruppen, die nachfolgend beschrieben werden. Der aktuelle Standard, RFC 1271, bezieht sich nur auf Ethernet. Die Erweiterung fuer Token Ring, RFC 1513, ist derzeit im Draft-Status. Im Rahmen dieses Beitrags kann darauf nicht naeher eingegangen werden.

-Segmentstatistik: Durch rein passives Monitoring wird eine Statistik der validen und fehlerhaften Frames (Daten, Broadcasts, Multicasts) nach den fuenf Kategorien "zu kurz", "zu lang", "CRC- Fehler bei Fragmenten", "fehlerhafte CRC-Pruefsumme/ keine ganzzahlige Bytelaenge" und "Jabber-Pakete" angelegt. Dabei ist zu beachten, dass die Korrektheit der gezaehlten Frames erheblich von der Adapterguete, das heisst Verarbeitungsschnelligkeit des Monitors (RMON-Probe) abhaengt .

- History: Mittels statistischer Basisberechnungen wird eine Trendanalyse der Netzlast implementiert. Das Sample-Intervall ist im Bereich von einer Minute bis zu einer Stunde einstellbar. Aufeinanderfolgende Samples werden in der Probe bis zum Abruf abgespeichert, solange der Speicherplatz reicht.

- Host-Table: Fuer jeden ueber valide Frames mit seiner MAC-Adresse identifizierten Netzknoten werden gesendete und empfangene Uni- und Multicasts sowie Fehlerpakete gezaehlt. Welche Knoten auf diese Weise ueberwacht werden, ist im "HostControlTable" spezifiziert. Der "HostTimeTable" zeigt alle entdeckten MAC-Adressen in der relativen Reihenfolge, in der sie gefunden wurden.

- Host-Top N: Hierfuer ist die Implementierung der Host-Table- Gruppe Voraussetzung. Ein Statistikkriterium wird vorgegeben und anschliessend die n-Knoten angezeigt, die die groessten Werte hinsichtlich des gesetzten Parameters erreichen. Diese Funktion kann zum Beispiel zur Lastueberwachung der groessten Lastgeneratoren am Netz eingesetzt werden, wenn als Kriterium "HostTopNOutPkts" (Anzahl gesendeter Pakete) konfiguriert wird. Ein anderer Einsatzfall ist die Fehlerueberwachung, wenn als Kriterium "HostTopNErrors" (Anzahl Fehlerpakete) gesetzt wird. Insgesamt sind sieben solcher Kriterien waehlbar.

-Kommunikationsmatrix: Auf der Basis gezaehlter Pakete, Bytes oder Fehler wird eine Matrixstatistik zwischen je zwei Knoten (Quell- und Ziel-MAC-Adresse) angelegt. Die gaengigste Nutzung dieser Gruppe ist eine Laststatistik ueber das Datenaufkommen zwischen beliebigen Kommunikationspartnern, das bedeutet die Zaehlung gueltiger Pakete, die zwischen zwei Peer-Knoten gesendet werden.

-Alarme: Die Aufzeichnung wichtiger Alarmsituationen hilft entscheidend bei der Automatisierung der fuer einen effizienten Netzbetrieb erforderlichen Management-Aktionen. Ueber die Setzung von Schwellwerten fuer die absolute oder Delta-Netzlast beziehungsweise Fehlerpakete werden Grenzbereiche des normalen Netzbetriebs definiert. Die Ueberschreitung der gesetzten Schwellwerte loest Alarme aus, die an ein NMS weitergeleitet werden und dort ein optisches oder akustisches Signal hervorrufen oder in einem Event-Log in der Probe selbst abgespeichert werden. Die Aktion, die auf den Alarm hin erfolgt, wird in der Event-Gruppe festgelegt.

- Filter: Zur detaillierteren Analyse koennen Pakete vom Netz kopiert und komplett abgespeichert werden. Dies macht bei einem durchschnittlich hohen Lastaufkommen nur fuer eine Untermenge des tatsaechlichen Verkehrs Sinn. Sie wird ueber Filterbedingungen spezifiziert. Beispiel Fehlerfall: Alle Pakete eines der fuenf Fehlertypen werden gespeichert, um so den oder die Verursacherknoten festzustellen. Zu beachten ist, dass die Filtergruppe lediglich der Definition von Trigger-Bedingungen fuer den Trace dient; die Speicherung und Anzeige der Trace-Daten wird ueber die Gruppe "Packet-Capture" realisiert.

- Packet-Capture: Diese Gruppe setzt auf der Filtergruppe auf. Fuer jeden gesetzten Filter wird in der Liste "BufferControlEntry" eine abrufbare Statistik (Zaehler) angelegt. Jeder Filter-Match fuehrt zu einer Abspeicherung des entsprechenden Paketes und zur Inkrementierung des zugehoerigen Zaehlers. Filtersetzung und Tracing gehoeren zu den maechtigsten RMON-Funktionen. Sie sind hinsichtlich Verarbeitung und Pufferplatz am aufwendigsten zu implementieren.

- Events: In einer Event-Tabelle werden Ereignisse definiert, die entweder in der Log-Datei der Probe aufgezeichnet werden oder das Senden eines Traps an ein NMS ausloesen. Solche Events sind zum Beispiel Kalt- und Warmstart, Schwellwertueber- oder - unterschreitung sowie Match mit gesetzten Filtern. Die Implementierung ereignisgesteuerter Management-Aktionen reduziert den Aufwand an Polling fuer Intervalle erheblich. Damit wird einerseits die durch Netz-Management erzeugte Netzlast, andererseits die erforderliche Verarbeitungszeit im NMS verringert.

Die Implementierung jeder einzelnen Gruppe ist im Standard als optional angegeben, wobei aufgrund der Interdependenzen - einige Gruppen setzen die Implementierung anderer Gruppen voraus - nicht alle Gruppen-kombinationen sinnvoll sind. Innerhalb einer Gruppe sind alle Variablen "mandatory", das heisst, sie muessen verpflichtend unterstuetzt werden, um standardkompatibel zu sein. Die Optionalitaet aller Gruppen bedeutet, dass ein Hersteller jedes Produkt als standardkompatibles RMON-Produkt bezeichnen darf, das mindestens den Funktionsumfang einer der neun Gruppen verfuegbar macht.

Das hat den Nachteil, dass der Anwender die Bezeichnung "RMON- Unterstuetzung" genau auf die tatsaechlich implementierten Gruppen untersuchen muss, und den Vorteil, bedarfsgerechte und preisgestaffelte RMON-Loesungen produzieren zu koennen, da nicht jeder Anwender in jedem zu ueberwachenden Teilnetz die volle RMON- Funktionalitaet benoetigt. Aufgrund der Flexibilitaet, neue MIBs unabhaengig von existierenden zu definieren, koennen zukuenftige Erweiterungen andere LAN-Verfahren wie FDDI oder ATM einbeziehen.

Probe fungiert entweder als Agent oder Manager

Die RMON-Funktionalitaet besteht immer aus zwei Teilen: Einer Anwendung oder zumindest Abfragefunktion in einer Management- Plattform (NMS), die die uebergeordnete, zentrale Manager-Rolle uebernimmt, und einer bis mehreren Probes, die via Proxy-Funktion eine Doppelrolle innehaben: gegenueber dem NMS ist die Probe SNMP- Agent, gegenueber den ueberwachten Knoten eines Segments ist sie SNMP-Manager (vgl. Abbildung). Die in SNMPv2 definierte Manager- Manager-Kommunikation wurde somit in der RMON-Architektur vorweggenommen.

RMON-Produkte koennen auf verschiedenen Architekturen implementiert sein, zum Beispiel in Form von Hardwaremonitoren als separaten Box-Loesungen, meist mit RISC-Prozessoren und einigen 10 MB Speicherplatz (Frontier, HP, Metrix, NAT, Network General, Novell, TTC) oder als Softwaremonitore, die auf Standardrechnern installierbar sind. Diese benutzen zur Netzankopplung Standard- Interfaces und haben deshalb insbesondere als PC-Loesung nicht die hohe Verarbeitungskapazitaet wie Hardwaremonitore. Eine weitere Alternative sind Hub-Karten, die als modularer Einschub in intelligenten Hubs eingesetzt werden. Hier ist je nach Produkt (eigene CPU auf der RMON-Karte oder nicht) eine unterschiedliche Belastung der Hub-CPU gegeben. Der Anwender muss daher darauf achten, dass die eigentliche Hub-Performance nicht durch zu starke Management-Taetigkeit leidet.

RMON-Konfigurationen sind in Bruecken- oder Router-strukturierten Standort-LANs ebenso vorteilhaft einsetzbar wie in LAN-WAN- Verbundnetzen. Im ersten Fall ueberwachen die Probes kritische Segmente, an denen das NMS nicht direkt angebunden ist. Dort kann die Ueberwachung direkt geschehen.

Nicht jedes Netzsegment benoetigt auch eine Probe

Im Rahmen einer vernuenftigen Kosten-Nutzen-Relation ist es meist nicht sinnvoll, jedes Segment mit einer Probe zu bestuecken, sondern nur solche mit hoher Anzahl angebundener Endgeraete, hoher Verfuegbarkeitsanforderung oder zentralen Diensteerbringern.

Im zweiten Fall ist der Einsatz einer Probe je Standort optimal geeignet, um auf den in ihrer Kapazitaet begrenzten WAN-Leitungen, potentiellen Bottlenecks, Polling-Overhead einzusparen. Die Pervertierung von Management, naemlich Ueberlast im WAN wegen Management-Aktivitaeten, wird somit vermieden.

Um hinreichende Leistungsfaehigkeit fuer den geforderten Verarbeitungsaufwand abzusichern, sind RMON-Produkte an einigen zentralen Anforderungskriterien zu messen (siehe Kasten).

Fazit: Welche Marktrelevanz hat RMON? Die rasche Verfuegbarkeit von hinreichend ausgereiften Produkten spricht fuer sich. RMON wurde die erste marktrelevante Standarderweiterung der MIB II, die entscheidend zur Etablierung von SNMP als Management-Philosophie beigetragen hat.

Zu den Vorteilen fuer Anwender gehoeren die Nutzung verschiedener Probes aus derselben Anwendung auf einer Management-Plattform heraus, die Vergleichbarkeit von Produkten anhand des spezifizierten Maximalumfangs, die Interoperabilitaet von Probes mit verschiedenen Management-Plattformen sowie die automatisierte Ueberwachung von Teilnetzen und remoten Standorten, die reduzierte Netzlast durch Funktionsteilung und passives Monitoring.

Leider steht diesen Vorteilen auch noch eine Reihe von Einsatzbeschraenkungen und offenen Wuenschen gegenueber. So erfordert zum Beispiel die reine Abfrage der RMON-Variablen ein zu hohes technisches Know-how, der Anwender ist daher auf die Verfuegbarkeit von bedienerfreundlichen und interpretativen Anwendungen angewiesen. Ausserdem ist der Abruf der Capture-Daten noch immer sehr bandbreitenintensiv und die Nutzung von SNMPv2 noch nicht spezifiziert. Ein weiterer Kritikpunkt waere, dass Per-Port- Statistiken, vielfach ueber Hub-Management implementiert, ueber RMON nicht erhaeltlich sind.

Anforderungskriterien an RMON-Produkte

- Unterstuetzung aller neun RMON-Gruppen,

- modulare Funktionsgestaltung, das heisst Verfueg- barkeit der Gruppen in verschiedenen, gemaess der Interdependenzen sinn- voll getrennten Funktionsgruppen,

- Anzahl unterstuetzter Knoten in einem Segment (Tabellengroesse),

- PPS-Rate fuer Filterung und Pufferung von Paketen,

- CPU-Ausstattung und Speicherkapazitaet sowie

- Integration in Anwendungen auf Management-Plattformen.