|
|
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 the network and which QoS techniques might improve the performance of those applications. Then, use the Cisco QoS Policy Manager (QPM) to create and deploy your QoS policies to the network.
These topics introduce you to QoS concepts and QoS Policy Manager, and get you started on developing a QoS strategy.
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 devices or 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 values in the packets.
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 one or more queues from which the device selects the next packet to send. By setting the queuing property (called the QoS Property in QPM) on a device or interface, you can control how the queues are serviced, thus determining the priority of the traffic.
Figure 1-1 shows an example of a local and wide area network. Typically, you classify traffic in the LAN before sending it to the WAN. The devices on the WAN then use the classification to determine the service requirements for the traffic. The WAN devices can limit the bandwidth available to the traffic, or give the traffic priority, or even change the classification of the traffic. If you control the WAN as well as the LAN, you can control all aspects of the traffic's priority. However, once the traffic leaves the networks under your control, it is your service provider who decides how to service the traffic (which might be based on an explicit agreement with your enterprise).
QoS Policy Manager (QPM) is a configuration interface for Cisco devices, including routers, layer-3 switches (switch routers), switches, and LocalDirector. Using QPM, you can define and deploy policies more easily than you can by using device commands directly.
These topics go into detail about the capabilities of QPM:
QoS Policy Manager (QPM) lets you define QoS policies at a more abstract level than can be defined using device commands. For example, with QPM you can define policies for groups of devices rather than one device at a time. You can also create policies that apply to applications or groups of hosts more easily than can be defined using device commands.
By giving you a higher level view of your policies, QPM makes it easier for you to define, modify, and redeploy policies. You can more easily analyze "what if" scenarios in a lab and then deploy your best solution to your live network.
By simplifying QoS policy definition and deployment, QPM can make it easier for you to create and manage differentiated services in your network, thus making more efficient and economical use of your existing network resources. For example, you can deploy policies that ensure that your mission-critical applications always get the bandwidth required to run your business.
When you install the QPM remote version, only Policy Manager and Distribution Manager are installed. The remote version must communicate with a QoS Manager service on another machine in order for you to distribute policies. You must also install the QPM complete version on a machine in order to install QoS Manager (Policy Manager and Distribution Manager are also installed with QoS Manager in the complete version).
Table 1-1 describes the features available in QPM.
|
These tables describe the devices and software releases that QoS Policy Manager supports, and the QoS techniques you can use on the supported platforms:
Note QPM supports approximately 200 devices in a QoS database. If you want to manage more than 200 devices, create multiple databases using Policy Manager (for example, by managing core devices in one database and edge devices in another database).
Table 1-2, Part 1 Supported Devices and QoS Techniques for
IOS Software Release 11.x Devices
Table 1-2, Part 2 Supported Devices and QoS Techniques for
IOS Software Release 12.x Devices
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
1 For IOS software release 12, QPM uses CAR classification instead of PBR commands to implement coloring policies on these devices. 2 For this IOS software release, QPM uses CAR classification commands to implement coloring policies for this device. |
Table 1-2, Part 3 Supported Devices and QoS Techniques for
Catalyst Operating System Devices
|
|||||||||||||||||||||
Table 1-2, Part 4 Supported Devices and QoS Techniques for
Other Devices
|
QoS Policy Manager translates your policies into device commands and enters the commands through the device's command line interface. Some policies require the creation of access control lists (ACLs), others do not. Through QPM, you can inspect the commands that will be used to configure the devices.
During policy distribution, you can view device log messages as QPM configures each device, so that you can identify configuration successes and failures.
Figure 1-2 shows the relationship of QPM to the devices in the network. If you are using a remote version of QPM (B), it updates the network through the QoS Manager service in the complete version (A). QoS Manager does the actual work of translating your policies, contacting the devices, and updating the device configurations.
QoS Policy Manager does basic checking to ensure that your policies are consistent and can be implemented:
QPM does not check to ensure that your policies are consistent with each other. For example, if you have two 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 in committed access rate (CAR) policies).
Thus, QPM ensures that your policies can be implemented, but does not ensure that your policies will have the effect you desire.
If you have already defined access control lists (ACLs) on your devices, QoS Policy Manager does not translate them into the QoS database. If you want to manage those policies through QPM, you must recreate them in QPM.
If you leave the existing ACLs on the device, QPM does not change them or delete them. They remain defined on the device until you change or remove them using the device's commands. For example, QPM does not modify ACLs created by Cisco ACL Manager.
QoS Policy Manager's interface 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 device commands to configure the policies.
QPM detects the QoS capabilities that are available on each of your devices, as defined by the device model, interface type, and the software version running on the device. With QPM, you cannot select an unsupported QoS capability for a given device or interface. You can chose different QoS techniques for different interfaces, as appropriate, to implement your overall networking policies.
These topics cover the general way that devices and interfaces apply policies to traffic, and the types of QoS capabilities you can implement with QPM:
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-3 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 or device QoS properties recognize a packet's relative importance by examining the IP precedence field in the packet's header. Changing the IP precedence value is changing the packets color or classification. Because the IP precedence is imbedded in the packet, changing it can affect the way the packet is handled on its entire path through the network.
You can color traffic on several types of devices:
Because IOS software applies 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. Interfaces that use WFQ, WRED, and some other queuing techniques automatically recognize and use the IP precedence value. Priority queuing and custom queuing interfaces do not automatically consider the IP precedence of a packet. Therefore, to have coloring affect how the packet gets prioritized on a priority queuing or custom queuing 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). Likewise, if you want to shape or limit traffic based on IP precedence, you must create traffic shaping or limiting policies on the outbound interface that specifically look for the selected precedence value.
If the interface supports CAR, you can use advanced coloring features. Your coloring policy can apply different precedence values based on whether the traffic flow is conforming to or exceeding a specific rate. You can also specify that additional policies be examined on the interface (usually, if a packet matches a policy, the policy is applied and no other policies on the interface are examined). Thus, in one policy you can color the traffic, and in the next policy, you can use the packet's color to limit the traffic to a specific rate, or place it in a custom or priority queue. CAR also allows you to color traffic whether it is entering or leaving the interface (or both), whereas PBR only lets you color traffic that is entering the interface. QPM only presents you with these advanced features if the interface supports them.
Ports that use 2Q2T queuing or other precedence-sensitive queuing techniques use the packet classification to alter how they queue packets.
You can also color the packets while limiting the traffic rate by creating a limiting (traffic policing) policy instead of a coloring policy.
You can define traffic coloring policies on any type of interface.
WFQ, WRED, WRR, and 2Q2T automatically consider the packet's color when queuing the packet. To have the packet's color affect queuing on interfaces using other queuing properties, you must define policies on the interface that specifically look at the precedence value (for example, custom or priority queuing policies, or shaping or limiting policies).
You can create traffic shaping or limiting (traffic policing) 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 smooth the traffic flow to meet your rate requirements, whereas limiting (traffic policing) does not smooth the traffic flow, it only prevents the flow from exceeding the rate.
Unlike queuing techniques, which are part of an interface's characteristics, generic traffic shaping or traffic limiting is done through policies that are defined in access control lists (ACLs). (However, Frame Relay traffic shaping, FRTS, is defined as interface characteristics.) Queuing techniques affect traffic only 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 target average transmission rate for specific types of traffic. For example, you can create a policy that limits web traffic to 200 kilobits/second. GTS shapes the traffic flow so that the rate does not exceed this value. 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 kilobits/second, other kinds of traffic can use the unused bandwidth.
GTS uses a buffer to hold packets while it transmits the flow at the target rate. You can also define a burst size and an exceed burst size to further model the flow. These values define how much data GTS can send from the buffer per time interval. Once the buffer is full, packets are dropped.
GTS is useful for satisfying service level agreements, or for slowing traffic on a link where the destination interface is slower than the transmission interface (where you would define the shaping policies).
You can define generic traffic shaping policies on any type of interface except those that use Frame Relay traffic shaping (FRTS). On Frame Relay interfaces, you cannot use GTS and FRTS simultaneously, nor can you mix GTS and FRTS on subinterfaces of a single interface.
Frame Relay traffic shaping lets you specify an average bandwidth size for Frame Relay virtual circuits (VC), defining an average rate commitment for the VC. FRTS is useful for satisfying service level agreements, or for slowing traffic on a link where the destination interface is slower than the transmission interface (where you would define the FRTS rate).
Unlike GTS, you enable FRTS in the interface's properties. You do not create FRTS policies on the interface. Thus, your FRTS settings apply to all traffic on the interface. You cannot selectively apply different rates to different types of traffic.
FRTS uses a buffer to hold packets while it transmits the flow at the target rate. You can also define a burst size and an exceed burst size to further model the flow. These values define how much data FRTS can send from the buffer per time interval. Once the buffer is full, packets are dropped.
You can also control whether the circuit responds to notifications from the network that the circuit is becoming congested (adaptive shaping).
QPM applies your FRTS settings to all VCs defined on an interface or subinterface. You cannot treat multiple VCs on a single interface or subinterface differently. However, you can have different rate settings for an interface and its subinterfaces. To use FRTS on a subinterface, you must first enable it on the associated interface.
If you are using Voice over Frame Relay, you can also define the percentage of the interface's bandwidth to use for voice.
Because Frame Relay is a WAN protocol, part of the Frame Relay network you use is provided by a carrier. Typically, you will need to negotiate rates and other FRTS settings with the carrier to ensure you get the WAN network performance you require.
Device groups allow you to treat selected interfaces or subinterfaces as a single unit, so that you can easily apply common policies or QoS settings to the group. FRTS has a special influence on how you can group frame relay interfaces.
FRTS is enabled or disabled for an interface and all of its subinterfaces. You cannot have FRTS enabled on one subinterface and not on another for the same interface. Thus, if you change whether FRTS is enabled, the change is also made to any associated interface or subinterface.
If a subinterface is a member of a device group, you cannot change whether FRTS is enabled on the associated interface. When you create a group for Frame Relay subinterfaces, you must specify whether the interfaces for the subinterfaces have FRTS enabled. This limits the subinterfaces you are allowed to add to the group.
You can use FRTS on Frame Relay interfaces using any type of QoS property (except "Do not change").
If you use priority queuing or custom queuing, you must create policies on the interfaces or subinterfaces that create the required queues. By creating custom or priority queues, you can further modify the rate-limiting features of FRTS.
On some versions of IOS software, when you select WFQ for QoS Property there are additional configuration settings available. These settings are used for Voice over Frame Relay. See the "New Interface and Properties of Interface Dialog Boxes" section for a description of these settings.
You cannot create generic traffic shaping policies on an FRTS interface. You can create traffic coloring policies on the interface, however.
Committed access rate (CAR) limiting (or policing) lets you set a bandwidth limit for specific types of traffic on router interfaces. For example, you can create a policy that limits web traffic to 200 kilobits/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 kilobits/sec, other kinds of traffic can use the unused bandwidth.
Packets are dropped if traffic bursts exceed the limit. CAR limiting does not attempt to smooth or shape the traffic flow in the way that GTS or FRTS attempt to do. Because CAR does not buffer the traffic, there is no delay in sending it, unless the traffic flow exceeds your rate policy and it is dropped.
In addition to limiting the traffic rate, CAR lets you color the traffic that conforms to the rate. CAR limiting is a related to CAR classification (described in the "Traffic Coloring Techniques" section). The difference between CAR classification and CAR limiting is that CAR classification allows traffic that exceeds the rate limit to be transmitted and optionally colored.
One of the main uses for limiting policies is to ensure that traffic coming into your network is not exceeding agreed-upon rates. If you define the limiting policy for inbound traffic, you can throttle misbehaving traffic before it gets into your network. Because you control the traffic's rate at the inbound interface, the traffic should be well-behaved while it is in your network.
You can define limiting policies on any type of interface.
For custom queuing or CBWFQ 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. To do this, you must specify Continue on the limiting policy, and ensure that the policy comes before the associated custom queuing or CBWFQ policy in the list of policies on the interface.
You can also use the Continue attribute to apply more than one rate limiting policy. For example, you can have a general policy that applies a rate limit to all TCP traffic, and a subsequent policy that applies a different rate limit to web traffic.
Traffic policing lets you set a bandwidth limit for specific types of traffic on Catalyst switch ports. For example, you can create a policy that limits web traffic to an average rate of 1024 kilobits/second, with a maximum burst of 2048 kilobits. 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 1024 kilobits/second with maximum bursts to 2048 kilobits, other kinds of traffic can use the unused bandwidth.
Packets are dropped if traffic bursts exceed the limits.
By setting the rate to 0, you can effectively prevent the selected traffic from being transmitted through the port.
In addition to limiting the traffic rate, traffic policing changes the color of traffic that does not conform to the rate.
You can define limiting policies on any type of port.
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 or traffic limiting policies on FIFO interfaces to limit the bandwidth available to selected traffic.
You can also color the traffic on a FIFO interface, but the packet's color does not affect the queuing on the interface. However, if the interface supports committed access rate (CAR) classification and limiting, you can create a coloring policy that simultaneously creates a rate limit and colors the traffic.
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 to alter the packet's queuing.
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 priority queuing policies you define on the interface. 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 limiting policies to define an upper range on the bandwidth allocated to selected traffic. If you use limiting policies, you can specify that the interface consider other policies if the limiting policy matches the traffic. In this way, you can both limit the rate for the traffic and place it in a specific priority queue. If you do not specify continue on the limiting policy, traffic that satisfies the limiting policy is placed in the normal priority queue.
If you use traffic shaping policies to specify a rate limit, the traffic to which the shaping policy applies is placed in the normal priority queue.
Priority queuing interfaces do not automatically consider the IP precedence settings of a packet. If you create traffic coloring policies on inbound interfaces (see the "Traffic Coloring Techniques" section), 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.
If the interface supports committed access rate (CAR) classification, you can create a coloring policy and specify that the interface consider other policies if the coloring policy matches the traffic. In this way, you can color the traffic and place it in a specific priority queue based on the color value.
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% (QPM 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.
QPM 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.
If you do not create custom queuing policies on the custom queuing interface, all traffic is placed in a single queue (the default queue), and is processed first-in, first-out, in the same manner as a FIFO queuing interface.
You can also create 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 limiting policy defines an upper limit. When defining the bandwidth upper limit, the limiting policy must appear before the custom queue policy, and it must filter the same traffic as the custom queue (or a subset of the same traffic), and it must specify that the interface continue looking at subsequent policies after applying the limiting policy. If you do not specify continue, traffic that satisfies the limiting policy is placed in the default custom queue.
If you use traffic shaping policies to specify a rate limit, the traffic to which the shaping policy applies is placed in the default custom queue.
Custom queuing interfaces do not automatically consider the IP precedence settings of a packet. If you create traffic coloring policies on inbound interfaces (see the "Traffic Coloring Techniques" section), 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.
If the interface supports committed access rate (CAR) classification, you can create a coloring policy and specify that the interface consider other policies if the coloring policy matches the traffic. In this way, you can color the traffic and place it in a specific custom queue based on the color value.
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.
On some versions of IOS software, when you select WFQ on Frame Relay interfaces where you enable FRTS, there are WFQ configuration settings available. These settings are used for Voice over Frame Relay. See the "New Interface and Properties of Interface Dialog Boxes" section for a description of these settings.
For interfaces on VIP cards, you can use fair queuing, but not weighted fair queuing. In fair queuing, the queues are treated with the same weight. This is also called distributed weighted fair queuing (DWFQ).
Weighted fair queuing interfaces automatically create queues for each traffic flow. No specific policies are needed.
However, you can also create traffic shaping or limiting policies to affect how selected traffic is handled on the interface. A shaping policy or a limiting policy controls the bandwidth available to the selected traffic.
Weighted fair queuing is sensitive to the IP precedence settings in the packets. WFQ automatically prioritizes the packets without the need for you to create policies on the WFQ interfaces. However, if you do create a coloring policy on the WFQ interface, it affects how the selected traffic is queued.
WFQ can improve network performance without traffic coloring policies. However, because WFQ automatically uses the IP precedence settings in packets, consider coloring all traffic that enters the device (or color the traffic at the point where it enters your network). By coloring all traffic, you can ensure that packets receive the service level you intend. Otherwise, the originator of the traffic, or another network device along the traffic's path, determines the service level for the traffic.
Class-based weighted fair queuing (CBWFQ) combines the best characteristics of weighted fair queuing and custom queuing.
CBWFQ uses WFQ processing to give higher weight to high priority traffic, but derives that weight from classes that you create on the interface. These classes are similar to custom queues—they are policy-based, identify traffic based on the traffic's characteristics (protocol, source, destination, and so forth), and allocate a percentage of the interface's bandwidth to the traffic flow.
Because you create the classes, CBWFQ is not limited to using IP precedence for queuing as is WFQ. You can create up to 64 classes on an interface.
CBWFQ also lets you control the drop mechanism used when congestion occurs on the interface. You can use WRED for the drop mechanism, and configure the WRED queues, to ensure that high-priority packets within a class are given the appropriate weight. If you use tail drop, all packets within a class are treated equally, even if the IP precedence is not equal.
The disadvantage of CBWFQ is that, like custom queuing, you must create policy statements on the interface to place the traffic in the classes.
An effective use of CBWFQ would be to guarantee bandwidth to a few critical applications to ensure reliable application performance.
If CBWFQ is available on an interface, Cisco recommends that you use CBWFQ instead of custom queuing.
In order for packets to be placed in a CBWFQ class on an interface, you must create CBWFQ policies on that interface. These policies need to specify a minimum percentage of the bandwidth on the interface that should be allocated to the class queue for the filtered traffic.
Unless you change the maximum allocatable bandwidth on the interface, for interfaces on a non-VIP card, a queue can be as small as 1%, or as large as 75%, in increments of 1%. The total bandwidth allocation for all policy statements defined on a CBWFQ interface cannot exceed 75%. For interfaces on a VIP card, the upper limit is 99%. The maximum bandwidth limit includes the IP RTP Priority queue if you create one. Because you can change the maximum allocatable bandwidth, QPM does not check to ensure that you do not exceed the bandwidth limits.
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.
If you do not create CBWFQ policies on the CBWFQ interface, all traffic is placed in a single queue (the class default queue), and is processed according to the settings in the default class. However, the default class is not created for interfaces on a VIP card—CBWFQ default processing is configured as part of the interface properties for VIP interfaces.
You can also create traffic limiting policies to define an upper range on the bandwidth allocated to selected traffic. Thus, the class queue defines a minimum bandwidth, and the limiting policy defines an upper limit. When defining the bandwidth upper limit, the limiting policy must appear before the CBWFQ policy, and it must filter the same traffic as the class queue (or a subset of the same traffic), and it must specify that the interface continue looking at subsequent policies after applying the limiting policy. If you do not specify continue on the limiting policy, traffic that satisfies the limiting policy is placed in the default class queue.
If you use traffic shaping policies to specify a rate limit, the traffic to which the shaping policy applies is placed in the default class queue.
You can use NBAR to refine your CBWFQ policies if the interface supports NBAR. With NBAR, you can identify traffic based on application. For example, you can filter all RealAudio traffic.
When using NBAR, ensure that the policy filter is general enough to include the application traffic you are identifying. Make the filter general, to ensure that it includes the traffic. For example, if you want to the policy to only apply to RealAudio traffic, the policy's filter properties should only identify TCP protocol traffic, and the application properties should specify RealAudio.
The application properties only appear if you select CBWFQ for policy action.
CBWFQ interfaces do not automatically consider the IP precedence settings of a packet. If you create traffic coloring policies on inbound interfaces (see the "Traffic Coloring Techniques" section), and you want the coloring to affect the class queue, you must create a policy on the CBWFQ outbound interface that recognizes the color value and places the packet in the desired queue.
If the interface supports committed access rate (CAR) classification, you can create a coloring policy and specify that the interface consider other policies if the coloring policy matches the traffic. In this way, you can color the traffic and place it in a specific class queue based on the color value.
If you use WRED for a class's drop mechanism, WRED automatically considers the packet's color when determining which packet to drop. Tail drop does not consider a packet's color.
If you use WFQ on the default class policy, WFQ automatically considers the packet's color when queuing, dropping, and sending packets in the default queues.
IP RTP Priority creates a strict-priority queue for real-time transport protocol (RTP) traffic. This is typically used to provide absolute priority to voice traffic, which uses RTP ports. Because voice traffic is delay-sensitive and low bandwidth, you can typically give it absolute priority without starving other data traffic. This ensures that voice quality is adequate.
The IP RTP Priority queue is emptied before other queues are serviced. Because voice packets are small, you should configure the Link Fragmentation and Interleaving (LFI) feature on slow interfaces. This breaks apart large data packets, ensuring that small voice packets can be sent quickly without waiting for a complete large data packet to be sent.
In QPM, you enable IP RTP Priority in the interface or device group properties. You select the range of RTP port traffic to place in the queue, and the percentage of the interface's bandwidth to allocate to the queue. Any allocated bandwidth that is not used is available to other queues on the interface.
Do not set the bandwidth too low. Any traffic for the queue that exceeds the bandwidth is dropped. Although voice traffic typically uses 24 kbps, there is occasionally overhead requiring 25 kbps service. If you select a bandwidth percentage that equates to 24 kbps, the interface is likely to drop voice packets occasionally, which will give you poor voice quality.
Also, IP RTP Priority ignores compression, treating a compressed 12 kbps flow as a 24 kbps flow.
There are no policies for IP RTP Priority. The IP RTP Priority configuration on the interface or device group determines which traffic is placed in the priority queue.
You can use IP RTP Priority only on WFQ or CBWFQ interfaces. On CBWFQ interfaces, you can configure custom class-based queues for other types of traffic. The bandwidth allocated to the IP RTP Priority queue counts as part of the total allocated CBWFQ queue bandwidth.
Weighted round-robin (WRR) scheduling is used on Catalyst 8500 family switch routers (layer 3 switches) on egress ports to manage the queuing and sending of packets. WRR places a packet in one of four queues based on IP precedence, from which it derives a delay priority. Table 1-3 shows the queue assignments based on the IP precedence value and derived delay priority of the packet, and the weight of the queue if you do not change it.
Table 1-3 WRR Queue Packet Assignments
|
| 1 Queue 2 is the queue typically used for voice traffic. |
The switch routers automatically use WRR on egress ports. Unlike other queuing properties, you do not configure WRR through the device's interface properties (QPM does not list switch router interfaces). Instead, you configure WRR through policies defined on the device level.
With WRR, each queue is given a weight. This weight is used when congestion occurs on the port to give weighted priority to high-priority traffic without starving low priority traffic. The weights provide the queues with an implied bandwidth for the traffic on the queue. The higher the weight, the greater the implied bandwidth. The queues are not assigned specific bandwidth, however, and when the port is not congested, all queues are treated equally. See Table B-15, Part 7 for the equation used to calculate implied bandwidth.
Devices that use WRR automatically create the four queues with default weights for each interface. You need only define policies on the device if you want to change the queue weights for an interface. These policies are defined at the device level. QPM does not display the interfaces for layer 3 switches.
WRR is sensitive to the IP precedence settings in the packets. WRR automatically places the packets in queues based on precedence. Although you cannot change the color of a packet on a layer 3 switch, if you change the packet's color on another device before it reaches the layer 3 switch, that change affects the WRR queuing.
2Q2T queuing on Catalyst 6000 family switches uses a packet's precedence setting to determine how that packet is serviced on the port.
2Q2T queuing uses two queues, one high priority, the other low priority, with two thresholds for each queue, to determine the bandwidth allowed for traffic based on each IP precedence value. 2Q2T assigns each precedence to a specific queue and threshold on that queue.
For example, packets with 0 for precedence (the lowest priority) are placed in the low priority queue and use the lower threshold by default. This ensures that the least important traffic gets less service than any other traffic.
These queues and thresholds are serviced using weighted round robin (WRR) techniques to ensure a fair chance of transmission to each class of traffic. 2Q2T favors high-priority traffic without starving low-priority traffic.
2Q2T queuing comes with a default configuration for the queues, thresholds, and traffic assignments based on IP precedence settings. You only need to change this configuration if it does not suit your requirements. The default configuration is described in the "Properties of 2 Queues 2 Thresholds QoS Property Dialog Box" section.
If you decide to change the 2Q2T configuration, you can change the size of the queues, their relative WRR weights, the sizes of their thresholds, and the assignment of precedence values to the appropriate queue and threshold.
2Q2T queuing ports are not configured with policies. Change the 2Q2T configuration through the switch's device properties. See the "Viewing or Changing Device Properties" section for information on changing device properties.
However, you can create traffic limiting policies (called traffic policing on switches) to affect how selected traffic is handled on the interface. A limiting policy controls the bandwidth available to the selected traffic.
2Q2T queuing is sensitive to the IP precedence settings in the packets. The queues and thresholds selected for the traffic are based on the precedence value.
If you use coloring policies on the interface to change a packet's precedence, that change affects the queue and threshold assignment for the packet.
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 predominantly TCP/IP networks can benefit. Other protocols, such as UDP or NetWare (IPX), do not respond to dropped packets by lowering their transmission rates, instead retransmitting the packets at the same rate. WRED treats all non-TCP/IP packets as having precedence 0. If you have a mixed network, WRED might 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 favor high priority, low bandwidth 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.
You can also create CBWFQ policies that use WRED as the drop mechanism for the class-based queues.
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. WRED automatically prioritizes the packets without the need for you to create policies on the WRED 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. If packets have the same IP precedence, WRED drops packets from the highest-bandwidth flows first. However, because WRED automatically uses the IP precedence settings in packets, consider coloring all traffic that enters the device (or color the traffic at the point where it enters your network). By coloring all traffic, you can ensure that packets receive the service level you intend. Otherwise, the originator of the traffic, or another network device along the traffic's path, determines the service level for the traffic.
If you create a coloring policy on the WRED interface, it also affects how the selected traffic is queued.
In order to implement end-to-end quality of service, a traffic flow must contain or use some type of signal to identify the requirements of the traffic. With QPM, you can control these types of signalling techniques:
The simplest form of signal is the IP precedence setting in data packets: the packet's color or classification.
This signal is carried with the packet, and can affect the packet's handling at each node in the network. Queuing techniques such as WFQ and WRED automatically use this signal to provide differentiated services to high-priority traffic.
To use the IP precedence setting effectively, ensure that you color traffic at the edges of your network so that the color affects the packet's handling throughout the network. See the "Traffic Coloring Techniques" section for information on how to change a packet's IP precedence setting.
IP precedence can only provide differentiated services on interfaces that use a queuing technique that is sensitive to the precedence setting in the packet. For example, WFQ, WRED, WRR, and 2Q2T automatically consider the precedence settings.
Other QoS properties can use the precedence settings, but you must create policies that specifically filter on the precedence. For example, custom queuing, priority queuing, and CBWFQ interfaces can use the precedence setting if you create the appropriate policies.
A more sophisticated form of signalling than IP precedence is the resource reservation protocol (RSVP). RSVP is used by applications to dynamically request specific bandwidth resources from each device along the traffic flow's route to its destinations. Once the reservations are made, the application can start the traffic flow with the assurance that the required resources are available.
RSVP is mainly used by applications that produce real-time traffic, such as voice, video, and audio. Unlike standard data traffic such as HTTP, FTP, or Telnet, real-time applications are delay sensitive, and can become unusable if too many packets are dropped from a traffic flow. RSVP helps the application ensure there is sufficient bandwidth so that jitter, delay, and packet drop can be avoided.
RSVP is typically used by multicast applications. With multicasting, an application sends a stream of traffic to several destinations. For example, the Cisco IP/TV application can provide several audio-video programs to users. If a user accesses one of the provided programs, IP/TV sends a stream of video and audio to the user's computer.
Network devices consolidate multicast traffic to reduce bandwidth usage. Thus, if there are 10 users for a traffic flow behind a router, the router sees one traffic flow, not 10. In unicast traffic, the router sees 10 traffic flows. Although RSVP can work with unicast traffic (one sender, one destination), RSVP unicast flows can quickly use up RSVP resources on the network devices if a lot of users access unicast applications. In other words, unicast traffic scales poorly.
To configure RSVP on network devices, you must determine the bandwidth requirements of the RSVP-enabled applications on your network. If you do not configure the devices to allow RSVP to reserve enough bandwidth, the applications will perform poorly. See the documentation for the applications to determine their bandwidth requirements.
In QPM, you enable RSVP in the interface's properties (where you also set the QoS property). You can determine the maximum percentage of the interface's bandwidth that can be reserved (default is 75%), and the maximum percentage of the bandwidth that any one flow can use. You can also configure RSVP on device groups.
When an RSVP request is made, RSVP calculates the bandwidth request by considering the mean data rate, the amount of data the interface can hold in the queue, and the minimum QoS requirement for the traffic flow. The interface determines if it can meet the request, and replies to the requesting application.
When the traffic flow begins, RSVP can dynamically respond to changes in routes, switching reservations to new devices and releasing reservations for devices no longer on the path. Once the flow is complete, all reservations are removed and the bandwidth on the interfaces released.
You can use RSVP on only WFQ, WRED, and CBWFQ interfaces:
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 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, or by placing the traffic in a priority queue. 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 should not be dropped.
This publication cannot cover everything you might want to know about quality of service. This section provides pointers to more information available 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/.
The references are broken down into these categories:
http://www.cisco.com/kobayashi/sw-center/netmgmt/nr/qos.html
http://www.cisco.com/warp/public/793/voip/
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_r/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/wan_c/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/wan_r/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t4/120tvofr/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/cbwfq.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/iprtp.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/fun_c/fcprt4/fcperfrm.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/fun_r/frprt4/frperfrm.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/wan_c/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/wan_r/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/112cg_cr/1cbook/1csysmgt.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/112cg_cr/1rbook/1rsysmgt.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/112cg_cr/4cbook/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/112cg_cr/4rbook/index.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/mods/1mod/1cbook/1csysmgt.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/mods/1mod/1rbook/1rsysmgt.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/car.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/wred.htm
http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/dwfq.htm
http://www.cisco.com/warp/customer/779/largeent/learn/technologies/qos/index.html
http://www.cisco.com/warp/customer/732/qos/index.html
http://www.cisco.com/warp/customer/732/net_enabled/qos.html
http://www.cisco.com/warp/customer/779/largeent/design/index.html
http://www.cisco.com/warp/customer/cc/sol/mkt/ent/multi/dvvi4/qosfs_ds.htm
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm
http://www.cisco.com/warp/customer/cc/sol/mkt/ent/cmps/gcnd_wp.htm
http://www.cisco.com/univercd/cc/td/doc/product/l3sw/8500/ios_12_0/8500conf/5cfg8500.htm
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_1/config/qos.htm
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_1/cmd_ref/cr_toc.htm
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_3/cofigide/qos.htm
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_3/comdref/cr_toc.htm
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/localdir/ld31rns/ldicgd/index.htm
Posted: Mon Aug 18 10:09:43 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
