MPLS QoS Basics
The EXP (Experimental) bits in the MPLS header are used for QoS. The EXP field is 3 bits long, which is the same length as the IPP field. (The IPP field is deprecated but the first three bits of the DSCP value map directly to an IPP value).
When an ingress PE does label imposition, it automatically copies the IP Precedence value in the IP header to the MPLS header EXP value. This is true for both IOS-XE and IOS-XR.
QoS for MPLS is very similar to regular QoS on IP traffic, except you match on the MPLS EXP value instead of DSCP, IPP, CoS, etc.
QoS Group
You should also be aware of the QoS Group feature, which is used to map an EXP value to a QoS Group, which is an internal “tag” put on the packet. This is used on the egress PE in order to apply policy to traffic without needing to classify IP traffic.
The problem that QoS group solves, is that the MPLS label has been popped off already when preforming shaping on the egress interface of the egress PE, so you can’t match the EXP value any longer. The solution is to map the EXP value to a QoS Group on ingress, and then shape the traffic on egress based on the QoS Group. The QoS Group is basically an internal placeholder. It is not a literal marking on the packet itself, but instead an internal marking associated with the packet and held in memory on the router. In the lab below we’ll use the QoS Group feature to solve the problem of shaping on the egress interface on the egress PE.
Lab
We’ll use a regular L3VPN topology, with an extra C router at each site (C1 and C2). Here are the startup configs:
If you’ve setup the inital lab correctly, you should be able to telnet from C1 to C2.
The customer has purchased QoS service from the SP. The SLA gaurantees that voice traffic will have 5mb and low latency, while data traffic will have 20mb and no latency gaurantee. The SP tells the customer that the voice traffic must be marked with IPP 5 or DSCP 46 (EF) in order to receive this treatment.
For this lab, we’ll use icmp as a substitute for voice traffic, and telnet as a substitute for general data traffic.
On the C routers, we’ll create an input policy that simply lets us count the IP Precedence markings on received traffic. We’ll use this to validate the markings on received traffic.
From C1, ping C2 and telnet to C2. Then check the counters on the class maps on the policy-map applied to Gi1.
Telnet automatically uses IP Precedence 6. This is because telnet is considered as network traffic. Network traffic is given the highest preference, IPP 6 and 7. We’ll need to re-mark this on the CEs in order to substitute telnet as voice traffic in our lab.
On CE1 and CE2, create an input service policy which matches IPP 6 and re-marks it as IPP 5.
Telnet from C1 to C2 again, and this time you should see the IPP_5 counters climb.
If we take a pcap at any point in the SP network, we can see that the IP Precedence is automatically mapped to the EXP field in all MPLS labels. Both the transport and service label reflect the IP Precedence value.
We’ll now configure the SP QoS policy which will reserve bandwidth and minimize delay for voice traffic.
Initiate telnet traffic between the C routers again. If you check any core routers, you should see the VOICE class counters incrementing. (XRv does not appear to work - it tells me that the service policy is not installed. I believe this is just a limitation of the virtual image. You can apply the policy in the config but it doesn’t actually take effect.)
The problem right now is that we are not applying the policy to the egress interfaces on PE1 and PE2 when they act as the egress PE. The router cannot look up the MPLS EXP field in this case, because the MPLS labels are already gone. Instead of classifying the traffic on egress, we can use the qos-group to classify the traffic on ingress and map it to a qos-group. We can then use the qos-group in the policy that is applied to the egress interface facing the CE.
The commit fails for me on XRv, however we can verify that this policy is working on PE1. Initiate the telnet traffic again and check the counters on both the input policy on Gi2 and output policy on Gi1.
Conclusion
This was a simple lab exercise to get some familiarity with how QoS works in a service provider’s MPLS network. We see that we can only have a maximum of 8 different queues or classes in the MPLS network, as the EXP field is only 3 bits long. By default the IP Precedence value on an IP packet is mapped to the EXP field when MPLS labels are imposed on an IP packet.
We can also use the QoS-Group feature to mark received packets which will have their labels popped off by the time they egress the other interface. This prevents us from having to classify the IP traffic on egress.
As you can see, the QoS tools we use for MPLS on IOS-XE and IOS-XR are extremely similar to QoS in the enterprise world.
Last updated