Files

Christoph Emsenhuber dfec117e6b TP15: Portfakten + Governance-Ausnahme CRS326-Bring-up + Handoff-Prompt

Portplan-Widerspruch aufgeloest (User): Core #15 = ap1 (Ziel kuenftig #4), #11 = cudy1.
Damit gilt die TP4-Variante (gi16 Arris -> gi15 Trunk -> ap1); 03-trunk-ap-ports.cli
(gi1 = ap1) ist STALE, vom Edge-Cutover 2026-07-01 ueberholt. gi16/gi8 bleiben
unverifiziert und sind in Nautobot als solche markiert.

Kernrisiko dokumentiert: crs326-core ersetzt sw1 UND wird L3-Router, an sw1 haengt ap1
(#15) mit Gateway/DHCP/DNS/WAN-Trunk -> Core-Tausch und L3-Umzug sind dasselbe Ereignis
und bedeuten ein Vollausfall-Fenster. Entscheid: Branch zuerst, Core eigene Session.
Rettungspfade liegen guenstig getrennt (Notebook-WLAN via cudy1 am Core #11,
Kabel-Plan-B am sw2/Branch P4).

Governance-Ausnahme #2 erteilt (User): CRS326-Grundconfig direkt via MikroMCP/Winbox
(Henne-Ei - GC kann nicht auf ein Geraet ohne IP pushen, Templates fehlen). Auflage:
Ist-Stand danach als intended config nach Nautobot. Gilt nicht fuer ap1/ap2.

Nautobot: cudy1/cudy2 als Cudy WR3600E V1.0 (Firmware 2.3.15-20250905-191956),
cudy1 -> Technik UG, cudy2 -> Technik OG/Decommissioning; Platzhalter-DeviceType
entfernt; sw1 gi8/gi11/gi15/gi16; crs326-core ether4 als Zielport fuer ap1.
Alle 8 Devices haben jetzt einen Bereich.

Neu: docs/tp15-crs326-session-handoff-prompt.md - kopierfertiger Auftrag fuer die
naechste Session (beide CRS326 bring-up, Portplan, NUR Branch-Tausch).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-22 21:58:12 +02:00

ingest-2026-07-22-restdaten.py

TP15: Portfakten + Governance-Ausnahme CRS326-Bring-up + Handoff-Prompt

2026-07-22 21:58:12 +02:00

ingest-baseline.py

TP21: Nautobot-Basisdaten (Ist-Stand) + TP15-Kurskorrektur CRS326 = L3-Router

2026-07-22 21:28:28 +02:00

README.md

TP21: Nautobot-Basisdaten (Ist-Stand) + TP15-Kurskorrektur CRS326 = L3-Router

2026-07-22 21:28:28 +02:00

README.md

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/.