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:[email protected]] On Behalf Of CiscoNSP List Sent: Thursday, September 17, 2015 6:30 AM To: James Bensley <[email protected]>; [email protected] 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 <[email protected]> Sent: Wednesday, 16 September 2015 10:49 PM To: [email protected]; CiscoNSP List Subject: Re: [c-nsp] Tail drops on ME3600 with shaping policy On 16 September 2015 at 10:10, CiscoNSP List <[email protected]> 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 [email protected] 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. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
