|
|
The Cisco QoS Policy Manager is a full-featured QoS policy system that simplifies the complexity of configuring and deploying QoS policies for enterprise networks. It provides users with the ability to enable differentiated services, thereby providing better service for selected network traffic. This improves control over network resources and improves the cost efficiency of Wan connections. Also, it automates the task of QoS policy deployment. Relying on IP Precedence to enforce QoS policy end-to-end, QoS Policy Manager enables customers to quickly apply a mix of QoS policy objectives that expedite the handling of mission-critical applications.
The Cisco QoS Policy Manager allows the user to define rules-based policies that controls QoS application traffic across the network. The QoS Policy Manager can be used to set policies on devices that will control the bandwidth when there is bandwidth contention, otherwise data flow is uninhibited. Using a high level graphical user interface, the user can define a QoS policy for multiple devices and interfaces, validate a policy prior to deploying it to the network, and monitor the deployment of QoS policies to network devices. QoS Policy Manager provides a network view of QoS policies deployed in the network and maintains an audit trail of all policy distributions.
The QoS Policy Manager has two GUI components and a back-end process.
QoS Manager—A back-end process that is the heart of the system. QoS Manager communicates with both the Policy Manager and the Distribution Manager, stores the policy database and configures the network devices.
The system has a distributed architecture. The GUI components may or may not be installed on the same computer as the QoS Manager. A Complete installation places all the components on one computer. A remote installation places the GUI components on a different computer from the QoS Manager. The remote installation allows the user to make, change, and distribute policies from a remote location.
Effective use of Quality of Service (QoS) capabilities requires careful planning. Before you deploy QoS to your network, carefully consider the types of applications used in your network and which QoS techniques might improve the performance of those applications.
These topics can help you plan for QoS deployment:
Quality of Service (QoS) is a set of capabilities that allow you to create differentiated services for network traffic, thereby providing better service for selected network traffic. For example, with QoS, you can increase bandwidth for critical traffic, limit bandwidth for non-critical traffic, and provide consistent network response, among other things. This allows you to use expensive network connections more efficiently, and to establish service level agreements with customers of the network.
To implement QoS, you define QoS properties and policies on device interfaces. The policies can differentiate traffic based on its source, destination, or type. For example, you can recognize traffic based on the network host, port, protocol, or even IP precedence and TOS values in the packets.
QoS Policy Manager helps to provide end-to-end QoS service across a complete network.
Figure 1-1 displays the conceptual diagram of a typical network. QoS Policy Manager normally classifies data packets in the Campus Domain (RSM for Catalyst 5000, 8510 and LocalDirector). The classification is what the WAN devices (7200, 7500, 4700, 4500, 4000, 3600, and 2500) first examine at the input interface. The packet information is then compared to the QoS policies for the output interface. Based upon the QoS policies, the data packet is queued for output. The QoS policies that determine output queuing may include shaping policies or limiting policies.
Table 1-1 Cisco QoS Policy Manager Features, Uses, and Benefits
QoS primarily comes into play when the amount of traffic through an interface is greater than the interface's bandwidth. When the traffic through an interface exceeds the bandwidth, packets form a queue from which the device selects the next packet to send. The selection is based upon preset criteria. The following topics describe how QoS manages traffic based upon selectable criteria.
Table 1-2 describes the devices and IOS software releases that QoS Policy Manager supports, and the QoS techniques you can use on the supported platforms. QoS Policy Manager, version 1.0 supports up to 200 devices in a network.
Table 1-2 Supported Devices, QoS Techniques, and IOS Software Releases
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Understanding the sequence in which policies are implemented by an interface can help you define meaningful policies that implement your traffic management requirements. Figure 1-2 shows the sequence a packet follows when it reaches an interface.
When a packet reaches an interface, the interface acts upon the packet in the following sequence:
With some IOS software versions and device models, you can define a policy so that subsequent policies are considered after a match is found. In these cases, you can color a packet in one policy at the input interface, and apply a limiting policy to the same packet, perhaps by keying on the packet's color. Refer to Table 1-2 to see which combinations support Committed Access Rate (CAR) limiting or CAR classification. Normally, you should apply a coloring policy prior to applying a limiting policy. However, in some CAR cases a limiting policy can be applied at the input interface before applying a coloring policy.
Some interface QoS properties recognize a packet's relative importance by examining the IP precedence field in the packets header. Changing the IP precedence value is changing the packets color. Coloring is a property that when attached to a packet affects the way the packet is handled on its entire path through the network.
By changing a packet's color on an inbound interface, you can affect how your devices handle the packet. Interfaces that use WFQ or WRED automatically recognize and use the IP precedence value. Priority queuing and custom queuing do not automatically consider the IP precendence (coloring) of a packet. Therefore, to have coloring affect how the packet gets prioritized on a priority queue or custom queue interface, you must create an additional policy on the outbound interface that recognizes the traffic and places it in the appropriate queue (in addition to creating a coloring policy on the inbound interface). The same applies for traffic shaping and traffic limiting.
With IOS 11.1cc and IOS 12.0, coloring policies are implemented using Committed Access Rate (CAR). CAR allows the user to set policies for coloring and priority queuing, custom queuing, shaping or limiting, to be implemented on the same interface. (See "Defining a Coloring Action.") By using complex coloring policies, you can create a policy that colors a packet, then tells the IOS to examine other policies set on that interface. For example, the first policy would color the packet, then in a subsequent policy, you can key on the packet's color to apply a shaping, limiting, priority queuing or custom queuing policies.
Because IOS software applies QoS coloring policies on the input interface before queuing a packet, the coloring policy you set can affect how that packet is queued on the interface.
You can define traffic coloring policies on any type of interface. WFQ and WRED automatically consider the packet's color when queuing the packet.
For any other queuing policies, shaping policies or limiting policies you must first define a coloring policy for the inbound interface. The color key may then be examined by IOS to determine other policies for policy based routing (PBR).
In IOS software versions 11.1cc and 12.0 committed access rate (CAR) allows the user to set polices that will apply the coloring policy on the inbound or outbound interfaces. IOS then examines other policies for queuing and bandwidth control.
You can set a queuing technique on a device's interface to manage how packets are queued to be sent through the interface. The technique you choose determines whether the traffic coloring characteristics of the packet are used or ignored.
These queuing techniques are primarily used for managing traffic congestion on an interface, that is, they determine the priority in which to send packets when there is more data than can be sent immediately:
FIFO queuing is the basic queuing technique. In FIFO queuing, packets are queued on a first come, first served basis: if packet A arrives at the interface before packet B, packet A leaves the interface before packet B. This is true even if packet B has a higher IP precedence than packet A: FIFO queuing ignores packet characteristics.
FIFO queuing works well on uncongested high-capacity interfaces that have minimal delay, or when you do not want to differentiate services for packets traveling through the device.
The disadvantage with FIFO queuing is that when a station starts a file transfer, it can consume all the bandwidth of a link to the detriment of interactive sessions. The phenomenon is referred to as a packet train because one source sends a "train" of packets to its destination and packets from other stations get caught behind the train.
There are no specific requirements for creating policies on FIFO interfaces. You do not have to define any policies on these interfaces.
However, you can create traffic shaping policies or traffic limiting policies on FIFO interfaces to set the rate limit on the bandwidth available to selected traffic. You can color the traffic on a FIFO interface but it cannot be used to affect FIFO queuing.
FIFO queuing treats all packets the same: whichever packet gets to the interface first is the first to go through the interface. Traffic shaping and traffic limiting policy statements can affect the bandwidth available to a packet based on its color, but FIFO does not use the coloring value.
Priority queuing is a rigid traffic prioritization scheme: if packet A has a higher priority than packet B, packet A always goes through the interface before packet B.
When you define an interface's QoS property as priority queuing, four queues are automatically created on the interface: high, medium, normal, and low. Packets are placed in these queues based on previously defined priorities and policies. Unclassified packets are placed in the normal queue.
The disadvantage of priority queuing is that the higher queue is given absolute precedence over lower queues. For example, packets in the low queue are only sent when the high, medium, and normal queues are completely empty. If a queue is always full, the lower-priority queues are never serviced. They fill up and packets are lost. Thus, one particular kind of network traffic can come to dominate a priority queuing interface.
An effective use of priority queuing would be for placing time-critical but low-bandwidth traffic in the high queue. This ensures that this traffic is transmitted immediately, but because of the low-bandwidth requirement, lower queues are unlikely to be starved.
In order for packets to be classified on a priority queuing interface, you must create policies on that interface. These policies need to filter traffic into one of the four priority queues. Any traffic that is not filtered into a queue is placed in the normal queue.
You can also create traffic shaping policies or traffic limiting policies to define an upper range on the bandwidth allocated to selected traffic.
Priority queuing interfaces do not automatically consider the IP precedence settings of a packet. If you create traffic coloring policies on inbound interfaces (see "Traffic Coloring Techniques"), and you want the coloring to affect the priority queue, you must create a policy on the priority queuing outbound interface that recognizes the color value and places the packet in the desired queue.
Custom queuing is a flexible traffic prioritization scheme that allocates a minimum bandwidth to specified types of traffic. You can create up to 16 of these custom queues.
For custom queue interfaces, the device services the queues in a round-robin fashion, sending out packets from a queue until the byte count on the queue is met, then moving on to the next queue. This ensures that no queue gets starved, in comparison to priority queuing.
The disadvantage of custom queuing is that, like priority queuing, you must create policy statements on the interface to classify the traffic to the queues.
An effective use of custom queuing would be to guarantee bandwidth to a few critical applications to ensure reliable application performance.
In order for packets to be classified on a custom queuing interface, you must create custom queuing policies on that interface. These policies need to specify a ratio, or percentage, of the bandwidth on the interface that should be allocated to the queue for the filtered traffic. A queue can be as small as 5%, or as large as 95%, in increments of 5%. The total bandwidth allocation for all policy statements defined on a custom queuing interface cannot exceed 95% (QoS Policy Manager ensures that you do not exceed 95%). Any bandwidth not allocated by a specific policy statement is available to the traffic that does not satisfy the filters in the policy statements.
QoS Policy Manager uses the ratio in these policies, along with the packet size specified when you define an interface as a custom queue, to determine the byte count of each queue.
The queues you define constitute a minimum bandwidth allocation for the specified flow. If more bandwidth is available on the interface due to a light load, a queue can use the extra bandwidth. This is handled dynamically by the device.
All packets that have not been classified for custom queuing are placed in the default queue.
You can also create traffic shaping policies or traffic limiting policies to define an upper range on the bandwidth allocated to selected traffic. Thus, the custom queue defines a minimum bandwidth, and the shaping policy or limiting policy defines an upper limit. When defining the bandwidth upper limit, the shaping or limiting policy must be executed before the custom queue policy, and it must filter the same traffic as the custom queue (or a subset of the same traffic).
Custom queuing interfaces do not automatically consider the IP precedence settings of a packet. If you create traffic coloring policies on inbound interfaces (see "Traffic Coloring Techniques"), and you want the coloring to affect the custom queue, you must create a policy on the custom queuing outbound interface that recognizes the color value and places the packet in the desired queue.
Weighted fair queuing acknowledges and uses a packet's priority without starving low-priority packets for bandwidth. Weighted fair queuing divides packets into two classes: interactive traffic is placed at the front of the queue to reduce response time; non-interactive traffic shares the remaining bandwidth proportionately.
Because interactive traffic is typically low-bandwidth, its higher priority does not starve the remaining traffic. A complex algorithm is used to determine the amount of bandwidth assigned to each traffic flow. IP precedence is considered when making this determination.
Weighted fair queuing is very efficient, and requires little configuration.
Weighted fair queuing interfaces automatically create queues for each traffic flow. No specific policies are needed.
However, you can also create traffic shaping policies or traffic limiting policies to affect how selected traffic is handled on the interface. A shaping policy or a limiting policy can control the bandwidth available to the selected traffic, whereas a coloring policy can change the relative importance of a packet and thus change how the interface queues the traffic.
Weighted fair queuing is sensitive to the IP precedence settings in the packets. Weighted fair queuing automatically prioritizes the packets without the need for you to create policies on the weighted fair queuing interfaces. However, if you do create a coloring policy on the weighted fair queuing interface, it will affect how the selected traffic is queued. Weighted fair queueing can improve network performance without traffic coloring policies.
When using coloring for weighted fair queuing, or WRED, you should be aware that traffic starting devices can set precedence fields in their outgoing packets. Thus, it is important to set IP precedence on all network access points in order to avoid unintended traffic receiving high priority.
In Weighted Round Robin (WRR) there are four queues for each interface. Incoming traffic is placed in one of the four queues based upon precedence. The system gathers IP precedence information from the service type field of the IP header. For an incoming IP packet, the first two (most significant) bits of the service type field determine the priority. The system recognizes the four QoS classes as summarized in Table 1-3.
Table 1-3 QoS Queue Assignment Precedence
Bandwidth is not explicitly reserved for these four queues. Each queue is assigned a different weighted round-robin (WRR) scheduling weight, which determines the way they share the interface bandwidth. The WRR is configurable. You can assign a different WRR weight for each queue. The higher the WRR weight, the higher the effective band width for that particular queue.
You can determine the effective bandwidth (in Mbps) for a particular queue using the following formula:
For example, if W is 4, S is 15, and B is 100 Mbps bandwidth, the equation is:
Thus the effective bandwidth for this queue is 26 Mbps.
The weight for any queue is from 0 - 15, however, the sum of the WRR weight for all four queues on an interface is 15. If the sum of the WRR weights exceed 15 you are likely to exceed the bandwidth.
You can create traffic shaping policies or traffic limiting policies on a device's interface to manage how much of the interface's bandwidth should be allocated to a specific traffic flow. You can set your policies based on a variety of traffic characteristics, including the type of traffic, its source, its destination, and its IP precedence settings (traffic coloring). Shaping differs from limiting in that shaping attempts to throttle traffic when it reaches the rate limits. The router buffers some of the traffic bursts. Only when the buffer fills are packets dropped. Whereas, limiting policies do not drop packets until rate limits are reached, then drop all packets that exceed the rate limit.
Unlike queuing techniques, which are part of an interface's characteristics, generic traffic shaping or traffic limiting is done through policies, which are defined in access control lists (ACLs). (Frame relay traffic shaping, FRTS, is defined in interface characteristics.) Queuing techniques only affect traffic when an interface is congested, or in the case of WRED, when traffic exceeds a certain threshold. With traffic shaping policies, flows are affected even during times of little congestion.
You can use these types of traffic shaping policies:
Generic traffic shaping lets you set a bandwidth limit for specific types of traffic. For example, you can create a policy that limits web traffic to 200 KB/sec. This puts a cap on the bandwidth available to that traffic, ensuring that the remainder of the interfaces bandwidth is available to other kinds of traffic. In this example, if web traffic does not fill 200 KB/sec, other kinds of traffic can use the unused bandwidth.
With generic traffic shaping, you can define a buffer to accommodate traffic bursts, so that packets are not immediately dropped once the limit is reached. If you do not define a buffer, once the limit is reached, packets are dropped.
You can define generic traffic shaping policies on any type of interface except those that use frame relay traffic shaping (FRTS).
For custom queuing interfaces, you can create a shaping policy to form an upper limit for the bandwidth available to the selected traffic, and have the interface also apply a custom queuing policy to form a lower bandwidth limit for the traffic. However, this is only available on selected combinations of IOS software versions and device models (see Table 1-2 to see which combinations support Committed Access Rate (CAR) limiting or CAR classification).
With IOS 11.1cc and IOS 12.0, coloring policies are implemented using Committed Access Rate (CAR). CAR allows the user to set policies for coloring and priority queuing, custom queuing, shaping or limiting, to be implemented on the same interface. (See "Defining a Coloring Action.") By using complex coloring policies, you can create a policy that colors a packet, then tells the IOS to examine other policies set on that interface. For example, the first policy would color the packet, then in a subsequent policy, you can key on the packet's color to apply a shaping, limiting, priority queuing or custom queuing policies.
For custom queuing interfaces, you can create a limiting policy to form an upper limit for the bandwidth available to the selected traffic, and have the interface also apply a custom queuing policy to form a lower bandwidth limit for the traffic.
CAR advanced settings allows you to set rate, burst size, exceeded burst size, direction, conformation priority, and exceeded priority. This allows you to set both coloring and limiting on both input and output interfaces.
You can define traffic coloring policies on any type of interface. WFQ and WRED automatically consider the packet's color when queuing the packet.
In IOS software versions 11.1cc and 12.0 committed access rate (CAR) allows the user to set polices that will apply the coloring policy on the inbound or outbound interfaces. IOS then examines other policies for queuing and bandwidth control. For custom queuing interfaces, you can create a shaping policy to form an upper limit for the bandwidth available to the selected traffic, and have the interface also apply a custom queuing policy to form a lower bandwidth limit for the traffic.
Frame relay traffic shaping lets you specify an average bandwidth size for frame relay virtual circuits (VC). You can also define the bandwidth allocated for bursty traffic, and control whether the circuit responds to notifications from the network that the circuit is becoming congested. By using FRTS, you can define a minimum rate commitment for the virtual circuit, and accommodate the occasional need for greater bandwidth.
Each virtual circuit (VC) is identified by a data link connection identifier (DLCI) and provides access to another endpoint of the frame relay (FR) cloud. The VC can be either a switched VC (SVC) or permanent VC (PVC). In the SVCs a connection establishment is made each time data needs to be sent over the network (like ATM) and negotiation of parameters occurs. For PVC, the connection is there all the time and its parameters are defined when it is ordered from the FR carrier.
If the FR is a fully meshed network, the FR cloud is viewed by the router like a shared media subnet, similar to an Ethernet interface in which few other routers connect to it. There may be a few VCs on the interface connecting to the FR network, but it will not be divided into logical subinterfaces.
It is very common that the FR interface is not fully meshed but is a collection of virtual point-to-point links. In this case subinterfaces will be defined on the interface connecting to the FR network and therefore only one VC is defined on each of the subinterfaces.
QoS Policy Manager applies your FRTS definitions to all VCs defined on an interface or subinterface. You cannot treat multiple VCs on a single interface or subinterface differently.
You can use FIFO, priority queuing, or custom queuing on frame relay subinterfaces. If you use priority queuing or custom queuing, you must create policies on the interfaces or subinterfaces that create the required queues. On a FR interface you can use WRED and weighted fair queuing (WFQ).
By creating custom or priority queues, you can further modify the automatic rate-limiting features of FRTS. Parameters you can control through QoS are Rate (CIR), burst size (BC), excess burst size (BE) and adaptive rate (response to BECN notifications).
You cannot create generic traffic shaping policies on an FRTS interface. You can create traffic coloring policies on the interface, however.
Note When applying FRTS to a subinterface, the system writes an enabling command to the parent interface.
Limiting lets you set a bandwidth limit for specific types of traffic. For example, you can create a policy that limits web traffic to 200 KB/sec. This puts a cap on the bandwidth available to that traffic, ensuring that the remainder of the interface's bandwidth is available to other kinds of traffic. In this example, if web traffic does not fill 200 KB/sec, other kinds of traffic can use the unused bandwidth.
Packets are dropped if traffic bursts exceed the limit.
You can define limiting policies on any type of interface.
For custom queuing interfaces, you can create a limiting policy to form an upper limit for the bandwidth available to the selected traffic, and have the interface also apply a custom queuing policy to form a lower bandwidth limit for the traffic. However, this is only available on selected combinations of IOS software versions and device models (see Table 1-2 to see which combinations support Committed Access Rate (CAR) limiting or CAR classification).
You can set a queuing technique on a device's interface to manage how packets are handled when an interface starts to be congested, in order to avoid the congestion. The queuing technique available for congestion avoidance is weighted random early detection (WRED).
With WRED, when traffic begins to exceed the interface's traffic thresholds, but before congestion occurs, the interface starts dropping packets from selected flows. If the dropped packets are TCP, the TCP source recognizes that packets are getting dropped, and lowers its transmission rate. The lowered transmission rate then reduces the traffic to the interface, thus avoiding congestion. Because TCP retransmits dropped packets, no actual data loss occurs.
To determine which packets to drop, WRED takes these things into account:
WRED chooses the packets to drop after considering these factors in combination, with the net result being that the highest priority and lowest bandwidth traffic is preserved.
WRED differs from standard random early detection (RED) in that RED ignores IP precedence, and instead drops packets from all traffic flows, not selecting low precedence or high bandwidth flows.
By selectively dropping packets before congestion occurs, WRED prevents an interface from getting flooded, necessitating a large number of dropped packets. This increases the overall bandwidth usage for the interface.
If you are using IOS software version 12.0 on a device with a versatile interface processor (VIP), when you configure an interface to use WRED it automatically uses distributed WRED. Distributed WRED takes advantage of the VIP.
The disadvantage of weighted random early detection is that only TCP/IP networks can benefit. Other protocols, such as UDP or Netware, do not respond to dropped packets by lowering their transmission rates, instead retransmitting the packets at the same rate. If you have a mixed network, WRED may not be the best choice for queuing traffic.
An effective use of weighted random early detection would be to avoid congestion on a predominantly TCP/IP network, one that has minimal UDP traffic and no significant traffic from other networking protocols. It is especially effective on core devices rather than edge devices, because the traffic coloring you perform on edge devices can then affect the WRED interfaces throughout the network.
Weighted random early detection interfaces automatically drop packets for high-bandwidth, low priority traffic flows. No specific policies are needed.
However, you can also create traffic shaping policies or traffic limiting policies to affect how select traffic is handled on the interface. A shaping policy or a limiting policy can control the bandwidth available to the selected traffic, whereas a coloring policy can change the relative importance of a packet and thus change how the interface queues the traffic.
Weighted random early detection is sensitive to the IP precedence settings in the packets, so you can create policies on inbound interfaces on the device and have those policies implemented on the outbound interfaces that use weighted random early detection. Weighted random early detection automatically prioritizes the packets without the need for you to create policies on the weighted random early detection queuing interfaces, dropping packets with low priority before dropping high-priority packets. However, you do not need to create policies on the inbound interfaces that color traffic (see the "Traffic Coloring Techniques" section earlier in this chapter). If packets have the same IP precedence, weighted random early detection drops packets from the highest-bandwidth flows first. If you create a coloring policy on the weighted random early detection interface, it also affects how the selected traffic is queued.
QoS Policy Manager's GUI makes it easier for you to create Quality of Service policies, so that you do not have to manually connect to each of your devices and use IOS software commands to configure the policies.
QoS Policy Manager detects the QoS capabilities that are available on each of your devices, as defined by the device model, interface type, and the IOS software version running on the device. With QoS Policy Manager, you cannot select an unsupported QoS capability for a given interface. You can chose different QoS techniques for different interfaces, as appropriate, to implement your overall networking policies.
Table 1-4 Cisco QoS Policy Manager Features, Uses, and Benefits
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
These topics cover the general way that interfaces apply policies to traffic, and the types of QoS capabilities you can implement with QoS Policy Manager:
QoS Policy Manager translates your policies into IOS software commands, and when you distribute your policies to the network, QoS Policy Manager creates the policies as ACLs on the devices. Through QoS Policy Manager, you can inspect the IOS software commands that will be used to configure the devices.
During policy distribution, you can view IOS software configuration messages as QoS Policy Manager configures each device, so that you can identify configuration successes and failures.
Figure 1-3 shows the relationship of QoS Policy Manager to the devices in the network. If you are using a remote version of QoS Policy Manager (B), it updates the network through the complete version (A). The QoS Manager service does the actual work of taking your policies, contacting the devices, and updating the device configurations.
QoS Policy Manager does limited checking to ensure that your policies are consistent and can be implemented:
QoS Policy Manager does not check to ensure your policies are logical. For example, if you have multiple policies on an interface, and the policies use the same filter conditions (thus selecting identical traffic), the second policy will never be applied (unless the first policy specifies that the interface should consider subsequent policies, which is a feature only available on certain IOS software version and device model combinations).
Thus, QoS Policy Manager ensures that your policies can be implemented, but does not ensure that your policies will have the effect you desire. The policies can not be implemented unless they meet a basic consistency.
If you have already defined access control lists (ACLs) on your devices, QoS Policy Manager does not translate them into the QoS Policy Manager database. If you want to manage those policies through QoS Policy Manager, you must recreate them in QoS Policy Manager.
If you leave the existing ACLs on the device, QoS Policy Manager does not change them or delete them. They remain defined on the device until you change or remove them using IOS software commands.
These topics help you decide how and where to deploy QoS in your network:
Some applications can benefit more from QoS techniques than other applications. The benefits you might get from QoS are dependent not only on the applications you use, but on the networking hardware and bandwidth available to you.
In general, QoS can help you solve two problems: constricted bandwidth and time sensitivity.
If you have insufficient bandwidth, either due to the lines you are leasing or the devices you have installed, QoS can help you allocate guaranteed bandwidth to your critical applications. Alternatively, you can limit the bandwidth for non-critical applications (such as FTP file transfers), so that your other applications have a greater amount of bandwidth available to them.
Some applications, such as video, require a certain amount of bandwidth for them to work in a usable manner. With QoS policies, you can guarantee the bandwidth required for these applications.
For time-sensitive applications, which are sensitive to timeouts or other delays, you can help the applications by coloring their traffic with higher priorities than your regular traffic. You can also define minimum bandwidth to help ensure the applications can deliver data in a timely fashion.
As you deploy QoS, identify the applications used on your network that are bandwidth or time sensitive, and also identify the applications that take more than their fair share of bandwidth. With this information, you can develop effective policies to improve the overall functioning of your network.
Any interface that is congested can benefit from QoS policies. LAN-WAN links are typical points of congestion, as data is moved between lines that have differing carrying capacity. These links might be the best place to start deploying QoS policies. However, the congestion points for your network might be anywhere. You evaluate interface points where packets most likely get dropped during peak traffic periods.
Deploy QoS everywhere you have bandwidth contention. Traffic analysis of different times of the day is helpful in identifying potential bandwidth contention. Note the high traffic periods for peak and length. Also, identify critical data routing where packets may not be dropped.
For more information about Quality of Service, see these papers on the web:
Note For pages that require a Cisco Connection Online (CCO) login, you can register at the CCO web site at http://www.cisco.com/register/.
Posted: Mon Aug 18 10:18:56 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.