From b2d286d9c8bef15f1f9891c39a4d05f1d77e2e35 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Sun, 23 Aug 2026 04:50:56 +0200 Subject: [PATCH] TP6 beantwortet: CAKE ist baubar, wirkt -- und reicht nicht an die Ursache Korrigiert den Befund von heute Nacht. Der stand so nicht richtig da. WAS FALSCH WAR: "der CRS326 fuehrt keine Software-Queue". Die These stuetzte sich auf zwei eigene Testfehler und ist widerlegt. ipv4-fast-path-active=no und fasttrack-packets=0 belegen sogar, dass die CPU jedes Paket im Slow Path sieht -- die Hardware war nie die Grenze. WAS RICHTIG IST (MikroTik-Doku, woertlich): "Interface HTB will not work correctly when the out-interface is hardware offloaded and the bridge Fast Path is not active." Das war die Ursache der wirkungslosen Queue auf parent=vlan100. Ueber parent=global + mangle mark-packet funktioniert CAKE einwandfrei: 6.040.563 Bytes gezaehlt cake-bandwidth=7000000 -> Durchsatz faellt 9,3 auf 7,78 Mbit Sie zaehlt UND drosselt. Es scheitert nicht am Bau. Die zweite "Gegenprobe" von heute Nacht war ebenfalls untauglich: Simple Queue auf 10.40.0.0/16 laeuft im Postrouting NACH src-nat, wo die Quelle laengst die WAN-IP ist. Sie konnte nie matchen und bewies nichts. DER BEFUND, DER TP6 BEENDET -- A/B, gleicher Client, Minuten auseinander: ohne CAKE 42,4 ms CAKE 8,5 Mbit (88 %) 43,3 ms CAKE 7 Mbit (73 %) 44,0 ms CAKE 5 Mbit (52 %) 44,6 ms (idle 12,9 ms) Selbst bei halber Linerate keine Verbesserung -- und dort MUSS die Warteschlange im Router liegen. Die ~30 ms entstehen stromabwaerts im Arris/DOCSIS-Uplink, wo Request/Grant-Scheduling auf MAC-Layer sitzt und gar keine Queue ist. Das kann kein Shaper im Router beheben. Die max-Werte steigen mit haerterer Drosselung (53 -> 94 -> 148 ms): die eigene Queue waechst, die DOCSIS-Latenz bleibt. EMPFEHLUNG: TP6 schliessen. Nicht mangels Nutzen, sondern weil das Werkzeug nicht an die Ursache reicht -- ein staerkeres Ergebnis als das "marginal" von 2026-06-16. Weder hw-offload opfern noch Chip-QoS ist noetig; der Global-HTB-Weg braucht beides nicht. Es lohnt nur nicht. Am Geraet steht weiterhin die wirkungslose Interface-Queue (qos-wan-up), in der SoT und compliant, aber ohne Funktion -- markiert, gehoert beim Abschluss entfernt. Alle Testaenderungen liefen als Transaktion, alle zurueckgebaut, 100/100 compliant. Co-Authored-By: Claude Opus 5 --- docs/teilprojekte.md | 105 ++++++++++-------- .../TEST-cake-global-htb.ab-off.rsc | 1 + .../TEST-cake-global-htb.commands.rsc | 2 + docs/transaktionen/TEST-cake-global-htb.json | 16 +++ .../TEST-cake-global-htb.rollback.rsc | 11 ++ .../TEST-cake-global-htb.rueckbau.rsc | 3 + .../TEST-cake-global-htb.snapshot.rsc | 9 ++ .../TEST-cake-global-htb.tune.rsc | 2 + .../TEST-cake-global-htb.tune5.rsc | 1 + 9 files changed, 102 insertions(+), 48 deletions(-) create mode 100644 docs/transaktionen/TEST-cake-global-htb.ab-off.rsc create mode 100644 docs/transaktionen/TEST-cake-global-htb.commands.rsc create mode 100644 docs/transaktionen/TEST-cake-global-htb.json create mode 100644 docs/transaktionen/TEST-cake-global-htb.rollback.rsc create mode 100644 docs/transaktionen/TEST-cake-global-htb.rueckbau.rsc create mode 100644 docs/transaktionen/TEST-cake-global-htb.snapshot.rsc create mode 100644 docs/transaktionen/TEST-cake-global-htb.tune.rsc create mode 100644 docs/transaktionen/TEST-cake-global-htb.tune5.rsc diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index 0b4c4f5..ea7cbb6 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -421,51 +421,58 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **(b) Live-Torch als Ad-hoc-Observability:** DNS ist bei direktem 1.1.1.1 blind, **Flows nicht** (NATen über ap1). `torch` auf `vlan30`/`vlan50` gefiltert auf die Geräte-IP zeigt Ziel-IPs live (Versuni → AWS `eu-west-1` IoT erkennbar). Voraussetzung: Gerät aktiv. Merkregel: Airfryer nur online wenn er kocht → Capture ans Einschalten koppeln. - **Abh.:** UNTRUSTED-Move des Airfryers (Kandidat, s. VLAN50) + TP5-Deny-by-default. Kein Blocker. -### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🔴 **GEBAUT 2026-08-23 — UND NACHWEISLICH WIRKUNGSLOS. Der CRS326 fuehrt keine Software-Queue.** -> 🔴 **Der Befund, der TP6 neu stellt (2026-08-23):** CAKE ist gebaut, deployt und compliant -> (100/100) — **und es passiert nichts.** Drei unabhaengige Belege am Geraet: +### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🟢 **BEANTWORTET 2026-08-23: CAKE ist baubar, wirkt technisch — und hilft nicht. Der Puffer gehoert nicht uns.** +> 🔴 **A/B gemessen, gleicher Client, gleiche Methode, Minuten auseinander:** > -> | Beleg | erwartet | gemessen | -> |---|---|---| -> | `/queue tree` Zaehler nach 6 MB Client-Upload | > 0 Bytes | **0 Bytes** | -> | Simple Queue auf `10.40.0.0/16` (Gegenprobe) | > 0 Bytes | **0 Bytes** | -> | Upload-Durchsatz gegen `cake-bandwidth=8.5Mbps` | <= 8,5 Mbit | **9,48 Mbit** | +> | Konfiguration | avg Latenz unter Upload-Last | +> |---|---| +> | ohne CAKE | **42,4 ms** | +> | CAKE 8,5 Mbit (88 % der Linerate) | 43,3 ms | +> | CAKE 7 Mbit (73 %) | 44,0 ms | +> | **CAKE 5 Mbit (52 %)** | **44,6 ms** | > -> Der dritte ist der harte: die Queue **drosselt nicht**, sie zaehlt nicht, sie wirkt nicht. -> Das ist kein Zaehler-Anzeigeproblem, sondern die Sache selbst. +> idle 12,9 ms. **Selbst bei halber Linerate aendert sich nichts** — und dort muss die +> Warteschlange zwingend im Router liegen, der Modem-Puffer also leer bleiben. Die ~30 ms +> Zusatzlatenz entstehen damit **stromabwaerts**: im Arris/DOCSIS-Uplink, wo das +> Request/Grant-Scheduling auf MAC-Layer sitzt und gar keine Warteschlange ist. +> **Das kann keine Queue im Router beheben.** Nebenbefund: die max-Werte *steigen* mit +> haerterer Drosselung (53 → 94 → 148 ms) — die eigene Queue wird laenger, die DOCSIS-Latenz +> bleibt. ⚖️ **Empfehlung: TP6 schliessen — nicht mangels Nutzen, sondern weil das Werkzeug +> nicht an die Ursache reicht.** Das ist ein staerkeres Ergebnis als „marginal“ von 2026-06-16. > -> **Sehr wahrscheinliche Ursache (nicht abschliessend bewiesen):** `crs326-core` ist ein -> **CRS326 mit Marvell-98DX3236-Switch-Chip**. Die Bridge faehrt `hw-offload` (`H`-Flag auf -> ether16), **alle** Ports stehen auf `only-hardware-queue`, das Bridge-Interface auf -> `no-queue`. Ein Geraet, dessen Ports der Switch-Chip bedient, hat an dieser Stelle keine -> Software-Queue, in der ein Scheduler arbeiten koennte. Passend dazu: `l3-hw-offloading=no` -> und `qos-hw-offloading=no` — die CPU *routet* zwar (die Firewall zaehlt 32,9 Mio Pakete), -> aber die Serialisierung passiert im Chip. +> ✅ **Dass CAKE technisch funktioniert, ist dabei bewiesen, nicht angenommen:** Global-HTB +> zaehlte 6.040.563 Bytes, und bei `cake-bandwidth=7000000` fiel der Durchsatz von 9,3 auf +> **7,78 Mbit**. Sie zaehlt *und* drosselt. Es scheitert nicht am Bau. > -> 🔎 **Kontrollen, die ausgeschlossen sind:** kein WARP auf dem Testclient (Default-Route -> `10.40.20.1`, en0); der Verkehr lief ueber den Core; Fasttrack ist ohnehin tot (0 von 445). -> Zwei eigene Testfehler sind dokumentiert und korrigiert: ein `parent=global`-Tree **ohne** -> `packet-mark` faengt per Definition nichts, und `target=0.0.0.0/0` wird von RouterOS -> stillschweigend zu `target=""` verworfen — beide sahen wie Befunde aus und waren keine. +> 🔴 **KORREKTUR der ersten Fassung dieses Abschnitts (ebenfalls 2026-08-23):** dort stand +> „der CRS326 fuehrt keine Software-Queue“ — **das war falsch** und stuetzte sich auf zwei +> eigene Testfehler. Richtig ist praeziser: +> - **`/queue tree parent=` ist bei hw-offloadetem out-interface wirkungslos.** +> MikroTik dokumentiert das: *„Interface HTB will not work correctly when the out-interface +> is hardware offloaded and the bridge Fast Path is not active.“* Das war die echte Ursache +> der ersten, wirkungslosen Queue auf `parent=vlan100`. +> - **`/queue tree parent=global` + `packet-mark` wirkt sehr wohl** — die HTB Global sitzt im +> IP-Stack, nicht an der Interface-Queue. Rezept: `mangle chain=postrouting +> out-interface=vlan100 action=mark-packet` (postrouting laeuft **vor** src-nat, die +> LAN-Quelle ist dort noch sichtbar), dann Tree auf `parent=global`. +> - **Die Simple-Queue-„Gegenprobe“ auf `10.40.0.0/16` war untauglich:** die Reihenfolge ist +> mangle postrouting → **src-nat** → HTB Global → simple queues. Zum Zeitpunkt der Simple +> Queue ist die Quelle laengst die WAN-IP; das Target konnte nie matchen. +> - `ipv4-fast-path-active: no` und `ipv4-fasttrack-packets: 0` belegen zudem: die CPU sieht +> jedes Paket im Slow Path. Die Hardware war nie die Grenze. +> Details und die restlichen Sackgassen: Memory `ref_queue_htb_platzierung_docsis`. > -> ⚖️ **Damit ist die offene Frage nicht mehr „lohnt CAKE“, sondern „geht CAKE auf dieser -> Hardware ueberhaupt“.** Drei Wege, keiner geschenkt: -> 1. **`hw-offload` auf dem WAN-Pfad abschalten** — dann sieht die CPU den Verkehr und die -> Queue greift. Preis: der Switch-Chip faellt fuer diesen Pfad aus, die 800-MHz-CPU traegt -> ihn allein. Bei 9,6 Mbit WAN plausibel, **aber die Inter-VLAN-Messung dazu steht bis -> heute aus** (dieselbe offene Messung wie in §4.2 zu Fasttrack). -> 2. **QoS auf den Switch-Chip legen** (`qos-hw-offloading`) — kann Priorisierung, **kein -> CAKE**. Waere ein anderes, aermeres Werkzeug. -> 3. **TP6 schliessen** — mit dem staerksten Argument, das es je hatte: nicht nur „messbar, -> nicht hoerbar“, sondern „auf dieser Hardware nicht ohne Gegenleistung baubar“. +> ✅ **Was aus beiden Anlaeufen bleibt:** die **ComplianceRule `queue`** (Feature + Rule, +> `match_config` = `/queue type` + `/queue tree`) schliesst die blinde Stelle aus §4.1 — +> dieselbe, die TP26 fuer `/ip firewall filter` geschlossen hat. Wirksamkeit bewiesen: erst +> 99/100 mit der fehlenden Queue als `missing`, nach dem Deploy 100/100. Zaehler jetzt +> **25 Rules x 4 Geraeten = 100 Checks**. +> ⚠️ **Am Geraet steht weiterhin die wirkungslose Interface-Queue** (`qos-wan-up` auf +> `parent=vlan100`) — in der SoT, compliant, **aber ohne jede Funktion**. Sie gehoert entfernt, +> sobald der Abschluss entschieden ist; bis dahin NICHT fuer aktives QoS halten. > -> ✅ **Was aus diesem Anlauf bleibt und Bestand hat:** die **ComplianceRule `queue`** -> (Feature + Rule, `match_config` = `/queue type` + `/queue tree`) schliesst die blinde -> Stelle aus §4.1 — dieselbe, die TP26 fuer `/ip firewall filter` geschlossen hat. Sie hat -> sich sofort bewiesen: erst 99/100 mit exakt der fehlenden Queue als `missing`, nach dem -> Deploy 100/100. Der Zaehler steht jetzt bei **25 Rules x 4 Geraeten = 100 Checks**. -> Die Queue selbst steht am Geraet und in der SoT — **wirkungslos, aber dokumentiert**, bis -> ueber die drei Wege oben entschieden ist. Sie NICHT fuer aktives QoS halten. +> 💡 **Falls QoS hier je wieder Thema wird:** weder `hw-offload` opfern noch Chip-QoS ist +> noetig — der Global-HTB-Weg funktioniert ohne beides. Es lohnt nur nicht. *(Vorheriger Kopf, als Messbefund weiter gueltig:)* 🟡 **GEMESSEN 2026-08-20/21 — Fall B, aber „messbar, nicht hörbar"** > ✅ **Die Prämisse ist geprüft. Ergebnis + Rohdaten: [`tp6-praemisse-messrunbook.md`](tp6-praemisse-messrunbook.md) §5.** @@ -2008,14 +2015,16 @@ TP5 E1 ✅ ─► E2 ✅ ─► E2-Nachtrag ✅ ─► E3 Drop ✅ ─► E4 inp > nächste Sitzung entscheidet daher **bauen oder begründet schließen** — sie misst nicht neu. > Übergabe mit den Sitzungszuschnitten: [`handoff-20260822-naechste-schritte.md`](handoff-20260822-naechste-schritte.md). -> 🔴 **Update 2026-08-23: die Entscheidung ist gefallen — gebaut — und der Bau hat die -> Frage veraendert.** CAKE steht auf `crs326-core` (ComplianceRule `queue` + Template-Block, -> 100/100 compliant) und ist **nachweislich wirkungslos**: 0 Bytes in der Queue nach 6 MB -> Client-Upload, und 9,48 Mbit Durchsatz gegen ein 8,5-Mbit-Limit. Ursache sehr wahrscheinlich -> die **Switch-Chip-Architektur** des CRS326 (Bridge-`hw-offload`, alle Ports -> `only-hardware-queue`). **TP6 steht damit weiter auf dem Pfad**, aber die offene Frage ist -> jetzt eine Hardware-Abwaegung (`hw-offload` opfern? Chip-QoS? schliessen?) und keine -> Nutzenfrage mehr. Details und die drei Wege: TP6-Abschnitt oben. +> 🟢 **Update 2026-08-23 (Endstand): TP6 ist beantwortet — und der kritische Pfad damit leer.** +> Gebaut wurde, wie entschieden. Der erste Anlauf (`/queue tree parent=vlan100`) war wirkungslos, +> **aber nicht aus dem zuerst notierten Grund**: nicht der Switch-Chip, sondern die +> MikroTik-dokumentierte Regel, dass Interface-HTB bei hw-offloadetem out-interface nicht greift. +> Ueber `parent=global` + Mangle-Mark **funktioniert CAKE einwandfrei** (zaehlt 6 MB, drosselt +> 9,3 → 7,78 Mbit). Und genau deshalb ist das Ergebnis belastbar: **die Latenz unter Last bessert +> sich trotzdem nicht — bei keiner Bandbreite, auch nicht bei 52 % der Linerate** (42,4 / 43,3 / +> 44,0 / 44,6 ms). Der Puffer sitzt im **DOCSIS-Uplink**, nicht im Router. ⇒ **TP6 schliessen: +> nicht mangels Nutzen, sondern weil das Werkzeug nicht an die Ursache reicht.** Details im +> TP6-Abschnitt oben, Merkregeln in `ref_queue_htb_platzierung_docsis`. **TP5 ist am 2026-08-18 abgeschlossen.** Damit steht rechnerisch nur noch **TP6** auf dem kritischen Pfad — 🟠 **aber dessen Prämisse ist offen**: eine Messung von 2026-06-16 (`docs/call-quality-diagnosis.md`) @@ -2032,7 +2041,7 @@ Ziel ist. Alles andere läuft nebenher und blockiert nichts. Anlernen eines IoT-Geraets (User 2026-08-17). Wer im IOT-SSID sitzt, ist im selben VLAN wie das Geraet und beruehrt die `forward`-Kette gar nicht; fuer Ad-hoc-Zugriffe aus MAIN gibt es jetzt die selbstverfallende Gruppe `jit-admin`. -2. 🔴 **TP6 — QoS/CAKE + Call-Quality-A/B-Test.** **Stand 2026-08-23: gebaut, aber wirkungslos** (s. TP6-Abschnitt — Switch-Chip-Befund). Der naechste Schritt ist weder Messen noch Bauen, sondern die Entscheidung ueber `hw-offload`. ~~Das eigentliche Projektziel; **keine offenen Blocker mehr**.~~ +2. 🟢 **TP6 — QoS/CAKE + Call-Quality-A/B-Test.** **Stand 2026-08-23: beantwortet** (s. TP6-Abschnitt). CAKE ist baubar und wirkt technisch, verbessert die Latenz aber bei keiner Bandbreite — der Puffer liegt im DOCSIS-Uplink. Offen ist nur noch der formale Abschluss (Queue entfernen, TP schliessen). ~~Das eigentliche Projektziel; **keine offenen Blocker mehr**.~~ **Korrigiert 2026-08-19:** kein *Blocker*, aber eine offene **Prämisse** — der Satz oben und dieser Punkt widersprachen sich seit dem 18. Richtig ist: der nächste Schritt ist eine **Messung**, kein Bau. Runbook liegt bereit: `docs/tp6-praemisse-messrunbook.md`. Fällt sie A/A+ aus, wird TP6 **geschlossen diff --git a/docs/transaktionen/TEST-cake-global-htb.ab-off.rsc b/docs/transaktionen/TEST-cake-global-htb.ab-off.rsc new file mode 100644 index 0000000..929bcae --- /dev/null +++ b/docs/transaktionen/TEST-cake-global-htb.ab-off.rsc @@ -0,0 +1 @@ +/ip firewall mangle disable [find where comment="TEST-cake-global-htb"] diff --git a/docs/transaktionen/TEST-cake-global-htb.commands.rsc b/docs/transaktionen/TEST-cake-global-htb.commands.rsc new file mode 100644 index 0000000..577e7e7 --- /dev/null +++ b/docs/transaktionen/TEST-cake-global-htb.commands.rsc @@ -0,0 +1,2 @@ +/ip firewall mangle add action=mark-packet chain=postrouting comment="TEST-cake-global-htb" new-packet-mark=wanup out-interface=vlan100 passthrough=no +/queue tree add comment="TEST-cake-global-htb" name=qostestglobal packet-mark=wanup parent=global queue=cake-wan-up diff --git a/docs/transaktionen/TEST-cake-global-htb.json b/docs/transaktionen/TEST-cake-global-htb.json new file mode 100644 index 0000000..65048e2 --- /dev/null +++ b/docs/transaktionen/TEST-cake-global-htb.json @@ -0,0 +1,16 @@ +{ + "change_id": "TEST-cake-global-htb", + "device": "crs326-core", + "scope": "queue", + "match_config": [ + "/queue type", + "/queue tree" + ], + "reason": "TP6: prueft Global-HTB + Mangle-Mark statt Interface-HTB (letztere ist laut MikroTik-Doku bei hw-offloaded out-interface unwirksam). Enthaelt eine temporaere mangle-Regel ausserhalb des queue-Scopes, wird im Rueckbau mitentfernt.", + "started": "2026-08-23", + "expires": "2026-08-24", + "state": "rolledback", + "snapshot": "docs/transaktionen/TEST-cake-global-htb.snapshot.rsc", + "device_backup": "", + "closed": "2026-08-23" +} diff --git a/docs/transaktionen/TEST-cake-global-htb.rollback.rsc b/docs/transaktionen/TEST-cake-global-htb.rollback.rsc new file mode 100644 index 0000000..0d5ce99 --- /dev/null +++ b/docs/transaktionen/TEST-cake-global-htb.rollback.rsc @@ -0,0 +1,11 @@ +# Rueckbau-VORSCHLAG fuer TEST-cake-global-htb (crs326-core, Scope queue) +# Aus dem Snapshot vom 2026-08-23. NICHT ungeprueft deployen: +# `add`-Zeilen legen neu an, statt zu aendern — was hier gebraucht wird, +# ist in der Regel ein `set [find ...]`. Zeilen entsprechend anpassen. + +/queue type +add cake-bandwidth=8.5Mbps cake-diffserv=diffserv4 cake-nat=yes kind=cake \ +name=cake-wan-up +/queue tree +add comment="TP6: CAKE auf der Senderichtung (WAN-Egress)" name=qos-wan-up \ +parent=vlan100 queue=cake-wan-up diff --git a/docs/transaktionen/TEST-cake-global-htb.rueckbau.rsc b/docs/transaktionen/TEST-cake-global-htb.rueckbau.rsc new file mode 100644 index 0000000..e5c3202 --- /dev/null +++ b/docs/transaktionen/TEST-cake-global-htb.rueckbau.rsc @@ -0,0 +1,3 @@ +/queue tree remove [find where name="qostestglobal"] +/ip firewall mangle remove [find where comment="TEST-cake-global-htb"] +/queue type set [find where name="cake-wan-up"] cake-bandwidth=8.5Mbps diff --git a/docs/transaktionen/TEST-cake-global-htb.snapshot.rsc b/docs/transaktionen/TEST-cake-global-htb.snapshot.rsc new file mode 100644 index 0000000..75a6e1e --- /dev/null +++ b/docs/transaktionen/TEST-cake-global-htb.snapshot.rsc @@ -0,0 +1,9 @@ +# Snapshot des Scopes 'queue' auf crs326-core, 2026-08-23 (Transaktion TEST-cake-global-htb) +# Bewusst NUR dieser Abschnitt — der Vollexport gehoert nicht ins Repo. + +/queue type +add cake-bandwidth=8.5Mbps cake-diffserv=diffserv4 cake-nat=yes kind=cake \ +name=cake-wan-up +/queue tree +add comment="TP6: CAKE auf der Senderichtung (WAN-Egress)" name=qos-wan-up \ +parent=vlan100 queue=cake-wan-up diff --git a/docs/transaktionen/TEST-cake-global-htb.tune.rsc b/docs/transaktionen/TEST-cake-global-htb.tune.rsc new file mode 100644 index 0000000..da41b6c --- /dev/null +++ b/docs/transaktionen/TEST-cake-global-htb.tune.rsc @@ -0,0 +1,2 @@ +/ip firewall mangle enable [find where comment="TEST-cake-global-htb"] +/queue type set [find where name="cake-wan-up"] cake-bandwidth=7000000 diff --git a/docs/transaktionen/TEST-cake-global-htb.tune5.rsc b/docs/transaktionen/TEST-cake-global-htb.tune5.rsc new file mode 100644 index 0000000..a146458 --- /dev/null +++ b/docs/transaktionen/TEST-cake-global-htb.tune5.rsc @@ -0,0 +1 @@ +/queue type set [find where name="cake-wan-up"] cake-bandwidth=5000000