120 lines
6.8 KiB
Markdown
120 lines
6.8 KiB
Markdown
# Ü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.
|