Home 
Resources Archived Articles Newsletter: Cisco AutoQoS
Resources Archived Articles Newsletter: Cisco AutoQoS
| Newsletter: Cisco AutoQoS |
| Tuesday, 04 March 2003 14:55 | ||||||||||||||||||||||||||||||||||||||||||||
IntroductionIn our recent consulting, we've been seeing a lot of networking shops eyeing Quality of Service (QoS). Some are considering QoS as a pre-requisite before deploying Voice Over IP or IP Telephony. Others are rushing to QoS to enhance or insure performance for IP Telephony (IPT), Voice Over IP (VOIP), or even IP-based Video-Conferencing (IPVC).But don't think of QoS as just something you have to or ought to put in place for such technologies. QoS is also a way of gaining more control over the application traffic mix on your network. QoS is about setting priorities, and giving precedence and bandwidth to the important or fragile traffic on your network. We're seeing many sites where backups or application traffic raise questions of prioritization and QoS. In the midst of all this interest in QoS, there is also a certain amount of QoS-phobia. (I'd call it Fear of QoS but that leads to an unfortunate acronym.) As one wades into QoS, there can appear to be too many options, too many specialized and different approaches for different environments (LAN, fast WAN, slow WAN). I've been trying to simplify and focus my presentations on the subject, to counter this. The good news here: slow immersion does seem to help. Solve the priorities, get used to QoS over time. That's where having a partner to help you work through gradual deployment of QoS and overall QoS strategy can be very helpful! Cisco apparently also saw that customers perceive QoS as too hard. That difficulty became another barrier to customers purchasing and deploying IP Telephony (IPT). Now Cisco has taken steps to make initial QoS deployment easier. The feature is called "autoqos". It does indeed make QoS deployment faster, simpler, cheaper! The emphasis here is also on initial deployment. Yes, autoqos does do a fairly good job of supporting IPT and VoIP right now. Autoqos reflects current Cisco Best Practices for VoIP, and extensive lab testing. But if you don't like the configuration generated, you can always tune it to be the way you think it should be. And if you need to support QoS for additional applications, autoqos gives you a running start. Add more classes of traffic to the autoqos-built policy and you're good to go! High-Level OverviewQoS starts with Classification and Marking at the edge of the network. Where exactly you do this is known as the "trust boundary". The idea is to specify various classes of traffic, then mark Layer 2 Class of Service (CoS) bits, or the IP Layer 3 Type of Service byte (either according to IP Precedence or Diff-Serve, DSCP). These markings can then be used downstream to determine the importance or relative priority of the traffic. The markings can also be used to guarantee at least a minimum amount of bandwidth to important traffic. They can also be used to police or shape to a maximum allowed bandwidth for less important or bandwidth-hungry traffic.Autoqos can be thought of as configuration macros. When you configure the autoqos commands, the router IOS or switch CatOS expands the few lines entered into a much larger set of QoS configuration commands. The resulting commands provide a very good set of QoS features for initial IPT deployments. And they greatly simplify that initial LAN and WAN QoS deployment. They also make it simpler to specify settings and deploy initial QoS from QPM (QoS Policy Manager). The technical person using QPM only has to specify and push out the autoqos commands, saving them from having to enter the many remaining details into a policy creation wizard. To understand how this helps, let's look at what's involved in deploying QoS before and after autoqos. Note that some of the following steps may involve entering a number of related configuration commands.
Technical Details: RoutersSee also http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080153ece.html .On the interfaces: specify bandwidth, IP address, and the command auto qos voipIf FR to ATM service interworking is being used, add "fr-atm " to the end of the command. The policy generated will reflect the configured bandwidth on the interface. Autoqos knows to use different policies for high-speed and low-speed WAN links. Autoqos is supported on serial (PPP or HDLC) links, ATM PVC's, FR PVC's, and FR/ATM service interworking links. Point-to-point sub-interfaces are required for FR and low speed ATM. The default for the autoqos command is untrusted. That is, all inbound traffic will be classified and (re-)marked. If the incoming traffic on the interface is trusted, add "trust" to the end of the command. On untrusted links, autoqos automatically classifies and marks VoIP bearer traffic, as well as MGCP, Skinny, and H.323 signaling traffic. This is facilitated by new NBAR protocols to match. NBAR has been extended to recognize various types of RTP traffic (allowing separation of video and audio), as well as the signaling protocols. This reduces the need to figure out then configure and maintain the appropriate access lists. On trusted links, the policy generated trusts DSCP as set by switches. Technical Details: SwitchesConfiguration guide: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_7_5/confg_gd/autoqos.htmAutoqos on the CatOS switches starts with the global command set qos autoqosThe ports are then configured with the commands set port macro <mod/port> [ciscosoftphone | ciscoipphone] set port qos autoqos <mod/port> voip [ciscosoftphone | ciscoipphone]The trust boundary is controlled via the port command set port qos autoqos <mod/port> trust [cos|dscp]If you want to simply trust inbound labels, the Cisco Catalyst 3550, 2950EI, and 4500 switches use the command auto qos voip trustYou can instead use the command auto qos voip cisco-phoneThis trusts inbound if CDP detects a Cisco phone on the switch port. Final ThoughtsIn case you've been wondering, "where can I get this wonderful autoqos", here's the official table of IOS / CatOS versions supporting autoqos:
A topic for another time: how to manage QoS. Part of what autoqos does is to set up internal RMON monitoring within a router, with SNMP traps reporting dropped VoIP packets. That's at least an early warning sign that bad things are happening to your VoIP! I get the sense that many shops have some tool for reporting utilization and error statistics. The reporting may be in a bit of disarray, from lack of being kept current as to network devices and links. Or web reports are being generated but nobody really looks at them. There are additional variables one could be polling and reporting on, to track device health and network stability. For example, Cisco's Class-Based QoS MIB (CBQOS-MIB), provides interesting QoS data: pre-policy and post-policy bit rates, and per-class traffic drop rate. Cisco's QDM graphs this data for a single device, and QPM can collect and report this data for many devices. At Chesapeake Netcraftsmen, we've been discussing providing a service offering involving network performance reporting. The idea is to have us cost-effectively maintain your software on your workstation, securely, remotely. We'd tune the reports, and we'd have a CCNP or CCIE look them over periodically. This expert would then write a short report summarizing anomalies and potential issues observed. If this sounds interesting, if it sounds sort of right but misses the mark, or if it seems like a really bad idea, please let us know! Questions, comments, and suggestions for further newsletters are very welcome. Please email This e-mail address is being protected from spambots. You need JavaScript enabled to view it . To have a salesperson get in touch with you, email This e-mail address is being protected from spambots. You need JavaScript enabled to view it . Other Links About AutoQoSThe first item, the technical presentation, provides good solid detail on what each autoqos command configures in the switch or router.
|
