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.
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 |
|
|