I was digging around trying to find the reason why the solution for section 2.8 bullet point number two was to use the command 'mls qos trust ip-precedence' for all the connections between the core switches. The bullet point asks you to ensure that the layer 3 QoS markings are trusted between the switches, and that you trust the 3 most significant bits of the DiffServ field in the IP packet.
I found this explanation for the difference between 'mls qos trust dscp' and 'mls qos trust ip-precedence'. DSCP is the most significant 6 bits of 8-bit service-type field, where IP-Precedence refers to the most significant 3 bits of 8-bit service-type field.
This picture shows this breakdown in a little better detail.
Hi Jennifer,
ReplyDeleteIP-Precedence is the older definition for the 8-bit TOS field, as detailed in the provided graphic in your post.
DSCP supersedes IP-Precedence to provide better support for differentiated services (hence, DiffServ), for providing per-hop behavior (PHB) decisions. This allows each hop / router to classify, mark, and "condition" the traffic (meter, shape, police). The 3 most significant bits are used for priority, while the next 2 bits provide the drop probability. The 6th bit is always 0, and the 2 least-significant bits are for Explicit Congestion Notification (ECN).
It's also relevant to note that the DSCP Class Selectors are backwards compatible with the legacy IP-Precedence values since they do not specify any drop-probability.
There is a decent Cisco article on the subject here:
http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a00800949f2.shtml
Cheers,
Andrew
Andrew,
ReplyDeleteThanks for the link to the Cisco article - I think I've seen that one, but didn't find it this time around. It helps, but all the different QoS options are quite a mess since they have to be backwards compatible.