Zwei weitere Fallen
Es treten noch zwei weitere Fallen bei der Protokollanalyse auf. Die erste Falle stellt die Kommunikationsrichtung dar. Viele Hersteller haben ihre Switches kostengünstig aufgebaut. Diese Geräte verfügen nicht immer über die notwendige Logik für ein vollwertiges Port-Mirroring je Port. Solche Implementierungen führen dazu, dass von der Kommunikation ausschließlich die ausgehenden Kommunikationsströme über den Mirror Port weitergeleitet werden. Um auch die eingehenden Kommunikationsströme darstellen zu können, muss unter Umständen die Konfiguration des Mirror Ports angepasst werden. Bei einigen Switch-Produkten ist eine solche Umkonfiguration des Mirror Ports jedoch nicht immer möglich. In einem solchen Fall müssen Sie auf ein anderes Netzwerk-Interface ausweichen. Hierfür können Sie beispielsweise den ausgehenden Trunkport des nächstgelegenen Switches nutzen.

Ein weiteres Problem tritt bei zu niedriger CPU-Leistung von Switches auf. Aufgrund der für die Mirror-Funktion notwendigen CPU-Leistung kann ein Port-Mirror auf dem Trunk zum Stillstand des gesamten Switches beziehungsweise zu Fehlfunktionen auf diesem Gerät führen. Ebenfalls kann es passieren, dass sich unter vertretbarer CPU-Belastung immer nur ein Client-Interface spiegeln lässt. Diese Fallstricke sind vom Hersteller abhängig (es gilt die Regel: je kostengünstiger, desto mehr Probleme) und sollten in einer Vormessung untersucht werden. Abhängig von den Ergebnissen dieser Vormessung lässt sich dann die eigentliche Protokollanalyse planen.

Das passende Werkzeug
Bei der indirekten Messung von Datenströmen ist daher immer eine ausführliche Planung sinnvoll. Im Idealfall zeichnen Sie für den Ernstfall im Netzwerkplan die jeweiligen Kommunikationsrichtungen der zu analysierenden Anwendung ein. Hierzu definieren Sie die in Frage kommenden Testfälle – sprich, was soll analysiert werden? – und ermitteln die notwendigen Testpunkte im Netzwerk, an denen die Kommunikationsströme aufgenommen werden sollen.

Die direkte Messung ist zwar deutlich einfacher, kann jedoch dazu führen, dass eine nachträgliche Installation eines entsprechenden Werkzeugs (beispielsweise Wireshark) zum Stillstand oder Neustart des betreffenden Servers führt. Sie sollten daher beim Aufbau eines Servers auch diesen Aspekt bedenken und die notwendigen Analysewerkzeuge bereits von Anfang an mit auf dem Server installieren. Diese Lösung hat allerdings den Nachteil, dass ein Großteil der auf dem Server zur Verfügung stehenden CPU-Leistung von dem Analysewerkzeug beansprucht werden kann und unter Umständen Performance-Probleme bei den Anwendungen auftreten. Somit sollte der Einsatz des Analysewerkzeugs nicht kontinuierlich stattfinden und sehr wohl überlegt sein. In jedem Fall sind beim Einsatz von Analysewerkzeugen unabhängig vom Messverfahren die Bestimmungen des Datenschutzes einzuhalten.

Ein weiteres wichtiges Werkzeug zur Fehleranalyse ist der Ping. Es nutzt dabei das ICMP (Internet Control Message Protocol) und ist auf nahezu jedem Endgerät implementiert. Das Ping-Programm prüft dabei, ob von einem Quellrechner zu einem Zielrechner eine Verbindung zustande kommt. Die meisten Fehler (zumindest die relativ einfachen) können Sie mittels Ping finden und beheben. Ein erfolgloser Ping meldet sich normalerweise mit Fehlermeldungen. Diese geben wichtige Hinweise zur weiteren Fehlersuche:

• Unknown Host: Der Name des Zielrechners kann vom Name Service (DNS) nicht in eine IP-Adresse übersetzt werden. Als Ursache kommt ein Ausfall des Nameservers, ein falscher Rechnername oder eine ausgefallene Leitung zwischen Ihrem Rechner und dem Zielsystem in Frage. Ist die IP-Adresse des Zielrechners bekannt, wird im nächsten Schritt ein Ping an die betreffende IP-Adresse abgeschickt. Bei erfolgreichem Ping erfolgt die weitere Fehlersuche im Bereich der Namensdienste. Überprüfen Sie mit Hilfe von "nslookup", ob der Nameserver funktioniert und der Rechnername des Zielsystems existiert.
• Network Unreachable: Der lokale Rechner kennt keine Route zum Zielsystem. Wurde der Ping anhand der IP-Adresse abgesetzt, sollte der Test mit Eingabe des Rechnernamens erneut versucht werden. Hierdurch wird sichergestellt, dass Sie sich bei der Eingabe der IP-Adresse nicht vertippt oder eine falsche IP-Adresse genutzt haben. Ist für die Verbindung ein Routing notwendig, sollten Sie überprüften, ob der entsprechende Prozess arbeitet. Die Routing-Tabelle überprüfen Sie mit dem Werkzeug "netstat". Wird das statische oder das Default-Routing genutzt, müssen die betreffenden Einträge überprüft beziehungsweise komplett neu eingetragen werden. Ist kein Fehler zu finden, überprüfen Sie das Default Gateway.
• No Answer: Der Zielrechner antwortet nicht. Einige Implementationen von Ping melden "100% packet loss". Telnet meldet "Connection timed out"; sendmail liefert "cannot connect". Die Bedeutung dieser Meldungen ist dieselbe: Der Quellrechner verfügt über eine Route zum Zielrechner, jedoch erhält dieser keine Antwort auf die ausgesendeten Pakete. Dies kann an einem Ausfall des Zielrechners oder der Fehlkonfiguration eines der beteiligten Rechner liegen. Ebenso sind der Ausfall einer Leitung oder eines Routers sowie Routing-Probleme denkbar.

In letzterem Fall hilft nur gezieltes Debugging weiter: Die Konfiguration des lokalen Rechners muss mit Hilfe von netstat und ifconfig überprüft werden. Die Route zum Zielsystem testen Sie dabei mit dem Traceroute-Mechanismus aus. Die Fehlermeldungen "No Answer" und "Cannot Connect" sind Anzeichen für ein Problem, das in den unteren Schichten der Protokollhierarchie zu suchen ist. Deuten die Tests auf ein solches Problem hin, sollte das Routing sowie das betreffende Netzwerkinterface überprüft werden.

  <<Vorherige Seite                Seite 2 von 3                     Nächste Seite>>

Michael Engelhardt/dr/ln