5

This Q. is really confirmation to what I already suspect.

On a single physical interface with a carrier that uses two dot1q logical sub interfaces to handle DIA and L3VPN, I suspect any usage of DIA for data from branch offices (BOs) instead of backhauling renders QoS for voice (SIP and RTP) packets over L3VPN moot when it's needed.

Although I can mark voice packets for QoS over VPN, DIA traffic competes with that without DSCP so the physical circuit can be saturated and priority not given to voice. And since the congestion is already at the doorstep, not much can be done.

Are these assumptions true? Would it be better to just backhaul data over VPN so end-to-end QoS is unaffected as long as sufficient branch office bandwidth exists? BO DIA could still exist as a backup. What other viable and proven options exist to this classic problem?

All BO sites are part of full mesh MPLS-VPN and were required to have DIA before voice came into picture. Hosted VoIP provider can tie into this VPN or use SIP trunks from HQ. Provider is recommending uncompressed codec that eats up 90Kbps over compressed one at 30Kbps.

2

For ingress traffic into your CE/BO devices, you are correct - your markings are largely pointless, as ingress traffic is serviced on a first-come/first-serve basis and congestion will be already in play by that point.

It should be possible for your provider to enforce egress prioritisation between their PE interface and each of your CEs to give your voice traffic priority over any Internet downloads, but this would depend on how well provisioned their network is and the type of service you have purchased. Some charge extra to "enable qos".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.