TP5 Etappe 1: Sammelphase laeuft, VLAN1-Rueckbau abgenommen

Abnahme bestanden: out:bridge = 0 ueber ein 10-Minuten-Fenster (Logdatei
vorher geleert). Vorher waren vlan20 -> bridge 76 % des gesamten
Inter-VLAN-Verkehrs; die Rate fiel von ~166 auf ~34 Zeilen/min.

Beobachtete Matrix (339 Zeilen / 10 min) als Arbeitsmaterial fuer Etappe 2
festgehalten. Zwei Befunde daraus:

- D4 ist belegt statt geschaetzt: der Management-Pfad ist HA (10.40.20.105),
  das ueber seine mikrotik-Integrationen 8728 auf branch/ap1 pollt (je 67x).
  Ohne Whitelist sperrt der spaetere Drop die Netzverwaltung aus.
- Neuer Merkposten: same-VLAN-Verkehr erreicht die forward-Kette —
  vlan10 -> vlan10 unicast mDNS, erzeugt vom mDNS-Repeater auf dem Core.
  Harmlos, aber ein blanker Drop wuerde Discovery innerhalb von MAIN
  beschaedigen.

Damit sind drei Whitelist-Zeilen bekannt, bevor Etappe 2 beginnt:
LAN->WAN, der Mgmt-Pfad, und same-VLAN-mDNS.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/tp5-deny-by-default-runbook.md

@@ -127,14 +127,21 @@ Es legt den manual Plan an, prüft `plan.device` gegen den Namen, gibt frei, dep
    `:log info ("… count=" . [:tostr [:len [… find …]]])` setzen — anschließend per `get_log` zeilengenau
    auslesen. Damit ist Root-Cause-Analyse **ohne Direkt-Write** möglich.
 
-### Etappe 1 — Log-Lauf (blockiert nichts, Dauer: einige Tage) ▸ ⏸️ **AUFGEBAUT, PAUSIERT (2026-08-14)**
+### Etappe 1 — Log-Lauf (blockiert nichts, Dauer: einige Tage) ▸ 🟢 **SAMMELPHASE LÄUFT (seit 2026-08-16)**
 
-> ⏸️ **Pausiert, bevor gesammelt wurde** (User-Entscheid): erst die `.41.x`→`.20.x`-Altlasten aufräumen,
-> sonst besteht die abgeleitete Whitelist zu drei Vierteln aus Verkehr, den es danach nicht mehr gibt.
-> Log-Regel `disabled=yes`, Memory-Logging zurück auf `topics=info`; Kollektor und Logging-Action
-> bleiben stehen. **Wiederaufnahme = zwei Zeilen + Logdatei leeren**, s. `routeros/tp5-etappe1-pause.rsc`.
-> **Vorbedingung für die Wiederaufnahme:** Prometheus-Scrape-Ziele und die pve-Referenz `.41.100`
-> sind umgezogen bzw. entfernt (Liste in `docs/teilprojekte.md` → TP19).
+> Historie: am 2026-08-14 **vor** der Sammelphase pausiert, weil 76 % des Verkehrs `.41.x`-Altlast war.
+> Nach dem VLAN1-Rückbau (TP19) am 2026-08-16 wieder scharf — `routeros/tp5-etappe1-resume.rsc`.
+>
+> ✅ **Abnahme bestanden: `out:bridge` = 0** über ein 10-Minuten-Fenster (Logdatei vorher geleert).
+> Rate von ~166 auf ~34 Zeilen/min gefallen. Die beobachtete Matrix steht in
+> `docs/teilprojekte.md` → TP5 und ist ab jetzt das Arbeitsmaterial für Etappe 2.
+>
+> **Zwei Regeln stehen damit schon fest und brauchen keinen weiteren Beleg aus dem Log:**
+> 1. `accept out-interface-list=WAN` — ohne sie nimmt der Drop das ganze Haus vom Netz.
+> 2. Der **Management-Pfad** `10.40.20.105 → 10.40.99.{2,11,12}:8728` (HA-`mikrotik`-Integrationen)
+>    plus MikroMCP vom Arbeitsplatz — sonst sperrt der Drop die Netzverwaltung aus.
+> 3. **Same-VLAN-mDNS** (`vlan10 → vlan10`, `5353`, vom Repeater auf dem Core erzeugt) erreicht die
+>    `forward`-Kette und würde von einem blanken Drop getroffen.
 
 Ausgerollt über Nautobot GC (manual Config Plans, `nautobot/gc-manual-plan.py`), Quelle
 `routeros/tp5-etappe1-log-lauf.rsc`. Auf dem Gerät: