Christoph Emsenhuber
e17e45db91
TP22 Schritt 5 — Datenmodell as-built aus dem Geraet erhoben (bridge/port, bridge/vlan, bridge/host + ARP/Leases), nicht aus der Doku: - crs326-core von 5 auf 26 Ports; 3 waren "GEPLANT (tentativ)", ether1 zeigte noch auf das tote sw1 #12 - Standort-Fehler: crs326-branch + ap2 standen auf Technik UG, real Technik OG - sw1/sw2/cudy2 -> Decommissioned (Endzustand), cudy1 -> Offline; sw1-Duplikat-Ports (gi*) entfernt - Schritt 4 entschieden: keine Secret-Injection (Governance-Regel 1 deckt es ab) TP21.1/4 — core ether4 geklaert und behoben: dort haengt das Wohnzimmer- Sideboard. Der Port war als ap1-Trunk vorkonfiguriert, pvid=40 nahm untagged an (Upstream ok), Egress war tagged -> TV bekam nichts. Diagnose ueber TX/RX- Asymmetrie + ARP failed bei frischem bound-Lease (ein bound-Lease beweist nur den Upstream: INIT-REBOOT-REQUEST braucht kein ACK). Auf untagged VLAN40 gezogen, Kabel bleibt auf Port 4 (Patchfeld-Nummerierung ist Infrastruktur). TP3.3 — Steering-Regression aus dem TP3-Rebuild behoben: /interface wifi steering war auf BEIDEN APs leer. 802.11r/FT macht die Uebergabe nur schnell, ausgeloest wird sie von 802.11k/v -> sticky client bis zum Abriss. st-main (rrm/wnm, neighbor-group bf-main) wiederhergestellt und ins GC-Template aufgenommen, damit eine Neuprovisionierung es nicht wieder still verliert. Compliance 20/20 -> 63/68 (dieselben 5 bekannten Altlasten): - neue Features wifi-steering, bridge-port, bridge-vlan - der L2-Layer war bisher komplett unueberwacht (core-Zweig hatte gar keine Bridge-Sektion, AP-Zweig nur VLAN ohne Ports) - Bridge-Sektionen bewusst als Literal-Block statt aus DCIM abgeleitet: pvid aus untagged_vlan zu generieren haette die akzeptierten Schiefstaende (core ether3, core ether2, branch ether9-23) zu Dauerdrift gemacht Alle Geraete-Aenderungen liefen ueber Nautobot-GC-ConfigPlans mit /system backup davor, keine Direkt-Writes. 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/.