# TP5 Etappe 1 — Log-Lauf auf crs326-core. Blockiert NICHTS.
# Ausgerollt 2026-08-14 ueber Nautobot GC als manual Config Plans (Governance TP22),
# nicht per Direkt-Write. Backup davor: core-pre-tp5-etappe1-20260814.backup
#
# Diese Datei bildet den AUSGEROLLTEN Endzustand ab. Der Weg dorthin brauchte
# mehrere Anlaeufe; die Lehren stehen unten, damit Etappe 2-4 sie nicht wiederholen.
# Push:  python3 nautobot/gc-manual-plan.py --device crs326-core \
#            --commands-file routeros/tp5-etappe1-log-lauf.rsc --change-id TP5-Etappe1 --deploy

# --- 1) Syslog-Ziel ---------------------------------------------------------
# Der Core hat nur ~3 MB freien Flash -> Disk-Logging faellt aus (Platz + Flash-Verschleiss),
# und der Memory-Ring fasst 1000 Zeilen, den wickelt der Log-Lauf in Minuten um.
# Kollektor: syslog-ng auf dem Docker-LXC, 10.40.20.18:514 (Container `tp5-syslog`,
# Config /opt/tp5-syslog/config/syslog-ng.conf, Logs /opt/tp5-syslog/log/).
# ACHTUNG Name ohne Bindestrich — s. Lehre 1.
:do { /system logging action add name="tp5syslog" target=remote } on-error={ :log info "tp5: action add hat geworfen" }
:do { /system logging action set [find name="tp5syslog"] remote=10.40.20.18 remote-port=514 } on-error={ :log info "tp5: action set hat geworfen" }

# --- 2) firewall-Topic an den Kollektor -------------------------------------
:do { /system logging add action="tp5syslog" topics=firewall } on-error={ :log info "tp5: logging rule hat geworfen" }

# --- 3) firewall aus dem Memory-Ring nehmen ---------------------------------
# Sonst besteht der 1000-Zeilen-Puffer tagelang zu 100 % aus TP5-Zeilen und der
# On-Box-Log ist fuer jede andere Fehlersuche wertlos — genau dann, wenn man ihn braucht.
# Matcher live geprueft: topics=info trifft NICHT (Listen-Property), topics~"info" trifft genau 1.
# Rueckbau am Ende von Etappe 1: topics=info
/system logging set [find topics~"info" and action=memory] topics=info,!firewall

# --- 4) Die Log-Regel ans ENDE der forward-Kette ----------------------------
# action=log ist nicht-terminierend: das Paket laeuft weiter und faellt danach aus
# der Kette in die Default-Policy (accept). Es wird nichts blockiert.
/ip firewall filter add action=log chain=forward comment="TP5: log-only, Vorstufe zum deny-by-default" log-prefix="TP5-WOULD-DROP"

# --- 5) Einengung auf Nicht-WAN --------------------------------------------
# Der erste Lauf zeigte, dass die Regel auch saemtlichen Internet-Verkehr faengt
# (out:vlan100) — bei 242 Zeilen/min war ein Viertel davon WAN-bound, unter Last mehr.
# LAN->WAN ist eine GARANTIERTE Whitelist-Zeile (ohne sie hat kein VLAN Internet,
# auch die "Internet-only"-VLANs 50/90 nicht), also reines Rauschen fuer die Matrix,
# die Etappe 2 ableiten soll.
# 🔴 MERKPOSTEN FUER ETAPPE 3: der spaetere drop DARF NICHT bare ans Kettenende —
#    davor gehoert `accept out-interface-list=WAN`, sonst ist das ganze Haus offline.
#    Diese Zeile ist bekannt und muss nicht aus dem Log wiederentdeckt werden.
/ip firewall filter set [find comment="TP5: log-only, Vorstufe zum deny-by-default"] out-interface-list="!WAN"


# ===========================================================================
# LEHREN AUS DEM ROLLOUT (jede am Geraet belegt, nicht vermutet)
# ===========================================================================
#
# 1) 🔴 BINDESTRICHE IN `name=` WERDEN ABGELEHNT — der teuerste Fund.
#      /system logging action add name="tp5-remote" target=remote   -> wirft
#      /system logging action add name="tp5-abc"    target=remote   -> wirft
#      /system logging action add name="tp5syslog"  target=remote   -> geht
#    Quoten hilft NICHT. Isoliert per :do/on-error-Plan mit Zaehler-Checkpoints.
#    Zwischenzeitlich hatte ich das faelschlich der Reihenfolge `target=`/`remote=`
#    im selben add-Statement zugeschrieben — diese Erklaerung ist WIDERLEGT
#    (`set remote=... remote-port=...` in einem Statement laeuft anstandslos).
#
# 2) 🔴 EIN GESCHEITERTER NETMIKO-DEPLOY HINTERLAESST EINEN TEIL-ZUSTAND.
#    Die TP22-Notiz "gescheiterter Deploy = sauberer Fehlschlag" galt dem NAPALM-Weg,
#    der scheiterte, BEVOR er das Geraet anfasste. Netmiko schickt Zeile fuer Zeile
#    und laesst Abgesetztes stehen: der erste Push hier hinterliess Zeile 3+4 auf dem
#    Geraet, ohne 1+2. **Nach jedem Fehlschlag den Geraete-Ist-Stand pruefen.**
#
# 3) KEINE `print`-ZEILEN IN EINEN CONFIG PLAN. Ein `/system identity print` als
#    Kanarienzeile hat die unmittelbar folgende Zeile verschluckt und eine
#    Fehldiagnose erzeugt. Config Plans enthalten nur schreibende Kommandos.
#
# 4) SELBSTPROTOKOLLIERENDE PLAENE SIND DIE DIAGNOSE-METHODE DER WAHL.
#    Der Deploy-Job liefert nur "E1028: found bad/failed/failure in output" und
#    zeigt den Geraete-Output NICHT. Wickelt man jedes Kommando in
#    `:do {...} on-error={ :log info "..." }` und setzt danach eine Zaehlzeile
#    `:log info ("... count=" . [:tostr [:len [... find ...]]])`, liest man das
#    Ergebnis anschliessend per get_log zeilengenau aus — ohne Direkt-Write.