Uebergabe fuer die TP6-Session + zwei fehlende Vorbedingungen im Messrunbook
Das Messrunbook verlangte einen kabelgebundenen VLAN10-Client, warnte aber nicht vor WARP. Ein aktiver WARP-Client tunnelt alles durch Cloudflares QUIC-Proxy -- gemessen waere der Tunnel statt der Leitung, und ICMP kaeme gar nicht erst durch. Genau das ist hier schon zweimal passiert. Dazu die Dual-Homing-Falle: das MacBook haelt zeitweise Leases in VLAN10 und VLAN20. Beides steht jetzt als Vorbedingung vor Schritt 1, nicht als Fussnote. Die Uebergabe traegt den live verifizierten Ist-Stand (92/92, 0 forward-Drops heute), die fuer die Messung relevanten Randbedingungen -- Fasttrack ist entschieden, /queue fehlt im Template, der Core ist ein 800-MHz-ARM -- und was mit beiden moeglichen Ergebnissen zu tun ist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
119
docs/handoff-tp6-session.md
Normal file
119
docs/handoff-tp6-session.md
Normal file
@@ -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.
|
||||
@@ -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:
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user