Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

QoS best practise in MPLS

Hi, I'm having a scenarios for applying QoS on the entire customer network. Its something like this:

i. Equipment -> Layer2 SW -> PE VRF -> P

The equipment's traffics are not marked with anything at least, the equipment gateway would be the PE VRF. I'm thinking of such QoS in these scenarios:

i. PE ingress, match any based on the VRF and set dscp marking from here

ii. PE egress, match by the dscp marked @ the ingress interface and perform policing/shaping and then conversion to MPLS Experimental bit

iii. P ingress, implement congestion avoidance here, as far as I understand, congestion avoidance are based on dscp, if I perform DSCP convertion to EXP bit in the PE egress interface, would the P ingress interface still use the congestion avoidance?

I'm venturing into the possibility on how the QoS is best implemented in such scenarios, and appreciate if you guys with such experiences to shed some lights and ideas here...

Thanks and have a nice day

Hall of Fame Super Silver

Re: QoS best practise in MPLS

Hello Creed,

The PE on the access link can mark the DSCP field, out the PE MPLS backbone link the EXP bits are set on the MPLS outer label.

The P router will be able to manage congestion avoidance based on a mix of IP and MPLS traffic using DSCP or EXP bits, and using EXP bits for MPLS VPN traffic.

To be noted that the PE can even mark only the EXP bits lefting untouched the DSCP field in the IP packet if required.


This example shows how to set the experimental-bit value on the topmost label on input or output:

Router(config)# policy-map policy1

Router(config-pmap)# class class1

Router(config-pmap-c)# set mpls experimental topmost 5

Hope to help


New Member

Re: QoS best practise in MPLS

can I safely says the approach would be something like this?

@ the PE

Router(config)# policy-map policy1

Router(config-pmap)# class class1

Router(config-pmap-c)# configure the dscp marking

check-in this policy as input under the vrf table as this is where the traffic would initiate from the equipment

Router(config)# policy-map policy2

Router(config-pmap)# class class2

Router(config-pmap-c)# match the dscp marked @ the input vrf

Router(config-pmap-c)# set the mpls experimental topmost bit

Router(config-pmap-c)# policing the traffic based on bandwidth percent or CIR

check-in this policy as input @ the PE egress interfaces -> P routers, means the PE egress interface will perform the EXP marking based on the DSCP bit and perform the policing here, would be be efficient way of doing QoS?

Then from there onwards, P routers only based on the EXP bit to adjust the congestion avoidance? But I saw we can use random-detect dscp @ the P routers, is there any congestion avoidance using the EXP bit @ the P routers end? As if we set the EXP bit on the PE egress interface, P routers would not be able to configure congestion avoidance based on the DSCP right?

I'm just venturing out the easier and cleaner way to configure the QoS so configuration maintenance would be better in near future.

Thanks for your suggestion bro

Hall of Fame Super Silver

Re: QoS best practise in MPLS

Hello Creed,

actually you can mark at the edge.

The edge in a MPLS VPN L3 scenario is the VRF access link.

At the VRF access link you can mark the DSCP and/or directy mark the EXP bits in the MPLS label stack that will be used starting from link PE-P.

If you choice to mark the DSCP depending on your scenario this can mean different things:

the choice of a specific LSP, copying of a three bits subset of DSCP on the EXP bits (leftmost three in DSCP).

But this happens by default you don't need to explicitly configure the EXP marking.

About WRED: even if the syntax doesn't provide an EXP choice in the WRED commands the P router should be able to treat MPLS packets as expected.

How this happens can be a question of implementation.

I made functional and performance tests and I can say WRED works with a mix of IP and MPLS traffic as expected.

It can map EXP to DSCP EXP 000 for example and treat them according to setups for a DSCP field = EXP 000 i.e. a CSX in DSCP terminology. Or it can inspect the MPLS packet to find the DSCP field in the IP packet inside (less probable: the MPLS label stack depth can vary so this is less efficient)

Hope to help