admin/bf-infra
1
0
Fork 0
Code Issues 21 Pull Requests Actions Packages Projects Releases Wiki Activity
29 Commits 5 Branches 0 Tags
919f8623c9c614b2ba73b886823e74af1e031280
Commit Graph

29 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Christoph Emsenhuber
919f8623c9 TP10 🎯 Root Cause FM-NAT gefunden: FB braucht LAN-IP als WG-Address (Proxy-ARP) 
Echt-Host-Test (Ping realer 10.101.0.10 über WG) -> Antwort aus 10.255.255.2
=> FB masqueradet den Tunnel, bestätigt. Ursache: .conf nutzte Transfernetz-
Adresse (10.255.255.2/32) -> FRITZ!OS = Einzelgerät-Modus = NAT. AVM nutzt
Proxy-ARP statt Transfernetz -> FB-WG-Interface-Address muss die FB-LAN-IP sein
(FM 10.101.0.254/24, DW 192.168.178.1/24), Transfernetz streichen, AllowedIPs
10.40.0.0/16. -> WG-Spoke-Ansatz damit machbar.

- fritzbox-wg-lanlan-klickanleitung.md: Root Cause + One-Field-Fix (LAN-IP als
  Address), LAN-LAN-Wizard, Verify gegen 10.101.0.10.
- teilprojekte.md / tp10-vpn-migration.md: Status "Root Cause gefunden, machbar".

Korrigierte Spoke-Configs in routeros/.secrets/wg-{fm,dw}.conf (gitignored).
FM bleibt auf IPsec (Sicherheitsnetz); ap1-WG-Hub inert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-17 00:15:32 +02:00
Christoph Emsenhuber
e54e6eb7cb TP10 ⏸ pausiert: FM-Cutover revertiert (IPsec), FB-WG-LAN-LAN-Klickanleitung 
FM-Cutover-Versuch gescheitert: .conf importiert, Handshake grün, IPsec voreilig
deaktiviert -> FM unerreichbar. Diagnose-Fehler: nur FB-eigene .254 gepingt (FB
antwortet aus Tunnel-IP 10.255.255.2 -> OS verwirft); echte FM-LAN-Hosts nie
getestet -> NAT-These unbewiesen. Research (Bouni) bestätigt FB<->MikroTik
LAN-LAN ohne NAT ist machbar. FM auf IPsec zurückgestellt; ap1-WG-Hub bleibt inert.

- routeros/fritzbox-wg-lanlan-klickanleitung.md: Diagnose->Fix->Verify, Echt-Host-
  Test ZUERST (10.101.0.10, nicht .254), IPsec bleibt Sicherheitsnetz.
- teilprojekte.md / tp10-vpn-migration.md: Status ⏸ + Incident dokumentiert.

Spoke-.conf mit Private-Keys bleiben gitignored in routeros/.secrets/ (die
ungetrackten Duplikate in routeros/ Root sind bewusst NICHT committet).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 21:36:02 +02:00
Christoph Emsenhuber
2c9c1b0e6c TP10 🔐 WG-Hub auf ap1 gebaut (Phase A); Cutover-Runbook FM/DW 
ap1 = WireGuard-Hub (wg-hub, UDP 51821, MTU 1412, keine IF-IP). Port 51821
statt 51820, damit der FB-eigene WG-Server (laufender DW-Tunnel) parallel intakt
bleibt. 2 Peers vorkonfiguriert: FM 10.101.0.0/24 (war IPsec), DW/Geli
192.168.178.0/24 CGNAT (war WG). Routen + Firewall (input/forward) gesetzt;
NAT unverändert (Egress wg-hub != masquerade-Interface).

docs/tp10-vpn-migration.md: As-built + Phase-B-Cutover-Runbook (FB-Import,
L3-Verify, NetBIOS-Lehre, Parallelphase, DDNS-Übergabe für Bridge-Mode).
Spoke-.conf mit Private-Keys liegen gitignored in routeros/.secrets/.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 20:55:47 +02:00
Christoph Emsenhuber
f1147d0fb3 Call-Quality 🔍 IPv6-Stand korrigiert: FB-6to4 nur am VLAN1, intern v4-only 
Verifiziert am VLAN1-Host (FB-nah): FB annonciert 2002::-Prefix per RA,
curl -6 klappt, ping6 Google v6 = 100% Loss (flatterhaftes 6to4).
Intern NICHT durchgereicht: Mac mini (VLAN20 hinter ap1) v6-los —
ap1 kein RA/DHCPv6-PD, Branch-Switch nicht v6-konfiguriert,
Core-Switch v6-Fähigkeit unklar. 6to4 untauglich für RT-Medien;
saubere Alt = 6in4-Tunnelbroker (HE). Geli-CGNAT-Bypass unberührt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 19:47:02 +02:00
Christoph Emsenhuber
6cfd857081 Call-Quality 🔍 IPv6-Stand: Liwest kein natives v6, 6to4 am LAN untauglich 
- Liwest bietet kein natives IPv6 (techn. Support bestätigt).
- Christophs 6to4-Versuch am Mac mini/LAN NICHT nutzbar (stf0 down,
  keine globale v6, kein v6-Route/Internet) → kein funktionierendes
  v6 auf Christophs Seite; ap1/TP4 bleibt v4-only.
- 6to4 = legacy/relay/hohe Latenz → keine Basis für Echtzeit-Medien;
  saubere Alt bei Bedarf = 6in4-Tunnelbroker (HE).
- Geli-seitiger CGNAT-Bypass (ihr natives v6, Telegram-Reflector-Leg)
  bleibt davon unberührt — der billige Hebel braucht Christoph-v6 nicht.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 19:37:57 +02:00
Christoph Emsenhuber
cfcb2eef56 Call-Quality 🔍 Diagnose revidiert (Video/ISP-Strecke) + Handout 
Anamnese mit Christoph kippt die frühere Roaming-These → Nebenfaktor.
Leitend: ratengebundenes Video über Geli→Christoph (CGNAT/Auslands-
Peering, Gegenlicht/Dunkel→Bitrate→Congestion-Kollaps; Jitter/Burst).

- Richtung geklärt: Engpass = Gelis Senderichtung (Handy-Uplink → ISP).
- 2 Kontrollexp.: Christophs nat. Video gut; Geli Cable→Fiber, Problem bleibt.
- Anschluss-Fakten: Geli 2.5/1.3 Gbit, v4=CGNAT (100.64/10), v6=nativ /56;
  Christoph kein Client-v6 (ap1 v4-only).
- IPv6 = billigster Hebel (nur Gelis v6 nötig; Telegram kann v6);
  Caveat CGNAT-Box vs Transit-Rohr → Abend-Messung entscheidet.
  SIP/Self-host nur Notnagel, TP3/Roaming nur Nebenfaktor.
- Handout (teilbar mit Geli): Schlauch-Analogie, 4 Knicke einfach erklärt,
  Telegram-Datensparmodus iOS/Android, Test + Ergebnis-Deutung.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 19:32:07 +02:00
Christoph Emsenhuber
1c9a41536f IP-Plan 📋 NAS/Controller geblockt auf CF ZT + TP10; Migrations-Phasen ausgearbeitet (docs/ip-plan.md) 
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-16 14:57:52 +02:00
Christoph Emsenhuber
2607964566 IP-Plan 📋 Hypervisor→INFRA, macmini migriert (docs/ip-plan.md) 
- pve: Hypervisor zählt zu INFRA (User-Entscheid) → 10.40.20.100 (VLAN20),
  MGMT/VLAN99 = nur noch Switch/AP-Mgmt.
- Mac mini ✅ live auf 10.40.20.167 (Omada Access-INFRA ohne VLAN1).

Kontext (live, nicht im Repo):
- Omada: Access-IOT/-UNTRUSTED/-GUEST/-MGMT Profile angelegt (Satz komplett).
- ap1 DNS: macmini.bf.lan → 10.40.20.167.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 14:09:21 +02:00
Christoph Emsenhuber
0ad2ca21e0 AP IP-Plan 📋 Geräte-IPs je Ziel-VLAN definiert (docs/ip-plan.md) 
Eigenständiges Arbeitspaket: finale statische IPs je Gerät in den
Ziel-VLANs (INFRA 20 / MGMT 99), Host-Oktett beibehalten, Vorschläge
zum Bestätigen.

Kontext (live in dieser Session umgesetzt, nicht im Repo):
- Omada PVID-Fix Teil 1: P3/P6 Sonos→Access-MEDIA (VLAN40),
  P5 Drucker→Access-MAIN10 (VLAN10).
- ap1 srcnat: accept 10.40.0.0/16 vor Masquerade → Inter-VLAN ohne SNAT.
- Voraussetzung erfüllt: VLAN1↔VLANx-Routing via statischer FB-Route → ap1.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 13:50:42 +02:00
Christoph Emsenhuber
3e59383317 AP4.1 📋 Cutover-Tutorial + Session-Doku — FB-Bridge gegated auf TP10-VPN 
Schärft das Runbook zum vollständigen Solo-Tutorial (Verkabelungs-Diagramm,
WiFi/VLAN-Matrix, Schritt-für-Schritt mit Zurückbau) und schreibt den
Session-Stand für die Fortsetzung fort.

Kernpunkt: FB-Bridge ist nur ein REVERSIBLER TEST. Die BF-FritzBox terminiert
aktuell 2 produktive Site-to-Site-Tunnel (AVM LAN-LAN: 1× IPsec + 1× WG),
Ziel 2× WG auf ap1 = TP10. Voller Bridge-Mode killt diese Tunnel → permanenter
Umstieg ist auf TP10 gegated (FB bleibt bis dahin Router + VPN + Telefon).

- wan-cutover-runbook.md: TEST-Banner, Verkabelung (ether2=Uplink nie ziehen,
  ether1=WAN), Console = FritzBox-WiFi → 10.40.41.1, install-SSIDs für DHCP-Test,
  wantest-run erklärt, Zurückbau-Schritt.
- docs/teilprojekte.md: Ist-Stand + TP4 (AP4.1 Public-IP bewiesen, Testmechanismus,
  DNS-Upstream jetzt CF-DoH) + TP10 (FB hält 2 Tunnel, gated permanenten Bridge).
- CLAUDE.md: WAN-Testmechanismus, device-mode-Gotchas (scheduler/fetch blockiert,
  [/ping]=nil → :resolve), VPN-Gate, REST-Fallback.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 11:45:41 +02:00
Christoph Emsenhuber
51054938ac AP4.1 🧪 Offline-WAN-Cutover-Test für ap1 — scheduler-frei, Disk-Log 
Toolkit, um den FB-Bridge/Passthrough-Cutover (Liwest) autonom auf ap1 zu
testen, während Claude/MikroMCP offline ist (Test-Client auf install-wifi,
LAN4-Umstecken kappt den Live-Pfad).

- wan-cutover-test.rsc: wantest-probe (schichtweise Diagnose: ether1-IP,
  default-gw, WAN-Reach via :resolve@1.1.1.1, DoH end-to-end) + wantest-run
  (blockierender Loop, Hintergrund-fähig). Persistentes Disk-Logging nach
  wan-test.0.txt.
- wan-macclone-test.rsc: CM-MAC-Clone (0C:72:74:36:90:99) mit eingebautem
  Auto-Revert (~90s), scheduler-frei.
- wan-cutover-runbook.md: Solo-Runbook für den User (Console altes WiFi →
  10.40.41.1).

Scheduler-frei, weil device-mode=home auf ap1 /system scheduler und /tool
fetch blockiert. Reachability via :resolve statt ping ([/ping] gibt in
7.23 nil; ICMP hier geblockt). Public-IP 86.56.201.104 bereits bewiesen
(kein Liwest-MAC-Lock).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-16 00:57:05 +02:00
Christoph Emsenhuber
48cdcc0fa2 TP4 ✅ ap1 ist L3-Router — VLAN-Subinterfaces, DHCP, DNS, NAT live 
Bridge vlan-filtering=yes; vlan10/20/30/40/50/90/99 je mit GW .1/24, DHCP-Server
(Pool .100-.200), statischen DNS-Einträgen bf.lan und srcnat masquerade →bridge.
Double-NAT via FB (Interim), FB-Bridge-Mode + Omada-PVID-Fix als nächste Schritte.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 19:24:32 +02:00
Christoph Emsenhuber
f0c08263dd TP2 🔍 Profile-Analyse + TP4 vorgezogen 
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>
 2026-06-15 19:00:40 +02:00
Christoph Emsenhuber
751845a119 Add memory index: TP2 Topologie, API-Gotchas, Portplan 
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 18:33:06 +02:00
Christoph Emsenhuber
fe477073a3 TP2 ✅ Omada ES208G vollständig konfiguriert — VLANs + Port-Profile live 
- Switch adopted (switchConsistent=true), alle 8 Ports benannt und mit
  Trunk-ALL/Access-MAIN/Access-INFRA Profilen versehen
- omada-mcp Settings-Bug behoben (doppelter Eintrag → .174 statt .176)
- Open-API-Auth dokumentiert: AccessToken=-Header, grant_type als Query-Param
- Ist-Stand und TP2-Abschnitt auf FERTIG aktualisiert; TP4-Hinweis ergänzt

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 18:32:26 +02:00
Christoph Emsenhuber
d99d8cf6da TP2 ✅ omada-mcp live (.176/pve, StreamableHTTP /mcp) — Verbindungstest grün 
Root cause der Crash-Loops gefunden:
- Container bekam Env beim Deploy INLINE (Portainer ignoriert env_file) → alte falsche Var-Namen
- jmtvms/tplink-omada-mcp v0.15 nutzt Omada OPEN API (CLIENT_ID/SECRET), nicht user/pass
- Transport ist StreamableHTTP (MCP_SERVER_USE_HTTP + MCP_HTTP_*), NICHT SSE/MCP_TRANSPORT

Jetzt: /health 200, MCP initialize-Handshake liefert Tools/Capabilities. settings.json → /mcp.
.env-Schema, .env.template, compose-Doku korrigiert.
Offen: Claude Code reload → VLANs anlegen + .12 adoptieren (Tool-Categories ggf. um write erweitern).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 15:07:14 +02:00
Christoph Emsenhuber
bf5d2b2741 TP2 🔄 omada-mcp deployed (.176/pve-LXC) — braucht Open-API-Client-Creds 
- omada-mcp Container auf pve-LXC (.126, endpointId=2, ipvlan .176), Stack Id=200, gestoppt
- Erkenntnis: jmtvms/tplink-omada-mcp nutzt Omada OPEN API (CLIENT_ID/SECRET/OMADAC_ID/SITE_ID),
  NICHT username/password → .env-Schema + compose-Kommentare + .env.template angepasst
- omada-mcp in ~/.claude/settings.json eingetragen (SSE .176:3000)
- Letzter manueller Schritt: Open-API-App im Controller-UI anlegen (Platform Integration),
  Client-Creds + SITE_ID in .env → Container starten → reload → dann VLANs + Adoption

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 14:49:51 +02:00
Christoph Emsenhuber
c5d4ee8bfa TP2 📋 Komodo-Migration geplant: Core/Periphery/MCP Compose + MIGRATION.md 
Portainer CE 2.40 hat keinen passenden portainer-mcp (erst ab 2.41) → Entscheidung:
Ablösung durch Komodo + Samik081/mcp-komodo (selber Autor wie pve-mcp).

- mcp/komodo/MIGRATION.md       — 5-Phasen-Plan (Export → Core → Periphery → Stacks → MCP)
- mcp/komodo/core-compose.yml   — Komodo Core + MongoDB auf pve-LXC (.126:9120)
- mcp/komodo/periphery.compose.yml — Agent-Template für DS923/.10, odroid/.7, macmini/.167, nas-fm
- mcp/komodo/komodo-mcp-compose.yml — MCP-Adapter, macvlan .176, SSE :3000
- mcp/komodo/.env.example       — Secret-Vorlage
- mcp/INVENTORY.md              — portainer-mcp auf ⏳ retiring, komodo-mcp als 🟡 geplant eingetragen

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 14:42:52 +02:00
Christoph Emsenhuber
8b08d9b5a4 TP2 🔄 Status persistiert: Wizard ✅, omada-mcp staged (Container noch offen) 
- teilprojekte.md: TP2 als IN ARBEIT markiert, offene Schritte präzisiert
  (omada-mcp deployen → Claude Code eintragen → VLANs anlegen → .12 adoptieren)
- INVENTORY.md: omada-controller 🟢 (Wizard done), omada-mcp 🔴 (Container pending)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 14:26:21 +02:00
Christoph Emsenhuber
a36bdd8f56 TP2 ✅ Omada Controller deployed + omada-mcp staged: DS923/macvlan, pve-mcp eingetragen 
- omada/docker-compose.yml: Controller 6.2.10.17 auf DS923 (macvlan .175, endpointId=14);
  pve-LXC (.126) hat zu wenig Disk → DS923 standard pattern
- mcp/omada/: docker-compose.yml + .env.template für omada-mcp (macvlan .174, MCP_TRANSPORT=sse);
  wartet auf Wizard-Passwort nach https://10.40.41.175:8043
- pve-mcp (samik081) in ~/.claude/settings.json eingetragen (SSE .173:3000)
- CLAUDE.md: Topologie korrigiert (wahre IPs .100/.126/.167/.173-.175, Omada Port 2 = ap2)
- INVENTORY.md: pve-mcp 🟢, omada-mcp 🟡, portainer-mcp zurückgestellt (→ Komodo)
- teilprojekte.md: TP2 ✅, Ist-Stand + offene manuelle Schritte dokumentiert

Noch offen (manuell): Wizard, .12 adopt, Port-Config, .env + Stack deploy, Claude Code eintragen.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 14:11:05 +02:00
Christoph Emsenhuber
a58d419747 TP1 ✅ ALLNET Core-Switch finalisiert: VLAN 40→MEDIA, VLAN 50 UNTRUSTED, GE8 Trunk verifiziert 
- Neues CLI-Script 04-vlan50-media-untrusted.cli ausgeführt + verifiziert:
  VLAN 40 umbenannt UNTRUSTED→MEDIA, VLAN 50 angelegt (UNTRUSTED),
  GE1/GE2 um VLAN 50 ergänzt; GE8 war bereits Trunk, VLAN 50 auto-includiert.
- Docs: teilprojekte.md TP1 als FERTIG markiert, Ist-Stand aktualisiert,
  VLAN-Gotcha entfernt. core-switch-prep.md Phase A/TP1 Stand ergänzt,
  Switch-IP .239→.11 korrigiert. CLAUDE.md Gotcha aktualisiert, IP korrigiert.
- CLI-REFERENCE.md: VLAN-Namen 40=MEDIA, 50=UNTRUSTED.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 11:33:25 +02:00
Christoph Emsenhuber
e15edc22d7 TP4 DNS: Entscheidung auf RouterOS-nativ + nur statische Records 
Variante A (BIND/RFC2136) verworfen: HW-Vorgabe "Container nur am Router
oder gar nicht, keine NAS/pve-Abhaengigkeit" + hAP kann praktikabel keinen
DNS-Container hosten (live: ~90MB frei, kein USB, Flash-Wear).

- research-Doc umgeschrieben: Entscheidung + Variante A als parkierter Anhang
- teilprojekte TP4 auf finale Entscheidung
- technitium/ -> dns/ umbenannt + README

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-15 11:24:05 +02:00
Christoph Emsenhuber
ae4d1e5fcd TP4 DNS: Variante A (RouterOS-DHCP + RFC2136 → BIND9), Technitium verworfen 
- Research-Doc: DHCP→DNS-Registrierung standardnah, PowerDNS-vs-BIND9-Vergleich
- teilprojekte TP4 auf BIND9 + RFC2136 umgestellt + Verweis; HW-Notiz angepasst

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-15 11:24:05 +02:00
Christoph Emsenhuber
3ae7321865 CLAUDE.md: auto-geladener Session-Kontext (VLAN, HW, Tooling, Gotchas) 
Ersetzt manuelles Referenzieren von Zusatzdateien beim Sessionstart.
HANDOVER.md als Archiv-Dokument markiert; teilprojekte.md bleibt kanonisch.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 10:45:42 +02:00
Christoph Emsenhuber
e688b37b60 Teilprojekte + MikroMCP + WLAN-Vorarbeit: Steuerungsdok, Research, MCP-Setup, CAPsMAN-Asbuilt, AP-Trunk-Guides + Port-Map 
- docs/teilprojekte.md: kanonisches Projektsteuerungsdokument (TP1–TP13 + TP-R)
- docs/research/: RouterOS-Capabilities-Sweep (TP-R) + VPN-Vergleich (TP10)
- mcp/: MikroMCP + Portainer-MCP Docker-Compose, routers.yaml, READMEs, .gitignore
- routeros/: ap1-manager.rsc, ap2-cap.rsc, CAPsMAN-Flat-Asbuilt, WLAN-Handover
- switch/cli/03-trunk-ap-ports.cli + switch/ui-guides/01-trunk-ap-ports.md: AP-Trunk-Konfiguration
- docs/allnet-ge8-trunk-klickanleitung.md: GE8 Hybrid→Trunk Schritt-für-Schritt
- inventory/bf-core-ports: gi1/gi2 als TRUNK zu ap1/ap2 eingetragen (gesetzt 2026-06-09)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-06-15 08:42:03 +02:00
Christoph Emsenhuber
1f6e2a000b Docs: core-switch-prep auf aktuellen Stand bringen 
- Phase A als ABGESCHLOSSEN markiert (Firmware 2.2.1, VLAN-DB+Names, Save)
- Alte DRAFT-Inhalte (172.20/30/40-Schema, FW-Update 'heute', Web-UI-Skripting) entfernt
- Neue Struktur: Status/Phase-A/Phase-B-Cutover-Plan/Gotchas/Offene-Punkte
- Telnet-VTY-Lockout, Mgmt-VLAN-Lockout, Gateway-Migration, end-vs-exit dokumentiert
- README: SSOT-Link auf HANDOVER.md, Struktur-Übersicht, aktueller Stand
 2026-06-09 19:01:14 +02:00
Christoph Emsenhuber
bb31625d8f CLI-Reference: bestaetigte Syntax (mask, name, end vs exit) 2026-06-09 18:56:41 +02:00
Christoph Emsenhuber
a73db06354 Phase A complete: VLAN DB + names + handover 
- HANDOVER.md: full delegation doc (Status, Architektur, Phasen, Gotchas)
- switch/cli/backup.exp: show running-config mit --More-- handling
- switch/cli/02-vlan-names.cli/exp: set VLAN names (MAIN/INFRA/IOT/UNTRUSTED/GUEST/MGMT/WAN)
- switch/cli/running-PRE.txt: pre-changes config backup (networkmask-Syntax bestaetigt)
- switch/cli/02-vlan-names.log: verifikations-Output (show vlan)

VLAN-DB jetzt: 1, 10, 20, 30, 40, 90, 99, 100 (alle benannt, alle Static)
Alle Ports weiterhin in VLAN 1 (non-disruptiv).
save: Success

Switch-Recovery: Telnet-VTY-Lockout (stale Session) erforderte User-Reboot
  des Switches. Credentials OK, WebUI ebenfalls blockiert (Session-Drop).
  Nach Reboot funktioniert Telnet ueber plain pipe UND expect.
 2026-06-09 18:55:43 +02:00
Christoph Emsenhuber
498fa06472 Initial commit: BF Core-Switch-Prep + VLAN-Architektur + Delegations-Übergabe 
- ALL-SG8316M auf FW 2.2.1.2956 geflasht; VLAN-DB 10/20/30/40/100 via Telnet-CLI (non-disruptiv)
- CLI-Tooling: run-cli.exp + .cli-Files + CLI-REFERENCE (FW 2.2.1, IOS-artig)
- Kanonisches Inventar: bf.csv/md + build.py (Doku-Motor), Core-Port-Map
- Finaler VLAN-/Adressplan (10.40.<vlanid>.0/24), Firmware-Runbooks, Recovery-Assets
- Secrets/Firmware/State/DS_Store via .gitignore ausgeschlossen

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-09 18:08:45 +02:00