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

[CiscoNSP List]

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.


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 have recently purchased a whole bunch of ASR920's(Instead of ME3600's) - Are they also afflicted with this issue?


Thanks again to all who replied....much appreciated.


________________________________________
From: James Bensley <jwbensley at gmail.com>
Sent: Wednesday, 16 September 2015 10:49 PM
To: cisco-nsp at puck.nether.net; CiscoNSP List
Subject: Re: [c-nsp] Tail drops on ME3600 with shaping policy

On 16 September 2015 at 10:10, CiscoNSP List <CiscoNSP_list at hotmail.com> wrote:
>
> Thanks very much James - Very helpful!
>
>
> So there's no singular way I can test this (queue-limit percent 100) on a single service instance under an Interface? i.e. Id have to re-do the entire qos policy for the Interface and associated service instances?
>
>
> In our current situation, we have ~30 service instances, all varying subscribed speeds under one Interface...only a few of them are showing tail drops, so I was hoping to test the queue limit "fix" on one or two of them...but from what Im reading in your reply, this doesnt look to be possible?


As per Adam's suggestion you can apply the policy lower down in the
tree of physical port > VLAN/service instance > individual traffic
class. Also you could match based on service instance in a parent
policy applied at the interface level. There's often more than way to
to achieve the same result.

Spyros mentioned about over-buffering. I don't see any problem with
this, with "queue-limit percent 100" the IOS resource manager will
allocate more buffers to the port as requried (as throughput
increases) and de-allocated them when they aren't need, otherwise you
couldn't have more than one traffic class on the entire switch with
"queue-limit percent 100" configured. The idea/approach I use is that
the command can be applied everywhere and just let the ASIC handle it.
This has removed tail-drops for us without any further issues or
repercussions.

Cheers,
James.