Customer DSCP Marking Lost at the PE Trust Boundary
An enterprise customer connects to a PE router over a 1 Gb/s Ethernet SAP in a VPRN. The SLA defines three classes: voice at 20 Mb/s DSCP EF, video at 150 Mb/s DSCP AF41, and business data at 300 Mb/s DSCP CS3. The CE marks all three correctly. The PE has a SAP ingress QoS policy with one IP criterion matching the customer's server subnet and assigning forwarding class BE; there is no DSCP-based classification. In the MPLS core, the network QoS policy marks every packet with EXP 0. During a core congestion event, voice and video are delayed, and the customer's zero-marked backup traffic shows similar delay. The account team asks whether the core is under-provisioned. The core has 10 Gb/s links and average utilization of 55%.
1. Diagnose why the core is not necessarily under-provisioned and explain the trust-boundary problem.
Read the worked answer
The core may be fine. The PE policy matches only the server subnet and sends it to BE; there is no DSCP-based entry for EF, AF41, or CS3. All three SLA classes therefore enter BE, share the same queue and WRED profile, and the zero-marked backup is in the same treatment. In the MPLS core the network QoS policy sets EXP 0 for everything, so even a correct PE classification would be lost: core queuing uses EXP and forwarding class, not the original DSCP. A congestion event on 55%-utilized links can then produce delay for all classes because there is no differentiated per-hop behavior. The symptom is a policy and trust-boundary failure, not proof of under-provisioning.
2. Design the ingress classification and MPLS marking changes needed to enforce the SLA.
Read the worked answer
Define the SAP as untrusted at the edge unless the customer is contractually trusted. Add ingress classification entries: DSCP EF to FC EF with profile in; AF41 to AF; CS3 to a business FC such as L2; unmatched or zero-marked traffic to BE and optionally police to the 300 Mb/s data rate. Use DSCP match criteria, not just subnet, and place the entries in the correct SAP ingress policy. Then create a network QoS policy that maps FC and profile to MPLS EXP at network ingress, for example EF to 5, AF41 to 3, CS3 to 4, and maps back at egress. Apply it consistently on all PE and P routers. Verify per-FC counters and EXP values with a mirror or router capture; test congestion with a traffic generator.
3. The customer asks to keep zero markings and rely on the CE's DSCP for voice. What do you advise?
Read the worked answer
Do not rely on the CE's markings for a service that crosses an untrusted boundary. Zero-marked traffic cannot be assumed to be backup, and trusting it could let low-value traffic enter EF. Re-mark unmatched traffic to BE, or if the customer needs to control treatment, use a separate trusted SAP or contract with policing and clear marking rules. If zero-marked traffic is genuinely backup, map it to BE and consider a lower PIR. Confirm the behavior with counters showing zero-marked packets entering the BE queue, and document the marking agreement so later troubleshooting does not assume DSCP was preserved.