Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Netzwerke und Systemintegration – Ein kleines Netz mit Abnahmetests übergeben

QR-Code

Netzwerke und Systemintegration – Ein kleines Netz mit Abnahmetests übergeben

Einleitung

Kurzbeschreibung: Du übergibst ein kleines Netz mit nachvollziehbaren Abnahmetests: erst Normalbetrieb, dann einen kontrolliert simulierten Ausfall und zuletzt die Wiederherstellung. Zielgruppe: Fachinformatiker/-innen für Systemintegration in der Ausbildung. Dauer: ca. 60–90 Minuten plus Projekt. Ergebnis: Testmatrix, Messbild, Fehlerbericht und Übergabeentscheidung.

Sicherheitsregel: Arbeite ausschließlich lokal oder in einer ausdrücklich freigegebenen, isolierten Schulungsumgebung. Die Python-Übung simuliert Zustände ohne Netzwerkschnittstelle, Ping, DNS-Anfragen oder fremde Ziele. Keine Produktivsysteme, Kundendaten, Zugangsdaten oder fremden Netze testen. Videos sind externe Angebote; Öffnen/Einbettung kann eine Verbindung zu YouTube herstellen.

Lerneinheiten

Einheit 1: Den Auftrag verstehen (5 Minuten)

Ausbildungsfall: In der fiktiven Lernwerkstatt Musterwerk sollen ein Arbeitsplatz, ein Switch, ein Gateway, ein DNS-Dienst und eine Beispielanwendung übergeben werden. Dein Ausbilder möchte drei Belege: Es funktioniert, ein Fehler wird erkannt und nach der Behebung funktioniert es wieder. Ein grüner Status allein ersetzt kein Abnahmeprotokoll.

Bildauftrag: Markiere Client, Switch und Weiterleitung im Schaubild. Es zeigt ein generisches LAN, nicht die konkrete Simulation.

Videoimpuls: Welche Geräte und Dienste müssen vor der Übergabe dokumentiert sein?

Einheit 2: Testnetz lesen (8 Minuten)

Fiktives Modell: Client 192.0.2.10/24, Gateway 192.0.2.1, lokaler DNS-Dienst 192.0.2.53, simulierter Dienst 198.51.100.80, Name portal.test. Die Netze 192.0.2.0/24 und 198.51.100.0/24 sind nach RFC 5737 ausschließlich Dokumentationspräfixe; .test ist für Tests vorgesehen (RFC 6761). Sie werden hier nicht auf einem echten Netzwerk konfiguriert.

 CLIENT 192.0.2.10          DNS 192.0.2.53
          \                    /
                 SWITCH
                   |
            GATEWAY 192.0.2.1
                   |
         PORTAL 198.51.100.80
        Name: portal.test
       (alles nur simuliert)

Der Switch verbindet Geräte im LAN, das Gateway führt zum anderen Subnetz. DHCP liefert normalerweise die Clientkonfiguration. Das DNS ordnet Namen einer Adresse zu. Ein bestandener Ping beweist allein noch nicht, dass die Anwendung läuft.

Vergleiche Stern- und Busstruktur; welche ähnelt unserem Switch-Aufbau?

Einheit 3: Sollwerte festlegen (8 Minuten)

Vor dem Test werden Prüfschritt, Sollwert und Nachweis vereinbart. Hier sind es fünf simulierte Kriterien.

Test-ID	Prüffrage	Soll im Normalbetrieb
A1	Ist der Link aktiv?	PASS
A2	Hat der Client eine gültige simulierte IP?	PASS
A3	Ist die modellierte Route über das Gateway nutzbar?	PASS
A4	Liefert DNS die erwartete Zieladresse?	PASS
A5	Ist der modellierte Testdienst nutzbar?	PASS

Vier DHCP-Phasen: Discover, Offer, Request, Acknowledge. Im Python-Labor wird DHCP nicht tatsächlich ausgeführt, nur sein Ergebnis modelliert.

Einheit 4: Normalbetrieb und Fehler eingrenzen (8 Minuten)

Normal: fünf PASS. Störung: Der simulierte DNS-Dienst fällt aus. Link, IP-Bezug und Gateway bleiben PASS; DNS und namensabhängiger Testdienst werden FAIL. Das ist eine erwartete Fehlerreaktion im Störungstest, keine bestandene Betriebsabnahme. Prüfe vom lokalen Link über die Konfiguration bis zur Anwendung und protokolliere die Ursache.

Die Grafik zeigt eine reale DNS-Abfragelogik; das Labor verwendet dagegen nur eine feste lokale Nachbildung.

Beispielbild eines Ping-Befehls, kein Mitschnitt aus dem Labor. Ein Echo-Erfolg sagt nichts Sicheres über DNS oder den Dienst.

Beobachtungsauftrag: Trenne Erreichbarkeit über IP von Namensauflösung.

Einheit 5: Wiederherstellen und erneut prüfen (7 Minuten)

Du setzt nur im Simulator den DNS-Zustand zurück. Danach vergleichst Du alle fünf Prüfpunkte mit der Ausgangsmessung. Erst Wiederholungsprüfung + Dokumentation erlauben eine positive Übergabeempfehlung. Ein DNS-Fehler und ein Gateway-Fehler wirken unterschiedlich: Beim Gateway-Ausfall bleibt der DNS-Dienst im selben LAN modellhaft verfügbar, die Anwendung im anderen Netz nicht.

Videoimpuls: Warum helfen getrennte Tests für lokale Kommunikation und Weiterleitung?

Einheit 6: Messdaten lesen und übergeben (7 Minuten)

Fiktive Prüfdaten – keine Messungen an echten Geräten:

Prüfschritt	Normal	DNS-Ausfall	Wiederhergestellt
Link	PASS	PASS	PASS
IP-Bezug	PASS	PASS	PASS
Gateway	PASS	PASS	PASS
DNS	PASS	FAIL	PASS
Testdienst	PASS	FAIL	PASS

Normalbetrieb      5/5  █████
DNS-Ausfall        3/5  ███░░
Wiederhergestellt  5/5  █████
Gateway-Ausfall    3/5  ███░░

Abnahmeentscheidung: Die Störung wurde nachweisbar erkannt und behoben; der abschließende Soll-Ist-Vergleich ist erfolgreich. In einem echten, autorisierten Abnahmetermin kommen die vereinbarten realen Prüfungen, Datenschutz, dokumentierte Restmängel und die Bestätigung durch die zuständige Person hinzu. Die Simulation allein ist kein Nachweis für eine betriebliche Anlage.

Isoliertes Python-Testlabor

Lokale Arbeitsumgebung

Speichere den folgenden Code als netzabnahme.py auf Deinem eigenen Rechner. Voraussetzung: Python 3.9 oder neuer, nur Standardbibliothek. Er verwendet keine Netzwerkzugriffe. Die IP-Adressen sind reine Zeichenketten für das Modell.

python netzabnahme.py demo
python netzabnahme.py labor
python netzabnahme.py test
python netzabnahme.py protokoll

demo visualisiert vier Zustände. labor ist eine lokale, interaktive Szenarioauswahl. test startet automatisierte Unit-Tests. protokoll schreibt nur die fiktive Datei abnahme_fiktiv.csv in den aktuellen Ordner. Unter manchen Systemen heißt der Befehl python3.

from dataclasses import dataclass, replace
from ipaddress import ip_address, ip_network
import csv
import sys
import unittest

LAN = ip_network("192.0.2.0/24")
TESTSERVER = "198.51.100.80"

@dataclass(frozen=True)
class Netz:
    kabel: bool = True
    dhcp: bool = True
    gateway: bool = True
    dns: bool = True
    dienst: bool = True
    client_ip: str = "192.0.2.10"
    dns_ziel: str = TESTSERVER

def pruefen(netz):
    link = netz.kabel
    try:
        adresse = link and netz.dhcp and ip_address(netz.client_ip) in LAN
    except ValueError:
        adresse = False
    route = adresse and netz.gateway
    namen = adresse and netz.dns and netz.dns_ziel == TESTSERVER
    anwendung = route and namen and netz.dienst
    return {
        "Link": link,
        "IP-Bezug": adresse,
        "Gateway": route,
        "DNS": namen,
        "Testdienst": anwendung,
    }

NORMAL = Netz()
FAELLE = {
    "normal": NORMAL,
    "dns-ausfall": replace(NORMAL, dns=False),
    "wiederhergestellt": replace(NORMAL, dns=True),
    "gateway-ausfall": replace(NORMAL, gateway=False),
}

def bericht(name, netz):
    ergebnisse = pruefen(netz)
    anzahl = sum(ergebnisse.values())
    print(f"\n{name:18} {anzahl}/5 " + "█" * anzahl + "░" * (5-anzahl))
    for test, okay in ergebnisse.items():
        print(f"  {test:12}: {'PASS' if okay else 'FAIL'}")

class Abnahmetests(unittest.TestCase):
    def test_normalbetrieb(self):
        self.assertTrue(all(pruefen(NORMAL).values()))

    def test_dns_ausfall(self):
        werte = pruefen(FAELLE["dns-ausfall"])
        self.assertEqual([k for k, ok in werte.items() if not ok],
                         ["DNS", "Testdienst"])

    def test_wiederherstellung(self):
        self.assertEqual(pruefen(FAELLE["wiederhergestellt"]),
                         pruefen(NORMAL))

    def test_gateway_ausfall(self):
        werte = pruefen(FAELLE["gateway-ausfall"])
        self.assertTrue(werte["DNS"])  # DNS liegt im gleichen LAN
        self.assertFalse(werte["Testdienst"])

    def test_falsche_client_ip(self):
        werte = pruefen(replace(NORMAL, client_ip="203.0.113.9"))
        self.assertFalse(werte["IP-Bezug"])
        self.assertFalse(werte["Testdienst"])

def main():
    modus = sys.argv[1] if len(sys.argv) > 1 else "demo"
    if modus == "test":
        unittest.main(argv=[sys.argv[0]], verbosity=2)
    elif modus == "demo":
        for name, netz in FAELLE.items():
            bericht(name, netz)
    elif modus == "protokoll":
        with open("abnahme_fiktiv.csv", "w", newline="",
                  encoding="utf-8") as datei:
            tabelle = csv.writer(datei, delimiter=";")
            tabelle.writerow(["Szenario", "Pruefpunkt", "Ergebnis"])
            for name, netz in FAELLE.items():
                for pruefpunkt, okay in pruefen(netz).items():
                    tabelle.writerow([name, pruefpunkt,
                                      "PASS" if okay else "FAIL"])
        print("Nur lokale Datei erzeugt: abnahme_fiktiv.csv")
    elif modus == "labor":
        print("Nur lokale Simulation. Keine Netzwerkverbindung.")
        while True:
            name = input("normal/dns-ausfall/wiederhergestellt/"
                         "gateway-ausfall/ende: ").strip()
            if name == "ende":
                break
            if name in FAELLE:
                bericht(name, FAELLE[name])
            else:
                print("Unbekanntes Szenario")
    else:
        print("Aufruf: python netzabnahme.py [demo|labor|test|protokoll]")
        sys.exit(2)

if __name__ == "__main__":
    main()

Kontrollwerte: normal = 5/5, dns-ausfall = 3/5, wiederhergestellt = 5/5, gateway-ausfall = 3/5. Die fünf automatischen Tests müssen OK ergeben. Interpretation: Alle Unit-Tests sind erfolgreich, obwohl der gezielt erzeugte Ausfall zwei fachliche Prüfpunkte als FAIL meldet: Genau dieses Fehlerbild war vorab erwartet.

Gestufte Hilfen und begründetes Feedback

Aufgabenniveau	Hilfe 1: Denkfrage	Hilfe 2: Konkreter Hinweis	Feedback und Begründung
Basis	Wo beginnt der Kommunikationsweg?	Prüfe A1 und A2 vor A4 und A5.	Ein fehlender Link macht nachgelagerte Aussagen unzuverlässig; die Reihenfolge verhindert Fehlschlüsse.
Anwendung	Welche Prüfpunkte ändern sich bei DNS-Ausfall?	Vergleiche `normal` und `dns-ausfall` zeilenweise.	DNS und der namensabhängige Dienst fallen aus; IP-Bezug und Gateway bleiben hier unabhängig funktionsfähig.
Transfer	Wäre bei Gateway-Ausfall auch DNS gestört?	In diesem Modell liegt DNS im selben LAN.	Nein: Die lokale Namensauflösung kann PASS bleiben; die entfernte Anwendung ist wegen der ausgefallenen Route FAIL.

Mini-Auftrag mit Selbstfeedback: Setze im Code client_ip="203.0.113.9" in einem zusätzlich selbst erstellten Zustand. Erwartung: A2 bis A5 werden FAIL, A1 bleibt PASS. Warum? Die Adresse liegt nicht im vorgegebenen Clientnetz. Stelle danach den Ausgangszustand wieder her und führe die Unit-Tests erneut aus.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was gehört zu einem aussagekräftigen Abnahmetest? (Sollwert und dokumentiertes Istergebnis) (!Nur eine grüne Statusanzeige) (!Nur die Gerätebezeichnung) (!Nur die Rechnung)

Welcher Dienst ordnet in diesem Beispiel portal.test einer IP-Adresse zu? (DNS) (!DHCP) (!Ethernet) (!NTP)

Welche Funktion wird vom simulierten DHCP-Zustand repräsentiert? (Die Bereitstellung einer Clientkonfiguration) (!Das Speichern des Abnahmeprotokolls) (!Die Stromversorgung des Routers) (!Das Verschlüsseln der Testdatei)

Welche drei Prüfungen bleiben beim modellierten DNS-Ausfall erfolgreich? (Link und IP-Bezug und Gateway) (!DNS und Testdienst und Gateway) (!DNS und Link und Testdienst) (!Testdienst und DNS und IP-Bezug)

Was bedeutet ein erfolgreicher Ping allein? (Eine Antwort auf die getestete Echoanfrage) (!Der Webdienst ist fehlerfrei) (!DNS muss korrekt arbeiten) (!Das gesamte Netz ist abgenommen)

Was geschieht in diesem Modell bei einem Gateway-Ausfall? (DNS kann bestehen und der entfernte Dienst fällt aus) (!Alle fünf Prüfungen bestehen) (!Der lokale DNS-Dienst muss ausfallen) (!Der Client wechselt automatisch zu IPv6)

Warum wird nach der Störungsbehebung erneut getestet? (Um die wiederhergestellten Sollwerte zu belegen) (!Um die Fehlerbeschreibung zu löschen) (!Um fremde Systeme zu überprüfen) (!Um die ursprünglichen Kriterien zu ändern)

Welches Netz ist als Dokumentationspräfix reserviert? (192.0.2.0/24) (!8.8.8.0/24) (!1.1.1.0/24) (!224.0.0.0/4)

Welche Datei erzeugt der lokale Befehl protokoll? (abnahme_fiktiv.csv) (!kundenliste.csv) (!passwoerter.txt) (!router_backup.bin)

Wann ist eine reale Netzabnahme fachlich belastbar? (Nach autorisierten Tests mit Nachweisen und Freigabe) (!Sobald der Simulator fünf grüne Anzeigen zeigt) (!Wenn ein einzelnes Kabel funktioniert) (!Wenn der Auftrag unvollständig ist)

Memory

Linkstatus	Physische Verbindung im Modell
DHCP-Zustand	Simulierter Client-IP-Bezug
Gateway-Prüfung	Weiterleitung zum anderen Subnetz
DNS-Prüfung	Auflösung des Testnamens
Testdienst	Verfügbarkeit der Modellanwendung
Wiederholungsprüfung	Erneuter Vergleich mit den Sollwerten

Drag and Drop

Ordne die richtigen Begriffe zu.	Abnahmefunktion
Linkkontrolle	Physische Verbindung bewerten
Adresskontrolle	Clientkonfiguration prüfen
Gatewaytest	Weiterleitung prüfen
Namensprüfung	Zielnamen auflösen
Dienstprüfung	Anwendungsfunktion beurteilen
Nachtest	Fehlerbehebung belegen

Kreuzworträtsel

Switch	Welches Gerät verbindet die Endgeräte im lokalen Sternnetz?
Gateway	Wie heißt der Übergang zum anderen Subnetz?
Subnetz	Wie nennt man einen logisch abgegrenzten IP-Adressbereich?
Protokoll	Wie heißt die schriftliche Aufzeichnung der Prüfergebnisse?
Wiederherstellung	Wie nennt man den Prozess zurück zum Sollbetrieb nach einer Störung?
Freigabe	Welche Bestätigung wird vor der endgültigen Übergabe benötigt?

LearningApps

Dies ist eine externe Suchansicht und kein eigens geprüfter Test. Keine personenbezogenen Daten eingeben.

Lückentext

Ein Abnahmetest vergleicht ein Istergebnis mit einem vereinbarten

.

Die physische Verbindung wird im Modell durch den

dargestellt.

Die automatische Clientkonfiguration wird typischerweise durch

bereitgestellt.

Der Übergang in ein anderes Subnetz ist das

.

Für die Namensauflösung ist

zuständig.

Beim simulierten DNS-Ausfall fällt auch der namensabhängige

aus.

Nach einer Behebung folgt die

.

Die dokumentierten Ergebnisse stehen im

.

Die Endentscheidung berücksichtigt eine autorisierte

.

Offene Aufgaben

Leicht – Basis

Netzwerkplan: Zeichne das fiktive Netz mit Client, Switch, DNS, Gateway und Dienst. Feedback: Die räumliche Trennung der beiden Netze macht die notwendige Weiterleitung sichtbar.
IP-Adresse: Beschrifte den Netzplan mit allen vier Dokumentationsadressen und portal.test. Feedback: Vollständige Adressierung verhindert unklare Prüfziele.
Testfall: Formuliere für A1 und A4 je einen Sollwert. Feedback: Ein Ergebnis ist nur bewertbar, wenn die Erwartung vorher feststeht.
Dokumentation: Erstelle eine Legende für PASS und FAIL. Feedback: Verständliche Kennzeichnungen ermöglichen eine prüfbare Übergabe.

Standard – Anwendung

Python-Labor: Starte demo und erkläre die beiden FAIL-Ergebnisse beim DNS-Ausfall. Feedback: Der Anwendungsfehler folgt hier aus der fehlenden Namensauflösung.
Fehleranalyse: Starte labor und vergleiche DNS- und Gateway-Ausfall. Feedback: Unterschiedliche Fehlerbilder helfen bei der Eingrenzung.
CSV-Bericht: Erzeuge abnahme_fiktiv.csv und markiere die kritischen Prüfpunkte. Feedback: Maschinenlesbare Evidenz vereinfacht die Nachprüfung.
Erklärvideo: Drehe mit selbst gezeichneten Bildern ein 60-Sekunden-Video über Normalbetrieb, Störung und Nachtest. Feedback: Wer Ursache und Folgewirkung erklären kann, hat das Testmodell verstanden.

Schwer – Transfer

Testabdeckung: Ergänze im Python-Modell einen fiktiven Ausfall des Testdienstes mit erwarteten Resultaten und einem Unit-Test. Feedback: Gezielte Fehlerszenarien prüfen, ob die Testmatrix Fehler unterscheidet.
Risikobewertung: Entscheide, ob die Übergabe bei dauerhaftem DNS-Fehler verantwortbar wäre, und begründe. Feedback: Ein nicht erfülltes kritisches Sollkriterium muss als offener Mangel bewertet werden.
Wiederanlauf: Entwirf einen Wiederherstellungsplan mit Verantwortlichen als Rollen ohne Namen sowie Prüfreihenfolge und Rückfalloption. Feedback: Ein Plan ist belastbar, wenn Schritte, Nachweis und Entscheidung verbunden sind.
Fachgespräch: Spiele ein Übergabegespräch mit Ausbilderin oder Ausbilder durch und verteidige den Unterschied zwischen simuliertem Test und realer Abnahme. Feedback: Transparente Grenzen verhindern unbegründete Freigaben.

Lernkontrolle

Ursachenanalyse: Im Labor steht Link auf PASS, DNS auf FAIL und Testdienst auf FAIL. Welche weiteren Daten wären nötig, um einen realen DNS-Fehler statt eines Anwendungsfehlers nachzuweisen?
Fehlereingrenzung: Zwei Abnahmeläufe liefern jeweils drei PASS. Warum kann die gleiche Anzahl unterschiedliche Ursachen verbergen? Vergleiche die Einzelprüfpunkte.
Änderungsmanagement: Eine Nachbesserung repariert DNS, beschädigt jedoch die Gateway-Konfiguration. Entwickle die sinnvolle Nachtest-Reihenfolge.
Qualitätssicherung: Formuliere zwei zusätzliche Akzeptanzkriterien für einen echten, ausdrücklich autorisierten Laboraufbau und erkläre, wie Du sie ohne Fremdnetze prüfen würdest.
Entscheidungsfindung: Begründe anhand des Protokolls eine Freigabe, eine Freigabe mit dokumentierten Restmängeln oder eine Ablehnung. Lege die Bedingungen offen.
Datenschutz: Ein echtes Abnahmeprotokoll enthält Geräte- und Personendaten. Entwickle eine datensparsame Übergabe mit Rollen, Zugriffsschutz und Aufbewahrungsregel.

Lernnachweis

Abzugeben sind ausschließlich eigene, fiktive oder ausdrücklich genehmigte Schulungsdaten.

Ein beschrifteter Netzplan mit getrennten Subnetzen, Dienstnamen und Sollwerten.
Eine vollständige Testmatrix für Normalbetrieb, DNS-Ausfall und Wiederherstellung.
Die lokale Testausgabe mit fünf erfolgreichen Unit-Tests und begründeter Fehlerinterpretation.
Die selbst erzeugte Datei abnahme_fiktiv.csv sowie ein kurzer Befund zur Ursache und Behebung.
Eine schriftliche Übergabeentscheidung mit Grenzen der Simulation, offenen Punkten und nachvollziehbarer Freigaberegel.

Bewertung: Fachlich korrekt, reproduzierbar, datensparsam, sicher durchgeführt und in Ursache-Wirkung-Zusammenhängen begründet. Wichtig: Der Simulator ersetzt keinen Realtest.

OERs zum Thema

Geprüfte Fachquellen:

RFC 5737 – reservierte IPv4-Dokumentationsnetze.
RFC 6761 – besondere Verwendung von .test.
RFC 2131 – technische Grundlagen des DHCP.
Python-Dokumentation – IP-Adressprüfung.
Python-Dokumentation – reproduzierbare Unit-Tests.

Medienrechte und Quellenhinweise: Dateiseiten auf Wikimedia Commons enthalten Urheber, Lizenz und gegebenenfalls Namensnennungs- und Weitergabepflichten. Die folgenden Dateien wurden inhaltlich und hinsichtlich ihrer ausgewiesenen Lizenzen geprüft:

LAN topology.svg – Retraza, CC0 1.0.
NetzwerkTopologien.svg – Foobaz, Parzi, Predatorix, CC BY-SA 4.0.
DHCPDORA.png – Endaargaanweweer, CC0 1.0.
Dns-abfrage.svg – Hank van Helvete, CC BY-SA 2.5.
Ping command example.png – Michel Bakni, CC BY-SA 4.0.

YouTube-Videos sind zur Vertiefung extern eingebettet; aus ihrer öffentlichen Verfügbarkeit folgt keine freie Weiterverwendungslizenz. Keine fremden Videos herunterladen oder neu veröffentlichen. Die Quellen sind Lehrvideos der Reihe „Netzwerktechnik mit Filius“ (IP, DHCP, DNS, Routing, Projekt).