Solved: DSCP mutation map doesn't work

John Blakley · ‎04-30-2012

All,

I've been working on a 3560 that doesn't seem to map dscp values to a new value:

mls qos map dscp-mutation ToR1 22 24 to 46

Ingress interface:

interface FastEthernet0/1

mls qos cos 3

mls qos trust cos

end

Egress interface:

interface FastEthernet0/3

srr-queue bandwidth share 1 2 3 4

srr-queue bandwidth limit 10

mls qos trust dscp <--- tried with and without

mls qos dscp-mutation ToR1

end

Cos-dscp map:

cos: 0 1 2 3 4 5 6 7

--------------------------------

dscp: 0 8 16 24 32 40 48 56

Dscp-dscp mutation map:

ToR1:

d1 : d2 0 1 2 3 4 5 6 7 8 9

---------------------------------------

0 : 00 01 02 03 04 05 06 07 08 09

1 : 10 11 12 13 14 15 16 17 18 19

2 : 20 21 46 23 46 25 26 27 28 29

3 : 30 31 32 33 34 35 36 37 38 39

4 : 40 41 42 43 44 45 46 47 48 49

5 : 50 51 52 53 54 55 56 57 58 59

6 : 60 61 62 63

On the router on the other side, I created an acl that matched on dscp 46, but it doesn't match on it. Any ideas? I've tried moving the mutation map to the ingress interface and I've tried setting dscp with a service policy instead of marking COS and using internal dscp. Where is the mutation map supposed to be placed: ingress or egress?

Also, I added an entry in the acl on the router to see if I was mapping to dscp 24, and I am:

Extended IP access list 101

2 permit ip any any dscp cs3 (480497 matches)

3 permit ip any any dscp ef <---- No matches here though

So it seems like the mutation map is being ignored completely. Any reason why?

Thanks,

John

HTH, John *** Please rate all useful posts ***

Edison Ortiz · ‎05-01-2012

John,

I did a testing just before your last post and here are the configuration snippet:

I have a switch in the middle of 2 routers. On the router acting as client, I change the telnet tos to 60 which emulates cs3.

On the receiving router, I created an ACL to test the QoS tags.

On the switch, I created the global dscp mutation like you did but placed the interface level mutation at the ingress interface facing the client router.

Device ID Local Intrfce Holdtme Capability Platform Port ID

Rack1R3 Fas 0/3 129 R S I 2651XM Fas 0/0

interface FastEthernet0/3

switchport access vlan 6

switchport mode access

speed 100

duplex full

mls qos trust dscp

mls qos dscp-mutation ToR1

Device ID Local Intrfce Holdtme Capability Platform Port ID

Rack1R1 Fas 0/1 175 R S I 2651XM Fas 0/0

interface FastEthernet0/1

switchport access vlan 6

switchport mode access

mls qos map dscp-mutation ToR1 22 24 to 46

Dscp-dscp mutation map:

ToR1:

d1 : d2 0 1 2 3 4 5 6 7 8 9

---------------------------------------

0 : 00 01 02 03 04 05 06 07 08 09

1 : 10 11 12 13 14 15 16 17 18 19

2 : 20 21 46 23 46 25 26 27 28 29

On R3

ip telnet tos 60

From R3 to R1, doing telnet

Extended IP access list 102

10 permit ip any any dscp cs3 (507 matches)

20 permit ip any any dscp ef (633 matches)

30 permit ip any any (1794 matches)

Extended IP access list 102

10 permit ip any any dscp cs3 (507 matches)

20 permit ip any any dscp ef (642 matches)

30 permit ip any any (1797 matches)

View solution in original post

Edison Ortiz · ‎05-02-2012

j.blakley wrote:

It works, but with a few caveats that I see and maybe you can correct me.

I have a PC that's connected to a 3750. I was initially setting the switchport to cos 3 and letting the internal map switch to DSCP outbound (24). The dscp tag of 24 was definitely getting to the router, but once I put the mutation map in play, it started being seen at the router as default and no longer dscp 24.

My mutation map was "mls qos map dscp-mutation Test 22 24 to 42"

I changed the map to "mls qos map dscp-mutation Test 0 to 42" and applied that to the interface without trusting with "service-policy input Host".

access-list 105 permit ip host 10.15.21.50

class-map Host

match access-group 105

policy-map Host

class Host

set dscp default

I was being seen as default at the router: with and without the mutation-map applied.

Last test was removing any policy maps and not marking at all. This worked and remarked 0 as 42 and I started seeing it at the router. My conclusion is that the switch doesn't allow a conversion if you're marking the packet at the port whether it be COS marking or DSCP (policy map or internal dscp). Is this the case?

John,

Per your configuration, the device sending the packet does not apply the QoS tag. The switch is applying the QoS tag at ingress. In order for the mutation to work, the packet must have the matching QoS tag at ingress since as I explained, mutation takes places at ingress.

If the QoS tag is applied by the switch, the mutation check had already taken place - the order is mutation check goes before applying the QoS tag.

Thus, in order for your configuration to work, you need to configure the device sending the packet with the 'matching' QoS tag and you must apply the interface level configuration at the ingress port.

Hope this feature makes sense to you now

View solution in original post

John Blakley · ‎05-01-2012

Okay...I tried this on a 3750 as well with the same results. What am I missing? It should just be changing the outgoing dscp marking based off of my map, correct? DSCP rewrite is enabled in both cases....

Thanks,

John

HTH, John *** Please rate all useful posts ***

John Blakley · ‎05-01-2012

It works, but with a few caveats that I see and maybe you can correct me.

I have a PC that's connected to a 3750. I was initially setting the switchport to cos 3 and letting the internal map switch to DSCP outbound (24). The dscp tag of 24 was definitely getting to the router, but once I put the mutation map in play, it started being seen at the router as default and no longer dscp 24.

My mutation map was "mls qos map dscp-mutation Test 22 24 to 42"

I changed the map to "mls qos map dscp-mutation Test 0 to 42" and applied that to the interface without trusting with "service-policy input Host".

access-list 105 permit ip host 10.15.21.50

class-map Host

match access-group 105

policy-map Host

class Host

set dscp default

I was being seen as default at the router: with and without the mutation-map applied.

Last test was removing any policy maps and not marking at all. This worked and remarked 0 as 42 and I started seeing it at the router. My conclusion is that the switch doesn't allow a conversion if you're marking the packet at the port whether it be COS marking or DSCP (policy map or internal dscp). Is this the case?

HTH, John *** Please rate all useful posts ***

Edison Ortiz · ‎05-01-2012

John,

I did a testing just before your last post and here are the configuration snippet:

I have a switch in the middle of 2 routers. On the router acting as client, I change the telnet tos to 60 which emulates cs3.

On the receiving router, I created an ACL to test the QoS tags.

On the switch, I created the global dscp mutation like you did but placed the interface level mutation at the ingress interface facing the client router.

Device ID Local Intrfce Holdtme Capability Platform Port ID

Rack1R3 Fas 0/3 129 R S I 2651XM Fas 0/0

interface FastEthernet0/3

switchport access vlan 6

switchport mode access

speed 100

duplex full

mls qos trust dscp

mls qos dscp-mutation ToR1

Device ID Local Intrfce Holdtme Capability Platform Port ID

Rack1R1 Fas 0/1 175 R S I 2651XM Fas 0/0

interface FastEthernet0/1

switchport access vlan 6

switchport mode access

mls qos map dscp-mutation ToR1 22 24 to 46

Dscp-dscp mutation map:

ToR1:

d1 : d2 0 1 2 3 4 5 6 7 8 9

---------------------------------------

0 : 00 01 02 03 04 05 06 07 08 09

1 : 10 11 12 13 14 15 16 17 18 19

2 : 20 21 46 23 46 25 26 27 28 29

On R3

ip telnet tos 60

From R3 to R1, doing telnet

Extended IP access list 102

10 permit ip any any dscp cs3 (507 matches)

20 permit ip any any dscp ef (633 matches)

30 permit ip any any (1794 matches)

Extended IP access list 102

10 permit ip any any dscp cs3 (507 matches)

20 permit ip any any dscp ef (642 matches)

30 permit ip any any (1797 matches)

John Blakley · ‎05-01-2012

Thanks Edison. The only thing that I didnt do was set my outbound dscp from the routers perspective. Am I correct in assuming that the internal dscp won't rewrite using the mutation map? It does seem like it passes whatever tag it receives inbound and rewrites that, but to me it doesn't look like it will rewrite anything if the switch has already used a map for it. Is that the case?

Thanks for the response!

Sent from Cisco Technical Support iPhone App

HTH, John *** Please rate all useful posts ***

Edison Ortiz · ‎05-01-2012

With my example, the router was sending CS3 and while passing via the switch, the mutation took place.

The switch changed the tag from CS3 to EF while leaving towards the final destination.

Edison Ortiz · ‎05-02-2012

j.blakley wrote:

It works, but with a few caveats that I see and maybe you can correct me.

I have a PC that's connected to a 3750. I was initially setting the switchport to cos 3 and letting the internal map switch to DSCP outbound (24). The dscp tag of 24 was definitely getting to the router, but once I put the mutation map in play, it started being seen at the router as default and no longer dscp 24.

My mutation map was "mls qos map dscp-mutation Test 22 24 to 42"

I changed the map to "mls qos map dscp-mutation Test 0 to 42" and applied that to the interface without trusting with "service-policy input Host".

access-list 105 permit ip host 10.15.21.50

class-map Host

match access-group 105

policy-map Host

class Host

set dscp default

I was being seen as default at the router: with and without the mutation-map applied.

Last test was removing any policy maps and not marking at all. This worked and remarked 0 as 42 and I started seeing it at the router. My conclusion is that the switch doesn't allow a conversion if you're marking the packet at the port whether it be COS marking or DSCP (policy map or internal dscp). Is this the case?

John,

Per your configuration, the device sending the packet does not apply the QoS tag. The switch is applying the QoS tag at ingress. In order for the mutation to work, the packet must have the matching QoS tag at ingress since as I explained, mutation takes places at ingress.

If the QoS tag is applied by the switch, the mutation check had already taken place - the order is mutation check goes before applying the QoS tag.

Thus, in order for your configuration to work, you need to configure the device sending the packet with the 'matching' QoS tag and you must apply the interface level configuration at the ingress port.

Hope this feature makes sense to you now

John Blakley · ‎05-02-2012

It makes perfect sense now Thank you!!

HTH, John *** Please rate all useful posts ***