So the network will have a core 6500 and roughly 10 idf switches. A few vlans and a Voice VLAN. I will enable MLS QOS on all switches. I will trust the DSCP on the ports to the phones. I will trust DSCP on the trunk links into the cores, or do i trust COS since its L2? Is there anything else to take into consideration?
You can trust DSCP on the trunk ports. The command simply tells the switch to trust the QoS markings.
You also need to change the default QoS mappings to mls qos map cos-dscp 0 8 16 26 32 46 48 56
The SRND covers this in details
mls qos map cos-dscp 0 8 16 26 32 46 48 56
So since the port is an access port to the phone i cannot trust COS as it doesnt have a dot1q header so no COS. So i trust DSCP, i am confused as to why i would need to make sure the COS to DSCP mapping is correct? Is that so when it sends the packets up the trunk it marks the COS correctly?
your assumption seems to be correct. You are taking data from access port which do not understand cos but still trust dscp
and when it will handover to trunk port it will be converted to cos..at this time you need to rewrite the default
dscp-to-cos value ..
you can verify default by ""sh mls qos map dscp-cos" command and decide what exactly you need here
By default, COS 3 maps to 24 and COS 5 maps to 40. These mappings will cause issues when a packet needs to be translated from COS and DSCP and viceversa.
If the phone sends a DSCP 46 marking, the switch will be able to map it to COS 5 and then back to DSCP 46 when going from a trunk port to an access port.
So should there be another hop after the 6500 (there isnt) but if there was i would need to manipulate the maps there to make sure it tags it with the correct dscp tag if it went to a access port. If it went to a trunk it would retain its original COS. Correct?
This is correct.
It's also why you should not use an untagged vlan (native) for qos traffic.
In general, you always use a trunk.
cos-dscp mappings should be set consistenly on all switches in the network.
No, the dscp info is also there, only it sits in the ip header instead of the dot1pQ tag.
You can choose to trust dscp, you would typically do this when you want to support more than one dscp value per cos-class.
However, in that case you cannot differentiate between them at layer 2. Remember there are only eight cos classes (0 - 7) and 64 dscp classes.
The cos-dscp map defines to which dscp number your respective cos values are tied.
A proper qos design utilizes a consistant mapping between the two throughout the network.
My advice: Keep it simple, use the 'trust cos' and utilize a maximum of six classes (cos 0-6) for customer traffic.
Typically voice goes into cos5 (ef), video into cos 4 (af41) and voice/video control traffic into cos3 (af31)
If you like, you could use cos 1 and cos 2 for special purposes, such as preferring applications but I would not encourage this.
A good solution for real time traffic is still the most important goel for qos on the LAN.
If the DSCP is indeed in the IP Packet of the trunk why do we need to manipulate the COS-DSCP Map? Is it because of the COS to output queue mapping because we are going over a trunk? And if we were not going over a trunk it would use the DSCP-output-q map?