In this post we will look at the basic classification and marking features available in the 3550 and 3560 switches. Basic features include packet marking using port-level settings and port-level policy-maps. Discussing Per-VLAN classification is outside the scope of this document.
The Catalyst QoS implementation bases on Differentiated Services model. In a few words, the ideas of this model could be outlined as follows:
1) Edge nodes classify ingress packets based on local policy and QoS label found in packets.
2) Edge nodes encode traffic classes using a special field (label) in packets to inform other nodes of the classification decision.
3) Core and edge nodes allocate resources and provide services based on the packet class.
Note that each node acts independently on its own, as instructed by the local policy. In order for the QoS policy to be consistent end-to-end, the network administrator must ensure that all nodes use the same classification and resource allocation policy.
The following are the marking types found in IP/Ethernet networks:
1) ToS byte in IP packet or Traffic Class byte in IPv6 packet. The switch may interpret this field in two different ways:
1.1) Interpret the topmost six bits of the byte as DSCP code point. This is in full compliance with Diff-Serv model.
1.2) Interpret the topmost three bits of the byte as IP Precedence value. This complies with the old, “military-style” QoS model, where higher precedence traffic preempts the lower precedences. Note that IP Precedence numbers form a “subspace” of DSCP numbers.
2) The CoS bits (three bits) in 802.1q/ISL header of a tagged Ethernet frame. These bits are also known as 802.1p priority bits, and should be interpreted as relative traffic priorities.
As we can see, the marking types could be either Layer 3 (IP/IPv6 fields) or Layer 2 (802.1p bits). Naturally, the latter option is only applicable on trunk links.
The Catalyst switches have no special intelligence to implement any of these QoS models by themselves. It’s up to you to define policy and encode classes using any marking you find more suitable for your task. Due to numerous markings types, Catalyst switches assign a special internal QoS label to all packets and use this label for internal QoS processing. In the 3550 this label is simply a special “internal” DSCP value. However, in the 3560 the QoS label format is more complicated, and allows storing either CoS or DSCP information.
Now recall the distinction made by the multilayer switches between IP and non-IP packets. As we know, Layer 3 switches are hardware optimized to route IP or IPv6 packets using their ASICs for optimum performance. This results in differences of handling the IP and non-IP packets. You may use MAC-based ACLs (matching MAC addresses, Ether-types or LSAPs) only with non-IP packets (e.g. ARP, DECNet, IPX). The MAC ACLs will not match any of IP packets, even if you specify a matching MAC addresses. Also, note that the 3560 models treats IPv6 as “IP” traffic, while the 3550 treats IPv6 packets as “non-IP” and matches them with MAC ACLs.
QoS processing pipeline
The following diagram displays stages of QoS processing in a typical Catalyst switch.
We are now considering the Classification and Marking stage. The switch uses local policy configuration to classify input packets. The local policy may be as simple as port QoS settings or more complicated, such as policy-maps with QoS ACLs. The result of classification stage is the internal QoS label (e.g. internal DSCP value with the 3550). At this stage, the switch uses special globally configurable QoS mapping tables. The tables map one QoS marking “type” to another, e.g. CoS values to DSCP, or DSCP to CoS. You can display the tables using the command show mls qos map.
The switch uses these tables for two major purposes:
a) To “synchronize” different types of QoS markings present in a packet. For example, if you instruct the switch to set CoS field to “3”, the switch will look up through the CoS-to-DSCP mapping table and rewrite the DSCP value in the IP packet header accordingly.
b) To translate the ingress marking (e.g. CoS, or IP Precedence) into the values used in the QoS label. For example with the 3550 switch, the CoS to DSCP mapping table is used when you trust ingress CoS marking to find the resulting internal DSCP value.
You may classify using either interface level settings or by applying a pre-configured policy-map to the interface. These two options are mutually exclusive: that is, if you configure interface level classification settings and later apply a service-policy, then the latter removes interface-level QoS classification settings (there are some exceptions though).
Classification Options
1) Trust one of the marking types already present in packet (mls qos trust {dscp|ip-precedence|cos}). For IP packets, it is possible to trust either IP Precedence or DSCP value. Of course, doing so makes sense only for IP packets. If the switch trust IP marking and incoming packet is non-IP, the switch will attempt to classify based on CoS value in the Ethernet header. If there is a CoS value in the packet (i.e. the port is trunk) the switch uses this value to build the QoS label. However, if the packets bears no CoS field, the switch will look at the default CoS value configured on the interface (mls qos cos x). The switch computes corresponding DSCP value for the label using the CoS to DSCP table. When you trust IP precedence, the switch builds DSCP value using the IP-Precedence to DSCP mapping table and the CoS value using the DSCP to CoS mapping table.
2) Trusting CoS (mls qos trust cos) is a bit different. First, it works for both IP and non-IP packets, since they both may bear CoS bits in the Ethernet header. Thus, when the switch trusts CoS on interface, it attempts to build the QoS label based on the CoS bits. If there is no 802.1q/ISL header, the default CoS value from the interface settings is used instead (not the IP/DSCP value from the packet header!). This procedure works for both IP and non-IP packets: the switch does not take in account the IP Precedence/DSCP values. The corresponding mapping table allows the switch to compute the internal DSCP value/QoS lable and rewrite the DSCP values in the IP/IPv6 packet header.
3) You may explicitly assign a specific CoS value to all packets, either marked or not, entering the interface using the mls qos cos override command. This command will force the use of CoS value specified by the mls qos cos x command for all IP and non-IP packets. Note that this feature only works with CoS values, and the switch deduces actual DSCP marking using the CoS to DSCP mapping table. Also, note that any “trust” configuration on an interface conflicts with the “override” settings and thus the switch removes the former commands.
4) The most flexible option is to use QoS ACLs to perform classification and we are going to discuss the use of QoS ACLs in a separate topic below.
A special type of trust is conditional trust. That means trusting QoS marking only if the switch detects certain device connected to the port - for example, if the switch senses Cisco IP Phone CDP announces. The command for conditional trust is mls qos trust device and it instructs the switch to trust the packet marking only if the certain device reports itself via CDP.
The automatic rewrite feature ensures the uniform marking - that is, it takes care of synchronizing L2 and L3 code points. Is it possible to trust DSCP and built the internal QoS label based on its value, but retain the CoS bits in the packet? Alternatively – trust CoS bits and retain the DSCP values? You may need this capability occasionally, if you want to “tunnel” one type of QoS marking through your network, while using the other type for your needs.
QoS Pass-Through feature
In the Catalyst 3550, you may set one type of marking as “pass-through”. For example, when you trust CoS you may enable DSCP pass-through with the interface-level command mls qos trust cos pass-through dscp. The command with reverse logic is naturally mls qos trust dscp pass-through cos.
On the 3560 switches, you only have option to disable DSCP rewrite in IP headers, when you trust the CoS values, using the global command no mls qos rewrite ip dscp
Classification using QoS ACLs
Even though they are called QoS ACLs (the term borrowed from CatOS) you actually apply these using MQC syntax by configuring class-maps and policy-maps. You may define MQC traffic classes by matching one of the following:
1) MAC or IP/IPv6 access-list. The MAC access-list matches non-IP packets and IP/IPv6 matches IP or IPv6 packets respectively. Of course, you can only match IPv6 packets on the 3560. As mentioned above, you cannot use MAC ACLs to match IP traffic (though you can use MAC ACLs on the 3550 to match IPv6 traffic).
2) DSCP and IP Precedence values. Note that you cannot match CoS value in Ethernet headers (like you can do in routers).
3) Additional platform-specific matches like match input-interface and match vlan. These are used by the 3560 hierarchical policy maps or the 3550 per-port per-VLAN classification.
The classification criteria are very limited, compared to IOS routers. You cannot match packet size or packet payload. Additionally, you cannot do hierarchical matching, with exception for per-VLAN classification feature. These limitations are result of tight hardware optimization in the Layer 3 switches.
Pay attention to the behavior of the class “class-default” with the Catalyst QoS. This class works fine in the 3560 switches, matching both IP and non-IP traffic. However, it seems to work inconsistently or does not work at all with the 3550 switches. In the latter model, as a workaround, create special classes to match either all IP or all non-IP traffic using IP/MAC ACLs:
ip access-list standard ALL_IP
permit any
!
mac access-list extended ALL_MAC
permit any any 0x0 0xFFFF
!
class-map ALL_IP
match access-group ALL_IP
!
class-map ALL_MAC
match access-group ALL_MAC
Under a class in the policy-map you can either trust (CoS, DSCP, IP Precedence) or set (DSCP, IP Precedence) the respective QoS marking. Note that you cannot set CoS value directly in the 3560 switches, but you can set DSCP for non-IP packets. The switch translates DSCP into CoS using the DSCP-to-CoS mapping table. The same holds true for the 3550 switches – you can set DSCP on the non-IP packets and it is translated to the CoS. Note the special feature of the 3560 switches: the QoS marking you trust or set is later used to look up the DSCP or CoS to queue/threshold mapping tables. This is because the 3560 defines two egress mapping tables: one for DSCP and other for CoS values, based on the complex structure of the QoS label.
In the 3550 switches you can set CoS value directly in one special case. First, you need the global command mls qos cos policy-map. Using this feature, you must trust DSCP marking and set Layer 2 marking using the set cos command. This simulates the behavior of “CoS pass-through” feature available at the interface-level settings. The set cos feature only works when you trust DSCP. Furthermore, the 3550 performs all QoS processing and deduces internal DSCP based on the trusted dscp value, not the CoS value set with the policy map.
With both switch models, you can either configure set dscp or set ip precedence but not at the same time, of course – the one configured later erases the previous one. Also, if a class contains ”trust” and “set” statements for the same type of marking (e.g. L3 or L2) the trust statement takes precedence over explicit set.
Aside from that, trust feature works the same way as it works on the interface but has scope limited to the class defined by ACL.
Remember that applying a service-policy will remove any interface-level QoS settings on the interface, with exception to the default CoS (which is used by the policy map when you trust CoS inside a class). If the input packet doest not match any class in the service-policy, the switch will set all marking to zero. If you trust CoS for IP or non-IP packets and there is no 802.1q/ISL header the switch will take the default CoS value from the interface settings or use zero markings.
Loading ...
