New Quality of Service Features in Cisco IOS 12.1
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.0 New Features:
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!
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:
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:
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:
- Policing and Shaping
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 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).
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:
The list of supported protocols is at:
This list will inevitably grow over time. Right now it includes:
- 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:
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-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 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 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:
(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 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:
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
We can also affect queuing behavior within our policy map. If we configure:
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
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:
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-cmap)#match access-group 120
router(config-cmap)#match input-interface Serial 0
router(config-cmap)#match protocol tcp
router(config-pmap-c)#police 64000 40000 64000 conform transmit exceed drop
router(config)#interface serial router(config-if)#service-policy output MyFirstPolicy
Diff-Serv information can be found in RFC's 2474 and 2475.
QoS for Voice:
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:
Copyright (C) 2000, Peter J. Welcher