LLQ not utilizing reserved bandwidth & packet drops in Nested policy-map (2 level hierarchial policymap)
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
Average Rate Traffic Shaping
cir 128000 (bps)
C2800-R6-CPE1#sh policy-map child-out1
Policy Map child-out1
priority 50 (%) 1600
bandwidth 20 (%)
bandwidth 10 (%)
bandwidth 10 (%)
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.
Re: LLQ not utilizing reserved bandwidth & packet drops in Neste
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.
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.
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.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...