Qos DSCP Label stripped ?

[usmansa1]

I have a question, is it possible that auto qos configured on the interface can alter the label on the outgoing packets ?

We have a switch that is processing the voip packet. The incoming interface on the switch is port-channel interface which has "auto-qos trust" configured on its member interface. The outgoing interface is a simple physical interface which is also configured with the same command "auto-qos trust". It is reported that when the packets leave the outgoing interface the EF label is stripped off. The switch acts as a layer 3 routing switch (Not as the GW but where the default  routing is configured). If the auto-qos alters the label here then I didnt find by which algorithm the QoS labels are altered.
Some one told me to configure the "auto-qos trust dscp" on the outgoing interface may solve the problem. But he is giving the reference to some random article that just mention the solution to configure the command but gives no explanation why this happened, Can someone help me please ? Also if you can tell me how can I verify the auto-qos actually resetting the label ?

[Joseph W. Doherty]

How auto-QoS behaves, varies between platforms and IOS versions.  So, unable to answer your question, generally.

Also older Cisco Catalyst switches tend to remove/reset ToS tag unless explicitly configured not to if QoS enabled.  (Newer/newest Cisco Catalyst switches now behave like Cisco routers, i.e. they only change ToS tag unless explicitly configured to do so.)

[usmansa1]

Hi

Many thanks for your response, I am particularly talking about Cisco Catalyst Evarest IOS XE. so is it possible that if auto qos trust cos is configured on the egress interface, it will strip off the dscp tag or reset the tag to 0 while sending the traffic outwards ?

[Joseph W. Doherty]

Generally, trust is configured for ingress, not egress.

Also generally, a policy, either ingress or egress would be how the ToS might be changed.  I'm unaware of auto-QoS, by default, changing the ToS, except possibly if an ingress port isn't trusted or the default (if any) auto-QoS ingress policy doesn't "trust".