The QoS Hierarchical
Queueing Framework feature introduces the following behavioral changes in some
Support in Class-Default
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.
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
commands in the class-default class to achieve different queueing behaviors.
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.
Implementation for Shape Class
When you configure
in a class, the default queueing behavior for the shape queue is FIFO instead
of weighted fair queueing (WFQ). You can configure the
commands in shape class to achieve different queueing behaviors.
Policy Map and Interface
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
(policy-map class) command. If you use the
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
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
In HQF, when you
enable fair queueing, the per-flow queue limit is calculated in one of the
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
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
It is recommended to
use the default value or 200 ms worth of packets/bytes for the “queue limit per
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
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.
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.
hierarchical policy applied to a GRE tunnel interface is shown below:
service-policy output parent
shape average 10000000
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
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:
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.
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.
change applies only to logical interfaces. It does not apply to physical
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
bandwidth percent 10
shape average 1200000
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,
shape average 1200000
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.