Voice Quality Collapse Because Video Is Being Classified as EF

The suspicious number is the offer rate: ef is receiving 700 Mbps while the contract only guarantees 300 Mbps of voice. The ef queue is strict-high with a 500 Mbps ceiling, so everything above the ceiling is tail-dropped, and voice shares that drop with whatever else was admitted to ef. Nothing is wrong with the physical link (6.5 Gbps on 10 Gbps) or with be/af41; the problem is classification, not scheduling capacity.

Verify in this order:

1. show class-of-service interface ge-0/0/1 - confirm which classifier is attached to the unit; a lone dscp BA classifier is the likely answer.
2. show class-of-service classifier name <name> - show that DSCP 46 maps to ef. Once you see that, any sender marking 46 gets EF treatment.
3. show interfaces queue ge-0/0/1 at 14:00 versus 09:00 - the delta in ef throughput should match the video call volume, not the voice volume.
4. If you need hard proof of the source, apply a temporary counting filter on the ingress unit matching DSCP 46 and the video subnet, and read show firewall counters.

Do not raise the ef ceiling as the first action; that would give video strict priority over the customer's business traffic and hide the real defect.

Reclassify the video before it reaches the ef queue. Because the customer will not change markings, use a multifield classifier: a firewall filter on the ingress unit that matches the video source addresses (or the video signalling/media flows) and sets forwarding-class af41, applied as an input filter so it overrides the behavior-aggregate classifier result.

set firewall family inet filter VIDEO-RECLASS term v1 from source-address 203.0.113.0/24
set firewall family inet filter VIDEO-RECLASS term v1 then forwarding-class af41
set firewall family inet filter VIDEO-RECLASS term v1 then accept
set firewall family inet filter VIDEO-RECLASS term rest then accept
set interfaces ge-0/0/1 unit <n> family inet filter input VIDEO-RECLASS

Why not raise the ceiling: the 500 Mbps cap is the only thing protecting af41 and be from a strict-high queue. Raising it to 800 Mbps would admit the video as strict-priority traffic and let a non-contracted flow starve business traffic during peak, and it would breach the 300 Mbps EF guarantee by allowing far more traffic into that class. Reclassification brings ef back to roughly 280–300 Mbps of genuine voice, which fits comfortably under the existing ceiling and removes the drops without touching the scheduler.

Immediate validation, after commit confirmed:

1. show firewall on the PE - the VIDEO-RECLASS term counters must be incrementing, proving the filter is matching and applied on the right unit.
2. show class-of-service interface ge-0/0/1 - confirm the filter is attached to the correct logical unit and that the DSCP classifier is still present for everything else.
3. show interfaces queue ge-0/0/1 at 14:00 - ef should now sit near 300 Mbps with zero or near-zero drops; af41 should rise by roughly the video volume; be should be unaffected.
4. Confirm no unintended drops: the rest then accept term must exist, otherwise the filter silently discards all non-video traffic on that port.

Ongoing:

• Watch ef drop counters daily for a week and correlate any residual loss with the 14:00–16:00 window.
• Watch af41 against its 2 Gbps rate; if the video estate grows, af41 will start dropping and the answer is capacity, not reclassification.
• Confirm with the customer that MOS recovered and that it stays recovered during a larger all-hands call, since that is when the video load and voice load peak together.
• If a second video vendor appears later, extend the filter rather than relaxing the EF ceiling.