I'm designing a QoS implementation and I'm going to use class-maps and policy-maps and service-policy commands. Now, obviously you use these commands to classify different kinds of traffic and define how you want it handled. But I'm confused about the degree to which certain DSCP markings, by themselves or by default, do or do not result in a certain kind of treatment by routers.
For example, I was reading Cisco's document on DSCP values and they said this about the Assured Forwarding class:
"Assured Forwarding PHB guarantees a certain amount of bandwidth to an AF class and allows access to extra bandwidth, if available."
So if I use clas-maps to define a certain kind of traffic as AF41, but don't configure any other treatment with a policy-map, will the router give that traffic some kind of preferential treatment just because I've marked it as AF41?
I'd have the same question about the EF class.
But at the same time, some classes, such as the CS classes (CS1, CS2, etc.) are comlpetely arbitrary - just labels, essentially - and you define whatever treatment you want, correct?
I guess I'm having trouble differentiating between QoS treatment that I would explicitely configure and QoS treatment that routers will automatically perform, by default, based on certain DSCP values.
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
The only router QoS configuration that I recall that by default treats traffic differently based on ToS byte (IP Precedence) is WFQ which is the default on E1 and slower serial interfaces. Otherwise, you need to configure QoS. Most such configured QoS also doesn't by default, treat traffic differently based on ToS byte either except for WRED, and FQ in class-default CBWFQ prior to HQF variant.
On L3 switches that support features that look at the ToS byte, they will in a default enabled QoS configuration treat packets differently too although they also generally by default don't trust the ToS byte and will reset it when QoS is enabled.
In other words, for the most part, pure default device configurations usually don't provide any special treatment of the ToS but as noted above, there is an exception on routers. Usually you need to enable QoS features, and if you do, you might get some new default special processing of ToS.
Like Joseph says, there is no default behavior. You can (must) configure a router to perform qos-controlled forwarding.
While doing this, you, the operator can configure it to perform different kinds of forwarding for any of the 64 dscp values available. Alternatively you can also use an acl to recognize traffic for this purpose.
What we often do is configure a certain amount of bandwidth for priority-class traffic (most often voice)
Another option is to reserve a certain amount of bandwidth for a special type of traffic. (video, citrix, ..)
Such traffic is then generally recognized by its dscp value.
The only things which are fixed are: the (1) dscp values 0-63 and (2) the types of forwarding a device can provide.
The latter is depending on both hard- and software capabilities of the device but you can configure every forwarding behavior for each of the dscp values available. You could for example give highest priority to unmarked (CS0) traffic if you wanted. Not very useful of course but nevertheless possible.
One more thing: qos processing is a per-hop behavior. This means that each node or device in the network must be specifically configured to run qos according to the defined policy.