Applying QoS based on ToS on a switchport

[jlixfeld]

I'm trying to wrap my head around QoS and I guess I have to start at the beginning - classification. I have a TDM to IP device that sets a ToS value of 0x08 to packets before it forwards the frame out towards the LAN.

Now as I understand it, ToS is an IP tag so I'm having a hard time understanding whether or not a L2 switch can read the ToS bit, map it to CoS to send about the LAN to the router, at which point CoS is mapped to DSCP, shipped out the WAN to the far end router where DSCP is mapped back to CoS to it's destination port.

I understand that the next steps are Policing, Marking and Queuing, and I'll cross those bridges when I come to them, but at this point, I think I just need to understand how the classification works on an L2 switch. The switch in question is a 2970 running 12.2(25)SEB4.

Thanks in advance.

[jlixfeld]

I've been looking over all those options. Based on how I'm interpreting the configuration guide (http://www.cisco.com/en/US/docs/switches/lan/catalyst2970/software/release/12.2_25_se/configuration/guide/swqos.html#wp1022237) , I'm not sure they are what I need.

mls qos trust dscp would be used on a routed port or an SVI. This is a switchport.

no mls qos rewrite ip dscp is about rewriting a DSCP value, and I'm still at the point of trying to match an incoming DSCP value.

trust dscp from within the policy-map didn't seem to make any difference.

The switch certainly sees DSCP on the port though.

show mls qos int g0/16 shows the counters incrementing for the bits I expect them to increment on:

2970#show mls qos interface g0/16 statistics

GigabitEthernet0/16

dscp: incoming

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

0 - 4 : 0 0 5854 0 0

...

dscp: outgoing

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

0 - 4 : 5862 0 0 0 0

[Joseph W. Doherty]

Ah, great, a reference to the correct documentation!

It's information like "When QoS is enabled with the mls qos global configuration command and all other QoS settings are at their defaults, traffic is classified as best effort (the DSCP and CoS value is set to 0) without any policing. No policy maps are configured. The default port trust state on all ports is untrusted." within your reference that concerns me.

Information like the foregoing is also why I noted the "no mls qos rewrite ip dscp" since the reference document has:

"In software releases earlier than Cisco IOS Release 12.2(25)SE, if QoS is disabled, the DSCP value of the incoming IP packet is not modified. If QoS is enabled and you configure the interface to trust DSCP, the switch does not modify the DSCP value. If you configure the interface to trust CoS, the switch modifies the DSCP value according to the CoS-to-DSCP map.

In Cisco IOS Release 12.2(25)SE or later, the switch supports the DSCP transparency feature. It affects only the DSCP field of a packet at the egress. By default, DSCP transparency is disabled. The switch modifies the DSCP field in an incoming packet, and the DSCP field in the outgoing packet is based on the quality of service (QoS) configuration, including the port trust setting, policing and marking, and the DSCP-to-DSCP mutation map.

If DSCP transparency is enabled by using the no mls qos rewrite ip dscp command, the switch does not modify the DSCP field in the incoming packet, and the DSCP field in the outgoing packet is the same as that in the incoming packet."

The way I read the above, the switch does see the incoming ToS value, but it might reset it before your policy "sees" the DSCP value. If this is happening, we need the switch to preserve the DSCP value so you can classify using it.

With regard to "routed ports" and "mls qos trust dscp", does the 2970 support routing? I didn't think it did. So, it's unclear whether this information only applies to routed ports or any physical switchport.

Lastly, note the stats do indeed show bit 2 incrementing on input, but zero incrementing on output. This would seem to indicate the switch is reseting the ToS byte.

[jlixfeld]

Ok, so what you are saying makes sense now that I understand things a bit more. Those points in the configuration guide were lost on me the first couple of times I read through them.

I enabled DSCP transparency, and now I see the outbound DSCP value 2 counter incrementing:

2970#show mls qos int g0/16 statistics

GigabitEthernet0/16

dscp: incoming

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

0 - 4 : 0 0 785099 0 0

...

dscp: outgoing

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

0 - 4 : 1018 0 785099 0 0

That said, I still don't see my policy-map counters incrementing:

2970#show policy-map interface G0/16

GigabitEthernet0/16

Service-policy input: IPTube

Class-map: IPTube2 (match-all)

0 packets, 0 bytes

5 minute offered rate 0 bps

Match: ip dscp 2

Class-map: class-default (match-any)

0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: any

0 packets, 0 bytes

5 minute rate 0 bps

2970#

If I configure mls qos trust dscp on the port (routed or not) it disables the service-policy, which isn't the desired behavior.

[Joseph W. Doherty]

Don't know about the 2970, but I recall on the 3560/3750, they don't show policy-map stats correctly (the packet counters), as the routers do. Believe you need to use the mls stats command (as you've done). In other words, things might be working correctly now, as the latest mls stats command appears to confirm. What you might now try, setting the inbound DSCP values to a different DSCP values and see if the mls stats reflects the change. I.e. DSCP 2 to DSCP EF.

[jlixfeld]

The mls qos stats are not reflecting the change made to the policy map. I even set mls qos rewrite ip dscp to turn of transparency, but all that did was reset the outgoing DSCP value to 0, so I enabled transparency again:

!

no mls qos rewrite ip dscp

mls qos

!

class-map match-any IPTube

match ip dscp 2

!

!

policy-map IPTube

class IPTube

set dscp 1

!

interface GigabitEthernet0/16

description IPTUBE01

switchport access vlan 31

service-policy input IPTube

!

2970#show mls qos interface g0/16 statistics

GigabitEthernet0/16

dscp: incoming

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

0 - 4 : 0 0 12399 0 0

...

dscp: outgoing

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

0 - 4 : 14 0 12398 0 0

Not sure what the 14 outbound packets with DSCP 0 are all about. Maybe that's a counter issue.

[jlixfeld]

Any ideas on this?

Again, I have a device that marks packets with ToS 0x08 (or DSCP 0x02). I'm trying to take dscp 2 and rewrite it to dscp 46 without much success. The only thing I can think of is the mls qos rewrite, but enabling that sets outbound DSCP to 0x00, which is not the desired effect either.

!

no mls qos rewrite ip dscp

mls qos

!

class-map match-any IPTube

match ip dscp 2

!

policy-map IPTube

class IPTube

set dscp ef

!

interface GigabitEthernet0/16

description IPTUBE01

switchport access vlan 31

service-policy input IPTube

!

2970#show mls qos interface g0/16 statistics | i 45 - 49 | 0 - 4 | dscp

dscp: incoming

0 - 4 : 0 0 172174 0 0

45 - 49 : 0 0 0 0 0

dscp: outgoing

0 - 4 : 271 0 172131 0 0

45 - 49 : 0 0 0 0 0

!

mls qos rewrite ip dscp

!

2970#show mls qos int g0/16 statistics | i 0 - 4 | 45 - 49 | dscp

dscp: incoming

0 - 4 : 0 0 7017 0 0

45 - 49 : 0 0 0 0 0

dscp: outgoing

0 - 4 : 7024 0 0 0 0

45 - 49 : 0 0 0 0 0

[Joseph W. Doherty]

What do the mls stats look like on the actual egress interface (not the ingress interface)?

[jlixfeld]

G0/16 is the ingress, G0/12 is the egress.

This output is with rewrite disabled.

2970#show mls qos int g0/16 statistics | i 0 - 4 | 45 - 49 | dscp

dscp: incoming

0 - 4 : 0 0 6966 0 0

45 - 49 : 0 0 0 0 0

dscp: outgoing

0 - 4 : 9 0 6966 0 0

45 - 49 : 0 0 0 0 0

0 - 4 : 6966 0 0 0 0

0 - 4 : 6974 0 0 0 0

2970#show mls qos int g0/12 statistics | i 0 - 4 | 45 - 49 | dscp

dscp: incoming

0 - 4 : 956 0 6969 0 157

45 - 49 : 0 0 0 82 0

dscp: outgoing

0 - 4 : 1203 0 6969 0 4

45 - 49 : 0 0 0 90 0

0 - 4 : 8170 0 0 10 0

0 - 4 : 8218 0 0 0 0

This output is with rewrite enabled:

2970#show mls qos int g0/16 statistics | i 0 - 4 | 45 - 49 | dscp

dscp: incoming

0 - 4 : 0 0 10388 0 0

45 - 49 : 0 0 0 0 0

dscp: outgoing

0 - 4 : 10407 0 0 0 0

45 - 49 : 0 0 0 0 0

0 - 4 : 10389 0 0 0 0

0 - 4 : 10407 0 0 0 0

2970#show mls qos int g0/12 statistics | i 0 - 4 | 45 - 49 | dscp

dscp: incoming

0 - 4 : 1474 0 10391 0 54

45 - 49 : 0 0 0 30 0

dscp: outgoing

0 - 4 : 11887 0 0 0 0

45 - 49 : 0 0 0 30 0

0 - 4 : 11957 0 0 16 0

0 - 4 : 11928 0 0 0 0

This seems odd to me. How can the outgoing DSCP on both interfaces reset to 0 when rewrite is enabled, yet the incoming on both interfaces is still set to 2? i'd expect the incoming on G0/12 to be 0 if the outgoing on G0/16 is 0.

[Joseph W. Doherty]

Assuming the switch software is working correctly (Cisco's often does), I suspect we're just missing something simple, but not, at least to me, obvious. I suspect we're missing a statement or have an incorrect statmement either within the policy or external to the policy.

Not sure I can offer much more help.

Some other ideas, see the section "Configuring the DSCP Trust State on a Port Bordering Another QoS Domain" in your referenced document to try DSCP mutation mapping instead of class-maps and policy-maps.

Leave on the default gobal DSCP rewrite, and try a mls qos trust DSCP statment within the ingress interface.

Repost to the forum (there are so many responses on this current post, others might not look at it.)

If you have a support contract, open up a TAC case.

Sorry I haven't help you find the solution, beyond perhaps looking for DSCP value 2.

[jlixfeld]

Hi Joseph,

I tried the dscp mutation map and got pretty much the same results. Thanks for the tips.