Hub Bandwidth Saturation After Voice Cutover
A retail chain has 40 branches on a hub-and-spoke SD-WAN overlay. Each branch has a 200 Mbps business internet circuit plus a 50 Mbps LTE backup. The hub has a single 1 Gbps internet circuit terminating the overlay. Branches run POS, back-office SaaS, and a newly added cloud-hosted VoIP service. After VoIP rollout, users report one-way audio and dropped calls during the 11:00-13:00 peak. Underlay latency and loss to the hub are nominal. Interface counters at the hub show the 1 Gbps circuit sustaining 940-980 Mbps inbound during peak. The branch LTE links are idle. Traffic policy currently sends all branch-to-branch and branch-to-datacenter traffic through the hub, and VoIP is marked EF with priority queuing on branch egress only.
1. Identify the most likely root cause of the voice degradation and explain why underlay health metrics look clean while calls fail.
Read the worked answer
The hub's single 1 Gbps circuit is the bottleneck. At 940-980 Mbps sustained inbound it is effectively saturated, so the hub's egress toward branches and the internet is oversubscribed. Voice quality depends on the path end-to-end, not on underlay latency/loss probes, which measure a small synthetic flow and can look fine while a saturated queue drops or delays EF packets.
Key reasoning:
- The LTE backups are idle, proving the overlay is not using all available capacity.
- VoIP is prioritized only on branch egress. On the hub, EF traffic competes with bulk branch-to-branch and branch-to-datacenter flows that are all hairpinned through the same circuit.
- Saturation at the hub causes bufferbloat and tail drop; voice sees jitter and loss even though the underlay RTT probe is nominal.
So the fix is capacity/path engineering, not a QoS tweak on the branch.
2. Propose a traffic-steering and overlay change that reduces hub load without sacrificing voice quality, and state how you would validate it.
Read the worked answer
Two levers, applied together:
- Stop hairpinning non-essential traffic. Branch-to-branch and branch-to-cloud-SaaS flows should use local internet breakout with regional/local steering rather than tromboning through the hub. Keep only flows that genuinely need hub inspection or central services on the hub path.
- Use the idle LTE links. Configure per-flow or per-tunnel load balancing so bulk/backup traffic uses LTE while voice stays on the primary. Better: enable a voice-specific path policy that prefers the lowest-jitter path and fails over to LTE when primary jitter/loss crosses threshold.
- Apply QoS on the hub egress too, not just branch egress, with EF strict priority and a shaper that reserves headroom (e.g., 80-85% of line rate) so EF never queues behind bulk.
Validation:
- Confirm hub inbound utilization drops below ~70% at peak.
- Verify LTE carries only the intended classes (not voice by default).
- Measure MOS/jitter on a sample of calls before/after; EF should show near-zero loss and low jitter.
- Check that failover to LTE still meets voice SLA when primary degrades.
3. A colleague proposes simply upgrading the hub circuit to 10 Gbps. Evaluate this as the sole fix.
Read the worked answer
It relieves the immediate symptom but is not the right sole fix:
- Cost and lead time are high for a 10x upgrade; the underlying architectural problem (all traffic hairpinned through one hub, idle LTE, QoS only at branch) remains.
- It does not fix voice QoS on the hub - a bigger pipe still queues EF behind bulk if no strict priority/shaper exists.
- No resilience gain: a single 10 Gbps circuit is still a single point of failure; the LTE links stay idle.
- Scaling: 40 branches today, but the design does not scale as branches or SaaS usage grow.
A defensible position: the upgrade may be justified as part of a broader plan, but only after local breakout, path-based steering, and hub-side QoS are in place. Measure post-optimization load before sizing the upgrade.