Cisco QoS is typically configured on modern equipment using the Modular QoS Command-line interface (MQC). With MQC, traffic is classified using the class-map and match commands, traffic policy is defined using the policy-map, class and set commands and policies are assigned using the service-policy command.

Another method which can be used is through the use of AutoQoS. AutoQoS takes much of the manual configuration out of the process and creates class and policy maps which are typical of most traffic (as defined by which version of AutoQoS you are using) and sets up policies on the interfaces you specify in a guided setup.

Let’s take a look at what the configuration looks like for both MQC and AutoQoS.

MQC Configuration

Here are a few of the MQC commands mentioned above; keep in mind that there are more match and set commands available, below is just a sampling.

class-map

router(config)#class-map class-map-name

This command is used to create a specific class-map. The class-map-name parameter is used to specify the name of the class-map and can be up to 40 alphanumeric characters.

match protocol

router(config-cmap)#match protocol protocol-name

This command is used to match a specific protocol. The protocol-name parameter is used to specify the protocol name to be matched, there are several which can be used including dhcp, eigrp, h323, http and irc.

match cos

router(config-cmap)#match cos cos-value [cos-value]

This command is used to match a specific Class of Service (CoS) value. The cos-value parameter is used to specify the CoS value carried in the frame to be matched; multiple cos-value’s can be specified in one command.

match dscp

router(config-cmap)#match dscp dscp-value [dscp-value]

This command is used to match a specific Differentiated Services Code Point (DSCP) value. The dscp-value is used to specify the DSCP value carried in the packet to be matched; multiple dscp-value’s can be specified in one command.

policy-map

router(config)#policy-map policy-map-name

This command is used to create a specific policy map. The policy-map-name parameter is used to specify the name of the policy-map and can be up to 40 alphanumeric characters.

class

router(router-pmap)#class {class-name | class-default}

This command is used to link a policy to a specific class-map. The class-name is used to match the class-map-name configured in the class-map command. The class-default parameter is used to specify the default class-map.

set cos

router(config-pmap-c)#set cos cos-value

This command is used to set a specific CoS value. The cos-value parameter is used to specify the Class of Service value which will be set in the frame.

set dscp

router(config-pmap-c)#set dscp dscp-value

This command is used to set a specific DSCP value. The dscp-value is used to specify the DSCP value which will be set in the packet.

service-policy

router(config-if)#service-policy {input | output} policy-map-name

This command is used to link a policy map to an interface The input and output parameters are used to specify in which direction the policy is to be evaluated. The policy-map-name parameter is used to specify the matching policy-map name.

MQC Example

To wrap this up together a bit, the following is a sample configuration which matches all H.323 traffic and gives it a DSCP value of EF (Expedited Forwarding). The configuration will then be configured to be evaluated on traffic coming into an interface.

router(config)#class-map h323

router(config-cmap)#match protocol h323

router(config)#policy-map h323-policy

router(config-pmap)#class h323

router(config-pmap-c)#set dscp EF

router(config-if)#service-policy input h323-policy

AutoQoS Configuration

There are actually two different types of AutoQos: AutoQoS for VoIP (which was the first iteration) and AutoQoS in the Enterprise (which detects the traffic types and builds policy based on this data).

auto qos voip

router(config-if)#auto qos voip

This command is used to install the AutoQoS configuration onto a specific interface.

auto discovery qos

router(config-if)#auto discovery qos

This command is used to start the traffic discovery portion of AutoQoS in the Enterprise. This command should be run for an amount of time to properly detect traffic types before using the next command.

auto qos

router(config-if)#auto qos

This command is used to install AutoQoS in the Enterprise configuration onto a specific interface.

QoS Resources

To learn more about Qos Configuration take a look at this QoS Whitepaper from Cisco and if you’re interested in going as far as the Cisco QOS (642-642) Exam then I’d definitely recommend the Cisco QOS Exam Certification Guide.

Each one of these classes is then configured for a specific level of service which is provided to the traffic. What parameters are set for each service class is configurable and depends greatly on the requirements of the specific traffic.

QoS Basics

There are four major traffic characteristics which are used to classify traffic, these include:

Bandwidth

This is a simple concept; how much total sustained bandwidth is required for the specific traffic type.

Delay

Delay is typically measured from end-to-end and simply records the amount of acceptable delay from source to destination.

Jitter

Jitter is a little more complex in that it defines delay variation. Delay variation is the amount of variation in end-to-end delay which happens from packet to packet. For example, one packet may be delayed so much more than the second packet that the second packet actually gets to the destination before the first.  With data traffic this is not an issue as some reassembly is expected and part of that is reordering the packet. However, with traffic types like voice, getting to the destination out of order lead to voice quality problems.

Loss

Again a simple concept; this is simply the number of packets which are lost from end-to-end.

When classifying traffic it is vital that each traffic type have the correct QoS parameters assigned in order for the network to prioritize correctly.

QoS Models

There are three QoS models which are used in order to provide the correct traffic characteristics. These three models are: Best Effort, Integrated Services and Differentiated Services.

Best Effort

The Best Effort model is rather simple and is the most common on public networks. This model simply gives all traffic the same amount of priority.  All traffic is routed in the same manner and the speed and path of a specific packet is determined by typical destination based networking protocols and equipment.

Integrated Services (IntServ)

The Integrated Services (IntServ) model is considerably more complex. With this model, traffic coming into the network requests a specific traffic class or specific traffic characteristics. For example, if a voice call is trying to be initiated, the phone will typically request a traffic path with specific low (lower) bandwidth, low delay, low jitter and low loss characteristics. These specific traffic characteristics are requested from  each network device from source to destination, if the specific characteristics are available then they are reserved and the traffic is allowed. If the traffic exceeds the specific characteristics setup at the beginning, the networking equipment may drop those packets which do not conform. The Resource Reservation Protocol (RSVP) is typically used to implement IntServ.

Differentiated Service (DiffServ)

The Differentiated Service (DiffServ) model comes at QoS differently; with DiffServ resources are not reserved at the beginning of a traffic flow like with IntServ. DiffServ utilizes classification and marking mechanisms to specify the expected priority that the traffic type expects, this process is typically done at the entry of the network. Each of these devices is then individually configured to react to these specific markings.

Traffic characteristics are maintained through traffic policing and traffic shaping. With traffic policing, traffic with specific markings will be provided a configured service quality (at this device only). If the traffic exceeds the configured amount of service then the device has the ability to drop all non-conforming traffic. With traffic shaping, the traffic is given a little more flexibility and the device attempts to “shape” the traffic into the configured settings. Again, if the traffic is too much out of conformance the device has the ability to drop non-conforming packets.  The DiffServ model is typically deployed over IntServ as it requires a less complex configuration.

Learn more about the DiffServ Model.

Congestion Mechanisms

Another part of this equation is how the network deals with congestion. All of us have been victim to a slow Internet connection from time to time and this is because of network congestion. Simply put, there is more demand for traffic bandwidth then there is supply to service it. How the network deals with these situations is just as important as how it deals with specific traffic service types.

There are two main ways to deal with congestion: Management and Avoidance. These two can also be used with each other. Congestion management looks to deal with congestion after it is already occurring, while congestion avoidance tries to prevent congestion from occurring in the first place.

Congestion management is provided by queue management and gives the ability to queue traffic at a specific point in order to give the equipment time to forward earlier traffic; it also has the ability to skip certain high priority traffic to the front of the queue in order to provide an even higher level of service. There are many queue mechanisms including:

• Weighted Fair Queueing (WFQ)
• First In – First Out (FIFO)
• Class Based – Weighted Fair Queueing (CBWFQ)
• Priority Queueing (PQ)
• Low Latency Queueing (LLQ)

WFQ and FIFO are the most used as they are the default on many interface types.

There are a couple of congestion avoidance mechanisms: Tail Drop and Weighted Random Early Detection (WRED).

Tail Drop is the default with most devices and simply drops all traffic which arrives to a device with full queues. WRED works by selectively dropping packets depending on the average queue size and the priority markings of the traffic. The specifics of the WRED algorithm are outside the scope of this article as it can be quite complex.