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:
12.0 New Features:
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:
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).
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!
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 PremiumYou'd repeat this sort of thing for each class of service you intend to have in your network, say Voice, Premium, Gold, and ElCheapo.
router(config-cmap)#match access-group 120
router(config-cmap)#match input-interface Serial 0
router(config-cmap)#match protocol tcp
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 nameIf 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!).
class-map match-any name
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 MACThe 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.
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 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 numberThese set either the IP Precedence or the Diff-Serv bits (the deeper subject we're ducking for now).
set ip dscp number
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(I've put in the ellipses, the dots, since we haven't talked about what goes there yet).
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
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 MyFirstPolicyThe 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 MyFirstPolicyCBWFQ 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:
router(config-pmap)#class Voice
router(config-pmap-c)#bandwidth 128
police bps burst-normal burst-max conform-action action exceed-action actionor more concretely:
police 16000 8000 16000 conform transmit exceed dropThe 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 16000See also: We can also affect queuing behavior within our policy map. If we configure:
random-detectwe get WRED random early packet drop behavior for traffic classes with bandwidth guarantees. We can also use the default CBWFQ, or we can configure
queue-limit packetsto 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:
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").
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)#exitrouter(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)#exitrouter(config)#interface serial router(config-if)#service-policy output MyFirstPolicy
Prior articles on QoS:
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 .