TP6: CAKE gebaut -- und der Bau beweist, dass der CRS326 keine Queue fuehrt

Entscheidung dieser Sitzung war "bauen statt schliessen". Gebaut ist es. Das
Ergebnis stellt TP6 aber neu: die Queue steht, ist compliant, und tut nichts.

DREI BELEGE AM GERAET, unabhaengig voneinander:
  /queue tree nach 6 MB echtem Client-Upload   ->      0 Bytes
  Simple Queue auf 10.40.0.0/16 (Gegenprobe)   ->      0 Bytes
  Upload gegen cake-bandwidth=8.5Mbps          -> 9,48 Mbit

Der dritte ist der harte. Ein Zaehler auf 0 laesst sich als Anzeigeproblem
wegerklaeren, ein Durchsatz UEBER dem gesetzten Limit nicht.

URSACHE (sehr wahrscheinlich, nicht abschliessend bewiesen): CRS326 mit
Marvell-98DX3236. Bridge faehrt hw-offload, alle Ports only-hardware-queue,
Bridge-Interface no-queue. Der Switch-Chip serialisiert, nicht die CPU. Dass
l3-hw-offloading=no ist, widerspricht dem nicht: die CPU routet (Firewall zaehlt
32,9 Mio Pakete), aber sie serialisiert nicht.

WAS BESTAND HAT -- die ComplianceRule `queue`:
  - nautobot/ingest-queue-rule.py (idempotent, Dry-Run default)
  - match_config = "/queue type\n/queue tree"; /queue interface bewusst NICHT,
    das traegt nur die Default-Portzuordnung und hat mit QoS nichts zu tun
  - Wirksamkeit bewiesen, nicht behauptet: erst 99/100 mit exakt der fehlenden
    Queue als `missing`, nach dem Deploy 100/100, 0 Drifts
  - Zaehler jetzt 25 Rules x 4 Geraete = 100 Checks
Damit ist dieselbe blinde Stelle zu, die TP26 fuer /ip firewall filter geschlossen
hat -- und zwar VOR der Queue, wie Runbook 4.1 es verlangt.

ZWEI DESIGN-ENTSCHEIDUNGEN, die im Template begruendet stehen:
  - nur die Senderichtung: der Download liegt mit +23..28 ms UNTER der
    3-Schwelle und ist nach demselben Kriterium Fall A
  - parent=vlan100 statt target=10.40.0.0/16: eine Simple Queue aufs LAN-Supernetz
    haette Inter-VLAN (NAS <-> MAIN, geroutet ueber dieselbe CPU) mitgedrosselt

VIER SACKGASSEN, dokumentiert in ref_crs326_keine_software_queue:
  1. active-queue=queue-tree heisst nur "verdrahtet", nicht "wirksam"
  2. parent=global OHNE packet-mark faengt per Definition nichts
  3. target=0.0.0.0/0 wird stillschweigend zu target="" verworfen
  4. router-eigener Verkehr durchlaeuft die Queues nicht -- Test-Pings vom Router
     beweisen nichts, es braucht einen echten LAN-Client
Zwei davon sahen wie Hardware-Befunde aus und waren eigene Testfehler.

FORMATFALLE: RouterOS exportiert 8.5Mbps statt 8500000 und schiebt eine eigene
Hinweiszeile vor die Tree-Zeile, wodurch der Backup-Normalisierer /queue tree
nicht abflacht. Template baut beides nach -> 100/100.

Alle Testaenderungen liefen als Config-Transaktion und sind zurueckgebaut; keine
Akte offen. Die wirkungslose Queue bleibt vorerst am Geraet und in der SoT --
dokumentiert, nicht als aktives QoS misszuverstehen -- bis ueber die drei Wege
entschieden ist (hw-offload opfern / Chip-QoS ohne CAKE / TP6 schliessen).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/teilprojekte.md

@@ -52,8 +52,8 @@ ab jetzt bei jeder Änderung mitgezogen, nicht nur die TP-Abschnitte.)*
   08-18) — TP19 ist geschlossen; `cudy1` hängt stromlos an core `ether11`, physischer Ausbau ist hands-on.
 - **Kontrolle / Governance:** MikroMCP für Reads/Debug (alle 4 Geräte in der Registry),
   **Config-Änderungen ausschließlich über Nautobot Golden Config** (TP21/TP22 — Deploy-Pipeline scharf,
-  **96/96 Compliance-Checks grün, 0 Drifts** bei **24 Rules × 4 Geräten**, Stand 2026-08-23 —
-  neu dazu: **`wifi-access-list`**, s. TP22-Nachtrag).
+  **100/100 Compliance-Checks grün, 0 Drifts** bei **25 Rules × 4 Geräten**, Stand 2026-08-23 —
+  neu dazu: **`wifi-access-list`** (08-22) und **`queue`** (08-23, TP6), s. TP22-Nachtrag).
 
 <details><summary>📜 Historische Fassung (Stand bis 2026-08-08, Topologie <b>vor</b> dem Core-Cutover — bewusst erhalten, nicht als Ist lesen)</summary>
 
@@ -421,7 +421,53 @@ 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 ▸ 🟡 **GEMESSEN 2026-08-20/21 — Fall B, aber „messbar, nicht hörbar"**
+### 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:
+>
+> | 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** |
+>
+> Der dritte ist der harte: die Queue **drosselt nicht**, sie zaehlt nicht, sie wirkt nicht.
+> Das ist kein Zaehler-Anzeigeproblem, sondern die Sache selbst.
+>
+> **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.
+>
+> 🔎 **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.
+>
+> ⚖️ **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 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.
+
+*(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.**
 >
 > | | idle / C0 | Upload-Last | Download-Last |
@@ -1962,6 +2008,15 @@ 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.
+
 **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`)
 bescheinigt dem Netz bereits **A/A+** und hält CAKE für „marginal". Der nächste Schritt ist deshalb ein
@@ -1977,7 +2032,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.** ~~Das eigentliche Projektziel; **keine offenen Blocker mehr**.~~
+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**.~~
    **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