LF3.13 – Netzwerkfunktion systematisch prüfen und protokollieren

Konfigurationsprüfung ist nicht Funktionsprüfung

Ein Test braucht zuerst ein Prüfkriterium

Ein Diagnosewerkzeug wird nicht einfach gestartet, nur weil es verfügbar ist.

Zuerst wird formuliert:

• Welche Funktion soll geprüft werden?
• Welches Ergebnis wird erwartet?
• Welches Testziel eignet sich dafür?
• Welche Beobachtung gilt als bestanden?
• Was lässt sich aus einem negativen Ergebnis tatsächlich ableiten?

K-27: definierte Testziele

Für das vollständig fiktive Laborszenario werden folgende Testziele ausdrücklich festgelegt:

Alle IP-Adressen liegen in Dokumentationsadressräumen. Der Name unter .example ist ausschließlich für Dokumentations- und Übungszwecke vorgesehen.

Prüfreihenfolge: vom Nahen zum Weiteren

1. Client- und Interfacezustand
   Ist weiterhin der in LF3.12 dokumentierte Zustand vorhanden?
2. lokale IP-Kommunikation
   Kann das definierte Ziel 192.0.2.70 im eigenen Subnetz wie vorgesehen erreicht werden?
3. Standardgateway
   Kann die definierte lokale Gatewayadresse 192.0.2.65 wie vorgesehen erreicht werden?
4. entfernte IP-Kommunikation
   Kann das definierte entfernte Testziel 198.51.100.80 wie vorgesehen erreicht werden?
5. DNS-Namensauflösung
   Liefert der konfigurierte Resolver für portal.k27.example die definierte Antwort 198.51.100.80?

ICMP Echo und Ping einordnen

Für IPv4 beschreibt ICMP unter anderem Echo Request und Echo Reply.

Ein Werkzeug wie Ping nutzt typischerweise ICMP Echo, um eine gezielte Erreichbarkeitsbeobachtung zu erzeugen.

Für ICMPv4 sind dabei insbesondere bekannt:

• Echo Request – Typ 8,
• Echo Reply – Typ 0.

Ein negatives Ping-Ergebnis vorsichtig interpretieren

Keine Echo-Antwort bedeutet zunächst nur:

Außerhalb eines ausdrücklich definierten Labortests können unter anderem folgende Situationen relevant sein:

• das Ziel ist tatsächlich nicht erreichbar,
• ICMP Echo wird gefiltert,
• das Ziel beantwortet Echo nicht,
• ein Pfadproblem besteht,
• eine lokale Konfiguration ist fehlerhaft.

Deshalb gilt:

Lokale IP-Kommunikation gezielt prüfen

K27-CL-12 verwendet:

Das definierte lokale Testziel lautet:

Beide Adressen liegen im Netz 192.0.2.64/27.

Eine erfolgreiche ICMP-Echo-Prüfung gegen das ausdrücklich dafür definierte lokale Testziel liefert im K-27-Labor eine positive Beobachtung für die lokale IP-Kommunikation.

Gatewayprüfung gezielt einordnen

Das Standardgateway des Clients lautet:

Im K-27-Labor ist dieses Ziel ausdrücklich so definiert, dass es ICMP Echo beantwortet.

Die Prüfung beantwortet damit:

Sie beantwortet noch nicht automatisch, ob jeder denkbare entfernte Netzwerkpfad funktioniert.

Entfernte IP-Konnektivität getrennt prüfen

Für den nächsten Prüfschritt wird verwendet:

Dieses Ziel liegt nicht im lokalen Netz 192.0.2.64/27.

Eine erfolgreiche Prüfung zeigt im fiktiven Labor, dass das definierte entfernte IP-Testziel unter den Testbedingungen erreicht wurde.

Erst diese Ebene sollte positiv beurteilt werden, bevor ein fehlgeschlagener Namenszugriff vorschnell als allgemeines Verbindungsproblem bezeichnet wird.

DNS erst als eigene Prüfebene betrachten

Für K-27 gilt:

• DNS-Resolver: 198.51.100.53,
• Testname: portal.k27.example,
• erwartete Laborantwort: 198.51.100.80.

Mit einem geeigneten DNS-Abfragewerkzeug wird gezielt geprüft, ob die erwartete Namensauflösung erfolgt.

Warum die Reihenfolge hilft

Angenommen:

• lokales Testziel erreichbar,
• Gateway erreichbar,
• entferntes IP-Testziel erreichbar,
• DNS-Testname nicht wie erwartet auflösbar.

Dann ist folgende Aussage fachlich belastbar:

Nicht belastbar wäre ohne weitere Prüfung:

Beobachtung und Hypothese trennen

Systematische Fehlereingrenzung

Eine sinnvolle Diagnosekette lautet:

1. Beobachtung eindeutig formulieren.
2. zugehöriges Prüfkriterium bestimmen.
3. bereits erfolgreiche Prüfschritte berücksichtigen.
4. mögliche Fehlerbereiche eingrenzen.
5. nächsten gezielten Prüfschritt auswählen.
6. neue Beobachtung dokumentieren.
7. Hypothese bestätigen, verwerfen oder offenlassen.

Drei Statuswerte für das Prüfprotokoll

Das SemaTrain-Netzwerkprüfprotokoll

Alle Prüfdaten und erwarteten Antworten sind vollständig fiktive SemaTrain-Labordaten.

Ein Prüfprotokoll dokumentiert auch negative Ergebnisse

Ein nicht bestandenes Prüfkriterium wird nicht versteckt.

Beispiel:

Die DNS-Prüfung bleibt in diesem Beispiel offen, bis die für den Test benötigte IP-Konnektivität weiter eingegrenzt wurde.

Ein Werkzeug liefert keine vollständige Diagnose

Ein häufiger Denkfehler lautet:

Das ist fachlich zu weitgehend.

Eine erfolgreiche ICMP-Echo-Prüfung sagt nichts direkt darüber aus, ob beispielsweise:

• DNS-Namensauflösung korrekt funktioniert,
• ein bestimmter Anwendungsdienst verfügbar ist,
• eine andere Zieladresse erreichbar ist,
• alle Anforderungen des Clientauftrags erfüllt sind.

Auch ein DNS-Test hat eine begrenzte Aussage

Eine erfolgreiche DNS-Abfrage zeigt, dass die definierte Namensauflösung im Test das erwartete Ergebnis geliefert hat.

Sie beweist nicht automatisch:

• dass jeder Anwendungsdienst erreichbar ist,
• dass jeder DNS-Name korrekt ist,
• dass jede Netzwerkverbindung funktioniert,
• dass die gesamte Client-Integration fehlerfrei ist.

Keine Infrastrukturadministration während der Diagnose

LF3.13 prüft clientbezogen.

Nicht Bestandteil sind:

• Switch-CLI,
• Router-CLI,
• Routingkonfiguration,
• DHCP-Serveradministration,
• DNS-Serveradministration,
• DNS-Zonenänderungen,
• umfassendes Netzwerkmonitoring,
• Serverbetrieb oder Serverdiagnose.

LF3.13 endet mit Fakten – LF3.14 bewertet

Am Ende von LF3.13 liegen vor:

• definierte Prüfkriterien,
• durchgeführte Prüfschritte,
• positive und negative Ergebnisse,
• beobachtete Abweichungen,
• eingegrenzte Fehlerbereiche,
• offene Punkte,
• ein nachvollziehbares Prüfprotokoll.

Noch nicht Gegenstand sind:

• Gesamtbewertung der Client-Integration,
• Bewertung des gesamten Arbeitsprozesses,
• wirtschaftliche Gesamtbewertung,
• ökologische Gesamtbewertung,
• Optimierungsmaßnahmen für den Gesamtprozess.

Diese Abschluss- und Reflexionsphase folgt in LF3.14.

PRAXISAUFGABE

Praktische Lernaufgabe

Für den fiktiven Client K27-CL-15 gelten:

• Client-IP: 192.0.2.79/27,
• Gateway: 192.0.2.65,
• DNS-Resolver: 198.51.100.53,
• lokales Testziel: 192.0.2.70,
• entferntes Testziel: 198.51.100.80,
• DNS-Testname: portal.k27.example.

Für das fiktive Szenario werden folgende Beobachtungen vorgegeben:

• Clientparameter entsprechen dem Zielzustand,
• 192.0.2.70 antwortet wie vorgesehen,
• 192.0.2.65 antwortet wie vorgesehen,
• 198.51.100.80 antwortet nicht wie vorgesehen,
• DNS wurde noch nicht abschließend geprüft.

Erstellen Sie:

1. eine Prüfreihenfolge,
2. für jeden Schritt ein Soll-Ergebnis,
3. eine sachliche Ist-Beobachtung,
4. einen Status BESTANDEN / NICHT BESTANDEN / OFFEN,
5. eine begründete Eingrenzung des nächsten Prüfbereichs,
6. mindestens zwei Hypothesen, ohne sie als bewiesene Ursachen auszugeben.

Praxisauftrag

Selbsttraining – keine Abgabe erforderlich.

Erstellen Sie für einen vollständig fiktiven Client ein eigenes Netzwerkprüfprotokoll.

Es muss mindestens enthalten:

• Clientkennung,
• Zielzustand,
• lokales IP-Testziel,
• Gateway-Testziel,
• entferntes IP-Testziel,
• DNS-Testname und erwartete Antwort,
• Prüfpunkt,
• Soll,
• Ist / Beobachtung,
• Status,
• Schlussfolgerung,
• offene Punkte.

Erzeugen Sie drei unterschiedliche Fehlerbilder:

1. lokale IP-Prüfung nicht bestanden,
2. lokale Prüfungen bestanden, entfernte IP-Prüfung nicht bestanden,
3. IP-Prüfungen bestanden, DNS-Prüfung nicht bestanden.

Beschreiben Sie jeweils, welcher nächste Prüfbereich sinnvoll ist.

Nehmen Sie keine Switch-, Router-, DHCP- oder DNS-Serveränderungen vor.

Bewerten oder optimieren Sie noch nicht den gesamten Arbeitsprozess aus LF3.

SELBSTKONTROLLE

Selbstkontrolle

• Leite ich jeden Test aus einem Prüfkriterium ab?
• Trenne ich Konfigurationsprüfung und Funktionsprüfung?
• Prüfe ich lokale Kommunikation vor weiter entfernten Ebenen?
• Trenne ich IP-Konnektivität und DNS-Namensauflösung?
• Kann ich ICMP Echo fachlich einordnen?
• Behandle ich ein negatives Ping-Ergebnis nicht als automatischen Ursachenbeweis?
• Trenne ich Beobachtung und Hypothese?
• Dokumentiere ich negative Ergebnisse ebenso wie positive?
• Nutze ich BESTANDEN, NICHT BESTANDEN und OFFEN eindeutig?
• Dokumentiere ich offene Punkte?
• Vermeide ich ungeplante Infrastrukturänderungen?
• Habe ich Gesamtbewertung und Optimierung für LF3.14 offengelassen?

REFLEXION

Reflexion

• Warum beweist eine korrekte Clientkonfiguration noch keine funktionierende Netzwerkkommunikation?
• Warum benötigt jeder Test ein definiertes Soll?
• Warum ist eine fehlende Echo-Antwort noch keine eindeutige Ursachenfeststellung?
• Warum sollte DNS erst als eigene Prüfebene beurteilt werden?
• Warum müssen Beobachtung und Hypothese getrennt werden?
• Warum sind offene Ergebnisse besser als eine erfundene technische Sicherheit?
• Welche Informationen benötigt LF3.14 aus dem Prüfprotokoll?