If you're like me, you keep seeing QoS in glancing through the IOS manuals, or perhaps in looking at slides from Networkers. You may have wondered what it was all about. My goal in this and any following articles is to give you a feel for what QoS is, and (briefly, all too briefly) how to configure it. I'm hoping to tempt you to look into these features more -- and working within the space limitations of articles such as these.
If that whets your appetite for QoS, there's a book out on the topic now, Quality of Service: Delivering QoS in the Internet and in Corporate Networks , Paul Ferguson (Cisco) and Geoff Huston, Wiley Press. Paul has a nice set of links on QoS on his Web page, at http://www.wiley.com/compbooks/ferguson .
When you get right down to it, there isn't all that much a router can do to control traffic, since it is not the originator of most of the traffic. The router can drop traffic -- although we'd prefer it didn't do so. It can put some queued frames out an interface before others. It can be selective about accepting traffic -- another form of dropped traffic. And, with TCP, it can selectively drop the occasional packet as an indirect signal to slow down. With cooperative hosts, the router can try to accept reservations and hold bandwidth for applications that need it.
Acronyms, features or topics that fall under QoS include: Priority Queuing (PQ), Custom Queuing (CQ), Fair and Weighted Fair Queuing (WFQ), Random Early Detection (RED) and its Distributed, Weighted variant (DWRED), Resource Reservation Protocol (RSVP), Traffic Shaping, Committed Access Rate (CAR), Policy Routing, QoS Policy Propagation via BGP (QPPB), NetFlow, and Cisco Express Forwarding (CEF).
The first set of functions relate to queuing, to managing congestion. They are sometimes referred to as "Fancy Queuing". These include Priority Queuing (PQ), Custom Queuing (CQ), and Weighted Fair Queuing (WFQ). These features allow the router to control which frames are sent first on an interface. If there are too many frames (congestion), then we are, in effect, also selecting which frames get dropped.
These functions, Priority Queuing (PQ), Custom Queuing (CQ), and Weighted Fair Queuing (WFQ), are the subject of this article. They are also discussed as one small part of the Cisco certified ACRC course.
The next feature on the list, Weighted Random Early Detection, is intended to prevent or reduce congestion -- trying to reduce problems, rather than mitigating the consequences once the problem has already occurred.
RSVP allows for applications to reserve bandwidth, primarily WAN bandwidth. It is designed to work with WFQ or Traffic Shaping on the outbound interface.
Traffic Shaping and Committed Access Rate (CAR) control traffic. It seems like a better acronym could have been chosen: CAR controls traffic? Anyway, CAR controls the rate of inbound traffic, allowing specification of what to do with traffic that is coming in faster than policy. Traffic Shaping paces outbound traffic, controlling use of bandwidth. Traffic Shaping also allows matching the speed of the output access link across a WAN cloud, so that a faster central hub access circuit doesn't cause carrier or remote link congestion.
CAR, Policy Routing, and QPPB can also set the IP precedence bits (TOS bits), which are used by some of the above mechanisms to favor some traffic over other traffic.
Finally, NetFlow and CEF are switching techniques used in high-performance routers. They assist in providing QoS by providing efficient packet delivery and statistics on the traffic, statistics to manage traffic flow, trunk sizing, and network design with.
You can regard Priority Queuing as being drastic. It says that the high priority traffic must go out the interface at all costs, and any other traffic can be dropped. It is generally intended for use on low bandwidth links.
priority-list list-number protocol protocol-name {high | medium | normal | low} queue-keyword keyword-value
priority-list list-number interface interface-type interface-number {high | medium | normal | low}
The first of these takes a protocol, like ip, ipx, appletalk, rsrb, dlsw, etc., to classify traffic. The queue-keyword can be one of: fragments, gt, lt, list, tcp, and udp. The keyword-value specifies the port for tcp or udp, or the size for gt (greater than) and lt (less than). The word list allows you to specify an access list characterizing the traffic. And fragments means just that, IP fragments (which should probably get expedited handling, so as to not have to retransmit all the fragments again if one is lost).
The second command above is similar, but classifies traffic based on the interface it arrived on.
The list-number is any number in the range 1-16. All statements in one policy use the same number.
To change the default queue for all other traffic:
priority-list list-number default {high | medium | normal | low}
To change the queue sizes from the defaults 20, 40, 60, 80 (don't go overboard on this if you see output drops, you may make things worse):
priority-list list-number queue-limit high-limit medium-limit normal-limit low-limit
To apply the priority queueing policy for outbound packets on an interface:
interface ...
priority-group list-number
priority-list 1 protocol dlsw high
priority-list 1 protocol ip high tcp 23
priority-list 1 protocol ip medium list 101
priority-list 1 default low
priority-list 1 queue-limit 30 60 90 120
interface serial 0
priority-group 1
Here's how it works. Packets are sent from each queue in turn. As each packet is sent, a byte counter is incremented. When the byte counter exceeds the default or configured threshold for the queue, transmission moves on to the next queue. The byte count total for the queue that just finished has the threshold value subtracted from it, so that it starts its next turn penalized by the number of bytes that it went over its quota. This provides additional fairness to the mechanism.
If you think about it, you can't send half of a packet. That's why this mechanism might well exceed quota on any given round of transmission from a queue. But on the next round, the queue is penalized for taking more than it's fair share, so in the long run it averages out.
Custom Queuing is aimed at fair division of bandwidth. For instance, you might set it up to allow IP roughly 50% of a link, DLSw 25%, and IPX 25%. When congestion is taking place, the limits are enforced. If there is unused bandwidth, say from IPX, it is divided equally among any excess traffic from the other classes of traffic, IP and DLSw. To implement this, you would tweak the thresholds for the relevant queues, say making them 3000, 1500, and 1500 bytes respectively. Some fine tuning to average packet MTU size can make this more precise.
queue-list list-number protocol protocol-name queue-number queue-keyword keyword-value
queue-list list-number interface interface-type interface-number queue-number
You can specify the default queue, the one that receives any unmatched traffic, with the command:
queue-list list-number default queue-number
(The default default queue is 1).
You can specify the number of packets allowed in any queue with the command:
queue-list list-number queue queue-number limit limit-number
The threshold for a queue can be changed with the following command:
queue-list list-number queue queue-number byte-count byte-count-number
The default threshold for the queues is 1500 bytes.
And the CQ policy is applied to outbound frames on an interface with:
interface ...
custom-queue-list list-number
show interface type number
queue-list 1 protocol dlsw 1
queue-list 1 protocol ip 2 list 101
queue-list 1 protocol ip 3 tcp 23
queue-list 1 default 10
queue-list 1 queue 3 limit 40
queue-list 1 queue 3 byte-count 3000
interface serial 0
custom-queue-list 1
In WFQ, packets are sorted in weighted order of arrival of the last bit, to determine transmission order. Using order of arrival of last bit emulates the behavior of Time Division Multiplexing (TDM), hence "fair". In Frame Relay, FECN, BECN, and DE bits will cause the weights to be automatically adjusted, slowing flows if needed.
From one point of view, the effect of this is that WFQ classifies sessions as high- or low-bandwidth. Low-bandwidth traffic gets priority, with high-bandwidth traffic sharing what's left over. If the traffic is bursting ahead of the rate at which the interface can transmit, new high-bandwidth traffic gets discarded after the configured or default congestive-messages threshold has been reached. However, low-bandwidth conversations, which include control-message conversations, continue to enqueue data.
Weighted fair queuing uses some parts of the protocol header to determine flow identity. For IP, WFQ uses the Type of Service (TOS) bits, the IP protocol code, the source and destination IP addresses (if not a fragment), and the source and destination TCP or UDP ports.
Distributed WFQ is available in IOS 12.0 on high-end interfaces and router models.
congestive-discard-threshold: Number of messages allowed in each queue in the range 1 to 4096, default 64.
dynamic-queues: Number of dynamic queues used for best-effort conversations.
Values are 16, 32, 64, 128, 256,
512, 1024, 2048, and 4096. The default is 256.
reservable-queues: Number of reservable queues used for reserved (RSVP) conversations, range 0 to 1000. The default is 0. If RSVP is enabled on a WFQ interface with reservable-queues set to 0, the reservable queue size is automatically set to bandwidth divided by 32 Kbps. Specify a reservable-queue size other than 0 if you wish different behavior.
Fair queuing is enabled by default for physical interfaces whose bandwidth is less than or equal to 2.048 Mbps, except for Link Access Procedure, Balanced (LAPB), X.25, or Synchronous Data Link Control (SDLC) encapsulations. Enabling custom queuing or priority queuing on an interface disables fair queueing. Fair queuing is automatically disabled if you enable autonomous or SSE switching on a 7000 model. Fair queueing is now enabled automatically on multilink PPP interfaces. WFQ is not supported on tunnels.
Start by specifying what type of fair queuing is in effect on an interface:
[no] fair-queue [ tos | qos-group ]
If you omit tos and qos-group, you get flow-based WFQ. Otherwise you get TOS (precedence)-based or QoS-group based WFQ on the interface. You then set the total number of buffered packets on the interface. Below this limit, packets will not be dropped. Default is based on bandwidth and memory space available.
fair-queue aggregate-limit <aggregate-limit>
You also specify the limit for each queue. Default is half the aggregate limit.
fair-queue individual-limit <individual-limit>
The documentation suggests you not alter the queue limits without a good reason. To specify the depth of queue for a class of traffic:
fair-queue {tos <0-7> | qos-group <0-99> } limit <queue-limit>
Finally, to specify weight (percentage of the link) for a class of traffic:
fair-queue {tos <0-7> | qos-group <0-99> } weight <weight>
The percentages on an interface must add up to no more than 99 (percent).
show queueing fair
This restores the defaults on a T1 serial link.
interface Hssi0/0/0
ip address 188.1.3.70 255.255.255.0
rate-limit output access-group rate-limit 6 155000000 2000000 8000000
conform-action
set-qos-transmit 6 exceed-action drop
rate-limit output access-group rate-limit 2 155000000 2000000 8000000
conform-action
set-qos-transmit 2 exceed-action drop
fair-queue qos-group
fair-queue qos-group 2 weight 10
fair-queue qos-group 2 limit 27
fair-queue qos-group 6 weight 30
fair-queue qos-group 6 limit 27
access-list rate-limit 2 2
access-list rate-limit 6 6
interface Hssi0/0/0
ip address 188.1.3.70 255.255.255.0
fair-queue tos
fair-queue tos 1 weight 20
fair-queue tos 1 limit 27
fair-queue tos 2 weight 30
fair-queue tos 2 limit 27
fair-queue tos 3 weight 40
fair-queue tos 3 limit 27
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .