Von: Michael Weingärtner
Die Informationsflut steigt. Immer mehr Firmen setzen auf konvergente Netze, die neben den herkömmlichen Daten Sprachsignale und Videostreams transportieren. Hinzu kommen zeitkritische Businessapplikationen, die extreme Anforderungen an die Performance und die Ausfallsicherheit des Netzes stellen. Gleichzeitig wird der LAN-Verkehr längst nicht mehr von den klassischen Hubs gemanagt, sondern von Switches, die auf den Ebenen 2 und 3 operieren. Dies erfordert Mechanismen, die ständig den Betrieb der Netzkomponenten überwachen. Dadurch erkennt der Administrator rechtzeitig, wenn die Ausrüstung den wachsenden Datenmengen nicht mehr gerecht wird und eine Erweiterung des LANs ansteht. Die technische Grundlage einer Kontrolle der Switches und Router bilden die Verfahren "Remote Monitoring" (RMON) und "Switch Monitoring" (SMON).
RMON entstand in den Zeiten des Hubs. Das Protokoll wurde vom Normierungsgremium "Internet Engineering Taskforce" (IETF) zum Standard erklärt und existiert in den zwei Versionen "RMON-I" und "RMON-II". Zunächst wurde die Norm primär für Ethernet-Umgebungen und LAN-Segmente spezifiziert. Bei RMON-I werden die Daten auf dem Layer-2 (Data Link Layer) des OSI-Modells (Open Systems Interconnection) gesammelt, damit sie anschließend für die Analyse zur Verfügung stehen. RMON-II hingegen ermittelt zusätzliche Eigenschaften, die auch den Layer 3 und den Layer 4 betreffen.
Überwachungstechnik für VLANs
Bereits bei der Einführung von RMON gab es Bestrebungen, auch "geswitchte" Netze zu analysieren. Dies ist prinzipiell mit den Mechanismen des RMON-Standards möglich. Jedoch bringen Netzarchitekturen wie "Virtual LANs" (VLANs), Multilayer-Switches mit verschiedenen Prioritätsebenen und "Aggregated" Links logische Interfaces ins Spiel, die RMON nicht mehr auslesen kann.
SMON entstand aus der Notwendigkeit heraus, logische Interfaces zu erfassen. Grundgedanke von SMON ist es, ein weiteres Bussystem zu implementieren, das unabhängig vom eigentlichen Nutzdatenbus der Backplane arbeitet und zum Sammeln der notwendigen Messwerte und Probewerte dient. Die Trennung stellt sicher, dass das Monitoring nicht die Bandbreite der primären Backplane beeinträchtigt.
Bei einem Switch tritt jeder Port als ein eigenes Segment auf und hat dementsprechend auch seine eigenen RMON-Werte. Diese lassen sich für jeweils ein Gerät zusammenfassen. Mit dieser Vorgehensweise ist es jedoch unmöglich, VLANs zu erfassen, die über mehrere Ports gehen und sich dabei gegenseitig überlappen können. Auch Broadcast- und Multicast-Pakete bereiten Probleme bei der Kontrolle. Schließlich erhöht das Sammeln und spätere Zusammenfassen der RMON-Werte die Prozessorlast und führt zu Verzögerungen, weil die CPU jeden Port einzeln abfragen muss, um Gesamtstatistiken zu erhalten. Gleichzeitig überwacht sie die Alarmwerte und erzeugt gegebenenfalls Traps oder Logs.
Die SMON-Objekte erweitern das RMON-Protokoll um eine "Port-Copy"-Funktion und um Statistikfunktionen zu VLANs und Übertragungsprioritäten.
SMON für Layer-3
Das durch den IETF-Standard "RFC 2613" definierte SMON-Verfahren erfasst ähnlich RMON-I nur Informationen über den Layer 2. Diese genügen aber nicht, um Effekte wie "Broadcast"- oder "Multicast-Stürme" zu erkennen. Gerade der zunehmende Einsatz von Serverclustern und das Loadbalancing von Firewalls bringen einen erhöhten Multicast-Verkehr mit sich. Und Netzwerksuchdienste, die auf Broadcast-Basis arbeiten, und Redundanzmechanismen wie "Virtual Router Redundancy Protocol" (VRRP) können kritische Broadcast-Fluten auslösen, die die Perfor-mance von Firmenanwendungen beeinträchtigen.
Peer-to-Peer-Beziehungen zwischen leistungsfähigen PCs im LAN und im Internet haben das klassische Client-Server-Modell in der Bandbreitendisziplin überholt. Daher sollten sie bei der Netzüberwachung nicht übersehen werden. Peer-to-Peer-Übertragungen lassen sich aber nur mit weitergehenden Matrixdarstellungen erfassen und in den Griff kriegen. Um auf höheren Layern die Netz-, Server-, Workstation- oder Applikationsperformance zu überwachen, bedienen sich die Hersteller verschiedener, proprietärer Erweiterungen, weil SMON-II noch nicht als Standard definiert ist. Die dabei eingesetzten Objekte sind von ihrer Struktur dem RMON-II-Verfahren ähnlich und berücksichtigen auch virtuelle Interfaces, die zum Beispiel ein Subnetz oder einen IP-Port darstellen. SMON-II ermittelt Werte zur Quality-of-Service-Technik "Diffserv", zu Layer-3-Multicasts, Paketverzögerungen, Jitter und Paketverlusten auf Applikationsebene.
Die über SMON gesammelten Informationen stehen über das SNMP-Protokoll (Simple Network Management Protocol) dem Netzmanagementsystem zur Verfügung. Der SNMP-Manager wertet die Daten in einer geräteübergreifenden "Enterprise-Statistik" aus und ermittelt Netzkenngrößen über die Performance und die Auslastung. Der Administrator kann zu allen Werten Grenzen definieren, die beim Überschreiten ein SNMP-Trap auslösen.
Durch die Überwachung der Kapazität von Switches, der Auslastung von Uplink-Ports und der Server- und Firewall-Ports erkennt der Systemverwalter frühzeitig Engpässe im Netzwerk, wenn er die Limits richtig setzt; zum Beispiel so, dass er bei 80prozentiger Auslastung der Switches ein Warning Trap erhält. SMON kann in vielen Fällen den Einsatz eines teuren Sniffers ersetzen und ermöglicht die Darstellung von Messgrößen, die ohne das Protokoll nur schwer erfassbar sind. (kpl)
Zur Person
Michael Weingärtner
ist Convergence Solution Architect bei Avaya Deutschland.