Traffic classes in QoS

Provides an overview of traffic classes, defining the criteria and match logic used to identify specific traffic types for QoS enforcement. It details supported match types, such as DSCP and IP Precedence, and explains how unclassified traffic is handled by the default class.

Components of a traffic class

Packet classification behavior

When a packet arrives at the router, it is compared against the match commands defined in the traffic class. This table describes how the router classifies packets.

Match conditions

• You can specify multiple values for the same match type in a single line of configuration. If the first value doesn’t match, the next value in the match statement is considered for classification.

• You can use the not  keyword with a match command to classify traffic that does not match specific values.

• Although all match commands are optional, you must configure at least one match criterion to define a valid traffic class.

Supported match types

Match logic

• The default behavior is match-any , where the packet must match at least one of the specified match statements for classification.

• When you configure match-all , the packet must match all specified criteria to be considered part of the traffic class.

• Although all match commands are considered optional, you must configure at least one match criterion to define a valid traffic class.

ACL considerations

• The match access-group command does not support matching on packet length or time-to-live (TTL) fields.

• When used in a class map, the ACL deny action is ignored. Traffic is classified solely on the basis of a match.

Egress classification rules

• These match types are valid only in the egress direction:

  • match qos-group

  • match traffic-class

  • match dscp

  • match precedence

  • match mpls experimental (EXP)

• The class-default implicitly matches qos-group 0 traffic.

• You can classify traffic into up to seven distinct groups using match qos-group , with supported values ranging from qos-group 1 to qos-group 31 .

• You cannot configure match qos-group 0 . In egress policies, qos-group 0 traffic is automatically matched by class-default .

Multicast and egress QoS handling

• On your routers, multicast and unicast traffic follow different paths but converge at the egress in a fixed 20:80 multicast-to-unicast ratio per interface.

• Egress QoS for multicast traffic treats traffic classes 0–5 as low-priority and traffic classes 6–7 as high priority. This prioritization behavior is not user-configurable.


• Egress shaping does not apply to multicast traffic in high-priority traffic classes. Shaping is only effective for unicast traffic in these classes.

Ingress and egress traffic class considerations

• If you assign a traffic class at ingress and do not define a matching class at egress, then the traffic will not be counted in the class-default at the egress policy map.

• Only traffic class 0 maps to the egress class-default. Any non-zero traffic class assigned at ingress, but not mapped to an egress class or queue, will not be included in either the default class or any other class at egress.

Default traffic class behavior

• Packets not matching any explicitly user-defined class are assigned to the default class (class-default .)

• The default class always exists, even if not explicitly configured.

• If no QoS actions are configured for the default class, packets receive no treatment—no marking, policing, shaping, or prioritization.

• To apply QoS to unclassified traffic, configure actions under the default class in a policy map.

Layer 2 classification using Layer 3 headers

From Cisco IOS XR Release 7.2.12, classification on Layer 2 transport interfaces using Layer 3 header fields is supported. This capability is limited to physical and bundle main interfaces and does not apply to sub-interfaces.