bf-infra/docs/tp15-crs326-session-handoff-prompt.md

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.

Empfohlenes Modell: Opus. Nicht wegen der Befehle — die sind Standard-RouterOS — sondern weil in der Session laufend zwischen „Ist-Zustand am Gerät", „Modell in Nautobot" und „Zielbild" abgeglichen werden muss und die sw1-Belegung nur teilweise verifiziert ist.

So übergibst du es: Neue Session öffnen, als ersten Prompt schicken: „Lies docs/tp15-crs326-session-handoff-prompt.md und arbeite den Auftrag darin ab."

--- PROMPT ---

TP15 — CRS326 in Betrieb nehmen: beide grundkonfigurieren, Portplan in Nautobot
modellieren, danach NUR crs326-branch produktiv gegen sw2 tauschen.

KONTEXT ZUERST LESEN (in dieser Reihenfolge):
1. docs/teilprojekte.md — TP15 (Hardware/Standorte/Portfakten/Risiko), TP21 (Nautobot-Stand),
   TP3 (WLAN-Neuaufbau ohne CAPsMAN) + die beiden Governance-Callouts im Kopfbereich.
2. CLAUDE.md (Projekt) — Hardware/Zugänge/Gotchas.
3. nautobot/README.md — die Nautobot-API-Fallen. NICHT überspringen: `tagged_vlans` liest
   sich per REST als `null`, OBWOHL korrekt gespeichert. Wer das nicht weiß, sucht eine
   Stunde einen Fehler, den es nicht gibt. Verifikation immer per GraphQL.
4. docs/tp16.1-warp-mesh-native-crs326.md — was später auf dem Core terminieren soll.

ZIEL DIESER SESSION (Scope-Grenze hart einhalten):
 (a) beide CRS326 grundkonfigurieren (Mgmt-IP, Bridge, vlan-filtering, Trunks/Access),
 (b) den Portplan beider Switches in Nautobot modellieren,
 (c) crs326-branch physisch gegen sw2 tauschen (Technik OG).
NICHT in dieser Session: crs326-core produktiv setzen, L3-Umzug (Routing/DHCP/DNS von ap1),
CAPsMAN-Abbau, ap2-Neuprovisionierung. Das sind eigene, spätere Sessions.

‼️ WARUM DER CORE TABU IST — DAS IST KEINE VORSICHT, DAS IST DIE TOPOLOGIE ‼️
crs326-core ersetzt sw1 UND wird der neue L3-Router. An sw1 hängt auf Port 15 ap1 — also
Gateway, DHCP, DNS und der WAN-Trunk fürs GESAMTE Netz. Wer sw1 anfasst, nimmt das ganze
Haus offline, inklusive des eigenen Management-Pfads. Core-Tausch und L3-Umzug sind faktisch
dasselbe Ereignis und brauchen ein geplantes Ausfallfenster. Deshalb: Branch zuerst.

GOVERNANCE — AUSNAHME BEREITS ERTEILT (Christoph, 2026-07-22):
Die Regel "Config ausschließlich über Nautobot" gilt weiter, ABER für den CRS326-BRING-UP
hat Christoph eine Ausnahme erteilt: Mgmt-IP, Bridge, VLAN-Filtering, Trunks/Access-Ports
dürfen direkt via MikroMCP/Winbox gesetzt werden (Henne-Ei: GC kann nicht auf ein Gerät ohne
erreichbare IP pushen, und die GC-Templates existieren noch nicht).
AUFLAGE: den entstandenen Ist-Stand danach als intended config nach Nautobot zurückschreiben.
Die Ausnahme deckt das Bootstrapping, NICHT den Dauerbetrieb, und gilt NICHT für ap1/ap2.

GERÄTE-IDENTITÄT (beide sind bereits am Netz, RouterOS 7.19.5, Werkszustand):
  crs326-core   = MAC 04:F4:1C:B4:17:76, software-id 4W04-URHT
  crs326-branch = MAC 04:F4:1C:B4:15:58, software-id RGZJ-UK0T
⚠️ BEIDE hören auf die Werks-IP 192.168.88.1 im SELBEN L2-Segment = IP-Konflikt.
   Immer nur eines nach dem anderen adressieren; Unterscheidung ausschließlich per MAC
   (MAC-Telnet/Winbox-Neighbor). Christoph hat die Geräte griffbereit neben sich, der
   Erstzugriff ist deshalb unkritisch — kein Lockout-Szenario, notfalls physisch.
⚠️ crs326-branch ist BEREITS PHYSISCH INLINE: ap2 hängt an dessen Port 24 (deshalb war es
   überhaupt per MNDP von ap1 aus sichtbar). Das ist kein Greenfield-Einbau.

ZIELBILD BRANCH = die heutige sw2-Belegung (aus TP2) 1:1 übernehmen:
  P1 Uplink-Trunk (→ sw1 gi8) | P2 ap2 | P3 frei | P4 Dock/Monitor | P5 Drucker
  P6 frei | P7 Mac mini | P8 NAS (2. Port)
  ⚠️ P4/P7/P8 sind in TP2 ausdrücklich als "nicht anfassen" markiert (fixe IPs, Lifeline).
  VLANs laut kanonischem Modell: Uplink+ap2 = Trunk all; Rest Access auf dem jeweiligen VLAN.

CONNECTIVITY — VOR DEM KABELZIEHEN LESEN:
Christophs Notebook hängt aktuell NUR per WLAN über cudy1, und cudy1 hängt am CORE (Port 11).
Der kabelgebundene Plan B (Dock/Monitor im Arbeitszimmer) hängt am sw2/BRANCH (P4).
Beim Branch-Tausch stirbt also der Kabelweg, das WLAN über cudy1 überlebt — die Pfade liegen
günstig auf verschiedenen Switches. Trotzdem: vor dem Ziehen von sw2 ansagen.

WAS VERIFIZIERT IST UND WAS NICHT (nicht raten, nicht als Fakt ausgeben):
  ✅ sw1 #15 = ap1, sw1 #11 = cudy1 (von Christoph bestätigt 2026-07-22)
  ⚠️ sw1 gi16 (Arris/VLAN100) und gi8 (Trunk → sw2) stammen aus der Doku, sind NICHT am
     Gerät gelesen — in Nautobot als "UNVERIFIZIERT" markiert. Falls für den Branch-Uplink
     relevant: von Christoph bestätigen lassen, er macht sw1 ohnehin selbst.
  ❌ switch/cli/03-trunk-ap-ports.cli (gi1 = ap1) ist STALE — vom Edge-Cutover 2026-07-01
     überholt. Nicht als Quelle verwenden.
  ❌ switch/state-backups/sw1-running-config-*.txt sind 214-Byte-Fehlschläge (toter
     claudecode-Login), switch/cli/running-PRE.txt ist Pre-TP1.

NAUTOBOT (SoT, http://10.40.20.30:8080):
  Token: NAUTOBOT_SUPERUSER_API_TOKEN in docs/nas-vlan20/stacks/210-nautobot.yml (gitignored).
  Bereits gepflegt: 8 Devices mit Bereich/Rolle/Platform, 9 VLANs, 8 Prefixes, ap1 vollständig
  (26 Interfaces + IPs), 6 SSIDs mit VLAN-Bindung, sw1 gi8/gi11/gi15/gi16, crs326-core ether4.
  Wiederverwenden: nautobot/ingest-baseline.py (idempotentes goc()/patch()-Muster) —
  nicht neu erfinden. Neue Ports als Interfaces am jeweiligen Device anlegen.

ROUTEROS-FAKTEN, DIE ZEIT SPAREN:
- Interface-Nummerierung beginnt bei 1 (ether1…ether24). Es gibt KEIN ether0.
- hAP ax²: PoE-Port ist ether1, aber PASSIV 18–28 V, NICHT 802.3af/at. Der CRS326 hat gar
  kein PoE → Strom käme aus einem Inline-Injektor. ether1 am hAP steht auf poe-out=auto-on;
  wenn ether1 künftig der versorgte Uplink wird, muss poe-out dort auf off.
  (PoE ist laut Christoph "vorerst kein Thema", die Config soll es nur vorsehen.)
- MikroMCP kennt in routers.yaml nur ap1/ap2 → die CRS326 dort ergänzen, sonst kein
  MCP-Zugriff. Writes immer erst dryRun/plan_changes, dann apply_plan.

NICHT ANFASSEN:
- ap1-Config (der CAPsMAN-Abbau kommt erst NACH dem Core-Tausch, s. TP3).
- ap2 (aktuell unerreichbar, meldet 10.40.40.2 = falsches VLAN; wird ohnehin neu
  provisioniert — nicht diagnostizieren, nicht reparieren).
- sw1 (Christoph macht sw1 selbst; siehe Feedback-Memory).

ABNAHME:
- Beide CRS326 unter ihrer neuen Mgmt-IP erreichbar, per MAC eindeutig zugeordnet, IP-Konflikt
  aufgelöst.
- Nach dem Branch-Tausch: ap2-Port, Dock/Monitor, Drucker, Mac mini und NAS wieder erreichbar;
  jeder in seinem korrekten VLAN (nicht ungetaggt in VLAN1 — das ist die Fehlerklasse, die
  dieses Projekt seit Wochen verfolgt).
- Nautobot bildet die tatsächliche Portbelegung ab; Verifikation per GraphQL, nicht REST.

DOKU (Pflicht am Ende): teilprojekte.md TP15 fortschreiben (As-built Portplan, was tatsächlich
lief/nicht lief), Nautobot-Stand nachziehen, Gotchas festhalten. Danach committen + pushen
(Commit-Msg-Konvention siehe git log: deutsch, Bullet-Struktur, Co-Authored-By).

--- ENDE PROMPT ---

Was Christoph zur Session parat haben sollte

• Beide CRS326 griffbereit (Erstzugriff/IP-Konflikt wird physisch aufgelöst).
• Bestätigung der sw1-Ports gi16 und gi8, falls der Branch-Uplink daran hängt — aktuell nur aus der Doku, nicht vom Gerät gelesen.
• Zeitfenster für den sw2-Ausfall (Dock/Monitor, Drucker, Mac mini, NAS-2. Port sind währenddessen weg; WLAN über cudy1 bleibt).
• Klarheit, ob der NAS-2.-Port (sw2 P8) und der Mac mini (P7) während des Tauschs ausfallen dürfen — beide sind in TP2 als „nicht anfassen" markiert.