Christoph Emsenhuber
f0c08263dd
Analyse via Omada Controller v2-API (2026-06-15):
- Access-Profile haben PVID=1 statt 10/20 (Constraint: fixe IPs in 10.40.41.x)
- Access-MAIN hat untagNetworkIds=[VLAN1,VLAN10,VLAN20] — bekannter Fehler, Fix nach TP4
- P4 (dock/monitor) → Access-MAIN (Lifeline-Port, nicht anfassen)
- P3/P5/P6 sicher zum Testen, P7/P8 eingefroren
- Network-IDs + v2-API-Pfade dokumentiert (Ctrl-API: Csrf-Token, /switches/{MAC}/ports)
- TP4 vorgezogen: blockiert Profile-Fix + echte VLAN-Segmentierung
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.6 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| project-tp2-topology | TP2 Omada Switch + Controller — IPs, Portplan, API-Zugang, Profile-Constraint, TP4 vorgezogen |
|
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/loginmit 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¤tPageSize=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}