admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b595c75eefb6c95f59219997c5168192867494cd
bf-infra/CLAUDE.md
Christoph Emsenhuber b595c75eef TP15: CRS326-Bring-up (core+branch) + Branch-Tausch gegen sw2 durch 
- Beide CRS326 grundkonfiguriert via REST (Governance-Ausnahme #2): core-zuerst
  als L2-Pfad, Zugriff auf Werks-.88.1 über temporäre ap1-.88.2+Masquerade
  (nach Bring-up entfernt). Winbox-MAC scheiterte (sync-timeout).
- branch produktiv, volle SOLL-Portbelegung (ether1 Uplink→sw1#8, 2/8 NAS-20T,
  3 Drucker/4 Dock VLAN10, 5/6 Sonos VLAN40, 7 macmini VLAN20, 24 ap2), mgmt
  .99.13; core grundkonfiguriert nicht produktiv (mgmt .99.11, an sw1#12).
- Branch-Tausch: sw2 physisch raus, Lifelines auf branch; Abnahme grün (NAS/
  macmini VLAN20, Dock VLAN10, Sonos VLAN40). Gotcha: ether3/5-Kabel vertauscht
  (Sonos-VLAN10-Leck/Dual-Homing) → gefixt.
- Nautobot modelliert + GraphQL-verifiziert (nautobot/ingest-crs326-ports.py):
  branch Active + Ports, core Planned + tentativ, sw1 verifizierte 16-Port-
  Belegung (löst UNVERIFIZIERT), sw2 Decommissioning.
- CRS326 in MikroMCP routers.yaml; Creds in ~/.secrets. Doku (teilprojekte/
  CLAUDE/ip-plan) nachgezogen; Core-Swap-Handoff-Prompt neu.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-23 16:20:26 +02:00

76 lines
9.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# BF-Netzwerk — Projekt-Kontext (auto-read)
**Standort BF:** VLAN-segmentiertes Heimnetz auf MikroTik/RouterOS. Ziel: CAKE/QoS gegen Bufferbloat,
DNS/DHCP-Ablösung, WLAN via CAPsMAN, Firewall Least-Privilege, Multi-Site VPN.
**Für jede TP-Session: zuerst `docs/teilprojekte.md` lesen** — enthält kanonischen Stand, Scope, Abhängigkeiten
und Reihenfolge aller Teilprojekte. Kein anderer Kontext nötig.
---
## VLAN-Modell (kanonisch)
| VLAN | Name | Subnetz | Zweck |
|---|---|---|---|
| 10 | MAIN | 10.40.10.0/24 | Trusted (Handy/Laptop) |
| 20 | INFRA | 10.40.20.0/24 | NAS/VMs/Docker/HA |
| 30 | IOT | 10.40.30.0/24 | Smart-Home |
| 40 | MEDIA | 10.40.40.0/24 | Sonos/AppleTV/TV/Cast |
| 50 | UNTRUSTED | 10.40.50.0/24 | Konsole/Low-Trust |
| 90 | GUEST | 10.40.90.0/24 | nur Internet |
| 99 | MGMT | 10.40.99.0/24 | Switch/AP/Hypervisor-Mgmt |
| 100 | WAN | (Arris-Transfer) | zum Arris-Kabelmodem (Liwest, Public-IP) |
GW je VLAN = `.1` · APs: ap1=`.1`, ap2=`.2` · Switches: ALLNET=`.11`, Omada=`.12`
---
## Hardware & Zugang
| Gerät | IP | Zugang |
|---|---|---|
| ALLNET Core-Switch (sw1) | 10.40.41.11 (interim, VLAN1) | `telnet 10.40.41.11` · User: `claudecode` · PW: `switch/.secrets` |
| ~~Omada Access-Switch (sw2)~~ | — | ❌ **abgebaut 2026-07-23** (TP15 Branch-Tausch) — durch `crs326-branch` in Technik OG ersetzt, physisch entfernt |
| **crs326-branch** (CRS326, Technik OG) | **10.40.99.13** (VLAN99, über sw1 #8) · VLAN1-Temp `.41.213` | RouterOS 7.19.5 · `admin`/`~/.secrets` (`CRS326_BRANCH_*`) · REST `http://10.40.99.13/rest` · MikroMCP `routers.yaml` (live nach MCP-Neustart) · **TP15 ✅ 2026-07-23: ersetzt sw2**, volle Portbelegung (ether1 Uplink→sw1#8, 2/8 NAS, 3 Drucker, 4 Dock, 5/6 Sonos, 7 macmini, 24 ap2) · sw-id RGZJ-UK0T, MAC 04:F4:1C:B4:15:58 |
| **crs326-core** (CRS326, Technik UG) | **10.40.99.11** (VLAN99, erreichbar erst wenn sw1#12 99T trägt) · VLAN1-Temp `.41.211` (an sw1 #12) | RouterOS 7.19.5 · `admin`/`~/.secrets` (`CRS326_CORE_*`) · REST `http://10.40.41.211/rest` · **TP15 ✅ 2026-07-23 grundkonfiguriert, NICHT produktiv** — wird Core/L3-Router (ersetzt sw1) in eigener Session · sw-id 4W04-URHT, MAC 04:F4:1C:B4:17:76 |
| hAP ax² #1 (ap1) | 10.40.10.1 (Mgmt-Zugriff) · `platform-pg.bf.lan`-artige DNS-Statics unter `bf.lan` | MikroMCP (live) · **TP4 ✅: L3-Router, GW je VLAN = .1**, vlan99-GW `10.40.99.1` seit TP4 live |
| hAP ax² #2 (ap2) | 10.40.41.2 (VLAN1, TP19.1-Umzug auf `.99.2` vertagt bis TP21/Nautobot) | MikroMCP (live) · **Port 2 am Omada-Switch** |
| NAS (nas-bf, DS923) | 10.40.20.10 | SSH `adm.christoph@10.40.20.10` (kein PW nötig) · Docker (Portainer endpointId=14) |
| platform-pg (LXC 105, pve) | 10.40.20.20 | SSH via pve (`pct exec 105 --`) · **TP20 ✅ 2026-07-16: PG16, DB `nautobot`, Creds `postgres/.secrets`** |
| Nautobot (Portainer-Stack, NAS) | 10.40.20.30 | Portainer ep14, Stack Id 203 · **TP21 ✅ 2026-07-16: `ghcr.io/nautobot/nautobot:3.1.7`, DB=platform-pg, Creds in `docs/nas-vlan20/stacks/210-nautobot.yml` (gitignored)** — Golden-Config-App/Device-Adoption noch offen |
| ~~Omada-Controller~~ | — | ❌ **entfernt 2026-07-16** (User hat den Container gelöscht — overkill für 1 Switch auf der Abschussliste, s. TP2.1/TP15) |
| ~~omada-mcp~~ | — | ❌ **entfernt 2026-07-16** — mit dem Controller gelöscht. MCP-Eintrag in Claude-Settings/`~/.claude.json` ist verwaist (Server wird nie mehr connecten), Aufräumen dort noch offen |
| pve-mcp | 10.40.20.173 | **StreamableHTTP `http://10.40.20.173:3000/` (Root-Pfad, NICHT /sse)** · NAS-Stack ep14 (=nas-bf `.20.10`, NICHT LXC .126!) id 202 (vlan20-only, TP14.1 2026-07-10) · **mcp-pve v0.6.1 (Upgrade 2026-07-10: Single-Session-Bug 0.4.8 „Server already initialized" gefixt, TP14.2a)** · `~/.claude.json` ✓ |
| Proxmox (pve) | 10.40.20.100 | `ssh root@10.40.20.100` (SSH-Key ✓) · **TP14 2026-07-13: Host-Mgmt VLAN1→VLAN20** (vmbr0.20 + Default-GW-Flip); `.41.100` bleibt interim ohne Route |
| Docker-LXC (auf pve) | 10.40.20.126 | Portainer CE 2.40.0 (`https://10.40.20.126:9443`) · **TP14.2 2026-07-10: LXC 400 net0 tag=20/.20.126 (iface heißt jetzt `veth20`, NICHT eth0); Docker-Netz `vlan20`=ipvlan parent `veth20`; adguard_bf1 .20.16, adguard_fm2 .20.17** |
| Mac mini | 10.40.41.167 | `ssh macmini` |
| Arris-Kabelmodem | (Bridge-Mode, keine Mgmt-IP im BF-LAN) | Liwest-Edge, physisch an sw1 gi16 · **FritzBox 6660 seit 2026-07-01 komplett ausgebaut** (Liwest-Tausch, kein Zurück); Telefonie war auf der FB und wird nicht weitergeführt |
---
## Tooling
- **MikroTik (hAP ax²):** MikroMCP-Server live verbunden → `mcp__mikromcp__*`-Tools verwenden.
Reads immer safe; Writes mit `dryRun:true` previwen, dann `apply_plan`.
- **ALLNET-Switch:** kein MCP — nur Telnet-CLI (IOS-artig, FW 2.2.1). Runner:
`cd ~/dev/bf-network-r6/switch && . ./.secrets && expect cli/run-cli.exp cli/<datei>.cli`
Klickanleitungen in `switch/ui-guides/` für manuelle Schritte.
- **Omada-Switch (sw2):** seit TP2.1 (2026-07-16) **standalone ohne Controller**, direkt über eigenes Web-UI konfiguriert. Der Controller ist mittlerweile **komplett gelöscht** (User 2026-07-16, overkill für 1 Switch auf der Abschussliste) — Omada-Ecosystem hat generell keine Rolle mehr im Netz (TP15-Korrektur). **omada-mcp ebenfalls gelöscht**, MCP-Registrierung in Claude-Settings ist verwaist.
- **Docker-Management:** Portainer API `https://10.40.20.126:9443`, Key in `mcp/portainer/.env`.
Ablösung durch Komodo (native MCP) geplant.
---
## Kritische Gotchas
- **ALLNET: nur 1 Telnet-VTY** — stale Sessions blockieren ~15 min. Sauber ausloggen (`exit exit`), nie hammern.
- **`save` nicht vergessen** nach ALLNET-Änderungen (sonst nach Reboot weg).
- **hAP ax² hat 128 MB Flash, kein USB** → Container NICHT auf dem Router; Container laufen auf NAS/pve.
- **VLAN20-Docker-Hosts: Host-DNS nach dem Umzug prüfen (2026-07-10, TP14.2a):** NAS + pve-LXC zeigten `/etc/resolv.conf` noch auf totes `.41.254` → `docker pull` ghcr scheitert (`EAI_AGAIN`, aber Egress ok!). Fix = `.20.1`: LXC `pct set 400 --nameserver 10.40.20.1`; **Synology-Falle: DSM-„Allgemein"-DNS ≠ was `dockerd` liest** — Interface zieht DNS per DHCP → Fix an der *Netzwerkschnittstelle* „DNS manuell". Laufende Container frieren den `127.0.0.11`-Upstream zum Erstellzeitpunkt ein (Recreate nötig). Merkregel: `docker-pull-hängt` + `dns.lookup EAI_AGAIN` aber `TCP zu ghcr-IP:443 ok` = toter Resolver, nicht Egress.
- **ALLNET VLAN-DB final (TP1 ✅):** 40=MEDIA, 50=UNTRUSTED; GE1/GE2/GE8 alle als Trunk mit 10/20/30/40/50/90/99/100.
- **Omada-Switch Port 2 = ap2** (Trunk all VLANs), Uplink-Port → ALLNET GE8 (Trunk all), Restports = Access.
- **Mesh = NEIN** (beide APs haben wired Trunk-Uplink → Loop-Risiko).
- **ap2 (CAP) braucht `vlan-filtering=yes` mit ether2-Trunk (TP3.1 ✅ 2026-07-01):** local forwarding → `datapath.vlan-id` wird nur bei vlan-filtering auf die Leitung geschrieben. Ohne → ALLE ap2-WLAN-Clients ungetaggt in VLAN1 (defconf/10.40.41.x). Nur Master-Radios wifi1/wifi2 sind Bridge-Ports (Slave-VAPs forwarden darüber) → wifi1/wifi2 müssen manuell tagged-Member je Client-VLAN sein (CAPsMAN legt das auf dem CAP NICHT an). As-built `routeros/tp3.1-ap2-vlan.rsc`. VLAN1 MUSS untagged=bridge,ether2 bleiben (Mgmt/MCP-Pfad 10.40.41.2, kein Scheduler → Recovery = Power-Cycle OG). Widerlegt „ein CAP hält keine Config" (galt nur für Manager-Forwarding).
- mgmt-VLAN-Wechsel am Switch = Lockout-Risiko: VLAN muss existieren + Port muss es tragen, in einem Schritt.
- **Omada ES208G = Easy Managed** → Controller-adoptierbar (ab 6.1.x), nur Basis-VLAN/QoS im Controller (kein ACL/Policy-Routing).
- **TP4 ✅: ap1 ist L3-Router.** Bridge mit vlan-filtering=yes; VLAN1 untagged (Mgmt/Transition); vlan10-99 Subinterfaces mit DHCP+DNS. DNS: 13 statische A-Records bf.lan, **Upstream seit 2026-06-16 = DoH Cloudflare Gateway** (servers=1.1.1.1 Bootstrap). Omada-PVID-Fix (→ .10/.20-Subnetze) ist nächster Schritt.
- **✅✅ Edge-Cutover vollzogen (2026-07-01): FritzBox komplett ausgebaut, Arris-Kabelmodem im Bridge-Mode.** Liwest hat die FB6660 dauerhaft gegen ein Arris-Kabelmodem getauscht (physisch weg, kein Zurück). WAN läuft über den Core-Switch (Arris→sw1 gi16 Access VLAN100→gi15 Trunk→ap1 ether2→`vlan100` auf bridge), NICHT über ether1. ap1 zieht öffentliche Liwest-IP direkt → Double-NAT weg, ap1 = Public-Edge. Vorarbeit dazu: TP10 (beide VPN FM/DW von FB auf ap1-WG-Hub migriert, 2026-06-27) hat den Bridge-Mode entblockt. Telefonie war auf der FB und wird **nicht weitergeführt** (User-Bestätigung 2026-07-02). Details/Runbooks: `routeros/wan-cutover-runbook.md`.
- **ap1 RouterOS-Scripting (device-mode=home):** **scheduler + fetch blockiert** (`not allowed by device-mode`) → keine Scheduler in Scripts, Autonomie via Loop-Script. **`[/ping]` gibt nil in 7.23**, ICMP geblockt → Reachability via `:resolve` (server=1.1.1.1 = Routing-Test, ohne server = DoH). MikroMCP-Tools können droppen → Fallback REST `http://10.40.41.1/rest` (Creds = ROUTER_AP1 in `~/.claude.json`).
- **WLAN dozende Legacy-Clients nur auf ap1 erreichbar, NICHT via CAP ap2 (2026-07-02, P750W-Fall):** L3-GW liegt auf ap1 → ARP-Broadcast an schlafenden Client wird nur am co-located AP zuverlässig zugestellt; Remote-CAP ap2 puffert Broadcast-ARP unzuverlässig. Fix = geordneter wifi-access-list-Pin auf ap1 (`0 accept interface=w2-iot` → `1 reject` ohne Interface = überlebt ap2-Re-Provision). **Merkregel: DHCP-geht-aber-Ping-nicht = ARP/Power-Save, NICHT Routing/L2/MTU/Switch.** Coverage-Kanten/Terrasse grenzwertig (−76..−89 dBm, 4-Radio-Ping-Pong); TX schon am AT-Max (18/15 dBm, kein Hebel); Steering `neighbor-group=bf-main` gesetzt; echter Fix = Platzierung (offen, Tageslicht). SSoT `docs/wifi-p750w-coverage-and-map.md`.
Reference in New Issue View Git Blame Copy Permalink