Initial import from bf-network-r6.opencode — opencode migration

memory/project_tp2_topology.md

@@ -0,0 +1,68 @@
+---
+name: project-tp2-topology
+description: TP2 Omada Switch + Controller — IPs, Portplan, API-Zugang, Profile-Constraint, TP4 vorgezogen
+metadata:
+  type: project
+---
+
+TP2 ✅ abgeschlossen 2026-06-15. Omada ES208G (sw2) adopted, VLANs + Port-Profile aktiv.
+Profile haben bekannten Fehler (PVID=1, untagNetworkIds-Chaos) — Fix nach TP4.
+
+**Finale IPs:**
+- omada-controller: 10.40.41.175 (DS923/macvlan, mbentley 6.2.10.17)
+- omada-mcp: 10.40.41.176 (pve-LXC endpointId=2, ipvlan, Stack 200)
+- pve-mcp: 10.40.41.173 (SSE)
+- sw2 (ES208G): 10.40.41.12 (adopted, FW 1.0.2 Build 20260329, MAC A8-29-48-EE-B9-04)
+
+**Controller-API (intern, v2) — für Writes:**
+- Login: POST `/{omadacId}/api/v2/login` mit JSON `{username, password}` → token
+- Requests: Header `Csrf-Token: <token>` (Cookie-Session wird mitgeführt)
+- Switches: GET `/sites/{siteId}/switches/{MAC}/ports` → alle 8 Ports inkl. VLAN-Config
+- Networks: GET `/sites/{siteId}/setting/lan/networks?currentPage=1&currentPageSize=20`
+- Creds: christoph@emsenhuber.com / in omada/.secrets NICHT gespeichert (nur Switch-Creds dort)
+
+**Omada Open API Gotcha (für MCP/Read):**
+- Token: POST /openapi/authorize/token?grant_type=client_credentials, JSON body: {client_id, client_secret, omadacId}
+- Auth-Header: `Authorization: AccessToken=<token>` (NICHT Bearer)
+- URL: `{base}/openapi/v1/{omadacId}/sites/{siteId}/...`
+- Port-Profile NICHT in Open API — nur in v2-intern oder Controller-UI
+
+**Omada-MCP Tools:**
+- 84 read-only Tools, OMADA_TOOL_CATEGORIES=all
+- Write NICHT im MCP — direkte v2-API oder Controller-UI .175:8043
+
+**Network-IDs (VLAN-Mapping):**
+- `6a2fe68fa33b9c62b13680f0` → Default (VLAN 1)
+- `6a300883a33b9c62b136950d` → MAIN (VLAN 10)
+- `6a3008a3a33b9c62b1369511` → INFRA (VLAN 20)
+- `6a3008c2a33b9c62b1369515` → IOT (VLAN 30)
+- `6a3008e1a33b9c62b1369519` → MEDIA (VLAN 40)
+- `6a300903a33b9c62b1369521` → UNTRUSTED (VLAN 50)
+- `6a30091ea33b9c62b1369525` → GUEST (VLAN 90)
+- `6a300939a33b9c62b136952b` → MGMT (VLAN 99)
+- `6a30097fa33b9c62b1369534` → WAN (VLAN 100)
+
+**Port-Plan ES208G (Stand 2026-06-15):**
+- P1 (uplink) → Trunk-ALL (6a300b5b…) → ALLNET GE8 ✅
+- P2 (ap2) → Trunk-ALL → hAP ax² #2 ✅
+- P3 (Port3) → Access-MAIN (6a300ba6…) — PVID=1 ⚠️, sicher zum Testen
+- P4 (dock/monitor) → Access-MAIN — PVID=1 ⚠️, **LIFELINE-PORT, nicht ändern**
+- P5 (drucker) → Access-MAIN — PVID=1 ⚠️, sicher zum Testen
+- P6 (Port6) → Access-MAIN — PVID=1 ⚠️, sicher zum Testen
+- P7 (macmini) → Access-INFRA (6a3015e6…) — PVID=1 ⚠️, **fixe IP, nicht ändern**
+- P8 (ds923+) → Access-MAIN — PVID=1 ⚠️, **NAS, nicht ändern**
+
+**Bekannte Fehler in Profilen (Analyse via v2-API):**
+- Access-MAIN: nativeNetworkId=VLAN1 (sollte 10), untagNetworkIds=[VLAN1, VLAN20, VLAN10] (sollte [VLAN10])
+- Access-INFRA: nativeNetworkId=VLAN1 (sollte 20), untagNetworkIds=[VLAN20, VLAN1] (sollte [VLAN20])
+- Folge: Geräte senden ungetaggt → VLAN 1, aber empfangen Traffic aus mehreren VLANs ungetaggt
+
+**PVID-Constraint (Kern-Blocker für Profile-Fix):**
+NAS, Mac mini, pve etc. haben fixe IPs in 10.40.41.x (VLAN-1-Range der FritzBox).
+Umbau auf PVID=10/20 bricht Konnektivität bis DHCP-Server auf diesen VLANs existiert (TP4).
+Fix: nach TP4 gemeinsam mit IP-Migration aller Infra-Geräte auf 10.40.10.x/10.40.20.x.
+
+**Why:** TP4 (Router-Cutover) ist vorgezogen — Blocker für Profiles und echte VLAN-Segmentierung.
+
+**How to apply:** Bei TP4: L3-Interfaces + DHCP-Server auf ap1 anlegen, DANN Omada-Profile korrigieren.
+Port-IDs für v2-API-Writes: /sites/6a2fe68e…/switches/A8-29-48-EE-B9-04/ports/{portId}