On 17 September 2015 at 04:29, CiscoNSP List <[email protected]> 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
