Qos Pre-Classify
The point of the qos pre-classify command is to be able to read and manipulate the IP header of a packet going through a VPN. The problem is that when a packet enters a VPN it is encrypted, header and all. After this command is applied, the router makes a copy of the original IP header so that you can perform QoS manipulation at egress on an interface.

Actually if the ToS byte (DSCP, ECN or IP Precedence) is the only portion of the header that needs manipulation you don’t need qos pre-qualify, however, if you need access to source or destination ip address or port numbers then you need the qos pre-qualify command.

This is better stated on page 231 of the QoS Exam Certification Guide:
Packets entering a router interface, not yet in a VPN tunnel, can be processed with ingress QoS features on that interface just like always.

Packets exiting a router interface, after encapsulation and encryption by that router into a VPN tunnel, cannot be processed with egress QoS features on that interface just like always. The Egress QoS features can only examine the post-encapsulation IP header.

That is why qos pre-classify makes a copy of the original IP header. The command qos pre-classify turns on pre-classification and is restricted to tunnel interfaces, virtual templates, and crypto maps, it is not available on any other interface type.

Applying a QoS policy to a physical interface causes that policy to affect all tunnel interfaces on that physical interface. Applying a service policy to a tunnel interface affects that particular tunnel only and does not affect other tunnel interfaces on the same physical interface.

The configuration below only applies qos pre-classify to the tunnel interface:

interface Tunnel0
 ip address 192.168.13.1 255.255.255.0
 qos pre-classify
 tunnel source Serial0/0
 tunnel destination 192.168.123.3

From page 195 of the ONT book:

• To classify packets based on the pre-tunnel header, apply the QoS policy to the tunnel interface without QoS pre-classify.
• To classify packets based on the post-tunnel header, apply the QoS policy to the physical interface without QoS pre-classify.
• To classify packets based on the pre-tunnel header, apply the QoS policy to the physical interface and enable QoS pre-classify.

Generic Routing Encapsulation (GRE)
Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that can encapsulate a wide variety of protocol packet types inside IP tunnels, including routing protocols, multicast packets and non-IP traffic. GRE tunnels create a virtual point-to-point link between Cisco routers at remote points over an IP internetwork. GRE itself does not provide data confidentiality using encryption.

IPSec Authentication Header (IPSec AH)
IPSec Authentication Header (IPSec AH) is a security protocol that provides authentication and optional replay-detection services. Transport mode is applicable only to host implementations and provides protection for upper layer protocols, in addition to selected IP header fields. AH can be used either by itself or with Encryption Service Payload (ESP).

Tunnel mode AH may be employed in either hosts or security gateways. When AH is implemented in a security gateway to protect transit traffic tunnel mode must be used.

IPSec AH is documented in RFC 2402.

Click here for a better image.

IPSec Encapsulating Security Payload (ESP)
IPSec Encapsulating Security Payload (ESP) is documented in RFC 2406.

The ESP header is inserted after the IP header and before the upper layer protocol header for transport mode or before an encapsulated IP header in tunnel mode.

Click here for a better image.

Tunnel mode in both IPSec ESP and IPSec AH the original packet header ToS byte is copied to the encapsulating IP packet header ToS byte and is available for QoS purposes. In transport mode, the entire original IP header is available for QoS processing in both.

End-to-End QoS
This may sound rudimentary, but in order to reap the benefits of QoS, it must be deployed consistently throughout an AS. At the access layer trust must be set appropriately, the correct queues on created on switch ports with priority queuing for VOIP. At the distribution layer you should employ layer 3 policing and marking, have the correct queues created, priority queuing for VOIP and use WRED in data queues. At the AS edge you should employ classification and marking, WRED, LLQ and LFI.

Now that service providers offer layer 3 hand-off it is more important to coordinate QoS setting with you provider. Layer 3 allows them more flexibility in in how they handle traffic. Typical service provider SLAs include up to five traffic classes, ranging from real-time to best effort.

These are the guidelines for implementing QoS in an AS taken from page 189 of ONT book:

• Classify and mark as close to the source as possible.
• Police traffic as close to the source as possible.
• Establish proper trust boundaries.
• Classify and mark real-time voice and video as high-priority traffic.
• Use multiple queues on transmit interfaces.
• Try to perform hardware-based rather software-based QoS.

Control Plane Policing
The control plane of a Cisco router includes the data plane, management plane and service plane. Control plane policing allows you to build QoS filters to protect the router against DoS attacks.

Documentation referenced in this post:
CCNP ONT Official Exam Certification Guide
Cisco QoS Exam Certification Guide, Second Edition

Quality of Service Options on GRE Tunnel Interfaces, Document ID: 10106
RFC 2402
<a href="RFC 2406