If i want to say change all packets coming in at cos 4 to be set to a dscp value of 16, do i need to put the mls trust cos command on there.
mls qos (enables qos)
mls qos map cos-dscp 0 8 16 24 16 50 48 56 (this maps cos 4 to to dscp 16)
now when packets come in will they be mapped to dscp 16 or are they rewritten to 0 cos and 0 dscp becuase they are not trusted?
Solved! Go to Solution.
You need the "mls qos trust cos" on your interface and then that cos value will be mapped to whatever is in your DSCP-to-Cos map.
And iassume this is the same if i wnat my dscp to cos map to work? I would have to trust dscp..
and i did trust dscp and trust cos no maps would be used..
Are the above statements correct?
Also i would have to trust dscp to use a dscp mutation?
"And i assume this is the same if i want my dscp to cos map to work? I would have to trust dscp"
Depends. Don't forget that the switch derives an internal DSCP value to use from either the CoS or DSCP value received on the port.
Your DSCP-to-Cos map is used for egress queueing. So you could trust CoS which would then be mapped according to the Cos-to-DSCP map and then mapped back to a Cos value in the DSCP-to-Cos map if you see what i mean. Or you could just trust DSCP which would then be the same DSCP as the internal value.
Yes you would need to trust DSCP if you wanted to then remap that DSCP value to another with the DSCP mutation map.
so if you trust cos then the packet will come in, trust the cos.. the dscp will then be mapped from the cos to dsp map
if you trust dscp then the packet will come in, trust the dscp, rewrite the cos depending on the dscp to cos map?
Sorry Mike, i'm not explaining this very well.
Key thing to understand is that L2 and L3 switches always use an internal DSCP value to prioritise the packet within the switch. This value is not written into the packet but it is used derive the value in the packet when sent to the egress queue.
A switch supports
Cos-to-DSCP map - used to derive the internal DSCP value when the packets contain Cos values on ingress
IPP-to-DSCP map - used to derive the internal DSCP value when the packets contain IP Precedence values.
DSCP-to-Cos map - used to derive a Cos value from the internal DSCP value before sending to egress queue.
Note DSCP-to-DSCP maps are not needed normally as the DSCP value received is the internal DSCP value which is also the DSCP value used to map to a queue, if you are using DSCP values to map to egress queues which some switches support.
However there is a DSCP-to-DSCP mutation map which allows you to change the received DSCP value.
So if you trust Cos the procedure is
1) map Cos to internal DSCP based on Cos-to-DSCP map
2) When placing the packet in an egress queue if
i) the queues are mapped based on the Cos value then use the DSCP-to-Cos map to derive the Cos value
ii) the queues are mapped based on DSCP just use the internal value
If you trust DSCP then no need to derive internal DSCP as it will be the received DSCP (providing no DSCP-to-DSPC mutation map) but you still need step 2 from above.
IP predence is prety much same as Cos except in step 1 you use IP Precedence-to-DSCP map.
If you don't trust the port then default Cos value of 0 is used which will map to DSCP 0 , still using Cos-to-DSCP map. This is assuming you haven't modified the Cos-to-DSCP map.
Hope this makes it clearer.
i think im almost there/
so an example.
1.) packet comes in with cos 5
2.) its trusted
3.) its mapped to dscp 40 (only internally to the switch) based on cos-dscp map
4.) if the dscp-cos map says dscp 40 to cos 5 then it will go into he egress queue assigned for cos 5
You've got it. The only slight difference would be if you were using DSCP values to map packets to egress queues then you wouldn't need to consult the DSCP-to-Cos map.
By modifying these maps you can influence which value is written into the packet before being sent to the egress queue.
Say # 4 said this:
4.) if the dscp-cos map says dscp 40 to cos 4 then it will go into he egress queue assigned for cos 4
Now does it overwright cos 5 to cos 4 when it leaves the port or just use this table for lookups.
And if you trusted the dscp value only. the output packet would contain that dscp value and whatever cos value is in the dscp-cos map?
pending the queses are mapped off cos
bottom line is the packet will leave the switch with a cos and dscp value
Youve been a super big help. Where do i write the check to for tonights training haha.
"Youve been a super big help"
Glad to have helped. One last point. The packet may or may not leave the switch with a CoS value because the Cos values are contained within an 802.1q/ISL tag so the egress port would need to be a trunk for the packet to have CoS values.
But if it came in with a DSCP mark then it is safe to say it will leave with a DSCP mark.
If the packet came in with a DSCP value then it will leave with a DSCP value whether or not that value is the same is down to your maps and the trust state on the port.
So if you trust CoS and the packet has no DSCP value, then an internal DSCP value will be used by the switch but it won't write a DSCP value into the outgoing packet.
If you trust Cos and the packet has a DSCP value then the packet will leave with the same DSCP value ie. it remains untouched.
Think i might have misled you on one point.
"If you trust Cos and the packet has a DSCP value then the packet will leave with the same DSCP value ie. it remains untouched"
Not strictly true. It would be true if you enabled DSCP transparency which says not to modify the DSCP value in the IP header. Yoi do this with the command -
no mls qos rewrite ip dscp
But DSCP transparency is not enabled by default. From the 3750 QOS configuration guide -
Depending on the QoS label assigned to a frame and the mutation chosen, the DSCP and CoS values of the frame are rewritten. If you do not configure the mutation map and if you configure the port to trust the DSCP of the incoming frame, the DSCP value in the frame is not changed, but the CoS is rewritten according to the DSCP-to-CoS map. If you configure the port to trust the CoS of the incoming frame and it is an IP packet, the CoS value in the frame is not changed, but the DSCP might be changed according to the CoS-to-DSCP map.
The input mutation causes the DSCP to be rewritten depending on the new value of DSCP chosen. The set action in a policy map also causes the DSCP to be rewritten.
Good luck with your lab on Tuedsay.
based on what u have updated
if i have the following:
cos 5/dscp 30 >>input port with trust cos (the map has cos 5 to dscp 40>>output port trust dscp >>( is here the resulted dscp to the next device will be 40 or 30 )???
Apologies for the delay in replying, i missed this one.
Firstly the trust state is only relevant on the ingress port not the egress port so when you say "output port trust dscp" not sure what you mean.
But anyway, if the ingress port is set to trust cos and the cos-to-dscp map maps cos 5 to DSCP 40 then the DSCP value of 30 will be overwritten by the DSCP value of 40 and the next device will see DSCP 40 in the packet.
Note that there are caveats to that. If you enable DSCP pass-thru/DSCP transparency then the switch will not rewrite the DSCP value and the next device would see DSCP 30 in the IP header.
Just in case anyone else reads thread where it states
"You need the "mls qos trust cos" on your interface and then that cos value will be mapped to whatever is in your DSCP-to-Cos map."
that should read -
You need the "mls qos trust cos" on your interface and then that cos value will be mapped to whatever is in your Cos-to-DSCP map.
it sounds intersting posts u have done
by the way
if trust cos and traffic come with cos 5 then the map on the switch will map it to dscp 46
then the out going uplink trust dscp will the recieving device lets say a router see the packet as dscp 46 in this case
regarding i mentioned the traffic came as cos 5 and maped on the switch ??