Das Messrunbook verlangte einen kabelgebundenen VLAN10-Client, warnte aber
nicht vor WARP. Ein aktiver WARP-Client tunnelt alles durch Cloudflares
QUIC-Proxy -- gemessen waere der Tunnel statt der Leitung, und ICMP kaeme gar
nicht erst durch. Genau das ist hier schon zweimal passiert. Dazu die
Dual-Homing-Falle: das MacBook haelt zeitweise Leases in VLAN10 und VLAN20.
Beides steht jetzt als Vorbedingung vor Schritt 1, nicht als Fussnote.
Die Uebergabe traegt den live verifizierten Ist-Stand (92/92, 0 forward-Drops
heute), die fuer die Messung relevanten Randbedingungen -- Fasttrack ist
entschieden, /queue fehlt im Template, der Core ist ein 800-MHz-ARM -- und
was mit beiden moeglichen Ergebnissen zu tun ist.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der kritische Pfad widersprach sich selbst: der Einleitungsabsatz sagte seit
dem 18. "Praemisse offen, erst messen", Punkt 2 der Liste darunter sagte
weiter "keine offenen Blocker mehr". Punkt 2 nachgezogen.
Neu: docs/tp6-praemisse-messrunbook.md. Reproduziert die Methode von
2026-06-16 (3 Flows Saettigung + 24 Pings idle/Last), damit die Zahlen
vergleichbar sind, und misst erstmals die Download-Richtung -- die wurde
damals nie gemessen und ist beim asymmetrischen Kabelanschluss die
wahrscheinlichere Problemseite. Das Abbruchkriterium steht VOR der Messung:
A/A+ heisst TP6 wird geschlossen statt gebaut.
Fasttrack (die Entscheidung, die der Handoff Christoph vorbehalten hat):
bleibt wie er ist, gilt ab jetzt aber als Absicht statt als Unfall. Bei
~10 Mbit WAN kostet der Verzicht nichts, fuer CAKE ist er sogar die
bequemere Ausgangslage. Gegenbedingung notiert: wer Inter-VLAN je auf
Gigabit will, muss vorher messen, was die Core-CPU ohne Fasttrack traegt.
Damit sind zwei offene Stellen zu -- das "Entscheidung noetig" in TP6 und
die TP21-Warnung, dass das Re-Baseline den Zustand zum Soll erklaert hat.
Die Merkregel dort bleibt: dass es diesmal gut ausging, war Glueck.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
