QoS/DSCP marking on a 3750G-EMI

[IanTarasevitsch1995]

Sorry to ask the stupid question, but I can't figure this out. I am running a converged LAN supporting about 1500 devices (1000 computers, 500 phones). I am running two 3750G-24TS switches (running 12.2(35)SE2) at Layer 3 as my core. They support all my voice and data SVIs. My routers on my WAN edge use DSCP markings for QoS on my outbound links.

I'm trying to move the DSCP marking off the routers and on to the multi-layer switches. I have the ACLs, class-maps, and policy-maps defined on the switch. IP CEF is enabled. I did remember to issue the global "mls qos" command. I did remember to attach the service-policy input on the interface I'm testing with. "Show mls qos" shows QoS enabled, and ip packet dscp rewrite enabled. "show mls qos interface g1/0/27" shows the correct policy-map attached to the interface, but shows 0 packets offered and the ACLs show 0 packets matched. I have tried attaching the service-policy on both the physical interfaces and on the SVIs. The only thing I'm trying to do on the 3750Gs right now is classify and mark -- I'm letting the routers use WRED to drop excess traffic. Any ideas why I'm not getting any matches? I'm guessing I missed a global command somewhere, but for the life of me, I can't figure it out.

Right now, I'm stuck doing the classification and DSCP marking on the ingress interfaces of the routers (3725s), and WRED on the egress interfaces. That works fine, so I think I've got the basic concepts down. Any thoughts?

[Edison Ortiz]

Can you post the relevant portion of the config ?

Thanks

[IanTarasevitsch1995]

Sure:

ip cef

!

mls qos

!

class-map match-all BulkData

match ip dscp default

class-map match-all VoiceSig

match ip dscp cs3

class-map match-all NetworkControl

match ip dscp cs6

class-map match-all CriticalServers

match access-group name CriticalServers

class-map match-all VoIP

match ip dscp ef

class-map match-all Video

match access-group name Video

!

policy-map DataMark

class CriticalServers

set dscp af31

class Video

set dscp af32

class BulkData

set dscp af23

!

interface GigabitEthernet1/0/27

description -> Distro4

switchport trunk encapsulation dot1q

switchport mode trunk

service-policy input DataMark

!

ip access-list extended CriticalServers

remark Collaboration Server

permit ip host x.x.x.x any

permit ip any host x.x.x.x

remark Transaction Server

permit ip host y.y.y.y any

permit ip any host y.y.y.y

!

ip access-list extended Video

permit ip z.z.z.z 0.0.0.15 any

permit ip any z.z.z.z 0.0.0.15

CORE1# show policy-map interface g1/0/27

GigabitEthernet1/0/27

Class-map: CriticialServers (match-all)

0 packets, 0 bytes

offered rate 0 bps, drop rate 0 bps

Match: access-group name CriticalServers

0 packets, 0 bytes

rate 0 bps

Class-map: Video (match-all)

0 packets, 0 bytes

offered rate 0 bps, drop rate 0 bps

Match: access-group name Video

Class-map: BulkData (match-all)

0 packets, 0 bytes

offered rate 0 bps, drop rate 0 bps

Match: ip dscp default(0)

0 packets, 0 bytes

rate 0 bps

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

0 packets, 0 bytes

offered rate 0 bps, drop rate 0 bps

Match: any

0 packets, 0 bytes

rate 0 bps

CORE1#

Thanks!! I know some of the choices for DSCP marking look odd, but they fit

our enterprise DiffServ model well at the WAN linkages. I'm just trying to figure out why my CORE1 switch won't mark the packets. Thanks again!!

V/R,

Ian

[Edison Ortiz]

Try this command on the ingress interface

mls qos trust dscp

[IanTarasevitsch1995]

Actually, that removed the service policy. I thought "mls qos trust dscp" was used when the dscp code was already marked by an switch closer to the packet source, and you just wanted to pass the current dscp code on (or remark it via a dscp-mutation map). Any other ideas? Thanks again for helping!

V/R,

Ian

[Edison Ortiz]

Yes, it will. You want to preserve the dscp setting from the device, aren't you ?

Once the dscp value enters the switch (that occurs after the service-policy input) then you can change the dscp value as they egress the switch (you would use service-policy output).

[IanTarasevitsch1995]

No, actually, I'm running a "conditionally-trusted IP phone + PC" model. I do *not* trust my hosts to set their dscp settings correctly, just my Cisco phones.

Also, I tried applying the service-policy on the output (egress) side of my uplinks, and received the following warning:

Warning: Assigning a policy map to the output side of an interface not supported.

On page 330 of Tim Szigeti and Christina Hattingh's "End-to-End QoS Network Design" (Cisco Press, 2005), the authors state that there is an IOS bug where the counters do not increment, but that is supposedly only on the 3550 on IOS 12.1(19)EA1 and 12.1(20)EA1. I'm running a 3750 on 12.2(35)SE2. Maybe there is a similar bug?

Do you know of another way to check the dscp settings on packets coming in or out? The only way I know of is to put them through a traffic shaper (with "random dscp-based") and see what falls out of it....

V/R,

Ian

[IanTarasevitsch1995]

It appears that the bug in question *does* apply to the 3750 as well. We left the service-policy on since it apparently wasn't working, and we discovered that it was stripping the dscp EF marking off our VoIP phones. Our WAN routers were showing zero VoIP calls, even while I was actively making one....

V/R,

Ian

[Edison Ortiz]

To check if dscp settings on packets, you can create an ACL match dscp and apply it to the interface.

I don't have a device at the moment to verify syntax but a 'permit ip any any ?' should help you complete the ACL.

[IanTarasevitsch1995]

Great idea! I didn't realize you can run an extended ACL against a DSCP value. Format is:

ip access-list extended QoStest

permit ip any any dscp ef

permit ip any any dscp af41

...

permit ip any any dscp default

permit ip any any

Apply that against the interface in question, and it does in fact track inbound DSCP settings. Thanks!