Suchen

Aus dem Alltag eines Netzwerkers – die Fehlersuche im System Root Cause Analysis, Teil 2 - Flatternde Links und Auto-Negotiation

| Autor / Redakteur: Peter Mörsch / Ulrike Ostler

Nur ein Performance- und Fehler-Management in Verbindung mit einer präzisen Fehler-Ursachenforschung (Root Cause Analysis) garantiert eine nahtlose Kommunikation. Anhand von Beispielen aus dem Praxisalltag eines Netzwerkers wird diese These in einer dreiteiligen Serie belegt. Dieser Teil befasst sich mit flatternden Links und Auto-Negotiation.

Ohne die richtigen Werkzeuge, ist die Fehlersuche manchmal reine Glücksache, Bild: wolke 07
Ohne die richtigen Werkzeuge, ist die Fehlersuche manchmal reine Glücksache, Bild: wolke 07
( Archiv: Vogel Business Media )

Folgendes zur Ausgangslage: Das Unternehmen ABC arbeitet mit einem Netzwerk aus 5.000 Switchen im Backbone-, Etagen- und Edge-Bereich. Im Etagenverteiler-Bereich der Niederlassung München liegt im Switch KHM ein Hardware-Defekt vor: Link 3 flattert, das heißt, er fährt innerhalb von Sekunden herunter und anschließend wieder hoch.

Dieses Flattern geschieht unregelmäßig und immer nur dann, wenn Lastspitzen vorhanden sind und besonders große Pakete zu transportieren sind. Damit ist das Fehlverhalten zeitlich nicht vorherseh- und reproduzierbar.

Die Folgen

Wegen des flatterhaften Links im Switch müssen Pakete erneut versendet werden. Dadurch kommt es zu Verzögerungen in der Kommunikation.

Weil der Link im Etagenverteiler arbeitet, sind viele Mitarbeiter von dem Problem betroffen. Sie beschweren sich via Service Desk beim Netzwerk-Administrator, dass das Netzwerk nicht mit der gewohnten Performance arbeitet.

Die umständliche Variante der Fehlersuche- und -beseitigung

Der Administrator recherchiert zunächst, welche Applikationen die Mitarbeiter verwenden, um entsprechende Fehler ausschließen zu können. Dann schaltet er sich via Telnet ins Netz und pingt die Switches der entsprechenden Arbeitsgruppe an.

Da der Link in dem Moment nicht flattert, kann der Administrator zunächst keinen Fehler feststellen. Bei näherem Hinsehen erkennt er jedoch, dass die Uptime von Link 3 nur bei fünf Stunden liegt und dass damit vor fünf Stunden ein Fehler aufgetreten sein muss.

Er weiß jedoch nicht, dass der Fehler bereits seit drei Wochen vorliegt – und seitdem die Kommunikation beeinträchtigt –, den Anwendern aber erst jetzt der „Kragen geplatzt“ ist.

Der Administrator beschließt, Link 3 im Auge zu behalten und dessen Uptime regelmäßig zu kontrollieren. Er weiß aber selbst dann immer noch nicht, wie oft und wie lange der Link flattert, weil er sich immer nur punktuell aufschalten kann.

weiter mit: Der Chef wird informiert

Artikelfiles und Artikellinks

(ID:2040995)