Hierarchical Policy with Queueing Features at Every Level

You can apply class-based queueing to any traffic class in the parent or child level of a hierarchical policy and obtain service levels for different sessions or subscribers.

In the example shown below, the traffic belonging to class parent-c2 has more scheduling time than class parent-c1:

policy-map child
 class child-c1
  bandwidth 400
 class child-c2
  bandwidth 400
policy-map parent
 class parent-c1 <------------------
  bandwidth 1000
  service-policy child
 class parent-c2 <------------------
  bandwidth 2000
  service-policy child

Shaping in an ATM PVC Policy

You can apply class-based shaping within an ATM PVC as shown in the following example:

policy-map p1
 class c1
  shape average 1000000
 class c2
  shape average 1000000
interface atm1/0.1
 pvc 1/100
  service-policy output p1
policy-map p1
 class c1
  shape average 1000000
 class c2
  shape average 1000000
interface atm1/0.1
 pvc 1/100
  service-policy output p1

Child Policy in a Priority Class

You can apply a child policy to a class with priority enabled as shown in the following example. The child policy can contain police or set features, but not queueing features.

policy-map p1
 class c1
  priority 256
  service-policy child

Flow-Based Fair-Queueing Support in Class-Default

The fair-queueing behavior for the class-default class is flow-based. This is a change from the weighted fair queueing (WFQ) behavior in previous releases. With flow-based fair queueing, the flow queues in the class-default class are scheduled equally instead of by weight based on the IP Precedence bits.

Default Queueing Implementation for Class-Default

When you do not explicitly configure the class-default class in a policy map, its default queueing behavior is FIFO. You can configure the bandwidth, fair-queue, or service-policy commands in the class-default class to achieve different queueing behaviors.

Class-Default and Bandwidth

The bandwidth assigned to the class-default class is the unused interface bandwidth not consumed by user-defined classes. By default, the class-default class receives a minimum of 1% of the interface bandwidth.

Default Queueing Implementation for Shape Class

When you configure the shape command in a class, the default queueing behavior for the shape queue is FIFO instead of weighted fair queueing (WFQ). You can configure the bandwidth, fair-queue, or service-policy commands in shape class to achieve different queueing behaviors.

Policy Map and Interface Bandwidth

In HQF, a policy map can reserve up to 100 percent of the interface bandwidth. If you do not assign an explicit bandwidth guarantee to the class-default class, you can assign a maximum of 99 percent of the interface bandwidth to user-defined classes, and you can reserve the other 1 percent for the class-default class by using the percent keyword from the bandwidth (policy-map class) command. If you use the kbps argument, you can assign a maximum of the entire interface bandwidth minus 1 kilobits per second (kbps) to user-defined classes and reserve the remaining 1 kbps for the class-default class.

Note

If you are migrating to Cisco IOS Release 12.4(20)T and the configured policy map allocates 100 percent of the bandwidth to the user-defined classes, an error message appears on the console after booting the HQF image. The message indicates that the allocated bandwidth exceeds the allowable amount, and the service policy is rejected. In HQF, you must reconfigure the policy to account for the minimum 1 percent of bandwidth that is guaranteed for the class-default. Then you can apply a service policy to the interface.

Per-Flow Queue Limit in Fair Queueing

In HQF, when you enable fair queueing, the per-flow queue limit is calculated in one of the following ways:

• 1/4 * n (where n = queue limit)

• Two packets (in the case of packet-based queue limits)

• One MTU size (in the case of byte-based queue limits)

These values are static even if the number of flows increase, so consider the overall buffer pool when configuring the queue limit in order to avoid exhausting the buffer pool.

Note	The queue limit per class in packets and bytes can be configured without fair queue. Therefore, the minimum value of queue limit per class and queue limit per flow is not connected.

It is recommended to use the default value or 200 ms worth of packets/bytes for the “queue limit per class”.

Over-Subscription Support for Multiple Policies on Logical Interfaces

When you attach a shaping policy to multiple logical interfaces including a subinterface, and the sum of the shape rate exceeds the physical interface bandwidth, congestion at the physical interface results in back pressure to each logical interface policy. This back pressure causes each policy to reduce the output rate down to its fair share of the interface bandwidth.

Here is an example: 10 subinterface policies each shaped to 2 Mbps, physical interface has 10 Mbps bandwidth (2:1 oversubscription), when all 10 subinterfaces are sending at 2 Mbps, each subinterface gets a throughput of 1 Mbps (10 Mbps/10 subinterfaces).

Shaping on a GRE Tunnel

In HQF, you can apply the shaping to a generic routing encapsulation (GRE) tunnel by using a hierarchical service policy after encapsulation. This means that the shape rate is based on packets with tunnel encapsulation and L2 encapsulation.

When configuring the shape feature in the parent policy applied to the tunnel interface, you can use the class-default class only. You cannot configure a user-defined class in the parent policy.

A typical hierarchical policy applied to a GRE tunnel interface is shown below:

interface tunnel0
service-policy output parent
policy-map parent
 class class-default
  shape average 10000000
  service-policy child
policy-map child
 class voice
  priority 512
 class video
  bandwidth 6000
 class data
  bandwidth 3000

Note

Some QoS deployments include a service policy with queueing features applied at the tunnel or a virtual interface and a service policy with queueing features applied at the physical interface. In Cisco IOS Release 12.4(20)T, you can apply a service policy with queueing features only at one of these interfaces. When migrating to Cisco IOS Release 12.4(20)T, a router configuration containing service policies at both interfaces will keep only the one applied to the physical interface.

FRF.12 and FRF.9

With HQF implementation, when you enable Frame Relay fragmentation (FRF.12) on an FR PVC or FR main interface, priority class packets are no longer subject to fragmentation. Priority packets, regardless of the packet size, always interleave among data fragments.

When you enable Frame Relay payload compression (FRF.9) on an FR PVC or main interface, priority class packets are no longer compressed. When you enable both FRF.12 and FRF.9, priority class packets are neither fragmented nor compressed.

User-Defined Classes Added to Policy Maps Attached to Logical Interfaces

A policy map may be configured with multiple user-defined classes and may contain a default class, called class-default. Optionally, a policy map may contain just the class-default, as illustrated below:

policy-map parent
 class class-default
 service-policy child

Typically, at this point, you would attach the policy map to the interface. After the policy map has been attached the interface, the HQF would allow you to add a user-defined class to the policy map.

However, HQF behavior has now changed so that this kind of modification is no longer permitted on a logical interface. If you want to add a user-defined class to a policy map (and that policy map has already been attached to a logical interface), you must first remove the policy map from the logical interface. Then add the user-defined class to the policy map and reattach the policy map to the logical interface.

Note	This behavior change applies only to logical interfaces. It does not apply to physical interfaces.

Nested Policy and Reference Bandwidth for Child Policy

In HQF when you configure a nested policy with a child queueing policy under a parent shaping class, the reference bandwidth for the child queueing policy is taken from the following: minimum (parent shaper rate, parent class's implicit/explicit bandwidth guarantee). When you do not define bandwidth for the parent class, the interface bandwidth divides equally among all parent classes as the implicit bandwidth guarantee.

The example below shows a nested policy applied on a serial interface of 1536 kbps. The 1536 kbps is equally shared, as the implicit bandwidth, among parent classes parent-c1 and class-default. For the parent class, the shaping rate of 1200 kbps is the maximum, while the implicit guarantee of 768 kbps is the minimum.

interface serial 0/0
service-policy parent
policy-map child
 class child-c1
 bandwidth percent 10
policy-map parent
class parent-c1
   shape average 1200000
 service-policy child

For the child policy child-c1 to take the parent shaping rate as the reference bandwidth, configure parent class parent-c1 with an explicit guarantee greater than the shaping rate. For example,

policy-map parent
class parent-c1
   bandwidth 1300
   shape average 1200000
 service-policy child

When configuring explicit bandwidth for parent classes with oversubscription, the restrictions in the "Policy Map Bandwidth" section applies.

Handling Traffic Congestion on an Interface Configured with a Policy Map

In Cisco IOS Release 12.4(20)T, if an interface configured with a policy map is congested, the implicitly defined queue allows the traffic as defined in the bandwidth statement of each traffic class. The queueing is activated whenever there is traffic congestion on an interface.