XPLN/Lernbereiche

F13 · Betrieb · Diagnose

Systematische Fehlersuche

Kapitel in dieser Lernstufe

Das lernst du

  • Hypothesen mit passenden Messpunkten prüfen.
  • DHCP-, DNS-, Routing- und Identitätsfehler getrennt beheben.

Voraussetzungen: G10 · Die Konfiguration überprüfenF08 · VLANs und mehrere SubnetzeF09 · DHCP-Relay und giaddrF12 · Paketmitschnitte auswerten

„Keine Verbindung“ ist eine Beobachtung, keine Ursache. Ein guter Diagnoseweg verändert zunächst möglichst wenig und sammelt Befunde, die zwischen Ursachen unterscheiden.

Jede Messung trennt zwei Fehlerbereiche

Kein OFFER am Client: Wo trennt sich der Weg?Anfrage am Serversichtbar?NeinJaClientwegVLAN / RelayHinweg prüfenAntwort verlässtden Server?NeinJaDienst, Scopeund Pool prüfenRückweg +Relayzustellung
Grafik vergrößern
Kein OFFER am Client: Wo trennt sich der Weg?Anfrage am Serversichtbar?NeinJaClientwegVLAN / RelayHinweg prüfenAntwort verlässtden Server?NeinJaDienst, Scopeund Pool prüfenRückweg +Relayzustellung
Diagnosebaum für den Befund: Der Client sieht kein OFFER. Ist seine Anfrage am Server nicht sichtbar, werden Clientweg, VLAN, Relay und Hinweg geprüft. Ist sie sichtbar, trennt eine zweite Messung die Serverentscheidung vom Rückweg: Keine Antwort am Serverausgang führt zu Dienst, Scope und Pool; eine sichtbare Antwort führt zu Rückweg und Relayzustellung. Keine der Beobachtungen beweist allein die genaue Ursache.

Vom Client zum Server und zurück

Beginne bei Link und Adapter. Prüfe dann Anschluss/VLAN, DHCP-Modus, Clientzustand und aktuelle Lease. Beobachte DISCOVER bzw. REQUEST im Clientnetz. Fehlt die Nachricht dort, muss ein anderer Teil untersucht werden als bei einer am Server sichtbaren Anfrage.

Danach Relay, Hin-/Rückroute und Filter prüfen. Am Server folgen Dienst, Bindung, Scopezuordnung, Aktivierung, freie Kapazität und Reservierung/Identität. Eine Antwort am Server ohne Antwort am Client weist auf den Rückweg oder die Auslieferung hin, nicht auf einen vollständig fehlenden Pool.

Nach der Vergabe weiterprüfen

Sind ACK und Clientkonfiguration vorhanden, vergleiche Maske, Gateway, DNS und Suffix mit der Planung. Teste lokale und entfernte IP-Ziele sowie Namen getrennt. Ein DNS-Fehler wird nicht durch wiederholte zufällige Pooländerungen behoben.

Ändere eine belegte Ursache und wiederhole denselben Test. Dokumentiere Zeitpunkt, Ausgangslage, Messung, Änderung, Ergebnis und Rückfalloption. Bei mehreren Fehlern ist ein Teilerfolg wichtig: Nach Relayreparatur kann ein zuvor verdeckter DNS-Fehler sichtbar werden.

Hypothesen nach ihrer unterscheidenden Messung ordnen

Der Befund „DISCOVER ohne OFFER am Client“ passt zu mehreren Ursachen: Anfrage erreicht den Server nicht, kein passender Scope, keine freie Adresse, bewusste Ablehnung oder verlorene Antwort. Der nächste sinnvolle Schritt ist deshalb keine beliebige Reparatur, sondern eine Messung am Servereingang. Ist dieselbe Anfrage dort sichtbar, werden rein clientseitige Sendeprobleme unwahrscheinlicher; die Serverauswahl und der Rückweg bleiben offen.

Siehst du ein OFFER am Serverausgang, aber nicht am Client, verschiebt sich die Hypothese erneut. Prüfe dann Routing, Filter und Relayzustellung. Wenn der Client anschließend einen REQUEST an einen anderen Anbieter richtet, war das ursprüngliche OFFER vielleicht korrekt, wurde aber nicht gewählt. Jeder Befund reduziert den Suchraum, ohne mehr zu behaupten, als er zeigt.

Eine Reparatur mit Gegenprobe abschließen

Nach einer Änderung wiederholst du denselben ursprünglichen Test mit derselben Clientrolle. Zusätzlich prüfst du einen Fall, der weiterhin unverändert funktionieren muss, etwa einen anderen Scope. Das schützt vor einer Reparatur, die nur den ersten Client versorgt und dabei ein Nachbarnetz beschädigt. Eine breite Firewallöffnung wäre beispielsweise kein ausreichender Abschluss, solange der benötigte Verkehrsweg nicht genauer bestimmt ist.

Dokumentiere zuletzt den Zusammenhang als überprüfbare Kette: falsches Relayziel, fehlende Anfrage am Server, korrigiertes Ziel, sichtbarer kompletter Bezug, richtige Clientparameter und erfolgreicher Diensttest. Eine solche Kette ist für spätere Störungen nützlicher als eine Liste versuchter Befehle. Bleibt ein Befund unerklärt, wird er als offene Frage festgehalten und nicht aus dem Abschlussbericht entfernt.

DURCHGEARBEITETES BEISPIEL

Neue PCs scheitern, alte funktionieren

  1. Alte PCs haben gültige Leases; neue bekommen APIPA. Das beweist nicht, dass der Server erreichbar ist.
  2. Link und VLAN stimmen. DISCOVER ist im Büro sichtbar, am Server nicht. Relayziel zeigt auf .20.11 statt .20.10.
  3. Ziel korrigieren. Nun kommen ACKs an, aber Namen scheitern: Die Scopeoption liefert DNS .20.99.
  4. DNS berichtigen, erneuern, Sollwerte und Namenstest prüfen. Beide Ursachen samt Beobachtungen getrennt dokumentieren.

Ergebnis: Die Diagnose erklärt jeden Befund und kontrolliert das Ergebnis. Eine einzige richtige Vermutung ersetzt keine Abnahme.

Typische Fehler

  • Funktionierende Altclients können nur von noch gültigen Leases profitieren.
  • Mehrere gleichzeitige Änderungen zerstören die Vergleichbarkeit.
  • Eine Option kann falsch sein, obwohl der Lease korrekt vergeben wurde.

Praktisch anwenden

P11 öffnen P12 öffnen P16 öffnen P20 öffnen P24 öffnen P36 öffnen

Offizielle Quellen

Versionsbezüge geprüft am 14. Oktober 2026. Produktkonfigurationen werden im jeweiligen isolierten Labor validiert.