11-16-2009 06:08 AM - edited 03-06-2019 08:37 AM
We are deploying qos configurations for access servers c3560-E switches. We want to know differences between these kind of configs:
Interface GigabitEthernet 0/1
mls qos trust dscp
or
policy-map trustDSCP
class class-default
trust dscp
interface GigabitEthernet 0/1
service-policy input trustDSCP
We have the same doubts about:
Interface GigabitEthernet 0/1
no mls qos trust dscp
or
policy-map DSCPdef
class class-default
set dscp default
interface GigabitEthernet 0/1
service-policy input DSCPdef
If you try to configure service-policy, and you try with "show policy-map interface gi0/1", you can't see matches in both cases.
We have read both commands (mls qos trust dscp and service-input) are mutually exclusive, but you can config both commands in the same interface.
Somebody could clarify us these issues?
Thanks.
11-16-2009 07:10 AM
Hello Juan,
The trust command in a policy map allows you to set the trust state only for the traffic covered by that particular class, whereas the mls qos trust command applies to all traffic entering the interface. The trust command is therefore more selective.
Do you have the mls qos configuration command entered in your global configuration mode? I suspect that it is necessary to activate the QoS support on the switch.
Best regards,
Peter
11-16-2009 01:07 PM
Hi Peter. Thanks for your answer.
Yes, we have configured mls qos command in switches. I think diference between them could be policy-map is implemented in software, while mls qos trust is implemented in hardware, but policy-map offers more flexibility.
But..., it means main choice is mls qos trust command over policy map (if this last one has only default class)?
I don't know.
11-16-2009 07:26 AM
As I understand from your questions that you would like to trust DSCP from endpoints.
mls qos trust dscp will have the same results as the
policy-map trustDSCP
class class-default
trust dscp
If you want to trust DSCP that I'll use the mls qos trust dscp command for simplicity and efficiency.
The trust statement in a policy map requires multiple hardware entries and, as such, might be too large to fit into the available QoS hardware memory, triggering an error when the policy map is applied to a port.
Both commands are supported in the same interface because the trust DSCP can be used with the conditional trust and using the policy map for policing for example.
I recommend that you review the latest QoS SRND version 4.0 for campus infrastructure at
It explains QoS configuration in details
Regrading the "no mls qos trust dscp" this is the default which will take effect when QoS is enabled and will remark DSCP in every packet to DSCP 0 (Default) which is the same as the policy map will do. So no need to create the policy map since is it configuration and processing overhead.
It all depends on your requirement but if you are using Cisco Phones then I think you should look at conditional trusting as well
Regrading the show policy-map output, the 3560, Though visible in the command-line help string, the control-plane and interface keywords are not supported, and the statistics shown in the display should be ignored.
I hope this helps.
Thanks
Hatim Badr
11-16-2009 01:32 PM
Hi Hatim, nice response, thanks very much.
It's clear to me I must ignore statistics from "show policy-map interface ..." command. I have been testing and there aren't relationship between packet matches in "sh policy-map interface" and input packets/sec. in "sh interface" commands. It's clear there is something wrong.
But I want to know what is the best option if you want (or not, with set dscp default in policy-map) to trust in DSCP marks for all input traffic, if you don't need to police it. I think if mls qos trust is implemented in hardware, could be the best option. But if you want to configure a policy-map to rewrite DSCP marks, is needed to configure mls qos trust dscp previously in the same interface? Take in mind, if default config for qos is "no mls qos trust" command, all inbound traffic is remarked with default DSCP previously to policy-map. Am I in the right way or perhaps i'm wrong?
Thanks.
11-17-2009 08:55 AM
If you just want to trust DSCP from endppoints then your best option is mls qos trust command.
It is simpler and moreover the problem with policy-map trust dscp command that it consumes multiple QOS TCAM hardware entries which you may need later on for other policies.
The best from Hardware optimization and also management point of view for trusting dscp values is to use the "mls qos trust dscp" command.
Thanks
Hatim Badr
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide