Christoph Emsenhuber
8b7ca8ddef
Der kritische Pfad widersprach sich selbst: der Einleitungsabsatz sagte seit dem 18. "Praemisse offen, erst messen", Punkt 2 der Liste darunter sagte weiter "keine offenen Blocker mehr". Punkt 2 nachgezogen. Neu: docs/tp6-praemisse-messrunbook.md. Reproduziert die Methode von 2026-06-16 (3 Flows Saettigung + 24 Pings idle/Last), damit die Zahlen vergleichbar sind, und misst erstmals die Download-Richtung -- die wurde damals nie gemessen und ist beim asymmetrischen Kabelanschluss die wahrscheinlichere Problemseite. Das Abbruchkriterium steht VOR der Messung: A/A+ heisst TP6 wird geschlossen statt gebaut. Fasttrack (die Entscheidung, die der Handoff Christoph vorbehalten hat): bleibt wie er ist, gilt ab jetzt aber als Absicht statt als Unfall. Bei ~10 Mbit WAN kostet der Verzicht nichts, fuer CAKE ist er sogar die bequemere Ausgangslage. Gegenbedingung notiert: wer Inter-VLAN je auf Gigabit will, muss vorher messen, was die Core-CPU ohne Fasttrack traegt. Damit sind zwei offene Stellen zu -- das "Entscheidung noetig" in TP6 und die TP21-Warnung, dass das Re-Baseline den Zustand zum Soll erklaert hat. Die Merkregel dort bleibt: dass es diesmal gut ausging, war Glueck. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
180 lines
8.3 KiB
Markdown
180 lines
8.3 KiB
Markdown
# TP6 — Prämissen-Messung: hat dieses Netz überhaupt ein Bufferbloat-Problem?
|
||
|
||
> **Stand 2026-08-19 · vorbereitet, nicht ausgeführt.** Dieses Runbook ändert **nichts** am Netz.
|
||
> Es misst, und es sagt vorher, was das Ergebnis bedeutet.
|
||
>
|
||
> **Der Deliverable dieses Runbooks ist eine Entscheidung, keine Queue.**
|
||
|
||
---
|
||
|
||
## 1. Warum gemessen wird, bevor gebaut wird
|
||
|
||
TP6 wird seit Monaten als „DAS Ziel" des Projekts geführt. Gleichzeitig liegt seit dem 2026-06-16 eine
|
||
Messung im Repo, die zum gegenteiligen Schluss kommt — [`call-quality-diagnosis.md`](call-quality-diagnosis.md)
|
||
sagt im Kopf, TP6 habe sich als **Nicht-QoS-Problem** entpuppt, und in der Ergebnistabelle wörtlich:
|
||
|
||
```
|
||
CAKE / QoS | kein Bufferbloat-Spielraum | ❌ nicht deployt (wäre marginal)
|
||
```
|
||
|
||
**Die Zahlen von damals:**
|
||
|
||
| Größe | Wert |
|
||
|---|---|
|
||
| Upload gesättigt (3 Flows) | **10,3 Mbit** sustained |
|
||
| Latenz idle | **12 ms** |
|
||
| Latenz unter Vollast | avg **17,5 ms** / max **26 ms** (24 Pings) |
|
||
| Bufferbloat-Grade | **A / A+** |
|
||
|
||
Bei einem Latenzanstieg von 12 → 17,5 ms unter Sättigung holt CAKE nichts mehr. Das ist der Grund,
|
||
warum dieses Runbook existiert: **es wäre falsch, eine Queue zu bauen, ohne diesen Befund zu widerlegen.**
|
||
|
||
### Was den Befund relativiert
|
||
|
||
Die Messung stammt aus der **FritzBox-Ära**. Seither ist der Edge komplett getauscht:
|
||
|
||
| damals (2026-06-16) | heute |
|
||
|---|---|
|
||
| FritzBox 6660 macht NAT + Queuing | **`crs326-core`** macht NAT + Queuing (ARM 2×800 MHz) |
|
||
| FB am Liwest-Anschluss | **Arris im Bridge-Mode**, Public-IP direkt auf `vlan100` |
|
||
| Double-NAT | kein Double-NAT |
|
||
| 2× Cudy als AP | 2× hAP ax² als CAPs unter CAPsMAN |
|
||
|
||
**Die Leitung ist dieselbe. Das Pufferverhalten des neuen Edge ist ungemessen.** Genau diese Lücke
|
||
schließt die Messung.
|
||
|
||
---
|
||
|
||
## 2. Methodengleichheit ist die halbe Messung
|
||
|
||
⚠️ **Wer anders misst als 2026-06-16, kann die beiden Zahlen nicht vergleichen** — und ohne Vergleich
|
||
ist die Messung wertlos, weil die Kernfrage lautet „hat sich seit dem Edge-Tausch etwas verschlechtert?".
|
||
|
||
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):
|
||
|
||
1. **Baseline idle** — 24 Pings gegen ein stabiles externes Ziel, Netz ansonsten ruhig.
|
||
```bash
|
||
ping -c 24 1.1.1.1
|
||
```
|
||
Notieren: min / avg / max.
|
||
|
||
2. **Sättigung aufbauen** — 3 parallele Upload-Flows, bis die Rate steht (das war 2026-06-16 der
|
||
Aufbau: 3 Flows × ~430 KB/s = 1,28 MB/s = 10,3 Mbit). Sättigung heißt: die Summenrate ist über
|
||
≥30 s stabil, nicht der Peak der ersten Sekunden.
|
||
|
||
3. **Ping unter Last** — dieselbe Ping-Reihe **während** die Flows laufen.
|
||
```bash
|
||
ping -c 24 1.1.1.1
|
||
```
|
||
|
||
4. **Dasselbe für Download.** 🔴 **Die Download-Seite wurde 2026-06-16 nie gemessen** — das ist die
|
||
größte Lücke im Altbefund. Kabelanschlüsse sind asymmetrisch, und der Down-Puffer sitzt beim ISP,
|
||
wo ein Router ihn nur per Ingress-Shaping erreicht. Wenn dieses Netz irgendwo Bufferbloat hat,
|
||
dann am wahrscheinlichsten hier.
|
||
|
||
### 2.2 Sekundärmessung — waveform als unabhängige Zahl
|
||
|
||
`https://www.waveform.com/tools/bufferbloat` vom selben Client. Liefert den Buchstaben-Grade und
|
||
trennt Up/Down sauber. **Dient der Gegenprobe, nicht als alleinige Grundlage** — die Ping-Reihe aus
|
||
2.1 ist die vergleichbare Zahl.
|
||
|
||
### 2.3 Was am Core mitläuft (read-only, parallel)
|
||
|
||
Während der Sättigung, damit die Zahl nicht ohne Kontext dasteht:
|
||
|
||
- **CPU-Last:** `/system resource print` — der Core ist ein **Switch mit 800-MHz-ARM-CPU**, kein
|
||
Router-Boliden. Geht die CPU unter 10 Mbit schon hoch, ist das ein eigener Befund.
|
||
- **Interface-Rate:** `/interface monitor-traffic vlan100` — bestätigt, dass die Sättigung wirklich
|
||
am WAN ankommt und nicht vorher im LAN hängt.
|
||
- **Tatsächliche Linerate:** aus der gemessenen Sättigung ableiten. ⚠️ Die im Projekt kolportierten
|
||
„~10 Mbit Upload" stammen aus der Diagnose-Session; **der aktuelle Liwest-Tarif ist nirgends im Repo
|
||
dokumentiert.** Wenn die Messung deutlich mehr zeigt, gehört die Zahl nachgetragen — sie ist die
|
||
Grundlage jeder späteren Prozent-Vorgabe.
|
||
|
||
---
|
||
|
||
## 3. Das Abbruchkriterium — steht VOR der Messung fest
|
||
|
||
> Dieser Abschnitt ist der eigentliche Zweck des Runbooks. Eine Schwelle, die erst nach dem Ergebnis
|
||
> festgelegt wird, ist keine Schwelle.
|
||
|
||
| Ergebnis unter Last | Entscheidung |
|
||
|---|---|
|
||
| **Grade A oder A+** (Latenzanstieg ≲ 30 ms über idle, beide Richtungen) | **TP6 wird geschlossen, nicht gebaut.** |
|
||
| **Grade B oder schlechter** in mindestens einer Richtung | **CAKE ist die Antwort** — dann mit einer Zahl als Begründung. |
|
||
|
||
### Fall A — es bleibt A/A+
|
||
|
||
Das ist der wahrscheinliche Ausgang, und er ist **kein Misserfolg**:
|
||
|
||
1. TP6 bekommt einen datierten Eintrag „✅ geschlossen — gemessen statt gebaut", mit beiden Messreihen
|
||
(2026-06-16 und heute) nebeneinander.
|
||
2. Der **kritische Pfad wird leer.** Das Projekt ist in seinem Kern fertig — deny-by-default steht,
|
||
Golden Config steht, WLAN steht, VLAN1 ist weg.
|
||
3. **Christoph entscheidet, was das neue Ziel ist.** Kandidaten aus der bestehenden Liste: TP24 (USV),
|
||
TP11 (Monitoring), TP16.2 (Härtung), TP12 (IPv6).
|
||
4. `call-quality-diagnosis.md` bekommt eine Bestätigungszeile — der Befund von damals hat gehalten.
|
||
|
||
### Fall B — es ist schlechter geworden
|
||
|
||
Dann ist **die Ursache neu**, denn 2026-06-16 war es gut. Vor jeder Queue erst die Ursache eingrenzen:
|
||
|
||
- Neuer Edge (Arris-Puffer) · CPU-Deckel am Core · gestiegene Grundlast (7 VLANs statt flach)
|
||
- Erst danach CAKE — und dann als Antwort auf eine benannte Ursache, nicht als Ritual.
|
||
|
||
---
|
||
|
||
## 4. Kontext für den Bau-Fall (damit er später nicht neu recherchiert wird)
|
||
|
||
Beides ist am 2026-08-18/19 live erhoben und muss nicht erneut ermittelt werden.
|
||
|
||
### 4.1 `/queue` fehlt im Golden-Config-Template
|
||
|
||
[`nautobot/mikrotik_routeros.j2`](../nautobot/mikrotik_routeros.j2) hat **keinen `/queue`-Block**, und es
|
||
gibt keine ComplianceRule dafür. Eine von Hand gesetzte CAKE-Queue wäre damit:
|
||
|
||
- **unsichtbar für die Compliance** (sie meldet weiter „compliant", während die Queue driftet), und
|
||
- **beim nächsten Deploy nicht geschützt.**
|
||
|
||
→ CAKE braucht **Template-Block + ComplianceRule**, nicht nur die Queue. Das ist exakt dieselbe Lücke,
|
||
die **TP26** für `/ip firewall filter` geschlossen hat — dort war der blinde Fleck 25 Firewallregeln groß.
|
||
|
||
### 4.2 Fasttrack ist auf dem Core faktisch tot — Entscheid: **so lassen**
|
||
|
||
Live gezählt (2026-08-18/19):
|
||
|
||
```
|
||
2 accept | defconf: accept est,rel,untracked | 32.979.171 Pakete
|
||
3 fasttrack-connection | defconf: fasttrack | 0 Pakete
|
||
0 von 445 Verbindungen fasttracked
|
||
```
|
||
|
||
Die `accept`-Regel steht **vor** der Fasttrack-Regel, also wird Fasttrack nie erreicht.
|
||
**Herkunft:** `ap1` hatte die Reihenfolge vor dem Cutover richtig (Fasttrack zuerst, MikroTik-defconf);
|
||
umgedreht wurde sie beim handgebauten Core-Aufbau in TP21.1.
|
||
|
||
**Entscheidung (Christoph, 2026-08-19): der Zustand bleibt — und zwar als Absicht, nicht als Unfall.**
|
||
|
||
- **Für CAKE ist er günstig.** Fasttrack umgeht die Queues; CAKE braucht sie. Der Konflikt, den man
|
||
sonst erst auflösen müsste, existiert hier gar nicht.
|
||
- **Bei ~10 Mbit WAN kostet er nichts.** Die Core-CPU trägt den Forward-Pfad ohnehin schon —
|
||
32,9 Mio Pakete sind der Beweis, nicht die Vermutung.
|
||
- ⚠️ **Gegenbedingung, unter der neu bewertet wird:** wenn **Inter-VLAN** je auf Gigabit soll
|
||
(NAS ↔ MAIN läuft geroutet über dieselbe CPU), ist der Verzicht auf Fasttrack teuer. **Diese Messung
|
||
steht aus** und ist die Vorbedingung jeder Neubewertung — nicht die WAN-Zahl aus diesem Runbook.
|
||
|
||
---
|
||
|
||
## 5. Abnahme dieses Runbooks
|
||
|
||
1. Beide Messreihen (Up **und** Down, idle **und** Last) liegen als Zahlen vor, nicht als Eindruck.
|
||
2. Die Entscheidung ist gegen die Tabelle aus §3 gefallen — **nicht** gegen ein Bauchgefühl.
|
||
3. Das Ergebnis steht datiert in TP6, und der kritische Pfad ist entsprechend nachgezogen.
|
||
4. Die tatsächliche Linerate ist dokumentiert (sie fehlte bisher im ganzen Repo).
|
||
5. **Kein Netz-Eingriff** im Fall A. Im Fall B entsteht ein *zweites* Runbook, das gebaut wird —
|
||
dieses hier bleibt die Begründung dafür.
|