Christoph Emsenhuber
f15dea6d16
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-Tooling
ingest-baseline.py
Idempotenter Basisdaten-Ingest (Locations, Rollen, Device-Types, Devices, VLANs/Prefixes, ap1-Interfaces + IPs, WLAN-Modelle). Bildet den Ist-Zustand ab, nicht den Zielzustand.
export NAUTOBOT_TOKEN=... # aus docs/nas-vlan20/stacks/210-nautobot.yml (gitignored)
python3 nautobot/ingest-baseline.py # Dry-Run
python3 nautobot/ingest-baseline.py --apply # schreiben
API-Fallen (teuer gelernt)
tagged_vlansliest sich per REST alsnull, obwohl korrekt gespeichert. Verifikation nur über GraphQL:POST /api/graphql/mit{interfaces(device:"ap1"){name mode untagged_vlan{vid} tagged_vlans{vid}}}.- Relationen kommen ohne
?depth=1ohnedisplay→ ein voll gepflegtes Device sieht leer aus. LocationType.content_typesmussipam.vlangroup/ipam.vlan/ipam.prefix/dcim.controllerenthalten, sonst 400 beim Anlegen.parent_interfacenur für virtuelle Interfaces — WLAN-VAPs können ihren Master nicht als Parent tragen.WirelessNetworkhat kein VLAN-Feld; die VLAN-Bindung hängt anwireless/controller-managed-device-group-wireless-network-assignmentsund braucht zwingend einenController(bei uns logisch,controller_deviceleer — kein CAPsMAN).RadioProfile.channel_widthwill Integer ([20,40,80]), nicht"20mhz".- IP↔Interface läuft über
/ipam/ip-address-to-interface/.
ingest-wifi-access-list-rule.py
Legt ComplianceFeature + ComplianceRule wifi-access-list an (Plattform RouterOS,
match_config=/interface wifi access-list). Idempotent, Dry-Run ist Standard.
export NAUTOBOT_TOKEN=...
python3 nautobot/ingest-wifi-access-list-rule.py --apply
Warum es die Rule braucht: ohne sie erzeugen Eintraege in der access-list keinen Drift
und lassen sich nicht als Config-Transaktion fuehren -- gc-transaktion.py verlangt eine
ComplianceRule als --scope. docs/tp25-pin-s22.sh schreibt dort bei jedem Messrundgang, und
TP25 Fund E (signal-range-Boden) landet dauerhaft dort.
Der Soll-Zustand ist leer und steht als Kommentarblock [6c] im Template. Waehrend eines
Messlaufs ist der Drift erwartet und gehoert als offene Transaktion gefuehrt.