Auf Fehlersuche

19.04.2002
Durch die zunehmende Segmentierung von geswitchten Netzwerken werden neue Analysesysteme nötig - nicht nur um den störungsfreien Betrieb eines Netzes zu erreichen, sondern auch um Störungen schnell zu finden und zu beheben.

Von: Oliver Thewes

In heutigen Netzen, wo jeder einzelne Switchport ein Segment darstellt, ist es teuer, ein Netz flächendeckend zu überwachen. Immer noch sind die Ursachen für viele Fehler auf den untersten zwei Schichten des OSI-Modells zu finden: Defekte Netzwerkkarten, Kabel und Ports, zu hohe Auslastung des Netzwerkes durch Broadcasts und ähnliches. Zwar bleibt durch die meist starke Segmentierung der Fehler häufig räumlich beschränkt, trotzdem ist es notwendig, ihn schnell zu lokalisieren und zu beheben. Dafür haben sich in der Praxis zwei Lösungsansätze als brauchbar erwiesen: Zentrales Management aktiver Komponenten mittels SNMP (Simple Network Management Protocol) oder mittels RMON 1 und 2 (Remote Monitoring).

Monitoring mittels SNMP

Aktuelle Switches und andere aktive Komponenten bieten über SNMP ausreichende Statistik und Monitoring-Funktionen, um die oben beschriebenen Fehler schnell zu finden und zu beheben. So kann SNMP zum Beispiel kritische Portzustände, Server, Drucker oder Applikationen überwachen. Neben der bloßen Benachrichtigung bei mangelndem Speicherplatz auf einem Server oder der Überschreitung von Schwellwerten lassen sich mittels SNMP auch Berichte über beliebige Parameter und Zeiträume erstellen. Von Herstellern aktiver Komponenten sind häufig auch Netzwerkmanagement-Lösungen erhältlich. Sie sind auf die Parameter der eigenen Geräte abgestimmt und leiden fast immer unter dem Nachteil, dass sie keine heterogenen Netzlandschaften überwachen können. Herstellerunabhängige Angebote wie zum Beispiel "TheGuard!" von Realtech oder "OpenView" von Hewlett-Packard sind meist teurer, bieten aber umfangreichere Funktionen.

Management-Lösungen übertragen Daten mittels SNMP unkomprimiert, ungesichert und unverschlüsselt. Zwar gibt es mit SNMP v3 eine aktualisierte Version, die fast alle Nachteile beseitigt, de facto ist aber in fast allen aktiven Komponenten nur Version 1 implementiert.

Monitoring und Analyse mit RMON 1 und 2

RMON 1 besteht aus neun beziehungsweise zehn Gruppen. Von diesen werden meist nur vier unterstützt. Komplettes RMON 1 bietet neben den Statistikfunktionen, wie zum Beispiel Netzlast, ein- und ausgehende Bytes, Pakete oder physikalische Fehler, auch detaillierte Informationen auf Layer 2 über so genannte Toptalker, Protokollverteilungen und Konversationsbeziehungen. Toptalker sind hochfrequentierte Netzabschnitte. Ebenso lassen sich Daten mitschneiden und mit dem lokalen Protokollanalysator auswerten. RMON 2 bietet diese Möglichkeiten zusätzlich auf Layer 3. Für eine volle RMON 1 und 2-Unterstützung sind bei den meisten Anbietern teure Zusatzmodule nötig. Mittlerweile haben fast alle Hersteller den Vertrieb von Hardware-RMON-Probes eingestellt. Probes überwachen den Datenverkehr in entfernten Netzsegmenten und übermitteln die aufgezeichneten Pakete an die zentrale Managementstation. RMON ist eine Untergruppe des SNMP-Protokolls. Es leidet unter den gleichen Nachteilen bei der Übertragung - sehr hohe Netzlast und geringe Sicherheit - wird aber im Gegensatz zu SNMP auf absehbare Zeit keine Weiterentwicklung erfahren. Zusätzliche RMON-Gruppen beziehungsweise Erweiterungen wie SMON (Switch Monitoring) haben sich weder im Gerätebereich noch im Managementbereich auf breiter Fläche durchgesetzt.

Trotz der Nachteile beider Ansätze gibt es wenig Alternativen. Durch die starke Segmentierung der Netzwerke und deren zunehmende Bedeutung für Unternehmen sind sie nahezu unverzichtbar. Netzwerkmanagement kann immer nur Hinweisgeber sein, RMON-Analyse ist immer nur ein unterstützender Bestandteil der Netzwerkanalyse. Deswegen ist es auch weiterhin nötig, mittels Analyzer direkt zu messen, um Ursachen für Störungen und Fehler zu finden.

Die interessantesten Messpunkte sind Uplinks zwischen Switches oder zu Routern und Serveranbindungen. Diese sowie Server- und Routeranbindungen sind immer häufiger Fast-Ethernet-Full-Duplex- oder Gigabit-Links. Mit einem auf einem Notebook oder PC installierten klassischen Protokollanalysator lassen sich diese Verbindungen aufgrund der hohen Geschwindigkeiten nicht mehr ohne weiteres messen. Außer den teuren Hardwareanalysatoren, die neben Ethernet und Fast-Ethernet auch Gigabit-Ethernet im Full-Duplex-Verfahren messen, gibt es jedoch noch andere Möglichkeiten zur Netzanalyse.

Mess-Hubs

100-MBit/s-Full-Duplex-Links lassen sich häufig problemlos auf Halb-Duplex umstellen, zum Beispiel wenn es sich um Server- oder Routeranbindungen handelt. Mittels eines eingefügten Hubs zwischen Switch und Router beziehungsweise zwischen Switch und Server lässt sich nun die Kommunikation analysieren. Dabei ist der Analysator auf dem Hub angeschlossen. Auf stark ausgelasteten Links kann es allerdings jetzt zu Problemen kommen: Server und Uplinks, die mit Gigabit-Ethernet angeschlossen sind, lassen sich aufgrund der hohen Geschwindigkeit so nicht analysieren. Der Einsatz von Hubs empfiehlt sich deshalb für Messungen an PCs, Routern oder wenig ausgelasteten Servern.

Spiegel-Ports

Sollte es nicht möglich sein, den Link umzustellen, lässt er sich auf den meisten managebaren Switches spiegeln: Dieses Verfahren ist unter den Namen Port Mirroring, Span-Ports beziehungsweise Roving-Analysis-Ports bekannt. Einige Hersteller von Switches bieten mittlerweile auch die Möglichkeit, komplette VLANs auf einen Analyseport zu spiegeln. Wenn allerdings zehn 100-MBit/s-Ports eines VLANs auf einem 100-MBit/s-Analyseport zusammengeführt werden, kann das zu Lastproblemen führen. Unter Umständen ist die Menge der Daten einer einzelnen 100-MBit/s-Full-Duplex-Verbindung schon zu groß, um sie auf dem Analyzer-Port auszugeben. In diesem Fall empfiehlt es sich, auf einen Gigabit-Port zu spiegeln. Die meisten Softwareanalysatoren unterstützen mittlerweile auch Gigabit-Ethernet. Somit lassen sich auch Gigabit-Ports messen, allerdings nur mittels Portspiegelung, da es keine Gigabit-Hubs gibt. Jedoch ist ein normaler Laptop oder PC mit einer Gigabit-Karte kaum in der Lage, einen stark ausgelasteten Gigabit-Link zu analysieren. Die meisten Gigabit-Uplinks sind jedoch in der Praxis so schwach belegt, dass sie sich sogar auf einen 100-MBit/s-Port spiegeln lassen. Zu bedenken ist, dass bei der Portspiegelung physikalische Fehler nicht mittransportiert werden. Um diesen Nachteil zu umgehen lassen sich alternativ Taps, auch Splitter genannt, einsetzen.

Link-Splitter

Splitter, die zum Beispiel von Shomiti oder Network Critical erhältlich sind, lassen sich in Full-Duplex, aber auch in Half-Duplex-Verbindungen einfügen und sind für alle Teilnehmer transparent. Der Splitter teilt eine Leitung, die aus einer Sende- und Empfangsrichtung besteht, in zwei separate Strecken auf. Auf den zwei Analyseports des Taps kann der Netzverwalter jetzt jederzeit die Sende- oder die Empfangsrichtung separat messen. Ursprünglich waren Taps für Hardwareanalysatoren gedacht. Die beiden Analyseports des Splitters wurden mit den zwei Interfaces des Analyzers verbunden. Dieser fügte die beiden separaten Datenströme wieder zusammen und synchronisierte sie gleichzeitig. Heutige Softwareanalysatoren verfügen jedoch nicht über die Möglichkeit, mehrere Adapterkarten zu synchronisieren und deren Daten zusammenzufassen. Allerdings können sich Anwender helfen, indem sie die beiden Tap-Ports auf einem Hub wieder zusammenfügen. So lassen sich mit einem Softwareanalysator zum Beispiel beliebige 10/100-MBit/s-Full-Duplex-Links für Kupferverkabelungen messen.

Taps gibt es auch für Single- oder Monomode-Lichtwellenleiter, die Gigabit übertragen. Auch für Gigabit über Kupfer sind sie mittlerweile erhältlich.

Expertensysteme

Fast alle Analyzer haben einen so genannten Expert-Modus, der auf Broadcast-Stürme hinweist, Verbindungen analysiert und Fehler darin sucht. Die Komplexität solcher Systeme ist je nach Anbieter sehr unterschiedlich: Sie reicht von der simplen Suche nach Prüfsummenfehlern in IP- und TCP-Paketen über die Auswertung von ICMP-Paketen bis hin zur komplexen Verbindungs- und Laufzeitanalyse auf Applikationsebene. Einige Expertensysteme visualisieren auch die Daten-Frames einer Verbindung, sodass sich Laufzeitprobleme und Übertragungsverluste visualisieren lassen. Kein Expertensystem kann das Wissen über Protokolle und über Netzwerke ersetzen. Es nimmt dem Netzwerkadministrator aber viel Arbeit ab, wenn es darum geht, in großen Datenmengen Fehler und Auffälligkeiten zu finden.

Fazit

Die Wahl der Messmethode richtet sich sicherlich auch nach dem Preis. Es kommt jedoch in erster Linie darauf an, für verschiedene Einsatzmöglichkeiten den richtigen Analyzer zu wählen. (awu)

Zur Person

Oliver Thewes

hat langjährige Erfahrung im Bereich Netzwerkanalyse in Unternehmensnetzwerken und arbeitet für die Magellan Netzwerke GmbH in Köln als Consultant für Netzwerkmanagement und Netzwerkanalyse.