Re: Output Drops on Gig Interface

I think that if you're not doing any QoS, then it absolutely makes sense to
increase the weight and queue-limit...might as well use it all when you are
planning on only having 1 class of traffic.

On Sat, May 8, 2010 at 11:18 PM, naman sharma <naman.prep_at_gmail.com> wrote:

> Hi David,
>
> This is a PE device and the interface having drops is a MPLS interface. Now
> as we are not doing any Qos on the MPLS it is classifying all the packets
> with default value and putting it in Queue 1. As as Queue 1 holds only
> certain amount of buffer it is leading to packet drops. Is increasing the
> weight and queue-limit a good idea.
>
> Marko: I understand that the interface drops are less as compared to the no
> of packets exiting but still customer would like to remove that from the
> interface. I understand your point but it is slightly difficult for me to
> explain my point. Hope you wil understand. :-).
>
> thanks
>
>
> On 7 May 2010 06:12, David Bass <davidbass570_at_gmail.com> wrote:
>
>> Can you paste the QoS config for the ports and the global config? Is
>> there a reason you have QoS enabled on the device, but aren't trusting
>> anything? You do know that when you don't trust that the box will rewrite
>> the DSCP value to 0 right?
>>
>> On Wed, May 5, 2010 at 4:53 PM, Marko Milivojevic <markom_at_ipexpert.com>wrote:
>>
>>> On Wed, May 5, 2010 at 20:36, naman sharma <naman.prep_at_gmail.com> wrote:
>>> > nope Kambiz i am based out of US..I understand that these drops are
>>> less but
>>> > as technical person i would like to know the reason of the drops. I am
>>> doing
>>> > some tests.. Will update the group with the status.
>>>
>>> Are they seeing the counter increase, or are they observing actual
>>> performance degradation? That's the important thing. Also, the counter
>>> increasing means nothing. The dropped packet, for all we know, could
>>> have dropped because the destination host was no longer present
>>> (dropped out of ARP table just before the packet was sent, but after
>>> it entered the queue - though I doubt this kind of verification is
>>> performed in the queue)... or any corner case like that. What you
>>> should keep an eye on is the RATE if failure, that is ratio of
>>> transmitted and dropped packets. There are dropped packets in *every*
>>> network. If the rate is below certain threshold (and this is almost
>>> 10x below it), that's about it.
>>>
>>> Now... of course, there is nothing to worry about, but there are
>>> multiple factors that can be causing this. For starters - have you
>>> checked the optics? Are those OK? Have you tried replacing them with
>>> different ones? What are the distances involved - could you be sending
>>> too strong signal (I see you are using LX SFPs and sometimes those
>>> lasers are too strong and could cause performance degradation on the
>>> receiver - you may need attenuators). Could it be too long and you may
>>> need to replace the optics with ZX? Finally... are you using
>>> Cisco-branded (bleh, those were the worst for me) optics or 3rd party
>>> - how reliable is your vendor?
>>>
>>> --
>>> Marko Milivojevic - CCIE #18427
>>> Senior Technical Instructor - IPexpert
>>>
>>> YES! We include 400 hours of REAL rack
>>> time with our Blended Learning Solution!
>>>
>>> Mailto: markom_at_ipexpert.com
>>> Telephone: +1.810.326.1444
>>> Fax: +1.810.454.0130
>>> Web: http://www.ipexpert.com/
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Mon May 10 2010 - 09:42:43 ART