From 4c592ff8aca3b1a117e0297e7127bbae556128cc Mon Sep 17 00:00:00 2001 From: Howard Enos Date: Thu, 18 Jun 2026 18:50:34 -0700 Subject: [PATCH] sync: auto-sync from HOWARD-HOME at 2026-06-18 18:50:25 Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-18 18:50:25 --- .../network-optimization-master-plan.md | 7 +++++- .../docs/network/phase1-voice-qos-design.md | 24 +++++++++++++++---- 2 files changed, 25 insertions(+), 6 deletions(-) diff --git a/clients/cascades-tucson/docs/network/network-optimization-master-plan.md b/clients/cascades-tucson/docs/network/network-optimization-master-plan.md index 8c911758..a322b119 100644 --- a/clients/cascades-tucson/docs/network/network-optimization-master-plan.md +++ b/clients/cascades-tucson/docs/network/network-optimization-master-plan.md @@ -50,8 +50,13 @@ already too low) starves edge clients. **Sequence matters.** `radio-usage.sh cascades ng 77 > .claude/tmp/usage-pre.txt`. - Pick a watch AP per floor (`watch-ap.sh `). -### PHASE 1 — QoS for voice (do FIRST; orthogonal, lowest risk, guaranteed win) +### PHASE 1 — QoS for voice (orthogonal, lowest risk — but INSURANCE, not the everyday fix) Voice VLAN 30 is isolated → mark + prioritize it end-to-end so calls beat data under load. +> **Reframe (measured 2026-06-18):** WAN1 fiber upload is **~522 Mbps** vs ~98 Mbps peak usage — huge +> headroom, so the WAN is **not** the day-to-day voice bottleneck (that's RF, Phases 2–4). QoS still earns its +> place as insurance for **WAN2 (coax) failover** and **rare WAN1 saturation** (you hit 680 Mbps down). Build +> it (cheap, correct), but don't expect it to fix the complaints — the RF work does. Full design: +> `docs/network/phase1-voice-qos-design.md`. **Phones confirmed marking DSCP EF** → rely on DSCP; subnet match is the net. - **UniFi (WLAN/switch):** ensure WMM/QoS on; the AudioCodes/Poly tag voice DSCP — trust/honor it. On the USW, voice VLAN traffic should hit the high-priority queue. - **pfSense:** add a traffic-shaper/limiter or floating QoS rule that puts `VOICE net (10.0.30.0/24)` DSCP EF diff --git a/clients/cascades-tucson/docs/network/phase1-voice-qos-design.md b/clients/cascades-tucson/docs/network/phase1-voice-qos-design.md index 8f21f43f..26473df4 100644 --- a/clients/cascades-tucson/docs/network/phase1-voice-qos-design.md +++ b/clients/cascades-tucson/docs/network/phase1-voice-qos-design.md @@ -21,8 +21,21 @@ became possible because we isolated voice onto VLAN 30. - **Dual-WAN:** WAN1 `igc0` (Cox Fiber, primary, 1G link), WAN2 `igc3` (Cox Coax, 2.5G link); `WAN_Group` failover (`downlosslatency`). Shaping must be applied on **both** WAN interfaces. - pfSense Plus 25.07 (ALTQ shaper + dummynet limiters available). +- **Phones mark DSCP EF — CONFIRMED (Howard 2026-06-18).** So we can rely on DSCP for WMM (Layer 2) + switch + QoS (Layer 3); the `10.0.30.0/24` subnet match (Layer 1) is the safety net. **No pfSense set-DSCP rule needed.** -## Three layers (in priority order) +## Measured WAN bandwidth (2026-06-18) — REFRAMES QoS priority +- **WAN1 (fiber, primary): upload ~522 Mbps** (Cloudflare single-stream from pfSense). RRD 3-day peaks: + **680 Mbps down / 98 Mbps up** (actual usage). +- **WAN2 (coax): not measurable remotely** (source-route bind to `72.211.21.217` failed; needs a WAN2-routed + host or the Cox bill). Coax is typically asymmetric ~20–50 Mbps up — **size its shaper conservatively**. +- **Implication:** 30 calls ≈ ~3 Mbps. WAN1 upload (~522 Mbps) vs peak usage (98 Mbps) = **huge headroom → + the WAN is NOT the everyday voice bottleneck.** Everyday dropped-calls = **RF** (Phases 2–4 of the master + plan). **QoS here is INSURANCE, not the day-to-day fix** — it earns its keep in two cases: (1) **WAN2 + failover** (small coax upload + a big upload → real congestion), (2) **rare WAN1 saturation** (backup / + large upload; you do hit 680 Mbps down). Build it (cheap, correct), but set expectations: RF is the substance. + +## Three layers (priority order; Layer 1 = insurance, see reframe above) ### Layer 1 — pfSense WAN shaper (PRIMARY — this is where calls break) **Type: HFSC** (hierarchical, lets us guarantee voice a floor while letting it borrow idle bandwidth). @@ -47,10 +60,11 @@ critical direction for cloud-PBX voice, but do both. - Or manual: Firewall → Traffic Shaper → By Interface → add HFSC on WAN1 + WAN2, create the 3 queues, then Firewall → Rules → Floating → match `10.0.30.0/24` out → Ackqueue/Queue = qACK/qVoice. -> **INPUT NEEDED (the one missing number):** the **Cox plan UPLOAD speed** for WAN1 (fiber) and WAN2 (coax). -> Shape `qVoice`'s parent to ~**90–95% of actual upload** so the queue forms in pfSense (where we control -> priority), not at the ISP. The physical link is 1G/2.5G but the *plan* upload is what to shape to — get it -> from the Cox bill / a speedtest from a LAN host. Without it the shaper can't be sized correctly. +> **Sizing inputs:** WAN1 upload **~522 Mbps (measured 2026-06-18)** → shape `qVoice`'s parent to ~480–500 +> Mbps. **WAN2 (coax) upload still UNKNOWN** (remote source-route test failed) — get from the Cox bill or a +> speedtest from a host routed via WAN2; size conservatively (assume ~35 Mbps up until measured). Shaping to +> ~90–95% of actual upload keeps the queue in pfSense (where we control priority), not at the ISP. WAN2 is the +> one that actually constrains voice (on failover), so its number matters most. ### Layer 2 — UniFi WMM (the WiFi phones — Poly) Over the air, **WMM** maps DSCP → WiFi access categories; voice (DSCP EF/46) → **WMM Voice AC** (gets TXOP