diff --git a/docs/handoff-tp6-session.md b/docs/handoff-tp6-session.md new file mode 100644 index 0000000..ef02aee --- /dev/null +++ b/docs/handoff-tp6-session.md @@ -0,0 +1,119 @@ +# Übergabe: TP6-Session — die Prämisse messen, bevor gebaut wird + +> **Stand bei Übergabe: 2026-08-19, live verifiziert.** Diese Datei ist der Einstieg. Der eigentliche +> Arbeitsplan steht in **`docs/tp6-praemisse-messrunbook.md`** — hier steht, was du wissen musst, bevor +> du ihn aufschlägst, und was du mit dem Ergebnis machst. + +--- + +## 1. Dein Auftrag in zwei Sätzen + +TP6 (QoS/CAKE) wird seit Monaten als „DAS Ziel" des Projekts geführt. **Es ist der einzige verbliebene +Punkt auf dem kritischen Pfad — und seine Prämisse ist unbelegt.** Deine Aufgabe ist nicht, CAKE zu +bauen, sondern zu messen, ob dieses Netz überhaupt ein Bufferbloat-Problem hat. + +**Das Abbruchkriterium steht vor der Messung fest** (Runbook §3): Grade **A/A+** in beiden Richtungen +→ **TP6 wird geschlossen statt gebaut**, und der kritische Pfad ist leer. Grade **B oder schlechter** +→ CAKE ist die Antwort, dann mit einer Zahl als Begründung. + +Warum das nicht akademisch ist: `docs/call-quality-diagnosis.md` hat am **2026-06-16** bereits gemessen +— Upload 10,3 Mbit gesättigt, idle 12 ms, Vollast avg 17,5 / max 26 ms = **A/A+** — und kam zum Schluss +`CAKE / QoS | kein Bufferbloat-Spielraum | ❌ nicht deployt (wäre marginal)`. Seither wurde der Edge +komplett getauscht (FritzBox → `crs326-core` + Arris im Bridge-Mode), die Messung ist also nicht +ungültig, aber auch nicht mehr aussagekräftig. + +--- + +## 2. Was du vor der ersten Zahl prüfen musst + +🔴 **WARP muss aus sein.** Ein aktiver WARP-Client tunnelt alles durch Cloudflares QUIC-Proxy — du +misst dann den Tunnel statt der Leitung, und ICMP kommt gar nicht erst durch. Das ist in diesem Projekt +zweimal aufgeschlagen, zuletzt am 2026-08-18: `dig`-Tests vom MacBook liefen stumm ins Leere, dieselben +Abfragen aus VLAN20 antworteten sofort. Merkregel im Repo: `ref_warp_local_icmp_trap`. + +🔴 **Nicht dual-homed messen.** Das MacBook hält zeitweise Leases in VLAN10 **und** VLAN20 gleichzeitig +(`project_dual_homing_slowness_incident`). Dann ist unklar, über welches Interface die Flows laufen. + +🔴 **Kabelgebunden, VLAN10.** WLAN verseucht die Messung mit Funk-Jitter. + +📌 **Der Liwest-Tarif ist nirgends im Repo dokumentiert.** Die kolportierten „~10 Mbit Upload" stammen +aus der Diagnose-Session von 06-16. Wenn deine Sättigung deutlich mehr zeigt, ist das ein eigener Fund +— trag die Zahl nach, sie ist die Grundlage jeder späteren Prozent-Vorgabe für CAKE. + +--- + +## 3. Der verifizierte Ist-Stand (damit du nichts davon neu erhebst) + +Alles am 2026-08-19 live gegen die Geräte geprüft, nicht aus der Doku abgeschrieben: + +| | | +|---|---| +| Compliance | **92/92, 0 Drifts** bei 23 Rules | +| Firewall | **deny-by-default in beiden Ketten** (TP5 E1–E5 ✅) | +| `forward`-Drops heute | **0** — die 10.657 Logzeilen sind ausnahmslos `input`-Broadcast-Rauschen (MNDP/NetBIOS/SSDP) | +| WLAN | CAPsMAN auf dem Core, ap1/ap2 reine CAPs, beide `Ok` | +| Alle 4 MikroTik | RouterOS **und** RouterBOOT **7.24** | +| Zeit | alle vier `synchronized`, Core ist Zeitquelle, DHCP-Option 42 | +| DNS | DoH zum CF-Gateway mit `verify-doh-cert=yes` | +| Repo | sauber, `main` = `gitea/main` | + +**Für deine Messung besonders relevant:** + +- **Fasttrack ist auf dem Core faktisch tot** — die `accept est,rel,untracked`-Regel steht davor, also + wird die Fasttrack-Regel nie erreicht (39,6 Mio Pakete vs. **0**). Das ist **entschieden und Absicht** + (2026-08-19): bei ~10 Mbit kostet der Verzicht nichts, und für CAKE ist es die bequemere Ausgangslage + — Fasttrack umgeht Queues, CAKE braucht sie. **Du musst dafür nichts tun.** Gegenbedingung steht in + TP6: wer Inter-VLAN je auf Gigabit will, muss vorher messen, was die Core-CPU ohne Fasttrack trägt. +- **`/queue` fehlt im Golden-Config-Template** (Runbook §4.1). Falls gebaut wird, ist das der erste + Schritt — sonst ist die Queue nicht drift-überwacht, derselbe blinde Fleck, den TP26 für die Firewall + und `system-ntp` am 18. geschlossen haben. +- **Der Core ist ein Switch mit 800-MHz-ARM-CPU**, kein Router-Bolide. CPU-Last während der Sättigung + mitschreiben (Runbook §2.3) — geht sie schon bei 10 Mbit hoch, ist das ein eigener Befund. + +--- + +## 4. Spielregeln, die hier teuer erkauft wurden + +1. **Config-Änderungen ausschließlich über Nautobot Golden Config.** Kein Direkt-Write per MikroMCP, + auch nicht „nur kurz". Werkzeug: `nautobot/gc-manual-plan.py --device … --commands-file … --deploy`, + davor `/system backup`. +2. **Abnahme misst die Wirkung, nicht die Anzeige.** Drei Fehlbefunde in einer Nacht hatten dieselbe + Ursache: Registration-Table statt DHCP-Lease (kostete 14 h), Job-Status statt Gerätezustand, + ein 70-Sekunden-Zähler statt eines echten Messfensters. Memory: + `feedback_abnahme_wirkung_nicht_anzeige`. +3. **Job-Status ist kein Wirksamkeitsnachweis.** Ein Plan meldete „Completed", ohne etwas zu ändern + (`[find !dynamic]` ist auf `/interface wifi configuration` ein *Syntaxfehler*), ein anderer + „FAILURE", obwohl alles saß (`/certificate import` gibt `failed: 0` aus, der Job scannt stumpf nach + dem Wort). Nutze `--assert`. +4. **Bei Statuswechseln den Header mitziehen.** Der wiederkehrende Fehler dieses Projekts: neuer Inhalt + wird geschrieben, der alte Status bleibt stehen. Hat am 19. gleich sechs Abschnitte betroffen + (TP3, TP3.3, TP28, TP13, TP14.4, TP16.3) und eine frische Session in die Irre geführt. +5. **Eine Session zur Zeit an diesem Repo.** Zwei parallele Sessions haben genau den Drift erzeugt, + der dann als Problem gemeldet wurde. `git pull` vor dem ersten Edit. + +--- + +## 5. Was du mit dem Ergebnis machst + +**Fall A — es bleibt A/A+ (wahrscheinlicher):** +TP6 im `teilprojekte.md` auf ✅/geschlossen setzen, **mit den Messwerten als Begründung**, und den +kritischen Pfad entsprechend leeren. Dann ist das Projekt in seinem Kern fertig — die Frage, was das +neue Ziel wird, gehört Christoph, nicht der Session. Kandidaten liegen bereit: **TP24** (DC-USV), +**TP25**-Restmessung (Signal-Boden + Re-Walk), **TP16.3** und **TP14.4** (beide haben seit dem 19. ein +ausführbares Runbook), **TP23** Stufe 3–6, **TP18**. + +**Fall B — schlechter als A:** +Dann baust du CAKE — aber erst `/queue` ins Template (§4.1), dann die Queue, dann dieselbe Messung als +A/B-Nachweis. Und beachte den Altbefund: die Diagnose von 06-16 hat den Engpass bei **Gelis +Senderichtung** verortet, nicht im Heimnetz. Ein schlechter Wert hier wäre also eine *neue* Ursache. + +**In beiden Fällen:** Ergebnis in `docs/tp6-praemisse-messrunbook.md` §5 eintragen, `teilprojekte.md` +nachziehen — **Header inklusive** —, committen, pushen. + +--- + +## 6. Nicht dein Auftrag + +Finger weg, solange TP6 läuft: Fasttrack-Reihenfolge (entschieden), WLAN-Parameter (TP25 ist eine +eigene Messarbeit), CF-Writes (TP14.4/TP16.3 sind Papier und sollen es bleiben, bis jemand sie bewusst +startet). Und die Compliance steht auf 92/92 — das soll sie bleiben. diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 553f7be..deb9258 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -405,7 +405,9 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **(b) Live-Torch als Ad-hoc-Observability:** DNS ist bei direktem 1.1.1.1 blind, **Flows nicht** (NATen über ap1). `torch` auf `vlan30`/`vlan50` gefiltert auf die Geräte-IP zeigt Ziel-IPs live (Versuni → AWS `eu-west-1` IoT erkennbar). Voraussetzung: Gerät aktiv. Merkregel: Airfryer nur online wenn er kocht → Capture ans Einschalten koppeln. - **Abh.:** UNTRUSTED-Move des Airfryers (Kandidat, s. VLAN50) + TP5-Deny-by-default. Kein Blocker. -### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🟠 **PRÄMISSE PRÜFEN, BEVOR gebaut wird** (2026-08-18) +### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🟠 **PRÄMISSE PRÜFEN, BEVOR gebaut wird** +> 📋 **Eigene Session, Einstieg: `docs/handoff-tp6-session.md`** (Übergabe 2026-08-19), +> Arbeitsplan: `docs/tp6-praemisse-messrunbook.md`. Abbruchkriterium steht **vor** der Messung fest. - 🔴 **Der Widerspruch, der zuerst aufzulösen ist:** dieser TP wird seit Monaten als „DAS Ziel" geführt — aber `docs/call-quality-diagnosis.md` hat den Bufferbloat **bereits gemessen** und kommt zum gegenteiligen Schluss. Wörtlich in dessen Ergebnistabelle: diff --git a/docs/tp6-praemisse-messrunbook.md b/docs/tp6-praemisse-messrunbook.md index da27f12..c5a0ae3 100644 --- a/docs/tp6-praemisse-messrunbook.md +++ b/docs/tp6-praemisse-messrunbook.md @@ -54,7 +54,22 @@ Deshalb: **dieselbe Methode zuerst**, die bequemere danach. ### 2.1 Primärmessung — reproduziert 2026-06-16 -Von einem **kabelgebundenen** Client in VLAN10 (WLAN würde die Messung mit Funk-Jitter verseuchen): +Von einem **kabelgebundenen** Client in VLAN10 (WLAN würde die Messung mit Funk-Jitter verseuchen). + +> 🔴 **Zwei Client-Vorbedingungen, ohne die die Messung wertlos ist** (nachgetragen 2026-08-19): +> +> 1. **WARP MUSS AUS SEIN.** Ein aktiver WARP-Client schickt den Verkehr durch Cloudflares +> QUIC-Tunnel — gemessen würde dann der Tunnel, nicht die Liwest-Strecke, und ICMP geht +> gar nicht erst durch. Das ist in diesem Projekt schon zweimal aufgeschlagen +> (`ref_warp_local_icmp_trap`; zuletzt am 2026-08-18, als `dig`-Tests vom MacBook stumm +> ins Leere liefen, während dieselben Abfragen aus VLAN20 sofort antworteten). +> **Vor der ersten Zahl prüfen, nicht danach.** +> 2. **Nicht dual-homed messen.** Das MacBook hält zeitweise Leases in **VLAN10 und VLAN20** +> gleichzeitig (dokumentiert in `project_dual_homing_slowness_incident`). Dann ist unklar, +> über welches Interface die Flows laufen und welchen Weg die Pings nehmen. Vor der Messung +> sicherstellen, dass genau **ein** Interface aktiv ist — sonst misst man eine Mischung. + +Ablauf: 1. **Baseline idle** — 24 Pings gegen ein stabiles externes Ziel, Netz ansonsten ruhig. ```bash