Christoph Emsenhuber
1006f91e6a
Der dritte Access-Point laeuft: 10.40.99.13 auf vlan99, Uplink ether1 -> core ether21, reiner CAP unter crs326-core, Kanaele 5180/ax/Ce/I und 2437/ax (ch6) -- am Geraet nachgemessen, nicht aus dem Plan abgeschrieben. Der Kanalplan stammt aus TP25 vom 2026-08-24; mein erster Entwurf hatte ihn neu erfunden und waere bei ch1 statt ch6 gelandet. Lehre: den TP-Body lesen, nicht nur den Quick-Index. ap1 hat bewusst KEINE Provisioning-Regel mehr: es steht bis zu seinem Umzug ans Sideboard direkt neben ap3 und wuerde auf 5180 kollidieren. Geraet bleibt erreichbar, die Objekte ch-*-ap1 / cfg-main-*-ap1 bleiben fuer den Umzug stehen. Bring-up in zwei Phasen ueber ein Patchkabel ap3 ether2 -> core ether22, weil ueber ether1 nichts ging (s.u.). Loop-Schutz: ether21 war waehrend Phase 1 abgeschaltet und wurde im selben Befehl gegen ether22 getauscht. RouterOS 7.20.8 -> 7.24.1 plus RouterBOOT (zwei Reboots, TP27-Kriterium erfuellt). Die anderen vier stehen auf 7.24 -- die Angleichung ist ein eigener Durchgang, der Core-Reboot ist ein Standort-Ausfall. Nautobot: DeviceType "cAP ax", Device ap3 mit 16 Interfaces, primary_ip4, secrets_group, ConfigContext 5g=ch36 2g=ch6 extra_ports=[]. Nebenkorrektur: ap1 stand auf "Wohnzimmer Sideboard", steht physisch aber in Technik UG (User-Bestaetigung). Sechs Funde, alle als Gotcha in CLAUDE.md und im Handoff: - ether1 ist am Werksgeraet WAN: Discovery aus, Input-TCP verworfen, ICMP aber erlaubt. Es pingt, und das liest sich wie "erreichbar". MikroMCP hilft nicht -- Port 80 ist zu. - pvid ist Ingress, tagged/untagged ist Egress. Ein Lease hing ewig auf "offered", weil der ACK getaggt rausging und ein Werksgeraet das nicht versteht. - `cap enabled=yes` reicht nicht: jedes Master-Radio braucht configuration.manager=capsman, sonst bietet der CAP seine Radios gar nicht an -- state=Ok, radio-Tabelle leer. - Ein Geraet ohne secrets_group erzeugt eine LUECKE, keine Fehlermeldung: Backup scheitert still, keine Compliance-Eintraege, Zahl bleibt unauffaellig bei 104/104. Eine gleichbleibende Compliance-Zahl nach dem Hinzufuegen eines Geraets ist ein BEFUND. - CAPsMAN verteilt keine Login-Passwoerter, nur WLAN-PSKs. Der Geraete-Login ist eine lokale DB pro Geraet; das einheitliche Admin-PW ist eine Konvention von Hand. - Firewall-Regelnummern aus `print where` sind Handles, keine Positionen. Beweis ist der Zaehler, nicht die Zahl. Abnahme: 3 CAPs state=Ok, VAP-Satz vollstaendig und running, 20 IOT-Clients auf ap3 mit 0 % Ping-Verlust ueber VLAN30 (bewusst nicht ueber die Registration-Table abgenommen), Compliance 130/130 / 0 Drifts, Core-Temp-Pfad restlos abgeraeumt. Offen: TP25-Messrunde (braucht Rundgang), PW-Rotation TP30, MikroMCP-Neustart. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
hAP ax² Setup — CAPsMAN + VLAN (Design & Plan, REVIEW vor Apply)
Stand: beide auf RouterOS 7.23.1 + RouterBOOT 7.23.1. Namen/IPs gesetzt: ap1 = 10.40.41.1 (künftiges Gateway/Router) · ap2 = 10.40.41.2 (CAP). Default-Bridge (ether2–5+wifi, vlan-filtering aus).
⚠️ Status: NUR PLAN. An den Geräten bisher nur: Firmware 7.23.1, Identity ap1/ap2, Stray-IP weg, Mgmt-IP→.1/.2. Exakte 7.23-Syntax (wifi/capsman/provisioning/scheduler) wird vor Apply gegen das Gerät validiert.
Hardware-Realität
- WiFi 6 (ax), dual-band 2,4+5 GHz. MLO ist NICHT verfügbar (MLO = WiFi 7/802.11be → bräuchte hAP be³). „MLO wenn möglich" entfällt.
Rollen
- ap1 = CAPsMAN-Manager + AP (später zusätzlich Router — L3/DHCP/DNS/NAT/CAKE = separater Cutover, NICHT hier).
- ap2 = CAP (zieht Wireless-Config von ap1 @ 10.40.41.1).
⚠️ Topologie / Verkabelung (Klärungsbedarf)
- ap1 → Core-Switch Port 2 (direkt). ✓ Guter Trunk-Kandidat.
- ap2 → hinter TP-Link TL-SG108E → Core-Switch Port 8. Damit ap2 die VLANs getaggt bekommt, müsste auch der TP-Link trunken (kann 802.1Q, aber fummelige UI). Empfehlung: ap2 im Wartungsfenster direkt an einen freien Core-Port (z.B. Port 3) → sauberer Trunk, keine TP-Link-VLAN-Config.
- ether1 = WAN — Achtung: Für ap1 (Router) ist ether1 = WAN zur FB (Internet); der LAN-Trunk zum Core bleibt ether2 → ap1 braucht 2 Kabel. Für ap2 (reiner AP) gibt es kein WAN; ein Uplink (Trunk) genügt. → Den LAN-Trunk auf ether1 zu legen wäre für den Router falsch. Finale Verkabelung bitte bestätigen.
Bridge-VLAN-Layout (beide APs)
- Uplink ether2 = Trunk: tagged
10,20,30,40,90,99,100+ native/untagged vlan1 (= aktuelles Mgmt-Netz, .1/.2). - Mgmt bleibt erreichbar (untagged vlan1), solange der Switch-Port native vlan1 untagged bleibt.
vlan-filtering=yeszuletzt — mit Auto-Rollback (5 min) gegen Lockout.
WLAN (SSID → VLAN via CAPsMAN-Datapath)
| SSID | VLAN | Security |
|---|---|---|
BF-Main |
10 (MAIN) | WPA3-only |
BF-IoT |
30 (IOT) | WPA2/WPA3-PSK |
BF-Guest |
90 (GUEST) | WPA2/WPA3-PSK |
Beide Bänder (2,4+5 GHz ax). Temp-Passphrase (Platzhalter BFtest-2026-tmp) — User setzt echte in Ruhe. |
VLAN-SSIDs bekommen erst nach dem Router-Cutover DHCP/Gateway. Sofort-Test optional via Temp-SSID auf native vlan1 (FB-DHCP).
Apply-Reihenfolge (wenn freigegeben)
- Switch: AP-Uplink-Port(s) → Trunk (tagged 10,20,30,40,90,99,100 + native vlan1). [ap2 erst sinnvoll, wenn direkt am Core ODER TP-Link trunkt]
- ap1: Bridge-VLAN → CAPsMAN-Manager → (Auto-Rollback) vlan-filtering=yes.
- ap2: Bridge-VLAN → CAP enable (manager=10.40.41.1).
- Verifizieren: ap2 im Manager; SSIDs auf beiden Radios; Mgmt erreichbar. Rollback canceln.
Safety — Auto-Rollback
/system scheduler add name=vlan-rollback interval=5m \
on-event="/interface bridge set [find name=bridge] vlan-filtering=no; /system scheduler remove vlan-rollback"
Offene Punkte (User)
- Finale Verkabelung bestätigen (ap1: ether1→FB-WAN, ether2→Core-Trunk; ap2: direkt an Core vs. TP-Link trunken).
- Switch-Mgmt-IP:
.3oder.239(da.2jetzt = ap2). - Echte WLAN-Passphrasen (später).
Dateien
routeros/ap1-manager.rsc·routeros/ap2-cap.rsc