C3750 packets not getting marked

Unanswered Question
Jul 6th, 2009

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

Attachment: 
I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.8 (4 ratings)
Loading.
gsidhu Wed, 07/08/2009 - 07:37

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

gsidhu Mon, 07/13/2009 - 08:21

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

Joseph W. Doherty Mon, 07/13/2009 - 08:49

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.

gsidhu Mon, 07/13/2009 - 09:29

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?

xcz504d1114 Mon, 07/13/2009 - 09:42

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

gsidhu Mon, 07/13/2009 - 10:24

Joseph, Craig,

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

Gurmakh

Joseph W. Doherty Mon, 07/13/2009 - 11:15

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.

gsidhu Mon, 07/13/2009 - 11:29

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?

Joseph W. Doherty Mon, 07/13/2009 - 11:47

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.

gsidhu Mon, 07/13/2009 - 11:55

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

Joseph W. Doherty Mon, 07/13/2009 - 11:59

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. :)

gsidhu Mon, 07/13/2009 - 12:11

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?

Joseph W. Doherty Mon, 07/13/2009 - 12:17

Yes, if you need to insure nothing slips by. However, if you're certain both Citrix and Exchange packets would only have the markings in your original table, that would work fine too.

Actions

This Discussion