Von der Störungsmeldung zur bewiesenen Ursache

Die sechs Fragen, die du vor dem ersten Befehl stellst

Die Erfassung der Meldung ist der Teil der Fehlersuche, den Erfahrene am wenigsten überspringen. Sie entscheidet, an welcher Stelle du anfängst, und sie liefert den Test, mit dem du am Ende prüfst, ob der Fehler behoben ist. Notiere die Antworten wörtlich, nicht in deiner Interpretation.

Besonders die Frage nach Änderungen wird gern vergessen, weil der Melder sie nicht beantworten kann. Beantworte sie selbst: Change-Kalender, Commit-Historie der Konfigurationen, Logmeldungen mit dem Text „Configured from“ auf Cisco-Geräten und die Freigaben der Firewall zeigen, was sich bewegt hat.

• Wer ist betroffen: ein Gerät, ein Raum, eine Abteilung, ein Standort oder alle?

• Was genau geht nicht: welche Anwendung, welches Ziel, welche Fehlermeldung im Wortlaut?

• Seit wann: erste Beobachtung mit Uhrzeit, dauerhaft oder zeitweise, zu bestimmten Tageszeiten?

• Was geht noch: andere Ziele, andere Anwendungen, dasselbe Ziel von einem anderen Gerät?

• Was hat sich geändert: Umzug, neues Kabel, Update, neue Firewall-Regel, neuer Switch, neues Zertifikat?

• Lässt es sich reproduzieren: tritt der Fehler bei jedem Versuch auf, und kannst du ihn selbst auslösen?

Vier Methoden und wann welche passt

Die Methoden schließen sich nicht aus. Du beginnst mit der, die zum Symptom passt, und wechselst, wenn ein Befund die Richtung ändert. Wer etwa mit divide and conquer feststellt, dass schon das Gateway nicht antwortet, arbeitet danach bottom-up weiter.

Eine fünfte Methode ist der Vergleich mit einem funktionierenden Gegenstück: dieselbe Portkonfiguration an einem Nachbarport, dieselbe Firewall-Regel an einem anderen Standort, derselbe Client in einem anderen VLAN. Ein diff zwischen zwei Konfigurationen findet Unterschiede, die beim Lesen untergehen, etwa ein fehlendes switchport trunk allowed vlan add.

Werkzeuge je Schicht auf Cisco IOS, Linux und Windows

Für jede Schicht gibt es einen Befehl, der die entscheidende Frage beantwortet. Die Tabelle nennt ihn für die drei Plattformen, die in den meisten Netzen zusammenkommen. Auf Cisco-Switches mit IOS XE gelten dieselben Befehle wie auf klassischem IOS.

Wichtig bei den Fehlerzählern: Ein absoluter Wert sagt wenig, weil die Zähler seit dem letzten Neustart oder dem letzten clear counters laufen. Lies den Wert, warte eine Minute unter Last und lies erneut. Steigt der CRC-Zähler, hast du ein aktuelles Problem auf Schicht 1.

Ping und traceroute so lesen, dass sie etwas beweisen

Ein Ping beweist mehr als „geht“ oder „geht nicht“, wenn du ihn gezielt einsetzt. Auf Cisco IOS schickt ein einfacher Ping laut Cisco fünf Pakete zu je 100 Byte mit zwei Sekunden Zeitlimit; ein Ausrufezeichen steht für eine Antwort, ein Punkt für eine Zeitüberschreitung. Fehlt beim ersten Ping auf ein neues Ziel nur das erste Paket, ist das meist die ARP-Auflösung und kein Fehler. Mit der Option source pingst du von einer bestimmten Schnittstelle, etwa der SVI des Client-VLANs, und prüfst so den Rückweg in genau dieses Netz.

Mit size und df-bit prüfst du die MTU auf dem Pfad. Kommen kleine Pakete durch und große mit gesetztem DF-Bit nicht, liegt irgendwo ein Tunnel oder ein Link mit kleinerer MTU, und die ICMP-Meldung „Fragmentation needed“ (Typ 3, Code 4 nach RFC 792) wird vermutlich gefiltert. Das erklärt das Bild, bei dem eine Webseite den Kopf lädt und dann hängt.

Traceroute schickt Pakete mit steigender TTL; jeder Router, bei dem die TTL abläuft, antwortet mit ICMP Time Exceeded. Cisco IOS verwendet laut Cisco UDP-Pakete an Port 33434, traceroute unter Linux standardmäßig ebenfalls UDP, tracert unter Windows dagegen ICMP Echo. Sternchen in der Mitte bei weiter antwortenden Folge-Hops sind normal, weil Router solche Antworten begrenzen oder filtern. Endet der Pfad dagegen dauerhaft an einem Hop, liegt die Ursache dort oder beim nächsten Gerät, und meist ist es eine fehlende Route oder eine Firewall auf dem Rückweg.

! Rückweg ins Client-VLAN mitprüfen
ping 10.50.1.10 repeat 100 source Vlan20

! MTU auf dem Pfad prüfen: 1500 Byte mit gesetztem DF-Bit
ping 10.50.1.10 df-bit size 1500 source Vlan20

! Pfad Hop für Hop
traceroute 10.50.1.10 source Vlan20

! Welche Route wird für das Ziel genutzt?
show ip route 10.50.1.10
show ip cef 10.50.1.10 detail

Die erste Runde in zwei Minuten am Client

Bevor du am Switch oder an der Firewall suchst, klärst du am betroffenen Gerät vier Grundfragen. Hat es eine gültige Adresse, kennt es sein Gateway, erreicht es das Ziel auf Schicht 3, und ist der Port des Dienstes erreichbar? Die Reihenfolge der Befehle folgt dieser Logik. Ein Ergebnis wie eine Adresse aus 169.254.0.0/16 beendet die Suche auf dem Client sofort und schickt dich zum DHCP.

Der Vergleich von Namens- und Adresstest ist der schnellste Weg, DNS als Ursache zu erkennen oder auszuschließen. Geht Test-NetConnection auf die IP-Adresse und Port 445 durch, auf den Namen aber nicht, liegt die Ursache in der Namensauflösung und nicht im Netz.

# Linux
ip -br addr
ip route get 10.50.1.10
ip neigh show 10.20.30.1
ping -c 4 10.20.30.1
tracepath -n 10.50.1.10
dig +short fs01.firma.example
nc -vz 10.50.1.10 445

# Windows PowerShell
Get-NetIPConfiguration
Get-NetNeighbor -IPAddress 10.20.30.1
Test-NetConnection 10.50.1.10 -TraceRoute
Resolve-DnsName fs01.firma.example -DnsOnly
Test-NetConnection 10.50.1.10 -Port 445
Test-NetConnection fs01.firma.example -Port 445

Hypothese statt Raten, Mitschnitt als Beweis

Eine brauchbare Hypothese nennt eine Ursache und eine Beobachtung, die eintreten muss, wenn sie stimmt. „Es liegt an der Firewall“ ist keine Hypothese. „Die Firewall verwirft TCP 445 von 10.20.30.0/24 nach 10.50.1.10, deshalb sieht der Server kein SYN“ ist eine, denn ein Mitschnitt am Server zeigt in einer Minute, ob das SYN ankommt.

Für den Mitschnitt auf einem Catalyst-Switch spiegelst du den Port des Clients mit einer SPAN-Session auf einen freien Port mit Analyse-Notebook. Auf Linux-Servern genügt tcpdump mit Filter auf die beteiligten Adressen. Zeichne bei Streitfällen an beiden Enden gleichzeitig auf, dann siehst du, auf welcher Strecke ein Paket verloren geht oder verändert wird. Achte vorher auf die Regeln deines Hauses zum Mitschneiden, denn ein Mitschnitt kann personenbezogene Inhalte enthalten.

! Cisco Catalyst: Port des Clients auf Analyseport spiegeln
configure terminal
monitor session 1 source interface Gi1/0/14 both
monitor session 1 destination interface Gi1/0/48
end
show monitor session 1

# Linux-Server: nur den Verkehr mit dem Client aufzeichnen
tcpdump -i eth0 -nn -w /tmp/ticket-4711.pcap host 10.20.30.57 and port 445

Wenn sich der Fehler als DNS-Problem entpuppt

Ein erheblicher Teil der Meldungen „Server nicht erreichbar“ endet nicht im Netz, sondern in der Namensauflösung. Die Abgrenzung gelingt mit einem einzigen Paar von Tests: dieselbe Verbindung einmal mit IP-Adresse, einmal mit Namen. Klappt die Adresse und der Name nicht, prüfst du, welchen DNS-Server der Client fragt, welche Antwort er bekommt und ob ein veralteter Eintrag im Cache liegt.

Ab diesem Punkt verlagert sich die Suche auf die DNS-Server, im Windows-Netz meist die Domänencontroller. Dort geht es um Zonen, Weiterleitungen, Replikation und dynamische Registrierung, also um Themen, die mit Switches und Routen nichts mehr zu tun haben. Für das Netz bleibt die Aufgabe, sicherzustellen, dass der Client den DNS-Server auf UDP und TCP 53 erreicht, denn größere Antworten fallen auf TCP zurück und scheitern an Regeln, die nur UDP erlauben.

Was ins Ticket gehört, damit der nächste Fall schneller geht

Die Dokumentation einer Störung hat zwei Leser: den Kollegen, der denselben Fehler in drei Monaten wiedersieht, und die Person, die entscheidet, ob ein Problem dauerhaft abgestellt werden muss. Für beide reicht kein „Port neu gestartet, geht wieder“. Schreibe so, dass jemand ohne Vorwissen die Ursache nachvollziehen kann.

Wiederkehrende Muster sind der eigentliche Gewinn. Drei Tickets zu Ports im falschen VLAN innerhalb eines Quartals zeigen, dass die Vorlage für neue Ports oder der Ablauf bei Umzügen fehlerhaft ist. Diese Ursache behebt kein Neustart, sondern eine Änderung am Prozess.

• Symptom im Wortlaut des Melders und die präzisierte Fassung mit Gerät, Ziel und Uhrzeit

• Umfang und geprüfte Änderungen im Zeitraum

• Gewählte Methode und Befund je geprüfter Schicht, auch die unauffälligen

• Ursache mit Beleg: Befehlsausgabe, Logzeile oder Name der pcap-Datei

• Durchgeführte Änderung mit Rückfallweg und Zeitpunkt

• Gegenprobe mit demselben Test und Bestätigung des Melders

• Hinweis, ob Netzplan, Portliste oder Vorlage angepasst wurden