|
This month we continue looking at Quality of Service (QoS) in Cisco devices. For last month's article, see QoS Features.
In this article, we'll look at the following topics:
The IP Precedence bits allow us to specify what traffic gets what Class of Service. RED lets us selectively drop TCP packets to throttle the sender, providing better goodput. And CAR is input-side traffic admission control, allowing us to police inbound traffic.
IP Precedence Bits
Part of the new IP QoS tool kit in routers and switches is the IP Precedence bits. Devices at the edge of the network may classify traffic as deserving a certain Class of Service using these bits. Core devices can then use the bits to provide differing types of service to different flavors of traffic.
The IP Precedence bits are the first 3 bits of the IP header Type of Service (TOS) field. They are followed by 4 TOS bits and an unused bit. The Cisco documentation relating to QoS seems to sometimes be a bit sloppy as to precedence versus TOS bits, sometimes using TOS to refer to the TOS field in a rather general way. The IETF Diff-Serv group is looking at using the Precedence bits for ISP/carrier purposes, so it is not safe to assume these bits will make it through your service provider unscathed -- they may well change the bits for their own purposes.
Cisco keyword values for precedence: critical, flash, flash-override, immediate, internet, network, priority, routine. One assumes these correspond respectively to numeric values 7 down to 0. The keywords may be found in the descriptions of the IP extended access list variants.
TOS keyword values: max-reliability, max-throughput, min-delay, min-monetary-cost, normal. TOS is not in much use today. It is up to an application to ask for the Type of Service it needs. The standing joke is that by default IP traffic is unreliable, slow, and costly, since none of the relevant TOS bits is usually turned on. Even were applications to use these bits, no-one that I know of is using them to provided differentiated service, although the IP extended access lists in the Cisco IOS do allow you to do so if you wish. This is perhaps somewhat of a chicken-and-egg problem: no reason to use TOS to provide better service if there are no customers, and no reason for applications to set the bits if it isn't going to make a difference.
Random Early Detection (RED)
About Random Early Detection (RED)
Random Early Detection (RED) is a high-speed congestion avoidance mechanism. It is not intended as a congestion management mechanism, the way the queuing techniques (PQ, CQ, WFQ) are. It is also more appropriate for long-haul trunks with many traffic flows, e.g. trans-oceanic links, rather than campus networks.
When enabled, RED responds to congestion by dropping packets at the selected rate. This is recommended only for TCP/IP networks with mostly TCP traffic. The drops are intended to cause TCP to back off its transmission rate.
TCP normally adapts its transmission rate to the rate the network can support. Each TCP flow repeats a cycle of ramping up to approximately the available bandwidth, then slowing to either near zero or near half the bandwidth, depending on the implementation. Thus a typical TCP flow may average between 1/2 and 3/4 of the available bandwidth, in the absence of any other traffic.
Multiple TCP flows tend to become synchronized, speeding up and slowing down in synchronization. This behavior is sometimes called "porpoising", because the flows surface and dive in unison, like a pod of porpoises. When congestion occurs, all TCP sessions normally get slowed down simultaneously, resulting in periods where link capacity is underutilized. By randomly slowing one TCP session, the others benefit, resulting in better goodput.
Note that dropping packets does not work with most other protocols, including AppleTalk and Novell.
When RSVP is also configured, packets from other flows are dropped before those from RSVP flows, when possible. We'll look at RSVP in a later article.
Weighted RED (WRED) allows you to specify a RED policy in combination with IP precedence, so that different types of packets are dropped at different rates and levels of congestion. You can set it so precedence is ignored, or you can set it so that lower precedence packets are more likely to be dropped. WRED is an IOS 11.1 CC or 12.0 feature.
Distributed Weighted RED (DWRED) is available in IOS 12.0 for hardware that supports it. The Distributed WRED (DWRED) feature uses the VIP rather than the RSP to perform the queuing. It requires a Cisco 7500 series router or Cisco 7000 series router with RSP.
Configuring Random Early Detection (RED)
The default is for RED to be disabled on an interface. RED is only useful on interfaces where most of the traffic is TCP. Random early detection cannot be configured on an interface already configured with custom, priority, or fair queueing. To enable RED on an interface, configure:
random-detect
You may also configure
random-detect exponential-weighting-constant constant
Here constant is a number in the range 1 to 16 used to determine the rate that packets are dropped when
congestion occurs. The default is 10. The number is an exponent used in the exponential decay rate for the weighted queue size calculation used in RED. It is suggested that you change the default with caution. A big value means the queue size measurement changes slowly, making RED less responsive. The formula used for tracking queue size is:
average = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)
where n is the exponential weighting constant.
To configure WRED on an interface, configure:
random-detect precedence <0..7> <min-thresh> <max-thresh> <mark-probability-denom>
In this command, precedence refers to IP precedence, number 0 to 7. And min-thresh is the minimum threshold in number of packets, from 1 to 4096. When the average queue length reaches this number, RED begins to drop packets with the specified IP precedence. The number max-thresh is the maximum threshold in number of packets, from 1 to 4096. When the average queue length exceeds this number, WRED drops all packets with the specified IP precedence. Finally, mark-prob-denom is the denominator for the fraction of packets dropped when the average queue depth is max-threshold, in the range 1 to 65536. If the denominator is 512, one out of every 512 packets is dropped when the average queue is at the max-threshold. The value is from 1 to 65536. The default is 10.
The per-precedence min-threshold defaults are 9/18, 10/18, ... 16/18 of the max-threshold size, for precedences 0 through 7 respectively. The max-threshold is determined based on interface speed and output buffering capacity.
Relevant EXEC Commands
show interface
show interface [interface] random-detect
Sample Configuration
RED configuration
interface Hssi0/0/0
ip address ...
random-detect
WRED configuration
interface Hssi0/0/0
description 45Mbps to R1
ip address ...
random-detect exponential-weighting-constant 9
random-detect precedence 0 540 1080 10
random-detect precedence 1 607 1080 10
random-detect precedence 2 674 1080 10
random-detect precedence 3 741 1080 10
random-detect precedence 4 808 1080 10
random-detect precedence 5 875 1080 10
random-detect precedence 6 942 1080 10
random-detect precedence 7 1009 1080 10
random-detect
Committed Access Rate (CAR)
About Committed Access Rate (CAR)
Committed Access Rate (CAR) has two functions:
- Packet Classification, using IP Precedence and QoS group setting
- Access Bandwidth Management, through rate limiting
So CAR is basically the input side of Traffic Shaping (which we've talked about somewhat in a prior Frame Relay article).
Traffic is sequentially classified using pattern matching specifications, just like access lists, on a first-match basis. The pattern matched specifies what action policy rule to use, based on whether the traffic conforms . That is, if traffic is within the specified rate, it conforms, and is treated one way. Non-conforming (excess) traffic can be treated differently, usually either by giving it lower priority or by dropping it. If no rule is matched, the default is to transmit the packet. This allows you to use rules to rate limit some traffic, and allow the rest to be transmitted without any rate controls.
The possible action policy rules:
- transmit
- drop
- continue (go to next rate-limit rule on the list)
- set IP Precedence bits and transmit
- set IP Precedence bits and continue
- set QoS group and transmit
- set QoS group and continue
IP Precedence uses the 3 bit precedence field in the IP header. This gives up to 6 Classes of Service (CoS): 0-5 can be used, but 6 and 7 are reserved per RFC791.
QoS group is an identifier within the router only. It can be set by CAR or by QPPB (see elsewhere). The QoS group is a number in the range 0 to 99, with 0 the default for unassigned packets (and not usable in assignments of QoS group).
The configurable parameters include:
- committed rate (bits/second) -- in increments of 8 Kbps
- normal burst size (bytes) -- how many bytes are handled in a burst above the committed rate limit without a penalty
- extended burst size (bytes) -- number of bytes in an extended burst -- beyond this, packets are dropped
For traffic falling between normal and extended burst sizes, selected packets are dropped using a RED-like managed drop policy. (See RED, elsewhere).
Configuring Committed Access Rate (CAR)
It's mostly one long command, repeated over and over with various rule specifications:
[no] rate-limit {input|output}
[access-group [rate-limit] <acl-index> | qos-group <qos-group> ]
<bps> <normal-burst> <extended-burst>
conform-action { drop|
transmit|
continue|
set-prec-transmit <precedence> |
set-prec-continue <precedence>
set-qos-group-transmit <qos-group>
set-qos-group-continue <qos-group>}
exceed-action { drop|
transmit|
continue|
set-prec-transmit <precedence> |
set-prec-continue <precedence>|
set-qos-group-transmit <qos-group>|
set-qos-group-continue <qos-group>}
The arguments bps, normal-burst, extended-burst are as noted prior to this section (committed rate in bps and burst sizes in bytes).
Traffic matches can be specified using access-lists:
[no] access-list rate-limit acl-index {precedence | mac-address | mask prec-mask}
where acl-index is the access list number: from 1 to 99 classifies packets by precedence or precedence mask, from 100 to 199 classifies by MAC address.
And mask prec-mask is the IP precedence mask; a two-digit hexadecimal number. This is used to assign multiple precedences to the same rate-limit access list. (Precedences map to bits: precedence 0 is the 1 bit, precedence 1 the 2 bit, etc.).
Relevant EXEC Commands
show access-lists rate-limit [acl-index]
show interface [interface] rate-limit
Sample Configuration
Here's a simple sample:
interface Hssi0/0/0
description 45Mbps to R1
rate-limit input 20000000 24000 24000 conform-action transmit exceed-action drop
ip address 200.200.14.250 255.255.255.252
And a more complex one:
interface Hssi0/0/0
description 45Mbps to R2
rate-limit input access-group 101 20000000 24000 32000 conform-action set-prec-transmit 5 exceed-action set-prec-transmit 0
rate-limit input access-group 102 10000000 24000 32000 conform-action set-prec-transmit 5 exceed-action drop
rate-limit input 8000000 16000 24000 conform-action set-prec-transmit 5 exceed-action drop
ip address 200.200.14.250 255.255.255.252
(etc.)
access-list 101 permit tcp any any eq www
access-list 102 permit tcp any any eq ftp
Some Cisco QoS Links
The following are on-line PowerPoint slides from 1998 Networkers talks. They give a good overview of various QoS-related topics.
Deploying QoS for SP to Enable Intelligent Services: http://www.cisco.com/networkers/presentations/qos/1077_038.ppt
QoS Toolkit for Enterprise WAN: http://www.cisco.com/networkers/presentations/qos/1058_038.ppt
Advanced Quality of Service Concepts and Topics: http://www.cisco.com/networkers/presentations/qos/1182_048.ppt
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 eleven CCIE's (4 of whom are double-CCIE's, R&S and Security). NetCraftsmen has 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/about-us/bios/staff-articles-and-blogs/pete-welcher.html . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.
12/2/98
Copyright (C) 1998, Peter J. Welcher
|
Resources 
