TP37 angelegt: Out-of-Band-Management, ein untagged-VLAN99-Port je Switch

Auslöser (User 2026-08-31): beim Core-Neustart war crs326-branch nicht mehr
erreichbar, weil sein Management ausschliesslich ueber den Core laeuft.

Live nachgemessen: auf dem Branch ist vlan99 tagged=ether1,ether24,bridge mit
untagged="" - es gibt also keinen Weg zu 10.40.99.2, der nicht durch den Core
fuehrt. Wer den Core zerkonfiguriert, verliert den Branch gleich mit und damit
die Moeglichkeit, es vom Branch aus zu reparieren.

Zweiter, unangenehmerer Befund: crs326-branch hat GAR KEINE input-Regeln (Kette
leer). Sein gesamter Schutz besteht heute darin, dass VLAN99 nur ueber den Core
erreichbar ist und dessen forward-Kette deny-by-default faehrt - die
Erreichbarkeitsbeschraenkung IST die Zugangskontrolle. Damit ist ein untagged
MGMT-Port ein physischer Generalschluessel, und das TP traegt eine explizite
Auflage: Port disabled im Normalbetrieb ODER input-Regeln auf beiden Switches
ODER physische Sicherung. Empfehlung im Abschnitt: die input-Regeln, weil sie
eine Luecke schliessen, die unabhaengig von diesem TP besteht.

Kandidat ether23 - auf core und branch beide running=false, also frei, und auf
beiden Geraeten dieselbe Nummer.

Abnahme im Abschnitt so formuliert, dass sie den Zweck prueft: Laptop an
branch ether23, Core-Trunk gezogen, 10.40.99.2 muss antworten. Alles andere
misst nur den Normalfall.

Quick-Index (nach TP36 einsortiert), TP-Abschnitt und Ist-Stand mitgezogen;
Handover 20260831 auf den angelegten TP umgestellt.

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

docs/handoff-20260831-tp16.3-vorort-session.md

@@ -84,13 +84,13 @@ kann nur vom Server kommen, die Firewall-Freigabe trägt also. cloudflared schic
    `ft-over-ds=no`, Soll `yes` (`ft=yes` ist korrekt). **Kam mit dem 7.24.1-Upgrade.** Braucht eine
    Entscheidung — Gerät korrigieren *oder* neuen Wert zum Soll erklären — plus Re-Provisionierung der
    CAPs. ⚠️ **Kein Re-Baseline ohne Entscheid**, das macht die Drift-Erkennung wertlos.
-2. 🆕 **TP-Vorschlag (Christoph 2026-08-31, noch nicht angelegt): dedizierter untagged-VLAN99-Port
+2. 🆕 **[TP37](teilprojekte.md#tp37) — OOB-Management, angelegt 2026-08-31.** Je ein untagged-VLAN99-Port
-   auf beiden Switches.** Auslöser ist eine reale Beobachtung: **beim Core-Neustart war `crs326-branch`
+   auf beiden Switches (Kandidat `ether23`, auf core **und** branch frei). Auslöser: beim Core-Neustart
-   nicht mehr erreichbar**, weil das Management über den Core läuft. Ein Out-of-Band-Zugang je Switch
+   war `crs326-branch` nicht erreichbar, weil sein Mgmt **ausschließlich** über den Core läuft.
-   (ein Port, untagged VLAN99, Laptop direkt) macht den Branch unabhängig vom Core.
+   🔴 Nebenbefund mit eigenem Gewicht: **der Branch hat gar keine `input`-Firewallregeln** — sein Schutz
-   **Bewusst nicht eigenmächtig angelegt** (TP-Management-Konvention: vorschlagen, abstimmen, dann
+   ist heute allein die Erreichbarkeit über den gehärteten Core.
-   anlegen). ⇒ Nummer vergeben und Abschnitt schreiben, sobald Christoph zustimmt.
+   💡 **Berührt diese Session, ist aber keine Voraussetzung:** hier rebooten dreimal Geräte, deren Mgmt
-   💡 Berührt TP16.3 direkt: die Vor-Ort-Session rebootet dreimal Geräte, deren Mgmt am Core hängt.
+   am Core hängt. Wer vor Ort ist, kann `ether23` schon mal beschriften — gebaut wird TP37 separat.
 3. 🟡 **`mcp/mikromcp/config/routers.yaml` hält `rosVersion: "7.24"`** für alle fünf — jetzt `7.24.1`.
    ⚠️ **Die Datei liegt auf `main`, nicht auf diesem Branch** (der Worktree hat eine ältere Kopie
    **ohne** ap3). Der Fix gehört auf `main`, nicht hierher — sonst gibt es einen Konflikt.

docs/teilprojekte.md

@@ -40,6 +40,11 @@ liest, liest ihn als Erstes: er wird bei jeder Änderung mitgezogen, nicht nur d
   unterstellte einen Registry-Pull (`fetch: no` auf ap1/ap2) und enthielt eine **falsche**
   Firewall-Freigabe-Behauptung. **CF-Stand:** `bf-public` `inactive` / 0 Connectoren; die vier
   öffentlichen Namen laufen noch über bf-mm/bf-nas/bf-pve **an Caddy vorbei** direkt aufs Backend.
+- 🆕 **TP37 angelegt (2026-08-31):** OOB-Management — je ein untagged-VLAN99-Port auf beiden Switches.
+  Auslöser: beim Core-Neustart war `crs326-branch` nicht erreichbar, weil sein Mgmt **ausschließlich**
+  über den Core läuft (`vlan99` dort `tagged=ether1,ether24,bridge`, kein untagged-Member).
+  🔴 **Nebenbefund mit eigenem Gewicht: `crs326-branch` hat gar keine `input`-Firewallregeln** — sein
+  Schutz ist heute allein die Erreichbarkeit über den gehärteten Core. Das ist die Hauptauflage des TPs.
 - 🆕 **ROS-Upgrade 7.24.1 auf allen fünf (2026-08-31, User).** In Nautobot nachgezogen: **ap1** stand
   als einziges Gerät noch auf `7.24` (die anderen vier waren schon richtig) ⇒ auf `7.24.1` gesetzt.
   🔴 **Eine Drift kam mit dem Upgrade: `crs326-core` / `wifi-security`** — `sec-main` hat am Gerät
@@ -252,6 +257,7 @@ nachmessen und dann entscheiden**. Blocker gibt es keine mehr. TP5 ist in der Na
 > | TP34 | 🔜 | Caddyfile via Nautobot/GC (Stub, Inventur-Handoff 2026-08-27) | — |
 > | TP35 | ⏳ | MCP-Schichtung + 3-Schicht-CLAUDE.md + Backup-Guard (Schicht 1+3+6 ✅) | — |
 > | TP36 | 🔜 | SSoT via Nautobot für teilprojekte.md-Live-Daten + Datei-Aufteilung | — |
+> | TP37 | 🔜 | OOB-Mgmt: untagged-VLAN99-Port je Switch | — |
 > | — | — | **34 archivierte TPs** in `teilprojekte-archiv.md` | — |
 
 ### TP5.1 — DNS-Visibility & Flow-Observability für Low-Trust-Geräte (Airfryer-Fall) ▸ vorgemerkt
@@ -1869,6 +1875,78 @@ kann in Ruhe nachziehen.
 - **Verzahnt mit:** TP22 (Nautobot-GC als Vorbild), TP35 (geht Hand in Hand — beide sind „SSoT + Konsolidierung"), `bf-infra/CLAUDE.md`-Lessons.
 - **Referenzen:** Lessons-Block-Eintrag „Manuell gepflegte Doku mit Live-Daten verliert gegen die Realität" · Handoff Session A 2026-08-28.
 
+<a id="tp37"></a>
+### TP37 — Out-of-Band-Management: ein untagged-VLAN99-Port je Switch ▸ 🔜 **ANGELEGT 2026-08-31**
+
+> **Auslöser (User 2026-08-31, aus eigener Anschauung):** *„ich durfte beim Neustart vom core gerade
+> erleben, dass ich nicht mehr auf den branch zum verbinden kam. weil das eben alles über den core
+> läuft."*
+
+#### Der Befund, live nachgemessen (2026-08-31)
+Das Management des Standorts hat **einen einzigen Weg**, und der führt über den Core:
+
+| | `crs326-core` | `crs326-branch` |
+|---|---|---|
+| Mgmt-IP | `10.40.99.1` (VLAN99-SVI) | `10.40.99.2` (`vlan99` auf der Bridge) |
+| VLAN99 auf der Bridge | SVI + Trunks | **`tagged=ether1,ether24,bridge`**, `untagged=""` |
+| Weg dorthin | direkt | **nur über `ether1` → core `ether8`** |
+
+⇒ **`crs326-branch` ist ausschließlich durch den Core hindurch erreichbar.** Rebootet der Core, ist der
+Branch für die Dauer weg — nicht weil er ausfällt, sondern weil der einzige Pfad zu ihm fehlt. Dasselbe
+gilt für jeden Fehler, der den Core-Trunk oder dessen VLAN99-Konfiguration betrifft. **Wer den Core
+zerkonfiguriert, verliert den Branch gleich mit** — und damit die Möglichkeit, es vom Branch aus zu
+reparieren.
+
+🔴 **Der zweite Befund ist der unangenehmere: `crs326-branch` hat KEINE `input`-Firewallregeln** (Kette
+leer, live gelesen). Sein gesamter Schutz besteht heute darin, dass VLAN99 nur über den Core erreichbar
+ist und **dessen** `forward`-Kette seit TP5 deny-by-default fährt. **Die Erreichbarkeitsbeschränkung
+IST die Zugangskontrolle.** Das ist für die Lösung unten kein Detail, sondern die Hauptauflage.
+
+#### Zielbild
+**Je Switch ein Port, untagged in VLAN99** — ein Laptop direkt daran erreicht das Gerät ohne jeden
+Umweg über den Core, ohne Trunk, ohne funktionierendes Routing.
+
+```
+Laptop ──(statische IP 10.40.99.x/24)── ether23 (untagged VLAN99) ── crs326-branch  10.40.99.2
+                                                                     ^ funktioniert auch, wenn der Core steht
+```
+
+**Kandidat `ether23` auf beiden Geräten** — auf core **und** branch heute `running=false`, also frei,
+und symmetrisch (ein Port, eine Nummer, an beiden Standorten dieselbe). *(Core hat reichlich freie
+Ports; auf dem Branch sind `ether23` und die Reihe darunter frei, `ether24` ist ap2.)*
+
+#### Umsetzung (Skizze — eigene Session)
+1. **Port aus dem Trunk-Verhalten nehmen und in VLAN99 untaggen:**
+   `bridge port` mit `pvid=99` + `frame-types=admit-only-untagged-and-priority-tagged`,
+   dazu `ether23` als `untagged`-Member in die `bridge vlan`-Zeile für VLAN99.
+2. **Kein DHCP dort** — der VLAN99-DHCP läuft auf dem Core, und genau der soll ja nicht Voraussetzung
+   sein. ⇒ **statische IP am Laptop** (`10.40.99.50/24`), im Runbook mitschreiben.
+3. **Beschriftung.** Ein OOB-Port, den niemand erkennt, wird im Zweifel für „ist ja frei" gehalten.
+4. **Abnahme, die den Zweck wirklich prüft:** Laptop an `ether23` des Branch, **Core-Trunk `ether1`
+   gezogen** (oder Core im Reboot) → `10.40.99.2` muss antworten. Alles andere misst nur den Normalfall.
+
+#### 🔴 Auflage, ohne die das TP nicht gebaut werden darf
+Ein untagged-MGMT-Port ist **ein physischer Generalschlüssel**: wer ihn steckt, steht ungefiltert im
+Management-VLAN eines Geräts, das (Branch) keinerlei `input`-Filter hat. Deshalb gehört **eine** der
+folgenden Absicherungen dazu, und die Entscheidung darüber in die Umsetzungs-Session:
+- **Port `disabled=yes` im Normalbetrieb**, im Bedarfsfall am *anderen* Gerät freigeschaltet — schützt,
+  kostet aber genau dann Zugriff, wenn das andere Gerät weg ist (halbierter Nutzen, ehrlich benennen);
+- **oder** `input`-Regeln auf beiden Switches nachziehen (der Branch braucht sie ohnehin — das ist die
+  eigentliche Lücke, die dieses TP nebenbei aufgedeckt hat);
+- **oder** rein physisch: abschließbarer Schrank, Port beschriftet und dokumentiert.
+
+⚖️ **Meine Einschätzung:** die `input`-Regeln sind der richtige Weg, weil sie eine Lücke schließen, die
+**unabhängig von diesem TP** besteht. Der OOB-Port macht sie nur sichtbar.
+
+#### Abgrenzung
+- **Nicht** Teil von TP16.3 — dort wird nur festgestellt, dass dreimal Geräte rebooten, deren Mgmt am
+  Core hängt. TP37 entschärft das für künftige Sessions, ist aber **keine Voraussetzung** dafür.
+- **Nicht** VLAN-Schema-Änderung (TP32 bleibt unberührt), **nicht** Konsolen-/Serial-Zugang (das wäre
+  echtes OOB im engeren Sinn; hier geht es um ein zweites *Netz*-Bein).
+- **Abh.:** TP5 (Firewall-Systematik, liefert das Muster für die `input`-Regeln), TP15 (Portbelegung
+  beider CRS326), TP22 (die Umsetzung läuft über Golden Config, `ip-firewall-filter` und
+  `bridge`-Sektionen stehen unter Drift-Kontrolle).
+
 ---
 
 ## Abgeschlossene Teilprojekte ▸ [`teilprojekte-archiv.md`](teilprojekte-archiv.md)