bf-infra/docs/tp6-praemisse-messrunbook.md

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

   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.

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