![]() |
|
| F E A T U R E | |
Fine-Tuning for IP QoS November 27, 2000 By Joel Conover Networked applications are evolving far faster than the infrastructure that supports them. And whether you're ready for it or not, convergence is just around the corner. All this is creating a problem -- poor application performance in the enterprise. Many enterprises today are faced with an age-old dilemma that seems to creep into every network: Throw more bandwidth at the problem, or manage the existing bandwidth more effectively. IP QoS (Quality of Service) is a highly effective way of getting more out of your existing LAN and point-to-point WAN connections. Furthermore, chances are that your existing infrastructure already has the functionality necessary to implement IP QoS with only a few software changes. This primer on IP QoS takes an in-depth look at many different aspects of IP QoS, with a focus on how to enable this functionality on a variety of Cisco Systems internetworking equipment. Increasing Need QoS has been available on Cisco routers and switches for many years. To date, most enterprises have not needed that provided functionality. However, with increased Internet and intranet usage, and a market that is accelerating toward converged networks, the need for IP QoS is growing. IP QoS is deployed primarily at the enterprise LAN-WAN boundary. Cisco controls a pervasive share of that market segment; thus it only makes sense that we focus on the features and functionality existing Cisco networking equipment can provide to fulfill IP QoS needs. You should be aware, however, that there are software and hardware products that can help you fine-tune your network for optimal bandwidth shaping--for example, Packeteer PacketShaper hardware and Sitara Networks QoSWorks bandwidth manager (see "Packeteer PacketShaper 2500: Traffic Control on Autopilot," and "When Bandwidth Is Tight, QoSWorks Does More With Less"). These tools give you fine-grained control over IP QoS on your network and provide extensive monitoring and SLA (service-level agreement) management functionality. We do not intend to do any injustice to these software and hardware tools but rather will focus on how you can use your existing investment to get the most out of your network. Unlike these tools, Cisco's offering has aggregated bulk traffic management and little in the way of statistics reporting. But the Cisco functionality is built into the hardware and does not require a significant investment as other add-on products do. After all, the bottom line is what counts, and when it comes to keeping your WAN costs low, adding dedicated bandwidth-management hardware to every location adds up quickly. You should understand that the IP QoS we talk about here has nothing to do with the IP QoS on the public Internet, nor does it have to do with differentiated services on service provider networks. We are not talking about putting your packets on a public network and expecting them to be differentiated from the rest of the traffic on that network, even though the same concepts apply. The networks we are talking about here are point-to-point or are private networks with service-level guarantees for bandwidth and latency. Enterprise IP QoS is not about improving the performance of your service provider's network. It is about ensuring that congestion at the customer premise is managed properly. We're assuming there is a serial link between two points, and that once a packet enters that link, it arrives at the other side. IP QoS helps shape and control which packets get on the link first. To give you a hands-on approach to Cisco's IP QoS, we invited Cisco to our partner lab at Schneider National, in Green Bay, Wis. We worked with Cisco to develop a number of tests and demonstrations that delivered on every aspect of IP QoS, from the simplest differentiation to a complex solution that included directory integration and policy management. To demonstrate QoS features, we took advantage of several components of Cisco's AVVID (Architecture for Voice, Video and Integrated Data), including its IP telephony solution and IPTV software. We also used a variety of typical traffic types, including HTTP traffic and Napster, to demonstrate how IP QoS can benefit any network. IP QoS: A Systematic Approach Deploying QoS on the network should be approached systematically. Before rolling out an extensive set of QoS policies, you need to identify the who, what, where, when, why and how of your network and the applications running on it. You'll need to determine whether you want to give all users equal access, or whether you are trying to differentiate traffic based on specific users or groups of users. Examples could include giving the CEO priority access to the Internet, prioritizing financial data over engineering CAD files across the WAN, or globally ensuring delivery of IP telephony or video traffic regardless of the user. User-based QoS is at the fringe of what we consider reasonable deployment. It is relatively simple to apply QoS to a specific user if he or she is always assigned the same IP address, in the same way that it is simple to apply an ACL (access control list) to a specific IP address. But if that user is mobile, moves among several remote locations or is part of a general DHCP address pool, assigning QoS can be problematic--but not impossible, especially in an all-Cisco environment.
QoS is available as a tool to ensure delivery of your mission-critical, revenue-generating traffic. If your users or helpdesk is complaining about slow response times for order-entry, inventory-tracking, ERP (enterprise resource planning) or CRM (customer-relationship management) applications, and you are running these applications across the WAN, now would be a good time to determine why. If you are considering converged technologies that are highly delay sensitive, now is also a good time to start worrying about QoS. If your average WAN utilization is under 50 percent and burst traffic does not regularly peg the connection, then IP QoS can probably wait. QoS is necessary only on network segments that suffer from high delay because of serialization or congestion. For most enterprises, that's on the WAN. However, as we mentioned, you can also deploy IP QoS in the LAN to ensure delivery from the LAN-WAN boundary to the end workstation. Likewise, you may want to enlist some of your LAN hardware to off-load packet classification by the router. By using IP precedence (or IP DiffServ) coloring on your LAN, you can off-load some of the processing that the router would otherwise have to do. The primary reason to use QoS is to save money. IP QoS can help you use the WAN pipes you have more effectively. And because you can use existing hardware, you really can get something for nothing. Of course, IP QoS lets you stretch your bandwidth budget only so far. Eventually, you'll have enough mission-critical applications vying for bandwidth that the only choice will be to add more bandwidth. But you can use IP QoS as an incremental step to extend the value of your existing investment. Before you go any further, you need to make some decisions about how you are going to handle the traffic on your LAN and WAN. That boils down to which applications you are going to prioritize, how you are going to prioritize them and how much bandwidth they are going to get. There is no substitute for planning at this crucial point, and likewise, there is no substitute for testing and staging before you roll the changes out. Below are some tips for analyzing, implementing and testing your strategy to get the most from your network.
| |
|
PAGE: 1 I 2 I 3 I NEXT PAGE |
|


Although QoS is deployed primarily at the LAN-WAN boundary, you may also want to deploy QoS in a LAN environment to ensure that localized LAN congestion does not clobber traffic your router labored to protect. Also, LAN switches with IP QoS recognition and tagging abilities, such as the Cisco Catalyst 6000 series, can be used to reduce the load and responsibilities of the LAN-WAN router. You can save a significant amount of router CPU time by classifying traffic upstream at the switch. To use the examples in this primer, you'll need at least a pair of Cisco routers, preferably Cisco 7200 series routers. Many of the basic examples will work on 2x00 and 3x00 hardware, but the more advanced examples require the 7200 hardware to work properly.









