Shape peak vs Shape Average

The shape peak replenishes both Bc and Be tokens every Tc seconds, and allows for sending at higher sustained rate that depends both on the size of Bc and Be. If only the Bc tokens were replenished, the sustained rate would be

CIR = Bc/Tc

With both Bc and Be tokens being replenished in shape peak, the sustained rate is

CIR' = (Bc+Be)/Tc

Expressing Tc from the first equation yields Tc=Bc/CIR, and using it in the second equation yields:

CIR' = (Bc+Be) / (Bc / CIR)=(Bc+Be) * CIR / Bc = CIR * (1 + Be/Bc)

This is the speed as indicated in the Command Reference for the shape peak command:

http://www.cisco.com/en/US/docs/ios/qos/command/reference/qos_s1.html#wp1074988

The shape average replenishes only the Bc tokens every Tc seconds, and hence the sustained rate is simply CIR=Bc/Tc. After periods of longer inactivity, the burst may grow up to Bc+Be bytes but it is not sustainable.

To compare:

• The sustained rate in shape average is equal to CIR=Bc/Tc (the CIR is a part of the configuration command)
• The sustained rate in shape peak is equal to CIR'=CIR * (1 + Be/Bc) (the CIR is a part of the configuration command)
• Both models allow for bursting up to Bc+Be

In default configuration, Be=Bc, therefore with shape peak, the CIR'=CIR*(1+Bc/Bc)=CIR*(1+1)=2*CIR, i.e. theshape peak would result into shaping on a doubled sustained rate than the shape average command.

Comparing the bandwidth and priority Commands

Summary of Differences

Configuring the bandwidth Command

The Cisco IOS^® Configuration Guides describe the bandwidth command as the "amount of bandwidth, in kbps, to be assigned to the class. . . .To specify or modify the bandwidth allocated for a class belonging to a policy map."

Look at what these definitions mean.

The bandwidth command provides a minimum bandwidth guarantee during congestion. There are three forms of the command syntax, as illustrated in this table:

Note: The bandwidth command defines a behavior, which is a minimum bandwidth guarantee. Not all Cisco router platforms use weighted-fair queueing (WFQ) as the underlying algorithm to implement this behavior.

Configuring the priority Command

The Cisco IOS Configuration Guides describe the priority command as reserving "a priority queue with a specified amount of available bandwidth for CBWFQ traffic…To give priority to a traffic class based on the amount of available bandwidth within a traffic policy." Below explains what these definitions mean.

You create a priority queue with these set of commands:

Router(config)# policy-map policy-name
 
Router(config-pmap)# class class-name
 
Router(config-pmap-c)# priority kpbs [bytes]

During congestion conditions, the traffic class is guaranteed bandwidth equal to the specified rate. (Recall that bandwidth guarantees are only an issue when an interface is congested.) In other words, the priority command provides a minimum bandwidth guarantee.

In addition, the priority command implements a maximum bandwidth guarantee. Internally, the priority queue uses a token bucket that measures the offered load and ensures that the traffic stream conforms to the configured rate. Only traffic that conforms to the token bucket is guaranteed low latency. Any excess traffic is sent if the link is not congested or is dropped if the link is congested. For more information, refer to What Is a Token Bucket?.

The purpose of the built-in policer is to ensure that the other queues are serviced by the queueing scheduler. In the original Cisco priority queueing feature, which uses the priority-group and priority-list commands, the scheduler always serviced the highest priority queue first. In extreme cases, the lower priority queues rarely were serviced and effectively were starved of bandwidth.

The real benefit of the priority command—and its major difference from the bandwidth command—is how it provides a strict de-queueing priority to provide a bound on latency. Here is how the Cisco IOS Configuration Guide describes this benefit: "A strict priority queue (PQ) allows delay-sensitive data such as voice to be de-queued and sent before packets in other queues are de-queued." Let's look at what this means.

Every router interface maintains these two sets of queues:

Which Traffic Classes Can Use Excess Bandwidth?

Важно!!!

Although the bandwidth guarantees provided by the bandwidth and priority commands have been described with words like "reserved" and "bandwidth to be set aside", neither command implements a true reservation. In other words, if a traffic class is not using its configured bandwidth, any unused bandwidth is shared among the other classes.

The queueing system imposes an important exception to this rule with a priority class. As noted above, the offered load of a priority class is metered by a traffic policer. During congestion conditions, a priority class cannot use any excess bandwidth.

This table describes when a bandwidth class and a priority class can use excess bandwidth:

From the above discussion, it is important to understand that since the priority classes are policed during congestion conditions, they are not allocated any remaining bandwidth from the bandwidth classes. Thus, remaining bandwidth is shared by all bandwidth classes and class-default.

How Is Unused Bandwidth Allocated?

This section explains how the queueing system distributes any remaining bandwidth. Here is how the Class-Based Weighted Fair Queueing Feature Overview describes the allocation mechanism: "If excess bandwidth is available, the excess bandwidth is divided amongst the traffic classes in proportion to their configured bandwidths. If not all of the bandwidth is allocated, the remaining bandwidth is proportionally allocated among the classes, based on their configured bandwidth." Let's look at two examples.

In the first example, policy-map foo guarantees 30 percent of the bandwidth to class bar and 60 percent of the bandwidth to class baz.

policy-map foo 
  class bar 
    bandwidth percent 30 
 class baz 
  bandwidth percent 60

If you apply this policy to a 1 Mbps link, it means that 300 kbps is guaranteed to class bar, and 600 kbps is guaranteed to class baz. Importantly, 100 kbps is leftover for class-default. If class-default does not need it, the unused 100 kbps is available for use by class bar and class baz. If both classes need the bandwidth, they share it in proportion to the configured rates. In this configuration, the sharing ratio is 30:60 or 1:2.

The next sample configuration contains three policy maps—bar, baz, and poli. In the policy map called bar and the policy map called baz, the bandwidth is specified by percentage. However, in the policy map called poli, bandwidth is specified in kbps.

Remember that the class maps should already be created before you create the policy maps.

 
 policy-map bar
  class voice
   priority percent 10
  class data
   bandwidth percent 30
  class video
   bandwidth percent 20
 policy-map baz
  class voice
   priority percent 10
  class data
   bandwidth remaining percent 30
  class video
   bandwidth remaining percent 20
 policy-map poli
  class voice
  class data
   bandwidth 30
  class video
   bandwidth 20

Note: The bandwidth remaining percent command was introduced in Cisco IOS version 12.2(T). Refer to Low Latency Queueing with Priority Percentage Support for a detailed description of the bandwidth command.

Using police Command to Set a Maximum

If a bandwidth or priority class should not exceed its allocated bandwidth during periods of no congestion, you can combine the priority command with the police command. This configuration imposes a maximum rate that is always active on the class. Choosing to configure a police statement in this configuration depends on the policy's objective.

Порядок обработки правил в HQoS

В качестве предисловия...

Queuing may be performed in software or in hardware. Within Cisco IOS Software there are two main queuing algorithms available, Class-Based Weighted-Fair Queuing (CBWFQ) and Low-Latency Queuing (LLQ).

CBWFQ

Regardless of what queuing policy is applied to an interface within Cisco IOS, there is always an underlying queuing mechanism in place called the Tx-Ring, which is a final (FIFO) output buffer. The Tx-Ring serves the purpose of always having packets ready to be placed onto the wire so that link utilization can be driven to 100%. The Tx-Ring also serves to indicate congestion to the IOS software; specifically, when the Tx-Ring fills to capacity, then the interface is known to be congested and a signal is sent to engage any LLQ/CBWFQ policies that have been configured on the interface.

Class-Based Weighted-Fair Queuing (CBWFQ) is a queuing algorithm that combines the ability to guarantee bandwidth with the ability to dynamically ensure fairness to other flows within a class of traffic. Each queue is serviced in a weighted-round-robin (WRR) fashion based on the bandwidth assigned to each class.

In Figure, a router interface has been configured with a 4-class CBWFQ policy, with an explicit CBWFQ defined for Network Control, Transactional Data, and Bulk Data respectively, as well as the default CBWFQ queue, which has a Fair-Queuing (FQ) pre-sorter assigned to it.

LLQ

Low-Latency Queuing (LLQ) is essentially CBWFQ combined with a strict priority queue. In fact, the original name for the LLQ scheduling algorithm was PQ-CBWFQ. While this name was technically more descriptive, it was obviously clumsy from a marketing perspective and hence the algorithm was renamed LLQ.

In Figure 1-18, a router interface has been configured with a 5-class LLQ/CBWFQ policy, with voice assigned to a 100 kbps LLQ, three explicit CBWFQs are defined for Call-Signaling, Transactional Data, and Bulk Data respectively, as well as a default queue that has a Fair-Queuing pre-sorter assigned to it. However, an underlying mechanism that doesn’t appear within the IOS configuration, but is shown in Figure 1-18, is an implicit policer attached to the LLQ.

The threat posed by any strict priority-scheduling algorithm is that it could completely starve lower priority traffic. To prevent this, the LLQ mechanism has a built-in policer. This policer (like the queuing algorithm itself) engages only when the LLQ-enabled interface is experiencing congestion. Therefore, it is important to provision the priority classes properly. In this example, if more than 100 kbps of voice traffic was offered to the interface, and the interface was congested, the excess voice traffic would be discarded by the implicit policer. However, traffic that is admitted by the policer gains access to the strict priority queue and is handed off to the Tx-Ring ahead of all other CBWFQ traffic.

Not only does the implicit policer for the LLQ protect CBWFQs from bandwidth-starvation, but it also allows for sharing of the LLQ. TDM of the LLQ allows for the configuration and servicing of multiple LLQs, while abstracting the fact that there is only a single LLQ “under-the-hood,” so to speak. For example, if both voice and video applications required realtime service, these could be provisioned to two separate LLQs, which would not only protect voice and video from data, but also protect voice and video from interfering with each other, as illustrated in Figure 1-19.

In Figure 1-19, a router interface has been configured with a 6-class LLQ/CBWFQ policy, with voice assigned to a 100 kbps LLQ, video assigned to a “second” 400 kbps LLQ, three explicit CBWFQs are defined for Call-Signaling, Transactional Data, and Bulk Data respectively, as well as a default queue that has a Fair-Queuing pre-sorter assigned to it.

Within such a dual-LLQ policy, two separate implicit policers have been provisioned, one each for the voice class (to 100 kbps) and another for the video class (to 400 kbps), yet there remains only a single strict-priority queue, which is provisioned to the sum of all LLQ classes, in this case to 500 kbps (100 kbps + 400 kbps). Traffic offered to either LLQ class is serviced on a first-come, first-serve basis until the implicit policer for each specific class has been invoked. For example, if the video class attempts to burst beyond its 400 kbps rate then it is dropped. In this manner, both voice and video are serviced with strict-priority, but do not starve data flows, nor do they interfere with each other.

Для понимания работы алгоритма обслуживания очередей и работы шейпера возьмем за основу 2 конфигурации:

Конфигурация 1 : MQC

policy-map WAN-QoS
class http
shape average 3072000
set dscp af41
class Mail
shape average 1024000
set dscp af41
class class-default
fair-queue

Конфигурация 2: CBWFQ

policy-map WAN-QoS
class http
priority 3000
set dscp af11
class Mail
bandwidth 2000
set dscp af41
class class-default
fair-queue

Конфигурация 1:

- HTTP трафик будет обработан шейпером до 3 Mbps и промаркирован как AF41. HTTP трафик превышающий CIR в 3 Mbps будет помещен в буфер очереди и будет обрабатываться FIFO алгоритмом по умолчанию, и если буфер окажется переполненным (параметр hold-queue x out) , пакет будет сброшен.

- Почтовый трафик будет обработан шейпером до 1 Mbps и промаркирован как AF41. Почтовый трафик  превышающий CIR в 1 Mbps будет помещен в буфер очереди и будет обрабатываться FIFO алгоритмом по умолчанию, и если буфер окажется переполненным (параметр hold-queue x out), пакет будет сброшен.

- Весь оставшийся трафик будет обработан с помощью алгоритма WFQ (директива fair-queue).

Weighted Fair Queuing (WFQ)

Weighted Fair Queuing диаметрально отличается от PQ или CQ алгоритмов. Первая и самая важная отличительная особенность, то что, WFQ не позволяет классифицировать трафик! WFQ  классифицирует пакеты основываясь на потоках (flows). Под потоком (flow) понимаются все пакеты которые имеют один и тот же адрес источника и назначения, а также порты источника и назначения, вкупе с одинаковым транспортным протоколом. Следующее большое отличие между WFQ и PQ and CQ - это scheduler, который отдает предпочтение low-volume, higher-precedence flows над large-volume, lower-precedence flows. Именно потому что WFQ является flow based queing tools, а каждый поток использует отдельную очередь, количество этих очередей по сравнению с PQ или CQ значительно выше— до 4096 queues per interface. 

Конфигурация 2: CBWFQ

policy-map WAN-QoS
class http
priority 3000
set dscp af11
class Mail
bandwidth 2000
set dscp af41
class class-default
fair-queue

- HTTP трафик вплоть до 3 Mbps будет обработан приоритетно и послан на интерфейс первым во время перегрузки (congestion) на TX-Ring и промаркирован как AF11.

- Почтовый трафик получит не менее 2 Mbps в момент перегрузки (congested) и промаркирован как AF41.

Напомню, что любые софтверные очереди (software queue) активируются только тогда, когда физическая очередь TX-Ring оказывается переполнена. 

- Весь оставшийся трафик будет обработан с помощью алгоритма WFQ (директива fair-queue).

CBWFQ/LLQ (Queuing mechanism) on subinterfaces.

Обычно мы не можем сконфигурировать и применить CBWFQ/LLQ (Queuing mechanism) на логический интерфейс, например Tunnel0 или subinterface. 

#################################################################################

Cisco IOS logical interfaces do not inherently support a state of congestion and do not support the direct application of a service policy that applies a queueing method. Instead, you first need to apply shaping to the subinterface using either generic traffic shaping (GTS) or class-based shaping. Refer to Policing and Shaping for more information.

The router prints this log message when an Ethernet subinterface is configured with a service policy that applies queueing without shaping:

router(config)# interface ethernet0/0.1
router(config-subif)# service-policy output test
 CBWFQ : Not supported on subinterfaces

In other words, you must configure a hierarchical policy with the shape command at the parent level. Use thebandwidth command for CBWFQ, or the priority command for Low Latency Queueing (LLQ) at lower levels. Class-based shaping limits the output rate and (we can assume) leads to a congested state on the logical subinterface. The subinterface than applies "backpressure," and Cisco IOS begins queueing the excess packets that are held by the shaper.
#################################################################################

Чтобы это стало возможным нам необходимо немного обмануть систему. Для этого нам нужно создать иерархическое правило HQoS в котором мы сначала создадим parent policy на котором сконфигурирован shaper ограничивающий трафик в пределах CIR для нашего логического интерфейса, а затем к нему применяется Queuing policy в качестве child policy.

Например, если у нас есть сабинтерфейс с установленным значением CIR 10Mbps и нам необходимо ограничить сверху HTTP трафик до 3 Mbps, а также обеспечить его приоритетность в периоды перегрузки, а почтовому  трафику предоставить не менее  2 Mbps, мы сконфигурируем нашу HQoS политику следующим образом:

policy-map CHILD

class HTTP

priority  3072

   set dscp af11

  class Mail

    bandwidth 2048

   set dscp af41

  class class-default

    fair-queue

policy-map PARENT

class class-default

shape average 10000000

service-policy CHILD

Приведенная выше конфигурация будет делать следующее:

• будет осуществлять шейпинг всего исходящего трафика на этом интерфейсе до значений определенных CIR (shape average 10000000) 10 Mbps. 
• Весь трафик  выше этого значения в 10 Mbps будет подвергаться буферизации и ставиться в очередь Shaping Queue (по умолчанию FIFO). 
• По умолчанию Shaping Queue -  FIFO алгоритм. 
• Однако мы переопределяем этот алгоритм, применяя CHILD policy, фактически мы меняем FIFO алгоритм на CBFWQ/LLQ и т.д..

Рассмотрим еще один вариант.

Minimum Versus Maximum Bandwidth Controls

Оба метода - и shape и police ограничивают исходящий трафик до значения maximum kbps (CIR). 

Важно отметить, что ни один ни другой механизм, не предоставляет гарантий минимальной полосы пропускания в периоды перегрузки на интерфейсе. Для этих целей, необходимо использовать команды bandwidth или priority.

Importantly, neither mechanism provides a minimum bandwidth guarantee during periods of congestion. Use the bandwidth or priority command to provide such guarantees.

A hierarchical policy uses two service policies – a parent policy to apply a QoS mechanism to a traffic aggregate and a child policy to apply a QoS mechanism to a flow or subset of the aggregate. Logical interfaces, such as subinterfaces and tunnel interfaces, require a hierarchical policy with the traffic-limiting feature at the parent level and queuing at lower levels. The traffic-limiting feature reduces the output rate and (предсказуемо) creates congestion, as seen by queuing excess packets.

Внимание:  Такая конфигурация не рекомендуется и показана только для иллюстрации различий между POLICER и SHAPER для целей ограничений агрегированного трафика, в нашем случае класс class-default.

 В этой ситуации  команда police посылает пакеты на выходной интерфейс от классов определенных в политике child базируясь на размере пакета и количестве байт или токенов в корзине Bc (based on the size of the packet and the number of bytes remaining in the conform and exceed token buckets). 

Результатом этого будет то, что битрейт выделенный для голосового и IP трафика  (given to the Voice over IP (VoIP) and Internet Protocol (IP) classes) не может быть гарантирован, так как алгоритм работы  police перечеркивает гарантии трафику сделанные командой priority (overriding the guarantees made by the priority feature).

class-map match-all IP 
   match ip precedence 3 
class-map match-all VoIP 
   match ip precedence 5 
  
policy-map child 
  class VoIP 
     priority 128 
   class IP 
     priority 1000 
 
 policy-map parent 
   class class-default 
     police 3300000 103000 103000 conform-action transmit exceed-action drop 
     service-policy child

Тем не менее,если мы будем использовать команду shape, мы получим иерархическую систему очередей (result is a hierarchical queuing system), и все гарантии при этом сохранятся (and all guarantees are made). Другими словами, когда битрейт трафика превысит указанный shape rate, трафик VoIP и IP классов получат свои гарантии по битрейту, а трафик класса class-default (at the child level) будет подвергаться сбросу.

In other words, you must configure a hierarchical policy with the shape command at the parent level. Use the bandwidth command for CBWFQ, or the priority command for Low Latency Queueing (LLQ) at lower levels. Class-based shaping limits the output rate and (we can assume) leads to a congested state on the logical subinterface. The subinterface than applies "backpressure," and Cisco IOS begins queueing the excess packets that are held by the shaper.

В соответствии с вышеприведенной конфигурацией, policing должен быть заменен на shaping. 

Например:

policy-map parent
    class class-default
     shape average 3300000 103000 0
      service-policy child

Inside each queue, the queuing methods use FIFO Queuing. The interesting logic for queuing 

occurs after the packets have been enqueued, when the router decides from which queue to take 

the next packet. Queue schedulingdescribes the process of the device, in this case a router, 

choosing which queue to service next. This process is also called a service algorithm, or a queue 

service algorithm. The scheduler may reserve amounts of bandwidth, or a percentage of link 

bandwidth, for a particular queue. The scheduler may always service one queue first, which 

means the packets in that queue will experience very low delay and jitter. 

Расчет полосы для классов в Cisco MQC c LLQ и Bandwith

Вычитаем размер bandwith зарезервированный системой для трафика класса default, который по умолчанию равен 25%( определяется командой max-reserved bandwith), от  пропускной способности  интерфейса (определяется командой bandwith).
Bandwith If -   Reserved Bandwith for class Default(25%)=75 Kbit/sec
Затем вычитаем 20% от пропускной способности интерфейса, которые зарезервированы для LLQ:
75Kbit/sec - (100Kbit/sec*0.2)=55Kbit/sec
Это наша доступная полоса для других классов. Как мы знаем для class-default система зарезервировала 25%, для LLQ мы получим свои 20% или 20 Kbit/sec в нашем случае, и все что остается в размере 55Kbit/sec мы будем делить согласно нашей конфигурации.
Так как у нас стоит директива для класса class2 bandwith remaining percent 20, то в итоге мы получаем следующее:
55Kbit/sec * 0.2(bandwith remaining percent 20)=11Kbit/sec

Qos Pre-classify. Где применять?

The quiz shows a scenario where the network engineer has to configure Low Latency Queuing (LLQ) for some traffic that will be encrypted into an IPsec tunnel.
The configuration of the policy-map is given but it has not been applied yet anywhere, as shown below:

The final question is "what is missing to finish this task ?" giving the impression that the answer to the quiz is very simple: apply the policy-map..

Unfortunately, the answer is not that simple...

Where to Apply the Service Policy

1. applying the policy-map onto the physical interface

R2#conf t
R2(config-if)#int s0/0
R2(config-if)#service-policy output LLQ
R2(config-if)#end

This configuration does not have the effect that we want because the ACL searches for traffic between host 192.168.1.1 and host 192.168.5.5 (the inner header), but the policy-map sees only the outer header of the tunnel.
See the zero counters (after sending 100 pings from 192.168.1.1 to 192.168.5.5 via the tunnel):

R2#sh policy-map int
 Serial0/0

  Service-policy output: LLQ

    Class-map: IMPORTANT_TRAFFIC (match-all)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group name ACL_IMPORTANT_TRAFFIC
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 33 (%)
        Bandwidth 509 (kbps) Burst 12725 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      101 packets, 15624 bytes
      5 minute offered rate 2000 bps, drop rate 0 bps
      Match: any
R2#

2. applying the policy-map onto the tunnel interface
At first look, this would represent the correct solution and it might work with a different type of policy-map, but not with a Class Based Weighted Fair Queueing (CBWFQ):

R2(config)#int tun0
R2(config-if)#service-policy output LLQ
*Mar  1 00:02:08.547: Class Based Weighted Fair Queueing not supported on interface Tunnel0
R2(config-if)#end

As you can see, the IOS parser does not accept the LLQ policy-map to be applied directly onto the VTI (Tunnel0) interface.
On Cisco, logical interfaces (tunnel interfaces, sub-interfaces, etc) do not understand the state of concestion (since they are logical) and as a result you cannot apply a queueing mechanism. There is a workaround as described later on.

Solutions

There is a workaround for each of the two situations described above:

1. QoS Pre-Classify - applying the policy-map onto the physical interface

The recommended solution for this quiz is to use the QoS Pre-Classify feature and apply the policy-map to the physical interface.
This features tells the router to keep a temporary copy of the packet's header in its memory (the inner header, before encapsulation and/or encryption) and use it to make QoS decisions such as priority queueing or classification.

R2#conf t
R2(config-if)#int s0/0
R2(config-if)#service-policy output LLQ
!
!
R2(config)#int tun0
R2(config-if)#qos ?
  pre-classify  Enable QOS classification before packets are tunnel
                encapsulated

R2(config-if)#qos pre-classify

R2#sh policy-map interface
 Serial0/0

  Service-policy output: LLQ

    Class-map: IMPORTANT_TRAFFIC (match-all)
      100 packets, 15600 bytes
      5 minute offered rate 2000 bps, drop rate 0 bps
      Match: access-group name ACL_IMPORTANT_TRAFFIC
      Queueing
        Strict Priority
        Output Queue: Conversation 264
        Bandwidth 33 (%)
        Bandwidth 509 (kbps) Burst 12725 (Bytes)
        (pkts matched/bytes matched) 0/0
        (total drops/bytes drops) 0/0

    Class-map: class-default (match-any)
      1 packets, 24 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
R2#

NOTE	The qos pre-classify feature can be applied either to the tunnel interface or to crypto-maps (for IPsec tunnels).

2. Hierarchical Queueing Framework (HQF) - applying the policy-map onto the tunnel interface

The workaround mentioned for the above scenario #2 is to configure a hierarchical QoS (HQF) service policy that will can be applied to the logical (Tunnel0) interface.

R2#conf t
R2(config)#policy-map HQF
R2(config-pmap)#class class-default
R2(config-pmap-c)#shape average 1544000
R2(config-pmap-c)#service-policy LLQ
R2(config-pmap-c)#exit
R2(config-pmap)#exit
R2(config)#int tun0
R2(config-if)#service-policy output HQF
R2(config-if)#exit

R2#sh policy-map interface
 Tunnel0

  Service-policy output: HQF

    Class-map: class-default (match-any)
      102 packets, 10499 bytes
      5 minute offered rate 2000 bps, drop rate 0 bps
      Match: any
      Traffic Shaping
           Target/Average   Byte   Sustain   Excess    Interval  Increment
             Rate           Limit  bits/int  bits/int  (ms)      (bytes)
          1544000/1544000   9650   38600     38600     25        4825

        Adapt  Queue     Packets   Bytes     Packets   Bytes     Shaping
        Active Depth                         Delayed   Delayed   Active
        -      0         102       10099     0         0         no

      Service-policy : LLQ

        Class-map: IMPORTANT_TRAFFIC (match-all)
          100 packets, 10400 bytes
          5 minute offered rate 2000 bps, drop rate 0 bps
          Match: access-group name ACL_IMPORTANT_TRAFFIC
          Queueing
            Strict Priority
            Output Queue: Conversation 72
            Bandwidth 33 (%)
            Bandwidth 509 (kbps) Burst 12725 (Bytes)
            (pkts matched/bytes matched) 0/0
            (total drops/bytes drops) 0/0

        Class-map: class-default (match-any)
          2 packets, 99 bytes
          5 minute offered rate 0 bps, drop rate 0 bps
          Match: any

REMEMBER

Since HQF is a logical engine, it needs shaping to be configured in order to be able to provide other QoS functions.

Some final notes:

• each of the above solutions have pro's and con's in specific scenarios and you may need to evaluate them before choosing the right solution
• be aware that on some platforms (low end ones, usually) using shape command on the tunnel interfaces might cause high CPU problems
• applying the service policy on the physical interface does account for the tunnel overhead

Where Do I Apply the Service Policy?

You can apply a service policy to either the tunnel interface or to the underlying physical interface. The decision of where to apply the policy depends on the QoS objectives. It also depends on which header you need to use for classification.

• Apply the policy to the tunnel interface without qos-preclassify when you want to classify packets based on the pre-tunnel header. Применяем политику на туннельном интерфейсе без директивы qos-preclassify, когда мы хотим классифицировать пакеты на основе оригинальных (pre-tunneled) заголовков.
• Apply the policy to the physical interface without qos-preclassify when you want to classify packets based on the post-tunnel header. In addition, apply the policy to the physical interface when you want to shape or police all traffic belonging to a tunnel, and the physical interface supports several tunnels. Применяем политику на физическом  интерфейсе без директивы qos-preclassify, когда мы хотим классифицировать пакеты на основе внешних (post-tunneled) заголовков. 
• Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface when you want to classify packets based on the pre-tunnel header. Применяем политику на физическом интерфейсе с дополнительной  директивой qos-preclassify на туннельном интерфейсе, когда мы хотим классифицировать пакеты на основе оригинальных (pre-tunneled) заголовков.

• Where to Apply the Qos-Preclassify