If QoS markings are applied before they enter the router, these markings will be automatically reflected into the GRE or IPSec header.
If QoS markings are applied on the router itself, these markings won't be reflected into the GRE or IPSec header without the QoS Pre-classify command.
If I want to implement QoS in the WAN should I use QoS pre-classify?
I mean what is the best practice to implement QoS and do I need to implement QoS pre-classify in this solution?
I already addressed on which situation you would use QoS pre-classify.
Having QoS pre-classify in the VPN config (either on the GRE tunnel or within the IPSec policy) wouldn't affect the QoS markings but not having QoS pre-classify in some QoS scenarios - such as performing QoS markings in the router itself - would affect QoS.
There is no best practice. You need to understand what the command actually does. I explained what it does already.
In addition to what Edison has stated, you typically use qos pre-classify in one of the following ways:
- if you already have IP Prec/DSCP markings in the ToS byte and that is all you need to use to classify the traffic (as opposed to using things such as source/dest ip, source/dest port number, etc) then you don't need to use qos pre-classify because as Edison said, the pre-tunnel IP header is automatically copied to the post-tunnel IPSec or GRE header
- if you want to classify traffic based on something other than IP Prec/DSCP markings (such as source/dest ip, protocol, port number, etc) then you either:
- apply the service-policy to the tunnel interface without qos pre-classify if you want to use the pre-tunnel header
- apply the service-policy on the physical interface without using the qos pre-classify command if you want to classify traffic on the post-tunnel header
- apply the service-policy on the physical interface with the qos pre-classify command if you want to use the pre-tunnel header
Perhaps to add to both to the information that the other posters have provided, and to clarify QoS pre-classify, you need to understand, by default, if you QoS analyze encrypted packets that's all your QoS analysis "sees" except for the original (pre VPN) packet's DSCP marking (which is copied to the VPN packet).
What pre-classify does is provide a copy of the original packet's header so that QoS analysis applied to the VPN packets can "see" this information.
For example, QoS analysis of VPN packets, by default, could not easily distinguish between a telnet or a FTP packet. With pre-classify active, QoS analysis could "see" a copy of the original packet's IP addresses, protocol and port numbers.
Something I'm not sure about, how deeply pre-classify supports QoS analysis. For instance, some NBAR analysis might not work. Again, though, not sure.
Thanks for the detail regarding a copy of the original header. This information is key to understanding the "magic" behind the pre-classify command.
In my own simpleton mindset I see it as follows- I am sure if I am incorrect others will show me the error of my ways!
If you want to mark traffic before encapsulation occurs thus allowing your traffic to be differentiated from other qos traffic then you can or don’t have to use this feature in the following scenarios:
1) If your marking is ONLY based on ip prec/dscp values then qos pre-classify is NOT required
2) If your service-policy applied directly onto tunnel then qos pre-classify is NOT required ( even using additional marked values)
3) If your service-policy applied to physical interface of tunnel(s) using additional marks values such as sip/dip - port- protocol etc then qos pre-classify IS required on each preferable tunnel(s)