VLAN1-Leak-Härtung (TP3.1) + VLAN1-Retirement/cudy-Teardown (TP19) — Runbook

Stand: 2026-07-15. Zwei verschiedene TPs, ein gemeinsamer Session-Ablauf (Phase A wird logisch zuerst gemacht, blockiert aber Phase B nicht). Steuerung/Scope: docs/teilprojekte.md → TP3.1 (Phase A) und TP19 (Phase B). Verwandt: project_vlan1_dhcp_incident (Root-Cause-Erstdiagnose), routeros/tp3.1-ap2-vlan.rsc (Interim-Härtungsmuster, dort erstmals auf ap2 angewendet). Für eine frische Session gedacht — kein Vorwissen aus Vorgänger-Sessions vorausgesetzt.

TL;DR

Akuter Bug, nicht nur Cleanup: Clients auf dirtyvader-main (VLAN10) bekommen zeitweise 10.40.41.x-IPs (VLAN1) statt 10.40.10.x — der bereits einmal diagnostizierte Dual-DHCP-Race (gleiche MAC hält gleichzeitig eine defconf/VLAN1- und eine dhcp-v10-Lease).

Phase A — TP3.1-Scope (~30–60 Min): akutes Leck auf ap1 stopfen, gleiche Härtung wie 2026-07-06 auf ap2 (dort schon TP3.1-Interim-Härtung). Symptom weg, VLAN1 existiert danach noch.
Phase B — TP19-Scope (~2–3h): VLAN1 + cudy komplett abbauen. Ursache weg, kein Leck mehr möglich, Phase-A-Härtung wird dabei redundant (muss nicht zurückgebaut werden, verschwindet mit VLAN1 selbst).

Phase A blockiert Phase B nicht (unabhängig ausführbar), aber Phase B macht Phase A überflüssig.

Kontext / Root Cause

VLAN1 ist historisch das Flachnetz der alten FritzBox-Ära und trägt bis heute:

Das cudy-Alt-WLAN (elektrosmog.c o.ä., cudy1/cudy2, 10.40.41.246/.247) — bridged Clients untagged in VLAN1.
Eine aktive DHCP-Client-Rolle auf ap1 (defconf/pool-v1) — vergibt weiterhin 10.40.41.x-Leases.
Switch-/AP-Management (sw1 .11, sw2 .12, ap2-Mgmt .2) — das bleibt bis zum separaten MGMT-VLAN99-Cutover, ist NICHT Teil dieses Teardowns.

Bereits einmal aufgetreten und diagnostiziert (project_vlan1_dhcp_incident, 2026-07-05/06): dieselben Main-SSID-MACs hielten gleichzeitig eine korrekte dhcp-v10-Lease und eine defconf/VLAN1-Lease → Race, sichtbar als „offering ... without success" + minütliches Flapping. Fix damals (TP3.1, 2026-07-06): auf ap2 wurden die Master-Radio-Bridge-Ports wifi1/wifi2 von frame-types=admit-all auf admit-only-vlan-tagged umgestellt — untagged Main-Frames werden seither auf ap2 verworfen statt in VLAN1 gedumpt. Diese Härtung wurde nur auf ap2 gemacht. Der aktuell gemeldete Leck auf dirtyvader-main deutet stark darauf hin, dass ap1 die gleiche Lücke noch offen hat (lokale Main-Radios dort vermutlich noch admit-all).

Phase A (TP3.1) — Akutmitigation (Leck auf ap1 stopfen)

Ziel: dirtyvader-main-Clients bekommen zuverlässig nur noch dhcp-v10-Leases, keine defconf mehr. VLAN1 selbst bleibt vorerst bestehen (das ist Phase B).

A1 — Live-Diagnose (Race bestätigen)

mikromcp list_wifi_clients / Registration-Table auf ap1, gefiltert auf dirtyvader-main-Interface → betroffene MACs sammeln.
mikromcp list_dhcp_leases auf beiden Servern (defconf = VLAN1-Pool, dhcp-v10 = VLAN10-Pool) → nach denselben MACs suchen. Beweis des Race: dieselbe MAC taucht in beiden Leases auf.
Prüfen, ob die betroffenen Clients über ap1 (lokal) oder ap2 (remote-CAP) verbunden sind — falls ap2, ist die TP3.1-Härtung dort vermutlich schon aktiv und das Leck sitzt tatsächlich auf ap1 (bestätigt die Hypothese) oder wo anders (cudy selbst, s. A4).

A2 — Fix: ap1 Main-Radio-Härtung (Playbook = TP3.1)

Auf ap1: welche Bridge-Ports tragen die lokalen Master-Radios für dirtyvader-main (wifi1/wifi2, analog zur ap2-Struktur aus TP3.1)? Aktuellen frame-types-Wert prüfen.
Falls admit-all: auf admit-only-vlan-tagged umstellen — exakt das gleiche Muster wie TP3.1 auf ap2, siehe routeros/tp3.1-ap2-vlan.rsc als Referenz.
⚠️ NICHT anfassen: ether2 (WAN-Trunk/Mgmt-Pfad von ap1 — VLAN1 muss dort laut TP3.1/TP4 weiterhin untagged=bridge,ether2 bleiben, sonst Lockout-Risiko für Switch-/AP-Mgmt). Nur die WLAN-Radio-Bridge-Ports ändern, kein anderer Port.
dryRun:true zuerst, Diff prüfen, dann apply_plan.

A3 — Verifikation

Betroffene Clients (aus A1) neu verbinden lassen (WiFi aus/an) oder auf DHCP-Renew warten.
Neue Lease muss ausschließlich dhcp-v10 sein — defconf-Lease für diese MAC darf nicht erneuert werden (alte Lease läuft aus/wird nicht erneuert = ok).
10–15 Min beobachten (mehrere Renew-Zyklen), kein erneutes Flapping.

A4 — Falls A2 nicht ausreicht

Falls nach dem ap1-Fix das Symptom weiter auftritt: Leck sitzt evtl. nicht an den Main-Radios, sondern am cudy selbst (bridged evtl. irgendwo denselben L2-Broadcast-Domain-Ast) oder an einem noch nicht identifizierten Pfad. In dem Fall: Phase B (kompletter cudy-Abbau) vorziehen/beschleunigen — das Symptom verschwindet spätestens dann garantiert, weil die VLAN1-Quelle physisch weg ist.

Phase B (TP19) — Vollständiger Teardown (VLAN1 + cudy weg)

B0 — Ziel-Abgrenzung

Weg: cudy-WLAN komplett, VLAN1 als Client-Netz (defconf/pool-v1). Bleibt (by design, bis separater MGMT-VLAN99-Cutover): sw1 .11, sw2 .12, ap2-Mgmt .2 — statisch, kein DHCP nötig.

B1 — Prereqs: restliche VLAN1-Clients umziehen (SONST verwaisen sie beim cudy-Tod)

Live-Stand ap1-ARP zuletzt geprüft 2026-07-13 — zu Sessionbeginn neu sweepen, Stand kann sich geändert haben:

Christophs Endgeräte → VLAN10 (dirtyvader-main): MacBook-Air .41.182 (c0:c7:db:de:71:be — = Claude-Sandbox-Client! Als Erstes umhängen, sonst verliert die laufende Session ggf. die Verbindung), iPhone .41.186.
2 unidentifizierte VLAN1-Geräte: .41.133 (02:11:32:22:1e:25, randomisierte/lokal-admin. MAC — evtl. Phone-Privacy-MAC oder VM) + .41.198 (34:2b:6e:6f:1f:ef) → vor Teardown verorten (größter Zeit-Unsicherheitsfaktor laut Schätzung). Falls nicht auflösbar in angemessener Zeit: Risiko abwägen — Gerät verwaist beim Teardown, taucht dann als "kein DHCP mehr" auf und lässt sich danach über den Symptom-Report re-identifizieren.
Media → VLAN40 verifizieren: Apple TV 4K + Philips TV 50PUS7304 (beide zuletzt aus) — einschalten, ap1-ARP prüfen ob dirtyvader-media/VLAN40 oder noch cudy/VLAN1. ⚠️ Apple TV = vermutlich Thread-Border-Router der 22-Matter-Geräte-Flotte (TP17.1) — nicht sorglos stromlos lassen, nur kurz für den Check.
Saisonale Shellys s1/s2/s3/s12 (aus, Weihnachtsdeko/Diele-Steckdose): Empfehlung kurz vor dem Teardown einstecken + mcp/shelly/migrate.py, sonst müssen sie später per physischem AP-Mode-Reset nachgezogen werden. Nicht blockierend — kann übersprungen werden, wenn der spätere Reset-Aufwand akzeptiert wird.
pve-Interim-IP .41.100 (bewusster Fallback) beim Teardown mit abräumen.

B2 — Teardown-Sequenz

VLAN1-Client-Sweep = leer verifizieren (nur Mgmt-IPs sw1/sw2/ap2 übrig).
cudy1/cudy2 stromlos/Reset/ausbauen (.41.246/.247).
SwitchBot floor-lamp (.41.184, b8:f8:62:09:f2:04) via App/BLE auf dirtyvader-iot/VLAN30 provisionieren (Reservierung .30.227 liegt bereits) — laut User erst jetzt (nach cudy-Tod) zuverlässig möglich, davor nicht versuchen.
ap1 defconf/pool-v1-Client-DHCP zurückziehen — Mgmt-Reachability für sw1/sw2/ap2 (VLAN1 statisch) dabei erhalten, nicht die ganze VLAN1-Interface-Config killen.
Interim-Krücken aufräumen:
- ap2 frame-types=admit-only-vlan-tagged (TP3.1) — verschwindet automatisch mit VLAN1, kein Rückbau nötig (bleibt im Zielbild korrekt).
- ap1-Härtung aus Phase A — dito, wird mit VLAN1-Tod redundant, kann bleiben.
- st-main rrm/wnm (802.11k/v Roaming-Provisorium) neu bewerten, ob nach Migration noch nötig.
Nachziehen: inventory/bf.csv, docs/ip-plan.md, ap1 bf.lan-DNS, docs/teilprojekte.md TP19 auf ✅.

Risiken & Rollback

Lockout-Risiko (wie bei jedem VLAN1-Touch): VLAN muss existieren + der Port/Radio muss es tragen, in einem Schritt ändern. Vor dem Zurückziehen von defconf/pool-v1 sicherstellen, dass sw1/sw2/ ap2-Mgmt-IPs weiterhin statisch erreichbar sind (kein DHCP-Abhängigkeit für die Mgmt-Pfade).
MacBook = Sandbox-Client: Reihenfolge einhalten (B1.1 zuerst) — sonst reißt beim cudy-Abbau die eigene Session-Verbindung ab, bevor der Umzug bestätigt ist.
Verwaiste Geräte: falls B1.2 (unidentifizierte Geräte) nicht rechtzeitig auflösbar ist und der Teardown trotzdem durchgezogen wird → Gerät fällt aus dem Netz, ist aber nicht zerstört (physischer Zugriff/Re-Provisionierung später möglich, kein Datenverlust-Risiko).
Rollback Phase A: frame-types auf ap1 zurück auf admit-all (macht das Leck wieder auf, aber reversibel).
Rollback Phase B: cudy-Hardware ist nach Ausbau nicht mehr im Netz — Rollback würde Wiedereinbau
- Reset auf alte Config bedeuten (nicht vorgesehen, Teardown ist bewusst final).

Verifikation (Gesamt)

dirtyvader-main-Clients bekommen ausschließlich .10.x-Leases (Phase-A- und Phase-B-Beweis).
VLAN1-ARP/DHCP-Sweep auf ap1: nur noch sw1/sw2/ap2-Mgmt-IPs sichtbar, keine Client-Leases mehr.
cudy-SSID nicht mehr sichtbar in WLAN-Scans.
Alle in B1 gelisteten Geräte auf ihrem Ziel-VLAN erreichbar (HA-Cross-Check wie im TP17-Runbook-Muster).

9.4 KiB Raw Permalink Blame History Unescape Escape