admin/bf-infra

Go to file

Christoph Emsenhuber 5f38cc8b72 TP25 Fund F aufgeloest: geraeteseitig, kein Netzfehler

Kollektor am Manager (15-s-Takt, 29 Samples, 28 Clients). Von den drei
Kandidaten fallen zwei, und beide ohne Wartezeit:

- (b) DHCP-lease-time: tot. dhcp-v30 faehrt lease-time=1d, Renew bei
  12h -- kann 5:05 nicht erzeugen. Eine Abfrage, keine Messung.
- (a) periodischer VAP-Re-Apply: tot. Auf genau dem VAP, der angeblich
  alle 5:05 abwirft, standen drei Clients bei 16h51m Uptime, 25 von 28
  ueber 6h. Dafuer braucht es die vier Zyklen nicht -- ein einziges
  Sample mit 16h51m widerlegt einen 5-Minuten-Takt.
- (c) Geraet selbst: bleibt, ist aber nicht pruefbar.

Denn die zwei Fund-F-MACs sind schlicht weg: ARP status=failed, keine
Lease, nicht in der Registration-Table, HA kennt sie nicht. Merkregel
wie beim P750W -- erst pruefen ob das Geraet ueberhaupt da ist, bevor
ein periodisches Trennen als Funk-/Configfehler untersucht wird.

Nebenbefund: einziger Client mit Uptime-Ruecksetzer war der DTU
(54:F2:9F:12:51:F0) auf ap1, 43min Sitzung, bei -52 dBm. Nicht Fund F,
aber echt -- derselbe ESP-Ein-Radio-Mechanismus wie in der Transaktion
TP17.1-dtu-pin-ap2. Gehoert zur Neubewertung des Pins.

Rohdaten: docs/messdaten/tp25-fundf-20260824.log

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

2026-08-24 09:42:36 +02:00

Sideboard-Test zurueckgebaut, und was dabei nicht verschwindet

2026-08-22 19:13:26 +02:00

TP4 DNS: Entscheidung auf RouterOS-nativ + nur statische Records

2026-06-15 11:24:05 +02:00

TP25 Fund F aufgeloest: geraeteseitig, kein Netzfehler

2026-08-24 09:42:36 +02:00

feat 🔌 TP17 GO: 16 Shellys VLAN1→VLAN30 (Anker-Verfahren) + eco-Policy; TP17.2/TP19 angelegt

2026-07-13 17:27:56 +02:00

TP17.1 verworfen + s9 zurueckgebaut, eco_mode flottenweit aus

2026-08-23 21:12:46 +02:00

TP2 🔍 Profile-Analyse + TP4 vorgezogen

2026-06-15 19:00:40 +02:00

TP6.1 live: NAS-Sync weicht zurueck -- 40,8 auf 11,0 ms unter Last

2026-08-23 06:38:39 +02:00

TP2 ✅ Omada Controller deployed + omada-mcp staged: DS923/macvlan, pve-mcp eingetragen

2026-06-15 14:11:05 +02:00

TP6-Praemisse: Messrunbook + Fasttrack entschieden

2026-08-19 15:56:22 +02:00

docs 🧭 Governance „Config nur via Nautobot" + TP19.1-Stand (ap1-DNS ✅, ap2 vertagt), sw2-IP-Korrektur .41.181, VLAN99-Cutover-Guides sw1/sw2, TP15-Lieferung 17.07., TP20 an Komodo gebunden

2026-07-16 09:58:09 +02:00

Compliance 68/68 + TP24 (USV) ausgeloest + Doku auf den Stand nach dem Core-Cutover

2026-08-16 19:28:50 +02:00

.gitignore

AP-Pin fuer den Rundgang -- und drei Dinge, die dabei still falsch waren

2026-08-22 20:21:55 +02:00

.mcp.json

chore 🔌 gitea-mcp in .mcp.json registriert + TP17 Shelly-Migrationslog (16 Geräte VLAN1→VLAN30)

2026-07-13 19:58:37 +02:00

CLAUDE.md

TP17.1 verworfen + s9 zurueckgebaut, eco_mode flottenweit aus

2026-08-23 21:12:46 +02:00

HANDOVER.md

CLAUDE.md: auto-geladener Session-Kontext (VLAN, HW, Tooling, Gotchas)

2026-06-15 10:45:42 +02:00

PLAN.md

TP21: Plan aktualisiert — IP-Schema core .99.1, branch .99.2, ap1 .99.11, ap2 .99.12

2026-08-08 09:46:38 +02:00

README.md

Docs: core-switch-prep auf aktuellen Stand bringen

2026-06-09 19:01:14 +02:00

README.md

bf-network-r6

BF-Netzwerk-Migration (Variante R6+C2). 2× MikroTik hAP ax² + Core ALL-SG8316M.

SSOT & Übergabe: HANDOVER.md — kompletter Status, Architektur + Begründungen, Phasen, Gotchas, Zugänge.

Plan-Origin: ~/.claude/plans/welche-kosteng-nstigen-alternativen-zu-memoized-sparkle.md

Struktur:

docs/vlan-plan.md — VLAN-/Adressplan (final)
docs/core-switch-prep.md — Core-Switch Status & Phasen
docs/firmware-flash-runbook.md — FW-Flash Historie
switch/cli/CLI-REFERENCE.md — bestätigte CLI-Syntax
switch/cli/*.cli / *.exp — reproduzierbare Konfig-Scripts
inventory/bf.csv / bf.md — IP-Doku (aus IPs.xlsx gespiegelt)
inventory/bf-core-ports.csv / .md — Switch-Port-Map

Aktueller Stand (2026-06-09):

Phase A (VLAN-Vorbereitung) ✅ abgeschlossen
Phase B (hAP-Cutover) ⏳ wartet auf MikroTik-Lieferung
Phase C (Firewall) + Phase D (Adress-Migration) ausstehend