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