Netzwerkanalyse, Fehlersuche, Testberichte
Home / News
Netzwerkanalyse
Grundlagen
Verkabelung
Erste Schritte
Baselining
Let's sniff
Tools
Auswerten/Filtern
Typische Probleme 1
Typische Probleme 2
Sicherheit
Bücher
Tutorials
Cacti
DSL einrichten
DynDNS einrichten
m0n0wall | pfSense
Nmap
VirtualBox
Wireshark
FAQ
Know How
Testberichte
Hardware-DB
Netzwerklexikon
Links / Service
Suche
Kontakt
Impressum
Feedback
Sitemap
Netzwerkanalyse

Erste Schritte - Fehlersuche mit Bordmitteln

Bevor der Sniffer ausgepackt wird, sollte eine Fehlereingrenzung mit Bordmitteln erfolgen. Viele Probleme können mit den zum System gehörenden Tools und etwas Erfahrung beseitigt werden.

Duplex Mismatch im Ethernet

In der Praxis ist die häufigste Ursache für Probleme der Duplex-Mismatch im Ethernet. Er tritt auf, wenn die automatisch Aushandlung von Geschwindigkeit und Duplexmode fehlschlägt. Auto-Negotiation funktioniert nur, wenn beide Stationen mitspielen. Ist eine Station fest eingestellt, wird von der anderen nur die Geschwindigkeit erkannt und Halfduplex gefahren.

Mehr Informationen zur Funktionsweise finden Sie im Artikel Duplex Mismatch und Autonegotiation im Ethernet.

Gerät A Gerät B Resultat
100 half 100 half Halfduplex, bei Last Kollisionen
100 half 100 full Duplex-Mismatch , viele Fehler, keine Performance
100 half auto Glück gehabt, B geht auf 100 half
100 full 100 full immer noch die sicherste Methode
100 full auto Duplex-Mismatch, B geht auf 100 half, viele Fehler, keine Performance
auto auto mit etwas Glück gehen A und B auf 100 full
100 10 Speed-Mismatch, kein Link

Einen Duplex-Mismatch erkennt man am einfachsten an den Fehlercountern eines Switchports. Auf der Seite mit Fullduplex treten viele Inputerrors auf und auf der Seite mit Halfduplex sind viele Late Collisions ein deutlicher Hinweis. Die neueren Netzwerktreiber für die Karten von HP (vormals Compaq) und Intel können den aktuellen Duplexmode und Fehlerstatistiken anzeigen.

Für den User zeigt sich ein Duplex-Mismatch durch die extrem schlechte Performance. Eine Verbesserung um den Faktor 50 durch Beseitigung des Mismatchs ist durchaus realistisch. Die Beeinträchtigung durch einen Duplex-Mismatch ist richtungsabhängig. Besonders stark betroffen ist die Performance des Halfduplex-Ports beim Senden von Daten.

Tip: Viele einfache Switche bieten keine Einstellmöglichkeit für den Duplexmode und laufen immer mit Autonegotiation. Hier sind die Clients also auch auf Auto einzustellen.

Es hat sich gezeigt, das auch die Kombination auto/auto in der Praxis nicht immer zuverlässig funktioniert. Daher zur Fehlereingrenzung am besten beide Partner fest auf die gleichen Parameter einstellen.

Oft lohnt sich auch ein Besuch auf den Webseiten der Produktanbieter. Cisco pflegt bespielsweise eine lange Liste von Problemkandidaten im Zusammenhang mit Catalyst Switchen.

Man sollte auch die maximal möglichen Übertragungsraten nicht aus dem Auge verlieren. Über ein Fast Ethernet lassen sich passen halt nur 12,5 Mbyte/s oder 45 Gbyte/h übertragen. Und das sind Bruttowerte inclusive Preamble und Inter Frame Gap die man nicht beim Kopieren von Dateien unter Windows erreichen wird.

Tip: Unter Linux gibt es das geniale Tool mii-diag von Donald Becker. Hier die Ausgabe für das Interface eth0:

[netzwerkler@lfs] ~ $ mii-diag
Using the default interface 'eth0'.
Basic registers of MII PHY #1: 1000 7809 02a8 0154 05e1
Basic mode control register 0x1000: Auto-negotiation enabled.
Basic mode status register 0x7809 ... 7809.
Link status: not established.
End of basic transceiver information.

Mii-diag zeigt einem beispielsweise die verfügbaren Modi der Gegenstelle an und unterstützt so die Fehlersuche.

Details zu mii-diag gibt es im Artikel Netzwerkdiagnose mit mii-diag unter Linux. Ebenfalls unter Linux arbeitet ethtool. Siehe dazu Ethernetkarten konfigurieren unter Linux mit ethtool.

Kollisionen

Eigentlich Vergangenheit... Aber auch in geswitchten Netzen findet man noch den einen oder anderen Halfduplex-Adapter. Auf Halfduplex-Verbindungen sind Kollisionen völlig normal. Aber auch hier lohnt ein Blick auf die Counter im Switch. Nach der wievielten Kollision ist der Switch den Frame losgeworden? Gibt es Excessive Collisions oder Late Collisions?

Tip: Auf Cisco-Boxen unter IOS gibt es neben dem oft benutzten „show interface“ auch noch das Kommando „show controller ethernet“. Dieses liefert detaillierte Informationen zu Ethernetinterfacen. Hier kann man auch sehen nach wieviel Versuchen, sprich Kollisionen, der Switch einen Frame senden konnte.

Die Angabe "Defered Frames" gibt die Anzahl der Frames an, die vor dem ersten Senden zurückgestellt worden, weil das Medium belegt war. Excessive Collisions (Frames wurden verworfen) sind Folge einer zu hohen Auslastung des Links. Hier helfen 100 MBit/s und Fullduplex weiter.

Late Collisions können durch zu lange Kabel oder häufiger durch einen Duplex Mismatch verursacht werden.

Kollisionsraten von über 10 Prozent sind schon kritisch und gehen zu Lasten der Performance. Hier bringt nur ein Umstieg auf Fullduplex Besserung. Auf einem Fullduplex Link darf es im Betrieb keine Kollisionen oder andere Fehler geben.

CRC & Co.

Meldet der Switch auf Fullduplex-Verbindungen Fehler, sollte die Verkabelung und die Netzwerkkarte überprüft werden. Ein oder zwei Fehler beim Booten einer Station oder beim Stecken eines Kabels sind vollkommen normal.

ifconfig, ipconfig, winipcfg, iwconfig

Für einen schnellen Überblick über die Netzwerkeinstellungen eines Clients eignen sich die Kommandozeilen-Tools ifconfig (Linux) und ipconfig (ipconfig). Die Tools zeigen den aktuellen Status der Netzwerkverbindungen an. Über "ipconfig /all" liefert Windows eine detaillierte Darstellung. Unter Windows 98 leistet "winipcfg" gute Dienste. Unter Linux zeigt "iwconfig" interessante Informationen zu WLAN-Adaptern an.

ARP, Ping und Traceroute

Zur Diagnose auf dem Layer 3 stellen sowohl Endgeräte als auch Router eine Reihe von Tools zur Verfügung.

ARP

ARP stellt die Verbindung zwischen Layer 2 (MAC-Adressen) und Layer 3 (IP-Adressen) im LAN her. Mit dem Kommando arp kann man sich den ARP-Cache von Endgeräten ansehen und manipulieren. Auf Cisco Router lautet das Kommando show ip arp.

Ping

Ping überprüft mit Hilfe von ICMP-Packeten die Erreichbarkeit eines Hosts. Dadurch erhält man eine Aussage über die Verbindung auf Layer 3. Interessant ist es gerade auf WAN-Strecken auch mal größere Pings abzusetzen. Bei Leitungsproblemen kommen normale, kleine ICMP-Packete dank Fehlerkorrektur manchmal noch über die Leitung, größere Packete können aber nicht mehr fehlerfrei übertragen werden.

Die vom Ping gemeldeten Round Trip Times können nur eine grobe Orientierung darstellen. ICMP wird von Netzkomponenten normalerweise nicht mit hoher Priorität bearbeitet. Heute schränken immer mehr Administratoren ICMP auf Routern und Firewalls ein. Es kann also vorkommen, dass man einen Host nicht mit Ping erreicht, aber auf einen Webserver auf diesem Host problemlos zugreifen kann.

Cisco IPX Ping

Cisco-Router bieten die Möglichkeit auch IPX-Hosts zu pingen. Leider haben Cisco und Novell unterschiedliche Frameformate für Ping definiert. So antwortet ein Netware-Server nicht auf das Cisco-Ping.

Mit dem Konfig-Kommando "ipx ping-default novell" kann man den Router allerdings überreden, original Novell-Pings zu versenden.

Cisco IOS Ping

Beim Ping unter IOS gibt es eine Reihe von Codes zur Anzeige der Resultate. Das Ausrufezeichen ist bei Cisco keine Warnung, sondern zeigt ein erfolgreiches Ping an.

Code Bedeutung
! Ping erfolgreich
. Timeout
U Destination unreachable
Q Source quench
M Fragmentation needed and DF set
? Unbekanntes Packet
C CE-Bit gesetzt RFC 2481
& TTL abgelaufen
I Ping durch Benutzer abgebrochen

Cisco Router senden die ICMP-Echo Requests übrigens ohne Delay direkt hintereinander. Es kann also beim pingen von Hosts durchaus zu Timeouts kommen, wenn diese nur eine bestimmte Anzahl von ICMP-Packeten pro Zeiteinheit beantwoten (Rate Limit).

Traceroute

Traceroute geht einen Schritt weiter als Ping. Es versucht Informationen über die Router auf dem Weg zum Ziel zu sammeln. Da Traceroute auf dem Layer 3 arbeitet, bleiben Hubs und Switche unsichtbar.

Tip: Traceroute liefert nur Informationen über die Router auf dem Weg zum Ziel. Der Rückweg der Packete kann durchaus ein anderer sein. Bei der Fehlersuche sollte man deshalb von beiden Kommunikationspartner ein Traceroute ausführen.

Cisco IOS Traceroute

Cisco benutzt einige spezielle Codes zur Darstellung der Ergebnisse von Traceroute.

Code Bedeutung
* Timeout
? Unbekanntes Packet
Q Source quench
A Administratively prohibited
H Host unreachable
N Network unreachable
P Protocol unreachable
U Port unreachable
I Traceroute durch Benutzer abgebrochen

Netstat

Ein weiteres Tool zur Fehlersuche an den Endgeräten ist netstat. Es liefert eine Reihe von Informationen aus dem TCP/IP-Stack des Betriebssystems.

Der Befehl "netstat -an" zeigt alle Netzwerkverbindungen auf einer Maschine an. Serverdienste die sich im Status "Listening" befinden, werden von deutschen Windowsversionen als "ABHÖREN" angezeigt.

C:\>netstat -an

Aktive Verbindungen

  Proto  Lokale Adresse         Remoteadresse          Status
  TCP    0.0.0.0:135            0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:445            0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:1029           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:1721           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:1722           0.0.0.0:0              ABHÖREN
  TCP    0.0.0.0:5405           0.0.0.0:0              ABHÖREN
  TCP    192.168.1.7:139        0.0.0.0:0              ABHÖREN
  TCP    192.168.1.7:1031       0.0.0.0:0              ABHÖREN
  TCP    192.168.1.7:1031       192.168.11.25:139      HERGESTELLT
  TCP    192.168.1.7:1071       0.0.0.0:0              ABHÖREN
  TCP    192.168.1.7:1071       192.168.11.77:139      HERGESTELLT
  TCP    192.168.1.7:1096       0.0.0.0:0              ABHÖREN
  TCP    192.168.1.7:1103       10.0.2.1:1433          HERGESTELLT
  TCP    192.168.1.7:1106       10.4.0.1:3311          HERGESTELLT
  TCP    192.168.1.7:1258       10:4.0.3:1352          HERGESTELLT
  TCP    192.168.1.7:1385       0.0.0.0:0              ABHÖREN
  TCP    192.168.1.7:1420       10.5.0.1:23            HERGESTELLT
  TCP    192.168.1.7:1721       10.5.0.1:80            SCHLIESSEN_WARTEN
  TCP    127.0.0.1:1871         127.0.0.1:445          WARTEND
  UDP    0.0.0.0:445            *:*
  UDP    0.0.0.0:1052           *:*
  UDP    0.0.0.0:5405           *:*
  UDP    192.168.1.7:137        *:*
  UDP    192.168.1.7:138        *:*
  UDP    192.168.1.7:500        *:*

Unter Windows NT 4 und Windows 2000 gibt es einen Bug, der bewirkt, das Ports die eigentlich für ausgehenden Verbindungen genutzt werden, als "Listening" auf der 0.0.0.0 angezeigt werden.
Siehe Knowledge Base Artikel 331078.

Weitere Informationen zu netstat finden Sie im Tutorial Offene Ports und Anwendungen finden mit netstat.

Route

Route ist das Kommando zur Anzeige und Veränderung der Routingtabelle unter Linux und Windows.

C:\>route print
===========================================================================
Schnittstellenliste
0x1 ........................... MS TCP Loopback interface
0x1000003 ...00 02 b3 04 48 ce ...... Intel(R) PRO Adapter
===========================================================================
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway   Schnittstelle  Anzahl
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.7       1
      192.168.1.0    255.255.255.0      192.168.1.7     192.168.1.7       1
      192.168.1.7  255.255.255.255        127.0.0.1       127.0.0.1       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
        224.0.0.0        224.0.0.0      192.168.1.7     192.168.1.7       1
  255.255.255.255  255.255.255.255      192.168.1.7     192.168.1.7       1
Standardgateway:       192.168.1.1
===========================================================================
Ständige Routen:
  Keine

Mit den entsprechenden Optionen, kann man auch Routen zur Tabelle hinzufügen und löschen.

Debug auf Switchen und Routern von Cisco

Bei der Fehlersuche auf Cisco-Boxen stehen eine Reihe von Debug-Kommandos zur Verfügung. Alle Meldungen werden normalerweise nur auf die physische Konsole des Gerätes ausgegeben. Also nicht etwa in der Telnetsession aus Verzweiflung „debug all“ eingeben, weil man keine Meldungen sieht. Da hilft nur ein „term mon“, dadurch werden die Meldungen auch in der Telnetsession angezeigt. Überhaupt sollte man recht vorsichtig vorgehen, da die Komponente durch das Aktivieren vieler Debugoptionen stark belastet wird.

Einige interessante Möglichkeiten sind:

  • debug broadcast
  • debug arp
  • debug ip icmp
  • debug span

Cisco bietet auch die Möglichkeit das Debug mit einer Access Liste einzuschränken oder nur Packete zu debuggen die ein bestimmtes Interface passieren. Debug wirkt nur auf process-switched Packets. Nach Arbeitsende auf jeden Fall alle Debugs mit „undebug all“ deaktivieren.

Checkliste Windows-Client

Die folgende Checkliste beschreibt die häufigsten Probleme an Windows-Clients. Die Zeichen in der Spalte „Auswirkung“ haben die Bedeutung:

L – Link (LEDs am Switchport oder auf der Netzwerkkarte leuchten nicht)
A – Anmeldung (Keine Anmeldung am Windows möglich)
Z – Zugriff (Zugriff auf bestimmte Dateien oder Drucker wird verweigert)
P – Performance (Geschwindigkeit bei Dateizugriffen entspricht nicht den Erwartungen)

Zu überprüfen Auswirkung geprüft
Netzwerkkabel steckt, Link-LED's an der Karte und am Hub oder Switch leuchten L  
Kartentreiber ist installiert, Keine Fehlermeldungen im Ereignissprotokoll L  
Speed- und Duplexeinstellungen stimmen mit dem Hub oder Switch überein P  
IP-Adresse, Netzmaske und Default Gateway passen zum Netz (ipconfig /all),
Ping auf das Default Gateway funktioniert
A  
DNS- und WINS-Server sind eingetragen,
Ping auf diese Server funktioniert
A, Z  
Computerkonto in der Domäne ist vorhanden A  
Ping und nbtstat auf die Domaincontroller und Fileserver funktioniert A, Z  
Net view auf die Fileserver funktioniert, die gesuchten Shares werden angezeigt Z  
Net use auf einen Share funktioniert Z  
Zugriff auf Dateien in einem Share funktioniert Z  
TCP Window Size steht auf 64 K P  
NetBIOS-Buffer steht auf 64 K P  
SMB Signing deaktiviert Z, P  

 

<-- Netzwerkverkabelung Inhalt Baselining -->

 

 
© 2004-2023, network lab - we make your net work - Netzwerkforum
aktualisiert am 22.03.2012