# 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.