- APs werden als reine APs neu aufgesetzt (kein Zurückbau)
- WG-Hub behält ap1-Private-Key, damit Remote-Spokes keine Reconfig brauchen
- WiFi-PSKs lokal auf APs, nicht im Nautobot-Template
- Nautobot/GC-Setup für alle 4 MikroTik-Geräte als Ziel, Switches heute nicht neu provisionieren
Co-Authored-By: Claude <noreply@anthropic.com>
- routeros/tp15-core-l3-staged.rsc: ap1s Live-L3-Config 1:1 als staged
Config (alles Betriebsumlenkende disabled=yes, Cutover-Enable in einem
Rutsch). Reservierungen + WG-Privkey bewusst erst im Fenster maschinell
von ap1 geholt statt abgetippt.
- Fund/Luecke geschlossen: WG-Hub (TP10 FM/DW-VPN) haengt an ap1s
Public-Edge, im Handoff uebersehen -> migriert im selben Fenster mit.
- Fenster-Start-Entscheide: Governance = frische Direkt-Ausnahme #3
(REST/MikroMCP, danach intended->Nautobot); Rettungspfad iPhone-Hotspot.
- Prep-Gotchas dokumentiert: MikroMCP kann core noch nicht schreiben
(ENV nicht geladen), Mgmt-.99.11 tot (nur .41.211), WG-Keypair-Transfer,
Public-IP-Wechsel am WAN, vlan99 .1-vs-.11-Reconcile, VLAN1-Teardown.
- teilprojekte.md TP15 fortgeschrieben.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Nautobot-Ingest (Ist, nicht Ziel):
- Locations: LocationType "Bereich"; Technik UG (Diele, kein Keller) = crs326-core,
Technik OG = crs326-branch, Wohnzimmer Sideboard = ap1
- Devices: ap2 -> Rolle "Wireless AP" + Offline; beide CRS326 Platform RouterOS
nachgetragen (fehlte -> haette jeden GC-Job auf ihnen verhindert);
sw1/sw2/cudy1 als Uebergangs-Devices ohne Platform
- IPAM: VLAN-Group BF, 9 VLANs (VLAN1 deprecated), 8 Prefixes je VLAN-gebunden
- ap1: 26 Interfaces inkl. MACs, ether2 als Trunk, 9 GW-IPs
- WLAN: logischer Controller bf-wlan (kein CAPsMAN), 6 SSIDs mit VLAN-Bindung,
2 RadioProfiles
Entscheide 2026-07-22:
- crs326-core wird L3-Router; Routing/DNS/DHCP wandern von ap1, APs werden reine APs.
Ueberschreibt die fruehere "Router bleibt ap1/ap2"-Zeile desselben Tages.
- CAPsMAN wird abgeschafft, beide APs von Nautobot identisch generiert.
- AP-Uplink wandert auf ether1 (PoE-Port). RouterOS nummeriert ab 1, nie ether0.
Befunde:
- Root Cause des ap1-VLAN1-Lecks: cfg-main-2g hat gar keinen datapath-Block ->
2,4-GHz-main taggt nicht, Bandwechsel = Subnetzsprung. Nicht das frame-types-Thema.
- Beide CRS326 laufen bereits (RouterOS 7.19.5, Werkszustand), beide auf 192.168.88.1
im selben L2 = IP-Konflikt.
- hAP ax2 PoE ist passiv 18-28V, nicht 802.3af/at; ether1 steht auf poe-out=auto-on.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- RB5009 final gestrichen (User-Entscheid 2026-07-22) — Router bleibt ap1/ap2,
Referenzen in teilprojekte.md + hw-refresh-requirements.md bereinigt.
- TP16.1 Ziel-Device von ap1 auf CRS326 Core-Switch retargeted (Doku-only,
Scharfschalten bleibt gated bis TP21 den CRS326 abdeckt), Runbook umbenannt
auf tp16.1-warp-mesh-native-crs326.md, cf-tunnel-mapping.md §14 + Handoff-
Prompt mitgezogen.
- TP21: docs/nas-vlan20/nautobot-image/ neu — der Dockerfile/nautobot_config.py/
allnet_sg8316m_driver.py, aus denen das laufende Custom-Image tatsächlich
gebaut ist (der bisherige Verweis auf scratch/nautobot-gc-build existierte
nirgends). Ergänzt napalm-ros + nornir-napalm + librouteros + gepinntes
setuptools<81 (pkg_resources-Regression), Nornir-Credentials auf
CredentialsNautobotSecrets umgestellt, Compliance/Intended-Config/SoT-Agg
aktiviert. Backup/Intended/Compliance-Pipeline live gegen ap1 verifiziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Omada-PVID-Fix gestrichen (User-Entscheid 2026-07-22): Omada spielt seit der
TP15-Korrektur keine Rolle mehr im Netz → nicht wieder aufgreifen
- TP5 Deny-by-default folgt nach TP21/CRS326-Adoption (Holes + WAN-Seal stehen schon)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Frische Sonnet-Delegations-Session lief in die '10000 Authentication error'-Falle:
sie versuchte CF-Writes über den read-only MCP. Root Cause: .claude.json referenziert
nur die MCP-URL, NIE den Token in mcp/cloudflare/.env → kalter Agent kennt den Write-Pfad nicht.
- Handoff-Prompt: prominenter 'CF-KOMMUNIKATION'-Block (2 getrennte Pfade, exakte curl-
Kommandos, '10000 = kein Rechteproblem, Pfad wechseln'-Hinweis im Ablauf).
- cf-tunnel-mapping.md §11: gleiche Klarstellung als SSoT-Callout inkl. Verifikation
(no-op vnet-PATCH: MCP→10000, curl→success). 'Claude hat zig Tunnel erstellt' = immer
via curl+Token, NIE via MCP.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Governance-Callout (teilprojekte.md): Christoph erteilt Ausnahme von 'Config nur
via Nautobot' für alle (Vor)Arbeiten am zentralen CF-Tunnel-Zugang AUF AP1 (TP16/16.1,
native WG-Mesh-Zeilen). Scope-Grenze: nur ap1 — CRS326 (TP15) fällt vorerst NICHT
darunter, bleibt Nautobot-GC-pflichtig. Follow-up: ap1-Zeilen später in GC nachtragen.
- Neu: docs/tp16.1-session-handoff-prompt.md — kopierfertiger Auftrag für die
Delegations-Session (Sonnet), Governance-Gate jetzt als 'erteilt' statt 'erst fragen'.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fehlschluss revidiert: ICMP-Häkchen ist Dashboard-only (nicht im API-Spec),
aber aktiv — belegt durch funktionierenden Ping ins FM-Netz. Kein To-Do.
bf-Ping-Verlust im Incident lag an QUIC-losen macmini-Connectoren (post-http2),
nicht am Flag. Re-Check trotzdem nach Scharfschalten (§4.5).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Primärquellen (animmouse Mesh-on-MikroTik + wgcf-connector) und offizielle
CF-Docs/OpenAPI-Spec gegengelesen — Lead bestätigt, 6 Härtungen eingearbeitet:
- Produkt seit 2026-04-14 offiziell 'Cloudflare Mesh' (API bleibt /warp_connector,
im Spec bestätigt inkl. Token- und HA-Endpoints; Node-Limit 50/Account)
- NEU: ICMP-Proxy-Prerequisite — Dashboard-only (nicht im API-Spec), 1 Klick
Traffic settings→Proxy→ICMP, sonst bleibt das Abnahmekriterium Ping tot
- Split-Tunnel-Exclude auf BEIDEN Device-Profilen (Default + Mesh)
- vnet-Gotcha beim Route-Umzug ('virtual networks only for cloudflared') →
Weg A PATCH / Weg B DELETE+POST; CF-API-Writes sind WARP-unabhängig (Rollback safe)
- v4-only-Entscheid (Mesh-IPv6-site-to-site laut Guide broken, kein NAT66)
- keepalive 1m ok, .conf-Inhalte präzisiert (IPv6+DNS ignorieren)
Runbook ausführungsreif für die Delegations-Session.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Incident-Nachgang 2026-07-16: ICMP über den cloudflared-WARP-Pfad ist strukturell
kaputt (TCP ok überall, Ping fm 36%/bf 100%/dw 100% Loss) — cloudflared ist ein
QUIC-L7-Proxy, kein WireGuard. Richtungsentscheid: Private Access (unterwegs ->
10.40.0.0/16 inkl. ICMP) wandert vom cloudflared-Proxy auf einen nativen
Cloudflare-Mesh-Node (WireGuard) auf ap1 -- kein Container/TUN/LXC/neue HW
(RouterOS-Container haben kein /dev/net/tun -> hAP ax3 löst es nicht, zudem WiFi6).
Public-FQDNs bleiben unverändert auf dem cloudflared-3-Tunnel-HA.
- Neu: docs/tp16.1-warp-mesh-native-ap1.md (Konzept + vollständiges Runbook +
gemessener Account-Ist-Stand, Team emsenhuber.cloudflareaccess.com)
- cf-tunnel-mapping.md §13: ICMP-Dreiländer-Befund; "bf-pve wegen USV" REVIDIERT
(Begründung invertiert -- bf-pve-Connectoren laufen auf NAS+macmini, nicht pve)
- cf-tunnel-mapping.md §14 + teilprojekte.md TP16.1: Richtungsentscheid dokumentiert
Scharfschalten = eigene Session (CF-Prereqs sind account-weit, treffen Live-WARP).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Incident 2026-07-16: User unterwegs, keine BF-IPs mehr über WARP. Root Cause:
cloudflared-bfnas/-bfpve auf macmini flappten unter QUIC/UDP (Docker-Desktop-
Bridge-NAT) -> bf-nas/bf-pve von 2 auf 1 Connector degradiert. Fix: beide auf
TUNNEL_TRANSPORT_PROTOCOL=http2 umgestellt, rollend, wieder volle HA.
Nebenbefund per Audit-Log: User hatte die WARP-Private-Network-Route selbst
neu angelegt, zeigt jetzt auf bf-pve statt bf-nas. Bewusst so belassen -
pve ist USV-gepuffert, NAS/macmini nicht. cf-tunnel-mapping.md §11 damit
überholt, §13 als neue Baseline.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TP20: Postgres-16-LXC (105, pve, 10.40.20.20) provisioniert, UTF8/en_US.UTF-8,
wal_level=replica, DB+Rolle nautobot angelegt, End-to-End verifiziert. archive_mode
bewusst noch aus bis TP18/pgBackRest steht.
TP21: Nautobot-Stack (ghcr.io/nautobot/nautobot:3.1.7) als Portainer-Stack auf NAS
live (App+Worker+Scheduler+Redis), DB=platform-pg, API-Smoke-Test grün. Healthcheck-
gated Worker/Scheduler-Start ergänzt (Migration-Race-Condition beim Erstboot gefixt).
TP19.1: sw2 jetzt final auf 10.40.99.12 (statisch) — Christoph über Klickanleitung.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TP2.1 (sw2-Standalone-Recovery) von Christoph solo abgeschlossen. TP19-Live-Sweep
auf ap1 zeigt VLAN1 schon viel weiter zurückgebaut als dokumentiert (defconf-DHCP
bereits disabled, cudy1→VLAN10 umgenutzt, cudy2 tot) → neuer Unterpunkt TP19.1 für
den VLAN99-MGMT-Cutover. TP14.1-Rest obsolet (kein Omada-Re-Adopt mehr), TP14.3
DNS-Sweep fertig (nas/docker-Records auf ap1 korrigiert, omada/omada-mcp/fritzbox-
Records entfernt, da Controller von Christoph komplett gelöscht wurde). RouterOS-
Config-Backups (enthalten Live-WiFi-Passphrasen) neu gitignored.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
dirtyvader-main-Clients bekommen zeitweise VLAN1-IPs (10.40.41.x) statt
VLAN10 — gleiches Dual-DHCP-Race-Muster wie beim ap2-Fix (TP3.1,
2026-07-06), aber die admit-only-vlan-tagged-Härtung fehlt bisher auf ap1.
Zwei-Phasen-Runbook angelegt: Phase A (TP3.1-Scope, Akutfix ap1) vor
Phase B (TP19-Scope, voller VLAN1+cudy-Teardown, macht Phase A obsolet).
TP19 auf hochdringlich gesetzt, da VLAN1 jetzt ein aktiver Bug ist statt
nur Cleanup.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sw2-Controller-Link brach beim VLAN20-Umzug (TP14.1), Werks-Reset beim
Rettungsversuch, fehlerhafte Wiederherstellung — Controller-Zustand jetzt
invalid. sw2 wird ohne Managementsoftware neu aufgesetzt (TP2 als Playbook,
neue Portbelegung offen). TP15 korrigiert: Omada bekommt keine Rolle mehr,
auch nicht WLAN (bleibt bei hAP ax²/CAPsMAN) — reines MikroTik-Ecosystem.
TP19-Update: Shelly wieder da, SwitchBot-Move erst nach VLAN1-Retirement.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
vmbr0.20 (kaputte Netzadresse statt Host-IP) auf 10.40.20.100/24 korrigiert,
Default-GW live geflippt (ifreload -a, kein Reboot). CF-Ingress bf-pve
(pve/j44d6tua-ssh) + ap1-DNS nachgezogen; dabei Alt-Bug gefunden und gefixt
(pve-mcp.bf.lan zeigte noch auf .41.173 statt .20.173).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer TP-Konzeptstand aus der Storage-Skalierungs-Diskussion: selbst
gehosteter, geo-verteilter S3-Objektspeicher (Garage) über BF/FM/DW als
Cold-Tier — statt Cloud oder größerem Einzel-NAS.
Kernentscheide festgehalten: Engine=Garage (WAN-tolerant; Ceph/MinIO/
SeaweedFS als Fallback begründet), Disk-Layout=JBOD statt RAID
(Redundanz nur über Sites, RF=3), Variante kalt=Objektspeicher/heiß=
lokal. Inkl. Dimensionierung (10 TB nutzbar Anker), Kostenmodell
(capex/opex, per-Site + kumulativ, JBOD-vs-RAID1-Ersparnis) und Impacts
auf Syno-Rolle, Backup-Kette und Container-Hosts (TP14/15/10/16).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Entscheidung: alle Shellys bekommen statische IP (10.40.30.<octet>, gw/dns .30.1)
+ in-pool DHCP-Reservierung als Backup. set_sta auf static=true (Default) umgestellt
(Ziel-IP aus Oktett), _sta_cfg-Helper.
- pool-v30 auf .100-.250 erweitert (Reservierungen jetzt in-pool, User-Konvention).
- s24 (14:33:5c:d8:2d:7c) ins inventory/bf.csv + .30.204-Reservierung.
- Voller HA-Device-Scan (alle MAC-Geräte, nicht nur configuration_url): fand
Apple TV 4K + Philips TV (aus, VLAN40) — vor cudy-Teardown VLAN verifizieren;
Apple TV = vmtl. Thread-Border-Router (TP17.1). Tasmota bestätigt tot (MAC nicht im Netz).
- .41.246/.247 = cudy1/cudy2 (Teardown-Ziele) dokumentiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Live-Abgleich Projektstatus vs. echter Netzstand (MikroMCP/pve-mcp/HA):
- VLAN20 verifiziert: NAS .20.10, Mac mini .20.167, pve-LXC .20.126 alle live;
einziger Host noch in VLAN1 = pve-Host-Mgmt .41.100 (verbleibende Host-Migration).
- TP17 Shelly: Migration schon ~6/26 durch (s14/16/18/22/23/24 stabil auf .30.2xx);
16 VLAN1-Shellys verbleiben; alle VLAN30-Reservierungen stehen; s6-Reservierung
.30.213 MAC gefixt (0C:72..9E -> real D0:CF:13:D8:18:FC).
- HA-Cross-Check aller IPv4-Geräte: .30.204 = Shelly Bad/Spiegelschrank (=vmtl. s24);
Nicht-Shelly-VLAN30-Mover SwitchBot/.184 + Tasmota Nous A1 + 1 offen; .41.246 unident.
- Neues Runbook docs/tp17-shelly-go-runbook.md: 16er-Migrationstabelle, Go-Sequenz,
Scope-Erweiterung (WLAN+IP+einheitliches Geräte-PW via Shelly.SetAuth),
Gen4->Thread/Matter-Projektion (TP17.1, experimentell), VLAN1-Leerstand-Verdikt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Projekt-Skill unter .claude/skills/projektstatus/ — liest SSoT docs/teilprojekte.md
frisch, gruppiert alle TP in Themenblöcke (inkl. TP17 Shelly, TP14-Migration) und
rendert ASCII-Statusbaum + kritischen Pfad.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
vw von bypass/everyone auf non_identity(Heim-IP)+allow(email:christoph) umgestellt
(reusable-Policy via App-PUT detacht). Neuer 🔴 Fund dokumentiert: Wildcard
*.emsenhuber.net login_method:github/google = jeder Eingeloggte erreicht alles
(user-gated). hass-400 = HA-Origin (nicht Access), gateway-dw WG offen. §10.6.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Root-Cause endgültig (User-Diagnose bestätigt): ein cloudflared ist blind NUR
für macvlan/ipvlan-Container auf seinem EIGENEN Host → mehrere Connectoren auf
1 Tunnel + Round-Robin = 1/N garantierte 1033 ("jeden 3. Schuss eine Niete").
Kein Route→Connector-Pinning innerhalb eines Tunnels → HA nur über getrennte
Tunnel: reziprokes Per-Host-Design (jeder Dienst von den anderen Hosts bedient,
3 Tunnel/2 cloudflared je Host = voll HA gegen Single-Host-Ausfall).
- cf-tunnel-mapping.md §9: Invariante + Live-Inventory v119 (Access-Modi,
DOWN-Origins pbs/nginx-bf/hermes×2) + Ziel-Design + Umsetzungsreihenfolge;
Abschnitte 1-8 als Historie markiert.
- teilprojekte.md TP16 umgeschrieben: Root-Cause, reziprokes HA, Access-Strang
(hass-400=CF-Access→WARP, vw=bypass→schützen), Status "dokumentiert,
Umsetzung = eigene Session".
- Reine Doku, keine Tunnel-/DNS-/Container-Änderung.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- pve-mcp „Failed to connect" = mcp-pve 0.4.8 kann nur 1 MCP-Session
("Server already initialized") → Upgrade 0.6.1 (Per-Session), ✔ Connected.
omada-mcp war/ist gesund (frische Session-ID pro Init).
- Kollateral: VLAN20-Host-DNS auf NAS+LXC zeigte noch auf totes .41.254
→ docker-pull scheitert; LXC pct set .20.1, NAS Synology-DHCP-DNS-Falle.
Neuer Gotcha in CLAUDE.md.
- TP16 (neu, hochdringlich): FQDNs via CF „sehr unsicher" = #1033-Round-Robin
zurück; Live-Snapshot 2026-07-10: bf-Tunnel 2 statt 3 Connectoren, alle
frisch (2026.7.1), Origins nach VLAN20-Move erneut asymmetrisch zu auditieren.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Requirements/Architektur zur Ablösung von ALLNET-Core + 2 Branch-Switches:
Strom-Baseline, Energieeffizienz, zentrales Management, DC-USV-Konzept.
Status: Entwurf; verweist auf TP15 in teilprojekte.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 6 NAS-Origins .41→.20 repointet (ha-mcp, NAS-ssh, gitea, vw, grafana, pve-mcp), v115→v116.
- Befund: pve-Connector erreicht VLAN20 (vw 200 via Tunnel); 502 direkt nach Ingress-PUT = transient.
- grafana 502 = Container exited, kein Routing-Problem. Kein pve-Static-Route nötig.
- Stufe-4-Connector-Vantage löst sich mit pve→VLAN20 (PVID1-Cutoff).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Diagnose der Docker-Container-Fehler nach NAS-NIC-Wechsel auf VLAN20:
- Config-Only-Macvlan-Falle (Portainer 2-Schritt, Driver=null → kein Attach)
- Macvlan-Parent ovs_eth0 exklusiv → default_external muss weg für vlan20
- default_internal (172.18) existiert nicht mehr (Range von gitea_default belegt)
RUNBOOK: IP-Mapping .41.X→.20.X (Oktett behalten), Phase-A-Teardown,
Post-Steps (ap1-DNS, CF-Ingress-Repoint, omada-Inform .20.175), CF-Access
claude-mcp-Profil-Status.
Stack-Compose-Files + Inspect-JSONs (docs/nas-vlan20/stacks/, inspect_*.json)
via .gitignore ausgeschlossen — enthalten Live-Secrets.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
