TP5 Etappe 1 pausiert + VLAN1-Restliste aus dem Log-Lauf

Etappe 1 ist aufgebaut und verifiziert, wird aber vor der Sammelphase
pausiert (User-Entscheid): 76 % des beobachteten Inter-VLAN-Verkehrs waren
.41.x-Altlasten. Eine Whitelist daraus haette nach dem Aufraeumen nicht
mehr gegolten.

- Log-Regel disabled=yes, Memory-Logging zurueck auf topics=info
- Kollektor + Logging-Action bleiben stehen -> Wiederaufnahme = zwei Zeilen
  (routeros/tp5-etappe1-pause.rsc dokumentiert beide Richtungen)
- D2 vollzogen: iPhone im MAIN-SSID, .30.201 im ARP auf failed

TP19 bekommt die konkrete Restliste, die der Log-Lauf sichtbar gemacht hat:
prometheus (.20.151) scrapet 10 tote 10.40.41.x-Ziele, .20.105 zieht auf
pve unter der alten .41.100. Umzugsregel 41->20 bei gleichem letzten Oktett.

Der gemeldete Timeout auf .20.100:8006 ist KEIN Firewall-/Portproblem:
pveproxy lauscht auf *:8006, pve-firewall disabled, HTTP 200 in 0,06 s aus
VLAN10 und VLAN20. Notiert ist auch die Fehlerquelle meines ersten Tests -
`timeout` existiert auf macOS nicht und meldet falsch-negativ.

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

routeros/tp5-etappe1-pause.rsc

@@ -0,0 +1,32 @@
+# TP5 Etappe 1 — PAUSE (User-Entscheid 2026-08-14).
+# Grund: erst die .41.x -> .20.x-Migration fertigstellen (Prometheus-Scrape-Ziele,
+# HA-pve-Integration). Daten, die davor gesammelt werden, gelten danach nicht mehr —
+# 76 % des Inter-VLAN-Verkehrs waren genau dieses Altlast-Rauschen.
+#
+# Push:  python3 nautobot/gc-manual-plan.py --device crs326-core \
+#            --commands-file routeros/tp5-etappe1-pause.rsc --change-id TP5-Etappe1-Pause --deploy
+
+# 1) Log-Regel stilllegen. Bleibt als Objekt stehen (Kommentar = Idempotenz-Schluessel),
+#    das Wiederanschalten ist damit eine Zeile.
+:do { /ip firewall filter set [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled=yes } on-error={ :log info "tp5p: disable hat geworfen" }
+
+# 2) Memory-Logging zurueckbauen. Der Ausschluss war nur wegen der Flut noetig;
+#    waehrend der Pause faellt keine an, und der On-Box-Log wird fuer die
+#    Migrationsarbeit wieder gebraucht.
+:do { /system logging set [find topics~"info" and action=memory] topics=info } on-error={ :log info "tp5p: topics-restore hat geworfen" }
+
+:log info ("tp5p: ENDE regel-disabled=" . [:tostr [/ip firewall filter get [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled]] . " memory-topics=" . [:tostr [/system logging get [find topics~"info" and action=memory] topics]])
+
+# ===========================================================================
+# WIEDERAUFNAHME (Etappe 1 fortsetzen)
+# ===========================================================================
+# Der Kollektor laeuft weiter (Container `tp5-syslog` auf dem Docker-LXC,
+# restart=unless-stopped, 10.40.20.18:514) und die Logging-Action `tp5syslog`
+# samt Regel `topics=firewall` bleibt auf dem Core stehen — beides ist ohne die
+# Filter-Regel wirkungslos. Zum Fortsetzen genuegen zwei Zeilen:
+#
+#   /ip firewall filter set [find comment="TP5: log-only, Vorstufe zum deny-by-default"] disabled=no
+#   /system logging set [find topics~"info" and action=memory] topics=info,!firewall
+#
+# Vorher aufraeumen, sonst mischt sich Altes unter die neue Sammelphase:
+#   ssh root@10.40.20.100 'pct exec 400 -- sh -c ": > /opt/tp5-syslog/log/tp5-would-drop.log"'