Christoph Emsenhuber
78eef95f12
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>
195 lines
9.2 KiB
Markdown
195 lines
9.2 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).
|
||
|
||
> 🔴 **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
|
||
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.
|