LLQ not utilizing reserved bandwidth & packet drops in Nested policy-map (2 level hierarchial policymap)

[narainarun]

Hi,

I think this issue is quite old but I could not get any conclusive explanation.

Below is the configuration:

C2800-R6-CPE1#sh policy-map parent-out

  Policy Map parent-out

    Class class-default

      Average Rate Traffic Shaping

      cir 128000 (bps)

      service-policy child-out1

C2800-R6-CPE1#sh policy-map child-out1

  Policy Map child-out1

    Class EF

      priority 50 (%) 1600

    Class DATA1

      bandwidth 20 (%)

    Class DATA2

      bandwidth 10 (%)

    Class DATA3

      bandwidth 10 (%)

C2800-R6-CPE1#

In the above configuration, parent policy has 128Kbps and Child has 4 Classes with Class EF is LLQ with priority of 50% bandwidth (burst size is default 1600bytes), class DATA1 with 20%, class DATA2 with 10% and class DATA3 with 10%.

With the above configuration, I could not able to push beyond 16Kbps of traffic on class EF (LLQ). When the burst size is increased to 16000 bytes, I am able to push around 60Kbps.

Wanted to understand this is the expected behavior of LLQ in Nested policy map or I am missing something.

thanks in advance

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

It's not usual for policers to slow traffic under it's nominal bandwidth with a too small Bc(/Be).  Often traffic is bursty, and a too small Bc(/Be) will drop packets out of a short term bursts even though the longer term average is under the CIR.  When you increase the Bc, you allow the policer to measure rate rate across a longer time period which will then often allow small short term bursts to pass.

The average of 1, 9, 1, 9 and 5, 5, 5, 5 are both 5, but usage is quite different between the two series.  A too small BC, in a policer, might drop all the nines in the first series, but pass the ones and fives.  Increasing the Bc may allow the policer see the longer term average for both series is 5 and pass all the packets.

[Vishesh Verma]

50 (%) Burst 1600 (Bytes) means you can send 1600 bytes in every 200 milliseconds.

Let's do the Maths -

Shaping rate = 128000bps

Priority percent = 50% of shaping rate = 64000

Burst(Bc) = 1600 bytes = 12800 bits

Formula - CIR = Bc/Time-interval(Tc) Or Tc = Bc/CIR

Tc = 12800 bits/64000 bits/sec= 0.2 secs = 200 ms

so if we push 12800 every 200 ms, in one second we can push 12800*5 = 64000 bits

For more info about token buckets, shaping and policing, refer following document -

http://www.cisco.com/c/en/us/td/docs/ios/12_2/qos/configuration/guide/fqos_c/qcfpolsh.html

Regards,

Vishesh