Methoden für die Fehlersuche im Ethernet

Praktikable Ratschläge für Netzwerktechniker

30.04.2007 | Redakteur: Ulrike Ostler

Ein paar Minuten bei der Analyse von Symptomen können Stunden bei der Suche nach den falschen Problem sparen, besagt eine „Applikations-Notiz“ von Fluke Networks, Hersteller von Tools für die Netzwerkanalyse. Und tatsächlich liefert der Blick in die Praxis oft nützliche Ratschläge für die Suche, wenn es im Ethernet hakt.

Der Schlüssel jeder erfolgreichen Fehlersuche ist die Kenntnis des normalen Betriebszustands des Netzwerks. Nur so lässt sich schnell bestimmen, ob ein irreguläres Verhalten vorliegt. Deshalb studiert ein erfolgreich arbeitender Techniker zunächst einmal alle verfügbaren Daten.

Doch werden viele Netzwerkprodukte ohne ausreichende Leistungsspezifikationen, Hintergrundinformationen zur Betriebsweise oder Aufstellung der technischen Daten ausgeliefert. Das entbindet den Techniker jedoch nicht davon, sich um ein tiefgreifendes Verständnis der Funktion und Verwendungsweise aller Komponenten zu bemühen.

Darüber hinaus sollte immer gegenwärtig sein, dass ein Betriebszustand, der sich als schwerwiegender Defekt präsentiert, häufig auf eine unsachgemäße Verwendung, fehlerhafte Konfiguration oder einen Bedienerfehler zurückzuführen ist. Zudem lässt sich in jeder Netzwerkumgebung die Fehlersuche beschleunigen, indem gut geschulte Techniker mit den richtigen Tools ausgestattet werden und diese nach einer erprobten Methodik einsetzen.

Dazu gehört es auch, sämtliche Informationen und Symptome im Verhältnis zueinander und zum Netzwerkbetrieb zu untersuchen. Dann erst kann mit Hilfe von Tests nach den Ursachen geforscht werden.

Fünf Tipps für die erfolgreiche Fehlersuche

  • Dokumentieren: Mit einer aktuellen Dokumentation etwa mit Hilfe physikalischer und logischer Diagramme sowie Tabellen der Adressen-Host-Zuordnung zur Basis und zu den Prüfdaten der Netzwerkleistung sowie zum Inventar der Geräte und zu Konfigurationen lässt sich die „Erkennungsphase“ bei der Fehlersuche drastisch verkürzen – bspw. mindestens um die Zeit, in der ein Techniker beispielsweise versucht zu ermitteln, wie PCs ins Netzwerk eingebunden sind.
  • Informationen sammeln und Fehlersymptome analysieren: Bemühen Sie sich um ein wirkliches Verständnis der Symptome. Kann der Anwender das Problem vorführen, oder gelingt es, dieses nachzustellen? Wurde an der Workstation oder am Netzwerk etwas geändert kurz bevor das Problem auftrat?
  • Problem lokalisieren und isolieren: Betrifft die Störung ein ganzes Netzwerksegment oder nur einen einzelnen Client? Ein Client-bezogenes Problem lässt sich unter Umständen dem Netzwerk, den physikalischen Übertragungsmedien oder der Workstation zuordnen. Das Sammeln von Informationen und die Isolierung des Problems passiert übrigens oft zeitgleich.
  • Problem beheben und Lösung überprüfen: Ist das Problem erst einmal isoliert, dürfte es sich leicht identifizieren und beheben lassen. Bei Netzwerkgeräten empfiehlt es sich, die betroffene Komponente zu wechseln, zum Beispiel ein fehlerhaftes Patch-Kabel oder die Netzwerkkarte des Clients auszutauschen oder den Hub-/Switch-Port zu wechseln. Dieser Schritt wird abgeschlossen, indem der Anwender den Vorgang, bei dem das Problem auftrat, noch einmal ausführt, ohne dass sich das Problem wiederholt.
  • Durchgeführte Maßnahmen dokumentieren: Das entspricht der Rückkehr zu Schritt 1. Indem die Probleme und deren Lösung dokumentiert werden, entsteht nach und nach eine firmeninterne Wissensdatenbank, mit der sich in Zukunft ähnliche Probleme schneller lösen lassen.

Besuch beim Anwender unnötig

Es stellt sich dann die Frage: Ist ein Einsatz vor Ort wirklich notwendig? Auch wenn Betriebssysteme immer zuverlässiger werden, vertreten Helpdesk-Techniker nach wie vor die Maxime „Erst einmal den PC neu starten“. Mit gutem Grund: Tatsächlich löst ein Reboot mit Kaltstart so viele, ansonsten unerklärliche Probleme, dass dieser Schritt einfach unumgänglich ist.

Ein weiterer Vorteil besteht darin, dass der Techniker für diese Maßnahme seinen Arbeitsplatz nicht zu verlassen braucht. Gleiches gilt für die Abfrage bestimmter Daten vom Anwender. Denn die meisten Anwender sind in der Lage, eine Eingabeaufforderung zu öffnen und das Ergebnis eines IPCONFIG-Befehls in der Kommandozeile mitzuteilen. Dadurch kann in Erfahrung gebracht werden, ob der PC eine geeignete Adresse für das Subnetz besitzt, mit dem er physikalisch verbunden ist.

  • Ist der PC für DHCP (Dynamic Host Control Protocol) konfiguriert, meldet aber eine standardmäßige Windows-IP-Adresse (169.254.x.x), so kommuniziert der Client nicht mit dem DHCP-Server.
  • Tragbare Computer erhalten eine Adresse von dem Netzwerk, mit dem sie verbunden sind. Manchmal wird allerdings die DHCP-Lease eines Subnetzes beibehalten, wenn sich der Computer längst an einem anderen Ort befindet.

Der Anwender kann nun gebeten werden, eine neue Adresse anzufordern, indem er in die Eingabeaufforderung die folgenden beiden Befehle eingibt:

C:\ >ipconfig /release
C:\ >ipconfig /renew

Nach dem Erhalt einer neuen IP-Adresse soll der Anwender erneut versuchen, auf das Netzwerk zuzugreifen. Bestätigt der IPCONFIG-Befehl, dass der DHCP-Vorgang nicht ausgeführt werden kann, so arbeitet der Anwender wahrscheinlich mit einer statischen IP-Konfiguration. Nun wird die gemeldete IP-Adresse anhand der Netzwerkdokumentation überprüft.

Gibt der Anwender eine gültige IP-Adresse an, kann ihm vom Techniker-Schreibtisch aus ein Ping-Signal zugesandt werden. Reagiert der PC des Anwenders darauf, kann der Anwender unter Anleitung selbst prüfen, ob sich ein Vorgang über das Netzwerk ausführt lässt, etwa eine Webseite öffnen oder ein Ping- Signal an den lokalen Router senden. Nur wenn das Problem dann nicht gelöst werden kann, ist es Zeit, sich vor Ort zu begeben.

Prüfung vor Ort am Client

Sobald ein Techniker an der betroffenen Workstation eingetroffenist, fängt das eigentliche Sammeln von Informationen an. Vorab gehört es zum Prozedere den Anwender zu fragen, ob er einen Vorgang ausgeführt hat, der die Netzwerkleistung beeinträchtigen könnte.

Die Antworten sind jedoch nicht immer ergiebig, da sich der Anwender häufig gar nicht darüber im Klaren ist, welche alltäglichen Änderungen an der Workstation oder im Arbeitsbereich sich auf die Netzwerkleistung auswirken können. Oder er hat sehr wohl eine Ahnung, wodurch er das Problem ausgelöst haben könnte, möchte es aber nicht zugeben.

Dennoch sollte nach kürzlich vorgenommenen Änderungen gefragt werden – sogar die Umstellung von Büromöbeln oder die Installation eines neuen Bildschirmschoners kommen in Betracht.

Traue keinem

Sinnvoll ist es ebenfalls. die Tests zu wiederholen, zu denen der Anwender bereits telefonisch angewiesen wurde. Schließlich bestätigt ein erfolgreiches Ping-Signal an einen Netzwerk-Server oder ein Off-Net-Gerät sofort, dass die Workstation über Layer 3 mit dem Netzwerk verbunden ist.

Ist die Anbindung über Layer 3 dagegen problematisch, beginnt die Fehlersuche auf Layer 1. Bei einer unterbrochenen oder wiederholt aussetzenden Verbindung sendet ein Dauerping-Signal einen endlosen Strom von Echo-Anfragen an das Zielgerät. Die Reaktionszeiten für jedes erfolgreiche Ping beziehungsweise fehlende Reaktionen werden angezeigt.

C:\ > ping -t x.x.x.x

Zu lange Reaktionszeiten oder verloren gegangene Pings können mit einer Trace Route-Prüfung zum Zielgerät (TRACERT oder PATHPING) weiter untersucht werden. Mit Trace Route erfahren Sie, wo es auf dem Netzwerkpfad zu der Verzögerung oder dem Verlust kommt, und beginnen die Fehlersuche auf Layer 1.

C:\ > tracert x.x.x.x

oder

C:\ > pathping x.x.x.x

Konnte das Problem noch nicht isoliert werden, ist eine detaillierte Prüfung erforderlich. Nun stellt sich zunächst die Frage. Liegt es am Netzwerk oder am PC des Anwenders?

Hier ein Schnelltest:

  • Prüfung der Verbindung
  • Prüfung der Aktivität im Segment
  • DHCP als Hilfsmittel für die Diagnose
  • Ping-Signale an lokale und Remote-Geräte

So ist zu prüfen, ob die Kabel, über die der Client mit dem Netzwerk verbunden ist, richtig installiert und funktionstüchtig sind, um den Zugriff auf das Netzwerk zu ermöglichen.

Prüfung der Verbindung

Viele Netzwerktechniker meinen, das Aufleuchten einer Verbindungs-LED an der Netzwerkkarte lasse automatisch auf das Vorhandensein eines Verbindungssignals schließen. Dies ist aber nicht immer der Fall. Viele Verbindungs-LEDs werden durch eine Software des Host-Systems gesteuert und leuchten auf, wenn eine Netzwerkaktivität der höheren Schichten festgestellt wird.

Einige Netzwerkkarten sind außerdem mit Aktivitäts-LEDs ausgestattet, die Datenverkehr anzeigen und im Allgemeinen zuverlässiger als Verbindungs-LEDs auf das Vorhandensein einer Netzwerkverbindung schließen lassen. Keine dieser LEDs kann jedoch Aufschluss über die Geschwindigkeit oder Duplex-Einstellung geben.

Zur Prüfung einer Verbindung kann ein Prozess namens automatische Verbindungsaushandlung herangezogen werden. Die beiden Partner einer Übertragungsstrecke tauschen dabei Informationen über die jeweils unterstützte Geschwindigkeit und Duplex-Einstellung aus.

Dabei wird die Datenübertragung mit der höchsten Geschwindigkeit und besten Duplex-Einstellung, die beiden Partnern möglich ist, eingeleitet. Falls einer der Partner falsch konfiguriert ist oder fehlerhafte Treiber aufweist, können eventuell keine gemeinsamen Übertragungseigenschaften ausgehandelt werden, und die Kommunikation ist unstet oder schlägt gänzlich fehl.

Tools wie „Link-Runner“ Von Fluke Networks versuchen, sobald sie mit einem Netzwerkanschluss verbunden sind, mit dem Partner am anderen Ende eine Verbindung auszuhandeln – egal, ob es sich dabei um ein Verbindungsglied (Hub oder Switch) oder die Netzwerkkarte eines PCs handelt. Erfolg oder Misserfolg wird angezeigt.

Prüfung der Aktivität im Segment insgesamt

Darüber hinaus geben solche Geräte zugleich den Auslastungsgrad an. Allerdings dürfen die Netzwerktechniker nicht vergessen, dass bei einer Verbindung zu einem einzelnen Switch-Port (keinem gemeinsam genutzten Medium) möglicherweise der einzige Datenverkehr aus Broadcast-Frames besteht, die in Netzwerken mit geringem Verkehrsaufkommen manchmal nur sehr sporadisch auftreten.

Wird eine Shared Ethernet-Umgebung getestet, eine Umgebung mit Hubs statt Switches, arbeitet das Netzwerk höchstwahrscheinlich im Halbduplex-Betrieb. Halbduplex- Ethernet wird durch die Anzahl der Stationen, die simultan übertragen möchten, und die Größe der zu übertragenden Frames beeinträchtigt. Zu viele gleichzeitige Übertragungsversuche können aufgrund von Kollisionen drastische Leistungseinbußen verursachen.

Handelt es sich dagegen um ein Netzwerk, in dem jede Station mit einem eigenen Switch-Port verbunden ist, ist die Gefahr übermäßiger Kollisionen zu vernachlässigen. Kollisionen gehören zwar zum normalen Betriebsverhalten eines Halbduplex-Ethernets, führt jedoch ein Anstieg des Datenverkehrs zu einem erhöhten Kollisionsaufkommen, so werden Neuübertragungen erforderlich, und das Verkehrsvolumen wächst immer schneller. Das Ergebnis ist eine schroff abfallende Kurve der Netzwerkleistung, während die Anzahl der gesendeten Frames, Kollisionen und erneut übertragener Pakete in die Höhe schießt.

Die Anwender beginnen, Leistungseinbußen festzustellen, und wenden sich an den Helpdesk. In den meisten Netzwerken jedoch ist das Ethernet-Verkehrsaufkommen unerheblich, und das Problem ist daher an anderer Stelle zu suchen.

DHCP als Hilfsmittel für die Diagnose

Nun erfolgt eine erneute Ping-Prüfung – Das Prüf-Tool versucht, von dem DHCP-Server des Netzwerks eine IP-Adresse zu beziehen.

Die Ping-Prüfung ist eines der meistgebrauchten Diagnoseverfahren in der Geschichte der Netzwerktechnik. Sie gehört zu jedem marktüblichen, Internet-fähigen Betriebssystem und ist für die meisten Netzwerktechniker einer der ersten Schritte bei der Fehlersuche.

Denn die Ping-Prüfung ähnelt im Prinzip der Funktionsweise der Sonargeräte, die in der Meeresforschung genutzt werden. Das Ping-Programm übermittelt ein Signal (in der Regel eine ICMP-„Echo-Anforderung“), das vom Zielgerät in Form einer „Echo-Antwort“ zurückgegeben wird. Der Sender erfährt damit, ob das Zielgerät verfügbar ist und wie lange das Signal vom Sender zum Empfänger und zurück gebraucht hat.

DHCP ist üblicherweise eine Technologie auf Broadcast-Basis. Daher ist entweder ein eigener DHCP-Server für jedes Subnetz erforderlich (teuer und verwaltungsintensiv), oder DHCP-Relay-Proxies oder -Agenten werden genutzt, um Anforderungen und Antworten zwischen Clients und Servern weiterzuleiten, die sich nicht im gleichen physikalischen Subnetz befinden. Diese gerichteten Broadcast-Hilfsapplikationen an Routern werden üblicherweise von großen Unternehmen verwendet, die DHCP-Server nur an einem zentralen Standort installieren möchten.

Schlägt die automatische DHCP-Konfiguration mittels Prüfgerät oder Client fehl, könnte dies auf ein Problem beim DHCP-Relay-System hindeuten. Durch den Bezug einer DHCP-Adresse hingegen wird die Funktionalität der lokalen Verkabelung, des lokalen Hub- oder Switch-Ports und der Netzwerkinfrastruktur bis zurück zum DHCP-Server bestätigt. In einem einzigen, einfachen Vorgang wird so die umliegende Netzwerkinfrastruktur bis hinauf zu Layer 3 geprüft.

Ping-Signale an lokale und remote Geräte

Ist eine DHCP-Server erhältlich, wird eine Ping-Prüfung an den DNS-Server (DNS = Domain Name Service) und Standard-Router initiiert. Beide Adressen werden während der DHCP-Konfiguration bereitgestellt.

Wenn die Ping-Prüfung für grundlegende Netzwerkdienste wie Web-Applikationen und Anwender-Authentifizierung erfolgreich verläuft, müssten diese Dienste auch vom Client-Standort aus verfügbar sein. So lässt sich mit vergleichsweise geringem Aufwand bestätigen, das zwischen zwei Geräten eine durchgängige Verbindung auf Layer 3 besteht.

Die gesamte Umlaufzeit (Round-Trip-Zeit) der Anforderung lässt sich mit bereits bekannten Werten vergleichen. Allerdings sind ICMP-Anforderungen Datenverkehr mit geringer Priorität und können somit verworfen werden, falls einer der Router auf der Übertragungsstrecke oder das Zielgerät selbst ausgelastet sind. Daher empfiehl es sich, eine reihe von Ping-Signalen auszusenden.

Außerhalb der Firewall

Auch Server außerhalb des Firmennetzwerks können „angepingt“ werden, um die WAN-Verbindung vom Client und lokalen Standort zu einem Remote-Standort zu prüfen. Reagieren Server innerhalb, nicht aber außerhalb der Firewall auf die Ping-Prüfung, so könnte die Ursache des Problems bei einem Router oder anderen System an der Infrastruktur der Netzwerkgrenze liegen.

Falls nur einige Server auf die Ping-Prüfung ansprechen, wird als Nächstes ermittelt, warum bestimmte Netzwerksegmente nicht verfügbar sind. Wenn dagegen die Ping-Prüfung für die externen und internen Server (Applikationen und Server) erfolgreich verläuft, der Client diese Dienste aber nicht erhält, ist das Problem jenseits des physikalischen Transports zu suchen.

Eine erfolgreiche Ping-Prüfung hingegen lässt darauf schließen, dass anderer Datenverkehr den Ziel-Server erreichen müsste. Dass die Dienste dennoch nicht verfügbar sind, ist wahrscheinlich auf den Server oder das Anmeldekonto des Anwenders zurückzuführen.

Zeigen die Tests, dass keine Ethernet-Verbindung hergestellt werden kann, Beginnen Sie mit einer genauen Prüfung der Netzwerkverkabelung.

Kabelprüfung

Als Erstes muss das Patch-Kabel getestet werden, das die Workstation oder das Gerät mit der Netzwerk-Wandbuchse verbindet. Ein für gut befundenes Kabel kann wieder in die Wand- oder Bodenbuchse gesteckt und anschließend als Teil der Prüfkonfiguration verwendet werden.

Der nächste Schritt bei der Suche nach einem Verkabelungsfehler besteht darin, das Kabel bis zum Verteilerraum und lokalen Switch zu verfolgen. In einem überfüllten Verteilerraum kann es schwierig und zeitaufwändig sein, das richtige Kabel im Gewirr am Austritt eines Installationsrohrs zu finden.

Ist erst das entfernte Kabelende bestimmt, ist die horizontale Kabelstrecke auf Durchgängigkeit und einwandfreie Paarung zu prüfen. Außerdem ist festezustellen, ob sich ein bisher unbenutzter Port nutzen lässt. Denn häufig zeigen auch Ports mit Fehlfunktion oder im Grenzbereich noch eine Verbindung an.

Workstation mit Tick

Wurde bei der Prüfung des Hub- oder Switch-Ports kein Problem festgestellt, so kommt die Workstation als Ursache in Betracht, genauer die Netzwerkkarte. Auch hier muss wie bei einem Hub oder Switch getestet werden, ob eine Verbindung besteht und welche Geschwindigkeit sowie Duplex-Einstellung sie ermöglicht.

Existiert eine Verbindung muss der PC neu gestarten werden oder ein Befehlszeilenprogramm, zum Beispiel Ping hilft, Datenverkehr zu erzeugen. Ist kein Datenaustausch feststellbar, obwohl der PC angibt, zu übertragen, müssen die Bindungen und andere Konfigurationsparameter in Augenschein genommen werden. Ist auch das in Ordnung, stimmt vermutlich die Netzwerkkonfiguration des PCs nicht.

Diagnose der oberen Schichten

  • Stimmt die Adresse für das jeweilige Subnetz?
  • Verwendet die Workstation die korrekten Protokollstapel?
  • Sind diese richtig konfiguriert?
  • Sind alle erforderlichen Programmkomponenten und Bibliotheken vorhanden?

So lauten hier die richtigen Fragen.

In der Regel lassen sich die Antworten finden, indem das Protokoll oder die Netzwerkkarte aus der Konfiguration der Workstation gelöscht und anschließend neu installiert wird.

Wenn jetzt allerdings noch alle erforderlichen Komponenten vorhanden und korrekt konfiguriert sind, die Workstation aber dennoch nicht richtig auf Netzwerk und Applikationen zugreifen kann, ist es an der Zeit, das Problem an eine andere Ebene als den Vor-Ort-Support weiterzuleiten.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2004351 / Grundlagen)