--- name: packet-tracer-ccna description: CCNA-Lab-Tutor für Cisco Packet Tracer 9.0.0 — .pka/.pkt-Labs lesen, analysieren und erklären; eigene IOS-Configs prüfen (pt_check_lab); Übungslabs generieren (pt_generate_lab); Konfigurations-Aufgaben autonom lösen via pt_apply_configs. Trigger: "CCNA", "Packet Tracer", ".pka", ".pkt", "Lab lösen", "Lab prüfen", "IOS-Config", "Übungslab generieren", "Cisco Lab". Live-Verify einer laufenden PT-Instanz nur opt-in via cisco-pt-mcp. Nicht verwenden für: OT/Industrieprotokolle, IE-3400/ISA-3000/PLC/Smart-Grid. --- # packet-tracer-ccna CCNA-Lab-Tutor für Cisco Packet Tracer 9.0.0. **Prozeduraler Skill** (SkillOpt-trainiert): Dieses Dokument ist der trainierbare Zustand — es beschreibt *Verfahren*, nicht nur Features. Optimiert via `eval/`-Harness (Rollout → Reflect → Gate); siehe `OPTIMIZATION.md`. ## Arbeitsmodus wählen (Entscheidungsregel) | Anfrage | Modus | Erster Schritt | |---|---|---| | "erkläre dieses Lab" / ".pka lesen" | Lesen+Coachen | `pt_read_lab(path)` | | "prüfe meine Lösung" | Prüfen | `pt_check_lab(student_path, solution_path)` | | "generier ein Übungslab" | Generieren | `pt_generate_lab(spec)` | | "löse das Lab" / "konfiguriere autonom" | Autonom | Prozedur unten | | "prüfe live" / "wirklich pingen" (PT+Bridge offen) | Prüfen (live, opt-in) | `references/live-verify-cisco-pt-mcp.md` | ## Verbindliche Prozedur — Autonomes Lösen **Niemals raten. Jeder Config-Schritt stammt aus `activity`/`grading` oder einer reference.** 1. **LESEN** — `pt_read_lab(path)` → `{devices, links, configs, activity, grading}`. 2. **ANFORDERUNGEN extrahieren** — aus `activity`+`grading` als prüfbare Liste; nicht aus der Topologie erraten. 3. **CONFIGS ableiten** — genau ein Config-Block für **jedes Gerät, dem die Anforderungen eine Konfiguration zuweisen**: Router/Switch immer, **PC/Server nur, wenn die Anforderungen ihm explizit eine IP/Gateway geben** (eine bloß *erwähnte* PC ohne Adress-Vorgabe NICHT konfigurieren). Kein gefordertes Gerät auslassen, kein nicht-gefordertes hinzufügen. Format nach **Config-Format-Vertrag** (unten). Kanonische Reihenfolge innerhalb eines Netzgeräts: `VLAN-Definitionen → Access/Trunk-Interface → Routing → Services (DHCP/NAT/ACL)`. 4. **ANWENDEN** — `pt_apply_configs(path, configs, out)`. 5. **VERIFIZIEREN** — `pt_check_lab(out, solution)`; `diff`-Liste leer = fertig. Bei Abweichungen: gezielt korrigieren (nicht ganze Config neu schreiben), zurück zu 4. ## Tool-Vertrag ``` pt_read_lab(path) -> {devices, links, configs, activity, grading} pt_check_lab(student_path, solution_path) -> [{device, kind, detail}, ...] pt_generate_lab(spec={topic, devices, difficulty}) -> .pkt-Pfad pt_apply_configs(path, configs, out) -> .pkt-Pfad # configs: {device: IOS-Text} ``` CLI (ohne MCP): `uv --directory ~/cisco/pt-ccna run pt-ccna {read|diff|solve|devices}`. ## Config-Format-Vertrag (verbindlich — Scoring vergleicht Config-Text exakt) `pt_check_lab` vergleicht den **gespeicherten Config-Text pro Gerät** **verbatim** — nur Whitespace je Zeile getrimmt, Leerzeilen ignoriert; sonst exakt, reihenfolgesensitiv. Eine Abweichung lässt das **ganze Gerät** als falsch zählen (0.15 Strafe pro Gerät). Daher: - **Geräte-Vollständigkeit (wichtigster Hebel):** jedes Gerät, dem die Anforderungen eine Konfiguration zuweisen, braucht einen Block. Ein fehlender Block (leere Running-Config) ist der **teuerste** Scoring-Fehler. Umgekehrt: ein nicht gefordertes Gerät NICHT konfigurieren (erzeugt `extra`-Diffs). - **End-Geräte (PC/Server): nur konfigurieren, wenn die Anforderungen eine IP/Gateway nennen** — dann genau zwei Zeilen, OHNE `configure terminal`: `ip ` und `default-gateway `. Eine PC, die nur als Access-Port-Ziel erwähnt wird (ohne Adress-Vorgabe), bleibt unkonfiguriert. - **Netzgeräte (Router/Switch): erste Zeile IMMER bare `configure terminal`.** Danach kanonische Reihenfolge (s. Prozedur Schritt 3); Adresse `ip address `, dann `no shutdown`; globale Befehle (`ip route …`, `router ospf 1`, `ip nat …`, `ip dhcp …`) **nach** den Interface-Blöcken; **kein** abschließendes `end`/`write`. - **Niemals Prompt-Präfixe ausgeben** (`SW1#`, `SW1(config-if)#`, `R1(config)#` …). Die Referenzen sind bare Befehle — ein Präfix lässt jede Zeile verbatim abweichen und versenkt das ganze Gerät. - **Interface-Token exakt kleingeschrieben mit Leerzeichen vor der Nummer:** `gigabitEthernet 0/0/0`, `fastEthernet 0/1`, `interface vlan 10`. Casing/Schreibweise zählt (verbatim-Vergleich, keine Normalisierung). ## Verifikationsregeln (mandatory vor `pt_apply_configs`) - **Interfaces**: jedes genutztes Interface `no shutdown` — vergessen ist der häufigste Fehler. - **Trunk**: `switchport trunk encapsulation dot1q` **nur** auf 3560/3650; 2960/2950 weglassen. - **OSPF**: Wildcard = invertierte Maske (`/24`→`0.0.0.255`); `router-id` manuell; `passive-interface` auf LAN; `auto-cost reference-bandwidth` auf allen Routern gleich. - **NAT**: `ip nat inside` = LAN, `ip nat outside` = WAN; NAT-ACL mit `permit`, nicht `deny`. - **ACL**: extended nah an der **Quelle**, standard nah am **Ziel**; implizites `deny any` am Ende bedenken; Richtung `in`/`out` aus Sicht des Interfaces. - **DHCP**: `ip dhcp excluded-address` vor Pool; `ip helper-address` auf dem Client-Subnetz-Interface. - **STP**: Root erzwingen via `priority 4096` oder `root primary`; PortFast+BPDU Guard nur an Edge-Ports, nie am Trunk. - **Troubleshooting**: bottom-up OSI 1→7; `show`-Befehle aus `references/troubleshooting.md`. ## Fehlervermeidungsregeln (aus Rollout-Mißerfolgen abgeleitet) - Config-Reihenfolge ist **signifikant** für das Scoring — kanonisch halten (s.o.). - **Kein gefordertes Gerät auslassen** — PC/Server konfigurieren, sobald die Anforderungen ihm eine IP/Gateway geben (leerer Block = teuerster Fehler); bloß *erwähnte* PCs ohne Adress-Vorgabe NICHT anfassen (sonst `extra`-Diffs). - `configure terminal`-Präambel lab-abhängig → im VERIFIZIEREN-Schritt an `extra`/`missing`-Diff angleichen, nicht blind setzen. - Kein `no shutdown`-Vergessen auf physischem Interface bei Subinterfaces (Router-on-a-Stick). - `encapsulation dot1Q` **vor** `ip address` auf Subinterfaces. - Native VLAN auf **beiden** Trunk-Seiten gleich; `allowed vlan`-Liste nicht vergessen. - OSPF-Nachbarschaft hängt im EXSTART → MTU/Hello-Mismatch prüfen, nicht nur Area-ID. - `ip routing` auf L3-Switch nicht vergessen (sonst SVIs ohne Routing). ## Grenzen - **Konfigurations-Aufgaben** sind autonom lösbar (Interface, Routing, VLAN, ACL, NAT, DHCP, STP, EtherChannel, OSPF). - **Laufzeit-Aktionen** (Ping zu Simulationszeitpunkt, PDU-Capture-Klicks, Activity-Wizard-Interaktion) sind nicht per `pt_apply_configs` injizierbar — offline nur coachen. **Opt-in Live-Verify:** bei laufendem PT + geladener cisco-pt-mcp-Bridge live prüfbar (`sendPdu`→`stepSimulation`→`getPduResults`) — siehe `references/live-verify-cisco-pt-mcp.md`. - **Kein OT/Industrie**: IE-3400, ISA-3000, PLC, Smart-Grid, DNP3, Modbus, CIP werden nicht unterstützt. ## Referenzen (lazy geladen) - `references/ios-vlan-stp-etherchannel.md` — VLAN, Trunk, Inter-VLAN-Routing, STP, EtherChannel - `references/ios-routing-ospf-static.md` — Statisches Routing, OSPFv2 Single-Area - `references/ios-services-dhcp-nat-acl.md` — DHCP, NAT/PAT, Standard-/erweiterte ACLs - `references/troubleshooting.md` — Troubleshooting-Flow mit `show`-Befehlen - `references/live-verify-cisco-pt-mcp.md` — opt-in Live-Verify einer laufenden PT-Instanz (cisco-pt-mcp) ## Wartung Dieser Skill ist SkillOpt-trainierbar (`eval/`-Harness, `OPTIMIZATION.md`-Runbook). Edits am Skill müssen das held-out Gate (`eval/run_epoch.py gate`) passieren — siehe `memory/edit_log.md` für akzeptierte/abgelehnte Edits.