TP6 geschlossen -- und der kritische Pfad ist leer

Abschluss wie entschieden. CAKE-Queue vom Geraet entfernt, Template-Abschnitt [11]
bleibt als BEGRUENDET LEER stehen: er traegt jetzt die Messreihe und die zwei
Fallen, damit der naechste QoS-Gedanke nicht bei null anfaengt.

  ohne CAKE 42,4 ms | 88 % 43,3 | 73 % 44,0 | 52 % der Linerate 44,6  (idle 12,9)

Die ComplianceRule `queue` BLEIBT und bewacht den Abschnitt weiter -- als leer.
Das ist derselbe Gedanke wie bei wifi-access-list: ein leerer Soll-Zustand ist
eine Aussage, kein fehlender Eintrag. 100/100 compliant, keine Drifts.

NEU: TP6.1 -- Saettigung vermeiden statt Bufferbloat bekaempfen.
Christophs Einwand beim Abschluss ("dann koennten wir zumindest den Sync von der
NAS zurueckhalten") trifft eine echte Luecke im TP6-Urteil: die 30 ms Zusatzlatenz
sind nicht wegzushapen, aber sie treten NUR unter Saettigung auf -- im Leerlauf
misst dieselbe Strecke 12,9 ms. Ein NAS-Sync, der bei laufendem Call zurueckweicht,
haelt die Leitung aus der Saettigung. Das ist eine groessere Verbesserung, als
Bufferbloat-Bekaempfung hier je gebracht haette.

Entwurf steht als TP6.1, bewusst NICHT gebaut:
  - Global-HTB (in TP6 als wirksam bewiesen) + zwei Prioritaetsklassen
  - Prioritaet statt hartem Cap: nimmt dem Sync die Bandbreite nur, solange
    jemand anders sie braucht
  - src-address=10.40.20.10, NICHT ganz VLAN20 -- dort haengen auch HA, Nautobot
    und pve, die nicht pauschal hinten anstehen sollen
  - Vorbedingung: /ip firewall mangle steht unter KEINER ComplianceRule
  - Abnahme misst den Call, nicht die Queue
  - und zuerst pruefen, ob der Fall ueberhaupt auftritt oder DSM schon drosselt

Kritischer Pfad: LEER. deny-by-default steht, Golden Config steht, WLAN steht,
VLAN1 ist weg, TP6 ist beantwortet statt offengelassen.

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

nautobot/mikrotik_routeros.j2

@@ -288,52 +288,31 @@
 /ip address add address=100.96.0.6 comment="TP16.1 Mesh-Overlay" interface=cf-mesh network=100.96.0.6
 /ip route add comment="TP16.1 Mesh" disabled=no distance=1 dst-address=100.96.0.0/12 gateway=cf-mesh
 
-# [11] QoS / CAKE (TP6, 2026-08-23) — gebaut gegen eine Zahl, nicht gegen ein Ritual.
+# [11] QoS — BEWUSST LEER (TP6 geschlossen 2026-08-23).
 #
-#      GEMESSEN am 2026-08-20/21 (tp6-praemisse-messrunbook.md §5), Linerate erstmals
-#      dokumentiert: Upload 9,6 Mbit, Download 54,6 Mbit.
+#      Hier stand einen Tag lang eine CAKE-Queue. Sie ist entfernt, weil sie GEMESSEN
+#      nichts gebracht hat — und das ist die Aussage dieses Abschnitts:
 #
-#                       idle      Upload-Last   Download-Last
-#        Durchlauf 1    12,9 ms   60,4 ms       41,3 ms
-#        Referenz 06-16 12   ms   17,5 ms       nie gemessen
+#        ohne CAKE 42,4 ms | 88 % 43,3 | 73 % 44,0 | 52 % der Linerate 44,6   (idle 12,9)
 #
-#      Der Anstieg liegt in der SENDERICHTUNG bei +28..+47 ms und damit ueber der
-#      §3-Schwelle von <=30 ms -> Fall B. Der Download liegt mit +23..+28 ms DARUNTER
-#      und ist damit nach demselben Kriterium Fall A.
+#      Selbst bei halber Linerate keine Verbesserung. Dort MUSS die Warteschlange im Router
+#      liegen — also entsteht die Zusatzlatenz stromabwaerts, im Arris/DOCSIS-Uplink
+#      (Request/Grant-Scheduling auf MAC-Layer, gar keine Queue). Kein Shaper hier erreicht das.
 #
-#      🔴 Deshalb wird hier NUR die Senderichtung geshaped. Das ist keine Sparsamkeit,
-#      sondern dasselbe Abbruchkriterium in beide Richtungen angewandt: eine Queue fuer
-#      den Download waere gegen ein Problem gebaut, das die Messung nicht gezeigt hat.
-#      Ingress-Shaping kostet auf RouterOS ausserdem Mangle-Umwege, weil man die
-#      Gegenstelle nicht kontrolliert -- Aufwand fuer einen unbelegten Nutzen.
+#      🔴 Zwei Dinge, die beim naechsten QoS-Gedanken Zeit sparen:
+#      1. `/queue tree parent=<interface>` ist auf diesem Geraet WIRKUNGSLOS — MikroTik:
+#         "Interface HTB will not work correctly when the out-interface is hardware offloaded
+#         and the bridge Fast Path is not active." Der Weg ist `parent=global` + ein
+#         `mangle chain=postrouting out-interface=vlan100 action=mark-packet`. So gebaut
+#         zaehlt und drosselt es nachweislich (9,3 -> 7,78 Mbit bei cake-bandwidth=7M).
+#      2. Eine Simple Queue auf `10.40.0.0/16` taugt hinter NAT NICHT als Probe: src-nat
+#         laeuft VOR der Simple Queue, das Target matcht nie.
+#      Merkregeln: Memory `ref_queue_htb_platzierung_docsis`.
 #
-#      🔴 parent=vlan100, NICHT target=10.40.0.0/16. Eine simple queue auf das
-#      LAN-Supernetz wuerde auch INTER-VLAN-Verkehr erfassen (NAS <-> MAIN laeuft
-#      geroutet ueber dieselbe CPU) und ihn auf WAN-Tempo drosseln. vlan100 traegt
-#      ausschliesslich WAN-Verkehr, der Rest bleibt unberuehrt.
-#
-#      Bandbreite = 8,5 Mbit ~= 88 % der gemessenen 9,6. CAKE muss die Warteschlange
-#      selbst halten koennen; bleibt der Puffer beim ISP, regelt es nichts. Der Preis
-#      sind ~1,1 Mbit Spitzendurchsatz und er ist im A/B-Nachweis sichtbar.
-#
-#      cake-nat=yes ist hier kein Beiwerk: hinter srcnat saehe CAKE sonst nur EINE
-#      Adresse und koennte die Hosts nicht gegeneinander fair halten -- genau das ist
-#      aber der Zielfall ("jemand laedt hoch, waehrend jemand telefoniert").
-#      cake-diffserv=diffserv4 trennt dabei latenzkritisch von bulk.
-#
-#      ⚠️ Fasttrack ist auf diesem Geraet faktisch tot (accept steht vor fasttrack,
-#      0 von 445 Verbindungen) und BLEIBT es -- Entscheid 2026-08-19, §4.2. Fasttrack
-#      umgeht Queues; fuer CAKE ist der Zustand die guenstigere Ausgangslage. Wer die
-#      Regelreihenfolge je "repariert", setzt diese Queue mit ausser Kraft.
-#      ⚠️ FORMAT: RouterOS exportiert `cake-bandwidth=8.5Mbps`, nicht `8500000` (gleiche
-#      Klasse wie `hw-offload=true` vs `yes`), UND schiebt vor die Tree-Zeile eine eigene
-#      Hinweiszeile. Dadurch flacht der Backup-Normalisierer `/queue tree` nicht ab: die
-#      add-Zeile steht ohne Pfad-Praefix da. Beide Eigenheiten muessen hier nachgebaut
-#      werden, sonst meldet die Compliance einen Dauer-Drift, bei dem das GERAET recht hat.
-/queue type add cake-bandwidth=8.5Mbps cake-diffserv=diffserv4 cake-nat=yes kind=cake name=cake-wan-up
-/queue tree
-# CAKE type with bandwidth setting detected, configure traffic limits within queue itself
-add comment="TP6: CAKE auf der Senderichtung (WAN-Egress)" name=qos-wan-up parent=vlan100 queue=cake-wan-up
+#      ⚖️ Was hier sehr wohl ginge und offen ist: nicht Bufferbloat bekaempfen, sondern
+#      Saettigung VERMEIDEN (Bulk-Uploads zuruecknehmen, damit ein Call gar nicht erst in
+#      die Saettigung geraet). Das ist ein anderes Ziel und steht als TP6.1.
+#      Die ComplianceRule `queue` BLEIBT — sie bewacht diesen Abschnitt weiter als leer.
 {% elif obj.role.name == "Switch" %}
 # =====================================================================================
 # L2-Switch (crs326-branch) — Sollzustand des Mgmt-Layers.