Strategien zur Fehlersuche in LAN und WAN

Troubleshooting im Netz

Jürgen Hill ist Teamleiter Technologie. Thematisch ist der studierte Diplom-Journalist und Informatiker im Bereich Communications mit all seinen Facetten zuhause. 
Mit Marcus Linde, Senior Technical Engineer bei D-Link, sprach CW-Redakteur Jürgen Hill über typische Fehler im Netz und womit eine erfolgreiche Troubleshooting-Strategie beginnen sollte.

CW: Was benötigen Anwender für ein grundlegendes Troubleshooting im Netz?

Marcus Linde,Senior Technical Engineer bei D-Link, gibt im CW-Gespräch Tipps zum Troubleshooting im Netz.
Marcus Linde,Senior Technical Engineer bei D-Link, gibt im CW-Gespräch Tipps zum Troubleshooting im Netz.
Foto: D-Link

Linde: Eigentlich brauchen Sie nicht viel. Das beginnt mit einer genauen Fehlerbeschreibung und einem funktionierendem Messsystem etwa auf Notebook-Basis. Dazu kommt ein Kabelsatz, der etwa aus einem Ethernet-Patchkabel, einem LWL-Patchkabel, seriellem Kabel etc. bestehen sollte - also alle gängigen im Unternehmen eingesetzten Kabelarten umfasst. Diese Grundausstattungen runden Analyseprogramme wie Netz-Sniffer, TFTP-Server, Terminalprogramme sowie Performance-Mess-Tools wie Iperf ab.

CW: Eine genaue Fehlerbeschreibung? Funktioniert das in der Praxis?

Linde: Nicht immer, so ist zum Beispiel mit Fehlermeldungen wie "das Netz ist langsam", "es fällt sporadisch aus" oder "ich habe keine Verbindung" natürlich wenig anzufangen.

CW: Wie sollte dann eine richtige Fehlermeldung aussehen?

Linde: Je genauer die User das Problem beschreiben, desto effizienter kann gesucht werden. Deshalb sind Fehlermeldungen wie "das Kopieren von A nach B dauert lange, von C nach D und B nach D geht es schnell, von A nach D aber wieder langsam ", "ich bekomme am Client XYZ keine DHCP Adressen zugewiesen" oder "Gerät XYZ ist per ping nicht erreichbar" bei der Suche hilfreich.

CW: Und wenn ich mich nicht auf die Meldungen der Mitarbeiter verlassen will, welche Optionen habe ich dann?

Linde: In diesem Fall sollte ich die Log-Meldungen meiner Geräte zentral sammeln und analysieren. In IP-Netzen ist hierzu syslog eine gute Möglichkeit, da es ein De-facto-Standard ist und von sehr vielen Netz-Devices unterstützt wird. Sicherlich hat syslog einige Schwächen wie die Übermittlung der Meldungen im Klartext oder die Nutzung von UDP. Auf der anderen Seite sprechen der einfache Aufbau für seine Verwendung sowie die Tatsache, dass die Technik für Auditierungsprogramme wie das "Health Care Environment" in den USA empfohlen wird.

Sylog-Server sind ein Ansatz, um über Vorgänge in Netzen informiert zu bleiben.
Sylog-Server sind ein Ansatz, um über Vorgänge in Netzen informiert zu bleiben.
Foto: D-Link

CW: Wo liegen typische Fehlerfelder im Netz?

Linde: Bei den Themen Trunking, Spanning Tree oder Stacking werden immer wieder gerne Fehler in der Infrastruktur gemacht. Anfangs müssen diese nicht unbedingt auffallen, doch später können sie ein Netz zum Erliegen bringen.

CW: Sie sehen mich etwas verwundert, was soll denn beim Trunking kompliziert sein?

Linde: Im Prinzip nichts, dennoch müssen Sie in der Praxis einige Feinheiten beachten, wenn per Trunking oder Link Aggregation das Bündeln mehrerer physikalischer LAN-Ports zu einem logischen Port mit der n-fachen Bandbreite reibungslos funktionieren soll. So gilt etwa das statische Trunking heute als veraltet und proprietär. Und bei der Link Aggregation werden spezielle Kontrollpakete verwendet. Statische Trunks und Link Aggregation sind nicht miteinander kompatibel. Gerne wird auch vergessen, dass alle beteiligten Ports die gleiche Geschwindigkeit unterstützen müssen.

CW: Und wo sehen Sie beim Spanning Tree Probleme?

Linde: Das Spanning-Tree-Protokoll ist seit 1990 eine bewährte Methode zum Aufbau von Switch-Infrastrukturen. Allerdings ist zu beachten, dass es mittlerweile verschiedene Varianten wie den Rapid Spanning Tree oder den Multiple Spanning Tree gibt. Letzterer Ansatz ist mit Spanning Tree und Rapid Spanning Tree nicht kompatibel. Beide können jedoch über den Common Internal Spanning Tree (CIST) in den Multiple Spanning Tree integriert werden.

CW: Bleiben wir beim Switching, worauf ist beim Stacking, dem Zusammenschalten mehrerer Switches zu einer Einheit zu achten?

Linde: Grundsätzlich sollten alle Mitglieder eines Stacks mit der gleichen Firmware betrieben werden. Zudem ist das Stacking nur innerhalb einer Geräteklasse möglich. Darüber hinaus empfiehlt sich der Aufbau eines Ring-Stack anstatt einer "Duplex-Chain" (Kette). Ferner würde ich den Master Switch und Backup Master manuell konfigurieren (Box-ID, Priority).

CW: Sehen Sie spezifische Fallstricke bei den so populären WLANs?

Linde: Es gibt Fehler, die einfach zu vermeiden sind. Das beginnt mit der Kanalwahl. Benachbarte Access Points sollten immer auf unterschiedlichen Kanälen laufen. Am besten ist es, immer 2 "freie" Kanäle Abstand zu halten. Zusätzlich ist die WLAN-Kanalbandbreite im 2,4 Gigahertz-Band zu beachten. Ebenso gilt es sicherzustellen, dass genügend Kanalabstand zu "Störern" (rouge APs) besteht. Zudem sollte -wenn möglich - die automatische Kanalauswahl deaktiviert werden.

CW: Und wie sieht es mit dem Montageort aus?

Linde: Natürlich sollte der Installationsort des Access Points an die räumlichen Gegebenheiten angepasst werden. Dabei sollte nicht nur auf optische Aspekte geachtet werden, sondern auch darauf, welche WLAN-Ausleuchtung erzielt werden soll.

CW: Die Sicherheit von Funknetzen wird auch immer heiß diskutiert. Worauf ist hier zu achten?

Linde: Grundsätzlich sollten auf den Clients aktuelle WLAN-Treiber verwendet werden, die am besten direkt vom Chipsatzhersteller bezogen werden. Als Sicherheitsmodus ist mindestens WPA zu verwenden und ein kleinster gemeinsamer Nenner zu finden, der von allen Geräten unterstützt wird. Das kann etwa WPA sein oder WPA2 TKIP/AES. Um späteren Inkompatibilitäten vorzubeugen, sind im Schlüssel und der SSID Umlaute, Sonderzeichen oder Leerzeichen zu vermeiden.

CW: Themenwechsel, ist nach Ihrer Erfahrung IPv6 beim Troubleshooting schon ein Thema?

Linde: Für Anwender, die IPv6 schon aktiv im Netz nutzen, ist es auf jeden Fall ein Punkt. Aber auch jeder andere Nutzer sollte sich damit befassen, denn alle aktuellen Windows-Betriebssysteme und auch andere Systeme unterstützen IPv6 bereits standardmäßig. Und die Clients bevorzugen in der Regel den IPv6-Datenverkehr gegenüber IPv4. Erhält der Client also auf eine DNS-Anfrage sowohl eine IPv4- als auch eine IPv6-Adresse als Antwort, dann wird er mit fast hundertprozentiger Sicherheit das IPv6-Protokoll wählen.

CW: Gibt es grundlegende Unterschiede beim Troubleshooting zwischen einem IPv4- und einem IPv6-Netz?

Linde: Ja, die gibt es schon deshalb, weil es sich bei IPv6 um ein komplett neues Protokoll handelt. So gibt es beispielsweise keine klassischen privaten und öffentlichen Adressen sowie Multicast/Broadcast Adressen in Dezimalschreibweise mehr, sondern Unique Local & Global Unicast, Link Local, Multicast und Anycast Adressen in Hexadezimalschreibweise.

Die IPv6 Local Unicast Adresse ist die Unique Local Addresse, während die Global Unicast für den Internetzugriff genutzt wird. IPv6 benutzt für Neighbour Discovery und Router Solicidated/Router Advertisement (RS/RA) ICMP, daher funktioniert der Befehl "arp -a" am Windows-Client nicht mehr. Er lautet nun "netsh interface ipv6 show neighbors". Das gleiche gilt für den Befehl "route print", der nun "netsh interface ipv6 show route" heißt.

IPv6 bedient sich neuer Mechanismen des Adressbeziehens, welche DHCPv6 Server überflüssig machen können, aber auch Angriffsszenarien ermöglichen, wie beispielsweise beim stateless Router Advertisement. In diesem Zusammenhang sollte geprüft werden, ob die verwendeten Firewalls bereits IPv6-tauglich sind. IPv6 hat einen eigenen Ethertype (0x86DD), so dass unter Umständen Firewalls die Pakete gar nicht klassifizieren können.

Wie immer beim Troubleshooting ist auch hier ein methodisches Vorgehen Pflicht - wenn der Fehler diffus ist, bietet sich das Ausschlussverfahren an.