Comment on page
QoS 101
Congestion occurs when there is more traffic to be sent than the interface can physically send. Depending on the configuration, packets that are waiting to be sent can be dropped or queued. Dropping is no good because the information is lost (UDP) or it may require retransmissions (TCP). Queuing on the other hand introduces delays. For some types of traffic this might not be a problem but for voice traffic this will result in poor quality. Another important factor is delay variation, called jitter. It will also have a negative impact on voice or real time traffic.
QoS tries to model the way network devices handle traffic in order to offer each application the required QOS level in terms of congestion, delay or jitter. When deploying QoS in a network, there are 2 models that can be used: DiffServ and IntServ.
IntServ provides an Integrated Services model, where the sender application requests a QoS level from the network, and the network devices agree to offer the required level end-to-end, from the sender to the receiver. The routers will have to implement a signalling method to communicate with the sender and with each other in order to agree if such a service level can be delivered or not. The signalling protocol used for IntServ is RSVP (Resource Reservation Protocol).
DiffServ provides a Differentiated Service model, where each router along the path from sender to the receiver must be manually configured to offer the required QoS level for the application. There is no signalling protocol involved so routers and applications do not talk to each other. So how does one router know what the application level should be? The process of Classification will do that. Traffic will be separated into different classes and each class will be treated differently. Usually, traffic classification is performed at the network edge and then the traffic is marked according to the Type of Service that should be assigned to it. For each QoS marking a PHB (Per Hop Behaviour) is configured that defines the QoS level.
Before MQC, there were 4 types of Queuing mechanisms that could be used on an interface of a Cisco Router. They are known now as legacy methods of configuring QoS: FIFO, WFQ, PQ, CQ. See Legacy Congestion Management for more details.
Additionally, IP RTP Priority and IP RTP Reserve are ways of configuring a Priority Queue for RTP (usually voice) traffic.
There are 2 methods for congestion avoidance: Tail Drop and (Weighted) Random Early Detection.
See Congestion Avoidance – WRED for more details.
MQC is a Cisco CLI Component used to apply QoS settings. In newer IOS versions, HQF is used instead of MQC. HQF is a an extended implementation of MQC that allows the use of hierarchical policies. They actually work pretty much the same.
There are 3 steps when using MQC:
R(config)# class-map CLASS [match-all | match-any]
!match-all = AND (default)
!match-any = OR
Now add match criteria for the class:
R(config-cmap)# match ATTRIBUTE VALUE
A policy is a list of Classes and the actions defined for each class:
R(config)# policy-map POLICY
R(config-pmap)# class CLASS
Now, inside each class you can define the QoS parameters for Marking, CBWFQ for Congestion Management, Class-Based WRED for Congestion Avoidance, Policing or Shaping and so on. You can also define a service policy for a class, which will make use of HQF, thus making the current policy the parent of the policy defined in the service policy
Here are some of the things you can define for each class:
R(config-pmap-c)#?
Policy-map class configuration commands:
bandwidth Bandwidth
compression Activate Compression
drop Drop all packets - used as a Security feature
exit Exit from class action configuration mode
log Log IPv4 and ARP packets - used as a Security feature
netflow-sampler NetFlow action
no Negate or set default values of a command
police Police
priority Strict Scheduling Priority for this Class
queue-limit Queue Max Threshold for Tail Drop
random-detect Enable Random Early Detection as drop policy
service-policy Configure Flow Next
set Set QoS values
shape Traffic Shaping
In a policy, all traffic that is not matched by the defined classes will be considered to be inside the default class. This class can be configured using:
R(config-pmap)# class default-class
R(config-if)# service-policy {input | output } POLICY
To verify the configuration, use one of the following commands:
R# show class-map
R# show policy-map [POLICY class CLASS]
R# show policy-map interface INTERFACE
See Header and Payload Compression, Link Fragmentation and Interleaving or look for Frame Relay Fragmentation Support.
Frame Relay offers some specific QoS configuration options which are detailed in the Frame Relay QoS article.
Last modified 2yr ago