Übergabe an die Doku-/Review-Session — Stand 2026-08-18, 06:30

Wofür das hier ist: Du hast in der Nacht auf den 18. eine Analyse gefahren und drei Befunde gemeldet. Alle drei waren richtig. Parallel lief eine zweite Session, die dieselben Dateien bearbeitet hat — daher dieses Dokument: es sagt dir, was inzwischen erledigt ist, was von deinen Befunden offen bleibt, und wo du weiterarbeiten kannst, ohne dass wir uns gegenseitig überschreiben.

1. Deine drei Befunde — Abgleich

✅ Befund 1: Doku-Drift — bestätigt, inzwischen behoben

Du hattest recht, und die Ursache war banal: die andere Session hat in der Nacht die TP-Abschnitte und CLAUDE.md nachgezogen, aber den „Ist-Stand (Kurz)"-Block oben in teilprojekte.md übersehen. Genau den Block, den eine frische Session zuerst liest.

Alle vier von dir genannten Punkte waren falsch und sind jetzt korrigiert:

stand dort	tatsächlich (live geprüft 08-18)
„reine Standalone-APs, kein CAPsMAN"	CAPsMAN auf dem Core seit 08-17 (TP28)
RouterOS 7.19.5 / 7.23	alle vier auf 7.24, RouterBOOT ebenfalls 7.24
DNS „plain 1.1.1.1"	DoH zum CF-Gateway, `verify-doh-cert=yes`
68/68 Compliance	92/92 bei 23 Rules, 0 Drifts

TP26/TP27 haben jetzt Abschnitte. Du hattest auch damit recht: beide existierten nur als Commits und .rsc-Dateien. TP27 ist Christophs eigene RouterBOOT-/7.24-Arbeit aus Commit b93514a — daher kam die 7.24, die im Ist-Stand-Block fehlte.

✅ Befund 2: TP6-Prämisse — bestätigt, jetzt im Dokument verankert

docs/call-quality-diagnosis.md sagt es sogar im Kopf: TP6 „hat sich als Nicht-QoS-Problem entpuppt". Dazu die Ergebnistabelle: CAKE / QoS | kein Bufferbloat-Spielraum | ❌ nicht deployt.

Das steht jetzt in TP6 selbst, samt der Einschränkung, die du selbst genannt hast (FritzBox-Ära, Edge seither getauscht). Der kritische Pfad ist entsprechend umformuliert: nächster Schritt ist eine Messung gegen den heutigen Edge, nicht der Bau einer Queue.

✅ Befund 3: Fasttrack — bestätigt, plus zwei Fakten, die du nicht wissen konntest

Live nachgezählt am 08-18:

2 accept                | defconf: accept est,rel,untracked | 32.979.171 Pakete
3 fasttrack-connection  | defconf: fasttrack                |          0 Pakete
0 von 445 Verbindungen fasttracked

Ergänzung 1 — es ist kein Zufall, sondern ein Cutover-Artefakt. ap1 hatte die Reihenfolge vor dem Cutover richtig (Fasttrack zuerst, MikroTik-defconf). Umgedreht wurde sie beim handgebauten Core-Aufbau in TP21.1.

Ergänzung 2 — seit dem 18. steht der Fehler als Absicht in der SoT. Das Re-Baseline (ingest-core-firewall.py --apply) nach TP5 E3/E4 hat die Reihenfolge unverändert nach Nautobot geschrieben, Rule ip-firewall-filter mit config_ordered=true. Das ist die Kehrseite dieses Werkzeugs: es erklärt den Ist-Stand zum Soll, ohne zu prüfen, ob der sinnvoll ist. Steht jetzt als Warnung in TP21.

Offen und bewusst nicht entschieden (gehört Christoph): Reihenfolge korrigieren · Fasttrack-Regel entfernen · so lassen. Vorher wäre zu messen, was Fasttrack-los den Inter-VLAN-Durchsatz kostet (NAS ↔ MAIN läuft geroutet über die Core-CPU). Für 10 Mbit WAN irrelevant, für Gigabit-Transfers nicht.

2. Was in der Nacht passiert ist (Kontext, den du sonst rekonstruieren müsstest)

Chronologisch, alles verifiziert und committet:

TP23 Stufe 1 — DoH auf dem Core. GTS Root R4 importiert (~1 KB statt CA-Bundle — der Core hat nur 2,8 MB freien Flash), verify-doh-cert=yes. ⚠️ Der Deploy meldete FAILURE, obwohl alles saß: /certificate import gibt failed: 0 aus, und der Job scannt den Output stumpf nach dem Wort.
TP23 Stufe 2 — AdGuard vorbereitet, bewusst NICHT scharf geschaltet. Conditional Upstreams, sechs CIDR-Gruppen, dns-bypass-exempt. Kein DHCP-Scope angefasst.
TP5 Etappe 2-Nachtrag. Das „die Log-Regel ist verstummt" von Etappe 2 stammte aus einem 70-Sekunden-Fenster und war falsch — über dreieinhalb Stunden liefen 119 Zeilen auf. Drei der vier Lücken hätten den Drop zum Ausfall gemacht, darunter: der Netmiko-Deploy kommt von 10.40.20.31 (nautobot-worker), nicht von .20.30.
TP5 Etappe 3 + 4 — deny-by-default in beiden Ketten. Abnahme: 11 gedroppte Pakete in 15 Minuten, alle von der eigenen Sonde. Die 5 mDNS-input-Regeln sind dadurch erstmals scharf.
NTP. Der Standort hatte nirgends eine funktionierende Zeitsynchronisation. Jetzt: Core als Quelle, DHCP-Option 42, ComplianceRule system-ntp.
TP7.1 — SSDP-Relay als LXC 108 auf pve. User-bestätigt: „sonos ist da!"
TP28-Rest — GC-Modell auf CAPsMAN umgebaut. Die APs trugen noch die komplette Standalone-WLAN-Config aus TP3; abgeräumt.
TP19 und TP3.2 geschlossen.

⚠️ Korrektur zu Punkt 7 — und die wichtigste Lehre der ganzen Nacht

Ich hatte den AP-Cleanup mit „30 Clients vorher, 30 nachher, kein Aussetzer" abgenommen. Das war der falsche Maßstab. Parallel lief bereits ein Ausfall, den genau diese Zahl verdeckt hat:

Seit dem CAPsMAN-Cutover vom 08-17 war /interface wifi cap slaves-datapath auf beiden APs leer — das einzige Feld, das die vom Manager erzeugten Slave-VAPs lokal in die Bridge hängt. Der Core schickt datapath.bridge=bridge mit, der CAP übernimmt davon aber nur die vlan-id. Folge: -iot, -media, -untrusted und -guest hingen in gar keiner Bridge. Clients assoziierten sauber und bekamen nie DHCP — 14 Stunden lang. dirtyvader-main lief weiter, weil wifi1/wifi2 statische Bridge-Ports sind, und hat den Ausfall getarnt.

Gefunden und behoben hat es Christoph am 08-18 um 09:13 (Commit 1ba8260): dp-caps-slaves (bridge=bridge, bewusst ohne vlan-id) + slaves-datapath darauf, auf beiden APs.

Zwei Konsequenzen, die du kennen solltest:

Die Registration-Table ist kein Abnahmekriterium. Sie zeigte während des Ausfalls zufriedene IOT-Clients — und ich habe damit „kein Aussetzer" attestiert. Richtig ist eine frische DHCP-Lease pro SSID. Steht inzwischen so in CLAUDE.md.
Es war nicht die TP5-Härtung, obwohl der zeitliche Zusammenfall das nahelegt: torch auf vlan30 am Core war leer und der TP5-Drop-Log zeigte nichts. Beides leer heißt: es kommt nichts an, es wird nichts verworfen → L2-Problem, nicht Firewall. Diese Merkregel steht jetzt ebenfalls in CLAUDE.md und ist bei künftigen „connect ok, kein DHCP"-Fällen der erste Griff.

Nautobot-Betrieb: der Stack hat sich zweimal selbst umgebracht. Ursache war der Image-Healthcheck (voller Django-Start alle 10 s, Aufrufe stapeln sich → ENOMEM → DSM räumt ab), nicht Celery. Behoben. Steht in TP21.

3. Arbeitsteilung — damit wir uns nicht überschreiben

docs/teilprojekte.md ist die einzige Datei, die beide Sessions anfassen wollen. In der Nacht wurde sie viermal committet.

Vorschlag: die andere Session hält sich ab jetzt von teilprojekte.md fern, solange du daran arbeitest. Vor jedem Edit git pull, danach zügig committen — der Stand ist auf gitea/main gepusht.

Was für dich sinnvoll offen liegt

Doku-Konsistenz weiter prüfen. Du hast den Ist-Stand-Block gefunden; wahrscheinlich gibt es mehr davon. Lohnende Kandidaten: docs/ip-plan.md (enthält noch 10.40.41.x-Zeilen aus der VLAN1-Ära), docs/doku-cleanup-session.md Punkt E (laut Follow-up-Liste „teilweise"), und die Memory-Dateien — mehrere behaupten noch „kein CAPsMAN".
TP13 / TP14.4 / TP16.3 — die hattest du bereits offen. TP14.4 (CF-Access-Service-Token rotieren) ist unverändert offen, TP16.3 ebenfalls (Recherche durch, Umsetzung offen).
Nicht anfassen ohne Rücksprache: die Fasttrack-Reihenfolge (Entscheidung gehört Christoph) und alles, was einen GC-Push auslöst — die Compliance steht gerade auf 92/92 und das sollte sie bleiben.

Zwei Regeln, die in der Nacht teuer erkauft wurden

Job-Status ist kein Wirksamkeitsnachweis. Zweimal meldete ein Plan „Completed", ohne etwas zu ändern ([find !dynamic] ist auf /interface wifi configuration ein Syntaxfehler, kein Filter), und einmal „FAILURE", obwohl alles saß. Nur die Gegenprüfung am Gerät zählt — --assert nutzen.
Ein Zählerstand über 70 Sekunden ist keine Messung. Siehe TP5 oben.

8.3 KiB Raw Blame History