cc/td/doc/product/rtrmgmt/qos/qpm21
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Working with Policies

Working with Policies

A major part of your Quality of Service configuration is the policy statements you create in QoS Policy Manager and deploy to your network devices. These policies define how the network devices manage the data that flows through the network.

These topics cover the details about creating and managing policies.

Understanding Policies

Using QPM, you can create the following types of policies:

The filter you create for a policy can be broad, in which case the policy is applied to a high percentage of the traffic that travels through the device or interface, or it can be very narrow and selective. When the device determines that a packet satisfies the conditions of the policy, it applies the policy's action to it. If there is more than one policy defined on the interface or device, the device looks at the policies in order, top to bottom, until a match is found, at which point it applies the policy and ignores remaining policies. (If you are creating an advanced coloring or limiting policy, however, you can specify that additional policies be considered after the device applies a matching policy.)

If an interface belongs to a device group, the list of policies includes those defined on the device group, as well as those defined directly on the interface. You cannot edit or change the order of group policies when viewing them from a member interface; you can only change the order on the device group. Group policies are always given lower priority than individual interface policies.

When you create a policy, QPM presents you with only actions and settings that are valid for the device and interface as they are defined in the QoS database. If an action you want is not available, ensure that the QoS database has the correct configuration information for the device, and that the device supports the QoS feature.

With QPM, you can enable and disable policies without deleting them. However, the status of the policy on the device does not change until you deploy the database to the devices.

QoS Policy Actions

QPM uses CLI or modular CLI (also known as MQC) to implement QoS policies, depending on the interface, QoS property, and software version. Policies implemented with modular CLI can contain multiple actions.

The actions you can apply using QoS policies depend on several factors:

Related Topics

Creating a Policy

You can create a QoS policy whenever you want to apply specific QoS actions to a selected group of packets, rather than just change how an interface or group of interfaces manages traffic. See Policy Actions, for information about the QoS actions you can apply through QPM.

You can create an access control policy to permit or deny specific classes of traffic. These policies do not contain any associated actions.

Before You Begin
Procedure

Step 1   In the tree view, select the interface, device, device group, or VLAN on which you want to create a policy.

Step 2  
To create a QoS policy, click the New QoS Policy button, or right-click in the List View pane and select NewQoS Policy.


To create an access control policy, click the New Access Control Policy button, or right-click in the List View pane and select New Access Control Policy.

QPM opens the Properties of Policy dialog box, in which you will create the policy.

When you first open the Properties of Policy dialog box, the General page appears in the right pane of the Properties of Policy dialog box. The types of actions that can be defined appear in the left pane. This list depends on the device, software version, interface, and type of policy (QoS or access control).

Step 3   In the General Properties page, change the name of the policy and add a meaningful comment. By default, the policy you create is enabled—you can disable it by changing the status on this page.

Step 4   Click Next to open the Direction Properties page, and choose the direction of packets to which the policy applies.

Actions that are invalid for the selected direction are grayed out in the left pane.

Step 5   Click Next to open the Filter Properties page, and create the policy filter.

The filters you create determine to which packets the policy applies. The filter elements available to you differ depending on the type of device. Typically, you can identify the traffic by its general characteristics, its source, or its destination.

Each row in the filter grid in the filter properties tab is a complete condition—in order for a packet to satisfy the condition in a row, it must satisfy all elements of the row.

When the software version on the device supports modular CLI, and you select Class Based QoS for the QoS property on the interface, the filter pages displays additional tabs for filtering options using Network Based Application Recognition (NBAR) properties (or dNBAR for VIP interfaces) and IP RTP ports. You do not have to define an NBAR or IP RTP filter. You can leave these tabs blank. When the interface QoS property is Class Based QoS or Priority Queuing, you can also create a policy for unclassified traffic that does not match any other filter condition. This policy is called the class default policy.

You can create many separate filter conditions for the policy. Rows in the filter grid are logically disjoined—that is, a packet satisfies the filter if it satisfies the condition in any one complete row. For example, if one row specifies TCP for protocol and 80 for sender port, and a second row specifies only UDP for protocol, then the filter applies to all UDP traffic and all TCP port 80 traffic (web traffic).

When creating filters using NBAR properties or IP RTP ports, you can apply the policy to packets that match any of the NBAR/IP RTP conditions, or any of the filter conditions, or to packets that match all of the NBAR/IP RTP conditions, and any one of the filter conditions.

See these tables for specific information on the filter elements available:

Step 6   For an Access Control policy, click Finish to save the policy. QPM adds the policy to the selected folder.

For a QoS policy, do one of the following to define a policy action:

On interfaces for which the QoS property is Class Based QoS, you can define multiple actions in a single policy. In other cases, after you define one action, the other actions are disabled, and you cannot define additional actions.

The actions available to you are determined by many factors (described in Understanding Policies). QPM only shows you the actions that are valid for this policy. See Policy Actions for a description of the actions you can select.

Step 7   Click Finish to save the QoS policy.

QPM adds the policy to the selected folder.


Tips

Policy Actions

The policy actions that are available for a specific interface or device group and its software version, are listed in the left pane of the Properties of Policy dialog box. The possible actions are as follows:

See Table B-27 for complete information on the coloring properties.

See Table B-29 for complete information on the shaping properties.

Select the Limiting Properties check box to enable the limiting action.

Enter the desired average rate limit, which must be a multiple of 8, in the Rate field, in kilobits per second. If a traffic flow is lower than or equal to this rate, the policy applies your conforming priority, if any, and transmits the traffic. If a traffic flow is greater than this rate, the traffic is dropped unless you specify burst sizes.
You can also color the conforming traffic, and indicate that subsequent policies should be considered for the traffic. For example, you could limit the flow of inbound traffic, set its precedence or DSCP value, then use a subsequent policy to place the traffic in a custom queue.
A limiting rate limit is a rigid limit. If a traffic flow exceeds your limit, the device drops all packets that exceed the rate. This allows you to set a firm service level for a traffic flow.
Because the device changes the color of a packet before queuing the packet, you can color traffic before you limit it on a single interface. You can color the traffic using a separate coloring policy, or you can color the conforming traffic within the limiting policy itself.
See Table B-30, Part 1 for complete information on the limiting properties for routers.
On all Catalyst 6000 switches, when defining a limiting policy, you can choose whether to limit per flow (microflow), per device (aggregate) or across several interfaces in a device group (cross-interface). In addition, you can specify that packets that match the filter but that exceed their designated rate are marked down, according to a pre-defined markdown table. In this way, you can apply different markdown values for packets with different IP precedence or DSCP values, rather than applying a fixed markdown value for all traffic that meets the filter conditions.
Enter the desired rate limit, which must be a multiple of 32, in the Rate field, in kilobits per second, and enter a burst size in kilobits. If supported, you can also enter an exceed burst size. If a traffic flow is lower than or equal to the combination of rate and burst size, the policy transmits the traffic. If a traffic flow is greater than this rate, the traffic is dropped or marked down, depending on what you specify as the exceed action.
If you want to reduce the precedence values of out of profile traffic, you must enter a Precedence or DSCP value. Any traffic that exceeds the rate is assigned this precedence. The precedence affects how the packets are queued on the port.
See Table B-30, Part 2 for complete information on the limiting properties for switches.
Select the queuing Properties check box to enable the queuing action.

Select the desired priority queue for the traffic in the Priority Level field. If you do not create a class default policy, unfiltered traffic is placed in the normal queue.
You can define a priority queuing action only on an interface or device group that has priority queuing as the interface QoS property. See Adding Device Interfaces or Creating Device Groups for information on defining the QoS property on an interface or device group.
See Table B-26, Part 1 for complete information on the priority queuing properties.
Enter the percentage of the interface's bandwidth you want to allocate to the traffic in the Ratio field.
The value must be in increments of 5% from 5% to 95%, and the total allocation of all custom queue policies on the interface or device group must not exceed 95%. The remaining 5% is used for unfiltered traffic.
You can define a custom queuing action only on an interface or device group that has custom queuing as the interface QoS property. See Adding Device Interfaces or Creating Device Groups for information on defining the QoS property on an interface or device group.
See Table B-26, Part 2 for complete information on the custom queuing properties.
For Cisco 8500 devices, enter the weight of each queue, from 0 to 15. The sum of the weights for the four queues should be 15. For other layer 3 switches, enter weights from 1 to 4. Voice traffic is typically placed in queue 2.
See Table B-26, Part 3 for complete information on the queue weight properties, including information on how packets are assigned to each queue and the default weights for the queues.
Enter the minimum percentage of the interface's bandwidth you want to allocate to the traffic in the Bandwidth field. Unless you change the maximum allocatable bandwidth on the interface, the value must be a whole number from 1% to 75%, and the total allocation of all CBWFQ policies on the interface or device group must not exceed 75%. If the interface is on a VIP card, the upper limit is 99%.
You can also set the drop mechanism for the interface. If you select WRED, configure the weight used to determine the length of the queues (Cisco recommends 10). Using WRED as the drop mechanism ensures that the precedence setting in the packets are used to selectively drop low priority packets before high priority packets. If you use tail drop, all a packets are treated equally.
You can create a strict priority queue, for example, for voice traffic. When you create this priority queue, you do not specify the drop mechanism.
If you do not define a class default policy for the interface, WFQ is used for unfiltered traffic.
You can define a CBWFQ action only on an interface or device group that has Class Based QoS as the interface QoS property. See Adding Device Interfaces or Creating Device Groups for information on defining the QoS property on an interface or device group.
See Table B-26, Part 4 for complete information on the CBWFQ properties.
Related Topics

Resolving the Host Names in a Policy to Their IP Addresses

QoS Policy Manager resolves newly added host names to their IP addresses when you save the QoS database, so you are never required to manually resolve new host names. However, QPM cannot identify if an already-used host name's IP address has changed. When IP addresses for host names have changed, you should resolve all host names so that the IP address changes are recognized and distributed to the devices.

Before You Begin

The DNS resolution process requires that the DNS server is up and available. Do not resolve host names if you are currently having DNS server problems.

Procedure

Step 1   To resolve only those host names that you have added to the database since your last save, select Tools>DNS Resolution>Resolve Unresolved Host Names.

To resolve all host names in the QoS database, select Tools>DNS Resolution>Resolve All Host Names.


Tips

Modifying a Policy

If a policy is not meeting your needs, you can modify its properties. When you redistribute the policies, the modified policy replaces the old policy on the device.

Procedure

Step 1   Select the interface, device, or device group that contains the policy you want to modify in the tree view.

Step 2   Double-click the policy you want to modify in the list view.

QPM opens the Properties of Policy window.

Step 3   Click the definition stage in the left pane that contains the settings you want to change, and alter the settings as desired. See Creating a Policy for information on each stage in policy creation.


Tips
Related Topics

Deleting a Policy

When you no longer want to use a policy, you can delete it from the QoS database. When you redistribute the policies, the deleted policy is removed from the associated device.

Before You Begin

If you are not sure that you no longer need a policy, consider disabling it instead of deleting it. See Enabling and Disabling Policies for more information.

Procedure

Step 1   Select the interface, device, or device group that contains the policy you want to delete in the tree view.

Step 2   Right-click the policy you want to delete in the list view and select Delete, or select Devices>Policy>Delete.


Tips
Related Topics

Enabling and Disabling Policies

When you create a policy on an interface, device, or device group, it is enabled by default. That is, when you distribute the QoS database to the devices, the policy is distributed and takes effect. However, you can disable a policy, or enable a disabled one, so that some policies that exist in the QoS database are not enacted on the network. This allows you to define policies before you want to make them effective, or temporarily remove a policy from the network without erasing it completely.

Procedure

Step 1   Select the interface, device, or device group that contains the policy you want to enable or disable in the tree view.

Step 2   Select the policy you want to enable or disable in the list view.

Step 3   Right-click on the policy and select Enable or Disable.

If you enable the policy, it is used on the interface, device, or device group.

If you disable the policy, it only resides in the QoS database, it is not defined on the devices.

Step 4  
Click the Save button to save your changes to the database. This only updates the database—it does not change the policies on the devices.

Step 5  
Click the Distribution Manager button to start Distribution Manager, and distribute your policies. See Distributing Policies and QoS Configurations for the procedure.


Related Topics

Creating Policy Building Blocks

You can simplify your policies by creating various building blocks that you can then use in the individual policy statements.

For example, you can create a host group that includes every host that requires a specific type of QoS. Instead of entering every host name in each related policy statement, you would use the name of the host group. Then, to add a host to a policy, you would edit the host group instead of every related policy.

These topics cover the types of building blocks you can create in QPM:

Working with Host Groups

A host group is a group of network hosts or subnets. You can use host groups to simplify the writing of your policies, because you can write a policy for the group instead of listing each host in the policy's filter.

Creating Host Groups

Create a host group when you want to treat a set of network hosts or subnets identically in a policy statement.

Before You Begin

Determine the names or IP addresses of the hosts or subnets you want to group together.

Procedure

Step 1  
Click the Host Groups button, or select Tools>Host Groups.

QPM opens the Host Groups window.

Step 2   In the Host Groups window, click New to create a new host group.

QPM opens the Properties of Host Group window.

Step 3   Enter a host group name in Group Name. Choose a name you will find meaningful.

Step 4   In the Members group, click in an empty box in the Host column and enter a host name or IP address. You can enter a subnet by including both IP address and subnet mask information.

If you run out of empty boxes, press Enter when your cursor is in the last row. QPM will also add a row if you click out of a box and select another box.

When you are finished adding members, click OK to return to the Host Groups window. Click OK in the Host Groups window to return to Policy Manager.


Tips
Related Topics

Modifying Host Groups

Modify a host group to add or remove members, or to change the host group name.

Procedure

Step 1  
Click the Host Groups button, or select Tools>Host Groups.

QPM opens the Host Groups window.

Step 2   In the Host Groups window, double-click the name of the host group you want to modify.

QPM opens the Properties of Host Group window.

Step 3   Make your desired changes to the host group:

If you run out of empty boxes, press Enter when your cursor is in the last row. QPM will also add a row if you click out of a box and select another box.

Step 4   When you finish modifying the host group, click OK to return to the Host Groups window. Click OK in the Host Groups window to return to Policy Manager.


Tips
Related Topics

Deleting Host Groups

Delete a host group when you no longer need to treat the set of hosts as a group. However, you can modify a host group to remove selected hosts, or add other hosts, if you still need to group a subset of the hosts in the group.

Before You Begin

You cannot delete a host group if it is being used in a policy. If you try to delete the group, QPM tells you the interface and policy name of the first policy it finds that uses the group.

Procedure

Step 1  
Click the Host Groups button, or select Tools>Host Groups.

QPM opens the Host Groups window.

Step 2   In the Host Groups window, select the name of the host group you want to delete.

Step 3   Click Delete. QPM asks for confirmation before deleting the group.


Working with Application Services Aliases

An application service alias is a name of a defined set of characteristics that can identify the source of network traffic from a host or subnet. You can use application service aliases to simplify the writing of your policies, because you can write a policy for the application service instead of one for each host.

Creating Application Service Aliases

Create an application service alias when you want to identify a particular type of network traffic source.

Before You Begin

Determine the IP address of the host or subnet that is the source of the targeted traffic.

Procedure

Step 1  
Click the Application Services button, or select Tools>Application Services.

QPM opens the Application Services window.

Step 2   Click Add in the Application Services window.

QPM opens the Application Service window.

Step 3   In the Application Service window, fill in the required information to identify the source of the targeted traffic, and to give the application service alias a name.

Click OK when finished to return to the Application Services window.

Step 4   Click OK in the Application Services window.


Modifying Application Service Aliases

Modify an application service alias when you want to change some characteristic of the type of network traffic source.

Procedure

Step 1  
Click the Application Services button, or select Tools>Application Services.

QPM opens the Application Services window.

Step 2   Select the alias you want to change and click Edit in the Application Services window.

QPM opens the Application Service window.

Step 3   In the Application Service window, change the information as required to identify the source of the targeted traffic, or change the application service alias name.

Click OK when finished to return to the Application Services window.

Step 4   Click OK in the Application Services window.


Deleting Application Service Aliases

Delete an application service alias when you no longer want to use the alias in policies.

Procedure

Step 1  
Click the Application Services button, or select Tools>Application Services.

QPM opens the Application Services window.

Step 2   Select the alias you want to delete and click Delete in the Application Services window.

QPM deletes the alias. If a policy still uses the alias, QPM changes the policy's filter by replacing the alias with the properties defined in the application service.


Changing the Priority of Policies

The device examines QoS policies in order until a match is found for the packet. Even if a packet satisfies more than one policy, it will be treated as satisfying only the first policy that the device encounters, unless you define your policy to include the Continue setting, in which case a subsequent match will be sought.

Policies on an interface are examined top-down according to the QPM display. Therefore your policies for an interface should appear in order of importance, from top to bottom, in order to ensure that policies get the priority you require. If you are creating complex policy structures that include Continue settings (so that you can set multiple policies on a given packet), ensure that the statements with the Continue setting come before the subsequent policy statement you want applied.

If an interface belongs to a device group, the list of policies includes those defined on the device group as well as those defined directly on the interface. You cannot edit or change the order of group policies when viewing them from a member interface. Group policies are always given lower priority than individual interface policies.

Procedure

Step 1   Select the interface, device, or device group whose policies you want to reorder in the tree view.

Step 2   Select the policy whose position you want to change in the list view, and:


Creating Policy Reports

You can create reports about your policies to help you identify the policies you have deployed. This might help you identify inconsistencies or other issues that you want to address.

Table 7-1 lists the reports available and the commands for creating them. The reports are created in HTML and displayed in your default web browser. Use the web browser's Print and Save As commands to print or save the reports.


Table 7-1: Policy Reports
Report Type Command Description

All Policies

Tools>Reports>All Policies

Displays the information on all policies defined in the database.

Device Policies

Tools>Reports>Device Policies

Displays information on all policies defined on the selected device.

Interface Policies

Tools>Reports>Interface Policies

Displays information on all policies defined on the selected interface.

Device Group Policies

Tools>Reports>Device Group Policies

Displays information on all policies defined on the selected device group.

Tips

hometocprevnextglossaryfeedbacksearchhelp
Posted: Tue Nov 12 12:26:43 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.