Netzwerkprobleme mit Wireshark suchen
Es gibt auf dem Markt viele Protokollanalysatoren, doch nur ein Wireshark. Wireshark ist das beste und umfassendste Produkt zur Protokollanalyse und zur Fehlersuche im Netzwerk. Das wunderbare an Wireshark ist, dass es als Open Source auch noch kostenlos erhältlich ist.
Druckversion Netzwerkprobleme mit Wireshark suchen
Ethernet-Netzwerke laufen über längere Zeiträume bemerkenswert problemfrei. Das lullt die IT-Administratoren ein und gibt ihnen ein falsches Gefühl der Sicherheit. Die Katastrophen können jederzeit eintreten und treten immer dann auf, wenn man sie überhaupt nicht gebrauchen kann.
Einige der schwersten Netzwerkprobleme sind die so genannten Broadcast-Stürme. Einen Broadcast-Sturm kennzeichnet die starke Anhäufung von Broadcast- und Multicast-Verkehr in einem Rechnernetz. Im Endstadium eines Broadcast-Sturms können keine neuen Netzwerkverbindungen mehr aufgebaut werden und bestehende Verbindungen werden möglicherweise unterbrochen. Eine fehlerhafte oder falsch konfigurierte Netzwerkkomponente überschwemmt dabei das Netzwerk mit Broadcast-Verkehr. Broadcast-Stürme haben die unangenehme Eigenschaft, sich selbst zu verstärken und dauern so lange an, bis das Netzwerk bzw. die darin installierten Koppelkomponenten vollständig heruntergefahren werden Die häufigste Ursache für Broadcast-Stürme ist die redundante Verkabelung mit zwei oder mehr Uplinks zwischen zwei Switches. In einem solchen Fall werden Broadcasts und Multicasts auf alle Ports weitergeleitet mit Ausnahme des Ports, von dem der Verkehr kam. Dadurch wird eine Schleife erzeugt und die Switches leiten die Broadcasts des jeweils anderen Switches weiter.
Eine weitere Bedrohung für die korrekte Funktion der Netze sind mit Malware infizierte Computer. Diese schicken eine Flut an E-Mails aufs Netz oder versuchen sich über das Netzwerk hinweg zu replizieren. Ein infizierter Computer kann dazu führen, dass sich der Internet-Verkehr verlangsamt und die Kommunikation fast unmöglich macht.
Manchmal belegen einzelne Nutzer oder Applikation so viel Bandbreite wie diese nur bekommen können. Dies hat negative Auswirkungen auf andere Benutzer im Netzwerk, da deren Daten nur ruckelnd und zuckelnd über das Netz übermittelt werden. Ursachen für das vollständige Aufbrauchen der verfügbaren Bandbreite können Peer-to-Peer File-Sharing-Programme, ein übermäßiger Bandbreitenkonsum durch Streaming-Audio oder Video-Downloads sein.
Will man alle Vorgänge im Netz vollständig verstehen, liegt eine wahrliche Herkulesaufgabe vor dem Troubleshooter. Aber mit ein paar einfachen Werkzeugen und ein wenig gesunden Menschenverstand, ist es sogar für einen Anfänger möglich, die grundlegenden Probleme im Netzwerk zu analysieren.
Eines der wichtigsten Netzwerkwerkzeuge für jeden IT-Administrator ist der Wireshark (www.wireshark.org). Wireshark ist ein kostenloser Netzwerkanalysator, mit dem alle Pakete im Netzwerk aufgezeichnet und die Paketinhalte detailliert analysiert werden können. Die neueste Variante von Wireshark unterstützt auf der physikalischen Ebene nicht nur Ethernet, DSL, sondern auch die WLAN (802.11) Funktionen. In Sachen Protokolldekodierung sind alle wichtigen Protokolle integriert. Der Umfang reicht von der TCP/IP Familie, über die proprietären Microsoft- und Cisco Protokolle, bis hin zur Unterstützung der Voice over IP Mechanismen.
Wireshark ist ein sehr cooles Tool und zeigt dem Administrator alle Daten auf dem Netzwerk auf. Beim Start von Wireshark sollte man sich nicht durch die Vielfalt der Informationen einschüchtern lassen. Der Analysator ist extrem leistungsstark und bietet eine Vielzahl von Optionen. Es gibt allerdings ein paar Grundlagen, die man kennen muss, bevor man mit der Netzanalyse beginnen kann.
Zuerst muss man wissen, welche Daten tatsächlich überwacht bzw. analysiert werden können. In den Tag als der "Shared Media-LANs" konnte der gesamte Verkehr an allen Ports abgegriffen werden. Ein "Shared Media-LAN" basiert auf einem gemeinsamen Kabelmedium. Dieses stellt den gemeinsamen Kommunikationskanal im Netzwerk dar. Über diesen Kommunikationskanal übermitteln alle angeschlossenen Clients und Server ihre Daten. Ein Analysator agiert in einem solchen Netzkonstrukt als stiller Beobachter, da von diesem Gerät alle auf dem Netz übermittelten Pakete empfangen werden. Aus der Paketanalyse lassen sich alle Sender, Empfänger, Protokolltypen und viele weitere Details ausfiltern. Für das Verständnis von "Shared Media-LANs" ist wichtig zu verstehen, dass immer nur ein Paket auf dem Medium pro Zeiteinheit transportiert werden kann!
Ein Hub stellt ein "Shared Media-LAN" auf engstem Raum dar und unterscheidet sich von der Funktion her nicht von den klassischen Netzkonstrukten. Jedes Endgerät erhält über einen eigenen physikalischen Port den Zugang zum Netzwerk. Dieses Netzwerk simuliert der Hub. Bei Kurzschlüssen oder bei Kabelunterbrechungen isoliert der betreffende Port den angeschlossenen Rechner vom Rest des Netzes und verhindert, dass das gesamte Netz von dem Kabelfehler in Mitleidenschaft gezogen wird.
Datenpakete und auch Fehler breiten sich in einem shared Medium mit annähernder Lichtgeschwindigkeit aus. Von Vorteil für die Analyse ist, dass die Platzierung des Analysators im Grunde gleichgültig ist. Nachteilig für das gesamte Netzwerk ist jedoch, dass auftretende Fehler auch das gesamte Netzwerk betreffen, und im schlechtesten Fall auch den gesamten Datenverkehr aller Stationen in Mitleidenschaft ziehen können. Wird der Analysator zur Überwachung an einen beliebigen Port des Hubs angeschlossen, lassen sich alle Datenströme aufzeichnen und analysieren. Der Hub arbeitet somit als Repeater (Verstärker), der physikalische Segmente terminiert, jedoch keinerlei Einfluss auf den Inhalt der Datenpakete nimmt.
Hat eine Station im LAN festgestellt, dass das Übertragungsmedium frei ist, übermittelt diese die Daten über das LAN-Segment an den Empfänger. Ist im gleichen Moment eine andere Station derselben Meinung und sendet diese zeitgleich ein Paket auf das Netz, so prallen die beiden Pakete zusammen und es entsteht eine Kollision. Findet eine solche Kollision statt, sorgen die sendenden Netzadapter für die Wiederholung der Nachrichten. Erst ab der kritischen Lastgrenze von 50 bis 70 Prozent der maximalen Übertragungsbandbreite (10 oder 100 MBit/s) kommt es beim Ethernet zu echten Durchsatzproblemen bzw. zum Verlust der Daten. Mit Hilfe eines Netzanalysators lassen sich die im Netz auftretenden Lasten und Fehler leicht ermitteln.
Der Einsatz von Switch-Systemen gehört heute zu den Standards in Netzwerken. Mit der Installation von Switches wird die Aggregat-Bandbreite (Gesamtbandbreite aller Ports) sofort um das X-fache erhöht. Die Separierung des Verkehrs führt dazu, dass ein Messgerät bzw. der Analysator nicht mehr bedenkenlos an jeden Port angeschlossen werden kann. Die Separierung des Datenverkehrs durch den Switch hat zur Folge, dass an einem Switch-Port nur noch folgender Verkehr gemessen werden kann:
- Unicast-Pakete die für das am Port angeschlossene Endgerät bestimmt sind,
- Unicast-Pakete mit unbekannter (nicht in der Switch-Tabelle eingetragener bzw. von dieser gelernter) MAC-Adresse
- Broadcast-Pakete.
Somit werden in geswitchten Netzen die für die Datenanalyse notwendigen Daten jedoch nicht an jeden Port übertragen. Wird zusätzlich noch die VLAN-Technologie im Netzwerk genutzt, ist selbst der Broadcast-Verkehr nur auf die Ports des betreffenden VLANs beschränkt. Von einer Transparenz des Netzverkehrs kann also nicht mehr die Rede sein.
Daher müssen in geswitchten Umgebungen Alternativen gefunden werden, die eine Ermittlung der Datenströme ermöglichen. Die jeweiligen Lösungsmodelle haben jedoch neben vielen Vorteilen auch einige gewichtige Nachteile.
Auf den ersten Blick bietet sich zur Lösung des Mess- und Analyseproblems in geswitchten Umgebungen der Abgriff der Daten direkt auf der physikalischen Ebene an. Bei diesem Verfahren wird ein Hub zwischen das zu messende Gerät (Server, Client PC, Etagen-Switch) und den betreffenden Switch-Port geschaltet. Damit wird mit einem simplen Trick ein Shared-Media-Umfeld wiederhergestellt. Dieses Verfahren weist nur den Unterschied auf, dass das Messgerät nur bestimmte Datenströme messen kann und nur den Verkehr von und zum Server misst. Bei dieser Methode sind jedoch einige Fakten zu berücksichtigen:
- Die Polarität des Netzwerkkabels vom Hub zum Switch muss richtig konfektioniert sein (ausgekreuztes Kabel oder MDI-X Port).
- Die Anwendung bzw. der Netzanschluss muss zulassen, dass die Netzwerkverbindung kurz geöffnet wird, um den Hub dazwischen zu schalten. Dieses Einschalten in die Verbindung kann oft nur zu definierten Wartungszeiten erfolgen und kann den Ablauf des Troubleshootings entscheidend behindern.
Mit dem Einbringen eines Hubs in den Kommunikationspfad wird nicht nur die physikalische Bedingung der Verbindung verändert, sondern auch das gesamte Kommunikationsverhalten. Wird ein Server oder ein Client-PC im Vollduplex-Modus an den Switch angeschlossen, und anschließend ein Hub in die Verbindung eingeführt, kann per Definition der Datenverkehr nicht mehr im Vollduplex-Modus übertragen werden. Ein Hub unterstützt nicht den Vollduplex-Modus. Dies kann dazu führen, dass ein fest auf den Voll-Duplex-Modus eingestellter Switch-Port nicht mit einem Hub-Port im Halbduplex-Modus zusammen geschaltet werden kann. Arbeitet der Switch im Autonegotiation-Modus und kann sich dadurch automatisch an die Bedingungen des Kommunikationspartners anpassen, verändern sich jedoch einige wichtige Rahmenbedingungen der Verbindung. Hubs können versehentlich falsche Analyseinformationen liefern. Somit weist die Hub-Methode einige gewichtige Nachteile auf:
- Es kann immer nur ein Netzsegment pro Zeiteinheit gemessen werden. Will man mehrere Server gleichzeitig überwachen, sind weitere Messgeräte bzw. Analysatoren erforderlich.
- Für Messungen auf Vollduplex-Verbindung ist die Hub-Variante ungeeignet.
- Um die Messung durchführen zu können, muss die Verbindung kurzzeitig unterbrochen werden. Dies bedeutet unter Umständen für die Nutzer der Serversysteme einen kurzzeitigen Verbindungsabbruch
- Fehlersituationen, die an den anderen Ports des Switches auftreten (CRC-Fehler, Runts etc.) bleiben dem Analysator zumeist verborgen, da der Switch durch seine Filterintelligenz verhindert, dass defekte Pakete an andere Ports weitergeleitet werden. Dies gilt ebenso für Überlasten, Protokollfehler etc.
Moderne Switch-Systeme stellen für das Messen und die Analyse im Netzwerk in der Regel die Spiegelung von Switch-Ports mit Hilfe der Mirror-Port-Funktion. Dadurch wird der jeweils zu untersuchende Link auf einen anderen Port des Switches, an dem der Analysator angeschlossen ist, gespiegelt. Einige Hersteller sind dabei sogar in der Lage, den Verkehr mehrerer Switch-Ports auf einem Mirror/SPAN-Port auszugeben. Der Mirror Port wird auch SPAN (Switch Port Analyser) Port oder Maintenance Port bezeichnet.
Die Weiterleitung der zu analysierenden Daten auf den Mirror/SPAN-Port sollte man nur nutzen, wenn dieser die Datenmengen der gespiegelten Ports auch verkraftet. Ist dies nicht der Fall, gehen Pakete verloren. Auf der sicheren Seite ist man, wenn der Spiegel-Port dieselbe Bandbreite aufweist wie der Quell-Port. Für längere Burst-Situationen eignet sich diese Methode allerdings nicht, da der Analysator über den Spiegel-Port nur die Hälfte der maximal möglichen Vollduplex-Bandbreite aufzeichnen kann. Darüber hinaus beeinträchtigt das Mirroring die Switch-Performance, da der Switch für die Spiegelung alle Pakete duplizieren muss. Auch der gespiegelte Port kann in seiner Performance einbrechen und die Fehlersuche produziert erst wirklich Probleme. Zum anderen verzerrt das Port-Mirroring die Analyse, weil ein Switch defekte Pakete automatisch verwirft. Oft werden auch nur die Pakete eines VLANs gespiegelt. Auch muss darauf geachtet werden, dass der Mirror-Port genügend Bandbreite hat. Also keinen 100BaseT-Port auf einen 10BaseT-Port spiegeln. In einem solchen Fall spiegelt der Switch nur einen Teilmenge der Pakete und macht die Datenaufzeichnung vollkommen wertlos. Bei der Spieglung mehrerer Ports auf einen Mirror-Port kommt es zusätzlich zu Verzögerungen, da Pakete die gleichzeitig an dem Ports ankommen unter Umständen in einer anderen Reihenfolge am Mirror-Port ausgegeben werden.
Die in Switches integrierten Mirror- und SPAN-Ports verhindern die Durchleitung fehlerhafter Datenpakete und können Messergebnisse verfälschen. Für die genaue Erfassung der Messdaten setzt man heute so genannte TAPs (Test Access Points) ein. TAPs werden in der Literatur auch manchmal als Link-Splitter bezeichnet. Diese Geräte werden direkt in die zu überwachende Netzverbindung eingeschleift. TAPs arbeiten absolut passiv und erzeugen keine Fehler und funktionieren auch bei einem Stromausfall. Ein TAP dupliziert (hochohmige Anschaltung) alle Pakete und erzeugt aus einem Vollduplex-Link zwei Halbduplex-Datenströme mit dem Rx- und dem Tx-Verkehr. Dadurch muss der Netzanalysator mit zwei Netzwerkkarten ausgerüstet sein. Die Analysesoftware fügt die beiden Datenströme anschließend wieder zu einem Datenstrom zusammen.
Nach dem Start von Wireshark lässt sich der Netzverkehr aufzeichnen. Hierzu wird im Dialogfeld "Capture Options" das Interface eingestellt, über welches die Aufzeichnung der Daten erfolgen soll. Neben der Netzwerkkarte lassen sich in diesem Menüpunkt folgende wichtige Optionen einstellen:
- Enable Network Name Resolution: wandelt alle IP-Adressen über DNS in Namen um. Dauert u.U. sehr lange. Daher diese Option deaktivieren!
- Update list of packets in real time: in Kombination mit Automatic scrolling: Wireshark zeigt alle Pakete an, sobald sie aufgezeichnet wurden
- Limit each packet to xx bytes: erlaubt die reine Aufzeichnung der Header und sorgt für die Unterdrückung des meist langen Datenteils.
- Capture Filter: erlaubt es, Pakete schon vor der Aufzeichnung zu qualifizieren. Unerwünschte Pakete gelangen dann gar nicht erst in den Speicher.
Unter File -> Save erscheint das entsprechende Menü, in dem man Pfad und Dateiname einstellt.
Der Protokolldekoder stellt Pakete in der allgemein üblichen Form, in drei Bereichen dar. Oben findet man die Übersicht - eine Zeile pro Paket -, in der Mitte wird ein Paket im Detail dekodiert und unten sieht man die Hex-ASCII Darstellung des Paketes. Die Bereiche lassen sich anpassen und über Edit -> Preferences -> Layout anders anordnen oder ganz ausblenden.
Die Paketübersicht zeigt Paketnummer, Zeit, Quell- und Zieladresse, Protokoll und Zusammenfassung an.
Sobald man sich darüber im Klaren ist, welche Art von Datenverkehr man sucht, kann man mit den Filterfunktionen die jeweiligen Daten bzw. Pakettypen aus den aufgezeichneten Datenströmen ausfiltern. Über das Menü "Optionen" lassen sich auch die Länge der Aufzeichnungen bzw. die aufzuzeichnenden Datenmengen konfigurieren. Diese Funktion ist sehr praktisch, wenn man mit Wireshark über einen längere Zeitraum messen will. Bei solchen Langzeitmessungen können die aufgezeichneten Datenmengen unüberschaubar groß werden.
Die Herausforderung für einen Anfänger mit Wireshark besteht darin, die aufgezeichneten Daten sinnvoll weiter zu verarbeiten. Für viele Messungen benötigt man eher statistische Analysen als genaue Kenntnis der Paketinhalte (Auslastung einer Strecke im Tagesverlauf, Top-Talker oder mittlere und maximale Antwortzeit eines Rechners. Wireshark analysiert hierzu seine Trace Files statistisch. Im Menü Statistics findet man:
- IO Graphs: stellt bis zu fünf Auslastungskurven in einem Diagramm dar. Man kann für jeden Graphen beliebige Filter setzen. Es lassen sich sogar beliebige Parameter als Funktion der Zeit darstellen.
- Conversation list: zeigt alle Kommunikationspaare des ausgewählten Protokolls.
- Service response time: rechnet kleinste, mittlere und längste Antwortzeiten von Layer 7 Protokollen aus.
Fazit
Hat man sich in die etwas gewöhnungsbedürftige Syntax und Befehle von Wireshark gewöhnt, dann ist es eine Wonne mit Wireshark zu arbeiten. Es ist ein unglaublich flexibles und nützliches Werkzeug, das jedem Administrator bei der Problembehebung und -Analyse im Netzwerk hilft.
