cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1060
Views
19
Helpful
16
Replies

C3750 packets not getting marked

gsidhu
Level 3
Level 3

Hi,

Customer requirement is to:

a) mark traffic from Exchange Server destined for Blackberry Enterprise Server at another site to AF21. The BES server ip address is 10.202.1.76.

b) mark Citrix traffic as CS4.

I've attached part of the configuration. The problem as you will see from the 'sh policy-map int xxxx' output is that none of the traffic is getting marked.

I think the problem is with the access list.

Please could somebody take a look and let me know what I am doing wrong?

The Exchange server is nic teamed (int gi 1/0/1 and int gi 2/0/1).

The Citrix Server is on gig 1/0/4 and gig 2/0/4).

Thanks

16 Replies 16

Jon Marshall
Hall of Fame
Hall of Fame

This is a well known issue with the 3750. It is not your access-list that is the problem. See this doc for details -

http://supportwiki.cisco.com/ViewWiki/index.php/Unable_to_display_QoS_information_at_the_port_level_with_the_show_policy-map_interface_command_in_Catalyst_3750_switch

Jon

Jon,

This is very usefull to know - certainly save me a lot of time....I've rated your post.

I used the 'sh mls qos int gi 1/0/4 statistics' command which displays traffic on the interface - but I'm not sure if this is giving me accurate information.

Thanks

Hi,

The sh mls qos interface statistics shows that the packets are not getting marked with the DSCP values required.

Please could somebody check the configuration. (The qos objectives are in the opening notes to this post).

Thanks

Perhaps a misunderstanding in marking stats?

You're marking packets upon ingress, on 3 ports, but to see these markings, I believe you need to look at the egress markings stats on the port(s) where these packets egress.

Also, you've configured a policer. Don't know what your Policed-DSCP Map is, but also I don't know whether the policed mapper uses the original packet's marking or the one you've set in your policy.

Hi

I'm not sure what you mean...

If you look at the egress markings for gi 1/0/4 and gi 2/0/4, the stats show that no packets are getting maked with dscp 32 (CS4).

If you look at the egress markings for gi 1/0/1 the stats show that no packets are getting maked with dscp 18 (AF21).

Is this down to the configuration?

Also AFAIA the policer should only remark traffic that exceeds the policed bandwidth.

I'm wondering if anybody can provide a configuration that works for citrix or any other data application using policy map?

No, he means you look at the "show mls qos interface gi x/0/y stat" of the interface the traffic is leaving...

So if you are marking on int gi 1/0/1, and ping a device on interface gi 1/0/2, you would look at the egress traffic on 1/0/2, "show mls qos int gi 1/0/2 stat" and you should see the traffic that is marked with your DSCP values.

Your config is right, in regards to the policing the above poster was talking about, you have your policy maps set to change the DSCP value for any traffic that exceeds your threshold limits "exceed-action policed-dscp-transmit" if you don't modify the policed-dscp map, then it is a 1 for 1, IE, a DSCP marking of 18, when it exceeds your BW threshold it will still be marked with 18. You can change this, so that you can specify another policy for traffic that exceeds the limits.

HTH,

Craig

Here is a link to some more info regarding MQC config, it's documentation for a 3750.

You followed it to the letter.

http://www.cisco.com/en/US/products/hw/switches/ps5023/products_tech_note09186a0080883f9e.shtml#concept22

Craig

Joseph, Craig,

Thanks very much for your help. I've rated your posts.

Gurmakh

I believe Craig did a nice post expanding on my two points.

One point that wasn't clear to me from the config guide, and even with Craig's post, is what value the policer uses mapping from. I.e., the packet's original value or what you've set DSCP to within the policy statement. From the example, in Craig's reference, it appears to be the packet's original value.

Since as Craig also notes, the default mapping table uses the same values, your policy will remark packets that match the policy that don't exceed the policer, but will preserve the original DSCP value (by default) for packets that exceed the policed rate (which I doubt is what you intend).

If either of these two points are still unclear, post another follow-up.

I have the following statement in the global configuration:

mls qos map policed-dscp 18 24 26 32 46 to 0

I think this answers your question?

Not sure.

If you intend, for instance, overrate Citrix packets that originally has one of the DSCP values you note, changed to BE and any other overrate Citrix packet preserve its DSCP, then it does answer my question. If you intend all in-rate Citrix packets to be marked (CS4), and all overrate Citrix packets to be marked BE, then it may not be what you want.

PS:

For something like Citrix traffic, a markdown from CS4 to BE is rather drastic. Often better, if different DSCP drop precedences are supported, to drop CS4 to AF4x (where x might be 1..3).

The Exchange traffic, might also benefit dropping from AF21 to AF22 or AF23, rather than BE, but for traffic like Exchange, BE shouldn't be as detrimental as it might be for Citrix.

Thanks for your advice.

My intention is for all in-rate Citrix packets to be marked (CS4), and all overrate Citrix packets to be marked BE

Okay then, in that case, believe you need the whole map table to map to BE (to be sure an unexpected DSCP values doesn't slip by).

It would be nice if the policer would set the overrate DSCP value like can be done on routers, but then it wouldn't be a 3750. :)

This means entering all of the dscp values after the mls qos map policed-dscp command and mapping them to 0?

ie mls qos map policed-dscp 8 10 12 14 16 18 20 22 24 26 .......etc to 0

Have I understood you correctly?

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: