Bei der Fehlerbehebung in Netzwerken sollte nach einem strukturierten und reproduzierbaren Prozess vorgegangen werden. Dadurch lässt sich vermeiden, dass Konfigurationen ohne ausreichende Analyse verändert oder mögliche Ursachen unsystematisch untersucht werden.
Der dargestellte Prozess orientiert sich dabei an den Inhalten der CompTIA Network+ Zertifizierung.
Problem identifizieren
Zunächst muss das eigentliche Problem möglichst eindeutig identifiziert und eingegrenzt werden.
Dazu gehören insbesondere:
- Informationen zum Problem sammeln
- Betroffene Benutzer, Systeme und Netzwerkbereiche bestimmen
- Symptome und Fehlermeldungen erfassen
- Feststellen, seit wann das Problem besteht
- Kürzlich durchgeführte Änderungen berücksichtigen
- Problem nach Möglichkeit reproduzieren
- Logs, Monitoring und vorhandene Dokumentation einbeziehen
Bei der Aufnahme einer Netzwerkstörung helfen gezielte Fragen dabei, das Fehlerbild schnell einzugrenzen.
| Bereich | Beispielfragen |
|---|---|
| Fehlerbild | Was genau funktioniert nicht? Welche Fehlermeldung wird angezeigt? |
| Zeitpunkt | Seit wann besteht das Problem? Wann hat es zuletzt funktioniert? |
| Häufigkeit | Tritt das Problem dauerhaft oder nur sporadisch auf? |
| Betroffene Systeme | Welches Gerät, welche Anwendung oder welcher Dienst ist betroffen? |
| Umfang | Sind auch andere Anwender oder Geräte betroffen? |
| Standort | Wo tritt das Problem auf: Büro, Homeoffice, bestimmter Standort? |
| Verbindung | Erfolgt der Zugriff über LAN, WLAN oder VPN? |
| Erreichbarkeit | Funktionieren andere Anwendungen, Webseiten oder Netzwerkressourcen? |
| Reproduzierbarkeit | Kann das Problem reproduziert werden? Welche Schritte führen zum Fehler? |
| Änderungen | Wurde kurz vor Auftreten des Problems etwas geändert, installiert oder aktualisiert? |
| Bisherige Maßnahmen | Was wurde bereits zur Fehlerbehebung versucht? Hat sich dadurch etwas verändert? |
| Vergleichstest | Funktioniert es mit einem anderen Gerät, Benutzer, Netzwerk oder Standort? |
Ziel dieses Schrittes ist eine möglichst klare Beschreibung des Fehlerbildes.
Theorie zur wahrscheinlichen Ursache entwickeln
Auf Basis der gesammelten Informationen werden mögliche Ursachen abgeleitet.
Dabei sollte zunächst mit den einfachsten und wahrscheinlichsten Ursachen begonnen werden. Anschließend kann die Analyse schrittweise auf komplexere Zusammenhänge ausgeweitet werden.
Zur strukturierten Eingrenzung kann beispielsweise das OSI-Modell verwendet werden. Je nach Fehlerbild kann dabei Bottom-Up, Top-Down oder gezielt auf einzelnen Layern gearbeitet werden.
Neben den genannten Methoden, die sich am OSI-Modell orientieren, gibt es jedoch auch weitere Verfahren.
| Methode | Startpunkt | Vorgehensweise | Besonders geeignet für |
|---|---|---|---|
| Top-down | Anwendung / Benutzersicht | Vom oberen OSI-Layer schrittweise nach unten arbeiten | Probleme mit bestimmten Anwendungen oder Diensten |
| Bottom-up | Physische Verbindung / Layer 1 | Vom unteren OSI-Layer schrittweise nach oben arbeiten | Link-, Kabel-, SFP-, Switchport- und grundlegende Verbindungsprobleme |
| Divide and Conquer | Mitte des OSI-Modells, häufig Layer 3 | Auf einem mittleren Layer beginnen und abhängig vom Testergebnis nach oben oder unten weiterarbeiten | Schnelle Eingrenzung bei zunächst unklarer Fehlerursache |
| Follow the Path | Quelle der Kommunikation | Den Kommunikationspfad vom Client bis zum Ziel Schritt für Schritt verfolgen | Routing-, Firewall-, VLAN-, VPN- oder Erreichbarkeitsprobleme |
| Spot the Differences (Compare-Configurations) | Funktionierendes Vergleichssystem | Konfiguration eines funktionierenden Systems mit dem betroffenen System vergleichen | Unterschiedliche VLANs, IP-Konfigurationen, Firewall-Regeln oder Gerätekonfigurationen |
| Move the Problem (Swap-Components) | Betroffene Komponente | Komponenten gezielt tauschen oder an anderer Stelle testen und prüfen, ob der Fehler „mitwandert“ | Kabel-, SFP-, Port-, Client- oder Hardwareprobleme |
| Compare Baselines | Bekannter funktionierender Zustand | Aktuellen Zustand mit Baselines, Monitoring-Daten oder früheren Konfigurationen vergleichen | Performanceprobleme, schleichende Veränderungen oder Fehler nach Änderungen |
Theorie testen
Die vermutete Ursache wird anschließend durch geeignete Tests überprüft.
Wird die Theorie bestätigt, kann mit der Planung der Lösung begonnen werden.
Wird sie nicht bestätigt, muss eine neue mögliche Ursache entwickelt und getestet werden.
Maßnahmenplan erstellen
Nach der Identifikation der Ursache wird ein Plan zur Behebung des Problems erstellt.
Dabei sollten insbesondere berücksichtigt werden:
- Erforderliche Änderungen
- Mögliche Auswirkungen
- Abhängigkeiten
- Notwendige Freigaben
- Wartungsfenster
- Backup der Konfiguration
- Rollback-Möglichkeit
Die eigentliche Änderung sollte erst erfolgen, wenn klar ist, wie das Problem behoben und die Änderung gegebenenfalls rückgängig gemacht werden kann.
Lösung implementieren oder eskalieren
Die geplante Maßnahme wird umgesetzt.
Kann die Fehlerursache nicht im eigenen Verantwortungsbereich behoben werden, erfolgt eine Eskalation an die zuständige Stelle.
Bei einer Eskalation sollten die bisher gewonnenen Informationen und Testergebnisse vollständig weitergegeben werden.
Funktionalität überprüfen
Nach Umsetzung der Maßnahme wird überprüft, ob das ursprüngliche Problem tatsächlich behoben wurde.
Dabei sollte nicht nur das ursprüngliche Fehlerbild getestet werden. Es muss ebenfalls sichergestellt werden, dass durch die Änderung keine anderen Funktionen beeinträchtigt wurden.
Zusätzlich sollte geprüft werden, ob präventive Maßnahmen sinnvoll sind, um ein erneutes Auftreten des Problems zu verhindern.
Ergebnisse dokumentieren
Abschließend wird der gesamte Vorgang dokumentiert.
Dazu gehören:
- Fehlerbild
- Ursache
- Durchgeführte Analyse
- Umgesetzte Maßnahme
- Ergebnis
- Gegebenenfalls präventive Maßnahmen
Die Dokumentation erleichtert die Bearbeitung zukünftiger Störungen und ermöglicht den Aufbau einer Wissensdatenbank für wiederkehrende Fehlerbilder.
Der Troubleshooting-Prozess im Überblick
Eine strukturierte Netzwerk-Fehlerbehebung folgt damit einem einfachen Grundprinzip:
Insbesondere die Trennung zwischen Analyse, Hypothese, Test und eigentlicher Änderung verhindert vorschnelle Eingriffe und sorgt dafür, dass Netzwerkprobleme nachvollziehbar und reproduzierbar bearbeitet werden.
