[c-nsp] Tail drops on ME3600 with shaping policy

[James Bensley]

On 17 September 2015 at 04:29, CiscoNSP List <CiscoNSP_list at hotmail.com> wrote:
> Thanks James - If the queue-limit percent 100 alleviates the issue for the one service instance Ive applied it to, I might look at implementing your solution, if you have had success with it eliminating tail drops.

I will answer your questions in reverse order:

> We have recently purchased a whole bunch of ASR920's (Instead of ME3600's) - Are they also afflicted with this issue?

Tail drops can potentially affect any device where you have
insufficient buffers, any device where you are doing something extreme
like stepping down from 10Gbps to 10Mbps will likely cause tail drops
unless unusually large buffers are assigned to that port by default.

For the ASR920's we have only rolled a hanful out and they seem OK so
far, I expect in the near future as we start to roll out more though
more issues like tail drops will crop up. Just looking on an ASR920 in
the lab, I can set queue-limit percent 100, Cisco would need to
confirm if this works the same as the MEs with some sort fo internal
memory allocation manager dyanimcally allocating and revoking memory
to port buffers as required. I would expect so though as the ASR920s
are essentially the next generation of the same ASIC.


> Side note - Are "most" using this type of solution on the ME3600's...we've only got approx 100 services deployed on 8 ME's, and havent run into any issues until now with tail drops....but this service is provided by a carrier that requires insane shaping to be applied at both ends(PE/CE), or there service simply works horribly.

We had a discussion with Cisco and I'm not sure if it was under NDA or
not, so no precise comment here but as we all know there are many bugs
with these ME boxes. Another bug is the help text is wrong for the
queue-limit command:


15.3(3)S on a test switch:

 Switch(config)#class-map match-any CM
Switch(config-cmap)#match protocol ip
Switch(config-cmap)#exit
Switch(config)# policy-map PM
Switch(config-pmap)#class CM
Switch(config-pmap-c)#shape average 100m
Switch(config-pmap-c)#queue-limit ?
<1-8192000>    in bytes, <1-512000> in us, <1-8192000> in packets by default
Switch(config-pmap-c)# queue-limit 8192000 bytes
QOS: Qlimit threshold value is out of range
Min and Max bytes qlimit are 200 & 2097152
queue-limit: platform params check fail
%QOSMGR-3-QLIMIT_VALUE_OUT_OF_RANGE: Qlimit value is out of range
Switch(config-pmap-c)# queue-limit 2097152 bytes

I can't set a queue depth above 2097152 bytes as above. So in this
case I would need to use the percentage option instead. We have
hundreads of the ME3600/ME3800's wit thousands of circuits hanging off
them, as tail-drop issues crop up we are pushing out this new (to us)
style of config to the affected PE and it's always resolving the
issue.

So to answer your first question, yes we are using a reasonbble
amount, we often have 10G backhauls to the ME switch in a PoP, with a
1G patch to a DSLAM with customers coming in from the DSLAM on
difference VLANs (so service instances) on that 1G link. Some of those
customers are shaped as low as 10Mbps (such as 10Mbps EFM) so we are
hitten the extreme and this is fixing the issue.


Cheers,
James.