We've been running Quantum SD-WAN for six months to manage our hybrid cloud links (AWS Direct Connect, two ISP fiber lines). The core requirement was flawless VoIP/QoS for our contact centers. The configuration is textbook, but we're seeing erratic MOS scores and intermittent one-way audio. The portal shows our policies are active, but the packet loss and jitter metrics don't align with the clean-looking config.
Our relevant policy looks like this:
```json
{
"rule-name": "VOICE_PRIORITY",
"service": "SIP, RTP",
"source": "10.10.50.0/24",
"destination": "10.10.100.0/24",
"action": {
"qos": {
"guaranteed-bandwidth": "10Mbps",
"priority": "real-time",
"dscp-marking": "EF"
}
},
"path-selection": "lowest-latency"
}
```
The observability gap is the problem. The GUI shows the rule is hitting, but the per-rule latency/jitter graphs are useless. We had to deploy our own probe endpoints and use Grafana with packet captures to confirm the issue: during congestion, RTP traffic is getting queued behind bulk data transfers despite the policy. It's as if the QoS queue isn't being respected on the egress interface of the Quantum appliance.
Has anyone else had to bypass the built-in reporting to prove QoS misbehavior? Specifically:
* Did you find a CLI command or hidden log that shows the actual queueing decisions in real-time?
* Are there known issues with certain software versions (we're on R81.20) and hardware platforms (1600 series) where QoS policies require a specific order or additional global setting?
* Is the "lowest-latency" path selection actually recalculating fast enough for VoIP, or is it sticking to a "best-effort" link even after latency spikes?
We're considering rolling back to a dedicated MPLS for voice, which defeats the purpose. Need concrete debugging steps, not vendor assurances.
-shift
shift left or go home
Classic case of the SD-WAN abstraction layer hiding the underlying transport reality. Your JSON policy configures the Quantum controller, but it's the edge appliance's local traffic shaping that's likely failing.
I've seen this before with "lowest-latency" path selection combined with guaranteed bandwidth. When the primary path's latency spikes, the traffic may flip to the secondary link. But if that secondary link's physical interface queue isn't honoring DSCP EF, your RTP gets dumped into the default FIFO. The portal shows the rule as "active" because the control plane processed it, but the data plane hardware is ignoring the marking.
Can you SSH into the appliance and run `show platform hardware qos interface GigabitEthernet0/1 statistics` (or similar)? Look for drops on the real-time queue. Often the built-in graphs only show L3 metrics, missing the L2 queue discards that kill voice quality.
Numbers don't lie
Spot on about the control plane vs. data plane disconnect. It's a painful lesson many of us learn the hard way.
A related gotcha I've seen is when an ISP's handoff strips or rewrites DSCP markings before the traffic even hits the WAN link. Your edge appliance might be perfectly configured, but if the ISP's network treats everything as best-effort after the CPE, your policy is just a nice picture in the portal. A quick packet capture on the WAN side can confirm if the EF markings are surviving.
user458's command suggestion is the right next step. Those hardware queue drops are rarely surfaced in the vendor's high-level dashboards.
Keep it constructive.
You've just described the fundamental lie of most SD-WAN marketing. They sell you a JSON policy abstraction while the actual packet scheduler on their cheap, off-the-shelf silicon is a black box. Your "guaranteed-bandwidth" and "real-time" priority are just suggestions to a best-effort Linux traffic control layer unless the vendor specifically implemented hardware offload for those markings.
Before you go spelunking in ISP handoffs, do a simple test. Set up an iPerf stream marked EF and a bulk TCP transfer on the same subnet, both routed through the appliance. If your voice traffic still gets smashed, the problem is inside the box, not the WAN. The fact that you needed your own Grafana setup to see this tells you everything about the value of their portal.
Throw out that "lowest-latency" path selection for voice. It's a trap. Constantly bouncing RTP streams between links to chase a 2ms difference creates more jitter than it solves. Pin it to your most stable circuit, even if it's not the absolute fastest, and use the other for failover only.
monoliths are not evil