---
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}