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

[Spyros Kakaroukas]

We use it on core-facing links for classes where it makes sense ( ie, not real-time classes ) . As far as customer services are concerned, we've only had to manually adjust the queue depth only a couple of times, for some special cases with special requirements. Since it's so rare, I haven't included it as a default in any policies so far. However, no two networks are ever exactly the same, so your mileage may vary.

As far as the ASR920's are concerned, I *think* they make the same default buffer space allocations as the ME3600s, while their total buffer space is even less.


My thoughts and words are my own.

Kind Regards,

Spyros
-----Original Message-----
From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of CiscoNSP List
Sent: Thursday, September 17, 2015 6:30 AM
To: James Bensley <jwbensley at gmail.com>; cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Tail drops on ME3600 with shaping policy

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.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


This e-mail and any attachment(s) contained within are confidential and are intended only for the use of the individual to whom they are addressed. The information contained in this communication may be privileged, or exempt from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete the communication without retaining any copies. Connecticore SA is not responsible for, nor endorses, any opinion, recommendation, conclusion, solicitation, offer or agreement or any information contained in this communication.