bf-infra/memory/project_tp2_topology.md

name, description, metadata

name	description	metadata
project-tp2-topology	TP2 Omada Switch + Controller — IPs, Portplan, API-Zugang, Profile-Constraint, TP4 vorgezogen	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}