Re: Output Drops on Gig Interface

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 Sat May 08 2010 - 21:18:51 ART