Hi!
Could anybody help me understand the following example taken from cisco.com (DMVPN SRND) and mentioned there as a "best practice":
class match-any voice ... class match-any mission-critical ... ! Other classes
policy-map my-policy class voice priority percent 20 class mission-critical priority percent 40 class other bandwidth ... class class-default fair-queue
policy-map my-shaper class class-default shape average 256000 service-policy my-policy
interface fa0/0 service-policy output my-shaper
Shaping is used here because not all bandwidth of fa0/0 is available (ISP polices our traffic). Inside the shaper voice and mision-critical classes should have priority treatment.
Unfortunately it simply doesn't work (IOS 12.4(5)). ALL traffic classes are shaped equally. ALL packets (voice, data, etc.) go to the shaper buffers in FIFO order (!), delayed there (!) and then processed by the inner policy-map (my-policy). Policy-map my-shaper has no idea about priorities of classes in the inner policy-map (my-policy). This is not good for voice, to say the least.
I've verified this with IPSec (DMVPN) and without IPSec configured, so this is not an IPSec problem, it is the QoS problem.
Can anybody tell me is this a bug or feature? Are there workarounds?
Also, does anybody know why is "match protocol" not working with IPSec qos-preclassify feature ("match access-group" works well)? So far as I know "match protocol icmp" doesn't mean that NBAR (which is not supported with IPSec) must be used by the router to classify traffic. In this simple case the router can classify traffic by Protocol field in the IP header, right? Am I mistaken?
Thx, Oleg Tipisov, REDCENTER