On certain switches, QOS Marking not applied to locally generated packets

[desmith]

Hello!

On some switches, QOS marking is not being applied to locally generated packets, while on other switches it is. 

Switch details where marking is *not* being applied:

WS-C3750G-12S-S  running IOS image c3750-ipbasek9-mz.122-55.SE3.bin

Switch where marking *is* being applied:

WS-C3750V2-48TS-S running IOS image c3750-ipbasek9-mz.150-1.SE.bin

We have tried two approaches, neither of which are working on the 3750G:

(1) defining a local policy:

access-list 1 permit any

route-map test permit 10

  match ip address 1

  set ip precdence internet

ip local policy route-map test

(2) setting mls cos on an uplink interface:

mls qos cos 6

Neither of these is resulting in marked packets on the 3750G, but setting the local policy worked on the 3750V2. 

Took a very careful look for known bugs, without finding any (of course, I could have been blind!).

Any suggestions/direction would be greatly appreciated!  This is a critical problem for us!

Best Regards,

Deb

[mcollaery]

My experience is with 3750G (not 3750v2), but the way I apply QoS marking appears slightly different to how you've tried to do it.

ip access-list extended voice.traffic

   permit ip host 1.2.3.4 any

class-map match-all voice

   match access-group name voice.traffic

policy-map assign.dscp

   class voice

      set dscp AF41

And then on your switch interface:

   service-policy input assign.dscp

Of course, this only works on *input*, so it all depends on what you mean by "locally-generated packets".

[desmith]

Hi, Matthew. 

Thank you for your response!

Yes, we are doing the same thing as you describe, i.e., marking dscp on packets at ingress on switch interfaces. (And then we simply trust dscp between switches/routers.)

The problem is that packets generated by the switch itself (e.g., telnet, routing protocol updates, etc.) do not enter a switch interface, and so are not marked by a service-policy.  That is a big problem!

The local policy is meant to solve this problem, and does so for certain switches, but not for others.

Thanks again for your time, and I hope this clears up what I meant!

Deb

[lgijssel]

Hi Deb,

I may have found the cause for this (and youre not gonna like it).

In the PBR section for the 3750, rel 12.2(58) it says:

Note

To enable PBR, the stack master must be running the IP services image

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_58_se/configuration/guide/swiprout.html#wp1228588

Looks like you have not fulfilled this requirement for the 3750.

Option 2, the mls qos cos 6 command obviously only works for ingress.

PBR is the way forward but you need the correct IOS.

regards,

Leo

[desmith]

Hello, Leo.

Thanks for your reply.  Yes, I had wondered about PBR availability, too, but in fact we are running IP Base images on both switches (i.e., a switch that is marking, and a switch that is not).  There is an IOS version difference (since we can run 15.x on the 3570V2 while the 3750G cannot). 

What I had assumed (may or may not be correct) is that Policy-Based Routing (i.e., applying a route-map on an interface with the "ip policy route-map" command is only supported in ip services images, but that applying a "local policy" (in enable mode, not interface mode, using "ip local policty route-map ") for marking was supported (since that was the behavior that I'd been seeing). 

I had also read elsewhere in the Forums that all that is required for "ip local policy" is a L3-capable switch and image (so IP Base on a 3750G would be sufficient). 

So, I'm still unsure what is going on, but I suppose it would be a worthwhile test to put an IP Services image on the switch in question and try it, just in case. 

Thanks again for your time and information!

Deb

[lgijssel]

Hi Deb,

I think it is logical that v15.0 behaves different because it utilizes a different licensing scheme.

Things have not been made easier by that but I suppose it keeps life interesting.

For the 12.2 train, I am confident that you will have positive results after upgrading to advipservices.

regards,

Leo

[desmith]

Hi, Leo.

Apologies for the delayed reply.  I thought you might be interested to know that applying the IP Services image had no effect: the problem was still there. 

However, when we changed the capture/telnet PC to be on the same VLAN as the switch's native VLAN, then we saw the DSCP markings.  We confirmed this both with IP Base and IP Services images.

When the switch exec and the PC are on different VLANs, then the traffic has to go elsewhere to get routed, and at a point in that process the markings were being over-written.

Wanted to update this discussion, in case others have the same problem, or are curious!

Cheerio,

Deb