TP15: CRS326-Bring-up (core+branch) + Branch-Tausch gegen sw2 durch
- Beide CRS326 grundkonfiguriert via REST (Governance-Ausnahme #2): core-zuerst als L2-Pfad, Zugriff auf Werks-.88.1 über temporäre ap1-.88.2+Masquerade (nach Bring-up entfernt). Winbox-MAC scheiterte (sync-timeout). - branch produktiv, volle SOLL-Portbelegung (ether1 Uplink→sw1#8, 2/8 NAS-20T, 3 Drucker/4 Dock VLAN10, 5/6 Sonos VLAN40, 7 macmini VLAN20, 24 ap2), mgmt .99.13; core grundkonfiguriert nicht produktiv (mgmt .99.11, an sw1#12). - Branch-Tausch: sw2 physisch raus, Lifelines auf branch; Abnahme grün (NAS/ macmini VLAN20, Dock VLAN10, Sonos VLAN40). Gotcha: ether3/5-Kabel vertauscht (Sonos-VLAN10-Leck/Dual-Homing) → gefixt. - Nautobot modelliert + GraphQL-verifiziert (nautobot/ingest-crs326-ports.py): branch Active + Ports, core Planned + tentativ, sw1 verifizierte 16-Port- Belegung (löst UNVERIFIZIERT), sw2 Decommissioning. - CRS326 in MikroMCP routers.yaml; Creds in ~/.secrets. Doku (teilprojekte/ CLAUDE/ip-plan) nachgezogen; Core-Swap-Handoff-Prompt neu. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
@@ -21,7 +21,9 @@
|
||||
| ap1 (Router/hAP) | 10.40.41.1 | Router/GW | alle (.1) + Mgmt | bleibt `.1` je VLAN; Mgmt `10.40.99.1` | ⬜ | ist GW, kein „Umzug" |
|
||||
| ap2 (hAP) | 10.40.41.2 | AP | 99 MGMT | `10.40.99.2` | ⬜ | |
|
||||
| sw1 ALLNET (Core) | 10.40.41.11 | Switch-Mgmt | 99 MGMT | `10.40.99.11` | ⬜ | Mgmt-VLAN-Wechsel = Lockout-Risiko, sorgsam |
|
||||
| sw2 Omada (ES208G) | ~~10.40.41.181~~ | Switch-Mgmt | 99 MGMT | `10.40.99.12` | ✅ **live** | TP19.1 2026-07-16, Christoph selbst über Klickanleitung |
|
||||
| ~~sw2 Omada (ES208G)~~ | — | — | — | — | ❌ **abgebaut** | TP15 2026-07-23: physisch entfernt, durch crs326-branch ersetzt (Technik OG) |
|
||||
| **crs326-branch** (CRS326) | 192.168.88.1 (Werk) | Switch-Mgmt (Technik OG) | 99 MGMT | `10.40.99.13` (Ziel `.99.12` nach Core-Tausch) | ✅ **live** | TP15 2026-07-23: ersetzt sw2; Bring-up-VLAN1-Temp `.41.213`; über sw1 #8 |
|
||||
| **crs326-core** (CRS326) | 192.168.88.1 (Werk) | Switch-Mgmt/künftig L3-Router (Technik UG) | 99 MGMT | `10.40.99.11` | 🟡 **grundkonf.** | TP15 2026-07-23: grundkonfiguriert, nicht produktiv (ersetzt sw1, eigene Session); VLAN1-Temp `.41.211`, an sw1 #12 |
|
||||
| NAS nas-bf (DS923) | ~~10.40.41.10~~ | INFRA | 20 INFRA | `10.40.20.10` | ✅ **live** | TP14.1 2026-07-10; DNS `nas.bf.lan` nachgezogen 2026-07-16 |
|
||||
| ~~Omada-Controller~~ | — | Service (macvlan/DS923) | — | — | ❌ **entfernt** | User hat den Container 2026-07-16 gelöscht (overkill für 1 Switch auf der Abschussliste, s. TP2.1/TP15). DNS-Eintrag `omada.bf.lan` entfernt |
|
||||
| ~~omada-mcp~~ | — | Service (pve-LXC) | — | — | ❌ **entfernt** | mit dem Controller zusammen gelöscht 2026-07-16 (MCP-Server verwaist, in Claude-Settings noch registriert — Aufräumen offen). DNS-Eintrag `omada-mcp.bf.lan` entfernt |
|
||||
|
||||
@@ -344,7 +344,15 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung".
|
||||
### TP14.5 — Session E: Freigabe-Gate → TP5-Firewall ▸ 🔜 (ZULETZT)
|
||||
- Erst wenn TP14.1–14.3 durch (alle Origins/Connectoren in VLAN20) → dann TP5 (Deny-by-default) starten. Reines Reihenfolge-Gate, kein eigener Change.
|
||||
|
||||
### TP15 — HW-Refresh: Switching + Router + DC-USV ▸ 🟡 Beschaffung läuft, **Lieferung 2026-07-17 (morgen)** — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc`
|
||||
### TP15 — HW-Refresh: Switching + Router + DC-USV ▸ 🟢 **CRS326-Bring-up + Branch-Tausch DURCH (2026-07-23)**; Core-Tausch/L3-Umzug offen (eigene Session) — `docs/hw-refresh-requirements.md`, Memory `project_mikrotik_commit_nautobot_gc`
|
||||
- ✅ **BRING-UP BEIDER CRS326 + BRANCH-TAUSCH gegen sw2 — DURCH (2026-07-23, Claude via REST unter Governance-Ausnahme #2).** Ablauf/As-built:
|
||||
- **Zugriffsweg (Henne-Ei gelöst):** Erst-Reihenfolge war **core zuerst** (User-Korrektur — core hängt an sw1 und ist der L2-Pfad, über den branch überhaupt erreichbar wird; branch war isoliert). Zugriff auf die Werks-`192.168.88.1` über **temporäre ap1-Zweit-IP `192.168.88.2/24` + srcnat-Masquerade `192.168.88.0/24`** (beide `TP15-temp`, nach Bring-up wieder entfernt — Rückweg nötig, weil die Werks-Box keine Route zu VLAN10 hat). Config dann komplett per **REST** (`/system/script` PUT+run), kein Winbox-Paste. **Winbox-MAC-Connect scheiterte reproduzierbar** („macconnection sync timeout" über WLAN/quer durch den Fabric — braucht selben Draht).
|
||||
- **Identitäten am Gerät verifiziert (nicht nur Doku):** `core` = sw-id **4W04-URHT**, MAC `04:F4:1C:B4:17:76`, Serial `HKA0AREXJFM`, PW `X9…`; `branch` = sw-id **RGZJ-UK0T**, MAC `04:F4:1C:B4:15:58`, Serial `HKA0AJJA52F`, PW `PHR…` (ap2 hängt an branch **ether24** — bridge-host bestätigt = definitiv branch). **PWs in `~/.secrets/credentials.env`.**
|
||||
- **branch = produktiv, volle SOLL-Portbelegung** (User-manuell erhoben, maßgeblich): ether1 Uplink-Trunk→sw1 #8 (native VLAN1 + tagged 10/20/30/40/50/90/99, **kein 100**), ether2+ether8 = **NAS 2×tagged-VLAN20** (zwei unabhängige Links), ether3 Drucker/VLAN10, ether4 Dock/VLAN10, ether5+ether6 Sonos/VLAN40, ether7 Mac mini/VLAN20, ether24 ap2-Trunk; ether9–23+sfp disabled. vlan-filtering=yes. Mgmt **`10.40.99.13` (VLAN99)** erreichbar über sw1 #8 (+ VLAN1-Temp `.41.213` während Bring-up). **Post-Swap-Abnahme grün:** NAS `.20.10`, Mac mini `.20.167` (VLAN20), Dock `.10.194` (VLAN10), Sonos `.40.191`/`.40.192` (VLAN40).
|
||||
- **core = grundkonfiguriert, NICHT produktiv** (bleibt an sw1 #12): identity/vlan-filtering/volle VLAN-Tabelle, ether1 Uplink, ether2 Temp-Downlink (war Config-Pfad für branch), Mgmt **`10.40.99.11`** (VLAN99, erreichbar erst wenn sw1 #12 99T trägt) + VLAN1-Temp `.41.211`. Port-Layout ab ether3 tentativ (final in Core-Swap-Session).
|
||||
- **Beide in MikroMCP `routers.yaml`** (crs326-core/-branch, ENV `ROUTER_CRS326_*` in `~/.claude.json` — **live erst nach MCP-Neustart**, diese Session lief alles per REST-curl). **Nautobot** modelliert + GraphQL-verifiziert (`nautobot/ingest-crs326-ports.py`): branch Active + volle Ports + primary_ip4 `.99.13`; core Planned + tentatives Layout; **sw1 verifizierte 16-Port-Belegung** (löst „UNVERIFIZIERT"); **sw2 → Decommissioning**.
|
||||
- 🐞 **Gotchas festgehalten:** (1) **Kabel ether3↔ether5 waren beim Umstecken vertauscht** → ein AZ-Sonos landete als Access-VLAN10 in `10.40.10.190` **und** blutete via SonosNet nach VLAN40 (= Dual-Homing-Muster, `project_dual_homing_slowness_incident`) → Kabeltausch gefixt, beide AZ-Sonos jetzt sauber VLAN40 (`.191`/`.192` bound). (2) RouterOS-Script-`policy`-Feld per REST wählerisch → **weglassen** (admin-Default = volle Policy). (3) Disable-Regex mit `^…$`-Ankern griff nicht → `[find name!="ether1" and …]` nutzen. (4) REST-`PUT`-Antwort mit mehrzeiligem `source` ist kein sauberes JSON → ID separat via `?.proplist=.id` holen. (5) Claude-Code-Auto-Mode-Classifier blockt Device-Config-*Writes* per Bash (Reads ok) → `autoMode.allow`-Regel in `.claude/settings.local.json` nötig (kann Claude sich nicht selbst setzen).
|
||||
- **🔜 Als Nächstes (eigene Session, Übergabe): Core-Tausch = L3-Umzug** (Routing/DHCP/DNS/CF-Mesh von ap1 → crs326-core) — **Vollausfall-Fenster**, s. `docs/tp15-core-swap-session-handoff-prompt.md`. Danach WLAN-Neuprovisionierung (TP3, CAPsMAN-Abbau). Finaler Mgmt-Renumber dann: branch `.99.13`→`.99.12`, core bleibt `.99.11`.
|
||||
- 📦 **2× CRS326-24G-2S+RM werden morgen (2026-07-17) geliefert, Produktivsetzung spätestens Montag 2026-07-20 (User-Entscheid 2026-07-16).** Sequenzierung ggü. Nautobot geklärt: **TP20+TP21 werden bis dahin fast-getrackt** (TP18/Komodo als Blocker entfernt, s. TP20) — Ziel ist, dass Nautobot **vor** der CRS326-Produktivsetzung steht und die Switches **direkt als Nautobot-verwaltete Geräte adoptiert** werden, statt erst von Hand konfiguriert und später importiert. sw1/sw2-VLAN99-Umzug (TP19.1) läuft parallel dazu on-demand, unabhängig davon.
|
||||
- **🧭 Grundsatzentscheid (2026-07-14, korrigiert 2026-07-15): reines MikroTik-Ecosystem — Routing + Switching + WLAN.** **Omada bekommt KEINE Rolle** (weder Switching noch WLAN — der ursprüngliche „Omada=WLAN"-Satz war ein Fehlschluss beim Dokumentieren, User-Korrektur 2026-07-15: „WLAN war NIE von Omada die Rede"). Begründung Switching: Projektziel #1 **CAKE** nur RouterOS/OpenWrt/OPNsense (Omada-Gateway kann kein CAKE) → Switching = MikroTik CRS. WLAN bleibt auf hAP ax²/CAPsMAN (kein EAP-Kauf), Coverage-Fix bleibt Platzierungsfrage (TP3.3). Verworfene Vollvarianten (Omada-only, MikroTik-only) samt Begründung + Ansible/Nautobot-Recherche → Memory. **Anlass der Korrektur:** Omada-Controller↔sw2-Link beim VLAN20-Umzug (TP14.1) zerbrochen, versehentlicher Werks-Reset bei Rettungsversuch, fehlerhafter Wiederherstellungsversuch → sw2 wird standalone neu eingerichtet, s. **TP2.1**.
|
||||
- **🛒 Switches: 2× CRS326-24G-2S+RM bestellt (2026-07-14 — CSS326-Fehlbestellung storniert → CRS).** 24×1G + 2×SFP+, lüfterlos, DC-input (USV-tauglich). Lösen ALLNET-Core (sw1) + Omada-ES208G (sw2, s. TP2.1 — Solo/Interim bis CRS-Tausch) + Cudy ab.
|
||||
|
||||
92
docs/tp15-core-swap-session-handoff-prompt.md
Normal file
92
docs/tp15-core-swap-session-handoff-prompt.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# TP15 — Handoff-Prompt: Core-Tausch = L3-Umzug ap1 → crs326-core (neue Session)
|
||||
|
||||
> **Zweck:** Kopierfertiger Auftrag für eine frische Session, die `crs326-core` produktiv setzt:
|
||||
> sw1 (ALLNET) physisch ablösen **und gleichzeitig** Routing/DHCP/DNS von ap1 auf den CRS326 umziehen.
|
||||
> **Das ist ein geplantes Vollausfall-Ereignis** — nicht nebenbei, sondern mit Wartungsfenster.
|
||||
>
|
||||
> **Voraussetzung erfüllt (2026-07-23):** Branch-Tausch ist durch, `crs326-core` ist grundkonfiguriert und
|
||||
> erreichbar. Diese Session ist der zweite, riskantere Teil.
|
||||
>
|
||||
> **So übergibst du es:** Neue Session, erster Prompt:
|
||||
> „Lies `docs/tp15-core-swap-session-handoff-prompt.md` und arbeite den Auftrag darin ab."
|
||||
|
||||
--- PROMPT ---
|
||||
|
||||
```
|
||||
TP15 — Core-Tausch: crs326-core wird L3-Router (ersetzt sw1) + L3-Umzug von ap1.
|
||||
|
||||
‼️ DAS IST EIN VOLLAUSFALL ‼️
|
||||
An sw1 hängt auf #15 ap1 = Gateway/DHCP/DNS/WAN fürs GANZE Haus. sw1 zu tauschen UND L3 von ap1
|
||||
wegzuziehen ist EIN Ereignis. Während des Cutovers ist das komplette Netz offline, inklusive des
|
||||
eigenen Management-Pfads. Vorher: Wartungsfenster ansagen, Rettungspfad klären (Notebook-Zugang der
|
||||
NICHT über den zu tauschenden Kern läuft), Rollback-Plan bereitlegen (sw1 + ap1-Config bleiben bis
|
||||
zum Beweis unangetastet/zurückspielbar).
|
||||
|
||||
KONTEXT ZUERST LESEN:
|
||||
1. docs/teilprojekte.md — TP15 (As-built Bring-up/Branch-Tausch 2026-07-23), TP4 (ap1 heutige
|
||||
L3/DHCP/DNS/NAT-Config = die Vorlage, die umzieht), TP16.1 (CF-Mesh terminiert künftig auf core),
|
||||
TP5/TP6 (Firewall + CAKE landen auf core), TP3 (WLAN-Neuprovisionierung DANACH).
|
||||
2. CLAUDE.md — Hardware/Zugänge (crs326-core = 10.40.99.11 / VLAN1-Temp 10.40.41.211, admin/~/.secrets).
|
||||
3. nautobot/README.md — GraphQL-Verifikation. Nautobot hat core als "Planned" mit tentativem Layout.
|
||||
|
||||
IST-STAND core (aus dem Bring-up 2026-07-23):
|
||||
- crs326-core an sw1 #12, RouterOS 7.19.5, identity gesetzt, vlan-filtering=yes, volle Bridge-VLAN-
|
||||
Tabelle 1/10/20/30/40/50/90/99/100 (ether1 Uplink-Trunk, ether2 war Temp-Downlink zu branch).
|
||||
- Mgmt 10.40.99.11 (VLAN99) — erreichbar erst, wenn sw1 #12 VLAN99 tagged trägt (aktuell nur VLAN1);
|
||||
Arbeitskanal diese Session bisher = 10.40.41.211 (VLAN1) über sw1 #12 native.
|
||||
- NUR Switching. KEIN L3 (keine /ip address je VLAN außer Mgmt, kein DHCP, kein DNS, kein NAT).
|
||||
|
||||
ZIEL-LAYOUT core (User-Survey, "neu"-Vorgabe 2026-07-22 — VLAN99 pro Port noch am Gerät gegenprüfen):
|
||||
- #4 ap1-Uplink-Trunk (ap1 wandert von sw1 #15 auf core #4; ap1-seitig Uplink ether2→ether1/PoE-Port)
|
||||
- #2/#3/#5 Sonos VLAN40 untagged (+ die weiteren Sonos-/Hybrid-/pve-/sonoff-Ports aus der sw1-Survey,
|
||||
s. Nautobot sw1 GE1-16 Beschreibungen = die verifizierte Alt-Belegung, die auf core abgebildet wird)
|
||||
- #16 Arris → WAN VLAN100 (Access); der WAN-Trunk-Pfad zu ap1 entfällt, WAN terminiert künftig auf core
|
||||
- #8 → crs326-branch (Uplink zur OG-Branch)
|
||||
- Kapazität/Ports final beim Umstecken festklopfen.
|
||||
|
||||
WAS UMZIEHT (ap1 → core), Vorlage = ap1s heutige Config (TP4):
|
||||
- VLAN-Subinterfaces vlan10..vlan99 auf der core-Bridge + GW-IP .1 je VLAN.
|
||||
- DHCP-Server je VLAN (Pools .100-.200, GW+DNS = VLAN-GW) inkl. aller MAC-Reservierungen (Sonos, Shelly,
|
||||
NAS/macmini/pve statisch, Drucker …) — 1:1 von ap1 exportieren.
|
||||
- DNS-Resolver (allow-remote-requests, DoH-Upstream Cloudflare Gateway, 13 statische bf.lan-A-Records).
|
||||
- NAT srcnat masquerade out=vlan100 (Public-Edge wandert auf core).
|
||||
- Routing: Default via Liwest-GW auf vlan100; Connected-Routes je VLAN.
|
||||
- WAN-Input-Firewall-Seal (TP10) + später Deny-by-default (TP5) + CAKE (TP6).
|
||||
- CF-Mesh WG-Node (TP16.1) — NACH dem Cutover, eigener Schritt.
|
||||
|
||||
ABLAUF-EMPFEHLUNG (reversibel bauen, dann in EINEM Fenster cutovern):
|
||||
1. core L3 VORBEREITEN, solange ap1 noch Router ist: VLAN-Interfaces + IPs auf core anlegen, ABER die
|
||||
GW-IPs .1 NICHT doppelt aktiv fahren (IP-Konflikt mit ap1). Trick: DHCP/DNS auf core bauen aber
|
||||
disabled, VLAN-GW-IPs erst im Cutover-Moment aktivieren. Alternativ core-L3 komplett scripten und
|
||||
als ein Import-Block bereitlegen.
|
||||
2. sw1-Kabel-Umzugsplan festklopfen (welcher sw1-Port → welcher core-Port), ap1 #15→#4.
|
||||
3. CUTOVER-Fenster: ap1 als Router stilllegen (DHCP/DNS/NAT/VLAN-GW-IPs runter ODER ap1 direkt auf
|
||||
reinen AP zurückbauen), sw1-Kabel auf core umstecken, core-L3 aktivieren, WAN (Arris) auf core #16.
|
||||
4. Verifizieren: je VLAN DHCP-Lease + GW-Ping + Internet; DNS bf.lan; NAT; branch weiterhin über core;
|
||||
WARP/CF. Rollback = Kabel zurück auf sw1 + ap1-Config-Restore.
|
||||
5. ap1/ap2 werden reine APs → danach WLAN-Neuprovisionierung ohne CAPsMAN (TP3, eigene Session).
|
||||
|
||||
GOVERNANCE: Die Bring-up-Ausnahme #2 (2026-07-22) deckte NUR den Grundconfig-Bring-up. Für den
|
||||
produktiven L3-Umzug braucht es entweder Nautobot Golden Config (TP21) ODER eine neu zu erteilende
|
||||
Ausnahme (User fragen). Ergebnis danach als intended nach Nautobot zurückschreiben.
|
||||
|
||||
MGMT-RENUMBER (User-Vorgabe): nach Austausch BEIDER Switches erben die neuen die Alt-IPs —
|
||||
core bleibt 10.40.99.11, branch 10.40.99.13 → 10.40.99.12. VLAN1-Temp-IPs (.41.211/.41.213) entfernen.
|
||||
|
||||
NICHT ANFASSEN bis Cutover: die produktive branch-Config (läuft), die Lifeline-Ports.
|
||||
|
||||
ABNAHME: alle VLANs bekommen DHCP+GW+Internet über core; DNS/NAT/WAN auf core; branch + alle OG/UG-
|
||||
Geräte erreichbar im korrekten VLAN; ap1/ap2 reine APs; Nautobot bildet core produktiv ab (GraphQL).
|
||||
|
||||
DOKU (Pflicht): teilprojekte.md TP15/TP4 fortschreiben, CLAUDE.md/ip-plan.md (core produktiv, ap1 = AP),
|
||||
Nautobot nachziehen, Gotchas. Commit + Push (deutsch, Bullet, Co-Authored-By).
|
||||
```
|
||||
|
||||
--- ENDE PROMPT ---
|
||||
|
||||
## Was Christoph zur Session parat haben sollte
|
||||
- **Wartungsfenster** (komplettes Netz offline während des Cutovers).
|
||||
- **Rettungspfad**, der NICHT über sw1/ap1 läuft (z.B. Notebook direkt an core, oder Handy-Hotspot).
|
||||
- **Entscheidung Governance:** L3-Umzug via Nautobot GC (TP21) oder frische Direkt-Ausnahme.
|
||||
- **sw1-Port→core-Port-Umzugsplan** final (ap1 #15→#4, Arris #16, pve, sonoff, cudy1, Sonos …).
|
||||
- **DC-USV** (falls parallel geplant, TP15 HW-Teil).
|
||||
@@ -1,5 +1,9 @@
|
||||
# TP15 — Handoff-Prompt: CRS326-Bring-up + Branch-Tausch (neue Session)
|
||||
|
||||
> ✅ **ERLEDIGT am 2026-07-23** — beide CRS326 grundkonfiguriert, branch produktiv gegen sw2 getauscht,
|
||||
> Nautobot modelliert. As-built s. `docs/teilprojekte.md` TP15. **Nächster Schritt = Core-Tausch/L3-Umzug:
|
||||
> `docs/tp15-core-swap-session-handoff-prompt.md`.** (Dieses Dokument nur noch als Historie.)
|
||||
|
||||
> **Zweck:** Kopierfertiger Auftrag für eine frische Session, die die beiden CRS326 in Betrieb
|
||||
> nimmt und **crs326-branch** produktiv gegen sw2 tauscht. Der Core-Tausch (= gleichzeitig der
|
||||
> L3-Umzug) ist **bewusst NICHT** Teil dieses Auftrags.
|
||||
|
||||
Reference in New Issue
Block a user