[c-nsp] Hierarchical QoS Policies

Andre Beck cisco-nsp at ibh.net
Wed Apr 6 12:54:20 EDT 2005


Hi,

in a lab test today I've tried to put traffic prioritization under a
shaper using policy-map hierarchically, and put the top level policy
onto the interfaces of a 831 running 12.3(14)T (which BTW crashed at
least 4 times in the last two days, so better stay away). The policy
was quite simple:

class-map match-all icmp-class
 match  access-group icmp-acl	! this is a "permit icmp any any" acl

policy-map icmp-priority
 class icmp-class
  priority percent 10
 class class-default
  bandwidth remaining percent 100

policy-map shape-all
 class class-default
  shape average 100000
  service-policy icmp-priority

Intention is to shape everything to 100kbps first, giving ICMP absolute
priority up to 10% of the available bandwidth (results in 10kbps) with
LLQ, while any other traffic gets the remaining bandwidth. I've also
tried "fair-queue" instead of "bandwidth remaining percent 100" with
no difference in the results. Policy was applied in output direction
to both Ethernet interfaces of the box. The box was doing overload NAT
and CBAC at the same time.

Now I started a "ping -s 1000" through the router and it appeared in the
icmp-class as expected. Then I started to downlad something large and
watched what happened. I *expected* the ping to run on smoothely while
the download is getting the remaining bandwidth so both together come
out shaped to 100kbps. What actually *happened* was the ping went stuck
almost instantly and "sh policy-map interface" made clear that the policy
was dropping packets - it was dropping them in class icmp-priority while
there wasn't a single drop in class-default! I expected it the other way
around: priority traffic will be the last thing that gets drops and only
so if it exceeds its guranteed bandwidth. I would have expected the ping
to get occasional delay when it exceeds 10kbps, like with 1400 byte
packets. Instead, even with smallest packets, I got very high RTTs which
made clear that it's neither LL nor PQ or at least it doesn't interact
correctly with the shaper.

What I'm now desperately want to know: Did I misunderstand the QoS concept
of hierarchical policy-maps with a shaper at the top completely? Or is
it just the implementation on the 831 that's broken? Or just 12.3(14)T?

I'm asking because I'm running something similar in production (where
the top policy-map is applied to tunnel interfaces) and there it seems
to work as expected so far. But that might have been by accident...

TIA,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-


More information about the cisco-nsp mailing list