Implicit Null Erases EXP Before the Congested Egress
A carrier core runs LDP. PE1 classifies voice at ingress: DSCP EF is mapped to MPLS EXP 5, and core queuing trusts EXP. PE1 sends traffic to PE2 loopback 10.255.255.2/32. P1 is the penultimate hop for that prefix. After a change window, voice quality degrades only on PE2's access link. On P1, show mpls ldp bindings 10.255.255.2/32 shows local label 3, and show mpls forwarding-table shows a pop for that prefix. A capture between P1 and PE2 shows IP packets with DSCP EF; PE2's ingress QoS policy matches MPLS EXP and has no match for those packets, so they enter the default queue. The design states that core devices trust EXP and that PE egress must preserve voice priority. The team proposes changing PE2's access policy to trust DSCP instead. You must diagnose the behavior and evaluate that proposal.
1. Why is the EXP field not visible at PE2, and why did the original ping and traceroute tests not expose the problem?
Read the worked answer
PE2 advertised the implicit-null label (label 3) for its loopback, so P1 performs penultimate hop popping. P1 removes the transport label before sending the frame to PE2. EXP is a field in the MPLS shim header; once the label is popped, there is no shim header and no EXP bits for PE2's ingress policy to match. The packet arrives as native IP with DSCP EF. Ping and traceroute test reachability, not per-hop QoS treatment. They can succeed while voice is queued in the default class, because the packet still reaches the destination. The symptom is therefore consistent with correct forwarding and incorrect QoS preservation, not with a routing or label-binding failure.
2. Compare configuring explicit-null on PE2 with classifying DSCP at PE2. Which do you recommend for this wholesale design?
Read the worked answer
Explicit-null makes PE2 advertise label 0 for its loopback instead of implicit null. P1 then sends label 0 rather than popping, so the shim header and EXP bits survive to PE2; PE2 pops label 0 and applies its EXP-based policy. This preserves the MPLS QoS model end to end and is the cleaner fit for a wholesale design where the carrier contracts on EXP treatment. It adds four bytes on the final hop and requires PE2 to be configured to advertise explicit null, usually under LDP for the loopback. Trusting DSCP at PE2 is simpler and avoids the extra label, but it shifts the contract to IP DSCP. That is risky if customer marking is untrusted, if DSCP is rewritten at a boundary, or if the carrier wants one QoS model across LDP and RSVP-TE cores. I would recommend explicit-null on PE2 for this design and keep DSCP trust only as a temporary workaround.
3. What commands would you use to confirm the label advertisement and the QoS classification before and after the change?
Read the worked answer
On PE2 and P1, check show mpls ldp bindings 10.255.255.2/32 to see whether the advertised label is 3 or 0. On P1, use show mpls forwarding-table 10.255.255.2/32 detail to confirm whether the operation is pop or swap to label 0. On PE2, verify the LDP explicit-null configuration and the ingress policy with show policy-map interface and a packet capture on the P1-PE2 link. After the change, the capture should show an MPLS header with EXP 5 and label 0, and the policy counters for the voice class should increment. Also check show mpls interfaces for label processing on the interface and confirm that PE2 still pops label 0 correctly.