Table of Contents

Planning for Quality of Service

Effective use of Quality of Service (QoS) capabilities requires careful planning. Before you deploy QoS to your network, you should 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 CiscoWorks2000 QoS Policy Manager, and help you get started on developing a QoS strategy:

• What Is Quality of Service?
  
  
• What Is CiscoWorks2000 QoS Policy Manager?
  
  
• Planning for QoS Deployment
  
  
• What Types of Quality of Service Does QPM Handle?
  
  
• More Information About Quality of Service
  
  

What Is Quality of Service?

Quality of Service (QoS) is a set of capabilities that allow you to deliver differentiated services for network traffic, thereby providing better service for selected network traffic. 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 policies for network devices. The policies can differentiate traffic based on categories, such as user address, application type, content, and so on. Once you have identified the applications and users on your network that are bandwidth or time sensitive, as well as the applications that take more than their fair share of bandwidth, you can develop effective QoS policies to improve the overall functioning of your network.

Following are some examples of the benefits of configuring QoS on your network:

• 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 users and applications. Alternatively, you can limit the bandwidth for non-critical applications (such as FTP file transfers), so that other applications or users have a greater amount of bandwidth available to them. For example, video applications 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 classifying 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.
  
  
• SLA Management allows you to define strict minimum and maximum bandwidth limits to user groups and application groups based on pre-defined service level contracts between a user or customer, and a service provider.
  
  
• On outbound device interfaces, packets can be queued according to their IP precedence. Using QoS, 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 in 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, after 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).

What Is CiscoWorks2000 QoS Policy Manager?

CiscoWorks2000 QoS Policy Manager (QPM) provides a scalable platform for defining and applying QoS policy. QPM manages QoS configuration and maintenance on a system-wide basis 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 provide details about the capabilities of QPM:

• Overview of QoS Policy Manager
  
  
• What Devices and Software Releases Are Supported?
  
  
• How Does QoS Policy Manager Deploy QoS Policies?
  
  
• Does QoS Policy Manager Ensure That Policies Are Consistent with Network Configuration?
  
  
• How Does QoS Policy Manager Support Existing QoS Configurations?
  
  

Overview of QoS Policy Manager

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 high 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 makes 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.

QPM is suitable for large-scale enterprise deployments consisting of hundreds or thousands of devices, such as IP Telephony deployments. QPM facilitates management of large networks by allowing you to create multiple QoS databases, each of which manages a subset of the network devices. In this way, you can effectively partition the network (typically by region and/or types of devices) and implement phased deployment of QoS policies across the network. The number of devices managed in a single database will vary according to your needs and preferences. Each QoS database can be managed separately, and can thus be assigned to specific individuals according to areas of administrative responsibility.

QPM includes the following programs:

• Policy Manager—Policy Manager lets you create QoS databases in which you define QoS policies for devices or interfaces, and set the queuing mechanism (QoS property) for interfaces. You can define groups of devices or interfaces and create policies for those groups, rather than for individual devices. You can also define VLAN-based policies for Catalyst switches. You can create groups of hosts, or definitions of application traffic, and use them in your policies to simplify policy definition. Policy Manager includes web-based reporting to help you maintain records of policy definitions.
  
  
• Distribution Manager—Distribution Manager lets you deploy policies and QoS configurations created in Policy Manager to the devices. It also enables you to preview the CLI commands that will be created on the devices, before you actually deploy your policies and QoS configurations. At any stage after deployment, you can verify the device configuration to ensure that your database policy definitions match the actual device configurations. Distribution Manager includes logging and web-based reporting capabilities to help you maintain records of policy deployments.
  
  
• QoS Manager—The QoS Manager program runs as a Windows NT or Windows 2000 service. It distributes the changes requested by Distribution Manager by configuring the devices, and maintains the QoS database created in Policy Manager. There are no direct interfaces to QoS Manager, although it appears in the Windows NT Services control panel. QoS Manager must be running in order for you to deploy policies using Distribution Manager.
  
  

For information about QPM features, refer to:

• QPM Features and Benefits
  
  
• New Features in QPM 2.1
  
  

QPM Features and Benefits

Table 1-1 provides a description of QPM's main features and benefits.

New Features in QPM 2.1

Table 1-2 describes the main new features in QPM 2.1. For specific information about which QoS features are supported on the devices and their software versions, refer to What Devices and Software Releases Are Supported?.

What Devices and Software Releases Are Supported?

The tables in this section describe the devices and software releases that QoS Policy Manager supports, and the QoS techniques you can use on the supported platforms. Please note that the information in the tables is subject to change, depending on specific devices and their QoS support.

Note   QPM allows you to manage large enterprise networks by creating multiple QoS databases, each of which manages a different subset of devices. For example, you can manage core devices in one database and edge devices in another database.

The following information is provided:

• Supported Devices and QoS Techniques for IOS Software Releases
  
  
• Supported Devices and QoS Techniques for CatOS Software Releases
  
  
• Supported Device Software Releases and QoS Techniques for Other Devices
  
  
• QoS Features That Require IP CEF or dCEF
  
  

Supported Devices and QoS Techniques for IOS Software Releases

Cisco IOS releases supported include 11.1, 11.2, 11.3, 11.1cc, 12.0, 12.1, 12.2, 12.2(2)T, and 12.1(6)E. In addition, a Cisco IOS mapping function is used to enable QPM to support 12.2(2)T and 12.1(6)E QoS techniques included in later releases of IOS main (T or E train) software.

The following tables describe the QoS techniques that you can use with the devices and IOS software releases that QPM supports.

• Table 1-3, "Supported Devices and QoS Techniques for IOS Software Releases 11.x"
  
  
• Table 1-4, "Supported Devices and QoS Techniques for IOS Software Releases 12.x"
  
  

Supported Devices and QoS Techniques for CatOS Software Releases

Cisco CatOS releases supported include 5.5, 6.1 and 6.2. In addition, a Cisco CatOS mapping function is used to enable QPM to work with the supported QoS techniques of 5.5, 6.1, and 6.2 in later releases of CatOS.

The table below describes the QoS techniques that you can use with the devices and CatOS software releases that QPM supports.

Supported Device Software Releases and QoS Techniques for Other Devices

The table below describes the QoS techniques that you can use with other devices and device software releases that QPM supports.

QoS Features That Require IP CEF or dCEF

Cisco Express Forwarding (CEF) is an advanced Layer 3 switching technology inside a router. Distributed CEF (dCEF) enables distributed forwarding on interfaces with VIP.

CEF must be enabled on a device in order to configure the following class based QoS features on the device:

• NBAR
  
  
• Class-based packet marking
  
  
• Class-based limiting (on a Cisco 7500 router)
  
  
• DTS
  
  

dCEF must be enabled in order to configure the following class based QoS techniques on a device with VIP:

• dNBAR
  
  
• dFRF
  
  
• dWRED
  
  

The global CLI command to enable CEF is:

How Does QoS Policy Manager Deploy QoS Policies?

QoS Policy Manager translates your policies into device commands and enters the commands through the device's command line interface (CLI). Some policies require the creation of access control lists (ACLs), others do not.

You can define up to three ACL ranges for the ACLs created by QPM. This lets you control your ACL numbering and use your specific numbering convention. The ACL range is defined globally for all QoS databases in your system.

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.

Device configuration can be implemented through QPM in the following ways:

• Via Telnet
  
  
• Using a configuration file
  
  
• Via Telnet and using a configuration file
  
  

The configuration file can be deployed to the device via TFTP or any other application that downloads configuration files to the devices.

Using QPM, you can restore a previous version of a specific database that was distributed to the network, in order to redistribute it. This is especially important when unexpected errors occur as a result of the deployment of a database and there is an immediate need to go back to a previous version of that database.

Does QoS Policy Manager Ensure That Policies Are Consistent with Network Configuration?

QoS Policy Manager does basic checking to ensure that your policies can be implemented. For example, you cannot define a policy or select a queuing technique that is not supported on the interface or device based on its software version and device model.

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 defined policies can be implemented, but does not ensure that your policies will have the effect you desire.

You can verify the device configuration to check whether the policies configured on the devices are consistent with the policies defined in your QoS database. If CLI changes are made on the device after deployment, there might be a mismatch between the database and the device configuration. During verification a DNS resolution check is done for all DNS names that are defined in the policy filter definition.

How Does QoS Policy Manager Support Existing QoS Configurations?

If you have already defined QoS configurations on your devices using the CLI, you can upload them into the QoS database when you add the devices to the database. QoS Policy Manager translates the QoS configurations into the QoS database, and generates reports for those QoS configurations that were not successfully uploaded. Unsuccessful upload might be because of incomplete configurations on the router, configuration options that are not supported by QPM, and so on.

How Does QoS Policy Manager Support Existing ACLs?

If you have existing ACLs on a device, QPM does not change 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.

Planning for QoS Deployment

These topics help you decide how and where to deploy QoS in your network:

• Which Applications Benefit from QoS
  
  
• Which Interfaces Benefit from QoS
  
  
• Where to Deploy QoS in the Network
  
  

Which Applications Benefit from QoS

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 the problems of 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.

Real-time applications such as voice applications tolerate minimal variation in the amount of delay affecting delivery of their voice packets. Voice traffic is also intolerant of packet loss and jitter, both of which degrade unacceptably the quality of the voice transmission delivered to the recipient end user. You can use QoS policies to provide priority service to ensure reliable delivery of packets with low latency.

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.

Which Interfaces Benefit from QoS

Any interface that is congested or on which congestion avoidance is required, 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.

Where to Deploy QoS in the Network

Deploy QoS to manage traffic congestion, and ensure the quality of real-time traffic:

• Congestion Management—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.
  
  
• Real-time Traffic Management—Deploy QoS wherever you have real-time applications, such as voice applications, to reduce delay and jitter.
  
  

What Types of Quality of Service Does QPM Handle?

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 choose different QoS techniques for different interfaces, as appropriate, to implement your overall networking policies.

QPM policies let you define the following:

• Classification—Packet classification assigns IP precedence or DSCP value to traffic flow. In QPM, this is called coloring. Coloring is generally applied to inbound traffic on its first interface.
  
  
• Limiting—The rate of traffic allowed to enter or exit an interface. On routers, limits are defined for aggregate flows. On Catalyst switches, you can define rate limits for single flows or aggregate flows. Out-of-profile traffic is discarded or its precedence value is marked down.
  
  
• Shaping—How to smooth the rate of traffic. Shaping can only be defined on outbound interfaces.
  
  
• Queuing—Scheduling and drop preferences to be applied to packets for congestion management and avoidance. Some queuing methods queue packets according to their coloring; for other queuing methods you may need to specify queuing priorities. The queuing method is defined as a QoS property on the interface. Queuing parameters are defined in the QoS policy.
  
  

The following 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 Policy Implementation Sequence on an Interface
  
  
• Traffic Coloring Techniques
  
  
• Traffic Shaping or Traffic Limiting Techniques for Controlling Bandwidth
  
  
• Queuing Techniques for Congestion Management for Outbound Traffic
  
  
• Queuing Techniques for Congestion Avoidance on Outbound Traffic
  
  
• Management of Voice and Other Real-Time Traffic
  
  
• Managing Traffic Through Access Control
  
  
• Signaling Techniques
  
  

Understanding Policy Implementation Sequence on an Interface

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:

• Normally coloring policies are applied first and at the input interface. For most interfaces, the first policy match found ends the search through the defined policies: that is, each policy is compared to the packet, and when a match is found, the policy is applied and no other policies are considered. There may, or may not, be a coloring policy.
  
  
• Next, shaping policies or limiting policies are applied. Shaping policies and limiting policies are applied to shape or limit bandwidth. Shaping policies work only on outbound traffic, whereas limiting policies can work on both outbound and inbound traffic. Shaping policies and limiting policies are not interchangeable. A shaping policy attempts to smooth the traffic flow to the specified rate. A limiting policy drops all packets that exceed the rate limit without trying to smooth the flow. There may, or may not, be a shaping policy or a limiting policy.
  
  
• Queuing the packet. After any policies are applied to a packet, the packet is queued to leave the interface. At this point, if a coloring policy was applied to a packet, it can affect how the packet is queued. If shaping policies or limiting policies were applied, it affects the bandwidth available to the packet.
  
  
• Send the packet to the designated IP address.
  
  

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.

Traffic Coloring Techniques

Some interface or device QoS properties recognize a packet's relative importance by examining the IP precedence or DiffServ Code Point (DSCP) value in the packet's header. Changing the IP precedence or DSCP value changes the packet's color or classification. Because the IP precedence or DSCP value is embedded in the packet, changing it can affect the way the packet is handled on its entire path through the network.

This topic provides the following information:

Coloring on Routers

Coloring on Catalyst 5000 Family Switches

Coloring on Catalyst 6000 Family Switches

Interface QoS Property Requirements for Colored Traffic

You can define traffic coloring policies on any type of interface.

WFQ, WRED, WRR, 1P2Q2T, 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).

Coloring on Routers

On routers, you create coloring policies on interfaces. QPM uses policy-based routing (PBR), committed access rate (CAR), or modular CLI classification to implement the policies. If the router and IOS software version supports CAR, QPM uses CAR. Otherwise, QPM uses PBR. QPM uses modular CLI if you choose to create a class-based policy on a router with an IOS software version that supports modular CLI.

Because IOS software applies coloring policies on the inbound interface before queuing a packet, the coloring policy you define can affect how that packet is queued on the interface. Interfaces that use WFQ, WRED and WRR queuing techniques automatically recognize and use the IP precedence value. PQ, CQ and CBWFQ interfaces do not automatically consider the IP precedence of a packet. Therefore, to have coloring affect how the packet gets prioritized on an interface using these queuing techniques, 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 defined 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 presents you with these advanced features only if the interface supports them.

If the software version supports modular CLI, you can define a class-based multiple-action policy that can contain a coloring action, a limiting action and queuing. The limiting policy definition can also apply coloring, based on whether the traffic conforms to the rate limit or exceeds it.

Note   If you define both coloring and queuing actions on an outbound interface, the queuing action cannot use the coloring defined in the same policy on that interface. It will use the coloring defined on the inbound interface.

Coloring on Catalyst 5000 Family Switches

Coloring policies on Catalyst 5000 family switches apply to all interfaces on the device. The switch itself does not use the packet classification to alter how it queues packets—the precedence setting affects only the packet as it travels through other network devices.

Coloring on Catalyst 6000 Family Switches

You create coloring policies in order to change the classification of packets, giving some packets priority over others across the network. Ports that use 1P2Q2T or 2Q2T queuing, or other precedence-sensitive queuing techniques, use the packet classification to determine how they queue packets.

With Catalyst 6000 switches, you can create coloring policies on the switch's ports or VLANs. For each port, you can specify whether its QoS style is port-based or VLAN-based. Policies defined on a VLAN will be deployed to its ports only if the ports are defined with VLAN-based QoS style (see Working with Device Interfaces and VLANS).

If you want to create the same policy on all ports on a device, you can create a device group containing all the ports and define the coloring policy on the device group. On deployment, only one ACL is created for the device. This ACL is mapped to each port in the device group.

You can also color packets while limiting the traffic rate by creating a limiting (traffic policing) policy instead of a coloring policy.

Trust Boundaries

Coloring a packet or flow with a specific priority establishes a trust boundary that must be enforced. The concept of trust is integral to implementing QoS on Catalyst 6000 switches. Once end devices have a set class of service (CoS) or type of service (ToS), the switch port has the option of trusting them or not. If the port trusts the settings, it does not need to do any reclassification; if it does not trust the settings, then it must perform reclassification for appropriate QoS. QPM allows ports to be configured as trusted or untrusted, on both the individual port level and the device group level. On trusted ports, the received CoS/ToS values are used. On untrusted ports, the received CoS/ToS values are replaced with the port CoS/ToS value.

Catalyst 6000 switches (but not Catalyst 6000 switches with Supervisor IOS) provide the additional capability to extend the trust boundary. For example, this is particularly useful for a VoIP network where you have a PC-IP phone-Catalyst 6000 setup. You can ensure that voice packets retain their high precedence settings by extending the trust boundary to the IP phone and setting it to "untrusted" so that the precedence of all packets received from the PC is negated.

Coloring by Trust

In a coloring policy, you have the option to specify a trust setting for specific traffic. This overrides the trust setting configured on the port, for the traffic that matches the policy's filter. This is useful, for example, if a port's trust value is Untrusted, but you are interested in trusting the precedence values of specific traffic from a reliable source.

Coloring on LocalDirector

On LocalDirector, you can create coloring policies on the device. QPM uses LocalDirector packet classification to implement the policies. You can color all traffic from a virtual server, or you can limit the coloring to specific ports or bind  IDs, depending on how the virtual and real servers are defined on the LocalDirector. LocalDirector itself does not use the packet classification to alter how it queues packets—the precedence setting only affects the packet as it travels through other network devices.

Related Topics

• Limiting on RoutersLimiting Bandwidth and Optionally Coloring Traffic
  
  
• Limiting on SwitchesPolicing Traffic by Limiting Bandwidth
  
  
• Creating a Policy
  
  
• More Information About Quality of Service
  
  

Traffic Shaping or Traffic Limiting Techniques for Controlling Bandwidth

You can create traffic shaping or limiting (traffic policing) policies on a device's interface to define 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), or in class-based policies (modular CLI), with the exception of Frame Relay traffic shaping (FRTS) which is defined as an interface characteristic. 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 (GTS)Basic Traffic Rate Control
  
  
• Frame Relay Traffic Shaping (FRTS)Controlling Traffic on Frame Relay Interfaces and Subinterfaces
  
  
• Distributed Traffic Shaping (DTS)Controlling Traffic on VIP Interfaces
  
  
• Limiting on RoutersLimiting Bandwidth and Optionally Coloring Traffic
  
  
• Limiting on SwitchesPolicing Traffic by Limiting Bandwidth
  
  

Generic Traffic Shaping (GTS)—Basic Traffic Rate Control

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. When the buffer is full, packets are dropped.

You can define GTS properties in class-based, multiple-action policies on devices with a software version that supports modular CLI. In these policies, GTS provides two types of shape commands: average and peak. When shape average is configured, the interface sends no more than the committed burst (Bc) in each interval. When shape peak is configured, the interface sends the committed burst (Bc) plus the excess burst (Be) bits in each interval.

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).

Interface QoS Property Requirements for Generic Traffic Shaping

You can define generic traffic shaping policies on any type of interface except VIP interfaces and those that use Frame Relay traffic shaping (FRTS). On VIP interfaces you can use Distributed Traffic Shaping (DTS). On Frame Relay interfaces, you cannot use GTS and FRTS simultaneously, nor can you mix GTS and FRTS on subinterfaces of a single interface.

On devices with a software version that supports modular CLI, you can configure GTS with CBWFQ.

Related Topics

• Creating a Policy
  
  
• Frame Relay Traffic Shaping (FRTS)Controlling Traffic on Frame Relay Interfaces and Subinterfaces
  
  
• Distributed Traffic Shaping (DTS)Controlling Traffic on VIP Interfaces
  
  
• More Information About Quality of Service
  
  

Frame Relay Traffic Shaping (FRTS)—Controlling Tra