i agree with Farrukh

according to cisco SRND

In Cisco AVVID solutions, the IP Phone and gateways provide the capability to set the ToS byte so

routers can make the appropriate QoS decision. However, most data applications do not set the ToS byte

and queuing decisions must be based on other fields of the IP header, including source/destination IP

address, port numbers, and protocol

Once the original IP packet is encrypted by IPSec, fields other than ToS byte, such as port numbers,

protocol and source/destination IP address fields, are no longer in clear text and cannot match an output

service policy. QoS Pre-Classify is an Cisco IOS software feature to allow fancy queuing,

CBWFQ/WFQ, at the output interface to match on these other fields in the original IP header, even after

the original IP header is encrypted

howver

u can use matching in the calss map and make the matching based on ur vpn tunnel-gourp that u have

in the case u can play with priority or bandwidth limitation

check the following link

PIX/ASA 7.x and Later: Bandwidth Management(Rate Limit) Using QoS Policies

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a008084de0c.shtml

good luck

please, if helpful Rate

Awesome! I did not realize the RFC called for that ToS bytes to be copied from the inner header to the outer header. I was planning on testing this out today by creating the policy-maps and running a capture on the other VPN endpoint to see if I see the DSCP bits set in the outer headers. I will let you guys know what I find.

Thanks!

It does work! Thanks for letting me know this! See attached picture.

Thanks!!!!

Brantley this is 5+ :)