Skip to content

Allgemeine Dokumentations- und Abgaberichtlinie

für Netzwerktechnik‑Übungen (alle Jahrgänge)

Diese Richtlinie definiert die Mindestanforderungen für die Erstellung und Abgabe einer Übungsdokumentation im Fach Netzwerktechnik.

1. Allgemeine Anforderungen

Abgabeform:

  • Ein einzelnes PDF‑Dokument
  • Zusätzlich: alle relevanten Projektdateien (z. B. .pkt, .gns3, .pcap)
  • Deutsch, technisch korrekt, präzise Formatierung:
    • Einheitliche Schrift (Empfehlung: Arial/Calibri 10–12 pt)
    • Klar strukturierte Überschriften
    • Einrückungen und Listen sinnvoll einsetzen
  • Lesbarkeit:
    • Screenshots groß und scharf
    • CLI‑Ausgaben nicht abgeschnitten
  • Eigenständigkeit:
    • Keine kopierten fremden Konfigurationen → keine Bewertung

2. Struktur der Dokumentation

2.1 Deckblatt

  • Titel der Übung
  • Name, Klasse, Datum
  • Fach / Lehrer
  • Einzel- oder Gruppenarbeit

2.2 Kurzbeschreibung der Aufgabenstellung

In eigenen Worten: * Welche Themen werden behandelt? * Was soll am Ende funktionieren/verifiziert sein? * Welche Geräte/Werkzeuge wurden verwendet (Router, Switch, Packet Tracer, wireshark etc.)?

2.3 Vorgehensweise / Durchführung

Dies ist der Hauptteil. Er beschreibt schrittweise, was durchgeführt wurde.

2.3.1 Netzwerkszenario

  • Beschreibung des Setups (physisch oder virtuell)
  • Topologiegrafik oder Screenshot der Simulation

2.3.2 Konfigurationen

Abhängig von der Art der Übung - Beispiele für Inhalte, die dokumentiert werden müssen:

  • IP‑Adressierungen (IPv4/IPv6)
  • VLAN‑Konfiguration
  • Routing (statisch, dynamisch)
  • Security‑Einstellungen (ACLs, Port Security, Firewall-Regeln)
  • Switching‑Features (STP, EtherChannel)
  • WLAN‑Konfigurationen
  • DHCP/DNS/NAT‑Konfigurationen
  • Virtualisierung (VM‑Netzwerke, Virtual Switches)

Wichtig: Konfigurationsausschnitte als CLI‑Blöcke einfügen – aber nur relevante Teile.

2.3.3 Tests & Überprüfung

Zu jeder Übung gehören aussagekräftige Tests:

  • Ping‑Tests / Traceroute
  • Ausgabe von Routingtabellen
  • Erreichbarkeit zwischen VLANs
  • DHCP‑Lease-Informationen
  • Capture-Ausschnitte in Wireshark
  • Fehleranalyse + Lösungen

Wichtig: Alle Tests müssen mit Screenshots oder CLI‑Ausgaben dokumentiert werden.

2.4 Analyse & Beantwortung von Theoriefragen

Wenn zur Übung Fragestellungen gehören:

  • Jede Frage muss klar beantwortet werden
  • Antworten in vollständigen Sätzen
  • Fachbegriffe korrekt verwenden
  • Grafiken oder Tabellen zur Verdeutlichung sind möglich

2.5 Key Learnings

Die „Key Learnings“ sollen präzise darstellen, welche technischen und methodischen Fähigkeiten während der Übung tatsächlich erworben oder verbessert wurden.

Dies ist ein Pflichtteil für jede Dokumentation.

Die folgenden Punkte dienen als Orientierung. Je nach Übung sind unterschiedliche Aspekte relevant.

Fachliche Key Learnings

Beispiele:

  • Verständnis der Funktionsweise zentraler Netzwerkprotokolle (z. B. IPv4/IPv6, ARP/NDP, DHCP, OSPF, VLANs, STP).
  • Souveräner Umgang mit Router‑/Switch‑Konfigurationen im CLI.
  • Fähigkeit, Routingtabellen zu interpretieren und Fehler darin zu erkennen.
  • Erkennen der Zusammenhänge zwischen Layer‑2‑ und Layer‑3‑Konfigurationen.
  • Effiziente Nutzung von Tools wie Packet Tracer, GNS3, Wireshark, ip/ping/traceroute.
  • Verständnis typischer Fehlerszenarien und deren Auswirkungen auf die Netzkommunikation.

Methodische Key Learnings

Beispiele:

  • Systematisches Troubleshooting (z. B. „von Layer 1 nach oben prüfen“, Ping‑Matrices).
  • Bedeutung einer strukturierten Netzplanung (Subnetting, Topologien, IP‑Vergabe).
  • Saubere Dokumentation als Arbeitswerkzeug, nicht nur zur Abgabe.
  • Bessere Einschätzung, welche Schritte kritisch sind (z. B. Gateway‑Konfiguration, Routing‑Statements).
  • Fähigkeit, komplexe Probleme in kleinere Teilprobleme zu zerlegen.

Persönliche / Lernprozessbezogene Key Learnings

Beispiele:

  • Verständnis, dass Fehler ein natürlicher Teil des Lernprozesses sind.
  • Höhere Sicherheit im Umgang mit Netzwerkgeräten und Konfigurationssyntax.
  • Erkenntnis, dass Tests und Validierung nicht am Ende, sondern im Prozess stattfinden sollten.
  • Wichtigkeit einer klaren Struktur und Übersicht im Projekt (z. B. nummerierte Konfigurationsschritte).

3. Quellenangaben

Jede technische Dokumentation muss alle externen Quellen enthalten, die zur Erstellung der Übung genutzt wurden. Dazu gehören z. B. Hersteller‑Dokumentationen, Standards, Lehrmaterialien, Webseiten oder Fachbücher.

Die Quellen sollen am Ende der Dokumentation in einem eigenen Kapitel stehen.

Grundsätzliche Regeln für Quellen

  • Alle verwendeten Informationen müssen nachvollziehbar zitiert werden.
  • URLs müssen vollständig angegeben sein.
  • Quellen müssen serös und fachlich korrekt sein (Cisco, IEEE, IETF, Hersteller‑Dokus, Fachliteratur).
  • KI‑Tools dürfen nicht als technische Quelle für Konfigurationsbefehle verwendet werden.
  • Bei Online‑Quellen: Abrufdatum angeben.
  • Wenn Schulunterlagen verwendet wurden: Name des Skriptes oder der Folien angeben.

4. Formale Qualitätskriterien

  • Dokument muss vollständig sein (keine leeren Kapitel).
  • Screenshots:
    • lesbar
    • nicht zu klein
    • keine privaten Informationen
  • CLI‑Auszüge:
    • strukturiert
    • logisch gruppiert
    • immer mit Angabe des Geräts
  • Topologien:
    • ordentlich
    • konsistente Beschriftungen
  • Nachvollziehbarkeit:
    • Jede Konfiguration muss überprüfbar sein
    • Kein Schritt darf fehlen

5. Optionaler Anhang

Empfohlen, falls vorhanden:

  • Komplette Konfigurationsausgaben
  • Tabellen (Adressierung, Ports, VLANs…)
  • Wireshark‑Mitschnitte (Auszüge)
  • Subnetzberechnungen
  • Topologiediagramme

Pre-Read Material

Datei Typ Größe Geändert
📕 Introduction Graf-iz v1.0.pdf .pdf 148.0 KB 2026-05-05 06:42
📕 Literatur und Promptverzeichnis.pdf .pdf 207.57 KB 2026-05-05 06:42
📕 ki_abarb.pdf .pdf 233.96 KB 2026-05-05 06:42

Attachments

Ordner nicht gefunden: 2nd year/Allgemein/Attachments

b9bf93b May 05, 2026 08:41:16 by Berndt Sevcik