Netzwerkfehler mit Befunden systematisch diagnostizieren

Wenn ein Befehl noch keine Diagnose ist

Im Architekturbüro Nordbogen meldet die Projektleiterin: “Der Raumkalender in Besprechungsraum 4 ist nicht erreichbar.” Das Wandterminal MIRA-04 zeigt weiterhin eine aktive Netzwerkverbindung. Die drei anderen Raumterminals öffnen den Kalender ohne Fehler.

Im Ticket stehen außerdem diese Sollwerte:

Clientnetz:       10.36.14.0/24
Standardgateway:  10.36.14.1
DNS-Server:       10.36.2.53
Kalenderdienst:   raumplan.intern -> 10.36.8.30

Das Domain Name System (DNS) übersetzt dabei den Namen raumplan.intern in eine IP-Adresse. In dieser Lektion vergleichst du seine Antwort mit dem dokumentierten Sollwert.

Du könntest jetzt mehrere Befehle nacheinander ausführen und hoffen, dass eine auffällige Zeile erscheint. Das wäre aber noch keine systematische Diagnose. Eine Diagnose verbindet eine konkrete Frage, einen passenden Test und einen Befund. Erst der Befund entscheidet über den nächsten Schritt.

Nach dieser Lektion kannst du:

• das gemeldete Symptom reproduzieren und seine Reichweite bestimmen,
• aus einem Soll-Ist-Vergleich eine prüfbare Hypothese ableiten,
• Ausgaben von ipconfig, ping und nslookup sinnvoll einordnen,
• nach einer Änderung den ursprünglichen Fehler erneut prüfen,
• den Weg von der Meldung bis zur Lösung im Ticket dokumentieren.

Du solltest bereits wissen, welche Aufgaben IP-Adresse, Präfix, Standardgateway und DNS-Server übernehmen. Wenn dir diese Rollen noch neu sind, beginne mit der Lektion “Einen Netzwerk-Client einrichten und systematisch testen”.

Beginne mit Symptom und Reichweite

Die Meldung “Netzwerk geht nicht” ist zu breit für einen gezielten Test. Frage zuerst, was tatsächlich nicht funktioniert:

• Welches Gerät und welche Anwendung sind betroffen?
• Seit wann tritt der Fehler auf?
• Lässt er sich wiederholen?
• Betrifft er nur eine Person, ein Gerät, einen Raum oder einen ganzen Standort?
• Was funktioniert trotz der Störung noch?
• Gab es kurz zuvor eine Änderung?

Für MIRA-04 prüfst du die Meldung direkt am Gerät. Der Aufruf von https://raumplan.intern endet reproduzierbar mit “Server nicht gefunden”. Ein zweites Terminal im Nachbarraum öffnet dieselbe Adresse. Damit hast du zwei belastbare Befunde: Der Fehler betrifft den Kalenderzugriff und ist auf MIRA-04 begrenzt.

Diese Eingrenzung verändert die Suche. Ein vollständiger Ausfall des zentralen Kalenderdienstes ist nun weniger wahrscheinlich. Eine abweichende Client-Konfiguration bleibt dagegen plausibel. “Weniger wahrscheinlich” bedeutet noch nicht “ausgeschlossen”. Es ist eine Hypothese, die weitere Befunde braucht.

Arbeite in einem Diagnosezyklus

Ein fester Zyklus verhindert, dass du gleichzeitig an mehreren Stellen änderst und danach nicht mehr weißt, welche Änderung gewirkt hat.

Der Zyklus ist wichtiger als eine starre Befehlsreihenfolge. Ein fehlender Link spricht für einen frühen Test an Kabel, Netzwerkkarte oder Switch-Port. Ein erfolgreicher Zugriff per IP bei einem Fehler über den Namen lenkt die Suche dagegen zur Namensauflösung. Du beginnst also grundlegend, nutzt aber bereits bekannte Befunde, statt jeden Test mechanisch zu wiederholen.

Jeder Test braucht eine Frage

Die folgende Übersicht ordnet häufige Prüfungen ihrer eigentlichen Frage zu. Sie ist kein Rezept, das du immer vollständig abarbeitest. ping nutzt üblicherweise Echo-Nachrichten des Internet Control Message Protocol (ICMP), um eine Antwort vom Ziel anzufordern.

Ein fehlgeschlagener ping ist kein vollständiger Beweis für einen ausgefallenen Host. Firewalls oder das Zielsystem können ICMP-Echoanfragen verwerfen, obwohl der benötigte Dienst erreichbar ist. Umgekehrt bestätigt eine Antwort auf ping nur den getesteten IP-Weg und ICMP-Austausch. Prüfe den eigentlichen Dienst deshalb immer mit einem dienstbezogenen Test oder über die Anwendung.

Werte die Ausgaben von MIRA-04 aus

Du hast den Fehler reproduziert und ein funktionierendes Vergleichsgerät gefunden. Jetzt zeigst du unter Windows die vollständige Client-Konfiguration an:

ipconfig /all

Die für den aktiven Adapter gekürzte Ausgabe lautet:

Beschreibung:           Ethernet-Adapter
DHCP aktiviert:         Nein
IPv4-Adresse:           10.36.14.84
Subnetzmaske:           255.255.255.0
Standardgateway:        10.36.14.1
DNS-Server:             10.36.2.54

Eine syntaktisch gültige IP-Adresse ist noch kein Beleg für eine richtige Konfiguration. Du vergleichst jeden Wert mit dem dokumentierten Soll. Adresse und Gateway passen zum Clientnetz. Beim DNS-Server gibt es eine Abweichung: Dokumentiert ist 10.36.2.53, eingetragen ist 10.36.2.54.

Die Abweichung führt zu einer Hypothese: MIRA-04 fragt einen veralteten DNS-Server und erhält deshalb keine passende Adresse für den Kalenderdienst. Bevor du die Konfiguration änderst, prüfst du, ob die Hypothese zu weiteren Befunden passt.

Der Netzwerkweg trägt bis zum Zielnetz

ping 10.36.14.1
ping 10.36.8.30

Beide Ziele antworten. Damit sind physischer Link, lokale IP-Kommunikation und der IP-Weg zum Netz des Kalenderdienstes für diesen Test belegt. Der Erfolg widerlegt die Vermutung, dass ein vollständiger Netzwerkweg fehlt. Er sagt noch nichts darüber aus, welche Adresse DNS für raumplan.intern liefert.

Die DNS-Abfrage macht die Abweichung sichtbar

nslookup raumplan.intern 10.36.2.54

Server:  dns-alt.nordbogen.intern
Address: 10.36.2.54

Name:    raumplan.intern
Address: 10.36.8.17

Der eingetragene DNS-Server antwortet, liefert aber 10.36.8.17. Laut Sollzustand arbeitet der Kalenderdienst unter 10.36.8.30. Ein Vergleich mit dem vorgesehenen DNS-Server schafft einen Gegenbefund:

nslookup raumplan.intern 10.36.2.53

Server:  dns01.nordbogen.intern
Address: 10.36.2.53

Name:    raumplan.intern
Address: 10.36.8.30

Jetzt trägt die Diagnose: MIRA-04 verwendet einen abweichenden DNS-Server. Dieser liefert für den benötigten Namen eine veraltete Zieladresse. Der Kalenderdienst selbst und der IP-Weg zu seiner dokumentierten Adresse sind erreichbar.

Ändere eine Sache und prüfe den Ausgangspunkt

Du korrigierst den statisch eingetragenen DNS-Server von 10.36.2.54 auf 10.36.2.53. Eine Änderung am zentralen DNS-Dienst wäre nicht begründet, denn der vorgesehene Server liefert bereits den korrekten Wert.

Danach prüfst du in dieser Reihenfolge:

1. Die Client-Konfiguration zeigt 10.36.2.53 als DNS-Server.
2. Die Abfrage für raumplan.intern liefert 10.36.8.30.
3. Der ursprüngliche Aufruf https://raumplan.intern öffnet den Kalender.
4. Eine neue Anmeldung und eine Testbuchung funktionieren.

Der dritte Schritt bestätigt das ursprüngliche Symptom. Der vierte Schritt geht bis zur benötigten Fachfunktion. Damit ist nicht nur eine Webseite sichtbar, sondern der tatsächliche Arbeitsablauf geprüft.

Wenn du bei der Diagnose personenbezogene oder sicherheitsrelevante Daten siehst, gehören sie nicht ungefiltert ins Ticket. Dokumentiere nur die Informationen, die andere Personen für Nachvollziehbarkeit und Weiterarbeit brauchen. Kennwörter, vollständige Zugangsdaten und unnötige Nutzerdaten bleiben außen vor.

Ein Ticket zeigt den Denkweg

Ein Eintrag wie “DNS geändert, geht wieder” hilft beim nächsten ähnlichen Fehler kaum. Eine nachvollziehbare Dokumentation trennt mindestens diese Punkte:

• Symptom und Reichweite: Was war für wen betroffen?
• Soll und Ist: Welche dokumentierte Abweichung gab es?
• Tests und Befunde: Was wurde mit welchem Ziel geprüft?
• Ursache: Welche Erklärung tragen die Befunde?
• Maßnahme: Was wurde tatsächlich geändert?
• Funktionsprüfung: Wurde der ursprüngliche Arbeitsablauf erfolgreich wiederholt?

Für MIRA-04 kann der Abschluss so aussehen:

Gerät: MIRA-04, Besprechungsraum 4
Symptom: https://raumplan.intern meldet reproduzierbar "Server nicht gefunden".
Reichweite: Nur MIRA-04 betroffen; Vergleichsterminal funktioniert.
Soll/Ist: DNS-Soll 10.36.2.53, eingetragen war 10.36.2.54.
Befunde: Gateway 10.36.14.1 und Ziel 10.36.8.30 per ICMP erreichbar.
         DNS 10.36.2.54 löste raumplan.intern zu 10.36.8.17 auf.
         DNS 10.36.2.53 lieferte die Solladresse 10.36.8.30.
Ursache: Veralteter statischer DNS-Eintrag am Client.
Maßnahme: DNS-Server am Client auf 10.36.2.53 korrigiert.
Prüfung: Namensauflösung liefert 10.36.8.30; Kalenderaufruf,
         Anmeldung und Testbuchung erfolgreich.

Die Dokumentation macht sichtbar, warum die Maßnahme begründet war. Sie unterscheidet außerdem Ursache und Symptom: Der nicht erreichbare Kalender war das Symptom. Der veraltete DNS-Eintrag am Client war die Ursache.

Übertrage den Diagnosezyklus

Was du aus der Diagnose mitnimmst

Eine reproduzierbare Netzwerkdiagnose ist keine Sammlung möglichst vieler Befehle. Sie ist eine Kette begründeter Entscheidungen:

1. Beschreibe das konkrete Symptom und seine Reichweite.
2. Vergleiche den Ist-Zustand mit dokumentierten Sollwerten.
3. Formuliere eine Hypothese, die ein Test widerlegen kann.
4. Ordne jede Ausgabe als begrenzten Befund ein.
5. Ändere nur, was die Befunde tragen.
6. Prüfe den ursprünglichen Arbeitsablauf erneut.
7. Dokumentiere Ursache, Maßnahme, Ergebnis und offene Grenzen.

Damit wird deine Arbeit auch für die nächste Person nachvollziehbar. Sie sieht nicht nur, welcher Wert am Ende geändert wurde, sondern welche Befunde zu dieser Entscheidung geführt haben.

Quellenbasis und Abgrenzung

Die berufliche Handlung folgt den Lernfeldern 3 und 6 des KMK-Rahmenlehrplans. Lernfeld 3 verbindet Client-Einbindung mit Prüfung und Dokumentation. Lernfeld 6 verlangt, Serviceanfragen einzuordnen, Fehlerursachen zu ermitteln, Lösungen im eigenen Support-Level umzusetzen und den Bearbeitungsstatus zu dokumentieren. Die Berufsbildpositionen 4, 5 und 8 tragen Betreuung, Qualitätssicherung, Störungsbehebung und Dokumentation von IT-Lösungen.

§ 9 der Fachinformatikerausbildungsverordnung nennt für den ersten Teil der Abschlussprüfung unter anderem das Konfigurieren und Testen eines IT-gestützten Arbeitsplatzes sowie das Kontrollieren und Protokollieren der Leistungserbringung. Dieser Prüfungsteil wird oft kurz AP1 genannt. Der interne AP1-Prüfungskatalog konkretisiert die Themenbreite mit Fehlermanagement, Störungs-Management, Supportanfragen sowie Test, Fehlersuche und Dokumentation von Netzwerkverbindungen. Die verwendeten Beispielprüfungen dienten nur dazu, wiederkehrende Aufgabenformen wie die Auswertung gekürzter Konfigurations- und Testausgaben zu erkennen. Szenario, Adressen, Befehlsausgaben, Aufgaben und Lösungen dieser Lektion sind neu erstellt.

Die technische Einordnung von ipconfig und nslookup orientiert sich an den Befehlsreferenzen von Microsoft Learn. Die Lektion behandelt eine Client-Störung in einem verwalteten IPv4-Netz. Sie ersetzt keine vertiefte Analyse von VLANs, Routingprotokollen, Paketmitschnitten, IPv6, WLAN-Funkproblemen oder zentralen Hochverfügbarkeitsdiensten. Sie sagt außerdem keine Inhalte eines bestimmten Prüfungstermins voraus.

Belegmatrix