New QoS Features in Cisco IOS 12.1 http://www.netcraftsmen.net/welcher/papers/newqos121.

html

New Quality of Service Features in Cisco IOS

12.1
Peter J. Welcher

Introduction
I've been looking at new Cisco IOS features in Quality of Service (QoS), IP multicast (IPmc), Firewall
features, IPSEC and VPN's, NetFlow, and Mobile IP recently for a course a Mentor Technologies
team has been developing. I'm very impressed with what I'm seeing! Since my brain is currently full of
this stuff, it's probably what's going to appear in the next few articles.

Yes, 12.1 is available. The usual caveats about running brand-new releases apply. IOS 12.1 does
however collect a number of new features slipped into 12.0(mumble)T releases, broadening the
platform support. It also (we trust ) incorporates tested and debugged code. I was surprised when I
started reading the features lists. There's lots of goodies there! Be sure to look at the alphabetic listing,
it's a lot nicer to work with than doing it release by release. (First link below).

12.1 Info:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/index.htm

12.0 New Features:

http://www.cisco.com/warp/public/cc/cisco/mkt/ios/rel/120/prodlit/815_pb.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/new120t.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/index.htm

If you look back at prior articles, you'll notice I slipped in some of the 12.0 new features. The
Command Line Interface search capabilities are one such, see the misctopic link below. And reflexive
access lists made up an article, see the link below. But by and large we haven't really covered much of
the new features here. Time to change that!

http://www.netcraftsmen.net/welcher/papers/misctopic.html

1 of 8 1/2/03 10:09 AM
New QoS Features in Cisco IOS 12.1 http://www.netcraftsmen.net/welcher/papers/newqos121.html

http://www.netcraftsmen.net/welcher/papers/reflexiveacl.html

I would normally point you at my prior articles on QoS at this point. But there's a new approach so
some of what's gone before has been simplified and cleaned up, made easier to use. You may be better
off starting here and then, for comparison purposes, looking back at the older articles.

What the New Features Are

The documentation describing the new approach to QoS is about Class-Based Weighted Fair Queuing
(CBWFQ). This is classic WFQ reworked to perform based on class of traffic, as specified by the IP
Precedence (former Type of Service, or ToS) bits. The focus on Class of Service (CoS) appears
intended to make things simpler to understand than the former flow-based approach. See also:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/cbwfq.htm

Internally at Cisco this set of features seems to be known as "Modular QoS CLI", the modular
command line interface to QoS. ("MQC" for those who like acronyms). What the clever engineers
have done is somewhat reworked the CLI for configuring QoS to make it easier to understand and to
configure. Instead of having several things happening in one command, the commands now pretty
much do just one thing.

There is one reference I've found to this:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5/mcli.htm

If you're reading this article some time after this writing, please forgive any errors: this is new
sparsely-documented material. I will post a note on the web page with any corrections or clarifications.

To understand the new approach, we need to talk about four things:

Classification
Marking
Policing and Shaping
Queuing

These are the four aspects of QoS in a router or in a network. Let's define and describe each of them in
turn.

Classification is where you define you policy and tell the routers how to recognize what traffic
belongs to which class of service. This is typically done at the edges of a network, leaving the
backbone or core to do more in the way of queuing and efficient routing. The classification might be
based on incoming interface (e.g. which customer of a Service Provider, which department of a
company) or on source or destination address, or other characteristics (favor PeopleSoft over FTP).
You'll still need to determine your classes of service based on Service Level Agreements (SLA's) and
business agreements or contracts.

Marking is the usual result of Classification. Once you classify a packet or flow, you want the router
to mark the packets in some way, so that the rest of the network no longer has to do deep IP header
examination, but can instead act upon the designated class of service. Marking usually affects the IP
Precedence (aka "Type of Service" or ToS) bits in the IP header. See also "Diff-Serv" (DSCP in the

2 of 8 1/2/03 10:09 AM
New QoS Features in Cisco IOS 12.1 http://www.netcraftsmen.net/welcher/papers/newqos121.html

IOS documentation). W(e're going to duck the details of this here, due to space constraints).

Policing and Shaping is one way of reacting to marked packets. Policing is what Frame Relay
allegedly does (depending on your carrier). Traffic up to a certain level is okay (I find I can't quite
manage to say "guaranteed" in public). Bursts up to another level may be accepted, as capacity
permits. And packets above the burst level are discarded. Shaping is what ATM edge devices have to
do: feed out traffic at a controlled rate because ATM switches work on steady flows, not bursty flows.
("Token bucket" to the ATM folks). To cut to the chase, if you want predictable results in a network,
you've got to control the rate at which traffic enters the network. (Just like those on-ramps to
interstates with metering lights?)

Queuing is what you need to do downstream of all of this, in particular on the WAN links in the
network. Queuing governs the choices each device makes as to how and in what order to put packets
out on the wire.

Let's back off on the technical talk for a second and think about the business side of all this.

Classification is where you recognize that the packet comes from Joe, who paid for premium service.
(Or the CEO, who demanded it?) Or perhaps the packet came from Fred, who's frugal -- heck, cheap.
Marking is where you stamp the packet so that other routers along the path can benefit from your
recognition of the packet. Policing and Shaping is where you throttle bursts -- so maybe Cheap Fred
gets less bandwidth than Hi-Octane Joe, at least as long as Joe's using his share. That's an incentive for
your users or customers to pony up and pay for the service they're getting. (This all assumes your
service is good enough the Premium customers are going to actually notice they are getting better
service). And queuing is where you handle getting packets out of a particular device onto the wire.
Given the choice of Fred's or Joe's packet sitting in queues, well, maybe Joe gets to go first. Or more
real-world: get the Voice Over IP (VoIP) packets out of the boxes fast, ahead of other traffic.

Queuing also interacts with congestion. When there's congestion, there's too much traffic. All you can
do is select whose traffic gets dropped. If you're doing differentiated service, you don't totally drop
Cheap Fred's traffic, but you drop more of his than Premium Joe's.

The previous paragraphs maybe have a bit of a Service Provider spin: high- and low-paying customers.
Instead, if you prefer an Enterprise spin, think about mission-critical applications (Joe) and less critical
applications (Fred).

NBAR
There is also a new feature in IOS (XE or early release versions, so far) called Network-Based
Application Recognition (NBAR), which also just happens to use the MQC. See also:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5a/nbar.ht
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121limit/121e/121e1/nbar12e.ht

The list of supported protocols is at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5a/nbar.htm

This list will inevitably grow over time. Right now it includes:

3 of 8 1/2/03 10:09 AM
New QoS Features in Cisco IOS 12.1 http://www.netcraftsmen.net/welcher/papers/newqos121.html

Non-UDP/TCP: EGP, GRE, ICMP, IPINIP, IPSEC, EIGRP

TCP and UDP static port protocols: BGP, CU-SeeMe, DHCP/Bootp, DNS, Finger, Gopher,
HTTP, HTTPS, IMAP, IRC, Kerberos, L2TP, LDAP, MS-PPTP, MS-SQLServer, NetBIOS,
NFS, NNTP, Notes, NTP PCAnywhere, POP3, RIP, RSVP, SFTP, SHTTP, SIMAP, SIRC,
SLDAP, SNNTP, SMTP, SNMP, SOCKS, SPOP3, SSH, STELNET, Syslog, Telnet, X
Windows.

TCP and UDP stateful protocols: FTP, Exchange, HTTP, Netshow, Realaudio, r-commands,
StreamWorks, SQL*NET, SunRPC, TFTP, VDOLive.

What's new here is that the latter list includes protocols that dynamically assign port numbers. NBAR
knows enough to pick up the ports that get assigned this way. It is reaching, where necessary, into the
application or "sub-port" level to do the classification.

NBAR can also recognize URL's (with wildcards) and MIME types. So you can give preferential
service to "*.GIF" and "*.JPEG* if you so wish. The list of supported MIME types is at:

ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types

NBAR also includes Protocol Discovery, so you can easily see what application protocols (and how
much of each) are transiting the interfaces of your routers.

Now are you impressed? I am!

Configuring the New Features

The Modular QoS CLI commands match up pretty well with the four steps above.

First we need to tell the router (or switch!) how to classify traffic. This is done via a class map. Here's
a configuration snippet showing the configuration of a class map:
router(config)#class-map Premium
router(config-cmap)#match access-group 120
router(config-cmap)#match input-interface Serial 0
router(config-cmap)#match protocol tcp

You'd repeat this sort of thing for each class of service you intend to have in your network, say Voice,
Premium, Gold, and ElCheapo.

No, you probably wouldn't use all of those options that are shown in a real class map. Maintaining it
could get rather messy. You'd use just what you needed.

There are two commands you may want to use with this:
class-map match-all name
class-map match-any name

If you omit either, the default is match-all. Match-all means match all of the match conditions
following. Match-any means you just have to match one to be within the class (logical OR). And
putting in a match not apparently reverses the logical of what follows it. You can also put in "no
match-all" or "no match-any" within a class map, to disable the effects (while you're typing the class

4 of 8 1/2/03 10:09 AM
New QoS Features in Cisco IOS 12.1 http://www.netcraftsmen.net/welcher/papers/newqos121.html

map? An experiment to try!).

There are other match possiblities that I've seen mentioned in the context of NBAR, but which don't
seem to be implemented or at least documented yet. [No, I haven't done the obvious experiment yet
either]. They include:
match source MAC
match destination MAC
match ip dscp
match ip prec
match qos-group
match mpls
match any
match not (the documentation mentions this precisely once)
match class-map (note that this in effect lets you nest class-maps, very
handy)

The input-interface match criterion seems useful when all traffic from a particular interface is going to
get treated the same way. This is a per-customer (per-subnet?) approach to CoS.

The access-group match criterion is pretty powerful. You can use extended access lists to define
exactly what traffic should fall into the class. You do have to use numbered not named access lists with
this.

The match protocol option is where NBAR comes in (see above). Very powerful!

If/when you can do "match class-map", that'll be useful. You can then define class maps such as
CustomerA, CustomerB, etc., and then define Premium (level of service) to be CustomerA or
CustomerB, etc. Readable, self-documenting code!

For each class of traffic, you can specify what happens in the way of marking with:
set ip prec number
set ip dscp number

These set either the IP Precedence or the Diff-Serv bits (the deeper subject we're ducking for now).

After you've defined your classes of traffic and your classification (packet recognition) rules, pull them
all together with a policy map. Here's what a policy map might look like:
router(config)#policy-map MyFirstPolicy
router(config-pmap)#class Voice
router(config-pmap-c)#...
router(config-pmap-c)#exit
router(config-pmap)#class Premium
router(config-pmap-c)#...
router(config-pmap-c)#exit
router(config-pmap)#class Gold
router(config-pmap-c)#...
router(config-pmap-c)#exit
router(config-pmap)#class ElCheapo
router(config-pmap-c)#...
router(config-pmap-c)#exit

(I've put in the ellipses, the dots, since we haven't talked about what goes there yet).

The policy map ties together a bunch of classes and says what your policy is for each, what to do with

5 of 8 1/2/03 10:09 AM
New QoS Features in Cisco IOS 12.1 http://www.netcraftsmen.net/welcher/papers/newqos121.html

the traffic from each class. (That's the missing dots).

To activate this policy and start doing CBWFQ, you attach the policy-map to an interface with a
service-policy command:
Router(config-if)#service-policy output MyFirstPolicy

The missing part in the policy map is the actual details of the policy. There are two areas we haven't
talked about: policing and shaping and queuing. The policy details are where you specify what you
want for policing or shaping, and what you want for queuing policy for each class. Let's look at these
in order

For each class, you can specify bandwidth in Kbps. The class weights for the W (Weighted) in
CBWFQ are determined based on bandwidth configured. So our policy might start out more like:
router(config)#policy-map MyFirstPolicy
router(config-pmap)#class Voice
router(config-pmap-c)#bandwidth 128

CBWFQ exerts somewhat of a leveling effect on traffic. If we wish more control, we can use policing.
Instead of just specifying bandwidth, we can tell the router the rate to police traffic at with:
police bps burst-normal burst-max conform-action action exceed-action
action

or more concretely:
police 16000 8000 16000 conform transmit exceed drop

The idea is to specify the average bandwidth for the class (in bps) and the normal and burst levels (in
bytes). Conforming traffic has the first action applied to it, excess traffic has the second action applied.
The actions are similar to Committed Access Rate (CAR): transmit, drop, continue to next police
statement in list, set IP Precedence and transmit or continue.

The alternative which probably results in fewer drops is shaping (Distributed Traffic Shaping).
The syntax for this is:
shape [average|peak] CIR [ Bc [ Be ]]

or for a concrete example:

shape average 16000

See also:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120xe/120xe5/dts.htm

We can also affect queuing behavior within our policy map. If we configure:
random-detect

we get WRED random early packet drop behavior for traffic classes with bandwidth guarantees. We
can also use the default CBWFQ, or we can configure

6 of 8 1/2/03 10:09 AM
New QoS Features in Cisco IOS 12.1 http://www.netcraftsmen.net/welcher/papers/newqos121.html

queue-limit packets

to hard-code a queue size.

Two topics we're going to give short shrift to here: Real Time Protocol Priority Queuing (RTP PQ)
and Low Latency Queuing (LLQ). They can be used together with CBWFQ. The idea is to reserve
bandwidth and police above that amount. Traffic within the reserved bandwidth is given absolute
priority in queuing, for example, voice up to some level. The respective commands are "ip rtp
priority..." and "priority". The former reserves bandwidth for UDP ports. The latter is used with one
class within a policy map to reserve bandwidth (and police to that reserved bandwidth) for one class of
traffic. See also:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/pqcbwfq.htm

Other Ways of Doing These Things, and Related Topics

Classification and Marking: Committed Access Rate (CAR), dial peers, Policy-Based Routing, QoS
Policy Propagation via BGP (QPPB).

Policing and Shaping: CAR, Generic Traffic Shaping, Frame Relay Traffic Shaping.

Queuing: PQ, CQ, WFQ, CBWFQ, WRED, FRED, and distributed variants.

Signaling QoS: Resource Reservation Protocol (RSVP).

Link Efficiency: Link Fragmentation and Interleaving (LFI), and RTP Header Compression ("cRTP").

Sample Overall Configuration

Here's a configuration pulling all that into one place. It is not intended to do anything particular for
policy, just illustrate the commands and what this would end up looking like.
router(config)#class-map Premium
router(config-cmap)#match access-group 120
router(config-cmap)#match input-interface Serial 0
router(config-cmap)#match protocol tcp
router(config-cmap)#exit

router(config)#policy-map MyFirstPolicy
router(config-pmap)#class Voice
router(config-pmap-c)#bandwidth 64000
router(config-pmap-c)#exit
router(config-pmap)#class Premium
router(config-pmap-c)#shape 128000
router(config-pmap-c)#exit
router(config-pmap)#class Gold
router(config-pmap-c)#police 64000 40000 64000 conform transmit exceed
drop
router(config-pmap-c)#random-detect
router(config-pmap-c)#exit
router(config-pmap)#class ElCheapo
router(config-pmap-c)#random-detect
router(config-pmap-c)#exit

7 of 8 1/2/03 10:09 AM
New QoS Features in Cisco IOS 12.1 http://www.netcraftsmen.net/welcher/papers/newqos121.html

router(config)#interface serial router(config-if)#service-policy output

MyFirstPolicy

Wrap-Up
Diff-Serv information can be found in RFC's 2474 and 2475.

http://www.ietf.org/rfc/rfc2474.txt
http://www.ietf.org/rfc/rfc2475.txt

QoS information:

http://www.wiley.com/compbooks/ferguson
http://www.qosforum.com/
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm
http://www.cisco.com/warp/public/cc/cisco/mkt/ios/tech/tch/qosio_wp.htm

QoS for Voice:

http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/qosvoip/qosvoip2.htm

Preserving the Type of Service (ToS) bits (well, really IP Precedence or Diff-Serv bits) with VPN's is a
concern. There is a new command to copy the bits to an appropriate place, usually the tunnel header:
qos pre-classify.

Prior articles on QoS:

QoS Features 10/98.

Quality of Service, Part II 11/98.
Quality of Service, Part III 1/2/99.
Resource Reservation Protocol, RSVP 2/9/99.

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 .

4/5/2000
Copyright 2000, Peter J. Welcher

8 of 8 1/2/03 10:09 AM