MultiLayer Switch QoS - MLS QoS
On Cisco switches, the mls qos commands are used to configure a range of QoS functions. The abbreviation MLS stands for MultiLayer Switch, which is a switch that, in addition to the classic Layer 2 switching, offers additional functions at higher OSI layers. One of these extended features is support for DiffServ QoS. It is worth noting that some of these configuration features are also present in the Catalyst 2960, which is a globally L2 switch (in contrast to the Catalyst 3750, which is L3).
On the switch, QoS is disabled by default, and if we want to use any function, we must first enable it.
SWITCH(config)#mls qos // globally enable QoS for the switch SWITCH#show mls qos // verify that QoS is enabled
Trusting QoS Markings
Switches form the access layer, which is often set as the Trust Boundary. Therefore, it is an ideal place to perform classification and marking. Alternatively, we can trust the sent values on certain ports.
Note: For packets to carry the CoS (Class of Service) information at the OSI Layer 2, the port must be in 802.1q trunk mode.
If we trust the device connected to the port (e.g., a Cisco IP phone), we can set trust for a specific value contained in the frame/packet.
SWITCH(config-if)#mls qos trust dscp SWITCH(config-if)#mls qos trust cos SWITCH(config-if)#mls qos trust ip-precedence
If CDP is enabled and a Cisco IP phone is connected to the port, we can set that the trusted value (set by one of the previous commands) is trusted only if the connected device is a Cisco phone.
SWITCH(config-if)#mls qos trust device cisco-phone
If we set trust for the connected IP phone, this setting applies only to packets in the voice VLAN. If a PC is connected to the phone, we can instruct the phone how to handle these packets. It is recommended to re-mark this traffic to CoS 0.
SWITCH(config-if)#switchport priority extend cos 0 // set CoS for packets from the PC behind the phone SWITCH(config-if)#switchport priority extend trust // trust values from the PC behind the phone
We can check the QoS configuration of the interface using
SWITCH#show mls qos interface g1/0/2
Setting CoS for Incoming Frames
If we set CoS trust and a non-tagged packet arrives, it will be assigned the default value of 0. The CoS value is important for the selection of the output queue (the CoS-to-DSCP map is used). We can change this default CoS value for the port.
SWITCH(config-if)#mls qos cos 3
Alternatively, we can set the CoS value of incoming packets to be overridden by the default value. We use the following command together with the previous one.
SWITCH(config-if)#mls qos cos override
Mapping Tables
When switches process traffic and use QoS, they use internal DSCP values corresponding to the priority of the traffic for all packets. Therefore, it is often necessary to convert the CoS values of incoming packets to DSCP and then DSCP to CoS, which is used to select the output queue. For this purpose, we use mapping tables that exist with certain default values (listed below), but we can reconfigure them.
We have multiple mapping tables, although the first two are the most commonly used:
- CoS-DSCP map - for converting CoS to DSCP
- DSCP-CoS map - for converting DSCP to CoS
- IP-Prec-DSCP map - for converting IP Precedence to DSCP
- DSCP-mutation - if we are connecting two domains that use different DSCP values, we use this map at the network boundary to rewrite the DSCP to our values, the default is null, i.e., it does not change the values
- Policed-DSCP - used to rewrite the DSCP to a new value within policing and marking, the default is null, i.e., it does not change the values
Default CoS-DSCP map
| CoS | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| DSCP | 0 | 8 | 16 | 24 | 32 | 40 | 48 | 56 |
Default DSCP-CoS map
| DSCP | 0-7 | 8-15 | 16-23 | 24-31 | 32-39 | 40-47 | 48-55 | 56-63 |
| CoS | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
The following examples show how to change the default values of the mapping tables. For the CoS-to-DSCP table, we specify 8 DSCP values that correspond to CoS values 0 to 7.
SWITCH(config)#mls qos map cos-dscp 0 8 16 24 32 46 48 56
For the DSCP-to-CoS table, we configure one CoS value per command. We can specify up to 8 DSCP values followed by the keyword to and then the CoS value that corresponds to them. To define the entire table, we must use the command multiple times.
SWITCH(config)#mls qos map dscp-cos 0 8 16 to 0
We can display the current maps as follows:
SWITCH#show mls qos maps cos-dscp
Input and Output Queues - Ingress and Egress Queues
WRR - Weighted Round Robin
On older switches (e.g., Catalyst 3550), the queue scheduler used was WRR - Weighted Round Robin. It works simply, Round Robin means that packets are taken from the output queues (on the C3550 there are 4, one can be set to priority, which is then not used) in a circular fashion (1, 2, 3, 4, 1, 2, etc.). By adding weight to individual queues, we ensure that a proportionate number of packets are dequeued from each queue in each round. This allows us to achieve bandwidth distribution on the port for certain queues. We can control the classification of data into queues.
SRR - Shaped/Shared Round Robin
On newer switches (such as Catalyst 3560, 3750, 2960), the technology has been changed. It uses not only output queues, but also input queues, and the WRR scheduler has been replaced by SRR. Since WRR is not very "fair," SRR tries to fix this. It can work in two modes, either Shared mode or Shaped mode. As a drop strategy, it supports only Weighted Tail Drop (WTD) with three threshold values (the first two can be changed, the third is fixed at 100%). As opposed to Tail Drop, which simply drops incoming packets when the queue is full, WTD drops certain traffic (associated with a specific threshold) earlier, before the queue is full.
The following image (from Cisco.com) schematically shows the queue solution on the Catalyst 3750, where there are 2 input and 4 output queues.

Shared mode
- is an improved version of WRR, dividing one round into mini-rounds, where it decides whether to send one packet or not (it does not send a larger number of packets from one queue at once)
- so per-round it behaves much better, but in the long run, the result is the same
- we can say that this method guarantees bandwidth for traffic (queue), but does not limit it, so if there is free bandwidth elsewhere, it can use the entire bandwidth
Shaped mode
- this mode is different, the weight determines the maximum allowed throughput
- this method guarantees and also limits the bandwidth to a given value
- the weights are specified using absolute values, the bandwidth is determined from them as interface-speed/weight
- this mode can be applied only to output queues
SRR Configuration
First, we need to divide the traffic into individual queues, which we can do either by CoS or DSCP. We always map certain CoS/DSCP values (we can specify a maximum of 8 at a time) to a specific queue and its threshold. The 3750 switch has two input queues (1 and 2) and four output queues (1, 2, 3 and 4). The threshold (related to the WTD drop algorithm) has three values available (1, 2 and 3). Threshold with id 3 has a fixed value of 100%, i.e., it drops when the queue is full. Thresholds 1 and 2 can be configured.
Note: Cisco says that most of the default settings are suitable for most applications, so changes are rarely needed.
SWITCH(config)#mls qos srr-queue input cos-map queue 1 threshold 3 5 // CoS 5 will go to input queue 1 with threshold 3 (100%) SWITCH(config)#mls qos srr-queue output cos-map queue 2 threshold 2 3 4 // CoS 3 and 4 will go to output queue 2 with threshold 2 SWITCH(config)#mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47 // DSCP values 40 to 47 will go to queue 1 with threshold 3
Setting the WTD threshold values (thresholds 1 and 2) for a specific queue is done differently for input and output queues. For output queues, we can create two setting sets (1 and 2) and then assign them to the port.
SWITCH(config)#mls qos srr-queue input threshold 1 60 70 // input queue 1, threshold 1 = 60%, threshold 2 = 70% SWITCH(config)#mls qos queue-set output 2 threshold 2 60 80 100 200 // set 2, output queue 2, threshold 1 = 60%, threshold 2 = 80%, reserved 100% for the queue, maximum 200% (where the queue can grow)
We can also set the buffer sizes, which are assigned to individual queues (i.e., the size of the queues).
SWITCH(config)#mls qos srr-queue input buffers 90 10 // queue 1 = 90%, queue 2 = 10%, this is the default SWITCH(config)#mls qos queue-set output 1 buffers 25 25 25 25 // creates set 1, where all 4 queues have 25%, this is the default
For input queues, the weight is set globally. This allows us to configure the bandwidth that each queue should have.
SWITCH(config)#mls qos srr-queue input bandwidth 4 4 // queue 1 = 4/(4+4) = 1/2 of the bandwidth, queue 2 = 1/2, this is the default setting
We can set one input queue as priority (expedited forwarding), which is prioritized when congested. If we want to disable the priority queue, we set the weight = 0 (by default, input queue 2 is the priority one).
SWITCH(config)#mls qos srr-queue input priority-queue 1 bandwidth 10 // queue 1 is the priority queue and has a reserved bandwidth of 10% (the maximum can be 40%)
For the output queues, we have created sets, which we then apply to the port. By default, all ports have set 1.
SWITCH(config-if)#queue-set 2
On individual ports, we can set the Shaped or Shared mode and distribute the bandwidth for the individual output queues (set their weight).
SWITCH(config-if)#srr-queue bandwidth share 25 25 25 25 // shared mode, all queues have 25%, default SWITCH(config-if)#srr-queue bandwidth shape 25 0 0 0 // shape mode, queue 1 gets 25% and the other queues are in shared mode (specified 0), default
We can also set one output queue on the port as priority. By default, there is none. If we use the priority queue, the weight settings (shared, shaped) for queue 1 are ignored.
SWITCH(config-if)#priority-queue out // queue 1 becomes the priority queue
If we want to limit the total port speed, we can use a simple command that sets a percentage of the speed. We can specify 10 to 90%.
SWITCH(config-if)#srr-queue bandwidth limit 80
I also provide a list of related show commands.
SWITCH#show class-map test-class SWITCH#show mls qos SWITCH#show mls qos aggregate-policer test-policer SWITCH#show mls qos input-queue SWITCH#show mls qos interface SWITCH#show mls qos maps SWITCH#show mls qos queue-set 1 SWITCH#show mls qos vlan 100 SWITCH#show policy-map test-policy
Auto-QoS
By default, QoS on the switch is disabled and packets are processed using BestEffort. If we enable QoS, certain pre-set values are used, which are sufficient for general traffic (but we must set some things manually). The Auto-QoS feature is used to simplify the configuration. Auto-QoS gets an idea of the network design and as a result configures QoS completely for the given purpose (changes the default values and configures everything necessary, including enabling QoS).
Auto-QoS is applicable for Cisco IP phones, Cisco SoftPhone, and uplink ports (trunks), where it trusts the transmitted values. It allows detecting the presence of a Cisco phone, configures classification and output queues.
Auto-QoS is configured on ports. On the first use, it enables QoS, adjusts the Cos-DSCP map, maps certain CoS and DSCP values to input and output queues, configures threshold values and queue sizes, creates a priority queue on the port, sets trust for CoS and DSCP for cisco-phone, and may create certain Policy maps and Class maps (with the word AutoQoS in their name). On subsequent use, it configures only the given port.
When using Auto-QoS, a series of commands are executed, as if we had entered them ourselves using the CLI. This can overwrite part of our configuration, or our configuration can cause problems for Auto-QoS. So, it is recommended to use Auto-QoS before performing our own QoS configuration. If we remove Auto-QoS from a port using the no keyword, the related commands are removed from the port (not from the global configuration).
The configuration is really simple.
SWITCH(config-if)#auto qos voip cisco-phone // Cisco IP phone, requires CDP SWITCH(config-if)#auto qos voip cisco-softphone // Cisco SW IP phone SWITCH(config-if)#auto qos voip trust // trunk port SWITCH(config-if)#no auto qos // removes the configuration from the port
We can use the following to check the settings.
SWITCH#show auto qos interface g1/0/1
Zaujimalo by ma aky druh oznacenia v tomto ptikaze oznacuje cisco-phone
SWITCH(config-if)#mls qos trus device cisco-phone
je to hostname(asi nie), alebo nejakym prikazom oznaceny nazov zariadenia k mac adrese?
A ci sa auto-qos pocas pouzivania meni, alebo berie statistiky len z prvotneho provozu.
Ak sa dynamicky meni ako sa sprava k nami doplnenemu qos?
respond to [1]morgun: ? cisco-phone neoznačuje přímo jedno zařízení, je to něco jako makro a značí libovolný Cisco IP telefon (informace se zjistí přes CDP).
Auto-qos se při používání se nemění. Po použití příkazu se spustí "makro", které vytvoří konfiguraci (napevno nastaví příkazy).
Zrovna na 2950 bych potreboval obcas manualne omezit rychlost na urcitych portech, tak jednoduse jak na 2960, ale srr-queue bandwidth tam nejde a speed 10 neomezi dostatecne.
Omlouvám se za slovíčkaření, ale jsem mimo misku, když si myslím, že věta: "Aby mohli pakety nést údaj CoS (Class of Service) v 2. vrstvě OSI, tak musí být port v módu 802.1q trunk", by měla znít: "Aby mohli RÁMCE nést údaj CoS (Class of Service) v 2. vrstvě OSI, tak musí být port v módu 802.1q trunk"? ;-)
respond to [4]Sas: Správně :-). Napsal jsem tu článek, že se často nesprávně zaměňuje termín paket a rámec a dopustil jsem se toho také.
Dobrý den, prosím o radu jak nastavit na switchy qos pro IPTV ( multicast ) používáme tedy suwitche DCN a mypu ale ios je tam skoro schodny s ciscem.
Nevim jak mam zaradit do skupiny multicas v urcitych vlanach a ostatni v jine vlane.
treba na
vlan 100 a 101 IPTV multicas
vlan 200 data
vlan 300 servis
Děkuji moc za radu