Files
Christoph Emsenhuber b91bac1265 TP45 Schicht B2: VLAN30-Reservierungen ins Oktett-Schema
36 DHCP-Reservierungen wandern aus dem Pool-Fenster (.5, .8, .202-.244)
in die Schema-Baender .11-.14 / .151-.176 / .177-.196. Dazu die CCU-Leiche
.232 (status=waiting, last-seen=never; die CCU lebt in VLAN20) entfernt und
SONOFF-NSPanelPro von einer dynamischen Lease auf .249 zu einer statischen
Reservierung auf .12 gepinnt.

Neuer Job `tp45-v30-leases` in gc-configplan.py. Er laedt MOVES/REMOVE/ADDS
per importlib aus tp45-leases.py, statt sie zu kopieren -- die Tabelle dort
ist die SSoT des Umzugs, eine zweite Kopie liefe still auseinander.

Warum der Job zwei Selektor-Formen traegt: die erste Fassung schrieb
ueberall `[/ip dhcp-server lease [find where ...]]`. In `[:len ...]` ist das
Syntaxfehler (`expected command name (line 1 column 55)`, live gemessen) --
Golden Config meldete trotzdem Job SUCCESS und Plan Completed, das Geraet
blieb unveraendert. Aufgefallen ist es an der Zahl der Log-Zeilen: von 38
`:if`-Statements hat kein einziger Zweig geloggt. Richtig ist
`[/ip dhcp-server lease find where ...]` ohne Klammerpaar um `find`;
die Argument-Form `set [find where ...]` bleibt.

Abnahme am Geraet, nicht am Plan-Status: 39 Leases im Soll-Schema, .232 und
.249 geraeumt, NSPanelPro dynamic=false; Compliance 145/145, keine Drifts.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-21 16:18:05 +02:00
..

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_vlans liest sich per REST als null, 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=1 ohne display → ein voll gepflegtes Device sieht leer aus.
  • LocationType.content_types muss ipam.vlangroup/ipam.vlan/ipam.prefix/dcim.controller enthalten, sonst 400 beim Anlegen.
  • parent_interface nur für virtuelle Interfaces — WLAN-VAPs können ihren Master nicht als Parent tragen.
  • WirelessNetwork hat kein VLAN-Feld; die VLAN-Bindung hängt an wireless/controller-managed-device-group-wireless-network-assignments und braucht zwingend einen Controller (bei uns logisch, controller_device leer — kein CAPsMAN).
  • RadioProfile.channel_width will 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.