QoS for VoIP Across an MPLS WAN

Voice over IP only works if the network treats voice packets differently from everything else. Voice is small, regular, and intolerant of delay or loss. Bulk file transfer is large, bursty, and does not care if a packet shows up 200ms later. QoS is the set of techniques that lets one router carry both and keep the voice call sounding like a phone call. This post covers the QoS chain end-to-end across an MPLS WAN, what each component does, and the DSCP-to-CoS mapping that ties the LAN and WAN sides together.

For QoS fundamentals at the LAN side, see the QoS complete guide. For the MPLS WAN technology this rides over, see the MPLS pillar.

The three things voice needs

QoS is the toolkit to keep all three numbers inside the bounds. The G.711 voice codec, the most forgiving of the common codecs, starts to sound bad above 150ms one-way latency or 1% loss. More aggressive codecs (G.729, Opus low-rate) are less tolerant.

The QoS chain across an MPLS WAN

A voice packet leaves an IP phone, crosses the LAN, hits the WAN edge, traverses the MPLS L3VPN, exits at the remote PE, crosses the remote LAN, arrives at the destination phone. Each hop applies some piece of QoS.

Notice the carrier piece in the middle. Once you hand the packet to MPLS, the carrier's network is treating it based on EXP bits, not DSCP. If you mark DSCP correctly but the PE-CE mapping is wrong, your voice traffic crosses the carrier's network as best-effort and you have no QoS at all over the bit you do not own. This is why carrier coordination matters.

DSCP marking standards

Most enterprises follow the RFC 4594 recommendations for DSCP marking, with some Cisco-specific aliases. The relevant rows:

Two things to know about EF specifically. First, EF is the only DSCP that should go into a Low-Latency Queue (LLQ) with strict priority. Everything else uses a Class-Based Weighted Fair Queue (CBWFQ) with bandwidth reservations. Second, the LLQ is policed: even though it has strict priority, you cap its bandwidth so that voice cannot starve everything else if a flood of EF-marked traffic arrives.

A minimum viable WAN-edge QoS policy

This is the smallest policy that actually works for VoIP across a contended WAN circuit. Adjust the numbers for your link rate and call volume.

! Classify traffic by DSCP marking
class-map match-any VOICE-RTP
 match dscp ef
class-map match-any VOICE-SIGNAL
 match dscp cs3
class-map match-any VIDEO
 match dscp af41
class-map match-any MISSION-CRITICAL
 match dscp cs4
class-map match-any NETWORK-CONTROL
 match dscp cs6
!
! Build a child policy for the queues
policy-map CHILD-WAN-QOS
 class VOICE-RTP
  priority percent 20
 class VIDEO
  bandwidth percent 25
 class MISSION-CRITICAL
  bandwidth percent 20
 class VOICE-SIGNAL
  bandwidth percent 5
 class NETWORK-CONTROL
  bandwidth percent 5
 class class-default
  bandwidth percent 25
  random-detect dscp-based
!
! Parent policy: shape to subscribed CIR, then run the child policy
policy-map PARENT-WAN-QOS
 class class-default
  shape average 50000000
  service-policy CHILD-WAN-QOS
!
interface GigabitEthernet0/0/0
 description WAN uplink to MPLS PE
 service-policy output PARENT-WAN-QOS

Key things in that config:

• Shape, then queue. The parent shapes outbound traffic to the CIR you bought from the carrier (50 Mbps here). The child policy operates inside that shaped envelope. Without shaping, queues never fill and QoS never kicks in.
• LLQ via priority percent 20. 20% of the 50 Mbps (10 Mbps) reserved for voice with strict priority. Caps voice at 10 Mbps regardless of how many EF-marked packets arrive.
• WRED on the default class. Random Early Detection on best-effort traffic prevents TCP global synchronization (everyone retransmitting at once when a queue overflows).

The carrier-side mapping

The PE router at the carrier edge classifies your traffic and maps DSCP to MPLS EXP. This is the mapping that controls how your traffic is treated inside the carrier's core. A standard 6-class to 4-EXP mapping:

Your carrier almost certainly publishes their EXP mapping in a service description document. Ask for it during contract negotiation. If you mark differently from what they expect, your traffic falls into best-effort inside the core, and your LLQ at the edge does nothing for traffic that already crossed the LAN.

Verifying QoS is actually working

The single most useful command:

R1# show policy-map interface GigabitEthernet0/0/0

 GigabitEthernet0/0/0
  Service-policy output: PARENT-WAN-QOS

    Class-map: class-default (match-any)
      125003 packets, 158734129 bytes
      ...
      Service-policy : CHILD-WAN-QOS

        Class-map: VOICE-RTP (match-any)
          18472 packets, 2954520 bytes
          5 minute offered rate 1280000 bps, drop rate 0 bps
          Match: dscp ef (46)
          Priority: 20% (10000 kbps), burst bytes 250000, b/w exceed drops: 0

        Class-map: VIDEO (match-any)
          ...
          drop rate 0 bps

Two numbers to watch: drop rate per class (anything > 0 in voice is a problem) and b/w exceed drops on the priority class (anything > 0 means your priority cap is being hit, voice is being dropped).

Common failure modes

Key takeaways

QoS for VoIP across an MPLS WAN requires the LAN, the CE edge, and the PE all to agree on how voice is marked and queued. The phone marks DSCP EF. The CE has a parent-shaper plus child-policy with LLQ for voice. The PE maps DSCP to MPLS EXP per your carrier's contract. The MPLS core queues based on EXP. Verify with show policy-map interface and watch for drops. The single most common failure is mis-marking or no carrier-side EXP mapping, which means your edge QoS protects nothing inside the part of the path you do not own.

For QoS fundamentals, see the QoS pillar.