Erste Hilfe fürs Netzwerk

Alles ist sorgfältig verlegt und angeschlossen, dennoch streikt das Netz - eine Applikation funktioniert nicht oder die neue Multimedia-Applikation zickt herum. Wer jetzt bei der Fehlersuche falsch vorgeht, verschlimmbessert womöglich das Problem.

Hier hat D-Link-Senior Consultant Christoph Becker einen Ratschlag parat, der auf den ersten Blick ungewohnt und fast schon paradox klingt: Egal, ob Heimnetz oder Corporate Network, bei der Fehlersuche sollte der User auf der untersten Schicht des OSI-Layers, also im Zweifelsfall mit der Netzebene 1 beginnen und sich dann nach oben arbeiten. Ungläubig halten wir ihm entgegen, dass wir genau andersherum vorgehen würden, denn auf den oberen komplexeren Netzschichten gäbe es ja vielmehr Fehlerquellen.

Eine Argumentation, die Becker im Prinzip teilt, gleichzeitig hält er uns aber entgegen: "Und was haben Sie davon, wenn Sie auf den oberen Ebenen den Fehler suchen, in Wirklichkeit aber ein Kabel einen Ermüdungsbruch hat? Sie haben die doppelte Arbeit, weil sie sich oft mit der Fehlersuche auf der falschen OSI-Ebene auch noch ihre Netzeinstellungen zerschossen haben." Er empfiehlt deshalb, sich bei der Suche unbedingt von der untersten OSI-Ebene nach oben vorzuarbeiten und so Fehlerquellen auszuschließen.

Problemfelder im LAN
Wenn das LAN verrückt spielt, kann das mehrere Gründe haben.

Verbindungsfragen
Als erstes sollten bei LAN-Problemen die Kabel überprüft werden, selbst optisch einwandfreie Kabel können defekt sein.

In der Dauerschleife
Falsch installierte Switches könne für eine Loop sorgen, der Broadcast-Stürme hervorruft. Dieser zusätzliche Verkehr kann das Netz massiv beeinflußen.

Unerlaubte IP-Adressen
Ein weitere beliebte Fehlerquellen sind doppelte oder falsche IP-Adressen. Bei modernen Switchen lassen sich diese Übeltäter auf Port-Ebene aussperren.

Zu viele DHCP-Server
Heimlich installierte DHCP-Server finden Sie mit einem Server-Screening. Da das mehrfache Vorhandensein von DHCP-Servern den Netzbetrieb beeinträchtigt, sollten Sie die Störenfriede aussperren.

Fehlerfalle Spanniung Tree
Das Vermeiden von doppelten Strecke und Gewährleistung der Redundanz – diese Vorteile sprechen für ein Netz mit Spanning Tree. Wer jedoch nicht aufpasst handelt sich mehr Probleme ein.

Performance-Booster Trunk
Mit paralellen Leitungen (Trunk) läßt sich die Übertragungsleistung verdoppeln.

Tuning statt Upgrade
Mit Hilfe des Trunking lässt sich häufig ein kostspieliges Upgrade auf 10 Gbit/s Ethernet vermeiden, denn im Trunk können bis zu acht Gigabit-Verbindungen zusammengeschaltet werden.

Fehler: Tückische Ethernet-Kabel

Der erste Blick sollte dabei den verwendeten Kabelverbindungen gelten, wie wir aus leidvoller Erfahrung selbst wissen. So brachte uns einmal ein NAS-Test fast zu Verzweifelung: Mit Fast Ethernet erzielten wir Messergebnisse, die im Rahmen des zu erwartenden waren. Schlossen wir dagegen ein Gigabit-Ethernet-Device an, brachen die Leistungen drastisch ein. Eine zeitraubende Überprüfung der Switches, Netzkarten etc. zeigte keine Auffälligkeiten. Erst als wir das optisch unbeschädigte Cat5e-spezifizierte Kabel - das ja mit Fast Ethernet funktionierte - austauschten, war der Spuk vorbei. Da der einfache Kabelaustausch, im Heim- oder Testnetz meist noch problemlos möglich, im Enterprise-LAN nicht so einfach ist, ist die Anschaffung eines Kabeltesters dringend ratsam. Dabei sollte das Testgerät aber auch alle Übertragungsarten (vollduplex, Gigabit Ethernet etc.) beherrschen, die später im Alltag gefahren werden.

Fehler: Ethernet-Treiber

Eine andere tückische Fehlerquelle stellen die Netzwerktreiber für die Interface-Karten dar. Auch wenn es uns noch nicht selbst passiert ist, so berichten User immer wieder davon, wie die seltsamsten Netzfehler mit einem Upgrade der Ethernet-Treiber verschwanden. Wer auf den Seiten des Motherboard- oder Netzwerkkarten-Herstellers keine neueren Treiber findet, sollte die Flinte nicht gleich ins Korn werfen. Die Chipsatz-Hersteller der Netz-Interfaces offerieren meist aktuelle generische Treiberversionen. Bei Windows-Systemen finden sie den Chipsatzhersteller in der Regel im "Gerätemanager" unter "Netzwerkadapter".

Fehler: Jumbo-Frames

Eine weitere, oft übersehene Performance-Bremse sind die so genannten Jumbo-Frames, also überlange Ethernet-Pakete. In Gigabit-Ethernet-Umgebungen sollen sie - zumindest in der Theorie - die Performance bei der Übertragung großer Dateien oder Multimedia-Files deutlich steigern. In der Praxis erlebten wir allerdings das Gegenteil: Deutliche Leistungseinbußen. Die eigentlich clevere Idee der Jumbo-Frames hat nämlich einen Haken: Alle Devices im Netz müssen diese Transferart unterstützen. Erschwerend kommt hinzu, dass dieses Verfahren nicht standardisiert ist, womit in heterogenen Umgebungen Probleme fast programmiert sind. Unser Ratschlag lautet deshalb: Deaktivieren Sie die Jumbo-Frames bis Sie die reibungslose Netzkommunikation in allen Betriebszuständen garantieren können. Danach können Sie mit diesem Performance-Booster experimentieren.

Erste Hilfe fürs Netzwerk II

Fehler: DAU in Aktion

Wie recht Becker mit seinem Ratschlag zur ersten Analyse auf Netzebene 0 hat, zeigt auch ein Blick in das COMPUTERWOCHE-Forum "Aufgehängt - Das Problem sitzt vor dem Rechner". Dort schildert ein Leser, wie er wegen dem Netzproblem "Internet geht nicht mehr" gerufen wurde. Vor Ort war das Problem schnell gelöst: Alle LEDs des Switch waren aus, denn man hatte die 220 Volt Steckdose für das Handy-Ladegerät benötigt.

Fehler: Netzdesign

Die konsequenteste Fehlervermeidung beginnt für Becker allerdings bereits im Vorfeld beim Netzdesign: "Komplexe Netze mit VoIP und anderen Echtzeit-Anforderungen lassen sich nicht einfach mit einem gesunden Halbwissen aufbauen." Hier sei eine konsequente Bedarfsanalyse gefordert, die sich dann im Design niederschlagen müsse. Und dieses sei dann später bei der Umsetzung akribisch zu dokumentieren, denn gerade vergessene Komponenten oder Altlasten würden später häufig für unerklärliche Phänomene sorgen: "Sie ziehen etwa ein Kabel und dürften eigentlich keine Netzanbindung mehr haben, der Rechner bleibt aber weiter munter im Netz." Im vorliegenden Beispiel entpuppte sich ein längst vergessener Hub als Übeltäter.

Fehler: Loop im Netz

Ein anderer typischer Fallstrick lauert für Becker in den so genannten gewachsenen Netzen - also LANs oder Corporate Networks, die je nach Bedarf von Zeit zu Zeit erweitert werden. Oft werden hier nachträglich Kabel gezogen, die dann später zu den krudesten Phänomen führen, wenn die Installation nicht sauber dokumentiert wurde. So können etwa Schleifen (Loops) im Netz entstehen, die dann ein Switched Network, das eigentlich auf dedizierten Verbindungen basiert, ausbremsen. Denn ein solcher Loop verursacht einen Broadcast-Sturm, der ein ganzes Netzsegment lahmlegen kann. Um das Problem zu vermeiden, hat der Netzbetreuer zwei Optionen: Das Aktivieren des Spanning Tree Protcols (STP), das aber oft von Unmanaged Switches nicht unterstützt wird, oder die Verwendung einer Loopback Detection (LBD), wie sie von verschiedenen Herstellern unter diversen Bezeichnungen offeriert wird.

Becker bevorzugt das LBD-Verfahren, denn der Spanning Tree wartet noch mit einigen Tücken auf - doch dazu später mehr. Bei der Loopback Detection ist dann zwischen einem Port- und VLAN-basierenden Verfahren zu unterscheiden. Während ersteres den Port komplett abschaltet, blockiert letzteres den Verkehr nur im VLAN, ohne den ganzen Port zu sperren.

Fehler: Fehlende Segmentierung

Gerade diese Segmentierung ist ein Grund, warum Becker den Einsatz von VLANs empfiehlt: "Sie erhöhen nicht nur die Sicherheit, sondern begrenzen Störungen auf ein Netzsegement." So blieben beispielsweise Broadcast-Stürme auf ein virtuelles LAN-Segement begrenzt und zögen nicht die gesamte Infrastruktur in Mitleidenschaft.

Allerdings bergen die VLANs in Kombination mit dem Spanning Tree Protocol (STP) auch eine Gefahr. Wie D-Link-Mann Becker aus der Praxis weiß, kommt es durchaus vor, dass das STP ein VLAN deaktiviert, wenn es um Redundanzen zu vermeiden eine physikalische Netzverbindung abschaltet. Auf den ersten Blick erschient dieses Phänomen unverständlich, doch die Erklärung fällt einem wie Schuppen von den Augen, wenn man sich das theoretische Konzept hinter STP verdeutlicht. Ursprünglich wurde STP entwickelt, um in geswitchten Umgebungen zwei sich widersprechende Anforderungen zu realisieren: Zum einen die Vermeidung mehrfacher Netzpfade zum Ziel, um eine Verdoppelung der Datenpakete zu verhindern; zum anderen die gleichzeitige Redundanz der Netzpfade; um beim Ausfall einer Strecke eine alternative Verbindung zu haben.

Genau diese Steuerung übernimmt STP beziehungsweise das Rapid Spanning Tree Protocol (RSTP) als neuere Variante. Hierzu kommunizieren die Switches über das Bridge-Protokoll miteinander. Zuerst wird eine sogenannte Root Bridge bestimmt, die das Oberkommando übernimmt und Startpunkt des Verbindungsbaumes (Tree) ist. Root wird normalerweise die Bridge mit der niedrigsten ID, die sich aus Priorität und MAC-Adresse ergibt. Existieren redundante Wege, so nehmen die Switches den Port mit den geringsten Pfadkosten zur Root Bridge und deaktivieren die anderen Ports, darunter eventuell auch ein VLAN.

Zudem weist das Konzept, sieht man einmal von Umschaltzeiten von bis zu 30 Sekunden ab (RSTP etwa eine Sekunde), im Fall einer Störung noch zwei andere gravierende Nachteile auf: kommt etwa ein neuer Switch in das Netz, dann kann dieser eventuell aufgrund seiner ID die Aufgabe der Root Bridge automatisch übernehmen und die ursprünglichen Verbindungszuordnungen stimmen nicht mehr, was zu Performance-Problemen führen kann. Ebenso kann es passieren, dass bei einem Ausfall ein Switch die Root-Bridge-Funktion übernimmt, der so ungünstig positioniert ist, dass das Netz zusammenbricht. Eine weitere Gefahr stellen in gewachsenen Netzen neue, ergänzende Kabel dar, die womöglich die Struktur des Spanning Trees zerstören, da sich keine eindeutigen Pfadkosten berechnen lassen.

Angesichts dieser Fallstricke rät der Consultant, "den Spanning Tree nicht sich selbst zu überlassen, sondern etwa für einen Ausfall eine Ersatz-Root-Bridge selbst festzulegen." Wer mit VLANs arbeitet, sollte zudem überlegen, ob er nicht mit dem Multiple Spanning Tree Protocol (MSTP) arbeitet. Dieses wird den Anforderungen der VLANs besser gerecht, da es in einem LAN mehrere Instanzen des Spanning Tree erlaubt. Für Anwender, die mit Hilfe des Spanning Tree einen Ring zur Erhöhung der Ausfallsicherheit nachbilden wollen, hat Becker noch einen anderen Ratschlag: Statt auf STP oder RSTP zu setzen, empfiehlt er herstellerspezifische Verfahren - bei D-Link etwa das Rapid Ethernet Ring Protection (RERP) - zu verwenden, da diese teilweise mit Umschaltzeiten von 200 Millisekunden aufwarten und die spezifischen STP-Nachteile nicht haben.

Erste Hilfe fürs Netzwerk III

Fehler: Ungenutztes Trunking-Potenzial

Kommt es zu Engpässen im Backbone oder bei Serveranbindungen, stellt sich häufig die Frage nach einem Upgrade auf 10 Gigabit Ethernet. Doch dies ist teuer, so dass viele Unternehmen die Investition scheuen und die entsprechenden Verbindungen am Anschlag fahren. Dabei gibt es eine Alternative: Mit Hilfe des Trunking, also dem parallelen Benutzen von 1 Gigabit/s-Verbindungen, kann die Bandbreite auf diesen Strecken erhöht werden. Üblich sind heute Trunks mit bis zu acht parallelen Verbindungen, was einer Bandbreite von 8 Gigabit/s entspricht.

Beim Trunking wird allerdings gerne, wie Becker aus seiner Hotline-Praxis weiß, Potenzial verschenkt: "Das Trunking kann nicht nur zur Performance-Steigerung, sondern auch zur Erhöhung der Redundanz genutzt werden." Das Stichwort lautet hier Cross Trunking. Hierbei werden die Ethernet-Kabel etwa zwischen zwei Stacks (Zusammenschluss mehrerer Switches zu einem logischen Switch) nicht parallel sondern über Kreuz zwischen den einzelnen Geräten geschaltet, um so bei einem Ausfall möglichst geringe Beeinträchtigungen zu haben.

Fehler: Performance-Falle Priorisierung

Allerdings warnt Becker davor, zu glauben, dass in den heutigen Netzen mit genügend Bandbreite jedes Problem gelöst werden kann. Gerade bei Echtzeitanwendungen wie VoIP oder Video seien zudem Parameter wie Delay, Jitter oder Paket Loss von Bedeutung. "Bandbreite ist kein Ersatz für Priorisierung", unterstreicht der LAN-Experte. Bei der Priorisierung ist allerdings darauf zu achten, dass diese im gesamten Netz Ende zu Ende genutzt wird. Wird etwa nur vom VoIP-Telefon in der lokalen Arbeitsgruppe bis hin zum ersten Swicth eine Priorisierung gefahren, dann sollte sich niemand wundern, wenn es später dennoch zu Ausfällen kommt. Ebenso wichtig ist, dass alle beteiligten Geräte die Priorisierungsmechanismen auch wirklich unterstützen.

Fehler: Device-Missbrauch

In diesem Zusammenhang spricht noch eine andere Systembremse an, die häufig unterschätzt wird: Der Missbrauch von Endgeräten für Einsatzzwecke, für die sie eigentlich nicht konzipiert wurden. Gerade die langen Feature-Listen aktueller Hardware verleiten oft dazu, zu viele beziehungsweise falsche Aufgaben auf einem Gerät erledigen zu wollen. Ein klassisches Beispiel hierfür ist in Schmitts Augen ein WLAN-Access-Point. Die eigentliche Aufgabe des Geräts sei ein reibungsloser Transport der Daten per Funk. "Deshalb sollte ein Access Point als Access Point", so der Supporter, "und ein Edge Device wirklich als Edge Device genutzt werden." Wer die Geräte mit ungeeigneten Aufgaben belaste, müsse sich nicht wundern, wenn hinterher die Performance leide. So gehört für Becker etwa das Routing in den Core- und nicht in den Edge-Bereich.

Fehler: TCP/IP-Bremse

Etliche unerklärliche Netzphänomene haben ihre Ursache allerdings auch auf den oberen Netzebenen: Doppelt vergebene IP-Adressen können zu den wildesten Fehlern führen. Eine Ursache hierfür sind häufig nicht erlaubte DHCP-Server im Netz, die eigenmächtig Adressen vergeben. Ob diese Server nun aus Versehen entstehen, weil ein neues Gerät per se mit aktiviertem DHCP-Server ausgeliefert wird, oder bewusst von einem User installiert werden, sei dahingestellt. Als Abhilfe hilft hier ein DHCP Server Screening, das DHCP-Pakete erkennt und im Bedarfsfall automatisch den entsprechenden Netz-Port abschaltet.

Ebenfalls oft zu beobachten ist, dass Anwender ihren Rechnern selbst IP-Adressen geben, ohne zu wissen, dass sie damit komplette Netzsegmente lahm legen können. Um dies zu verhindern, empfehlen sich Switches, die das Anlegen von White Lists erlauben, in denen eine IP-Adresse fest einer MAC-Adresse und einem Switch-Port zugeordnet ist. Kommt nun ein Datenpaket mit der falschen Zuordnung - bei D-Link nennt man diese Technik beispielsweise IP-MAC-Port-Binding (IMPB), dann blockiert der Switch den Weitertransport.

Die 10 bizarrsten Netzwerkfehler
Haiangriffe, Vandalismus oder Flugzeugabstürze, die COMPUTERWOCHE präsentiert Ihnen die kuriosesten Netzwerkausfälle der letzten Jahre.

Netzwerk vs. Vandalismus
Insgesamt gehen sieben Prozent der jährlichen Ausfälle auf Schießübungen zurück. Häufig geschieht dies in den gefährlichen Stadtbezirken, weshalb es notwendig wird, dass die Techniker von Sicherheitskräften begleitet werden.

Netzwerk vs. Flugzeugabsturz
Vor kurzem wurde in Kalifornien ein Ausfall aufgrund eines Flugzeugabsturzes verzeichnet. Ein kleines Flugzeug schoss am Burbank International Airport über die Landebahn hinaus, erreichte ein Wohngebiet und riss die Glasfasermasten um. Zum Glück kam niemand zu Schaden.

Netzwerk vs. Fire & Ice
Bei einem Eissturm in Chalfont, Pennsylvania wurden einige Äste abgerissen, die auf eine Hauptstromleitung fielen, über die auch die Kommunikationsleitung gelegt war. Die Kabel fingen an mehreren Stellen Feuer, umgeben von mit Eis bedeckten Ästen - Fire & Ice!

Netzwerk vs. Hai
Alligatoren, Schlangen und sogar Haie würde man wohl nie als Grund für einen Glasfaserausfall vermuten. Nach dem Hurrikan Katrina fand einer der Mitarbeiter gut drei Kilometer im Landesinneren einen 90 Zentimeter großen Hai in einem Graben neben unserem Glasfaserkabel. Das ist wohl der ungewöhnlichste Vorfall mit einem Tier, den Level 3 je hatte.

Netzwerk vs. Bauunternehmen
Ein besonders spektakulärer Fall ereignete sich in Kalifornien, als ein Bauunternehmen ein massives Stahlrohr 1,2 Meter unter der Erde vorfand. Man würde annehmen, dass die Herren sich die Mühe machen würden, herauszufinden, was das denn für ein Stahlrohr sei und sicherstellen, dass darin nicht etwas Gefährliches wie Öl oder Gas fließe. Aber ganz so logisch war es nicht, sie sprangen einfach in das Loch und schnitten mit ihrer Säge das Rohr und die Glasfaserleitung durch.

Netzwerk vs. Eichhörnchen
Während man sich mit Menschen für gewöhnlich verständigen kann, kann man nicht wirklich etwas gegen die zweithäufigste Ursache für Leitungsunterbrechungen unternehmen: Eichhörnchen! Von allen Tieren der Welt sind sie mit Abstand die häufigsten Angreifer der Leitungen - sie haben einen Anteil von knapp 17 Prozent der Unterbrechungen.

Netzwerk vs. Mutter Natur
In Utah sollte vor einigen Jahren ein Kabel über einer Schlucht repariert werden, die eine Viertelmeile breit war und in der ein reißender Strom toste. Selbst die großen Jeeps und die gesamte Ausstattung waren knietief in Schlamm versunken. Sogar Jetboote versagten dabei, das Kabel über den Fluss zu ziehen. Am Ende wurde das Kabel mit einer Line Gun über die Schlucht geschossen. Zum Glück wurde niemand verletzt - aber es war ziemlich furchterregend.

Netzwerk vs. Trucks
Ein besonderer Vorfall ereignete sich in Pennsylvania, als ein Lkw-Fahrer sich verfahren hatte und versehentlich die Straße einer Wohnsiedlung entlang fuhr. Sein Fahrzeug verfing sich in einem ganzen Netz von Telefonkabeln. Aber er machte dennoch nicht Halt. Er fuhr einfach weiter bis sein Fahrzeug eingewickelt war wie ein Weihnachtsgeschenk. Sogar einen sechs Meter langen Telefonmast zog er hinter sich her, bis er auf die Idee kam, anzuhalten und nachzuschauen, was denn sein Fortkommen behinderte.

Netzwerk vs. Kabelbrand
Die gemeinsame Anbringung von Telefon- und Stromkabeln an einem einzigen Mast kann eine praktische Maßnahme sein, manchmal aber auch zu Ausfällen führen. Dies war der Fall in Boise im US-amerikanischen Bundesland Idaho. Starke Winde hatten während eines Sturms mehrere Telefonmasten umgerissen. Aber das war noch lange nicht der Grund, warum es zum Ausfall kam. Das Kabel war immer noch funktionsfähig, bis der Strom an einem der Masten zu einem Grasbrand führte. Die Hitze ließ das Kabel dann letztendlich schmelzen. Die Techniker reparierten das Kabel noch während die Löschflugzeuge den Brand einzudämmen versuchten.

Netzwerk vs. Backer
Zu guter Letzt ein besonderer Höhepunkt: Man sollte niemals einen Gentleman aus dem Süden der USA unterschätzen, der einen Bagger und eine Schrotflinte sein Eigen nennt. Der besagte Herr besaß Land, das über die Staatsgrenzen von Georgia und Florida verlief. Er war wütend auf das Straßenverkehrsamt von Florida, weil er seiner Meinung nach zu wenig Entschädigung für das Wegerecht erhalten hatte, den Highway auf seinem Grundbesitz auszuweiten. So entschloss er sich eines Tages, einen ausgeklügelten Racheplan in die Tat umzusetzen. Der Herr fuhr also mit seinem Bagger über die Staatsgrenze von Georgia nach Florida, grub zwei Löcher und zerschnitt an diesen Stellen das Kabel. Als die Techniker zur Reparatur anrückten, wurden sie vom Grundbesitzer schon mit seiner Schrotflinte erwartet. Er drohte jeden zu erschiessen, der sich am Kabel zu schaffen macht. Als dann die Gesetzeshüter kamen, zog sich der Herr zurück nach Georgia und gab an, überhaupt nicht zu wissen, wie es zu diesem Ausfall kommen konnte.

Vorbeugen statt heilen

Unabhängig von diesen Detaillösungen hat Becker für alle Anwender noch einen grundsätzlich Ratschlag auf Lager: "Dokumentieren Sie den Aufbau ihres Netzes penibel genau". Denn diese Dokumentation ist später bereits die halbe Miete bei der Fehlersuche oder hilft bei Erweiterungen, Störungen zu vermeiden, da eventuelle Wechselwirkungen teilweise bereits beim Blick in die Dokumentation ersichtlich sind. Last, but not least, sollte sich jeder Anwender fragen, was ihn ein Netzausfall wirklich kostet. So wird ein Unternehmen in die Ausfallsicherheit eines LANs im Börsensaal - dessen Ausfall den Ruin bedeuten kann - sicherlich mehr investieren als in das LAN der Verwaltung, wo die Auswirkungen nicht so gravierend sind.