Files

Christoph Emsenhuber 3666e1e7fe TP22: RouterOS-Fleet unter Nautobot Golden Config, Deploy scharf

Nimmt die 4 Live-Geräte (crs326-core/-branch, ap1, ap2) real unter Golden
Config: Backup -> Compliance -> intended -> kontrollierter Push. Damit greift
der Governance-Entscheid "Config exklusiv über Nautobot" operativ.

Secret-Leak geschlossen (Anlass, ungeplant gefunden)
  Es gab keine ConfigReplace-Regeln, deshalb hatte der Backup-Job den
  ap1-/export ungefiltert nach Gitea geschrieben: der live genutzte
  WG-Hub-private-key und 6 WLAN-PSKs lagen dort im Klartext.
  - nautobot/ingest-gc-scrubbing.py: 5 ConfigReplace-Regeln, Maske
    "<<REDACTED>>". RouterOS quotet nur bei Bedarf (4 von 6 PSKs standen
    unquotiert), daher Alternation mit der quotierten Variante zuerst --
    \S+ ist greedy und würde bei einem PSK mit Leerzeichen den Rest
    exponieren. Regex-Selbsttest läuft bei jedem Aufruf.
  - Gitea-Repo neu angelegt (History-Rewrite verworfen: Gitea hält
    unerreichbare Blobs bis zum server-seitigen gc). Verifiziert: 0
    unmaskierte Secrets über alle 4 Geräte. User-Entscheid: nicht rotieren.
  - push-gc-template.py: Pre-Push-Secret-Guard, --dry-run, -m, sha optional.

Template
  - AP-Zweig (role == "Wireless AP"), datengetrieben aus ConfigContext
    ap-common + local_config_context_data; ap1/ap2 differieren nur in 4
    Werten. RadioProfile verworfen (hängt an einem Controller, den es seit
    der CAPsMAN-Abschaffung nicht gibt).
  - crs326-core-Zweig von Slash- auf /export-Form (Space-Form, Attribute
    alphabetisch), stale disabled=yes aus der Cutover-Ära entfernt.
  - Switch-Zweig für crs326-branch.
  - Mgmt-Nummernplan korrigiert: ap2 und branch waren in den DNS-Statics
    vertauscht, ap1 zeigte auf ein nicht existierendes .99.3.
    Verbindlich: core .99.1 | branch .99.2 | ap1 .99.11 | ap2 .99.12.
  Ergebnis: ap1 intended == Geräte-Ist (0 Drift), core 68/69 Zeilen
  byte-identisch. 14 ComplianceRules, 51/56 compliant -- die 5 Restdrifts
  sind echte Altlasten (Rettungspfade, Aufräumen gehört zu TP19).

Deploy (nautobot_config.py, Image gc9)
  enable_plan/enable_deploy an. napalm-ros ist READ-ONLY: der Default-
  Dispatcher wählt NAPALM (Platform trägt napalm: ros), Backup geht,
  merge_config scheitert grundsätzlich mit leerer Fehlermeldung. Fix =
  custom_dispatcher auf NetmikoMikrotikRouteros, in den Golden-Config-
  Settings (nicht den Nornir-Settings). Pilot-Deploy: DNS-Statics auf dem
  Core korrigiert, per Purge-vor-Add, weil plan_type=missing nur add
  erzeugt und sonst Duplikate entstanden wären.
  Governance-Regeln in docs/teilprojekte.md festgeschrieben: Pläne nur
  feature-scoped (ein Voll-Push schriebe die Maske als PSK auf die APs),
  AP-Template nie zeilenweise auf ein laufendes Gerät (vlan-filtering=no
  reisst den Mgmt-Pfad ab).

CLAUDE.md: Power-Save-Fehldiagnose korrigiert
  Der P750W war nicht im Power-Save, sondern schlicht ausgeschaltet; das
  Ping-Symptom kam vom lokal mitlaufenden WARP-Client (cloudflared =
  QUIC-Proxy, kein ICMP). Die Merkregel "DHCP-geht-aber-Ping-nicht =
  ARP/Power-Save" ist damit widerlegt und entfernt; strukturell schliesst
  TP16.1 diese ICMP-Lücke.

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

2026-08-13 18:16:21 +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-ap-configcontext.py

TP22: RouterOS-Fleet unter Nautobot Golden Config, Deploy scharf

2026-08-13 18:16:21 +02:00

ingest-ap-rebuild.py

TP3-Rebuild: ap1+ap2 als reine Standalone-APs (CAPsMAN weg)

2026-08-08 19:18:50 +02:00

ingest-baseline.py

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

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

ingest-crs326-core-l3.py

TP15: CRS326-Core als L3-Router aktiviert

2026-08-07 22:39:29 +02:00

ingest-crs326-ports.py

TP15: CRS326-Bring-up (core+branch) + Branch-Tausch gegen sw2 durch

2026-07-23 16:20:26 +02:00

ingest-gc-scrubbing.py

TP22: RouterOS-Fleet unter Nautobot Golden Config, Deploy scharf

2026-08-13 18:16:21 +02:00

mikrotik_routeros.j2

TP22: RouterOS-Fleet unter Nautobot Golden Config, Deploy scharf

2026-08-13 18:16:21 +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/.