QoS and GRE Tunnels

[Gavin Sparks]

I have a QoS Policy that doesn't appear to be working as I expected.

Two Routers A end and B end.

A GRE tunnel runs between them and the policy is identical at each end.

 Class Map match-any Gold
   Match protocol rtp audio

 Class Map match-any Silver
   Match protocol h323

 Class Map match-any Bronze
   Match protocol sip

 Class Map match-all Default
   Match any

policy-map Child_Policy
 Class Gold
  Priority percent 10 
 Class Silver
  bandwidth percent 20
 Class Bronze
  bandwith percent 10
 Class class-default
  random-detect dscp-based

policy-map Parent_Shaper
 class class-default
  shape average percent 100
   service-policy Child_Policy

policy-map Marking_Policy
 class Gold
  set dscp ef
 class Silver
  set dscp af41
 class Bronze
  set dscp af31
 class Default

int g1/0
Outside

vrf forwarding FrontDoor
Service-policy output Parent_Shaper

Int g2/0
Inside
service-policy input Marking_Policy

ip nbar-protocol discovery ipv4

vrf forwarding BackDoor

Int t1
Tunnel

vrf forwarding Backdoor

ip add x.x.x.x y.y.y.y

The Marking Policy matches as expected but the Parent_Shaper policy on the physical interface g1/0 is empty for matched packets.

Would this be due to a quiet link therefore the policy hasn't kicked in? Or something wrong in my config?

What am I missing?

Thanks in advance!

[Rolando Valenzuela]

QoS will work only link congestion.

If your link it is not suffering congestion, your policy will not be matched, you can check that with the command "show interfaces" and look for the Queue statistics.

Regards.

Rolando A. Valenzuela

[Joseph W. Doherty]

Why is your parent policy shaping at 100%? I.e. as your shaping is restricting bandwidth, you shouldn't need to shape. (At least I don't think so, but ASR1Ks QoS is a bit different from ISRs, of which I'm much more familiar.) You might be able to apply your current "child" policy with just a bandwidth statement on the tunnel interface.

BTW, I generally recommend against using WRED unless you're a QoS expert. (It's not as simple to get it to work optimally as the Cisco's documentation can lead one to believe.)

[paul driver]

Hello

Just like to add - Looking at your class map match statements possibly look into also applying  qos pre-classify  to the tunnel interface and some WFQ to the child policy class class-deafult 

[Joseph W. Doherty]

Ah, Paul makes an interesting suggestion about pre-classify.

That may not help with all (specifically - deep packet inspection) NBAR matching, as what pre-classify does (I recall) is save a copy of the original packet's headers to examine during tunnel egress. That said, assuming NBAR might not work for all protocols during tunnel egress (with or without pre-classify), the alternative would be to examine and mark packets upon ingress and then only match against markings upon egress (and for that, you wouldn't need pre-classify).

Paul's suggestion about using WFQ in class-default is great! it's often a much better choice than WRED.

Also BTW, I don't believe (?) you need to enable nbar-discovery for routine CBWFQ class-map matching. However, if you're looking for NBAR analysis stats, then you would need to enable it.