MPLS QoS Marking : The rebuttal

Earlier today Ivan Pepelnjak over at IOS Hints (url / @ioshints) posted a piece on his blog in which he mentioned the behaviour of MPLS QoS markings and how they don’t copy over upon label imposition at the edge-LSR (the post is here).

Having only looked at this very same topic a couple of weeks ago I was almost certain that this was not the case, and so I set out to lab it out and either prove myself or Ivan wrong….

My setup for this lab is as follows:

I’m not going to bother going into the basic configuration of MPLS or the underlying technologies used but rest assured they are all standard settings with nothing changed.

After this I added a fairly simple and easy policy-map to CE1 to mark all outgoing packets as DSCP EF (expedited forwarding)

CE1(config)#policy-map EF_set
CE1(config-pmap)#class class-default
CE1(config-pmap-c)#set dscp ef
!
CE1(config)#int f0/0
CE1(config-if)#service-policy output EF_set
!

Once this was implemented I pinged across from the F0/0 interface on CE1 across to the loopback interface on CE2, upon checking the packet using Wireshark we can see (picture below) that MPLS has indeed copied over the IP precedence bits from the IP packet into the EXP bits of the MPLS header.

The above screenshot shows the IP packet with a DSCP value of EF (101110) which when converted to IP Precedence is 5, which in turn is what the MPLS EXP bits are set to.

Then, to put my mind at ease that this wasn’t just a coincidence I then removed the policy-map from the Fa0/0 interface and did the same ping again, this then showing that if the DSCP value is not set in the IP header that nothing is copied over to the EXP bits.

I am not 100% sure if this is just that I am using an older IOS version (All are 3640’s with 12.4(16) ) or that I completely misread Ivan’s article but either way I thought it would be good to post this up here to see if anyone can suggest anything?

Follow-up #

Ivan re-checked his working and found that his original findings were wrong and that the behaviour above is also still valid on 15.1(M) and that there must have been some bug when he previously ran the test.