|
One of the major parts 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.
A QoS policy is a conditional statement that applies a specific QoS action to a packet if the packet satisfies the conditions (filters) defined in the policy.
The filters 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 QoS 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.
The actions you can apply using policies depend on several factors:
When you create a policy, QPM only presents you with 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 distribute the database to the devices.
Create a policy whenever you want to apply a specific QoS action to a selected group of packets, rather than just change how an interface or group of interfaces manages traffic.
Determine the characteristics of the packets you are targeting. For example, the port the packets use, the protocol the packets use, the IP address of the source of the packets, the IP address of the destination of the packets, and so forth.
You must also add the device and its interfaces to the database before you can create policies for it.
Step 2
Click the New Policy button, or select File>New>Policy.
QPM opens the Properties of Policy window, in which you will create the policy.
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 while creating it by changing the status on this page.
Step 4 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 is a complete condition—in order for a packet to satisfy the condition in a row, it must satisfy all elements of the row.
You can create many separate filter conditions for the policy by using more than one row in the filter grid. These rows are logically disjoined (ORed)—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).
QPM does not allow you to create a set of filter conditions that are internally inconsistent. If Policy Manager finds the filter conditions inconsistent, it issues an error message that describes the error.
See these tables for specific information on the filter elements available:
Step 5 Click Next to open the Action Properties page, and select the QoS action to apply to the traffic identified by the filter.
The actions available to you are determined by many things (described in the "Understanding QoS Policies" section). QPM only shows you the actions that are valid for this policy. These are all the options that you can select:
Select the desired value in the Precedence field.
With advanced coloring policies, you can define coloring actions for inbound or outbound traffic. With regular coloring policies, the policy only applies to inbound traffic. The device changes the color of a packet before queuing the packet, so your coloring affects queuing if the interface uses a type of queuing that is sensitive to coloring.
Some versions of device software support complex coloring policies using committed access rate (CAR) classification. If you are creating a coloring policy on an interface that supports it, you can click Advanced and define a complex coloring action, rather than filling the Precedence field.
If you use the Continue field so that subsequent policies are examined after the coloring policy is applied, ensure the coloring policy appears before the subsequent policies in the list pane. For example, if you create a limiting policy that should also apply to the selected traffic, the limiting policy must appear after the coloring policy (or alternately, the limiting policy must also use Continue).
See Table B-15, Part 1 for complete information on the coloring properties.
Enter the desired average rate in the Rate field, in kilobits per second. Optionally, you can include a burst and exceed burst size. The burst size determines the number of kilobits that can be transmitted per time interval, whereas the exceed burst size determines the additional number of kilobits that can be transmitted when there is congestion.
Shaping policies buffer traffic flows to even out the transmission rate. Packets are not dropped until the buffer limits are reached.
See Table B-15, Part 2 for complete information on the shaping properties.
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.
Use the Direction field to indicate whether the policy should limit the traffic flow for traffic leaving the interface (OUT), entering the interface (IN), or both. By creating limiting policies on inbound traffic at the edge of your network, you can prevent traffic from exceeding agreed-upon limits, and ensure that the traffic is well-behaved while it is in your network.
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, 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-15, Part 3 for complete information on the limiting properties for routers.
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 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.
You must also enter a Precedence 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-15, Part 4 for complete information on the limiting properties for switches.
Select the desired priority queue for the traffic in the Priority Level field. 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 the "Adding Device Interfaces" section or the "Creating Device Groups" section for information on defining the QoS property on an interface or device group.
See Table B-15, Part 5 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 only define a custom queuing action on an interface or device group that has custom queuing as the interface QoS property. See the "Adding Device Interfaces" section or the "Creating Device Groups" section for information on defining the QoS property on an interface or device group.
See Table B-15, Part 6 for complete information on the custom queuing properties.
Enter the weight of each queue, from 0 to 15. The sum of the weights for the four queues should be 15. Voice traffic is typically placed in queue 2.
See Table B-15, Part 7 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.
When you select CBWFQ for the QoS Property on the interface, QPM creates a class default CBWFQ policy on the interface (unless the interface is on a VIP card). This policy applies to all IP traffic. You can only change some of the action characteristics for this policy. You cannot delete the policy or change its other properties. The policy is always the last one in the list of policies—you cannot change its position.
You can define a CBWFQ action only on an interface or device group that has CBWFQ as the interface QoS property. See the "Adding Device Interfaces" section or the "Creating Device Groups" section for information on defining the QoS property on an interface or device group.
See Table B-15, Part 8 for complete information on the CBWFQ properties.
Step 6 If you select the CBWFQ policy action, and the device and its software supports network-based application recognition (NBAR), QPM adds an additional page to the policy definition. Click Next to open the Application Properties page. Otherwise, continue with Step 7.
Use the application property to refine the policy's filter. If you select an application on this page, then every packet must not only satisfy the policy's filter conditions, it must also satisfy the application condition. If your filter conditions are inconsistent with your application selection, no traffic will satisfy the policy, and the policy will not be applied to any packets.
Thus, if you intend to use NBAR, ensure that the filter conditions are generic enough to include the application you select (click on Filter in the left pane to go back and redefine your filter if necessary). For example, if your goal is to identify all RealAudio traffic and apply the policy to it, select RealAudio in the Application field, then ensure that your only filter condition is TCP for protocol. Only RealAudio traffic will satisfy this combined filter-application condition.
You are not required to select an application—you can leave this page blank.
Step 7 Click Finish to save the policy.
QPM adds the policy to the selected folder.
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.
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.
If a policy is not meeting your needs, you can modify it to alter the its properties. When you redistribute the policies, the modified policy replaces the old policy on the device.
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 the "Creating a Policy" section for information on each stage in policy creation.
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.
If you are not sure that you no longer need a policy, consider disabling it instead of deleting it. See the "Enabling and Disabling Policies" section for more information.
Step 2 Right-click the policy you want to delete in the list view and select Delete, or select Devices>Policy>Delete.
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.
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 the "Distributing Policies and QoS Configurations to Network Devices" section for the procedure.
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:
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.
Create a host group when you want to treat a set of network hosts or subnets identically in a policy statement.
Determine the names or IP addresses of the hosts or subnets you want to group together.
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.
Modify a host group to add or remove members, or to change the host group name.
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.
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 have use for grouping a subset of the hosts in the group.
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.
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.
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.
Create an application service alias when you want to identify a particular type of network traffic source.
Determine the IP address of the host or subnet that is the source of the targeted traffic.
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. (See the "Application Service Dialog Box" section for more information.)
Click OK when finished to return to the Application Services window.
Step 4 Click OK in the Application Services window.
Modify an application service alias when you want to change some characteristic of the type of network traffic source.
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. (See the "Application Service Dialog Box" section for more information.)
Click OK when finished to return to the Application Services window.
Step 4 Click OK in the Application Services window.
Delete an application service alias when you no longer want to use the alias in policies.
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.
When the device examines QoS policies, it examines them in order until a match is found. 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.
In terms of the QPM display, the policies on an interface are examined top-down. To ensure that policies get the priority you require, ensure that your policies for an interface are in order of importance, from top to bottom. 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.
Step 2 Select the policy whose position you want to change in the list view, and
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 Manager Reports
Posted: Mon Aug 18 10:16:04 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.