3560G output drops

[dan.letkeman]

Hello,

We are seeing some high output drops on our 3560G's and I'm wondering if there is anything I can do to solve this, or should I just be looking at an upgrade.

I do not have qos enabled:

do-rs-ah-3560g#show mls qos

QoS is disabled

QoS ip packet dscp rewrite is enabled

I don't have anything special configured apart from some trunk ports, otherwise its mostly defaults.

Should I enable qos and tweak the buffering?

Thanks,

Dan.

[singhaam007]

Hello Dan,

i dot think so qos will help here but may be it will make drops more worse. It will divide the bandwidth into queues. Yes you can change the buffer size and it will help to some point but it will create trouble for another queues.

Is there any duplex mismatch or network congestion ??

Please post show interface command.?

It may be cable issue.

thanks

[dan.letkeman]

GigabitEthernet0/1 is up, line protocol is up (connected)

  Hardware is Gigabit Ethernet, address is 000a.b8a8.4301 (bia 000a.b8a8.4301)

  Description: p4500 node1 nic1

  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,

     reliability 255/255, txload 10/255, rxload 2/255

  Encapsulation ARPA, loopback not set

  Keepalive set (10 sec)

  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX

  input flow-control is off, output flow-control is unsupported

  ARP type: ARPA, ARP Timeout 04:00:00

  Last input 5d18h, output 00:00:01, output hang never

  Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 741668

  Queueing strategy: fifo

  Output queue: 0/40 (size/max)

  30 second input rate 8558000 bits/sec, 933 packets/sec

  30 second output rate 40509000 bits/sec, 3435 packets/sec

     220135748 packets input, 198233225191 bytes, 0 no buffer

     Received 23747 broadcasts (23736 multicasts)

     0 runts, 0 giants, 0 throttles

     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored

     0 watchdog, 23736 multicast, 0 pause input

     0 input packets with dribble condition detected

     1866977140 packets output, 2718876986062 bytes, 0 underruns

     0 output errors, 0 collisions, 1 interface resets

     0 unknown protocol drops

     0 babbles, 0 late collision, 0 deferred

     0 lost carrier, 0 no carrier, 0 pause output

     0 output buffer failures, 0 output buffers swapped out

There are many interfaces that look like this.  I believe it has to do with microbursts.  I don't think anything except upgrading the switch will help.  We are not really seeing performance degredation, just output drops.

[paolo bevilacqua]

I see that on various switches. Doing IOS upgrade helped to point.

In reality there is no application packet loss or perfoermance impact whatsoever.

And the ratio to tolat is neglible.

[Arumugam Muthaiah]

Hi,

I can see the interface counter is never cleard. Please clear the counter and verify that how often drops count is incrementing.

Last clearing of "show interface" counters never

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 741668

Then, verify #show interface counters errors (how often you see the output drops)

If you are not overutilizing the circuit, maybe that could be send traffic bursts. Then you will see the output drops as the interface queue is not able to handle these peaks of traffic.

But if you have constant bursty traffic there is no much thing to do, you need to upgrade the switch which support more traffic.

Regards,

Aru

*** Please rate if the post is useful ***

[Joseph W. Doherty · Accepted solution]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

If your drops are indeed caused by microbursts, an "upgraded" device might not help.

If your drop percentages are like the one interface which you posted, I agree with Paolo that the impact is negligible.

However, also if microbursts, drops might be mitigated by buffer tuning on your existing platform.

[dan.letkeman]

I have found mixed information on tuning to fix this problem.  I currently have qos off, could I turn it on and tune the buffers to work better than the defaults when qos is off?

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

dan.letkeman wrote:
I have found mixed information on tuning to fix this problem.  I currently have qos off, could I turn it on and tune the buffers to work better than the defaults when qos is off?

Yes, I believe there's a chance for it to work better.

[dan.letkeman]

Ok, well I am willing to give it a try.  Do you have a base set of mls commands that I could start from?  I did some reading and some people are changing the default:

mls qos queue-set output 1 threshold 1

mls qos queue-set output 1 threshold 2

to a much higher value to compensate, but I am not sure that this is the only thing I need to do.  Any examples and info would be great.

Thanks,

Dan.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Have you read https://supportforums.cisco.com/docs/DOC-8093, especially section 3?  It discusses how to reduce drops with QoS threshold and buffer tuning vs. disabled QoS.