diff --git a/docs/teilprojekte.md b/docs/teilprojekte.md index ea7cbb6..b58d9af 100644 --- a/docs/teilprojekte.md +++ b/docs/teilprojekte.md @@ -421,7 +421,7 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". - **(b) Live-Torch als Ad-hoc-Observability:** DNS ist bei direktem 1.1.1.1 blind, **Flows nicht** (NATen über ap1). `torch` auf `vlan30`/`vlan50` gefiltert auf die Geräte-IP zeigt Ziel-IPs live (Versuni → AWS `eu-west-1` IoT erkennbar). Voraussetzung: Gerät aktiv. Merkregel: Airfryer nur online wenn er kocht → Capture ans Einschalten koppeln. - **Abh.:** UNTRUSTED-Move des Airfryers (Kandidat, s. VLAN50) + TP5-Deny-by-default. Kein Blocker. -### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ 🟢 **BEANTWORTET 2026-08-23: CAKE ist baubar, wirkt technisch — und hilft nicht. Der Puffer gehoert nicht uns.** +### TP6 — QoS/CAKE + Call-Quality-A/B-Test ▸ ✅ **GESCHLOSSEN 2026-08-23 — gebaut, gemessen, wieder ausgebaut. CAKE wirkt, reicht aber nicht an die Ursache.** > 🔴 **A/B gemessen, gleicher Client, gleiche Methode, Minuten auseinander:** > > | Konfiguration | avg Latenz unter Upload-Last | @@ -549,6 +549,51 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". Ohne diese Zahl ist die übliche CAKE-Vorgabe „85–95 % Linerate" geraten. - **Abh.:** TP5 ✅ (keine Blocker mehr). Vorgelagert: die Messung oben. +### TP6.1 — Saettigung vermeiden statt Bufferbloat bekaempfen (Bulk-Uploads zuruecknehmen) ▸ 🟠 **VORSCHLAG 2026-08-23, aus dem TP6-Abschluss heraus** +> **Der Gedanke kommt von Christoph** („dann koennten wir zumindest den Sync von der NAS +> zurueckhalten“) und er trifft eine Luecke im TP6-Urteil. TP6 hat gezeigt: die ~30 ms +> Zusatzlatenz sind **nicht** wegzushapen, weil sie im DOCSIS-Uplink entstehen. Aber sie +> treten **nur unter Saettigung** auf — im Leerlauf misst dieselbe Strecke **12,9 ms**. +> +> ⚖️ **Damit ist das Ziel ein anderes: nicht die Latenz unter Last senken, sondern die Last +> gar nicht erst entstehen lassen.** Ein NAS-Sync, der bei laufendem Call zurueckweicht, +> haelt die Leitung aus der Saettigung — und dann liegt der Call bei 12,9 statt 42 ms. Das +> ist die Verbesserung, die CAKE nicht liefern konnte, und sie ist **groesser** als alles, was +> Bufferbloat-Bekaempfung hier je gebracht haette. +> +> ✅ **Die Vorarbeit ist erledigt und bewiesen** (TP6): der **Global-HTB-Weg funktioniert** auf +> diesem Geraet — `mangle chain=postrouting out-interface=vlan100 action=mark-packet` plus +> `/queue tree parent=global packet-mark=…`. Gemessen: zaehlt 6 MB, drosselt 9,3 → 7,78 Mbit. +> Der Interface-Weg (`parent=`) ist dagegen tot, s. TP6. +> +> **Entwurf (zu bauen, nicht gebaut):** ein Parent-Tree mit `max-limit` knapp unter der +> Linerate — nur so muss HTB ueberhaupt entscheiden — und darunter zwei Klassen: +> - `priority=8` **Bulk**: Upload **von der NAS** (`src-address=10.40.20.10`). Bewusst die +> Host-IP, **nicht** ganz VLAN20 — dort haengen auch HA, Nautobot und pve, die nicht +> pauschal hinten anstehen sollen. +> - `priority=1` **Rest**: alles andere, insbesondere Calls. +> +> 🔴 **Priorisierung, kein hartes Limit.** Ein festes Cap wuerde den Sync auch dann bremsen, +> wenn die Leitung frei ist. Prioritaet nimmt ihm die Bandbreite nur, solange jemand anders +> sie braucht — das ist genau die Bedingung, unter der es hier ueberhaupt weh tut. +> +> **Preis, ehrlich:** der Parent muss unter die Linerate shapen (~1 Mbit Spitze weniger, +> derselbe Preis wie bei CAKE), und Mangle kostet CPU pro Paket — bei 9,6 Mbit WAN irrelevant. +> +> 🔴 **Governance-Vorbedingung, dieselbe wie bei TP6:** `/ip firewall mangle` steht unter +> **keiner ComplianceRule**. Die Regeln waeren also unsichtbarer Drift. Vor dem Bau eine Rule +> `ip-firewall-mangle` anlegen — Muster liegt mit `nautobot/ingest-queue-rule.py` vor. Die +> Rule `queue` existiert bereits und deckt den Tree-Teil ab. +> +> 🔴 **Abnahme misst den Call, nicht die Queue:** Ping-Latenz waehrend eines echten +> NAS-Syncs, gegen die 12,9 ms idle. Ein Queue-Zaehler beweist hier gar nichts — genau der +> Fehler, der in TP6 eine Nacht gekostet hat (`feedback_abnahme_wirkung_nicht_anzeige`). +> **Vorher pruefen, ob der Fall ueberhaupt auftritt:** laeuft der Synology-Sync tatsaechlich +> ins offene Messer, oder drosselt DSM ihn ohnehin schon? Ohne diesen Nachweis waere TP6.1 +> eine Loesung auf Verdacht — und davon hatte TP6 genug. +> +> **Abh.:** keine harten. Erbt die Erkenntnisse aus TP6; blockiert nichts. + ### TP7 — Media-Discovery (mDNS) für VLAN 40 ▸ ✅ FERTIG (2026-07-02) — `docs/tp7-mdns.md` - ✅ **Built-in mDNS-Repeater** aktiv — **Live-Stand `crs326-core` (verifiziert 2026-08-14):** `mdns-repeat-ifaces=vlan10,vlan20,vlan30,vlan40,vlan90` → MAIN/INFRA/IOT/GUEST ↔ MEDIA. Reversibel (Feld leeren). @@ -2000,12 +2045,15 @@ FT kaschierte das bisher als „Roaming" statt „schwache Abdeckung". ## Reihenfolge / Abhängigkeiten -### 🎯 Kritischer Pfad (Stand 2026-08-22) +### 🎯 Kritischer Pfad (Stand 2026-08-23) — **LEER** ``` -TP5 E1 ✅ ─► E2 ✅ ─► E2-Nachtrag ✅ ─► E3 Drop ✅ ─► E4 input+MGMT ✅ ─► E5 MAIN→IOT ✅ ─► TP6 (CAKE) ◄ Ziel - ▲ - ab hier ist alles frei +TP5 E1 ✅ ─► E2 ✅ ─► E2-Nachtrag ✅ ─► E3 Drop ✅ ─► E4 input+MGMT ✅ ─► E5 MAIN→IOT ✅ ─► TP6 ✅ GESCHLOSSEN + + 🎯 DER KRITISCHE PFAD IST LEER (2026-08-23). + Das Projekt ist in seinem Kern fertig: deny-by-default steht, Golden Config + steht, WLAN steht, VLAN1 ist weg, und TP6 ist beantwortet statt offengelassen. + Was jetzt kommt, entscheidet Christoph — nichts blockiert mehr etwas. ``` > ➡️ **Update 2026-08-22 (Sitzungsende):** TP25 hat den Pfad seit dem 08-20 blockiert und ist im > Kern **erledigt** — die Terrasse ist repariert, der Dead Spot weg, Fund E abgestuft. Damit ist @@ -2041,7 +2089,14 @@ Ziel ist. Alles andere läuft nebenher und blockiert nichts. Anlernen eines IoT-Geraets (User 2026-08-17). Wer im IOT-SSID sitzt, ist im selben VLAN wie das Geraet und beruehrt die `forward`-Kette gar nicht; fuer Ad-hoc-Zugriffe aus MAIN gibt es jetzt die selbstverfallende Gruppe `jit-admin`. -2. 🟢 **TP6 — QoS/CAKE + Call-Quality-A/B-Test.** **Stand 2026-08-23: beantwortet** (s. TP6-Abschnitt). CAKE ist baubar und wirkt technisch, verbessert die Latenz aber bei keiner Bandbreite — der Puffer liegt im DOCSIS-Uplink. Offen ist nur noch der formale Abschluss (Queue entfernen, TP schliessen). ~~Das eigentliche Projektziel; **keine offenen Blocker mehr**.~~ +2. ✅ **TP6 — QoS/CAKE ▸ GESCHLOSSEN 2026-08-23.** Gebaut, gemessen, wieder ausgebaut. CAKE ist + auf diesem Geraet baubar (Global-HTB + Mangle) und wirkt technisch — verbessert die Latenz + unter Last aber bei **keiner** Bandbreite, auch nicht bei 52 % der Linerate. Der Puffer sitzt + im DOCSIS-Uplink, nicht im Router. Queue und Template-Block sind entfernt, die ComplianceRule + `queue` bleibt und bewacht den Abschnitt als leer. **Damit ist der kritische Pfad leer.** + 💡 Aus dem Abschluss ist **TP6.1** entstanden (Saettigung vermeiden statt Bufferbloat + bekaempfen) — Christophs Gedanke, den NAS-Sync zurueckzuhalten. Steht als Vorschlag, nicht + auf dem Pfad. ~~Das eigentliche Projektziel; **keine offenen Blocker mehr**.~~ **Korrigiert 2026-08-19:** kein *Blocker*, aber eine offene **Prämisse** — der Satz oben und dieser Punkt widersprachen sich seit dem 18. Richtig ist: der nächste Schritt ist eine **Messung**, kein Bau. Runbook liegt bereit: `docs/tp6-praemisse-messrunbook.md`. Fällt sie A/A+ aus, wird TP6 **geschlossen @@ -2065,6 +2120,9 @@ den Weg, über den man den Fehler zurücknehmen wollte. Datenpfad (im TP5-Log mit 137 Zeilen belegt); Container braucht nur noch der **öffentliche** Ingress. Vorschlag: `nautobot` als Probe aus dem CF-Ingress nehmen. - ~~**DoH-Cloudflare auf `crs326-core`**~~ ✅ **erledigt 2026-08-18** (TP23 Stufe 1 = TP21.1 TODO 1). +- **TP6.1 — Saettigung vermeiden (NEU 2026-08-23):** NAS-Sync per Prioritaet zuruecknehmen, + damit ein Call gar nicht erst in die Saettigung geraet (12,9 statt 42 ms). Vorarbeit aus TP6 + ist bewiesen; Vorbedingung ist eine ComplianceRule fuer `/ip firewall mangle`. - **TP24 — DC-USV** (seit 2026-08-16 eigener TP, aus TP15 herausgelöst). - ~~**TP19 — VLAN1-Client-Retirement / cudy-Teardown**~~ ✅ **geschlossen 2026-08-18** (VLAN1-ARP = 0). Die zwei Reste sind dorthin verschoben, wo sie hingehören: tote CF-Tunnel → TP16, HA-Portainer `setup_retry` → TP11. - ~~**TP3.3 — WLAN-Coverage-Kur**~~ → **in TP25 aufgegangen** (2026-08-17). 802.11k/v ist repariert (08-13); @@ -2099,7 +2157,7 @@ steht unten unter „Durch". Nachfolger ist **TP16.3**, das oben unter Follow-up TP1 · TP2 · TP2.1 · TP3 (Rebuild 2026-08-08) · TP3.1 · TP4 (Rolle seit 08-08 auf dem Core) · TP7 · TP7.2 · TP10 (Kern) · TP14 (+14.1/14.2/14.2a/14.3/14.5) · TP15 · TP16 (Kern) · TP17 · TP19.1 · TP20 · TP21 · TP21.1 · -TP22 · TP-R · **TP3.2** (08-17) · **TP5** (08-18) · **TP7.1** (08-18) · **TP19** (08-18) · **TP23 Stufe 1** (08-18) · **TP26** (08-17) · **TP27** (08-17/18) · **TP28** (08-17, GC-Modell 08-18). **Verworfen:** TP9 (Gateway-HA, User-Entscheid 2026-08-08). **Obsolet:** Omada-PVID-Fix +TP22 · TP-R · **TP3.2** (08-17) · **TP5** (08-18) · **TP7.1** (08-18) · **TP19** (08-18) · **TP23 Stufe 1** (08-18) · **TP6** (08-23, geschlossen statt gebaut) · **TP26** (08-17) · **TP27** (08-17/18) · **TP28** (08-17, GC-Modell 08-18). **Verworfen:** TP9 (Gateway-HA, User-Entscheid 2026-08-08). **Obsolet:** Omada-PVID-Fix (User-Entscheid 2026-07-22 — „nie wieder aufgreifen").
📜 Historische Fassung dieses Abschnitts (bis 2026-08-14 fortgeschrieben, hier bewusst erhalten) diff --git a/nautobot/mikrotik_routeros.j2 b/nautobot/mikrotik_routeros.j2 index ba37947..c2ec8ef 100644 --- a/nautobot/mikrotik_routeros.j2 +++ b/nautobot/mikrotik_routeros.j2 @@ -288,52 +288,31 @@ /ip address add address=100.96.0.6 comment="TP16.1 Mesh-Overlay" interface=cf-mesh network=100.96.0.6 /ip route add comment="TP16.1 Mesh" disabled=no distance=1 dst-address=100.96.0.0/12 gateway=cf-mesh -# [11] QoS / CAKE (TP6, 2026-08-23) — gebaut gegen eine Zahl, nicht gegen ein Ritual. +# [11] QoS — BEWUSST LEER (TP6 geschlossen 2026-08-23). # -# GEMESSEN am 2026-08-20/21 (tp6-praemisse-messrunbook.md §5), Linerate erstmals -# dokumentiert: Upload 9,6 Mbit, Download 54,6 Mbit. +# Hier stand einen Tag lang eine CAKE-Queue. Sie ist entfernt, weil sie GEMESSEN +# nichts gebracht hat — und das ist die Aussage dieses Abschnitts: # -# idle Upload-Last Download-Last -# Durchlauf 1 12,9 ms 60,4 ms 41,3 ms -# Referenz 06-16 12 ms 17,5 ms nie gemessen +# ohne CAKE 42,4 ms | 88 % 43,3 | 73 % 44,0 | 52 % der Linerate 44,6 (idle 12,9) # -# Der Anstieg liegt in der SENDERICHTUNG bei +28..+47 ms und damit ueber der -# §3-Schwelle von <=30 ms -> Fall B. Der Download liegt mit +23..+28 ms DARUNTER -# und ist damit nach demselben Kriterium Fall A. +# Selbst bei halber Linerate keine Verbesserung. Dort MUSS die Warteschlange im Router +# liegen — also entsteht die Zusatzlatenz stromabwaerts, im Arris/DOCSIS-Uplink +# (Request/Grant-Scheduling auf MAC-Layer, gar keine Queue). Kein Shaper hier erreicht das. # -# 🔴 Deshalb wird hier NUR die Senderichtung geshaped. Das ist keine Sparsamkeit, -# sondern dasselbe Abbruchkriterium in beide Richtungen angewandt: eine Queue fuer -# den Download waere gegen ein Problem gebaut, das die Messung nicht gezeigt hat. -# Ingress-Shaping kostet auf RouterOS ausserdem Mangle-Umwege, weil man die -# Gegenstelle nicht kontrolliert -- Aufwand fuer einen unbelegten Nutzen. +# 🔴 Zwei Dinge, die beim naechsten QoS-Gedanken Zeit sparen: +# 1. `/queue tree parent=` ist auf diesem Geraet WIRKUNGSLOS — MikroTik: +# "Interface HTB will not work correctly when the out-interface is hardware offloaded +# and the bridge Fast Path is not active." Der Weg ist `parent=global` + ein +# `mangle chain=postrouting out-interface=vlan100 action=mark-packet`. So gebaut +# zaehlt und drosselt es nachweislich (9,3 -> 7,78 Mbit bei cake-bandwidth=7M). +# 2. Eine Simple Queue auf `10.40.0.0/16` taugt hinter NAT NICHT als Probe: src-nat +# laeuft VOR der Simple Queue, das Target matcht nie. +# Merkregeln: Memory `ref_queue_htb_platzierung_docsis`. # -# 🔴 parent=vlan100, NICHT target=10.40.0.0/16. Eine simple queue auf das -# LAN-Supernetz wuerde auch INTER-VLAN-Verkehr erfassen (NAS <-> MAIN laeuft -# geroutet ueber dieselbe CPU) und ihn auf WAN-Tempo drosseln. vlan100 traegt -# ausschliesslich WAN-Verkehr, der Rest bleibt unberuehrt. -# -# Bandbreite = 8,5 Mbit ~= 88 % der gemessenen 9,6. CAKE muss die Warteschlange -# selbst halten koennen; bleibt der Puffer beim ISP, regelt es nichts. Der Preis -# sind ~1,1 Mbit Spitzendurchsatz und er ist im A/B-Nachweis sichtbar. -# -# cake-nat=yes ist hier kein Beiwerk: hinter srcnat saehe CAKE sonst nur EINE -# Adresse und koennte die Hosts nicht gegeneinander fair halten -- genau das ist -# aber der Zielfall ("jemand laedt hoch, waehrend jemand telefoniert"). -# cake-diffserv=diffserv4 trennt dabei latenzkritisch von bulk. -# -# ⚠️ Fasttrack ist auf diesem Geraet faktisch tot (accept steht vor fasttrack, -# 0 von 445 Verbindungen) und BLEIBT es -- Entscheid 2026-08-19, §4.2. Fasttrack -# umgeht Queues; fuer CAKE ist der Zustand die guenstigere Ausgangslage. Wer die -# Regelreihenfolge je "repariert", setzt diese Queue mit ausser Kraft. -# ⚠️ FORMAT: RouterOS exportiert `cake-bandwidth=8.5Mbps`, nicht `8500000` (gleiche -# Klasse wie `hw-offload=true` vs `yes`), UND schiebt vor die Tree-Zeile eine eigene -# Hinweiszeile. Dadurch flacht der Backup-Normalisierer `/queue tree` nicht ab: die -# add-Zeile steht ohne Pfad-Praefix da. Beide Eigenheiten muessen hier nachgebaut -# werden, sonst meldet die Compliance einen Dauer-Drift, bei dem das GERAET recht hat. -/queue type add cake-bandwidth=8.5Mbps cake-diffserv=diffserv4 cake-nat=yes kind=cake name=cake-wan-up -/queue tree -# CAKE type with bandwidth setting detected, configure traffic limits within queue itself -add comment="TP6: CAKE auf der Senderichtung (WAN-Egress)" name=qos-wan-up parent=vlan100 queue=cake-wan-up +# ⚖️ Was hier sehr wohl ginge und offen ist: nicht Bufferbloat bekaempfen, sondern +# Saettigung VERMEIDEN (Bulk-Uploads zuruecknehmen, damit ein Call gar nicht erst in +# die Saettigung geraet). Das ist ein anderes Ziel und steht als TP6.1. +# Die ComplianceRule `queue` BLEIBT — sie bewacht diesen Abschnitt weiter als leer. {% elif obj.role.name == "Switch" %} # ===================================================================================== # L2-Switch (crs326-branch) — Sollzustand des Mgmt-Layers.