Go to file

Christoph Emsenhuber 2048b77f8f 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>

2026-08-23 00:54:21 +02:00

.claude

Sideboard-Test zurueckgebaut, und was dabei nicht verschwindet

2026-08-22 19:13:26 +02:00

dns

TP4 DNS: Entscheidung auf RouterOS-nativ + nur statische Records

2026-06-15 11:24:05 +02:00

docs

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

2026-08-23 00:54:21 +02:00

inventory

feat 🔌 TP17 GO: 16 Shellys VLAN1→VLAN30 (Anker-Verfahren) + eco-Policy; TP17.2/TP19 angelegt