Christoph Emsenhuber
b2d286d9c8
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 <noreply@anthropic.com>
Transaktionen — Teständerungen mit Ablaufdatum
Hier liegen die Akten offener und geschlossener Config-Transaktionen. Werkzeug:
nautobot/gc-transaktion.py.
Wozu
Eine Änderung, die am Gerät steht, aber nicht in der SoT, ist Drift — und Drift sieht bisher immer gleich aus, egal ob er ein Versehen ist oder ein laufender Versuch. Wer testen wollte, hatte die Wahl zwischen „Compliance kaputt" und „gar nicht testen".
Eine Transaktion macht die Absicht sichtbar, ohne die Governance aufzuweichen: der Change geht
weiterhin ausschließlich über Golden Config (gc-manual-plan.py), und die Compliance meldet den
Drift weiterhin. Neu ist nur, dass status ihn zuordnen kann.
| SQL | hier |
|---|---|
BEGIN |
Snapshot des Scope-Abschnitts + Akte mit Gerät, Scope, Grund und Ablaufdatum |
| uncommitted | Change ist am Gerät wirksam und im Testumfeld sichtbar, aber nicht in der SoT |
COMMIT |
Template/Config-Context nachziehen → Compliance grün → Akte schließen |
ROLLBACK |
Rückbau-Vorschlag aus dem Snapshot, prüfen, deployen, Akte schließen |
Drei Regeln, die das Werkzeug erzwingt
--expiresist Pflicht. Eine offene Transaktion ohne Frist ist undokumentierter Drift mit besserem Gewissen.statusmarkiert überfällige Akten.- Der Scope ist eine ComplianceRule, kein Freibrief. Driftet etwas außerhalb des Scopes, meldet
statusdas ausdrücklich als nicht abgedeckt. - Eine offene Transaktion je Gerät — sonst ist beim Rollback nicht mehr entscheidbar, wohin zurück.
Zwei bewusste Grenzen
- Der Rollback pusht nicht selbst. Er schreibt einen Vorschlag aus dem Snapshot;
add-Zeilen aus einem/exportlegen neu an, statt zu ändern, und brauchen meist einset [find …]. Ein Rückbau, den niemand gelesen hat, ist genau die Sorte Automatik, die hier schon zweimal teuer war. - Der Snapshot enthält nur den Scope-Abschnitt. Ein voller
/exportenthält Firewall, Adressen, Benutzerliste und Skriptquellen — nichts davon wird für den Rückbau gebraucht, und diese Akten liegen im Git. Für den Ernstfall gibt es das binäre/system backupauf dem Gerät (--device-backup).
Dateien je Transaktion
| Datei | Inhalt |
|---|---|
<change-id>.json |
die Akte: Gerät, Scope, Grund, Fristen, Status |
<change-id>.snapshot.rsc |
der Scope-Abschnitt vor der Änderung |
<change-id>.commands.rsc |
was deployt wurde |
<change-id>.rollback.rsc |
erst nach rollback — der Vorschlag zum Prüfen |